Pilvegaming avatud koodiga WebRTC-l: p2p, mitme mängijaga, null latentsus.

Teenus nagu programm, infrastruktuur nagu teenus, platvorm nagu teenus, kommunikatsiooniplatvorm nagu teenus, videokonverentsid nagu teenus, aga kuidas oleks pilvemängudega kui teenusega? Mitmeid katseid pilvemängude loomiseks (Cloud Gaming) on juba tehtud, näiteks Google'i hiljuti käivitatud Stadia. ei ole WebRTC-d jälgiv algaja., aga kas teised saavad WebRTC-d sama hästi kasutada?

Thanh Nguyen otsustas uurida seda võimalust oma avatud koodiga projektis CloudRetro. CloudRetro põhineb Pionil, populaarsel WebRTC teegil Go põhjal (tänud Shonile Pioni arendajate meeskonnast abi eest selle artikli koostamisel). Antud artiklis annab Thanh ülevaate oma projekti arhitektuurist ning räägib, mida kasulikku ta õppis ja millega väljakutsetega silmitsi seisis.

Sissejuhatus

Eelmisel aastal, kui Google kuulutas välja Stadia, olin ma absoluutselt hämmingus. Idee on nii ainulaadne ja innovatsiooniline, et ma küsisin endalt pidevalt, kuidas see üldse on võimalik olemasolevate tehnoloogiate juures. Soov sügavamalt sellesse teemasse süveneda ajendas mind looma oma versiooni avatud koodiga pilvemängust. Tulemuseks oli lihtsalt fantastiline. Allpool soovin jagada oma aastase projekti.

TLDR: lühike slaidiversioon peamiste punktidega

Miks on pilvemängude tulevik

Usun, et pilvemängud saavad peagi uueks põlvkonnaks mitte ainult mängude, vaid ka muudes infotehnoloogia valdkondades. Pilvemängud on klient/server mudeli tipp. Selline mudel maksimeerib tagapaneeli juhtimise ja minimaalselt vähendab esipaneeli tööd, paigutades mängu loogika kaugs serverisse ning edastades pilte/heli kliendile. Server teostab rasked arvutused, mistõttu klient ei sõltu enam riistvaralistest piirangutest.

Google Stadia võimaldab sisuliselt mängida AAA-mänge (st kõrgekvaliteedilisi mängu või suurtükimängu) erinevatel platvormidel sarnase liidese kaudu nagu YouTube. Sama meetodit saab rakendada ka teistele intensiivsetele offline rakendustele, nagu operatsioonisüsteem või 2D/3D graafiline kujundus jne, et saaksime neid stabiilselt käivitada madala tehnilise spetsifikatsiooniga seadmetes.

Selle tehnoloogia tulevik: kas suudate kujutada, et Microsoft Windows 10 töötab Chrome'i brauseris?

Pilvemängud on tehniliselt keerulised

Mängimine on üks neist haruldastest valdkondadest, kus kasutaja pidev kiire reaktsioon on hädavajalik. Kui aeg-ajalt kohtame leheküljel klikkides 2 sekundi viivitust, ei ole see probleemne. Reaalajas videovood jäävad tavaliselt paar sekundit maha, kuid pakuvad ikkagi piisavat kasutusmugavust. Siiski, kui mäng viibib pidevalt 500 ms, on mängimine lihtsalt võimatu. Meie eesmärk on saavutada äärmiselt madal viivitus, et sisendi ja meedia vahe oleks võimalikult väike. Seetõttu ei ole traditsiooniline lähenemine voogedastusele siin rakendatav.

Üldine pilootmudel pilve mängimiseks

Avatud lähtekoodiga projekt CloudRetro

Otsustasin luua pilve mängimise testversiooni, et kontrollida, kas see on võimalik selliste karmide võrgu piirangute korral. Kontseptsiooni testimiseks valisin Golangi, kuna see on mulle kõige tuttavam keel ja sobib selle rakendamiseks paljuski paremini, nagu selgus hiljem. Go on lihtne ja areneb väga kiiresti; Go kanalid sobivad suurepäraselt mitme lõime juhtimiseks.

Projekt CloudRetro.io – avatud lähtekoodiga pilve mängimise teenus retro-mängude jaoks. Projekti eesmärk on tuua traditsioonilistesse retro-mängudesse kõige mugavam mängukogemus ja lisada mitmikmäng.
Projekti kohta saab lähemalt lugeda siit: https://github.com/giongto35/cloud-game.

CloudRetro funktsionaalsus

CloudRetro demonstreerib pilve mängimise kogu võimet retro-mängude abil. See võimaldab saada palju unikaalseid mängukogemusi.

