Peerjs: nach Anschluss

Erstellt am 25. Juni 2019  ·  7Kommentare  ·  Quelle: peers/peerjs

Zuallererst: Mein Wissen über das Timing von Ereignissen in Javascript ist schlecht, also akzeptieren Sie bitte meine Entschuldigung, wenn meine Frage offensichtlich erscheint (und entschuldigen Sie, wenn ich Sie mit Fragen bombardiere).

Wenn ein Peer A die Verbindung eines anderen Peers B über DataConnection.on('connection', function() {...}) handhabt, ist diese Verbindung im Handler bereit oder wird sie vollständig verfügbar, nachdem der Event-Handler zurückkehrt? Ich meine: Darf A wie in diesem Code eine Datennachricht an B senden?

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

Falls dies nicht möglich ist, wäre es nicht gut, ein "Afterconnection"-Ereignis zu haben, um diese Fälle zu behandeln? Oder vielleicht soll der folgende Code funktionieren?

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

Danke.

picture bilo1967

Hilfreichster Kommentar

  1. Wird es möglich sein, anhand einer Metadatenfunktion wie in v1 zu unterscheiden, wer sich verbindet?

Jawohl! Ich habe diese Funktion gerade dem Plan hinzugefügt, sie sollte sehr einfach zu implementieren sein

  1. Kann ich auf entfernte und lokale Streams zugreifen, um eine (lokale) Audioverarbeitung über AudioContext durchzuführen? In meinem Projekt habe ich Peer A, der Birne B im L-Kanal und C im R-Kanal seines Headsets hören und die Lautstärke von jedem von ihnen unabhängig ändern muss; und sowohl B als auch C benötigen ein Vu-Meter, das an ihr Mikrofon angeschlossen ist, um kontinuierlich zu überwachen, ob es ordnungsgemäß funktioniert (ich habe diese Funktionen bereits teilweise implementiert und muss sie behalten).

Sie haben bereits Zugriff auf die Streams auf den Handlern. Es ist nicht gut dokumentiert, aber wie Sie sagten, erhalten Sie einen Remote-Stream pro Peer und einmal Ihren eigenen Remote-Stream, der derzeit für alle Verbindungen wiederverwendet wird und bei Bedarf in Zukunft geändert werden kann.

Wollen Sie die Streams verarbeiten, bevor Sie sie senden? Wenn ja, kann es auch implementiert werden.

  1. Ich habe den Datenkanal nicht getestet, aber ich denke, es ist dasselbe wie der Medienkanal: eine 1-1-Verbindung zwischen jedem Peer, wobei onDataStream bei jeder Verbindung ausgelöst wird? Und Nachrichten werden einzeln an jeden Peer gesendet?

Ja, Sie erhalten die Rohdatenkanäle, einen pro verbundenem Peer. Es funktioniert auch gut mit der oben erwähnten Metadatenfunktion.

  1. Schön zu hören, dass kein Peer-Server benötigt wird. Aber wofür ist wss://broker.peerjs.com ?

PeerJS benötigt einen Kanal für die anfängliche Signalisierung. Aber anstatt einen PeerServer zu verwenden, wird die gesamte Logik von der PeerJS-Bibliothek selbst erstellt und benötigt nur einen MQTT-Broker. Sie brauchen also immer noch einen Server, aber MQTT ist ein Standardprotokoll, also müssen Sie nur einen Broker einrichten, es braucht auch keine Datenbank oder irgendetwas wird im Serverspeicher gespeichert (wie in v1), so dass es vollständig skalierbar ist.

picture kidandcat am 26. Juni 2019
🎉3

Alle 7 Kommentare

Es ist einsatzbereit im Handler. Ich finde ein "start conneting"-Ereignis nicht sehr nützlich. In welchem ​​Fall finden Sie es nützlich?

kidandcat picture kidandcat am 25. Juni 2019

In dem Projekt, das ich entwickle, besteht ein Problem darin, unerwünschte Verbindungen zu vermeiden.

Es gibt drei Rollen: Schüler, Sprecher, Lehrer (ich habe ein Metadaten-Flag hinzugefügt, das die Rolle im Options-Array angibt, wenn der Peer registriert wird). Der Lehrer verbindet sich mit seiner bekannten ID mit dem Server und wartet auf den Sprecher und den Schüler. Sobald sie alle verbunden sind, müssen weitere Verbindungen vermieden werden.
Die Ablehnung, die Sie in v2.0.0 implementiert haben, sollte den Job erledigen, aber es scheint mir, dass die Änderungen in der API ziemlich radikal sind.

bilo1967 picture bilo1967 am 26. Juni 2019

Ja, die neue Version ist eine größere (kaputt, keine Abwärtskompatibilität). Die alte API ist ziemlich verwirrend, und der Code hat viele Legacy-Tricks aus den ersten Tagen im Jahr 2013, es ist sehr schwer zu warten.

Da es sich jedoch um eine bahnbrechende Änderung handelt, werde ich die alte Version weiterhin unterstützen, also werde ich eine Art der Ablehnung in v1 implementieren. Wie auch immer, ich empfehle Ihnen, auf v2 umzusteigen, wenn Sie keine sehr alten Browser unterstützen müssen. Sie gewinnen an Stabilität und müssen keinen PeerServer hosten.

