Sissejuhatus

Meie ettevõte Leaning Technologies pakub lahendusi traditsiooniliste töölauarakenduste veebiversioonide jaoks. Meie C++ kompass Cheerp genereerib WebAssembly ja JavaScripti kombinatsiooni, mis tagab nii lihtsa suhtluse brauseriga, kui ka kõrge jõudluse.

Kuna näide selle kasutamisest otsustasime portida veebile jaoks mitmikmängu ja valisime selle jaoks Teeworlds. Teeworlds on kahemõõtmeline retro-mitmik mäng väikese, kuid aktiivse mängijate kogukonnaga (sealhulgas mina!). See on väike nii alla laadimise ressurssides kui ka CPU ja GPU nõuetes — ideaalne kandidaat.

Teeworlds, mis töötab brauseris

Otsustasime kasutada seda projekti, et eksperimenteerida üldiste lahendustega võrgu koodi portimiseks veebisse. Tavaliselt teostatakse seda järgmiste viisidega:

XMLHttpRequest/fetch, kui võrguosa koosneb ainult HTTP-päringutest, või
WebSockets.

Mõlemad lahendused nõuavad, et serveri komponent oleks serveripoolse hostimisega, ja kumbki ei luba kasutada transportprotokollina UDP. See on oluline reaalajas rakenduste, nagu videokonverentside tarkvara ja mängude jaoks, sest protokolli pakkumise ja järjekorra tagamise garantiid TCP võivad segada madala latentsusega.

On olemas ka kolmas tee — kasutada brauserivõrku: WebRTC.

RTCDataChannel toetab nii usaldusväärset kui ka usaldusväärset edastamist (viimasel juhul püüab see võimalusel kasutada transpordiprotokollina UDP-d) ning võib töötada nii kaugserveriga kui ka brauserite vahel. See tähendab, et saame portida kogu rakenduse brauserisse, sealhulgas serverikomponendi!

Siiski on sellega seotud lisaraskus: enne kui kaks WebRTC peer'i saavad andmeid vahetada, peavad nad läbima suhteliselt keerulise „kätlemise“ protseduuri ühendamiseks, milleks on vajalik mitu kolmanda osapoole erinevat üksust (signaaliserver ja üks või mitu serverit STUN/TURN).

Ideaalis tahaksime luua võrguteabe, mis kasutab siseselt WebRTC-d, kuid on nii lähedane UDP Sockets liidesele, et see ei nõua ühenduse loomist.

See aitab meil kasutada WebRTC eeliseid, ilma et peaksime rakenduse koodi keerulisi üksikasju paljastama (mida soovisime oma projektis vähem muuta).

Minimaalne WebRTC

WebRTC on brauserites olemasolev API komplekt, mis võimaldab peer-to-peer heli, video ja mis tahes andmete edastamist.

Ühendus peer’ide vahel luuakse (isegi kui NAT on ühelt või kahelt poolt) STUN ja/või TURN serverite abil, kasutades mehhanismi nimega ICE. Peer’id vahetavad ICE teavet ja kanaliparameetreid SDP protokolli pakkumise ja vastuse kaudu.

Vau! Nii palju lühendeid korraga. Selgiteks lühidalt, mida need mõisted tähendavad:

Session Traversal Utilities for NAT (STUN) — protokoll NAT-i ületamiseks ja (IP, port) páru hankimiseks, et andmeid otse hostiga vahetada. Kui see suudab oma ülesande täita, saavad peer’id omavahel andmeid iseseisvalt vahetada.
Traversal Using Relays around NAT (TURN) kasutatakse ka NAT-i ületamiseks, kuid see teeb seda, suunates andmeid kaudu vaheproksi, mis on mõlemale peerile nähtav. See lisab viivituse ja on täitmisel kulukam kui STUN (kuna see rakendatakse kogu suhtlusseansi vältel), kuid mõnikord on see ainus võimalik variant.
Interaktiivne Ühenduse Loomine (ICE) kasutatakse kahe peer'i parima ühendusviisi valimiseks, tuginedes teabele, mis on saadud otsese ühenduse loomisel peer'ide vahel, ning teabele, mis on saadud igasugustelt STUN ja TURN serveritelt.
Seansi Kirjeldamise Protokoll (SDP) on ühenduskanali parameetrite, näiteks ICE kandidaatidest, meedia koodekidest (heli/videokanali puhul) jne, kirjeldamise formaat. Üks peer saadab SDP pakkumise ("pakkumine"), teine vastab SDP vastusega ("vastus"). Pärast seda luuakse kanal.

Selle ühenduse loomiseks peavad peer'id koguma teavet, mille nad on saanud STUN ja TURN serveritelt, ja vahetama seda omavahel.

Probleem on selles, et neil pole veel võimalust andmeid otse vahetada, seega peab andmete vahetamiseks olema olemas vaheline mehhanism: signaaliserver.

