WebRTC-n kode irekiko hodeiko jokoak: p2p, jokalari anitzeko, zero latentzia

Softwarea zerbitzu gisa, azpiegitura zerbitzu gisa, plataforma zerbitzu gisa, komunikazio plataforma zerbitzu gisa, bideokonferentzia zerbitzu gisa, zer gertatzen da hodeiko jokoarekin zerbitzu gisa? Dagoeneko hainbat saiakera egin dira hodeiko jokoak (Cloud Gaming) sortzeko, Google-k abian jarri berri duen Stadia adibidez. Estadioak ez da berria WebRTC-n, baina beste batzuek WebRTC modu berean erabil dezakete?

Thanh Nguyenek aukera hau bere kode irekiko CloudRetro proiektuan probatzea erabaki zuen. CloudRetro Pion-en oinarritzen da, herrikoia Go-n oinarritutako WebRTC liburutegia (eskerrik asko Erakutsita Pion garapen-taldearen eskutik, artikulu hau prestatzeko laguntzagatik). Artikulu honetan, Thanh-ek bere proiektuaren arkitekturaren ikuspegi orokorra eskaintzen du, eta zer gauza baliagarri ikasi zituen eta bere lanean zehar zein erronkei buruz ere hitz egiten du.

Sarrera

Iaz, Google-k Stadia iragarri zuenean, txundituta geratu nintzen. Ideia hain da berezia eta berritzailea, ezen etengabe galdetzen niola hori nola posible zen lehendik zegoen teknologiarekin. Gai hau hobeto ulertzeko nahiak kode irekiko hodeiko joko baten nire bertsioa sortzera bultzatu ninduen. Emaitza, besterik gabe, zoragarria izan zen. Jarraian, nire urtea lantzeko prozesua partekatu nahiko nuke proiektua.

TLDR: diapositiba laburren bertsioa nabarmenduekin

Zergatik hodeiko jokoak etorkizuna dira

Uste dut Cloud Gaming laster jokoen hurrengo belaunaldia ez ezik, informatikaren beste arlo batzuk ere bihurtuko direla. Hodeiko jokoak bezero/zerbitzari ereduaren gailurra da. Eredu honek backend kudeaketa maximizatzen du eta frontend lana minimizatzen du jokoaren logika urruneko zerbitzari batean ostatatuz eta bezeroari irudiak/audioak transmitituz. Zerbitzariak prozesamendu astuna egiten du, beraz, bezeroa hardwarearen mugen menpe egon ez dadin.

Funtsean, Google Stadiak jolasten uzten dizu AAA jokoak (hau da, goi mailako joko arrakastatsuak) YouTube bezalako interfaze batean. Metodologia bera lineaz kanpoko beste aplikazio astun batzuetan aplika daiteke, hala nola, sistema eragilea edo 2D/3D diseinu grafikoa, etab. beraz, koherentziaz exekutatu ditzakegu zehaztapen baxuko gailuetan hainbat plataformatan.

Teknologia honen etorkizuna: Imajinatu Microsoft Windows 10 Chrome arakatzailean abiaraziko balu?

Hodeiko jokoak teknikoki zaila da

Jolasak erabiltzailearen erantzuna etengabe eta azkarra behar den eremu bakan horietako bat da. Tarteka orrialde batean klik egitean 2 segundoko atzerapena aurkitzen badugu, hori onargarria da. Zuzeneko bideo-korronteek segundo batzuk atzeratu ohi dute, baina hala ere zentzuzko erabilgarritasuna eskaintzen dute. Hala ere, jokoa maiz 500 ms atzeratzen bada, ezin da jolastu. Gure helburua oso latentzia baxua lortzea da, sarreraren eta komunikabideen arteko tartea ahalik eta txikiena izan dadin. Hori dela eta, bideo-streamingaren ikuspegi tradizionala ez da aplikagarria hemen.

Hodei-jokoen txantiloia

CloudRetro kode irekiko proiektua

