Signalisatie is nauw verbonden met onze implementatie van sockets, die in het volgende gedeelte wordt beschreven.<\/li>\n<\/ul>\n\nDe lijst met servers binnen het spel en op de startpagina<\/i><\/p>\nImplementatie van sockets<\/h1>\n
\nWe willen een API cre\u00ebren die zo dicht mogelijk bij Posix UDP Sockets ligt, om het aantal noodzakelijke wijzigingen te minimaliseren.<\/p>\n
Daarnaast willen we het noodzakelijke minimum implementeren dat vereist is voor de eenvoudigste gegevensuitwisseling via het netwerk.<\/p>\n
Bijvoorbeeld, we hebben geen echte routering nodig: alle peers bevinden zich in \u00e9\u00e9n 'virtueel LAN', gekoppeld aan een specifieke instantie van de Firebase-database.<\/p>\n
Daarom hebben we geen unieke IP-adressen nodig: voor unieke identificatie van peers is het voldoende om unieke waarden van de Firebase-sleutels te gebruiken (vergelijkbaar met domeinnamen), en elke peer kent lokaal 'nep' IP-adressen toe aan elke sleutel die moet worden omgezet. Dit elimineert volledig de noodzaak voor globale toewijzing van IP-adressen, wat geen triviale taak is.<\/p>\n
Hier is de minimale API die we moeten implementeren:<\/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\nDe API is eenvoudig en lijkt op de API van Posix Sockets, maar heeft een aantal belangrijke verschillen: registratie van callback-functies, toewijzing van lokale IP's en 'lui' verbindingen<\/strong>.<\/p>\nRegistratie van callback-functies<\/h2>\n \nZelfs als de oorspronkelijke programma gebruik maakt van niet-blokkerende invoer\/uitvoer, moet de code worden gerefactoreerd voor gebruik in een webbrowser.<\/p>\n
De reden hiervoor is dat de event loop in de browser verborgen is voor het programma (of het nu JavaScript of WebAssembly is).<\/p>\n
In een native omgeving kunnen we de code op deze manier schrijven<\/p>\n
while(running) {\n select(...); \/\/ wacht op I\/O gebeurtenissen\n while(true) {\n int r = readfrom(...); \/\/ probeer te lezen\n if (r < 0 && errno == EWOULDBLOCK) \/\/ geen gegevens meer beschikbaar\n break;\n ...\n }\n ...\n}<\/code><\/pre>\n\nAls de event loop voor ons verborgen is, moeten we deze omzetten in iets dat hierop lijkt:<\/p>\n
auto cb = []() { \/\/ dit zal worden aangeroepen wanneer nieuwe gegevens beschikbaar zijn\n while(true) {\n int r = readfrom(...); \/\/ probeer te lezen\n if (r < 0 && errno == EWOULDBLOCK) \/\/ geen gegevens meer beschikbaar\n break;\n ...\n }\n ...\n};\nrecvCallback(cb); \/\/ registreer de callback<\/code><\/pre>\n<\/p>\n
Toepassing van lokale IP's<\/h2>\n \nDe knooppunten in ons 'netwerk' zijn geen IP-adressen, maar Firebase-sleutels (dit zijn strings die er als volgt uitzien: -LmEC50PYZLCiCP-vqde<\/code> ).<\/p>\nDit is handig omdat we geen mechanisme nodig hebben voor het toewijzen van IP's en de controle van hun uniciteit (en hun verwijdering na het uitschakelen van de klant), maar het is vaak nodig om peers te identificeren op basis van numerieke waarde.<\/p>\n
Daarom worden de functies resolve<\/code> en reverseResolve<\/code>: de applicatie krijgt op de een of andere manier de stringwaarde van de sleutel (door invoer van de gebruiker of via de master-server) en kan deze omzetten in een IP-adres voor intern gebruik. De rest van de API ontvangt ook deze waarde in plaats van de string voor de eenvoud.<\/p>\nDit lijkt op een DNS-zoekopdracht, alleen wordt deze lokaal bij de klant uitgevoerd.<\/p>\n
Dat betekent dat IP-adressen niet gedeeld kunnen worden tussen verschillende klanten, en als er een globale identifier nodig is, deze op een andere manier gegenereerd moet worden.<\/p>\n
Lui verbinding maken<\/h2>\n \nUDP vereist geen verbinding, maar zoals we eerder hebben gezien, vereist WebRTC een lang verbindingsproces voordat het dataverkeer tussen twee peers kan beginnen.<\/p>\n
Als we hetzelfde abstractieniveau willen garanderen, (sendto<\/code>\/recvfrom<\/code> met willekeurige peers zonder voorafgaande verbinding), dan moeten we 'lui' (uitgestelde) verbinding maken binnen de API.<\/p>\nDit is wat er gebeurt bij normale gegevensuitwisseling tussen een 'server' en 'client' bij gebruik van UDP, en wat onze bibliotheek zou moeten uitvoeren:<\/p>\n
\nDe server roept bind()<\/code>, om het besturingssysteem te informeren dat het pakketten op de opgegeven poort wil ontvangen.<\/li>\n<\/ul>\n\nIn plaats daarvan publiceren we een open poort in Firebase onder de serversleutel en luisteren we naar gebeurtenissen in zijn subtree.<\/p>\n
\nDe server roept recvfrom()<\/code>, waarmee we pakketten vanaf elke host naar deze poort accepteren.<\/li>\n<\/ul>\n\nIn ons geval moeten we de inkomende wachtrij van pakketten controleren die naar deze poort zijn gestuurd.<\/p>\n
Elke poort heeft zijn eigen wachtrij, en we voegen de oorspronkelijke en eindpoorten van de WebRTC-datagrammen aan het begin toe, zodat we weten in welke wachtrij een nieuw pakket moet worden omgeleid wanneer het binnenkomt.<\/p>\n
De aanroep is niet-blokkerend, dus als er geen pakketten zijn, retourneren we gewoon -1 en stellen we errno=EWOULDBLOCK<\/code>.<\/p>\n\nDe klant verkrijgt op een of andere externe manier het IP en de poort van de server en roept sendto()<\/code>. Ook wordt bij dit proces een interne aanroep gedaan, zodat de daaropvolgende bind()<\/code>een antwoord ontvangt zonder expliciet een bind uit te voeren. recvfrom()<\/code> ontvangen een antwoord zonder expliciete uitvoering van bind.<\/li>\n<\/ul>\n\nIn ons geval ontvangt de klant extern een string sleutel en gebruikt de functie resolve()<\/code> om het IP-adres te verkrijgen.<\/p>\nIn deze fase beginnen we met de \"handshake\" van WebRTC, als de twee peers nog niet met elkaar verbonden zijn. Verbindingen op verschillende poorten van \u00e9\u00e9n peer gebruiken dezelfde WebRTC DataChannel.<\/p>\n
Ook voeren we een indirecte bind()<\/code>, zodat de server de verbinding in de volgende sendto()<\/code> kan herstellen, indien deze om welke reden dan ook is verbroken.<\/p>\nDe server wordt op de hoogte gesteld van de verbinding van de klant wanneer de klant zijn SDP-aanbod onder de serverpoortinformatie in Firebase opslaat, en de server daar ook op reageert met zijn antwoord.<\/p>\n
\nIn de onderstaande afbeelding wordt een voorbeeld van de berichtbewegingen voor de socketschema en de overdracht van het eerste bericht van de klant naar de server weergegeven:<\/p>\n
Het volledige schema van de verbindingsfase tussen de klant en de server<\/i><\/p>\nConclusie<\/h1>\n
\nAls je tot het einde hebt gelezen, ben je waarschijnlijk benieuwd om de theorie in actie te zien. Je kunt het spel spelen op teeworlds.leaningtech.com<\/a><\/noindex>, probeer het eens!<\/p>\n