🥇Molngaming med öppen källkod på WebRTC: p2p, multiplayer, zero latency

Programvara som tjänst, infrastruktur som tjänst, plattform som tjänst, kommunikationsplattform som tjänst, videokonferenser som tjänst, men vad sägs om molngaming som tjänst? Det har redan gjorts flera försök att skapa molngaming (Cloud Gaming), som till exempel Stadia, nyligen lanserad av Google. Stadia är inte ny inom WebRTC, men kan andra använda WebRTC på samma sätt?

Thanh Nguyen beslutade att undersöka denna möjlighet i sitt öppen källkodsprojekt CloudRetro. CloudRetro är baserat på Pion, en populär WebRTC-bibliotek byggt på Go (tack Sean från Pion-utvecklargruppen för hjälpen med att förbereda denna artikel). I denna artikel ger Thanh en översikt över arkitekturen av sitt projekt och berättar vad han har lärt sig och vilka utmaningar han har stött på under arbetets gång.

Inledning

Förra året, när Google tillkännagav Stadia, blev jag helt exalterad. Idén är så unik och innovativ att jag ständigt funderade på hur något sådant överhuvudtaget är möjligt med de nuvarande teknologierna. En önskan att förstå detta bättre ledde mig till att skapa min egen version av molngaming med öppen källkod. Resultatet var helt fantastiskt. Nedan vill jag dela med mig av processen bakom mitt ettåriga projekt.

TLDR: kort sammanfattning med huvudpunkterna

Varför molngaming är framtiden

Jag tror att molngaming snart kommer att bli den nya generationen av inte bara spel, utan även inom andra områden av datavetenskap. Molngaming är toppen av klient/server-modellen. Denna modell maximerar backend-hantering och minimerar frontend-arbetet genom att placera spel-logiken på en fjärrserver och streama bilder/ljud till klienten. Servern utför den tunga bearbetningen, så klienten längre är beroende av hårdvarubegränsningar.

Google Stadia tillåter i praktiken att spela AAA-spel (dvs. högklassiga blockbuster-spel) på en plattform liknande YouTube. Samma metodik kan tillämpas på andra tunga offline-applikationer, som operativsystem eller 2D/3D grafikdesign etc., så att vi kan köra dem stabilt på lågt specifikationsutrustning på olika plattformar.

Framtiden för denna teknik: föreställ dig att Microsoft Windows 10 skulle fungera i webbläsaren Chrome?

Molnspel är tekniskt utmanande

Gaming är ett av de sällsynta områdena där konstant snabb respons från användaren krävs. Om vi ibland har en fördröjning på 2 sekunder när vi klickar på en sida, är det acceptabelt. Liveströmmar ligger vanligtvis efter med några sekunder, men erbjuder ändå tillräcklig användarvänlighet. Men om ett spel ofta laggar med 500 ms, är det helt enkelt omöjligt att spela. Vårt mål är att uppnå extremt låg latens så att skillnaden mellan input och media är så liten som möjligt. Därför är den traditionella metoden för videostreaming här inte tillämplig.

Den övergripande mallen för molnspel

Open source-projektet CloudRetro

Jag beslutade att skapa ett testexempel på molnspel för att se om allt detta är möjligt under sådana strikta nätverksbegränsningar. För konceptets test valde jag Golang eftersom det är det språk jag är mest bekant med och passade väl för denna implementering av många andra skäl, som senare visade sig. Go är enkelt och utvecklas väldigt snabbt; kanaler i Go är utmärkta för att hantera flertrådighet.

Projektet CloudRetro.io – en molnbaserad speltjänst med öppen källkod för retrospel. Projektets mål är att ge traditionella retrospel en så bekväm spelupplevelse som möjligt och att lägga till flerspelarläge.
Du kan bekanta dig med projektet här: https://github.com/giongto35/cloud-game.

Funktionalitet för CloudRetro

För att visa hela kraften i molnspel används retrospel i CloudRetro. Detta gör att man kan få en mängd unika spelupplevelser.