Hodeiko joko baten proba-lagin bat sortzea erabaki nuen, sare-murrizketa hain estuekin hori guztia posible zen ikusteko. Kontzeptuaren frogarako Golang aukeratu nuen gehien ezagutzen nuen hizkuntza zelako eta inplementazio honetarako ondo egokitzen zitzaidalako beste arrazoi askorengatik, geroago ezagutu nuen bezala. Go sinplea da eta oso azkar garatzen da; Go-ko kanalak bikainak dira multithreading kudeatzeko.

Proiektu CloudRetro.io retro-jokoetarako kode irekiko hodeiko joko-zerbitzua da. Proiektuaren helburua retro joko tradizionaletara joko-esperientzia erosoena ekartzea eta jokalari anitzekoa gehitzea da.
Proiektuari buruz gehiago jakin dezakezu hemen: https://github.com/giongto35/cloud-game.

CloudRetro funtzionaltasuna

CloudRetro-k retro jokoak erabiltzen ditu hodeiko jokoen indarra erakusteko. Horrek joko-esperientzia paregabe asko lortzeko aukera ematen dizu.

• Jokoaren eramangarritasuna
  • Orrialde bat irekitzean berehalako erreprodukzioa; ez da deskargatu edo instalaziorik behar
  • Arakatzaile mugikor batean funtzionatzen du, beraz, ez da softwarerik behar hura exekutatzeko

