En primer lugar: mi conocimiento del tiempo de los eventos en javascript es deficiente, así que acepte mis disculpas si lo que estoy preguntando parece obvio (y disculpe si lo estoy bombardeando con preguntas).
Cuando un par A maneja la conexión de otro par B a través DataConnection.on('connection', function() {...}) ¿está lista esa conexión dentro del controlador o está completamente disponible después de que el controlador de eventos regresa? Quiero decir: ¿puede A enviar un mensaje de datos a B como en este código?
peerA.on('connection', function(c) {
// do something
c.send("Welcome! (will this message ever got delivered?)");
// do something else
});
En caso de que esto no sea posible, ¿no sería bueno tener un evento 'después de la conexión' para manejar estos casos? ¿O tal vez se espera que funcione el siguiente código?
peerA.on('connection', function(c) {
// do something
setTimeout(function() {
c.send("Welcome! (will this message ever got delivered?)");
}, 0);
});
Gracias.
bilo1967
Todos 7 comentarios
Está listo para ser utilizado en el manipulador. No encuentro muy útil un evento de "comenzar a conectarse". ¿En qué caso te parece útil?
kidandcat
en 25 jun. 2019
En el proyecto que estoy desarrollando, un problema es evitar conexiones no deseadas.
Hay tres roles: estudiante, orador, profesor (he agregado un indicador de metadatos que indica el rol en la matriz de opciones al registrar al compañero). El profesor se conecta al servidor con su DNI, que es conocido, y espera al ponente y al alumno. Una vez que estén todos conectados, se deben evitar más conexiones.
El rechazo que ha implementado en v2.0.0 debería funcionar, pero me parece que los cambios en la API son bastante radicales.
bilo1967
en 26 jun. 2019
Sí, la nueva versión es importante (rompiendo, sin compatibilidad con versiones anteriores). La antigua API es bastante confusa y el código tiene muchos trucos heredados de sus primeros días en 2013, es muy difícil de mantener.
Pero como es un cambio de última hora, seguiré soportando la versión anterior, por lo que implementaré alguna forma de rechazo en la v1. De todos modos, le recomiendo que cambie a v2 si no necesita admitir navegadores muy antiguos. Ganarás en estabilidad y no necesitarás alojar un PeerServer.
El rechazo en v2 aún no está hecho, pero me estoy enfocando en el desarrollo de v2, por lo que esa función estará lista pronto.
kidandcat
en 26 jun. 2019
He echado un vistazo al ejemplo que proporcionó para v2 y realmente se ve impresionante: ¡un simple chat uno a uno en unas pocas líneas de código! Además, modifiqué un poco ese código y vi que onRemoteStream se activa en cada compañero cada vez que alguien se une a la sala, lo que hace posible manejar toda la conexión de medios que puede admitir su ancho de banda: ¡wow!
Solo algunas preguntas:
- ¿Será posible distinguir quién se está conectando usando una característica de metadatos como en v1?
- ¿Podré acceder a transmisiones remotas y locales para realizar algún procesamiento de audio (local) a través de AudioContext? En mi proyecto tengo un compañero A que necesita escuchar pera B en el canal L y C en el canal R de sus auriculares, y cambiar independientemente el volumen de cada uno de ellos; y tanto B como C necesitan un vúmetro conectado a su micrófono para monitorear continuamente si funciona correctamente (ya he implementado estas características en parte y necesito mantenerlas).
- No probé el canal de datos, pero supongo que es lo mismo que el canal de medios: ¿una conexión 1-1 entre cada par con onDataStream disparada en cada conexión? ¿Y los mensajes se enviarán individualmente a cada compañero?
- Es bueno saber que no se necesitará un servidor de pares. Sin embargo, ¿para qué sirve wss://broker.peerjs.com ?
PD He visto que ha actualizado la planificación de la hoja de ruta para agregar un número máximo de pares por sala y eso es algo que realmente necesito.
bilo1967
en 26 jun. 2019
- ¿Será posible distinguir quién se está conectando usando una característica de metadatos como en v1?
¡Sí! Acabo de agregar esa característica al plan, debería ser muy fácil de implementar
- ¿Podré acceder a transmisiones remotas y locales para realizar algún procesamiento de audio (local) a través de AudioContext? En mi proyecto tengo un compañero A que necesita escuchar pera B en el canal L y C en el canal R de sus auriculares, y cambiar independientemente el volumen de cada uno de ellos; y tanto B como C necesitan un vúmetro conectado a su micrófono para monitorear continuamente si funciona correctamente (ya he implementado estas características en parte y necesito mantenerlas).
Ya tiene acceso a las transmisiones en los controladores. No está bien documentado, pero como dijo, recibe una transmisión remota por par y su propia transmisión remota una vez, que se reutiliza para todas las conexiones en este momento, que puede cambiarse en el futuro si es necesario.
¿Quiere decir procesar los flujos antes de enviarlos? si es así, también se puede implementar.
- No probé el canal de datos, pero supongo que es lo mismo que el canal de medios: ¿una conexión 1-1 entre cada par con onDataStream disparada en cada conexión? ¿Y los mensajes se enviarán individualmente a cada compañero?
Sí, recibe los canales de datos sin procesar, uno por par conectado. También funcionará bien con la función de metadatos mencionada anteriormente.
- Es bueno saber que no se necesitará un servidor de pares. Sin embargo, ¿para qué sirve wss://broker.peerjs.com ?
PeerJS necesita un canal para hacer la señalización inicial. Pero ahora, en lugar de usar un PeerServer, toda la lógica está hecha por la propia biblioteca PeerJS, y solo necesita un intermediario MQTT. Por lo tanto, aún necesita un servidor, pero MQTT es un protocolo estándar, por lo que solo necesita configurar un intermediario, además, no necesita una base de datos ni se guarda nada en la memoria del servidor (como en v1), por lo que es completamente escalable.
kidandcat
en 26 jun. 2019
¡Una gran noticia! Creo que definitivamente cambiaré de v1 a v2. Hará que todo sea mucho más fácil. ¡Muchas gracias!
bilo1967
en 26 jun. 2019
Gracias por la biblioteca increíble
shivarajnaidu
en 26 jun. 2019
Temas relacionados
jameshfisher
·
5Comentarios
l2aelba
·
3Comentarios
nick0702y
·
9Comentarios
jameshfisher
·
6Comentarios
kahrkunne
·
4Comentarios
Comentario más útil
¡Sí! Acabo de agregar esa característica al plan, debería ser muy fácil de implementar
Ya tiene acceso a las transmisiones en los controladores. No está bien documentado, pero como dijo, recibe una transmisión remota por par y su propia transmisión remota una vez, que se reutiliza para todas las conexiones en este momento, que puede cambiarse en el futuro si es necesario.
¿Quiere decir procesar los flujos antes de enviarlos? si es así, también se puede implementar.
Sí, recibe los canales de datos sin procesar, uno por par conectado. También funcionará bien con la función de metadatos mencionada anteriormente.
PeerJS necesita un canal para hacer la señalización inicial. Pero ahora, en lugar de usar un PeerServer, toda la lógica está hecha por la propia biblioteca PeerJS, y solo necesita un intermediario MQTT. Por lo tanto, aún necesita un servidor, pero MQTT es un protocolo estándar, por lo que solo necesita configurar un intermediario, además, no necesita una base de datos ni se guarda nada en la memoria del servidor (como en v1), por lo que es completamente escalable.