Spelbarhet
- Omedelbar spelstart vid öppning av sidan; ingen nedladdning eller installation behövs
- Fungerar i mobilwebbläsare, så ingen programvara behövs för att köra det
Spelsessioner kan delas mellan flera enheter och lagras i molnet för nästa inloggning
Spelet kan streamas, och flera användare kan spela det direkt:
- Crowdplay à la TwitchPlayPokemon, bara mer plattformsövergripande och mer realtidsanpassat
- Offlinespel online. Många användare kan spela utan nätverksinställningar. I Samurai Shodown kan nu 2 spelare spela över CloudRetro-nätverket
Demoversion av ett flerspelarläge online-spel på olika enheter
Infrastruktur
Krav och teknologiska stackar
Nedanför finns en lista över krav som jag satte innan projektet startade.
1. En spelare
Detta krav kan verka oviktigt och uppenbart här, men det är en av mina centrala insikter, det gör att molnspel kan hålla sig så långt borta från traditionella strömningstjänster som möjligt. Om vi fokuserar på enspelarlägen kan vi undvika behovet av en centraliserad server eller CDN, eftersom vi inte behöver sända till massorna. Istället för att ladda upp strömmar till en mottagande server eller skicka paket till en centraliserad WebSocket-server, överförs tjänstestreamar direkt till användarna genom en peer-to-peer WeRTC-anslutning.
2. Låg latens mediastreaming
När jag läser om Stadia stöter jag ofta på nämningar av WebRTC i vissa artiklar. Jag har förstått att WebRTC är en lysande teknologi, och den passar perfekt för användning inom molnspel. WebRTC är ett projekt som erbjuder webbläsare och mobilapplikationer realtidskommunikation via ett enkelt API. Det möjliggör en peer-to-peer-anslutning, optimerad för media och har inbyggda standardkodekar som VP8 och H264.
Jag prioriterade att säkerställa en så bekväm användarupplevelse som möjligt, snarare än att bevara hög grafik. Vissa förluster är acceptabla i algoritmen. Google Stadia har ett extra steg för att minska bildstorleken på servern, och bilderna skalas upp till högre kvalitet innan de överförs till peer-noder.
3. Distribuerad infrastruktur med geografisk routing
Oavsett hur optimerad komprimeringsalgoritmen och koden är, är nätverket fortfarande den avgörande faktorn som mest bidrar till latens. Arkitekturen måste ha en mekanism för att koppla ihop den server som är närmast användaren för att minska överföringstiden (RTT). Arkitekturen bör ha en koordinator och flera streamingservrar spridda över hela världen: västra USA, östra USA, Europa, Singapore, Kina. Alla streamingservrar måste vara helt isolerade. Systemet kan justera sin distribution när en server går med i nätverket eller lämnar det. På så sätt, vid hög trafik, gör ytterligare servrar det möjligt att utföra horisontell skalning.
4. webbläsarkompatibilitet
Molnspel framträder i bästa ljus när de kräver minimalt av användarna. Detta betyder att det finns möjlighet att spela direkt i webbläsaren. Webbläsare hjälper till att göra spelupplevelsen så bekväm som möjligt för användarna, utan att de behöver installera programvara eller hårdvara. Webbläsare hjälper också till att säkerställa plattformsoberoende för mobila och desktopversioner. Lyckligtvis stöds WebRTC utmärkt i olika webbläsare.
5. Tydlig separation av spelgränssnitt och tjänst
Jag betraktar molnspeltjänsten som en plattform. Varje användare ska kunna ansluta vad som helst till plattformen. Just nu har jag integrerat LibRetro med molnspeltjänsten, eftersom LibRetro erbjuder ett vackert gränssnitt för spelemulatorer för retrospel som SNES, GBA, PS.
6. Rum för flerspelare, crowd play och djup-länkar (deep-link) till spelet
CloudRetro stöder många nya spelupplevelser, såsom CrowdPlay och Online Multiplayer för retrospel. Om flera användare öppnar samma djup-länk på olika datorer, kommer de att se samma pågående spel och till och med kunna gå med i det.
Dessutom lagras spelens tillstånd i molnlagring. Detta gör att användare kan fortsätta spela när som helst på vilken annan enhet som helst.
7. Horisontell skalning
Precis som alla SAAS-tjänster måste molnspel idag utformas för att vara horisontellt skalbara. Designen "koordinator-arbetare" gör det möjligt att lägga till fler arbetare för att hantera högre trafik.
8. Ingen bindning till ett enda moln
Infrastructure CloudRetro finns på olika molnleverantörer (Digital Ocean, Alibaba, anpassad leverantör) för olika regioner. Jag aktiverar containerdrift med Docker för infrastrukturen och konfigurerar nätverksinställningarna med hjälp av bash-skript för att undvika beroende av en enda molnleverantör. Genom att kombinera detta med NAT Traversal i WebRTC kan vi uppnå flexibilitet för att distribuera CloudRetro på vilken molnplattform som helst och till och med på användarmaskiner.
Arkitekturdesign
Arbetare: (eller strömserver, som nämnts ovan) multiplicerar spelen, kör den kodande pipeline och överför den kodade media till användarna. Instanser av arbetaren är spridda över hela världen, och varje arbetare kan hantera flera användarsessioner samtidigt.
Koordinator: ansvarar för att koppla en ny användare till den mest lämpliga arbetaren för strömning. Koordinatorn interagerar med arbetarna via WebSocket.
Lagring av speltillstånd: ett centralt fjärrlager för alla spelets tillstånd. Detta lager tillhandahåller viktiga funktioner, såsom fjärrspara/ladda.

