Die Signalgebung ist eng mit unserer Implementierung der Sockets verbunden, die im folgenden Abschnitt beschrieben wird.<\/li>\n<\/ul>\n\nListe der Server im Spiel und auf der Startseite<\/i><\/p>\nImplementierung der Sockets<\/h1>\n
\nWir m\u00f6chten eine API erstellen, die so nah wie m\u00f6glich an Posix UDP Sockets herankommt, um die Anzahl der erforderlichen \u00c4nderungen zu minimieren.<\/p>\n
Au\u00dferdem m\u00f6chten wir das notwendige Minimum implementieren, das f\u00fcr den einfachsten Datenaustausch \u00fcber das Netzwerk erforderlich ist.<\/p>\n
Zum Beispiel ben\u00f6tigen wir keine echte Routing-Funktion: Alle Peers befinden sich in einem \"virtuellen LAN\", das mit einer bestimmten Instanz der Firebase-Datenbank verbunden ist.<\/p>\n
Folglich ben\u00f6tigen wir keine eindeutigen IP-Adressen: Zur eindeutigen Identifizierung der Peers gen\u00fcgt es, eindeutige Werte der Firebase-Schl\u00fcssel (\u00e4hnlich wie bei Domainnamen) zu verwenden, und jeder Peer weist lokal jedem Schl\u00fcssel, der umgewandelt werden muss, \"falsche\" IP-Adressen zu. Das befreit uns vollst\u00e4ndig von der Notwendigkeit einer globalen IP-Adresszuweisung, was eine nicht triviale Aufgabe ist.<\/p>\n
Hier ist die minimale API, die wir umsetzen m\u00fcssen:<\/p>\n
\/\/ Create and destroy a socket\nint socket();\nint close(int fd);\n\/\/ Bind a socket to a port, and publish it on Firebase\nint bind(int fd, AddrInfo* addr);\n\/\/ Send a packet. This lazily create a WebRTC connection to the \n\/\/ peer when necessary\nint sendto(int fd, uint8_t* buf, int len, const AddrInfo* addr);\n\/\/ Receive the packets destined to this socket\nint recvfrom(int fd, uint8_t* buf, int len, AddrInfo* addr);\n\/\/ Be notified when new packets arrived\nint recvCallback(Callback cb);\n\/\/ Obtain a local ip address for this peer key\nuint32_t resolve(client::String* key);\n\/\/ Get the peer key for this ip\nString* reverseResolve(uint32_t addr);\n\/\/ Get the local peer key\nString* local_key();\n\/\/ Initialize the library with the given Firebase database and \n\/\/ WebRTc connection options\nvoid init(client::FirebaseConfig* fb, client::RTCConfiguration* ice);<\/code><\/pre>\n\nDie API ist einfach und \u00e4hnelt der API von Posix Sockets, hat jedoch einige wichtige Unterschiede: Callback-Registrierung, Zuordnung lokaler IPs und \"lazy\" Verbindung<\/strong>.<\/p>\nCallback-Registrierung<\/h2>\n \nSelbst wenn das urspr\u00fcngliche Programm nicht blockierendes I\/O verwendet, muss der Code zum Ausf\u00fchren im Webbrowser umstrukturiert werden.<\/p>\n
Der Grund daf\u00fcr ist, dass die Ereignisschleife im Browser vor dem Programm verborgen ist (egal ob JavaScript oder WebAssembly).<\/p>\n
In einer nativen Umgebung k\u00f6nnen wir den Code so schreiben<\/p>\n
while(running) {\n select(...); \/\/ auf I\/O-Ereignisse warten\n while(true) {\n int r = readfrom(...); \/\/ versuchen zu lesen\n if (r < 0 && errno == EWOULDBLOCK) \/\/ keine weiteren Daten verf\u00fcgbar\n break;\n ...\n }\n ...\n}<\/code><\/pre>\n\nWenn die Ereignisschleife f\u00fcr uns verborgen ist, muss sie in etwas \u00c4hnliches umgewandelt werden:<\/p>\n
auto cb = []() { \/\/ dies wird aufgerufen, wenn neue Daten verf\u00fcgbar sind\n while(true) {\n int r = readfrom(...); \/\/ versuchen zu lesen\n if (r < 0 && errno == EWOULDBLOCK) \/\/ keine weiteren Daten verf\u00fcgbar\n break;\n ...\n }\n ...\n};\nrecvCallback(cb); \/\/ Callback registrieren<\/code><\/pre>\n<\/p>\n
Zuordnung lokaler IPs<\/h2>\n \nDie Identifikatoren der Knoten in unserem \u201eNetz\u201c sind keine IP-Adressen, sondern Firebase-Schl\u00fcssel (das sind Zeichenfolgen, die so aussehen: -LmEC50PYZLCiCP-vqde<\/code> ).<\/p>\nDas ist praktisch, da wir keinen Mechanismus zur Zuweisung von IPs und zur \u00dcberpr\u00fcfung ihrer Einzigartigkeit ben\u00f6tigen (sowie deren Entsorgung nach der Abmeldung eines Clients), es jedoch oft notwendig ist, Peers durch numerische Werte zu identifizieren.<\/p>\n
Genau dazu werden die Funktionen resolve<\/code> und reverseResolve<\/code>: Die Anwendung erh\u00e4lt auf irgendeine Weise den Schl\u00fcsselwert als Zeichenfolge (durch Benutzereingabe oder \u00fcber einen Master-Server) und kann ihn in eine IP-Adresse f\u00fcr interne Zwecke umwandeln. Der Rest der API erh\u00e4lt auch aus Gr\u00fcnden der Vereinfachung anstelle der Zeichenfolge diesen Wert.<\/p>\nDas \u00e4hnelt einer DNS-Abfrage, wird jedoch lokal beim Client durchgef\u00fchrt.<\/p>\n
Das bedeutet, dass IP-Adressen nicht f\u00fcr verschiedene Clients gemeinsam sein k\u00f6nnen, und wenn ein globaler Identifikator ben\u00f6tigt wird, muss dieser auf andere Weise generiert werden.<\/p>\n
Laid-Back-Verbindung<\/h2>\n \nUDP ben\u00f6tigt keine Verbindung, jedoch erfordert WebRTC, wie wir gesehen haben, einen langen Verbindungsprozess, bevor Daten zwischen zwei Peers \u00fcbertragen werden k\u00f6nnen.<\/p>\n
Wenn wir das gleiche Abstraktionsniveau gew\u00e4hrleisten wollen, (sendto<\/code>\/recvfrom<\/code> mit beliebigen Peers ohne vorherige Verbindung), m\u00fcssen wir eine \u201elaissez-faire\u201c (verz\u00f6gerte) Verbindung innerhalb der API herstellen.<\/p>\nSo funktioniert der normale Datenaustausch zwischen einem \u201eServer\u201c und einem \u201eClient\u201c im Fall von UDP, und das ist, was unsere Bibliothek tun sollte:<\/p>\n
\nDer Server ruft bind()<\/code>, um dem Betriebssystem mitzuteilen, dass er Pakete an den angegebenen Port empfangen m\u00f6chte.<\/li>\n<\/ul>\n\nStattdessen ver\u00f6ffentlichen wir einen offenen Port in Firebase unter dem Schl\u00fcssel des Servers und h\u00f6ren Ereignisse in seinem Unterbaum.<\/p>\n
\nDer Server ruft recvfrom()<\/code>, um Pakete an diesem Port von jedem Host zu empfangen.<\/li>\n<\/ul>\n\nIn unserem Fall m\u00fcssen wir die eingehende Warteschlange der Pakete \u00fcberpr\u00fcfen, die an diesen Port gesendet werden.<\/p>\n
Jeder Port hat seine eigene Warteschlange, und wir f\u00fcgen den WebRTC-Datagrammen am Anfang die Quell- und Zielports hinzu, um zu wissen, in welche Warteschlange ein neues Paket weitergeleitet werden soll, wenn es eintrifft.<\/p>\n
Der Aufruf ist nicht blockierend, daher geben wir, wenn keine Pakete vorhanden sind, einfach -1 zur\u00fcck und setzen errno=EWOULDBLOCK<\/code>.<\/p>\n\nDer Client erh\u00e4lt durch externe Mittel die IP und den Port des Servers und ruft sendto()<\/code>. Gleichzeitig erfolgt ein interner Aufruf bind()<\/code>, sodass der folgende recvfrom()<\/code> eine Antwort erh\u00e4lt, ohne explizit bind auszuf\u00fchren.<\/li>\n<\/ul>\n\nIn unserem Fall erh\u00e4lt der Kunde extern einen String-Schl\u00fcssel und verwendet die Funktion resolve()<\/code> um die IP-Adresse zu erhalten.<\/p>\nAn diesem Punkt beginnen wir das \u201eHandschlag\u201c von WebRTC, falls zwei Peers noch nicht miteinander verbunden sind. Verbindungen zu verschiedenen Ports eines Peers verwenden denselben WebRTC DataChannel.<\/p>\n
Au\u00dferdem f\u00fchren wir eine indirekte bind()<\/code>aus, damit der Server die Verbindung im n\u00e4chsten sendto()<\/code> Weltfall wiederherstellen kann, falls sie aus irgendeinem Grund geschlossen wurde.<\/p>\nDer Server wird \u00fcber die Verbindung des Clients informiert, wenn der Client sein SDP-Angebot unter der Portinformation des Servers in Firebase speichert, und der Server dort mit seiner R\u00fcckmeldung antwortet.<\/p>\n
\nDas folgende Diagramm zeigt ein Beispiel f\u00fcr den Nachrichtenaustausch im Socket-Schema und die \u00dcbertragung der ersten Nachricht vom Client an den Server:<\/p>\n
Das vollst\u00e4ndige Schema des Verbindungsprozesses zwischen Client und Server<\/i><\/p>\nFazit<\/h1>\n
\nWenn Sie bis hierher gelesen haben, sind Sie wahrscheinlich daran interessiert, die Theorie in der Praxis zu sehen. Sie k\u00f6nnen das Spiel auf teeworlds.leaningtech.com<\/a><\/noindex>, versuchen Sie es!<\/p>\n