Peerjs: pós-conexão

Criado em 25 jun. 2019  ·  7Comentários  ·  Fonte: peers/peerjs

Primeiro de tudo: meu conhecimento do tempo dos eventos em javascript é ruim, então por favor aceite minhas desculpas se o que estou perguntando parece óbvio (e desculpe se estou bombardeando você com perguntas).

Quando um peer A manipula a conexão de outro peer B via DataConnection.on('connection', function() {...}) essa conexão está pronta dentro do manipulador ou fica completamente disponível após o retorno do manipulador de eventos? Quero dizer: A pode enviar uma mensagem de dados para B como neste código?

peerA.on('connection', function(c) {
    // do something
    c.send("Welcome! (will this message ever got delivered?)");
    // do something else
});

Caso isso não seja possível, não seria bom ter um evento 'afterconnection' para tratar esses casos? Ou talvez o código a seguir funcione?

peerA.on('connection', function(c) {
    // do something
    setTimeout(function() {
        c.send("Welcome! (will this message ever got delivered?)");
    }, 0);
});

Obrigada.

picture bilo1967

Comentários muito úteis

  1. Será possível distinguir quem está se conectando usando um recurso de metadados como na v1?

Sim! Acabei de adicionar esse recurso ao plano, deve ser muito fácil de implementar

  1. Poderei acessar fluxos remotos e locais para fazer algum processamento de áudio (local) via AudioContext? No meu projeto tenho o peer A que precisa ouvir a pera B no canal L e C no canal R do seu fone de ouvido, e alterar independentemente o volume de cada um deles; e tanto B quanto C precisam de um vu-meter conectado ao microfone para monitorar continuamente se está funcionando corretamente (já implementei esses recursos em parte e preciso mantê-los).

Você já tem acesso aos fluxos nos manipuladores. Não está bem documentado, mas como você disse, você recebe um fluxo remoto por peer e seu próprio fluxo remoto uma vez, que é reutilizado para todas as conexões agora, o que pode ser alterado no futuro, se necessário.

Você pretende processar os fluxos antes de enviá-los? se sim, pode ser implementado também.

  1. Eu não testei o canal de dados, mas acho que é o mesmo que o canal de mídia: uma conexão 1-1 entre cada peer com onDataStream disparado em cada conexão? E as mensagens serão enviadas individualmente para cada peer?

Sim, você recebe os DataChannels brutos, um por peer conectado. Também funcionará bem com o recurso de metadados mencionado acima.

  1. É bom saber que um servidor peer não será necessário. No entanto, para que serve isso wss://broker.peerjs.com ?

PeerJS precisa de um canal para fazer a sinalização inicial. Mas agora ao invés de usar um PeerServer, toda a lógica é feita pela própria biblioteca PeerJS, e ela só precisa de um broker MQTT. Então você ainda precisa de um servidor, mas o MQTT é um protocolo padrão, então você só precisa configurar um broker, também não precisa de um banco de dados ou qualquer coisa é salva na memória do servidor (como na v1), então é completamente escalável.

picture kidandcat em 26 jun. 2019
🎉3

Todos 7 comentários

Está pronto para ser usado no manipulador. Não acho muito útil um evento "start conneting". Em qual caso você acha útil?

kidandcat picture kidandcat em 25 jun. 2019

No projeto que estou desenvolvendo um problema é evitar conexões indesejadas.

Existem três funções: aluno, palestrante, professor (adicionei um sinalizador de metadados indicando a função na matriz de opções ao registrar o colega). O professor se conecta ao servidor com seu ID, que é conhecido, e aguarda o palestrante e o aluno. Uma vez que todos estejam conectados, outras conexões devem ser evitadas.
A rejeição que você implementou na v2.0.0 deve fazer o trabalho, mas me parece que as mudanças na API são bastante radicais.

bilo1967 picture bilo1967 em 26 jun. 2019

Sim, a nova versão é maior (quebra, sem retrocompatibilidade). A API antiga é bastante confusa, e o código tem muitos truques legados desde seus primeiros dias em 2013, é muito difícil de manter.

Mas como é uma mudança de última hora, continuarei suportando a versão antiga, então implementarei alguma forma de rejeição na v1. De qualquer forma, recomendo que você mude para a v2 se não precisar suportar navegadores muito antigos. Você ganhará em estabilidade e não precisará hospedar um PeerServer.