Översiktlig arkitektur för CloudRetro
Användarscenario
När en ny användare öppnar CloudRetro i steg 1 och 2, som visas nedan, begärs koordinatorn tillsammans med en lista över tillgängliga arbetare på första sidan. Därefter, i steg 3, beräknar klienten fördröjningarna för alla kandidater med hjälp av en HTTP ping-förfrågan. Denna lista med fördröjningar skickas sedan tillbaka till koordinatorn så att denne kan avgöra den mest lämpliga arbetaren för att betjäna användaren. I steg 4 nedan skapats ett spel. En strömförbindelse via WebRTC etableras mellan användaren och den tilldelade arbetaren.

Användarscenario efter åtkomst
Vad finns inuti arbetaren
Spel- och streamingspipeline lagras isolerat inom workern och utbyter information där genom ett gränssnitt. För närvarande sker denna koppling genom att överföra data i minnet via Golang-kanaler i samma process. Nästa mål är segmentering, dvs. oberoende körning av spelet i en annan process.

Interaktionen mellan workerkomponenter
Huvudkomponenter:
- WebRTC: klientkomponenten som tar emot användarinmatning och skickar kodad media från servern.
- Spelemuator: spelskomponenten. Tack vare biblioteket Libretro kan systemet köra spelet inom samma process och internt fånga media och indataflöde.
- In-game frames fångas och skickas till kodaren.
- Bild-/ljudkodare: kodningspipeline som tar emot mediaprogram, kodar dem i bakgrunden och skickar ut kodade bilder/ljud.
Implementering
CloudRetro förlitar sig på WebRTC som en huvudteknologi, så innan jag dyker djupare in i implementeringen i Golang, ville jag berätta om själva WebRTC. Det är en fantastisk teknik som har hjälpt mig att uppnå en datastreamingfördröjning på endast en bråkdel av en sekund.
WebRTC
WebRTC är designat för att säkerställa högkvalitativa peer-to-peer-anslutningar i inbyggda mobilapplikationer och webbläsare med hjälp av enkla API:er.
NAT Traversal
WebRTC är känt för sin funktionalitet NAT Traversal. WebRTC är avsett för peer-to-peer-kommunikation. Dess syfte är att hitta den mest lämpliga direkta vägen, undvika NAT-gateways och brandväggar för peer-to-peer-kommunikation genom en process som kallas ICE. Inom ramen för denna process hittar WebRTC API din offentliga IP-adress med hjälp av STUN-servrar och omdirigerar den till en retransmission server (TURN), när en direkt anslutning inte kan etableras.
Men CloudRetro utnyttjar inte helt denna funktion. Dess peer-to-peer-anslutningar existerar inte mellan användare, utan mellan användare och molnservrar. Serverdelen av modellen har färre begränsningar för direkt kommunikation än vanliga användarenheter. Detta gör det möjligt att förhandsöppna inkommande portar eller använda offentliga IP-adresser direkt, eftersom servern inte ligger bakom NAT.
Tidigare ville jag förvandla projektet till en plattform för spridning av spel för Cloud Gaming. Idén var att låta spelutvecklare tillhandahålla spel och strömresurser. Användarna skulle interagera direkt med leverantörerna. I ett sådant decentraliserat format är CloudRetro bara en plattform för att koppla externa strömresurser till användarna, vilket gör det mer skalbart när det inte längre har hosting på sig. Rollen av WebRTC NAT Traversal är mycket viktig för att underlätta initieringen av en peer-to-peer-anslutning på externa strömresurser, vilket förenklar kopplingen av skaparen till nätverket.
Videokomprimering
Videokomprimering är en oumbärlig del av pipeline som i hög grad bidrar till smidigheten i strömningen. Även om det inte är nödvändigt att känna till alla detaljer om videokodning i VP8/H264, så hjälper förståelsen av konceptet att hantera inställningarna för strömmande video, felsöka oväntat beteende och justera latens.
Videokomprimering för en strömningstjänst är en komplex uppgift eftersom algoritmen måste garantera att den totala kodningstiden + överföringstid + avkodningstid är så liten som möjligt. Dessutom måste kodningsprocessen vara konsekvent och kontinuerlig. Vissa ömsesidiga uppoffringar vid kodning är inte tillämpliga – till exempel kan vi inte föredra en lång kodningstid framför en mindre filstorlek och avkodningstid, eller använda inkonsekvent komprimering.
Idén med videokomprimering är att utesluta onödiga bitar information och samtidigt behålla en acceptabel noggrannhetsnivå för användarna. Förutom att koda individuella stillbilder, gör algoritmen slutsatser för den aktuella bilden baserat på föregående och nästa bild, så att endast deras skillnader sänds. Som visas i exemplet med Pacman, skickas endast de differenspunkterna.