• Mängu kaasaskantavus
  • Hetkeline mängimine lehe avamisel; laadimist ja installimist ei ole vaja
  • Töötab mobiilibrauseris, seega ei ole käivitamiseks vajalik ühtegi tarkvara

• Mänguseansse saab jagada mitme seadme vahel ja salvestada pilve järgmise sisenemise jaoks
• Mängu saab voogedastada või mängida seda samal ajal mitme kasutajaga:
  • Crowdplay, nagu TwitchPlayPokemon, kuid rohkem platvormidevaheline ja reaalajas
  • Mänge saab mängida ka offline režiimis. Palju mängijaid saavad mängida, ilma et võrk peaks olema seadistatud. CloudRetro's saab nüüd Samurai Shodownis mängida 2 mängijat võrgu kaudu

  
  Mitmikmänguline online mängude demoversioon erinevates seadmetes

  Infrastruktuur

  Nõuded ja tehnoloogia virn

  Allpool on loetelu nõuetest, mille seadsin enne projekti alustamist.

  1. Üks mängija
  See nõue võib alguses tunduda mitte eriti oluline ja ilmselge, kuid see on minu peamine järeldus, et pilvemängud saaksid võimalikult kaugel traditsioonilistest voogedastusteenustest. Kui keskendume ühekohalistele mängudele, saame loobuda tsentraliseeritud serverist või CDN-ist, kuna meil pole vaja edastada vooge massidele. Selle asemel, et vooge laadida kopsakasse serverisse või edastada pakette tsentraliseeritud WebSocket serverisse, saadetakse teenusevood otse kasutajale läbi peer-to-peer WebRTC ühenduse.

  2. Madala latentsusega meediastruktuur
  Lugedes Stadia kohta, satun tihti kokku mõningate artiklite mainimisega WebRTC-st. Mõistsin, et WebRTC on silmapaistev tehnoloogia ning sobib suurepäraselt pilvemängude kasutamiseks. WebRTC on projekt, mis võimaldab veebibrauserid ja mobiilirakendused reaalajas suhtlemist lihtsa API kaudu. See pakub võrguühendust, mis on optimeeritud meedia ja sisaldab sisseehitatud standardkoodekeid, nagu VP8 ja H264.

  Olen eelistanud tagada kasutajatele võimalikult mugava töö, mitte kõrge graafikakvaliteedi säilitamist. Algoritmis on lubatud teatud kaotused. Google Stadia-s on lisasamm pildikvaliteedi vähendamiseks serveris, ja kaadrid skaleeritakse enne edastamist võrguühenduse sõlmedele kõrgemale kvaliteedile.

  3. Jagatud infrastruktuur geograafilise marsruudiga
  Ükskõik kui optimeeritud ka algoritm on, jääb võrk ikkagi määravaks teguriks, mis kõige rohkem panustab latentsusesse. Arhitektuuril peab olema mehhanism, et siduda lähim kasutajale server, et vähendada edastusaega (RTT). Arhitektuuril peab olema 1 koordinaator ja mitmed voogedastusserverid, mis on jaotatud kogu maailma: Lääne-USA, Ida-USA, Euroopa, Singapore, Hiina. Kõik voogedastusserverid peavad olema täielikult isoleeritud. Süsteem võib oma jaotust kohandada, kui server liitub või lahkub võrgust. Seega võimaldab suure liikluse korral täiendavate serverite lisamine horisontaalset skaleerimist.

  4. Brauseri ühilduvus
  Pilvemuudid tulevad parimal viisil esitlemisele, kui need nõuavad kasutajatelt minimaalset pingutust. See tähendab, et mängimist on võimalik alustada otse brauseris. Brauserid aitavad muuta mängukogemuse kasutajatele maksimaalselt mugavaks, vabastades nad tarkvara ja riistvara paigaldamise kohustusest. Samuti aitavad brauserid tagada platvormidevahelist ühilduvust mobiilsete ja lauaversioonide vahel. Õnneks toetab WebRTC suurepäraselt erinevaid brausereid.

  5. Selge mänguliidese ja teenuse eristus
  Ma käsitlen pilvmänguteenust platvormina. Igal inimesel peaks olema võimalus platvormiga ühendada mida iganes. Praegu olen integreerinud LibRetro pilve-mänguteenusega, kuna LibRetro pakub ilusat mänguemulaatori liidest retro-mängude mängimiseks, nagu SNES, GBA, PS.

  6. Mitme mängija ruumid, crowd play ja sügava lingiga ühendamine mänguga
  CloudRetro toetab palju uusi mänguviise, nagu CrowdPlay ja online mitme mängija režiim retro-mängude jaoks. Kui mitu kasutajat avavad sama sügava lingi erinevates arvutites, näevad nad sama käigitavat mängu ja saavad isegi liituda sellega.

  Veelgi enam, mängu seisud salvestatakse pilve. See võimaldab kasutajatel jätkata mängimist igal ajal mistahes teisel seadmel.

  7. Horisontaalne skaleerimine
  Nagu kõik SAAS-id tänapäeval, peavad pilvmängud olema kavandatud horisontaalselt skaleeritavateks. 'Koordinaatori-töötaja' konstruktsioon võimaldab lisada rohkem töötajaid, et teenindada suuremat liiklust.

  8. Pole sidumist ühe pilvteenusega
  CloudRetro infrastruktuur on paigutatud erinevatesse pilveteenustesse (Digital Ocean, Alibaba, kohandatud pakkuja) erinevates piirkondades. Ma aktiveerin konteineris Docker käivitamise infrastruktuuri jaoks ja seadistan võrgu parameetrid bash-skripti abil, et vältida sõltuvust ühest pilveteenustest. Kombineerides selle NAT Traversal'iga WebRTC-s, saame paindlikkuse CloudRetro juurutamiseks igasugustes pilveplatvormides ja isegi iga kasutaja masinates.

  Arhitektuurne disain

  Töötaja: (või voogesituse server, nagu mainitud eespool) kopeerib mänge, käitab kodeerimisvoogu ja edastab kodeeritud meedia kasutajatele. Töötaja instantsid jaotuvad üle kogu maailma ning iga töötaja suudab samal ajal töödelda mitut kasutaja seanssi.

  Koordinaator: vastutab uue kasutaja sidumise eest kõige sobivama töötajaga voogesitamiseks. Koordinaator suhtleb töötajatega läbi WebSocketi.

  Mängu olekute salvestamine: keskne kaugsalvestus kõigi mängu olekute jaoks. See salvestus tagab sellised olulised funktsioonid nagu näiteks kaug-salvestamine/laadimine.

  
  CloudRetro överstruktuur

  Kasutajaskripti

  Kui uus kasutaja avab CloudRetro sammudel 1 ja 2, nagu alloleval joonisel näha, küsitakse koordinaatorilt koos saadaval olevate töötajate nimekirjaga esimesel leheküljel. Pärast seda arvutab klient kõikide kandidaatide latentsuse sammul 3 HTTP-päringu pingiga. See latentsuse nimekiri saadetakse seejärel tagasi koordinaatorile, et ta saaks määrata kõige sobivama töötaja kasutaja teenindamiseks. Sammul 4 allpool luuakse mäng. Kasutaja ja määratud töötaja vahel luuakse voogesituse WebRTC ühendus.
  
  Kasutajaskripti juures, pärast juurdepääsu saamist

  Mis on töötaja sees

  Mängu ja voogesituse vood hoitakse töötaja sees eraldatult ning vahetavad seal teavet liidese kaudu. Praegu toimub see ühendus andmete edastamise kaudu mällu Golang kanalites samameelses protsessis. Järgmine eesmärk on segregatsioon, st sõltumatu mäng käivitades teises protsessis.

  
  Töötaja komponentide interaktsioon

  Peamised koostisosad:

  • WebRTC: kliendikomponent, mis võtab kasutaja sisendi ja edastab serverilt kodeeritud meedia.
  • Mängu emulaator: mängu komponent. Libretro raamatukogu abil suudab süsteem mängu käivitada samas protsessis ning sisemiselt salvestada meedia ja sisendvoo.
  • Mängu raame salvestatakse ja saadetakse kodeerijale.
  • Pilt/heli kodeerija: kodeerimisvoog, mis võtab meedia raame, kodeerib neid taustal ja edastab kodeeritud pilte/heli.

  Rakendamine

  CloudRetro toetub WebRTC-le kui peamisele tehnoloogiale, seega enne, kui süvenen Golangi rakendusse, otsustasin rääkida WebRTC-st endast. See on suurepärane tehnoloogia, mis on mind palju aidanud saavutada andmevoogude edastamise viivitus vaid murdosa sekundist.

  WebRTC

  WebRTC on mõeldud kvaliteetsete peer-to-peer ühenduste tagamiseks natiivsetes mobiilirakendustes ja brauserites lihtsate API-de kaudu.

  NAT Traversal

  WebRTC on tuntud oma NAT Traversal funktsionaalsuse poolest. WebRTC on loodud peer-to-peer suhtluseks. Selle eesmärk on leida sobivaim otseühendus, vältides NAT-gate’e ja tulemüüre peer-to-peer suhtluseks protsessi käigus, mida nimetatakse ICE. Selle protsessi käigus leiavad WebRTC API-d teie avaliku IP-aadressi STUN-serverite kaudu ja edastavad selle edasi edastusserverile (TURN), kui otsest ühendust ei suudeta luua.

  Kuid CloudRetro ei kasuta täielikult seda võimalust. Selle peer-to-peer ühendused ei toimu kasutajate vahel, vaid kasutajate ja pilveserverite vahel. Serveri mudeli osal on vähem piiranguid otsese suhtluse jaoks kui tavalise kasutaja seadmel. See võimaldab avada sissepääsu porte või kasutada avalikke IP-aadresse otse, kuna server ei asu NAT-i taga.

  Varem tahtsin muuta projekti mängude levitamise platvormiks Cloud Gamingu jaoks. Idee oli võimaldada mängude loojatel pakkuda mänge ja voogedastusressursse. Kasutajad suhtleksid otse teenusepakkujatega. Sellises detsentraliseeritud mooduses on CloudRetro lihtsalt keskkond kolmandate osapoolte voogedastusressursside ühendamiseks kasutajatega, mis muudab selle skaleeritavamaks, kui see ei ole enam hostimise koormatud. WebRTC NAT Traversali roll on siin väga oluline, et hõlbustada peer-to-peer ühenduse loomist kolmandate osapoolte voogedastusressurssidega, mis lihtsustab looja ühendamist võrku.

  Videote sürvendamine

  Videotehnoloogia kokkusurumine on kriitiline osa töövoost, mis mängib suurt rolli voo sujuvuses. Kuigi ei ole vajalik teada kõiki VP8/H264 kodeerimise üksikasju, aitab mõistmine mõista voogesituse videokiirusparameetreid, lahendada ootamatuid käitumisi ja kohandada viivitust.

  Videotehnoloogia kokkusurumine voogedastusteenuse jaoks on keeruline ülesanne, kuna algoritm peab tagama, et kodeerimise aeg + edastamisaeg + dekodeerimisaeg oleks võimalikult väike. Lisaks peab kodeerimisprotsess olema järjepidev ja katkematu. Mõned vastastikused järeleandmised kodeerimisel ei tule kõne alla – näiteks ei saa me eelistada pikka kodeerimisaega väiksemale failisuurusele ja dekodeerimisaegale või kasutada järjepidevat kokkusurumist.

  Videotehnoloogia kokkusurumise idee on jätta kõrvale tarbetud bitid teabest, säilitades samal ajal lubatud täpsuse taseme kasutajatele. Lisaks üksikute staatiliste piltide kodeerimisele teeb algoritm järeldusi praeguse kaadriga eelneva ja järgmise kaadri põhjal, edastades seega ainult nende erinevuse. Nagu näha Pacmani näitest, edastatakse ainult diferentsiaalsed punktid.

  
  Videokaadrite võrdlemine Pacmani näitel

  Heli kokkusurumine

  Sarnaselt videotehnoloogia kokkusurumisega, loob heli kokkusurimise algoritm andmeid, mida inimene ei suuda tajuda. Opus on hetkel parim töötav helikooder. See on välja töötatud helilainete edastamiseks järjepideva andmevoo protokolli, nagu RTP (Real Time Transport Protocol – reaalajas edastusprotokoll), kaudu. Selle latentsus on väiksem kui mp3-l ja aac-l, samas kui kvaliteet on kõrgem. Latentsus on tavaliselt umbes 5–66,5 ms.

  Pion, WebRTC Golangis

  Pion on avatud lähtekoodiga projekt, mis toob WebRTC Golangi. Erinevalt tavapärasest natiivsete C++ WebRTC teekide kirjutamisest on Pion WebRTC natiivne Golangi teostus, millel on parem jõudlus, Go-iga integreerimine ning versioonihaldus WebRTC protokollide jaoks.

  Raamatukogu võimaldab ka edastada andmeid suure mahtude suurepäraste sisseehitatud moodulitega, mille latentsus on alla sekundi. Sellel on oma STUN, DTLS, SCTP jne teostus ning mõned eksperimendid QUICi ja WebAssemblyga. See avatud lähtekoodiga raamatukogu on tõeliselt hea õppimise allikas koos suurepärase dokumentatsiooni, võrgu protokollide teostuse ja toredate näidistega.

  Pioni kogukond, mida juhib väga kirglik looja, on üsna elav ja seal toimub palju kvaliteetseid arutelusid WebRTCi kohta. Kui sind huvitab see tehnoloogia, liitu http://pion.ly/slack – õpid palju uut.

  CloudRetro kirjutamine Golangis

  
  Worker'i teostamine Go-s

  Go kanalid tegevuses

  Go kanalite kauni disaini tõttu lihtsustatakse oluliselt sündmuste voogedastamise ja paralleelsuse probleeme. Nagu diagrammil, töötavad erinevates GoRoutines samaaegselt mitmed komponendid. Iga komponent haldab oma olekut ja suhtleb kanalite kaudu. Golangi valikuline väide sunnib töötlema üksikute aatomite sündmusi iga mängu ajal (game tick). See tähendab, et sellise disaini korral ei ole lukustamine vajalik. Näiteks, kui kasutaja salvestab, on vajalik kogu mängu oleku snapshot. See olek peab olema järjepidev, teostades sisendi kuni salvestamine on lõpetatud. Iga mängu tick'i ajal saab backend töödelda ainult salvestus- või sisendoperatsiooni, mis teeb protsessi üheselt turvaliseks.

  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

  See Golangi malle sobib suurepäraselt minu CrowdPlay ja Mitme mängija kasutusjuhtumiteks. Selle mustri järgimisel voogedastatakse kõik kasutaja sisendid ühte tuuma sisendkanalisse. Mängu meedia edastatakse seejärel kõigile ühes ruumis olevatele kasutajatele. Nii saavutame mängu oleku jagamise mitme erineva kasutaja mänguseansi vahel.

  
  Sünkroonimine erinevate seansside vahel

  Golang'i puudused

  Golang ei ole ideaalne. Kanal on aeglane. Kui võrrelda Go kanalit lukustuse korral, on see lihtsalt lihtsam viis paralleelsete ja voogedastuse sündmuste käsitlemiseks, kuid kanal ei paku parimat jõudlust. Kanali all on keeruline lukustuse loogika. Seetõttu tegin ma mõned muudatused rakenduses, rakendades uuesti lukustusi ja aatomilisi väärtusi kanaleid asendades jõudluse optimeerimiseks.

  Lisaks on Golangi prügikorjaja haldamata, mis põhjustab mõnikord kahtlaselt pikki pause. See segab oluliselt reaalajas voogesituse rakenduse tööd.

  CGO

  Projekti koostamisel kasutatakse olemasolevat VP8/H264 avatud lähtekoodiga Golangi teeki meedia tihendamiseks ja Libretro mängu emulaatorite jaoks. Kõik need teegid on lihtsalt Go-s C teegi ümberpakendamisest. CGO. Mõned puuded on loetletud selles Dave Cheney postituses. Probleemid, millega ma silmitsi seisnud olen:

  • CGO-s ei ole võimalik katki minna, isegi kasutades Golangi RecoveryCrash'i;
  • pole võimalik tuvastada jõudluse kitsaskohti, kui me ei saa tuvastada detailseid probleeme CGO-s.

  Kokkuvõte

  Sain oma eesmärgi – mõistsin pilvepõhiseid mänguteenuseid ja lõin platvormi, mis aitab mul koos sõpradega nostalgilisi retro-mänge veebis mängida. Selle projekti loomine ei oleks olnud võimalik ilma Pioni teegi ja Pioni kogukonna toeta. Olen äärmiselt tänulik selle intensiivse arenduse eest. WebRTC ja Pioni pakutud lihtsad API-d tagasid sujuva integreerimise. Minu esimene tõestuskontseptsioon avaldati samal nädalal, vaatamata sellele, et ma ei teadnud sellest eelnevalt ühepunktiühenduse (P2P) kohta.

  Hoolimata integreerimise lihtsusest on P2P-voogedastus tõeliselt keeruline valdkond arvutiteadlastele. See peab tegelema keerukate mitme aasta vanuste võrguarhitektuuridega, nagu IP ja NAT, et luua võrdne sessioon. Selle projekti töös olen omandanud palju väärtuslikke teadmisi võrgu ja jõudluse optimeerimise kohta, seetõttu soovitan kõigil proovida P2P-tooteid WebRTC abil ehitada.

  CloudRetro teenindab kõiki kasutusstsenaariume, mida ma ootasin, kui vaadata seda retrosõber. Siiski arvan, et projektis on palju valdkondi, mida saaksin parendada, näiteks võrgu usaldusväärsemaks ja tootlikumaks tegemine, mängude graafika kvaliteedi parandamine või võimalus jagada mänge kasutajate vahel. Ma töötan selle nimel kõvasti. Palun jälgige projekti ja toetage seda, kui see teile meeldib.

Allikas: habr.com