Signaalserver võib olla väga lihtne, kuna selle ainus ülesanne on edastada andmeid paaride vahel „kätlemise” etapis (nagu on kujutatud alloleval skeemil).

Lihtsustatud WebRTC kätlemise järjestuse skeem

Teeworldsi võrgu mudeli ülevaade

Teeworldsi võrgu arhitektuur on väga lihtne:

Kliendi ja serveri komponendid on kaks erinevat programmi.
Kliendid liituvad mänguga, ühendudes ühe mitmest serverist, millest igaüks hostib korraga ainult ühte mängu.
Kõik mängus sisalduvad andmed edastatakse serveri kaudu.
Eraldi meistriserverit kasutatakse kõigi avalike serverite nimekirja kogumiseks, mis kuvatakse mängu kliendis.

Andmete vahetamiseks WebRTC kasutamine võimaldab meil viia mängu serveri komponendi brauserisse, kus klient asub. See annab meile suurepärase võimaluse…

Vabaneda serveritest

Serveri loogika puudumine toob kaasa meeldiva eelise: saame rakenduse paigutada staatilise sisuna GitHub Pages'i või oma seadmetesse Cloudflare'i tagant, kindlustades seeläbi tasuta kiire laadimise ja kõrge tööaja. Tegelikult võiksime neist täielikult unustada, ning kui meil vedama hakkab ja mäng muutub populaarseks, siis infrastruktuuri uuendama ei pea.

Kuid süsteemi tõhusaks töötamiseks peame siiski kasutama välist arhitektuuri:

Üks või mitu STUN serverit: meil on valida mitme tasuta variandi vahel.
Kõik vähemalt üks TURN server: siin tasuta variante ei ole, seega võime kas seada oma või maksta teenuse eest. Õnneks saab suurema osa ajast ühenduse luua STUN serverite kaudu (tagades tõelise p2p), kuid TURN on vajalik varuvõimalusena.
Signaaliserver: erinevalt teistest kaht aspektist ei ole signaalimise standardiseerimist. See, mille eest signaaliserver tegelikult vastutab, sõltub osade kaupa rakendusest. Meie puhul tuleb enne ühenduse loomist vahetada väike andmemaht.
Teeworldsi meistriserver: seda kasutavad teised serverid oma olemasolu teatamiseks ning kliendid avalike serverite leidmiseks. Kuigi see ei ole kohustuslik (kliendid saavad alati manuaalselt ühenduda tuttava serveriga), oleks see kasulik, et mängijad saaksid osaleda mängudes juhuslike inimestega.

Otsustasime kasutada Google'i tasuta STUN-servereid, ning ühe TURN-serveri seadistasime ise.

Kahe viimase punkti jaoks kasutasime Firebase:

Teeworldsi meistriserver on väga lihtsalt rakendatud: see on objektiloetelu, mis sisaldab teavet (nimi, IP, kaart, režiim jne) iga aktiivse serveri kohta. Serverid avaldavad ja uuendavad oma objekti ning kliendid saavad kogu loendi ning kuvavad selle mängijale. Samuti kuvame loendi avalehel HTMLina, et mängijad saaksid lihtsalt serverile klikkida ja otse mängu siseneda.
Signaalimine on tihedalt seotud meie soklite rakendusega, mida kirjeldatakse järgmises jaotises.

Serverite loend mängus ja avalehel

Soklite rakendamine

Soovime luua API, mis oleks võimalikult lähedane Posix UDP sokkidele, et minimeerida vajalike muudatuste arvu.

Samuti soovime rakendada vajalikku miinimumi, mis on vajalik kõige lihtsama andmevahetuse jaoks üle võrgu.

Näiteks me ei vaja tõelist suunamist: kõik peer’id asuvad ühes „virtuaalses LANis“, mis on seotud konkreetse Firebase'i andmebaasi eksemplariga.

Seetõttu ei ole meil unikaalsed IP-aadressid vajalikud: piisab, kui kasutada unikaalseid Firebase võtme väärtusi (sarnaselt domeeninimedele), ning iga peer määrab igale võtmele kohalikult "vale" IP-aadressi, mida tuleb konverteerida. See vabastab meid globaalsete IP-aadresside määramisest, mis on mitte triviaalne ülesanne.

Siin on minimaalne API, mille me peame rakendama:

// Create and destroy a socket
int socket();
int close(int fd);
// Bind a socket to a port, and publish it on Firebase
int bind(int fd, AddrInfo* addr);
// Send a packet. This lazily create a WebRTC connection to the 
// peer when necessary
int sendto(int fd, uint8_t* buf, int len, const AddrInfo* addr);
// Receive the packets destined to this socket
int recvfrom(int fd, uint8_t* buf, int len, AddrInfo* addr);
// Be notified when new packets arrived
int recvCallback(Callback cb);
// Obtain a local ip address for this peer key
uint32_t resolve(client::String* key);
// Get the peer key for this ip
String* reverseResolve(uint32_t addr);
// Get the local peer key
String* local_key();
// Initialize the library with the given Firebase database and 
// WebRTc connection options
void init(client::FirebaseConfig* fb, client::RTCConfiguration* ice);

