Introduktion

Vårt företag Leaning Technologies tillhandahåller lösningar för portering av traditionella desktopapplikationer till webben. Vår C++-kompilator Cheerp genererar en kombination av WebAssembly och JavaScript, vilket möjliggör både enkelt samspel med webbläsaren, och hög prestanda.

Som exempel på dess tillämpning har vi beslutat att portera ett flerspelarspel för webben och valde Teeworlds. Teeworlds är ett flerspelars 2D-retrospel med ett litet men aktivt spelargemenskap (bland dem jag!). Det är litet både när det gäller nedladdningsresurser och krav på CPU och GPU – en idealisk kandidat.

Teeworlds som fungerar i webbläsaren

Vi beslutade att använda detta projekt för att experimentera med gemensamma lösningar för portering av nätverkskod till webben. Detta utförs vanligtvis på följande sätt:

XMLHttpRequest/fetch, om nätverksdelen endast består av HTTP-förfrågningar, eller
WebSockets.

Båda lösningarna kräver att hysa serverkomponenten på serversidan, och ingen av dem tillåter användning av UDP. Detta är viktigt för realtidsapplikationer, såsom programvara för videokonferenser och spel, eftersom garantier för leverans och paketordning för protokollet TCP kan störa låga latenser.

Det finns också ett tredje sätt – att använda nätverket från webbläsaren: WebRTC.

RTCDataChannel stödjer både pålitlig och opålitlig överföring (i det senare fallet försöker det i möjligaste mån använda UDP som transportprotokoll), och kan användas både med en fjärrserver och mellan webbläsare. Det betyder att vi kan portera hela applikationen till webbläsaren, inklusive serverkomponenten!

Men det finns en ytterligare svårighet: innan två WebRTC-peerar kan utbyta data måste de genomföra en relativt komplex "handskakning"-procedur för att ansluta, vilket kräver flera externa enheter (signalingserver och en eller flera STUN/TURN).

I idealfallet skulle vi vilja skapa ett nätverks-API, som inuti använder WebRTC, men som så nära som möjligt liknar gränssnittet för UDP-sockets, vilket inte behöver etablera en anslutning.

Det här gör att vi kan utnyttja fördelarna med WebRTC utan att behöva avslöja de komplexa detaljerna i applikationens kod (som vi ville ändra så lite som möjligt i vårt projekt).

Minimal WebRTC

WebRTC är en uppsättning API:er som finns i webbläsare och möjliggör peer-to-peer överföring av ljud, video och godtyckliga data.

Anslutningen mellan peeringarna upprättas (även om det finns NAT på ena eller båda sidor) med hjälp av STUN- och/eller TURN-servrar genom en mekanism som kallas ICE. Peeringar byter information om ICE och kanalparametrar via offer och answer-protokollet SDP.

Oj! Så många förkortningar på en gång. Låt oss kort förklara vad dessa termer betyder:

Session Traversal Utilities for NAT (STUN) är ett protokoll för att kringgå NAT och få ett par (IP, port) för att utbyta data direkt med värden. Om det lyckas med sin uppgift kan peeringar utbyta data sinsemellan.
Traversal Using Relays around NAT (TURN) används också för att kringgå NAT, men det gör detta genom att omdirigera data via en proxy som är synlig för båda peeringarna. Det tillför fördröjning och är mer resurskrävande än STUN (eftersom det tillämpas under hela kommunikationssessionen), men ibland är det den enda möjliga lösningen.
Interactive Connectivity Establishment (ICE) används för att välja det bästa möjliga sättet att ansluta två peeringar baserat på information som erhållits vid den direkta anslutningen av peeringarna samt information från ett antal STUN- och TURN-servrar.
Session Description Protocol (SDP) är ett format för beskrivning av anslutningskanalens parametrar, till exempel kandidater för ICE, multimedia-codecs (i fallet med ljud/videokanal), osv. En av peeringarna skickar en SDP Offer ("erbjudande"), och den andra svarar med en SDP Answer ("svar"). Efter detta skapas en kanal.

För att skapa en sådan anslutning behöver peeringarna samla informationen de fått från STUN- och TURN-servrarna och utbyta den sinsemellan.