A rejeição na v2 ainda não foi feita, mas estou focando no desenvolvimento da v2, então esse recurso estará pronto em breve.

kidandcat picture kidandcat em 26 jun. 2019

Dei uma olhada no exemplo que você forneceu para a v2 e realmente parece impressionante: um simples bate-papo individual em poucas linhas de código! Além disso, ajustei um pouco esse código e vi que onRemoteStream é acionado em cada peer sempre que alguém entra na sala, tornando possível lidar com todas as conexões de mídia que sua largura de banda pode suportar: uau!

Apenas algumas perguntas:

  1. Será possível distinguir quem está se conectando usando um recurso de metadados como na v1?
  2. Poderei acessar fluxos remotos e locais para fazer algum processamento de áudio (local) via AudioContext? No meu projeto tenho o peer A que precisa ouvir a pera B no canal L e C no canal R do seu fone de ouvido, e alterar independentemente o volume de cada um deles; e tanto B quanto C precisam de um vu-meter conectado ao microfone para monitorar continuamente se está funcionando corretamente (já implementei esses recursos em parte e preciso mantê-los).
  3. Eu não testei o canal de dados, mas acho que é o mesmo que o canal de mídia: uma conexão 1-1 entre cada peer com onDataStream disparado em cada conexão? E as mensagens serão enviadas individualmente para cada peer?
  4. É bom saber que um servidor peer não será necessário. No entanto, para que serve isso wss://broker.peerjs.com ?

PS Vi que você atualizou o planejamento do roteiro para adicionar um número máximo de pares por quarto e isso é algo que eu realmente preciso!

bilo1967 picture bilo1967 em 26 jun. 2019
  1. Será possível distinguir quem está se conectando usando um recurso de metadados como na v1?

Sim! Acabei de adicionar esse recurso ao plano, deve ser muito fácil de implementar

  1. Poderei acessar fluxos remotos e locais para fazer algum processamento de áudio (local) via AudioContext? No meu projeto tenho o peer A que precisa ouvir a pera B no canal L e C no canal R do seu fone de ouvido, e alterar independentemente o volume de cada um deles; e tanto B quanto C precisam de um vu-meter conectado ao microfone para monitorar continuamente se está funcionando corretamente (já implementei esses recursos em parte e preciso mantê-los).

Você já tem acesso aos fluxos nos manipuladores. Não está bem documentado, mas como você disse, você recebe um fluxo remoto por peer e seu próprio fluxo remoto uma vez, que é reutilizado para todas as conexões agora, o que pode ser alterado no futuro, se necessário.

Você pretende processar os fluxos antes de enviá-los? se sim, pode ser implementado também.

  1. Eu não testei o canal de dados, mas acho que é o mesmo que o canal de mídia: uma conexão 1-1 entre cada peer com onDataStream disparado em cada conexão? E as mensagens serão enviadas individualmente para cada peer?

Sim, você recebe os DataChannels brutos, um por peer conectado. Também funcionará bem com o recurso de metadados mencionado acima.

  1. É bom saber que um servidor peer não será necessário. No entanto, para que serve isso wss://broker.peerjs.com ?

PeerJS precisa de um canal para fazer a sinalização inicial. Mas agora ao invés de usar um PeerServer, toda a lógica é feita pela própria biblioteca PeerJS, e ela só precisa de um broker MQTT. Então você ainda precisa de um servidor, mas o MQTT é um protocolo padrão, então você só precisa configurar um broker, também não precisa de um banco de dados ou qualquer coisa é salva na memória do servidor (como na v1), então é completamente escalável.

kidandcat picture kidandcat em 26 jun. 2019
🎉3

Boas notícias! Eu acho que definitivamente vou mudar de v1 para v2. Vai tornar tudo muito mais fácil. Muito obrigado!

bilo1967 picture bilo1967 em 26 jun. 2019

Obrigado pela incrível biblioteca

shivarajnaidu picture shivarajnaidu em 26 jun. 2019
Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

senihtosun picture senihtosun  ·  5Comentários
fresheneesz picture fresheneesz  ·  10Comentários
jameshfisher picture jameshfisher  ·  5Comentários
lucastwong picture lucastwong  ·  3Comentários
maxpavlov picture maxpavlov  ·  6Comentários