Die Signalgebung steht in engem Zusammenhang mit unserer Socket-Implementierung, die im n\u00e4chsten Abschnitt beschrieben wird.<\/li>\n<\/ul>\n\nDie Serverliste innerhalb des Spiels und auf der Startseite<\/i><\/p>\nImplementierung von Sockets<\/h1>\n
\nWir m\u00f6chten eine API erstellen, die so nah wie m\u00f6glich an Posix UDP Sockets ist, um die erforderlichen \u00c4nderungen auf ein Minimum zu reduzieren.<\/p>\n
Wir m\u00f6chten auch das notwendige Minimum umsetzen, das f\u00fcr einen einfachen 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
Daher ben\u00f6tigen wir keine einzigartigen IP-Adressen: F\u00fcr die eindeutige Identifikation von Peers gen\u00fcgt es, einzigartige Firebase-Schl\u00fcsselwerte zu verwenden (\u00e4hnlich wie bei Domainnamen). Jeder Peer weist lokal \"falsche\" IP-Adressen jedem Schl\u00fcssel zu, die dann umgewandelt werden m\u00fcssen. Dies befreit uns vollst\u00e4ndig von der Notwendigkeit, IP-Adressen global zuzuweisen, was eine nicht triviale Aufgabe darstellt.<\/p>\n
Hier ist die minimale API, die wir implementieren 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 der Posix-Sockets, hat jedoch einige wichtige Unterschiede: Registrierung von R\u00fcckrufen, Zuweisung lokaler IPs und \"lazy\" Verbindungen<\/strong>.<\/p>\nRegistrierung von R\u00fcckrufen<\/h2>\n \nSelbst wenn das urspr\u00fcngliche Programm nicht blockierenden I\/O verwendet, muss der Code f\u00fcr die Ausf\u00fchrung im Webbrowser refaktoriert werden.<\/p>\n
Der Grund daf\u00fcr ist, dass die Ereignisschleife im Browser der Anwendung verborgen ist (ob es sich nun um JavaScript oder WebAssembly handelt).<\/p>\n
In einer nativen Umgebung k\u00f6nnen wir Code so schreiben<\/p>\n
while(running) {\n select(...); \/\/ warte auf I\/O-Events\n while(true) {\n int r = readfrom(...); \/\/ versuche zu lesen\n if (r < 0 && errno == EWOULDBLOCK) \/\/ keine weiteren Daten verf\u00fcgbar\n break;\n ...\n }\n ...\n}<\/code><\/pre>\n\nWenn uns die Ereignisschleife verborgen bleibt, m\u00fcssen wir sie in etwas \u00c4hnliches umwandeln:<\/p>\n
auto cb = []() { \/\/ dies wird aufgerufen, wenn neue Daten verf\u00fcgbar sind\n while(true) {\n int r = readfrom(...); \/\/ versuche 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
Zuweisung lokaler IPs<\/h2>\n \nDie Identifikatoren der Knoten in unserem \"Netzwerk\" sind keine IP-Adressen, sondern Firebase-Schl\u00fcssel (das sind Strings, die so aussehen: -LmEC50PYZLCiCP-vqde<\/code> ).<\/p>\nDas ist praktisch, da wir keinen Mechanismus zur Zuweisung von IPs und zur \u00dcberpr\u00fcfung ihrer Eindeutigkeit ben\u00f6tigen (sowie deren Nutzung nach der Trennung des Clients), aber oft ist es notwendig, Peers durch einen numerischen Wert zu identifizieren.<\/p>\n
Genau daf\u00fcr werden die Funktionen verwendet resolve<\/code> und reverseResolve<\/code>: die Anwendung erh\u00e4lt auf irgendeine Weise den Stringwert des Schl\u00fcssels (durch Benutzereingabe oder \u00fcber den Master-Server) und kann ihn in eine IP-Adresse f\u00fcr interne Zwecke umwandeln. Der Rest der API erh\u00e4lt ebenfalls der Einfachheit halber anstelle des Strings diesen Wert.<\/p>\nDas ist \u00e4hnlich wie eine DNS-Anfrage, die jedoch lokal beim Client ausgef\u00fchrt wird.<\/p>\n
Das hei\u00dft, IP-Adressen k\u00f6nnen nicht f\u00fcr verschiedene Clients gemeinsam sein, und wenn eine globale Kennung erforderlich ist, muss diese auf andere Weise generiert werden.<\/p>\n
Faules Verbindung<\/h2>\n \nUDP ben\u00f6tigt keine Verbindung, aber wie wir gesehen haben, erfordert WebRTC einen umfangreichen Verbindungsprozess, bevor Daten zwischen zwei Peers \u00fcbertragen werden k\u00f6nnen.<\/p>\n
Wenn wir dasselbe Abstraktionsniveau gew\u00e4hrleisten wollen, (sendto<\/code>\/recvfrom<\/code> mit beliebigen Peers ohne vorherige Verbindung), m\u00fcssen wir eine \u201elazy\u201c (verz\u00f6gerte) Verbindung innerhalb der API ausf\u00fchren.<\/p>\nDas passiert beim normalen Datenaustausch zwischen \u201eServer\u201c und \u201eClient\u201c, wenn UDP verwendet wird, und was unsere Bibliothek tun sollte:<\/p>\n
\nDer Server ruft bind()<\/code>auf, um dem Betriebssystem mitzuteilen, dass er Pakete am 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 lauschen Ereignissen in seinem untergeordneten Baum.<\/p>\n
\nDer Server ruft recvfrom()<\/code>, um Pakete zu empfangen, die von jedem Host an diesen Port gesendet werden.<\/li>\n<\/ul>\n\nIn unserem Fall m\u00fcssen wir die Eingangsqueue der Pakete \u00fcberpr\u00fcfen, die an diesen Port gesendet wurden.<\/p>\n
Jeder Port hat seine eigene Warteschlange, und wir f\u00fcgen den WebRTC-Datagrammen die Quell- und Zielports am Anfang hinzu, um zu wissen, in welche Warteschlange ein neues Paket umgeleitet werden soll.<\/p>\n
Der Aufruf ist nicht blockierend, daher geben wir einfach -1 zur\u00fcck, wenn keine Pakete vorhanden sind, und setzen fort. errno=EWOULDBLOCK<\/code>.<\/p>\n\nDer Client erh\u00e4lt \u00fcber externe Mittel die IP-Adresse und den Port des Servers und ruft auf sendto()<\/code>. Gleichzeitig erfolgt ein interner Aufruf bind()<\/code>, daher erh\u00e4lt der folgende recvfrom()<\/code> eine Antwort, ohne dass ein bind ausgef\u00fchrt werden muss.<\/li>\n<\/ul>\n\nIn unserem Fall erh\u00e4lt der Client extern einen String-Schl\u00fcssel und verwendet die Funktion resolve()<\/code> zur Ermittlung der IP-Adresse.<\/p>\nAn dieser Stelle beginnen wir das \u201eHandschlag\u201c-Verfahren von WebRTC, wenn die beiden Peers noch nicht miteinander verbunden sind. Verbindungen zu unterschiedlichen Ports eines Peers verwenden denselben WebRTC DataChannel.<\/p>\n
Au\u00dferdem f\u00fchren wir einen indirekten bind()<\/code>, damit der Server die Verbindung im n\u00e4chsten sendto()<\/code> wiederherstellen kann, falls diese aus irgendeinem Grund geschlossen wurde.<\/p>\nDer Server wird \u00fcber die Verbindung des Clients informiert, wenn der Client sein SDP-Angebot mit den Informationen zum Serverport in Firebase aufzeichnet und der Server darauf mit seiner Antwort reagiert.<\/p>\n
\nIn der unten gezeigten Abbildung ist ein Beispiel f\u00fcr den Nachrichtenaustausch im Socket-Schema und die \u00dcbertragung der ersten Nachricht vom Client zum Server dargestellt:<\/p>\n
Das vollst\u00e4ndige Schema des Verbindungsaufbaus zwischen Client und Server.<\/i><\/p>\nFazit<\/h1>\n
\nWenn Sie bis hierher gelesen haben, sind Sie wahrscheinlich interessiert, die Theorie in der Praxis zu sehen. Sie k\u00f6nnen auf teeworlds.leaningtech.com<\/a><\/noindex>, versuchen Sie es!<\/p>\n