Signalering \u00e4r n\u00e4ra kopplad till v\u00e5r implementering av socketar, som beskrivs i n\u00e4sta avsnitt.<\/li>\n<\/ul>\n\nServerlista inom spelet och p\u00e5 startsidan<\/i><\/p>\nImplementering av socketar<\/h1>\n
\nVi vill skapa ett API som ligger s\u00e5 n\u00e4ra Posix UDP Socketar som m\u00f6jligt f\u00f6r att minimera antalet n\u00f6dv\u00e4ndiga f\u00f6r\u00e4ndringar.<\/p>\n
Vi vill ocks\u00e5 implementera det minimala som kr\u00e4vs f\u00f6r den enklaste datakommunikationen \u00f6ver n\u00e4tverket.<\/p>\n
Till exempel beh\u00f6ver vi ingen riktig routing: alla peers \u00e4r i ett enda \"virtuellt LAN\" kopplat till en specifik instans av Firebase-databasen.<\/p>\n
D\u00e4rf\u00f6r beh\u00f6ver vi inga unika IP-adresser: f\u00f6r unik identifiering av peers r\u00e4cker det med att anv\u00e4nda unika nyckelv\u00e4rden fr\u00e5n Firebase (liknande dom\u00e4nnamn), och varje peer tilldelar lokalt \"falska\" IP-adresser till varje nyckel som beh\u00f6ver \u00f6vers\u00e4ttas. Detta befriar oss helt fr\u00e5n behovet av global IP-tilldelning, vilket \u00e4r en icke-trivial uppgift.<\/p>\n
H\u00e4r \u00e4r det minimala API:t som vi beh\u00f6ver implementera:<\/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:t \u00e4r enkelt och liknar API:t f\u00f6r Posix Socketar, men har n\u00e5gra viktiga skillnader: registrering av callbacks, tilldelning av lokala IP adresser och \"lazy\" anslutning<\/strong>.<\/p>\nRegistrering av callbacks<\/h2>\n \n\u00c4ven om det ursprungliga programmet anv\u00e4nder icke-blockerande I\/O, beh\u00f6ver koden refaktoreras f\u00f6r att k\u00f6ras i webbl\u00e4saren.<\/p>\n
Anledningen till detta \u00e4r att h\u00e4ndelseloopen i webbl\u00e4saren \u00e4r dold f\u00f6r programmet (oavsett om det \u00e4r JavaScript eller WebAssembly).<\/p>\n
I en inhemsk milj\u00f6 kan vi skriva kod p\u00e5 f\u00f6ljande s\u00e4tt<\/p>\n
while(running) {\n select(...); \/\/ v\u00e4nta p\u00e5 I\/O-h\u00e4ndelser\n while(true) {\n int r = readfrom(...); \/\/ f\u00f6rs\u00f6k att l\u00e4sa\n if (r < 0 && errno == EWOULDBLOCK) \/\/ ingen mer data tillg\u00e4nglig\n break;\n ...\n }\n ...\n}<\/code><\/pre>\n\nOm h\u00e4ndelseloopen \u00e4r dold f\u00f6r oss, m\u00e5ste vi omvandla den till n\u00e5got som liknar detta:<\/p>\n
auto cb = []() { \/\/ detta kommer att kallas n\u00e4r ny data \u00e4r tillg\u00e4nglig\n while(true) {\n int r = readfrom(...); \/\/ f\u00f6rs\u00f6k att l\u00e4sa\n if (r < 0 && errno == EWOULDBLOCK) \/\/ ingen mer data tillg\u00e4nglig\n break;\n ...\n }\n ...\n};\nrecvCallback(cb); \/\/ registrera callback-funktionen<\/code><\/pre>\n<\/p>\n
Tilldelning av lokala IP-adresser<\/h2>\n \nIdentifierarna f\u00f6r noder i v\u00e5rt \"n\u00e4t\" \u00e4r inte IP-adresser, utan Firebase-nycklar (detta \u00e4r str\u00e4ngar som ser ut s\u00e5 h\u00e4r: -LmEC50PYZLCiCP-vqde<\/code> ).<\/p>\nDetta \u00e4r praktiskt eftersom vi inte beh\u00f6ver en mekanism f\u00f6r att tilldela IP-adresser och kontrollera deras unika v\u00e4rde (eller avveckla dem efter att kunden har kopplats bort), men det \u00e4r ofta n\u00f6dv\u00e4ndigt att identifiera peers med ett numeriskt v\u00e4rde.<\/p>\n
Det \u00e4r just d\u00e4rf\u00f6r vi anv\u00e4nder funktioner resolve<\/code> och reverseResolve<\/code>: applikationen f\u00e5r p\u00e5 n\u00e5got s\u00e4tt str\u00e4ngv\u00e4rdet av nyckeln (genom anv\u00e4ndarinmatning eller genom en masterserver), och kan omvandla det till en IP-adress f\u00f6r internt bruk. Resterande del av API:et f\u00e5r ocks\u00e5 ist\u00e4llet f\u00f6r str\u00e4ngen detta v\u00e4rde f\u00f6r enkelhetens skull.<\/p>\nDet liknar en DNS-s\u00f6kning, men den g\u00f6rs lokalt hos klienten.<\/p>\n
Det vill s\u00e4ga att IP-adresser inte kan vara gemensamma f\u00f6r olika klienter, och om n\u00e5gon global identifierare beh\u00f6vs, m\u00e5ste den genereras p\u00e5 annat s\u00e4tt.<\/p>\n
Lazykoppling<\/h2>\n \nUDP kr\u00e4ver ingen anslutning, men som vi har sett, innan vi b\u00f6rjar \u00f6verf\u00f6ra data mellan tv\u00e5 peers, kr\u00e4ver WebRTC en l\u00e5ng anslutningsprocess.<\/p>\n
Om vi vill uppr\u00e4tth\u00e5lla samma abstraktionsniv\u00e5, (sendto<\/code>\/recvfrom<\/code> med godtyckliga peers utan f\u00f6reg\u00e5ende anslutning), m\u00e5ste vi utf\u00f6ra en \"lazy\" (uppskjuten) anslutning inom API:et.<\/p>\nS\u00e5 h\u00e4r fungerar den vanliga datautbytet mellan \"servern\" och \"klienten\" n\u00e4r man anv\u00e4nder UDP, och vad v\u00e5rt bibliotek m\u00e5ste utf\u00f6ra:<\/p>\n
\nServern anropar bind()<\/code>, f\u00f6r att informera operativsystemet om att den vill ta emot paket p\u00e5 den angivna porten.<\/li>\n<\/ul>\n\nIst\u00e4llet publicerar vi en \u00f6ppen port i Firebase under serverns nyckel och kommer att lyssna p\u00e5 h\u00e4ndelser i dess undertr\u00e4d.<\/p>\n
\nServern anropar recvfrom()<\/code>, tar emot paket p\u00e5 den h\u00e4r porten fr\u00e5n vilken v\u00e4rd som helst.<\/li>\n<\/ul>\n\nI v\u00e5rt fall m\u00e5ste vi kontrollera ing\u00e5ngsk\u00f6n f\u00f6r paket som skickas till den h\u00e4r porten.<\/p>\n
Varje port har sin egen k\u00f6, och vi l\u00e4gger till ursprungliga och slutgiltiga portar i WebRTC-datagrammen f\u00f6r att veta vilken k\u00f6 vi ska dirigera ett nytt paket till n\u00e4r det ankommer.<\/p>\n
Anropet \u00e4r icke-blockerande, s\u00e5 om det inte finns n\u00e5gra paket returnerar vi helt enkelt -1 och st\u00e4ller in errno=EWOULDBLOCK<\/code>.<\/p>\n\nKlienten f\u00e5r IP och serverport genom n\u00e5gra externa medel, och anropar sendto()<\/code>. Samtidigt g\u00f6rs ett internt anrop bind()<\/code>, s\u00e5 efterf\u00f6ljande recvfrom()<\/code> f\u00e5r svaret utan uttrycklig bindning.<\/li>\n<\/ul>\n\nI v\u00e5rt fall f\u00e5r kunden en str\u00e4ngnyckel externt och anv\u00e4nder funktionen resolve()<\/code> f\u00f6r att h\u00e4mta IP-adressen.<\/p>\nI det h\u00e4r steget b\u00f6rjar vi \"handshake\" f\u00f6r WebRTC, om tv\u00e5 peers \u00e4nnu inte \u00e4r anslutna till varandra. Anslutningar till olika portar hos en peer anv\u00e4nder samma DataChannel f\u00f6r WebRTC.<\/p>\n
Vi utf\u00f6r ocks\u00e5 en indirekt bind()<\/code>, s\u00e5 att servern kan \u00e5teruppr\u00e4tta anslutningen i n\u00e4sta sendto()<\/code> ifall den av n\u00e5gon anledning har st\u00e4ngts.<\/p>\nServern meddelas om klientens anslutning n\u00e4r klienten skriver sitt SDP-erbjudande under serverns portinformation i Firebase, och servern svarar med sin respons d\u00e4r.<\/p>\n
\nI schemat nedan visas ett exempel p\u00e5 meddelandefl\u00f6det f\u00f6r socket-schemat och \u00f6verf\u00f6ringen av det f\u00f6rsta meddelandet fr\u00e5n klienten till servern:<\/p>\n
Den fullst\u00e4ndiga schemat f\u00f6r anslutningssteget mellan klienten och servern<\/i><\/p>\nSlutsats<\/h1>\n
\nOm du har l\u00e4st \u00e4nda hit s\u00e5 \u00e4r du nog intresserad av att se teorin i praktiken. Du kan spela spelet p\u00e5 teeworlds.leaningtech.com<\/a><\/noindex>, ge det ett f\u00f6rs\u00f6k!<\/p>\n