Problemet är att de för närvarande inte kan utbyta data direkt, därför måste det finnas en utanför-band mekanism för att utbyta dessa data: en signalserver.

Signalservern kan vara mycket enkel, eftersom dess enda uppgift är att omdirigera data mellan peeringarna under "handtryckssteget" (som visas i diagrammet nedan).

Förenklad sekvensdiagram för WebRTC-handtryckning

Översikt av nätverksmodellen Teeworlds

Nätverksarkitekturen i Teeworlds är mycket enkel:

Klient- och serverkomponenterna är två olika program.
Kunder går med i spelet genom att ansluta till en av flera servrar, var och en av vilka är värd för endast ett spel åt gången.
All dataöverföring i spelet sker genom servern.
En särskild mästerserver används för att samla en lista över alla offentliga servrar som visas i spelklienten.

Genom att använda WebRTC för datakommunikation kan vi flytta serverkomponenten av spelet till webbläsaren där klienten finns. Detta ger oss en fantastisk möjlighet…

Att slippa servrar

Bristen på serverlogik har en trevlig fördel: vi kan implementera hela applikationen som statiskt innehåll på Github Pages eller på vår egen hårdvara bakom Cloudflare, vilket på så sätt gratis ger oss snabba laddningstider och hög drifttid. I huvudsak kan vi glömma dem, och om vi har tur och spelet blir populärt, behöver infrastrukturen inte uppgraderas.

Men för att systemet ska fungera måste vi ändå använda extern arkitektur:

En eller flera STUN-servrar: vi har flera gratis alternativ att välja på.
Minst en TURN-server: här finns det inga gratis alternativ, så vi kan antingen ställa in vår egen eller betala för en tjänst. Lyckligtvis kan anslutning i de flesta fall upprättas via STUN-servrar (och möjliggöra äkta p2p), men TURN är nödvändig som en reserv.
Signaleringsserver: till skillnad från de två andra aspekterna är signalering inte standardiserad. Vad som faktiskt kommer att ansvara för signaleringsservern beror delvis på applikationen. I vårt fall är det nödvändigt att byta en liten mängd data innan anslutningen kan upprättas.
Teeworlds mästerserver: den används av andra servrar för att meddela sin existens och av kunder för att söka efter offentliga servrar. Även om den inte är obligatorisk (kunder kan alltid manuellt ansluta till en server de känner till), skulle det vara bra att ha den så att spelare kan delta i spel med slumpmässiga människor.

Vi har valt att använda Googles gratis STUN-servrar, medan vi har implementerat en TURN-server själva.

För de två senaste punkterna använde vi Firebase:

Mästaren för Teeworlds-servern är väldigt enkelt genomfört: som en lista med objekt som innehåller information (namn, IP, karta, läge, ...) om varje aktiv server. Servrar publicerar och uppdaterar sitt eget objekt, och klienterna hämtar hela listan och visar den för spelaren. Vi visar också listan på startsidan som HTML, så att spelarna enkelt kan klicka på servern och gå direkt in i spelet.
Signalering är nära kopplad till vår implementering av socketar, som beskrivs i nästa avsnitt.

Serverlista inom spelet och på startsidan

Implementering av socketar

Vi vill skapa ett API som ligger så nära Posix UDP Socketar som möjligt för att minimera antalet nödvändiga förändringar.

Vi vill också implementera det minimala som krävs för den enklaste datakommunikationen över nätverket.

Till exempel behöver vi ingen riktig routing: alla peers är i ett enda "virtuellt LAN" kopplat till en specifik instans av Firebase-databasen.

Därför behöver vi inga unika IP-adresser: för unik identifiering av peers räcker det med att använda unika nyckelvärden från Firebase (liknande domännamn), och varje peer tilldelar lokalt "falska" IP-adresser till varje nyckel som behöver översättas. Detta befriar oss helt från behovet av global IP-tilldelning, vilket är en icke-trivial uppgift.

Här är det minimala API:t som vi behöver implementera:

// 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:t är enkelt och liknar API:t för Posix Socketar, men har några viktiga skillnader: registrering av callbacks, tilldelning av lokala IP adresser och "lazy" anslutning.

Registrering av callbacks