• Joko saioak hainbat gailutan parteka daitezke eta hodeian gorde daitezke saioa hasten duzun hurrengoan
• Jokoa erreproduzitu daiteke, edo hainbat erabiltzailek aldi berean jokatu dezakete:
  • Crowdplay TwitchPlayPokemon bezalakoa, plataforma anitzeko eta denbora errealekoagoa baino ez
  • Lineaz kanpoko jokoak linean. Erabiltzaile askok sarerik konfiguratu gabe jolastu dezakete. Samurai Shodown orain 2 jokalarik jokatu dezakete CloudRetro sarearen bidez

  
  Lineako jokalari anitzeko jokoaren demo bertsioa gailu ezberdinetan

  Azpiegitura

  Baldintzak eta teknologia pila

  Jarraian proiektua hasi aurretik ezarri ditudan eskakizunen zerrenda dago.

  1. Jokalari bat
  Baldintza hau ez dirudi hemen garrantzitsuegia edo agerikoa dena, baina nire funtsezko ondorioetako bat da, hodeiko jokoak streaming zerbitzu tradizionaletatik ahalik eta urrunen egoteko aukera ematen du. Jokalari bakarreko joko batean zentratzen bagara, zerbitzari edo CDN zentralizatu bat ken dezakegu, ez baitugu jendearengana bidali beharrik. Korronteak konketa-zerbitzari batera igo edo WebSocket zerbitzari zentralizatu batera paketeak pasa beharrean, zerbitzu-korronteak erabiltzaileari zuzenean ematen zaizkio peer-to-peer WebRTC konexio baten bidez.

  2. Latentzia baxuko multimedia-jarioa
  Stadia-ri buruz irakurtzen, askotan ikusten dut WebRTC aipatzen artikulu batzuetan. Konturatu nintzen WebRTC teknologia bikaina dela eta hodeiko jokoetan erabiltzeko ezin hobea dela. WebRTC web arakatzaileei eta aplikazio mugikorrei denbora errealeko komunikazioa eskaintzen dien proiektua da, API sinple baten bidez. Peer-to-peer konektibitatea eskaintzen du, multimediarako optimizatuta dago eta kodek estandarrak barneratuta ditu, hala nola VP8 eta H264.

  Erabiltzaileen esperientzia onena ziurtatzea lehenetsi nuen kalitate handiko grafikoak mantentzea baino. Algoritmoan galera batzuk onargarriak dira. Google Stadiak zerbitzariko irudiaren tamaina murrizteko urrats gehigarri bat du, eta fotogramak kalitate handiago batera igotzen dira kideei transmititu aurretik.

  3. Bideratze geografikoa duten azpiegitura banatuak
  Konpresio-algoritmoa eta kodea zein optimizatuta dauden arren, sarea da oraindik latentzian gehien laguntzen duen faktore erabakigarria. Arkitekturak erabiltzailearengandik hurbilen dagoen zerbitzaria parekatzeko mekanismo bat izan behar du, joan-etorriko denbora (RTT) murrizteko. Arkitekturak koordinatzaile 1 eta hainbat streaming zerbitzari izan behar ditu mundu osoan banatuta: AEBetako Mendebaldea, AEBetako Ekialdea, Europa, Singapur, Txina. Streaming zerbitzari guztiak guztiz isolatuta egon behar dira. Sistemak bere banaketa doi dezake zerbitzari bat sarera sartzen edo irteten denean. Horrela, trafiko handiarekin, zerbitzari osagarriak gehitzeak eskala horizontala ahalbidetzen du.

  4. Arakatzailearen bateragarritasuna
  Hodeiko jokoak bere onenean daude erabiltzaileei gutxien eskatzen dienean. Horrek esan nahi du arakatzaile batean exekutatu daitekeela. Arakatzaileek joko-esperientzia ahalik eta erosoena izaten laguntzen dute erabiltzaileentzat, softwarea eta hardwarea instalatu gabe. Arakatzaileek plataforma anitzeko funtzionaltasuna eskaintzen dute mugikorren eta mahaigaineko bertsioen artean. Zorionez, WebRTC ondo onartzen da hainbat arakatzailetan.

  5. Jokoaren interfazea eta zerbitzuaren bereizketa garbia
  Hodeiko joko-zerbitzua plataforma gisa ikusten dut. Guztiek plataformara edozer konektatu ahal izan behar dute. Orain integratu naiz LibRetro hodeiko joko-zerbitzuarekin, LibRetro-k joko-emulatzaile interfaze ederra eskaintzen duelako SNES, GBA, PS bezalako retro jokoetarako.

  6. Jokalari anitzeko, jendetza jolasteko eta jokoarekin kanpoko lotura (esteka sakona) aretoak
  CloudRetro-k joko berri asko onartzen ditu, hala nola CrowdPlay eta Online MultiPlayer retro jokoetarako. Hainbat erabiltzailek deep-link bera ordenagailu ezberdinetan irekitzen badute, exekutatzen ari den joko bera ikusiko dute eta bertan sartzeko aukera ere izango dute.

  Gainera, joko-egoerak hodeiko biltegian gordetzen dira. Horri esker, erabiltzaileek edozein unetan beste edozein gailutan jolasten jarrai dezakete.

  7. Eskalatze horizontala
  Gaur egun edozein SAAS bezala, hodeiko jokoak horizontalki eskalagarriak izateko diseinatu behar dira. Koordinatzaile-langilearen diseinuari esker, langile gehiago gehi ditzakezu trafiko gehiago zerbitzatzeko.

  8. Ez dago konexiorik hodei batekin
  CloudRetro-ren azpiegitura hodei-hornitzaile ezberdinetan (Ozeano Digitala, Alibaba, hornitzaile pertsonalizatua) ostatatuta dago eskualde ezberdinetarako. Docker edukiontzi batean exekutatzen ari naiz azpiegiturarako eta sarearen ezarpenak konfiguratzen ditut bash script bat erabiliz, hodeiko hornitzaile bakarrean blokeatuta ez geratzeko. Hau WebRTC-n NAT Traversal-ekin konbinatuz, CloudRetro edozein hodeiko plataformatan eta baita edozein erabiltzaileren makinetan ere zabaltzeko malgutasuna izan dezakegu.

  Diseinu arkitektonikoa

  Langilea: (edo goian aipatutako streaming zerbitzariak) jokoak biderkatzen ditu, kodeketa kanalizazioa exekutatzen du eta kodetutako euskarriak erabiltzaileei transmititzen dizkie. Langile-instantziak mundu osoan banatzen dira, eta langile bakoitzak hainbat erabiltzaile-saio kudeatu ditzake aldi berean.

  Koordinatzailea: erabiltzaile berria streaming-erako langile egokienarekin parekatzeaz arduratzen da. Koordinatzaileak langileekin elkarreragiten du WebSocket bidez.

  Jokoaren egoera biltegiratzea: urruneko biltegiratze zentrala joko-egoera guztietarako. Biltegiratze honek funtzio garrantzitsuak eskaintzen ditu, esate baterako, urruneko gorde/karga.

  
  CloudRetro-ren goi-mailako arkitektura

  Script pertsonalizatua

  Erabiltzaile berri batek CloudRetro irekitzen duenean beheko irudian erakusten diren 1. eta 2. urratsetan, koordinatzailea lehen orrialdera eskatzen da eskuragarri dauden langileen zerrendarekin batera. Horren ostean, 3. urratsean bezeroak hautagai guztien atzerapenak kalkulatzen ditu HTTP ping eskaera erabiliz. Ondoren, atzerapen-zerrenda hori koordinatzaileari bidaltzen zaio, erabiltzaileari zerbitzua emateko langile egokiena zein den erabaki dezan. Beheko 4. urratsak jokoa sortzen du. WebRTC streaming konexioa ezartzen da erabiltzailearen eta esleitutako langilearen artean.
  
  Erabiltzaile-scripta sarbidea lortu ondoren

  Langile baten barruan dagoena

  Jolasak eta streaming kanalizazioak langilearen barruan gordetzen dira isolatuta eta bertan informazioa trukatzen dute interfazearen bidez. Gaur egun, komunikazio hau memorian dauden datuak transferituz egiten da Golang kanalak prozesu berean. Hurrengo helburua segregazioa da, hau da. jokoaren abiarazte independentea beste prozesu batean.

  
  Langilearen osagaien elkarrekintza

  Osagai nagusiak:

  • WebRTC: erabiltzaileen sarrera onartzen duen eta zerbitzaritik kodetutako euskarria ateratzen duen bezero osagaia.
  • Joko emuladorea: jokoaren osagaia. Libretro liburutegiari esker, sistemak gai da jokoa prozesu berean exekutatu eta barnean multimedia eta sarrera korrontea atzematea.
  • Joko barruko fotogramak harrapatu eta kodetzailera bidaltzen dira.
  • Irudi/Audio kodetzailea: multimedia-markoak hartzen dituen, atzeko planoan kodetzen dituen eta kodetutako irudiak/audioa ateratzen duen kodetze kanalizazioa.

  Inplementazioa

  CloudRetro-k WebRTC oinarritzen da bere bizkarrezur-teknologia gisa, beraz, Golang-en ezarpenaren xehetasunetan murgildu aurretik, WebRTC berari buruz hitz egitea erabaki nuen. Teknologia harrigarria da, eta asko lagundu dit segundo azpiko latentzia lortzen datuak erreproduzitzeko.

  WebRTC

  WebRTC kalitate handiko peer-to-peer konexioak eskaintzeko diseinatuta dago jatorrizko aplikazio mugikorretan eta arakatzaileetan API sinpleak erabiliz.

  NAT zeharkaldia

  WebRTC bere NAT Traversal funtzionalitateagatik ezaguna da. WebRTC peer-to-peer komunikaziorako diseinatuta dago. Bere helburua bide zuzen egokiena aurkitzea da, NAT atebide eta suebakiak saihestuz peer-to-peer komunikaziorako, izeneko prozesu baten bidez. ICE. Prozesu honen baitan, WebRTC APIek STUN zerbitzariak erabiliz zure IP helbide publikoa aurkitzen dute eta errelebo zerbitzarira birbidaltzen dute (TXANDA) konexio zuzena ezarri ezin denean.

  Hala ere, CloudRetro-k ez du funtzio hau guztiz ustiatzen. Bere peer-to-peer konexioak ez dira erabiltzaileen artean existitzen, erabiltzaileen eta hodeiko zerbitzarien artean baizik. Ereduaren zerbitzariaren aldean erabiltzailearen gailu arrunt batek baino zuzeneko komunikazio murrizketa gutxiago ditu. Horrek sarrerako portuak aldez aurretik ireki ditzakezu edo IP helbide publikoak zuzenean erabiltzeko aukera ematen du, zerbitzaria NAT atzean ez baitago.

  Aurretik, proiektua Cloud Gaming-en jokoak banatzeko plataforma bihurtu nahi nuen. Ideia zen joko sortzaileei jokoak eta streaming baliabideak eskaintzea. Eta erabiltzaileek hornitzaileekin zuzenean interakzionatuko lukete. Modu deszentralizatu honetan, CloudRetro hirugarrenen streaming baliabideak erabiltzaileekin konektatzeko esparru bat besterik ez da, ostatatuta ez dagoenean eskalagarriagoa bihurtuz. WebRTC NAT Traversal-en eginkizuna hemen oso garrantzitsua da hirugarrenen streaming-baliabideetan peer-to-peer konexio hasieratzea errazteko, sortzailea sarera konektatzea erraztuz.

  Bideo-konpresioa

  Bideo-konpresioa kanalizazioaren ezinbesteko zati bat da eta asko laguntzen du fluxu leuna lortzen. VP8/H264 bideo-kodeketaren xehetasun guztiak ezagutzea beharrezkoa ez den arren, kontzeptuak ulertzeak bideoaren abiadura-aukerak ulertzen, ustekabeko portaeran arazketan eta latentzia doitzen lagunduko dizu.

  Streaming zerbitzu baterako bideoa konprimitzea zaila da, algoritmoak kodetze-denbora osoa + sarearen transmisio-denbora + deskodetze-denbora ahalik eta txikiena dela ziurtatu behar duelako. Gainera, kodetze prozesuak koherentea eta etengabea izan behar du. Kodetze-konpromiso batzuk ez dira aplikatzen; adibidez, ezin dugu kodetze-denbora luzea hobetu fitxategi-tamaina eta deskodetze-denbora txikiagoak baino, edo konpresio koherentea erabili.

  Bideo-konpresioaren atzean dagoen ideia alferrikako informazio zatiak ezabatzea da, erabiltzaileentzako zehaztasun-maila onargarria mantenduz. Irudi estatiko indibidualak kodetzeaz gain, algoritmoak aurreko eta hurrengoetatik uneko fotograma ondorioztatzen du, beraz, haien aldea bakarrik bidaltzen da. Pacman-en adibidean ikus daitekeenez, puntu diferentzialak soilik transmititzen dira.

  
  Bideo fotogramak alderatzea Pacman adibide gisa erabiliz

  Audio-konpresioa

  Era berean, audio-konpresioaren algoritmoak gizakiek hauteman ezin dituzten datuak baztertzen ditu. Opus da gaur egun errendimendurik onena duen audio-kodeka. Audio-uhin bat transmititzeko diseinatuta dago datagrama protokolo ordenatu baten bidez, hala nola RTP (Real Time Transport Protocol). Bere latentzia mp3 eta aac baino txikiagoa da, eta kalitatea handiagoa da. Latentzia 5 ~ 66,5 ms ingurukoa izan ohi da.

  Pion, WebRTC Golang-en

  Peoia WebRTC Golangera ekartzen duen kode irekiko proiektu bat da. C++ WebRTC liburutegi natiboen ohiko bilgarriaren ordez, Pion WebRTCren jatorrizko Golang inplementazioa da, WebRTC protokoloetan errendimendu hobea, Go integrazioa eta bertsio-kontrola dituena.

  Liburutegiak erreprodukzioa ere ahalbidetzen du integrazio handi askorekin, segundo azpiko latentziarekin. STUN, DTLS, SCTP, etab. inplementazio propioa du. eta QUIC eta WebAssembly-rekin esperimentu batzuk. Kode irekiko liburutegi hau bera ikasteko baliabide oso ona da, dokumentazio bikainarekin, sareko protokoloen inplementazioekin eta adibide politekin.

  Pion komunitatea, oso sortzaile sutsu batek zuzentzen duena, nahiko bizia da, WebRTCri buruz kalitatezko eztabaida asko izaten direlarik. Teknologia hau interesatzen bazaizu, sartu http://pion.ly/slack - gauza berri asko ikasiko dituzu.

  CloudRetro idazten Golang-en

  
  Langile bat ezartzea Go-n

  Joan Kanalak Ekintzan

  Go-ren kanalaren diseinu ederrari esker, gertaeren streaming eta aldibereko arazoak asko errazten dira. Diagraman bezala, GoRoutine ezberdinek hainbat osagai dituzte paraleloan exekutatzen. Osagai bakoitzak bere egoera kudeatzen du eta kanalen bidez komunikatzen da. Golang-en baieztapen selektiboak jokoan den bakoitzean gertaera atomiko bat prozesatzera behartzen du (jokoaren tick). Horrek esan nahi du diseinu honetarako ez dela blokeorik behar. Adibidez, erabiltzaile batek gordetzen duenean, jokoaren egoeraren argazki osoa behar da. Egoera honek etengabe jarraitu behar du, saioa hasita gordetzea amaitu arte. Jokoaren marka bakoitzean, backend-ak gorde edo sarrera eragiketa bat bakarrik kudeatu dezake, prozesuaren haria seguru bihurtuz.

  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

  Golang txantiloi hau ezin hobeto egokitzen da nire CrowdPlay eta Multiple Player erabilera kasua. Eredu horri jarraituz, gela bateko erabiltzaileen sarrera guztiak sarrerako kanal zentralean sartzen dira. Ondoren, jokoaren euskarria gela berean dauden erabiltzaile guztiei zabaltzen zaie. Horrela, erabiltzaile ezberdinen hainbat joko-saioren artean joko-egoeraren banaketa lortzen dugu.

  
  Saio ezberdinen arteko sinkronizazioa

  Golang-en desabantailak

  Golang ez da perfektua. Kanala motela da. Blokeatzearekin alderatuta, Go kanala aldibereko eta haridun gertaerak kudeatzeko modu errazagoa da, baina kanalak ez du errendimendurik onena ematen. Kanalaren azpian blokeo logika konplexua dago. Beraz, ezarpenean doikuntza batzuk egin nituen, blokeoak eta balio atomikoak berriro aplikatuz kanalak ordezkatzean errendimendua optimizatzeko.

  Gainera, Golang-eko zabor-biltzailea kudeatu gabe dago, eta horrek, batzuetan, etenaldi luze susmagarriak eragiten ditu. Horrek asko oztopatzen du denbora errealeko streaming aplikazioarekin.

  COG

  Proiektuak lehendik dagoen kode irekiko Golang VP8/H264 liburutegia erabiltzen du multimedia konpresiorako eta Libretro joko emuladoreetarako. Liburutegi hauek guztiak Go erabiliz C liburutegiaren bilgarriak besterik ez dira COG. Desabantaila batzuk zerrendatzen dira Dave Cheney-ren mezu hau. Aurkitu ditudan arazoak:

  • CGOn istripu bat harrapatzeko ezintasuna, nahiz eta Golang RecoveryCrash-ekin;
  • CGOn arazo zehatzak detektatzeko gai ez garenean errendimendu-botoiak identifikatzea.

  Ondorioa

  Hodeiko joko-zerbitzuak ulertzea eta nire lagunekin linean retro joko nostalgikoetara jolasten lagunduko didan plataforma bat sortzea lortu nuen. Proiektu hau ez zen posible izango Pion liburutegia eta Pion komunitatearen laguntzarik gabe. Oso eskertuta nago bere garapen intentsiboagatik. WebRTC eta Pion-ek eskainitako API sinpleek integrazio ezin hobea bermatzen zuten. Nire lehen kontzeptuaren froga aste horretan bertan kaleratu zen, nahiz eta ez nuen aldez aurretik berdinen arteko komunikazioaren (P2P) ezagutzarik.

  Integratzeko erraztasuna izan arren, P2P streaminga oso arlo konplexua da informatikan. IP eta NAT bezalako aspaldiko sare arkitekturen konplexutasunari aurre egin behar dio parekideen arteko saio bat sortzeko. Proiektu honetan lanean ari nintzen bitartean, sareen eta errendimenduaren optimizazioari buruzko ezagutza baliotsu asko lortu nuen, beraz, guztiei animatzen diet WebRTC erabiliz P2P produktuak eraikitzen saiatzera.

  CloudRetro-k retro-jokalari gisa espero nituen erabilera kasu guztiak betetzen ditu. Hala ere, uste dut hobetu ditzakedan arlo asko daudela proiektuan, hala nola, sarea fidagarriagoa eta eraginkorragoa izatea, kalitate handiagoko joko grafikoak eskaintzea edo erabiltzaileen artean jokoak partekatzeko gaitasuna. Horretan gogor ari naiz lanean. Mesedez, jarraitu proiektua eta lagundu nahi baduzu.

Iturria: www.habr.com