Die Ablehnung in v2 ist noch nicht abgeschlossen, aber ich konzentriere mich auf die Entwicklung von v2, sodass diese Funktion bald fertig sein wird.

kidandcat picture kidandcat am 26. Juni 2019

Ich habe mir das Beispiel angesehen, das Sie für v2 bereitgestellt haben, und es sieht wirklich beeindruckend aus: ein einfacher Eins-zu-Eins-Chat in wenigen Codezeilen! Außerdem habe ich diesen Code ein wenig optimiert und gesehen, dass onRemoteStream auf jedem Peer ausgelöst wird, wenn jemand den Raum betritt, wodurch es möglich wird, alle Medienverbindungen zu handhaben, die Ihre Bandbreite möglicherweise unterstützt: wow!!!

Nur ein paar Fragen:

  1. Wird es möglich sein, anhand einer Metadatenfunktion wie in v1 zu unterscheiden, wer sich verbindet?
  2. Kann ich auf entfernte und lokale Streams zugreifen, um eine (lokale) Audioverarbeitung über AudioContext durchzuführen? In meinem Projekt habe ich Peer A, der Birne B im L-Kanal und C im R-Kanal seines Headsets hören und die Lautstärke von jedem von ihnen unabhängig ändern muss; und sowohl B als auch C benötigen ein Vu-Meter, das an ihr Mikrofon angeschlossen ist, um kontinuierlich zu überwachen, ob es ordnungsgemäß funktioniert (ich habe diese Funktionen bereits teilweise implementiert und muss sie behalten).
  3. Ich habe den Datenkanal nicht getestet, aber ich denke, es ist dasselbe wie der Medienkanal: eine 1-1-Verbindung zwischen jedem Peer, wobei onDataStream bei jeder Verbindung ausgelöst wird? Und Nachrichten werden einzeln an jeden Peer gesendet?
  4. Schön zu hören, dass kein Peer-Server benötigt wird. Aber wofür ist wss://broker.peerjs.com ?

PS Ich habe gesehen, dass Sie die Roadmap-Planung aktualisiert haben, um eine maximale Anzahl von Peers pro Raum hinzuzufügen, und das ist etwas, was ich wirklich brauche!

bilo1967 picture bilo1967 am 26. Juni 2019
  1. Wird es möglich sein, anhand einer Metadatenfunktion wie in v1 zu unterscheiden, wer sich verbindet?

Jawohl! Ich habe diese Funktion gerade dem Plan hinzugefügt, sie sollte sehr einfach zu implementieren sein

  1. Kann ich auf entfernte und lokale Streams zugreifen, um eine (lokale) Audioverarbeitung über AudioContext durchzuführen? In meinem Projekt habe ich Peer A, der Birne B im L-Kanal und C im R-Kanal seines Headsets hören und die Lautstärke von jedem von ihnen unabhängig ändern muss; und sowohl B als auch C benötigen ein Vu-Meter, das an ihr Mikrofon angeschlossen ist, um kontinuierlich zu überwachen, ob es ordnungsgemäß funktioniert (ich habe diese Funktionen bereits teilweise implementiert und muss sie behalten).

Sie haben bereits Zugriff auf die Streams auf den Handlern. Es ist nicht gut dokumentiert, aber wie Sie sagten, erhalten Sie einen Remote-Stream pro Peer und einmal Ihren eigenen Remote-Stream, der derzeit für alle Verbindungen wiederverwendet wird und bei Bedarf in Zukunft geändert werden kann.

Wollen Sie die Streams verarbeiten, bevor Sie sie senden? Wenn ja, kann es auch implementiert werden.

  1. Ich habe den Datenkanal nicht getestet, aber ich denke, es ist dasselbe wie der Medienkanal: eine 1-1-Verbindung zwischen jedem Peer, wobei onDataStream bei jeder Verbindung ausgelöst wird? Und Nachrichten werden einzeln an jeden Peer gesendet?

Ja, Sie erhalten die Rohdatenkanäle, einen pro verbundenem Peer. Es funktioniert auch gut mit der oben erwähnten Metadatenfunktion.

  1. Schön zu hören, dass kein Peer-Server benötigt wird. Aber wofür ist wss://broker.peerjs.com ?

PeerJS benötigt einen Kanal für die anfängliche Signalisierung. Aber anstatt einen PeerServer zu verwenden, wird die gesamte Logik von der PeerJS-Bibliothek selbst erstellt und benötigt nur einen MQTT-Broker. Sie brauchen also immer noch einen Server, aber MQTT ist ein Standardprotokoll, also müssen Sie nur einen Broker einrichten, es braucht auch keine Datenbank oder irgendetwas wird im Serverspeicher gespeichert (wie in v1), so dass es vollständig skalierbar ist.

kidandcat picture kidandcat am 26. Juni 2019
🎉3

Großartige Neuigkeiten! Ich denke, ich werde auf jeden Fall von v1 auf v2 wechseln. Es wird alles viel einfacher machen. Danke sehr!

bilo1967 picture bilo1967 am 26. Juni 2019

Danke für die tolle Bibliothek

shivarajnaidu picture shivarajnaidu am 26. Juni 2019
War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

jameshfisher picture jameshfisher  ·  6Kommentare
kidandcat picture kidandcat  ·  8Kommentare
nick0702y picture nick0702y  ·  9Kommentare
afrokick picture afrokick  ·  5Kommentare
furozen picture furozen  ·  9Kommentare