Även om det ursprungliga programmet använder icke-blockerande I/O, behöver koden refaktoreras för att köras i webbläsaren.

Anledningen till detta är att händelseloopen i webbläsaren är dold för programmet (oavsett om det är JavaScript eller WebAssembly).

I en inhemsk miljö kan vi skriva kod på följande sätt

while(running) {
  select(...); // vänta på I/O-händelser
  while(true) {
    int r = readfrom(...); // försök att läsa
    if (r < 0 && errno == EWOULDBLOCK) // ingen mer data tillgänglig
      break;
    ...
  }
  ...
}

Om händelseloopen är dold för oss, måste vi omvandla den till något som liknar detta:

auto cb = []() { // detta kommer att kallas när ny data är tillgänglig
  while(true) {
    int r = readfrom(...); // försök att läsa
    if (r < 0 && errno == EWOULDBLOCK) // ingen mer data tillgänglig
      break;
    ...
  }
  ...
};
recvCallback(cb); // registrera callback-funktionen

Tilldelning av lokala IP-adresser

Identifierarna för noder i vårt "nät" är inte IP-adresser, utan Firebase-nycklar (detta är strängar som ser ut så här: -LmEC50PYZLCiCP-vqde ).

Detta är praktiskt eftersom vi inte behöver en mekanism för att tilldela IP-adresser och kontrollera deras unika värde (eller avveckla dem efter att kunden har kopplats bort), men det är ofta nödvändigt att identifiera peers med ett numeriskt värde.

Det är just därför vi använder funktioner resolve och reverseResolve: applikationen får på något sätt strängvärdet av nyckeln (genom användarinmatning eller genom en masterserver), och kan omvandla det till en IP-adress för internt bruk. Resterande del av API:et får också istället för strängen detta värde för enkelhetens skull.

Det liknar en DNS-sökning, men den görs lokalt hos klienten.

Det vill säga att IP-adresser inte kan vara gemensamma för olika klienter, och om någon global identifierare behövs, måste den genereras på annat sätt.

Lazykoppling

UDP kräver ingen anslutning, men som vi har sett, innan vi börjar överföra data mellan två peers, kräver WebRTC en lång anslutningsprocess.

Om vi vill upprätthålla samma abstraktionsnivå, (sendto/recvfrom med godtyckliga peers utan föregående anslutning), måste vi utföra en "lazy" (uppskjuten) anslutning inom API:et.

Så här fungerar den vanliga datautbytet mellan "servern" och "klienten" när man använder UDP, och vad vårt bibliotek måste utföra:

Servern anropar bind(), för att informera operativsystemet om att den vill ta emot paket på den angivna porten.

Istället publicerar vi en öppen port i Firebase under serverns nyckel och kommer att lyssna på händelser i dess underträd.

Servern anropar recvfrom(), tar emot paket på den här porten från vilken värd som helst.

I vårt fall måste vi kontrollera ingångskön för paket som skickas till den här porten.

Varje port har sin egen kö, och vi lägger till ursprungliga och slutgiltiga portar i WebRTC-datagrammen för att veta vilken kö vi ska dirigera ett nytt paket till när det ankommer.

Anropet är icke-blockerande, så om det inte finns några paket returnerar vi helt enkelt -1 och ställer in errno=EWOULDBLOCK.

Klienten får IP och serverport genom några externa medel, och anropar sendto(). Samtidigt görs ett internt anrop bind(), så efterföljande recvfrom() får svaret utan uttrycklig bindning.

I vårt fall får kunden en strängnyckel externt och använder funktionen resolve() för att hämta IP-adressen.

I det här steget börjar vi "handshake" för WebRTC, om två peers ännu inte är anslutna till varandra. Anslutningar till olika portar hos en peer använder samma DataChannel för WebRTC.

Vi utför också en indirekt bind(), så att servern kan återupprätta anslutningen i nästa sendto() ifall den av någon anledning har stängts.

Servern meddelas om klientens anslutning när klienten skriver sitt SDP-erbjudande under serverns portinformation i Firebase, och servern svarar med sin respons där.

I schemat nedan visas ett exempel på meddelandeflödet för socket-schemat och överföringen av det första meddelandet från klienten till servern:

Den fullständiga schemat för anslutningssteget mellan klienten och servern