Signalisering er n\u00e6rt relateret til vores implementering af sockets, som beskrives i n\u00e6ste afsnit.<\/li>\n<\/ul>\n\nServerliste indeni spillet og p\u00e5 startsiden<\/i><\/p>\nImplementering af sockets<\/h1>\n
\nVi \u00f8nsker at skabe et API, der er s\u00e5 t\u00e6t p\u00e5 Posix UDP Sockets som muligt for at minimere antallet af n\u00f8dvendige \u00e6ndringer.<\/p>\n
Vi \u00f8nsker ogs\u00e5 at implementere det n\u00f8dvendige minimum for den enkleste dataudveksling over netv\u00e6rket.<\/p>\n
For eksempel har vi ikke brug for \u00e6gte routings: alle peers befinder sig i et 'virtuel LAN', der er forbundet til et specifikt Firebase-database-eksperiment.<\/p>\n
Derfor har vi ikke brug for unikke IP-adresser: for at identificere peers unikt er det tilstr\u00e6kkeligt at bruge unikke v\u00e6rdier af Firebase-n\u00f8gler (svarende til dom\u00e6nenavne), og hver peer tildeler lokalt 'falske' IP-adresser til hver n\u00f8gle, der skal omdannes. Dette fjerner fuldst\u00e6ndigt behovet for global tildeling af IP-adresser, hvilket er en ikke-triviel opgave.<\/p>\n
Her er det minimale API, vi skal implementere:<\/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\nAPI'et er enkelt og ligner API'et for Posix Sockets, men har nogle vigtige forskelle: registrering af callback-funktioner, tildeling af lokale IP-adresser og 'lazy' forbindelse<\/strong>.<\/p>\nRegistrering af callback-funktioner<\/h2>\n \nSelv hvis den oprindelige program bruger ikke-blokerende input-output, skal koden refaktoreres for at k\u00f8re i en webbrowser.<\/p>\n
\u00c5rsagen til dette er, at begivenhedsl\u00f8kken i browseren er skjult for programmet (uanset om det er JavaScript eller WebAssembly).<\/p>\n
I et natives milj\u00f8 kan vi skrive koden s\u00e5dan her<\/p>\n
while(running) {\n select(...); \/\/ vent p\u00e5 I\/O begivenheder\n while(true) {\n int r = readfrom(...); \/\/ pr\u00f8v at l\u00e6se\n if (r < 0 && errno == EWOULDBLOCK) \/\/ ikke flere data tilg\u00e6ngelige\n break;\n ...\n }\n ...\n}<\/code><\/pre>\n\nHvis begivenhedsl\u00f8kken er skjult for os, skal den omdannes til noget som:<\/p>\n
auto cb = []() { \/\/ denne vil blive kaldt, n\u00e5r nye data er tilg\u00e6ngelige\n while(true) {\n int r = readfrom(...); \/\/ pr\u00f8v at l\u00e6se\n if (r < 0 && errno == EWOULDBLOCK) \/\/ ikke flere data tilg\u00e6ngelige\n break;\n ...\n }\n ...\n};\nrecvCallback(cb); \/\/ registrer callback'en<\/code><\/pre>\n<\/p>\n
Tildeling af lokale IP-adresser<\/h2>\n \nNoderne i vores \"netv\u00e6rk\" identificeres ikke ved IP-adresser, men ved Firebase-n\u00f8gler (de strenge, der ser s\u00e5dan ud: -LmEC50PYZLCiCP-vqde<\/code> ).<\/p>\nDet er praktisk, fordi vi ikke har brug for en mekanisme til at tildele IP og kontrollere deres unikke identitet (og ogs\u00e5 deres bortskaffelse efter frakobling af klienten), men det er ofte n\u00f8dvendigt at identificere peers ved numeriske v\u00e6rdier.<\/p>\n
Netop til dette bruges funktionerne resolve<\/code> og reverseResolve<\/code>: Applikationen f\u00e5r p\u00e5 en eller anden m\u00e5de den strenge v\u00e6rdi af n\u00f8glen (gennem brugerinput eller gennem masterserveren), og kan konvertere den til en IP-adresse til intern brug. Resten af API'et f\u00e5r ogs\u00e5 for nemhed i stedet for strengen denne v\u00e6rdi.<\/p>\nDet minder om DNS-opslag, men udf\u00f8res lokalt hos klienten.<\/p>\n
Det vil sige, at IP-adresser ikke kan v\u00e6re f\u00e6lles for forskellige klienter, og hvis der er behov for en global identifikator, skal den genereres p\u00e5 en anden m\u00e5de.<\/p>\n
Lazy connection<\/h2>\n \nUDP kr\u00e6ver ikke en forbindelse, men som vi har set, kr\u00e6ver WebRTC en lang forbindelsesproces, f\u00f8r data kan overf\u00f8res mellem to peers.<\/p>\n
Hvis vi vil sikre det samme abstraheringsniveau, (sendto<\/code>\/recvfrom<\/code> til vilk\u00e5rlige peers uden forudg\u00e5ende forbindelse), skal vi udf\u00f8re en \"lazy\" (forsinket) forbindelse inden for API'et.<\/p>\nHer er, hvad der sker ved almindelig dataudveksling mellem \"serveren\" og \"klienten\", n\u00e5r der bruges UDP, og hvad vores biblioteker skal udf\u00f8re:<\/p>\n
\nServeren kalder bind()<\/code>, for at informere operativsystemet om, at den vil modtage pakker p\u00e5 den angivne port.<\/li>\n<\/ul>\n\nI stedet offentligg\u00f8r vi en \u00e5ben port i Firebase under serverens n\u00f8gle og lytter efter begivenheder i dens undertr\u00e6.<\/p>\n
\nServeren kalder recvfrom()<\/code>, modtager pakker til denne port, der kommer fra enhver v\u00e6rt.<\/li>\n<\/ul>\n\nI vores tilf\u00e6lde skal vi kontrollere den indkommende pakkequeue, der sendes til denne port.<\/p>\n
Hver port har sin egen k\u00f8, og vi tilf\u00f8jer i starten af WebRTC-datagrammerne kilde- og destinationsportene for at vide, hvilken k\u00f8 vi skal omdirigere en ny pakke til, n\u00e5r den ankommer.<\/p>\n
Opkaldet er ikke-blokerende, s\u00e5 hvis der ikke er pakker, returnerer vi bare -1 og s\u00e6tter errno=EWOULDBLOCK<\/code>.<\/p>\n\nKlienten f\u00e5r serverens IP og port ved hj\u00e6lp af nogle eksterne metoder, og kalder sendto()<\/code>. Der udf\u00f8res ogs\u00e5 et internt kald, s\u00e5 den efterf\u00f8lgende bind()<\/code>f\u00e5r svar uden eksplicit at udf\u00f8re bind. recvfrom()<\/code> f\u00e5r svar uden at binde det eksplicit.<\/li>\n<\/ul>\n\nI vores tilf\u00e6lde f\u00e5r klienten en strengn\u00f8gle eksternt og bruger funktionen resolve()<\/code> for at f\u00e5 IP-adressen.<\/p>\nP\u00e5 dette tidspunkt begynder vi \"h\u00e5ndtrykket\" WebRTC, hvis de to peers endnu ikke er forbundet med hinanden. Forbindelser til forskellige porte p\u00e5 \u00e9n peer bruger den samme DataChannel WebRTC.<\/p>\n
Vi udf\u00f8rer desuden en indirekte bind()<\/code>, s\u00e5 serveren kan genoprette forbindelsen i den n\u00e6ste sendto()<\/code> i tilf\u00e6lde af, at den af en eller anden grund er blevet lukket.<\/p>\nServeren bliver informeret om klientens forbindelse, n\u00e5r klienten registrerer sit SDP-offer under serverens portinformation i Firebase, og serveren svarer med sit svar der.<\/p>\n
\nDiagrammet nedenfor viser et eksempel p\u00e5 bev\u00e6gelsen af meddelelser for socket-skemaet og overf\u00f8rslen af den f\u00f8rste meddelelse fra klienten til serveren:<\/p>\n
Den komplette skematiske forbindelse mellem klienten og serveren<\/i><\/p>\nKonklusion<\/h1>\n
\nHvis du er n\u00e5et hertil, er du sikkert interesseret i at se teorien i praksis. Du kan spille spillet p\u00e5 teeworlds.leaningtech.com<\/a><\/noindex>, pr\u00f8v det!<\/p>\n