API on lihtne ja sarnaneb Posix Sockets API-le, kuid on mitmeid olulisi erinevusi: tagasikutsumiste registreerimine, kohalike IP-de määramine ja "laiska" ühendamine.

Tagasikutsumiste registreerimine

Isegi kui algne programm kasutab mittesummutavat I/O-d, tuleb kood veebibrauseris töötamiseks refaktoorida.

Selle põhjuseks on see, et brauseris on sündmuste tsükkel programmist varjatud (ükskõik kas see on JavaScript või WebAssembly).

Kohalikus keskkonnas saame koodi kirjutada järgmiselt

while(running) {
  select(...); // oota I/O sündmusi
  while(true) {
    int r = readfrom(...); // proovi lugeda
    if (r < 0 && errno == EWOULDBLOCK) // enam andmeid ei ole kättevõetav
      break;
    ...
  }
  ...
}

Kui sündmuste tsükkel on meie jaoks varjatud, tuleb see muuta millegi sarnaseks:

auto cb = []() { // see this will be called when new data is available
  while(true) {
    int r = readfrom(...); // try to read
    if (r < 0 && errno == EWOULDBLOCK) // no more data available
      break;
    ...
  }
  ...
};
recvCallback(cb); // register the callback

Kohalikud IP-aadressid

Meie 'võrgus' olevate sõlmede identifikaatorid ei ole IP-aadressid, vaid Firebase'i võtmed (need on stringid, mis näevad välja sellised: -LmEC50PYZLCiCP-vqde ).

See on mugav, sest me ei vaja mehhanismi IP-de määramiseks ja nende unikaalsuse kontrollimiseks (samuti nende utiliseerimiseks pärast kliendi lahtiühendamist), kuid tihti on vajalik identifitseerida peer'e numbriliste väärtuste järgi.

Just selle jaoks kasutatakse funktsioone resolve ja reverseResolve: rakendus saab tõlkida võtme stringi väärtuse (kasutaja sisendi kaudu või master-serveri kaudu) ja võib selle sisemiselt IP-aadressiks muuta. API ülejäänud osa saab samuti selle väärtuse stringina, et lihtsustada kasutamist.

See on sarnane DNS-otsingule, kuid toimub kliendi kohal.

See tähendab, et IP-aadressid ei saa olla erinevate klientide jaoks ühised ja kui on vajalik mingi globaalne identifikaator, tuleb see genereerida muul viisil.

Laisk ühendus

UDP ei nõua ühendust, kuid nagu me oleme näinud, enne andmete edastamise alustamist kahe peer'i vahel nõuab WebRTC pikka ühendusprotsessi.

Kui soovime tagada sama abstraktsiooni taseme, (sendto/recvfrom ilma eelneva ühenduseta juhuslike peer'idega), peame teostama "laiska" (edasilükatud) ühendamist API sees.

Nii toimub tavaline andmevahetus "serveri" ja "kliendi" vahel UDP kasutamisel ning mida peaks meie teek tegema:

Server kutsub välja bind(), et teavitada operatsioonisüsteemi soovist saada pakette määratud porti.

Selle asemel avaldame Firebase'is avatud portaali serveri võtme all ja kuulame sündmusi selle alampuus.

Server kutsub välja recvfrom(), et võtta vastu pakette, mis saadetakse sellele portile mistahes hostilt.

Meie puhul tuleb kontrollida sissetulevat pakettide järjekorda, mis on saadetud sellele portile.

Igal pordil on oma järjekord ning me lisame WebRTC datagrammidele algusesse alg- ja lõpp-pordid, et teada, kuhu suunata uus pakett.

Väljakutse on mitteblokeeriv, seega, kui pakette pole, tagastame lihtsalt -1 ja määrame errno=EWOULDBLOCK.

Kliendil on väliste allikate kaudu IP ja serveri port, ning ta kutsub sendto(). Samuti toimub see ajal sisemine kutse bind(), seega järgnev recvfrom() saab vastuse ilma selge bind-kutsumise protsessita.

Meie puhul saab klient väliselt stringi võtme ja kasutab funktsiooni resolve() IP-aadresse saamiseks.

Selles etapis alustame WebRTC "kätlemist", kui kaks peer-i veel ei ole üksteisega ühendatud. Ühendused ühe peer-i erinevatele portidele kasutavad sama WebRTC DataChannelit.

Me teostame ka kaudset bind(), et server saaks järgmises sendto() kui see mingil põhjusel suletakse.

Serverile antakse teada kliendi ühendusest, kui klient salvestab oma SDP pakkumise serveri porti informatsiooniga Firebase'is, ja server vastab seal oma vastusega.

Alltoodud skeemil on näidatud sõnumite liikumine socket-skeemi ja kliendi jaoks serveri esimese sõnumi edastamine:

Kliendi ja serveri vahelise ühenduse etapi täielik skeem