Jämförelse av videobilder med Pacman-exemplet
Ljudkomprimering
På samma sätt hoppar ljudkomprimeringsalgoritmen över data som inte kan uppfattas av människan. Opus är för närvarande ljudkodeken med den bästa prestandan. Den är utformad för att skicka ljudvågor över protokoll för ordnad datagram, såsom RTP (Real Time Transport Protocol – protokoll för realtidsöverföring av trafik). Den har lägre fördröjning än mp3 och aac, och kvaliteten är högre. Fördröjningen ligger vanligtvis runt 5~66,5 ms.
Pion, WebRTC i Golang
Pion är ett open source-projekt som implementerar WebRTC i Golang. Istället för att vanligtvis kapsla in native C++ WebRTC-bibliotek är Pion en nativ Golang-implementation av WebRTC med bättre prestanda, integration med Go och versionskontroll av WebRTC-protokoll.
Biblioteket erbjuder också datastreaming med många utmärkta inbyggda moduler med en fördröjning på mindre än en sekund. Det har sin egen implementation av STUN, DTLS, SCTP, etc., och vissa experiment med QUIC och WebAssembly. Själva denna open source-bibliotek är verkligen en bra lärandekälla med utmärkt dokumentation, implementation av nätverksprotokoll och intressanta exempel.
Pion-communityt, lett av en mycket passionerad skapare, är ganska livligt, och det pågår många kvalitativa diskussioner om WebRTC. Om du är intresserad av den här teknologin, gå med i http://pion.ly/slack – du kommer att lära dig mycket nytt.
Att skriva CloudRetro i Golang

