Peerjs: post-connexion

Créé le 25 juin 2019 · 7Commentaires · Source: peers/peerjs

Tout d'abord : ma connaissance de la chronologie des événements en javascript est médiocre, veuillez donc accepter mes excuses si ce que je demande semble évident (et désolé si je vous bombarde de questions).

Lorsqu'un pair A gère la connexion d'un autre pair B via DataConnection.on('connection', function() {...}) , cette connexion est-elle prête à l'intérieur du gestionnaire ou devient-elle complètement disponible après le retour du gestionnaire d'événements ? Je veux dire : A peut-il envoyer un message de données à B comme dans ce code ?

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

Dans le cas où ce n'est pas possible, ne serait-il pas bon d'avoir un événement 'afterconnection' pour gérer ces cas ? Ou peut-être que le code suivant devrait fonctionner ?

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

Merci.

Source

bilo1967

Commentaire le plus utile

Sera-t-il possible de distinguer qui se connecte à l'aide d'une fonctionnalité de métadonnées comme dans la v1 ?

Oui! Je viens d'ajouter cette fonctionnalité au plan, elle devrait être très facile à mettre en œuvre

Pourrai-je accéder à des flux distants et locaux pour effectuer un traitement audio (local) via AudioContext ? Dans mon projet, j'ai un pair A qui a besoin d'entendre la poire B dans le canal L et C dans le canal R de son casque, et de changer indépendamment le volume de chacun d'eux ; et B et C ont besoin d'un vu-mètre connecté à leur micro pour surveiller en permanence s'il fonctionne correctement (j'ai déjà implémenté ces fonctionnalités en partie et je dois les conserver).

Vous avez déjà accès aux flux sur les gestionnaires. Ce n'est pas bien documenté, mais comme vous l'avez dit, vous recevez un flux distant par pair, et votre propre flux distant une fois, qui est réutilisé pour toutes les connexions en ce moment, qui peut être modifié à l'avenir si nécessaire.

Voulez-vous dire traiter les flux avant de les envoyer ? si c'est le cas, il peut également être mis en œuvre.

Je n'ai pas testé le canal de données mais je suppose que c'est la même chose que le canal multimédia : une connexion 1-1 entre chaque pair avec onDataStream déclenché à chaque connexion ? Et les messages seront envoyés individuellement à chaque pair ?

Oui, vous recevez les dataChannels bruts, un par pair connecté. Cela fonctionnera bien aussi avec la fonctionnalité de métadonnées mentionnée ci-dessus.

Ravi d'entendre qu'un serveur pair ne sera pas nécessaire. Cependant, à quoi sert ce wss://broker.peerjs.com ?

PeerJS a besoin d'un canal pour effectuer la signalisation initiale. Mais maintenant, au lieu d'utiliser un PeerServer, toute la logique est faite par la bibliothèque PeerJS elle-même, et elle n'a besoin que d'un courtier MQTT. Vous avez donc toujours besoin d'un serveur, mais MQTT est un protocole standard, il vous suffit donc de configurer un courtier, il n'a pas non plus besoin d'une base de données ou quoi que ce soit est enregistré dans la mémoire du serveur (comme dans la v1), il est donc complètement évolutif.

kidandcat le 26 juin 2019

🎉3

Tous les 7 commentaires

Il est prêt à être utilisé dans le gestionnaire. Je ne trouve pas très utile un événement "démarrer la connexion". Dans quel cas le trouvez-vous utile ?

kidandcat le 25 juin 2019

Dans le projet que je développe, un problème consiste à éviter les connexions indésirables.