Implementering av en arbetsprocess i Go
Go-kanaler i praktiken
Med den eleganta designen av Go-kanaler förenklas problem med händelseströmning och parallellitet avsevärt. Som på diagrammet arbetar flera komponenter parallellt i olika GoRoutines. Varje komponent hanterar sitt tillstånd och kommunicerar via kanaler. Go:s selektiva påstående tvingar varje atomär händelse att hanteras vid varje given tidpunkt i spelet (game tick). Det betyder att en sådan design inte kräver låsning. Till exempel, när en användare sparar, krävs en fullständig snapshot av spelets tillstånd. Detta tillstånd måste förbli kontinuerligt under inloggningen tills sparandet är slutfört. Under varje game tick kan backend endast bearbeta antingen sparande- eller inloggningsoperationer, vilket gör processen trådsäker.
```
func (e *gameEmulator) gameUpdate() {
for {
	select {
		case <-e.saveOperation:
			e.saveGameState()
		case key := <-e.input:
			e.updateGameState(key)
		case <-e.done:
			e.close()
			return
	}
    }
}
```
Fan-in / Fan-out
Denna Golang-mall passar perfekt för mitt användningsfall med CrowdPlay och flera spelare. Genom att följa denna mall samlas all användarinmatning i ett rum i en central ingångskanal. Spelmedia distribueras sedan till alla användare i rummet. På så sätt uppnår vi delning av speltillstånd mellan flera spel-sessioner av olika användare.

Synkronisering mellan olika sessioner
Nackdelar med Golang
Golang är inte perfekt. Kanaler är långsamma. Jämfört med lås är Go-kanaler ett enklare sätt att hantera parallella och strömmade händelser, men kanalen ger inte den bästa prestandan. Under kanalen finns en komplicerad låslogik. Därför har jag gjort vissa justeringar i implementationen genom att återanvända lås och atomära värden för att optimera prestanda.
Dessutom är garbage collectorn i Golang okontrollerad, vilket ibland leder till misstänkt långa pauser. Detta stör starkt driften av realtidsapplikationer.
CGO
Projektet använder ett befintligt VP8/H264-bibliotek i Golang med öppen källkod för komprimering av media och Libretro för spel-emulatorer. Alla dessa bibliotek är helt enkelt omslag av C-biblioteket i Go med användning av CGO. Några av nackdelarna är listade i detta inlägg av Dave Cheney. Problematiken jag stötte på:
- oförmågan att fånga krascher i CGO, även med hjälp av Golang RecoveryCrash;
- oförmågan att identifiera flaskhalsar i prestanda när vi inte kan upptäcka detaljerade problem i CGO.
Slutsats
Jag har nått mitt mål – att förstå molnbaserade speltjänster och skapa en plattform som hjälper mig att spela nostalgiska retrospel med mina vänner online. Att skapa detta projekt skulle vara omöjligt utan Pion-biblioteket och Pion-gemenskapens stöd. Jag är extremt tacksam för dess intensiva utveckling. De enkla API:erna som tillhandahålls av WebRTC och Pion möjliggjorde en smidig integration. Min första konceptbevis lanserades samma vecka, trots att jag på förhand inte kände till peer-to-peer-anslutningar (P2P).
Trots integrations enkelhet är P2P-strömning verkligen ett mycket komplext område inom datavetenskap. Det måste hantera komplexiteten i fleråriga nätverksarkitekturer, såsom IP och NAT, för att skapa en peer-to-peer session. Under arbetet med detta projekt har jag samlat mycket värdefull kunskap om nätverk och prestandaoptimering, så jag rekommenderar alla att prova att bygga P2P-produkter med hjälp av WebRTC.
CloudRetro hanterar alla användningsscenarier som jag förväntade mig, utifrån min synvinkel som retro-gamer. Men jag tror att det finns många områden i projektet som jag kan förbättra, såsom att göra nätverket mer pålitligt och effektivt, säkerställa högre spelgrafik eller möjligheten att dela spel mellan användare. Jag arbetar hårt med detta. Vänligen följ projekt och stöd det om du gillar det.