Il y a trois rôles : étudiant, intervenant, enseignant (j'ai ajouté un indicateur de métadonnées indiquant le rôle dans le tableau d'options lors de l'enregistrement du pair). L'enseignant se connecte au serveur avec son identifiant, qui est connu, et attend l'orateur et l'élève. Une fois qu'ils sont tous connectés, d'autres connexions doivent être évitées.
Le rejet que vous avez implémenté dans la v2.0.0 devrait faire l'affaire mais il me semble que les changements dans l'API sont assez radicaux.

bilo1967 le 26 juin 2019

Oui, la nouvelle version est majoritaire (rupture, pas de rétrocompatibilité). L'ancienne API est assez déroutante, et le code a beaucoup d'astuces héritées de ses premiers jours en 2013, il est très difficile à maintenir.

Mais comme il s'agit d'un changement de rupture, je continuerai à prendre en charge l'ancienne version, donc j'implémenterai un moyen de rejet dans la v1. Quoi qu'il en soit, je vous recommande de passer à la v2 si vous n'avez pas besoin de prendre en charge de très anciens navigateurs. Vous gagnerez en stabilité et vous n'aurez pas besoin d'héberger un PeerServer.

Le rejet dans la v2 n'est pas encore terminé, mais je me concentre sur le développement de la v2, donc cette fonctionnalité sera bientôt prête.

kidandcat le 26 juin 2019

J'ai jeté un coup d'œil à l'exemple que vous avez fourni pour la v2 et il a l'air vraiment impressionnant : une simple conversation en tête-à-tête en quelques lignes de code ! De plus, j'ai un peu modifié ce code et j'ai vu que onRemoteStream est déclenché sur chaque pair chaque fois que quelqu'un rejoint la salle, ce qui permet de gérer toutes les connexions multimédias que votre bande passante peut prendre en charge : wow !!!

Juste quelques questions :

Sera-t-il possible de distinguer qui se connecte à l'aide d'une fonctionnalité de métadonnées comme dans la v1 ?
Pourrai-je accéder à des flux distants et locaux pour effectuer un traitement audio (local) via AudioContext ? Dans mon projet, j'ai un pair A qui a besoin d'entendre la poire B dans le canal L et C dans le canal R de son casque, et de changer indépendamment le volume de chacun d'eux ; et B et C ont besoin d'un vu-mètre connecté à leur micro pour surveiller en permanence s'il fonctionne correctement (j'ai déjà implémenté ces fonctionnalités en partie et je dois les conserver).
Je n'ai pas testé le canal de données mais je suppose que c'est la même chose que le canal multimédia : une connexion 1-1 entre chaque pair avec onDataStream déclenché à chaque connexion ? Et les messages seront envoyés individuellement à chaque pair ?
Ravi d'entendre qu'un serveur pair ne sera pas nécessaire. Cependant, à quoi sert ce wss://broker.peerjs.com ?

PS J'ai vu que vous aviez mis à jour la planification de la feuille de route pour ajouter un nombre maximum de pairs par salle et c'est quelque chose dont j'ai vraiment besoin !

bilo1967 le 26 juin 2019

Sera-t-il possible de distinguer qui se connecte à l'aide d'une fonctionnalité de métadonnées comme dans la v1 ?

Oui! Je viens d'ajouter cette fonctionnalité au plan, elle devrait être très facile à mettre en œuvre

Pourrai-je accéder à des flux distants et locaux pour effectuer un traitement audio (local) via AudioContext ? Dans mon projet, j'ai un pair A qui a besoin d'entendre la poire B dans le canal L et C dans le canal R de son casque, et de changer indépendamment le volume de chacun d'eux ; et B et C ont besoin d'un vu-mètre connecté à leur micro pour surveiller en permanence s'il fonctionne correctement (j'ai déjà implémenté ces fonctionnalités en partie et je dois les conserver).

Voulez-vous dire traiter les flux avant de les envoyer ? si c'est le cas, il peut également être mis en œuvre.

Je n'ai pas testé le canal de données mais je suppose que c'est la même chose que le canal multimédia : une connexion 1-1 entre chaque pair avec onDataStream déclenché à chaque connexion ? Et les messages seront envoyés individuellement à chaque pair ?

Oui, vous recevez les dataChannels bruts, un par pair connecté. Cela fonctionnera bien aussi avec la fonctionnalité de métadonnées mentionnée ci-dessus.