Pilve mängimine avatud lähtekoodiga WebRTC-l: p2p, mitmikmäng, null viivitus

Tarkvara teenusena, infrastruktuur teenusena, platvorm teenusena, suhtlusplatvorm teenusena, videokonverentsid teenusena, aga kuidas on lood mängimisega teenusena? On tehtud mitmeid katseid mängude pilve viimiseks (Cloud Gaming), näiteks Google'i hiljuti lansseeritud Stadia. Stadia, kuid kas teised saavad kasutada WebRTC-d sama hästi?

Thanh Nguyen otsustas seda võimalust kontrollida oma avatud lähtekoodiga projektis CloudRetro. CloudRetro põhineb Pionil, populaarne WebRTC raamatukogu Go põhjal (tänu Shonile Pioni arendajate grupist, kes aitas selle artikli ette valmistada). Käesolevas artiklis annab Thanh ülevaate oma projekti arhitektuurist ning räägib, mida kasulikku ta õppis ja milliste väljakutsetega ta silmitsi seisis oma töö ajal.

Sissejuhatus

Eelmisel aastal, kui Google kuulutas välja Stadia, olin täiesti lõhkevad. Idee on nii ainulaadne ja innovaatiline, et ma küsisin endalt pidevalt, kuidas selline asi on tehnoloogiliselt võimalik. Soov süvitsi minna sellesse valdkonda ajendas mind looma oma versiooni avatud lähtekoodiga pilve mängust. Tulemus oli lihtsalt fantastiline. Allpool jagan oma aastase projekti väljatöötamise protsessi. projektiga.

TLDR: lühike slaidiversioon peamistest punktidest

Miks on pilve mängude tulevik

Usun, et pilvemängud saavad peagi olema uue põlvkonna mitte ainult mängude, vaid ka teiste infotehnoloogia valdkondade lahendustes. Pilvemängud on kliendi/serveri mudeli tipp. See mudel maksimeerib tagapidamise haldamist ja minimeerib ettepoole suunatud töö, viies mängu logika kaugserverisse ja edastades pilti/häält kliendile. Server teostab rasked arvutused, seega ei sõltu klient enam seadme piirangutest.

Google Stadia võimaldab põhimõtteliselt mängida AAA-mänge (st. kõrgekvaliteetsed mängud-plokkbusterid) YouTube'i sarnasel liidestel. Sama metodologia võib kehtida ka teistele rasketele off-line rakendustele, nagu opsüsteem või 2D/3D graafiline disain jms, et suudaksime neid stabiilselt käitada madala spetsifikatsiooniga seadmetes erinevates platvormides.

Selle tehnoloogia tulevik: kas oskate ette kujutada, kui Microsoft Windows 10 töötaks Chrome'i brauseris?

Pilvemängud on tehniliselt keerulised.

Mängimine on üks haruldasi valdkondi, kus on vajalik pidev kiire kasutaja reageerimine. Kui me mõnikord kogeme 2 sekundi viivitust lehe klikil, on see vastuvõetav. Otsevooged, mis reeglina jäävad paar sekundit hiljaks, pakuvad siiski 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 traditsiooniline lähenemine voogesitusele siin ei toimi.

Pilvemängude üldine malli

Avatud lähtekoodiga projekt CloudRetro

Otsustasin luua testimiseks pilvemängu näidise, et uurida, kas see on kõik võimalik nii rangete võrgupiirangute tingimustes. Kontseptsiooni kontrollimiseks valisin Golangi, kuna see on mulle kõige tuttavam keel ja sobib selle rakendamiseks paljuski, nagu hiljem selgus. Go on lihtne ja areneb väga kiiresti; Go kanalid sobivad suurepäraselt mitme lõime haldamiseks.

Projekt CloudRetro.io – avatud lähtekoodiga pilvemänguteenuse platvorm retro-mängude jaoks. Projekti eesmärk on tuua traditsioonilistesse retro-mängudesse parim mängukogemus ja lisada mitmikmängu.
Projekti üksikasjadega saab tutvuda siin: https://github.com/giongto35/cloud-game.

CloudRetro funktsioonid

CloudRetro demonstreerib pilvemängude kogu potentsiaali retro-mängude abil. See võimaldab saada mitmeid unikaalseid mängukogemusi.

• Mängu kaasaskantavus
  • Kohene mängimise võimalus lehe avamisel; allalaadimist ja installimist ei ole vaja.
  • Töötab mobiilibrauseris, seega pole käitamiseks mingit tarkvara vajalik.

• Mänguseansse saab jagada mitmel seadmel ja salvestada pilve järgmiseks sisenemiseks.
• Mängu saab voogedastada, aga seda saavad korraga mängida mitmed kasutajad:
  • Crowdplay sarnane TwitchPlayPokemonile, kuid rohkem platvormideülene ja reaalajas.
  • Offline mängud online'is. Mitu kasutajat saavad mängida ilma võrgu seadistamiseta. Samurai Shodownis saavad nüüd kaks mängijat mängida CloudRetro võrgus.

  
  Mitu mängijat toetamata online-mängu demoversioon erinevates seadmetes.

  Infrastruktuur

  Nõuded ja tehnoloogiatehnoloogia.

  Allpool on toodud nõuete loetelu, mille ma projekti alustamise eel seadnud olen.

  1. Üks mängija
  See nõue võib tunduda mitte liiga oluline ja ilmne, kuid see on üks mu peamisi järeldusi – see võimaldab pilvemängudel võimalikult kaugel hoida traditsioonilistest voogedastusteenustest. Kui keskendume ühe mängijaga mängule, saame loobuda tsentraliseeritud serverist või CDN-ist, kuna me ei pea voeedastust massidesse tegema. Selle asemel, et edastada vooge sööv serverisse või edastada pakette tsentraliseeritud WebSocket serverisse, saadetakse teenusevood otse kasutajale läbi punkt-punkti WebRTC ühenduse.

  2. Madala latentsusega meediavool
  Lugedes Stadia kohta, kohtan ma sageli mõnedes artiklites mainimist WebRTC-st. Hakkasin aru saama, et WebRTC on silmapaistev tehnoloogia, mis sobib suurepäraselt pilvemängude kasutamiseks. WebRTC on projekt, mis võimaldab veebibrauseritel ja mobiilirakendustel reaalajas ühendust luua lihtsa API kaudu. See tagab punkt-punkti ühenduse, mis on optimeeritud meedia jaoks ja sisaldab sisseehitatud standardkoodekeid, nagu VP8 ja H264.

  Ma olen eelistanud kasutajate mugava töö tagamist, mitte kõrge graafika kvaliteedi säilitamist. Algoritmis on lubatud teatavad kadud. Google Stadias on serveris pildi suuruse vähendamise täiendav samm, ja kaadrid skaleeritakse kõrgema kvaliteedini enne edastamist võrgu sõlmedele.

  3. Geograafilise marsruutimisega jaotatud infrastruktuur
  Kuna algoritmide tihendamine ja kood on optimeeritud, on siiski kõige olulisem tegur latentsuse korral võrgustruktuur. Arhitektuur peaks sisaldama mehhanismi, mis ühendab lähima kasutajale serveriga, et vähendada RTT (ringkäigu aega). Arhitektuuril peab olema üks koordinaator ja mitu voogesituse serverit, mis on jaotatud üle kogu maailma: Lääne-USA, Ida-USA, Euroopa, Singapur, Hiina. Kõik voogesituse serverid peavad olema täielikult isoleeritud. Süsteem suudab reguleerida oma jaotust, kui server liitub või lahkub võrgust. Seega, kui koormus on suur, võimaldab lisaserverite lisamine horisontaalset skaleerimist.

  4. Brauseri ühilduvus
  Pilve mängud saavad parima ilme, kui need nõuavad kasutajatelt minimaalset. See tähendab, et neid saab käivitada brauseris. Brauserid aitavad muuta mängimise kasutajasõbralikumaks, vabastades nad tarkvara ja riistvara installimise koormast. Brauserid toetavad ka platvormidevahelist ühilduvust mobiilsete ja lauaarvutiversioonide vahel. Õnneks toetab WebRTC suurepäraselt erinevaid brausereid.

  5. Selge eristus mängu liidese ja teenuse vahel
  Ma käsitlen pilvmänguteenust platvormina. Igal kasutajal peaks olema võimalus ühendada platvormile mida iganes. Praegu olen integreerinud LibRetro pilvmänguteenusega, sest LibRetro pakub kaunist mängu emulaatori liidest retro mängude jaoks, nagu SNES, GBA, PS.

  6. Mitme mängija toad, crowd play ja mänguga sügava lingi (deep-link) sidumine
  CloudRetro toetab mitmeid uusi mängimise vorme, nagu CrowdPlay ja Online MultiPlayer retro mängude jaoks. Kui mitu kasutajat avavad erinevatel arvutitel sama sügava lingi, näevad nad sama mängu ja saavad sellele isegi liituda.

  Lisaks sellele salvestatakse mängu seisud pilves. See võimaldab kasutajatel jätkata mängimist igal ajal igasugustel seadmetel.

  7. Horisontaalne skaleerimine
  Nagu iga praegune SAAS, peavad pilvemängud olema loodud horisontaalselt skaleeritavateks. Koordineerija-töötaja struktuur võimaldab lisada rohkem töötajaid suurema liikluse teenindamiseks.

  8. Pole seotust ühe pilvega
  CloudRetro infrastruktuur on paigutatud erinevatele pilveteenuse pakkujatele (Digital Ocean, Alibaba, kohandatud pakkuja) erinevates piirkondades. Käivitan konteinerites Docker infrastruktuuri ja seadistan võrguseaded bash-skripti abil, et vältida sõltuvust ühest pilveteenuse pakkujast. Kombineerides selle NAT Traversal WebRTC-ga, saame paindlikkuse CloudRetro juurutamiseks igasugustel pilveplatvormidel ja isegi mis tahes kasutaja masinates.

  Arhitektuuri disain

  Töötaja: (või ülekandeteenus, nagu eespool mainitud) haldab mänge, käivitab kodeerimisvoo ja edastab kodeeritud meedia kasutajatele. Töötlusinstance jagatakse üle kogu maailma ning iga töötleja suudab samal ajal hallata mitmeid kasutaja seansse.

  Koordinaator: vastutab uue kasutaja sidumise eest sobiva töötlejaga voogedastamiseks. Koordinaator suhtleb töötlejatega WebSocketi kaudu.

  Mängu seisundite hoidla: keskne kaughoidla kõikide mängu seisundite jaoks. See hoidla tagab sellised olulised funktsioonid nagu kaugsalvestus/laadimine.

  
  CloudRetro ülemine arhitektuur

  Kasutajaskenario

  Kui uus kasutaja avab CloudRetro 1. ja 2. sammul, nagu on näidatud alloleval pildil, küsitakse koordinaatorilt koos saadaval olevate töötajate nimekirjaga esimeses leheküljel. Pärast seda, 3. sammul, arvutab klient viivitused kõigi kandidaatide jaoks HTTP pingiga. See viivituste nimekiri saadetakse seejärel tagasi koordinaatorile, et ta saaks määrata kasutajale kõige sobivama töötaja. 4. sammul luuakse mäng. Kasutaja ja määratud töötaja vahel luuakse WebRTC kaudu voogedastuse ühendus.
  
  Kasutajascenarion peale juurdepääsu saamist

  Mis on töötajas sees

  Mängu- ja voogedastuskanalid hoitakse töötaja sees isoleeritult ning nad vahetavad teavet seal läbi liidese. Hetkel toimub see ühendus mälus andmete edastamise teel läbi Golang kanalite samas protsessis. Järgmine eesmärk on segregeerimine, st mängu iseseisev käivitamine teises protsessis.

  
  Töötaja komponentide interaktsioon

  Peamised komponendid:

  • WebRTC: klientkomponent, mis võtab vastu kasutaja sisendi ja väljastab serverist kodeeritud meedia.
  • Mänguemulaator: mängukomponent. Tänu Libretro raamatukogule suudab süsteem käivitada mängu ühes protsessis ja sisemiselt peatada meedia ja sisendi voogu.
  • Mängu kohaletoimetatavad kaadrid salvestatakse ja saadetakse kodeerijale.
  • Pilt/heli kodeerija: kodeerimise torustik, mis võtab meedia kaadrid, kodeerib need taustal ning väljastab kodeeritud pildid/helid.

  Rakendus

  CloudRetro toetub WebRTC-le kui põhitehnoloogiale, seetõttu enne, kui süveneen Gumidetailide elluviimisse Golangis, tahtsin rääkida WebRTC-st. See on hämmastav tehnoloogia, mis on mind aidanud saavutada andmeedastuse viivituseks vaid killu sekundist.

  WebRTC

  WebRTC on mõeldud kõrgekvaliteediliste üheotsaliste ühenduste tagamiseks kohalikus mobiilirakenduses ja brauserites lihtsate API-de kaudu.

  NAT Traversal

  WebRTC on tuntud oma NAT Traversali funktsionaalsuse poolest. WebRTC on mõeldud üks-ühele suhtlemiseks. Selle eesmärk on leida sobivaim otsene marsruut, vältides NAT-lüüse ja tulemüüre töös, mida kutsutakse ICE. Selle protsessi käigus leiavad WebRTC API-d teie avaliku IP-aadressi STUN-serverite abil ja suunavad selle edasi tagasiserverisse (TURN), kui otseühendust ei õnnestu luua.

  Kuid CloudRetro ei kasuta seda võimalust täielikult. Selle peer-to-peer ühendused ei toimu kasutajate vahel, vaid kasutajate ja pilveserverite vahel. Mudeli serveripoolsel osal on vähem piiranguid otseühenduse osas kui tavalisel kasutajal. See võimaldab ette avada sissetulevad pordid või kasutada otseselt avalikke IP-aadresse, kuna server ei asu NAT-i taga.

  Kun ma tahtsin varem muuta projekti mängude levitamise platvormiks Cloud Gaming jaoks. Idee oli võimaldada mängu loojatel pakkuda mänge ja voogesituse ressursse. Kasutajad suheldaksid otse teenusepakkujatega. Sellises detsentraliseeritud lähenemises on CloudRetro lihtsalt keskkond, mis ühendab kolmandate osapoolte voogesitusressursse kasutajatega, muutes selle skaleeritavaks, kuna hosting ei ole enam selle peamine eesmärk. WebRTC NAT Traversal mängib siin väga olulist rolli, hõlbustades peer-to-peer ühenduse loomist kolmandate osapoolte voogesitusressursside vahel, mis lihtsustab looja ühendamist võrguga.

  Videokompressioon

  Videokompressioon on hädavajalik osa voogesituse tööprotsessist, mis panustab olulisel määral voogesituse sujuvusele. Kuigi ei ole hädavajalik teada kõiki VP8/H264 videokoodimise detaile, aitab mõistmine kontseptsioonist aru saada voogedastuse kiirusparameetritest, tuvastada ootamatut käitumist ja kohandada viivitust.

  Video voogesituse tihendamine on keeruline ülesanne, kuna algoritm peab tagama, et kokkuvõttes koodimise aeg + edastusaeg + dekodeerimise aeg oleks võimalikult väike. Lisaks peab kodeerimisprotsess olema järjepidev ja katkematu. Teatud kompromissid kodeerimise osas ei kehti – näiteks ei saa me eelistada pikemat kodeerimisaega väiksema failisuuruse ja dekodeerimise aja arvel, ega kasutada järjepidevat tihendamist.

  Video tihendamise idee seisneb ebavajalike informatsiooni bittide eemaldamises, säilitades samal ajal kasutajatele vastuvõetava täpsuse taseme. Lisaks üksikute staatiliste piltide kodeerimisele teeb algoritm järeldusi praegusest kaadrist varasema ja järgmise põhjal, seega saadetakse ainult nende vaheline erinevus. Nagu näha Pacmani näites, edastatakse ainult diferentseeritud punktid.

  
  Kuid videokadrite võrdlemine Pacmani näitel

  Audio tihendamine

  Sarnasel viisil loob heli kompressioon algoritm andmeid, mida inimene ei suuda tajuda. Opus on hetkel parim tulemuslikkusega helikodek. See on välja töötatud helilaine edastamiseks järjestiku datagrammi protokollis, nagu RTP (Real Time Transport Protocol – reaalajas edastamise protokoll). Selle latentsus on madalam kui mp3 ja aac ning kvaliteet on parem. Latentsus on tavaliselt umbes 5–66,5 ms.

  Pion, WebRTC Go'is

  Pion on avatud lähtekoodiga projekt, mis toob WebRTC Go-sse. Erinevalt tavalistest C++ WebRTC teekide väänamisest on Pion natiivne Golangi teostus WebRTC jaoks, millel on parem tulemuslikkus, Go'ga integreerimine ning protokollide WebRTC versioonikontroll.

  Raamatukogu toetab ka andmevoogu suure hulga suurepäraste sisseehitatud moodulitega, mille viivitus on vähem kui sekund. Sellel on oma STUN, DTLS, SCTP jne rakendus ning mõned katsetused QUICi ja WebAssemblyga. See avatud lähtekoodiga raamatukogu on tõeliselt hea õppeallikas suurepärase dokumentatsiooni, võrguprotokollide rakendamise ja ägedate näidistega.

  Pioni kogukond, mida juhib väga kirglik looja, on üsna elav, seal toimub palju kvaliteetseid arutelusid WebRTCi üle. Kui teid huvitab see tehnoloogia, liituge http://pion.ly/slack – te õppite palju uut.

  CloudRetro kirjutamine Golangis

  
  Töötlija rakendamine Go-s

  Go kanalid tegevuses

  Go kanalite kauni disaini tõttu on voogedastuse ja paralleelsuse probleemid oluliselt lihtsamad. Nagu diagrammil, töötavad erinevates GoRoutines mitmed komponendid paralleelselt. Iga komponent haldab oma olekut ja suhtleb kanalite kaudu. Golangi valikuline avaldus sunnib töötlema ühte aatomitööd iga mängu hetke jooksul (game tick). See tähendab, et sellise disaini puhul ei ole lukustamine vajalik. Näiteks, kui kasutaja salvestab, on vajalik täielik mängu oleku snapshot. See olek peab jääma pidevaks, tehes sisendi, kuni salvestamine on lõpetatud. Iga game tick'i ajal saab tagasisüsteem töödelda vaid salvestamise või sisendi operatsiooni, mis muudab protsessi voogude 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 Golang'i mall sobib suurepäraselt minu CrowdPlay ja Multiple Player kasutusstsenaariumiga. Järgides seda malli, integreeritakse kõik kasutaja sisendid ühes toas keskse sisendi kanalisse. Mängu multimeedia edastatakse seejärel kõigile kasutajatele, kes viibivad ühes toas. Nii saavutame mängu oleku jagamise erinevate kasutajate mängusessioonide vahel.

  
  Sünkroniseerimine erinevate seansside vahel

  Golang'i puudused

  Golang ei ole täiuslik. Kanal on aeglane. Võrreldes lukustatud kanaliga on Go lihtsalt lihtsam viis paralleelsete ja voogedastuste töötlemiseks, kuid kanal ei paku parimat jõudlust. Kanali all on keeruline lukustamise loogika. Seetõttu olen mõned muudatused teinud rakendusse, rakendades uuesti lukustusi ja aatomväärtusi kanali asendamiseks jõudluse optimeerimiseks.

  Lisaks on Golang'i jäätme kogumine halduses, mis põhjustab mõnikord kahtlaseid pikaid pause. See häirib tõsiselt reaalajas voogedastuse rakenduse toimimist.

  CGO

  Projektis kasutatakse olemasolevat VP8/H264 avatud lähtekoodiga Golangi teeki meedia pakkimiseks ja Libretro mängu emulaatoriteks. Kõik need teegid on lihtsalt C teegi ümbermõtestamised Go-s, kasutades CGO. Mõned puudused on loetletud selles Dave Cheney postituses. Probleemid, millega ma silmitsi seisin:

  • CGO-s krahhi kinni püüda ei ole võimalik, isegi Golangi RecoveryCrash'i abil;
  • võimetus määrata, kus on jõudlusprobleem, kuna me ei suuda CGO-s detailsetelt probleeme avastada.

  Kokkuvõte

  Olin oma eesmärgiga saavutanud – mõistsin pilvemänguteenuseid ja lõin platvormi, mis võimaldab mul mängida nostalgilisi retro mänge oma sõpradega veebis. Selle projekti loomine ei oleks olnud võimalik ilma Pioni teegi ja Pioni kogukonna toeta. Olen äärmiselt tänulik selle intensiivse arengu eest. WebRTC ja Pioni pakutud lihtsad API-d võimaldasid sujuvat integreerimist. Minu esimene tõend kontseptsioonist käidi välja samal nädalal, isegi kui ma ei teadnud ette ühte punkti suhete kohta (P2P).

  Kuigi P2P-voogedastus integreerimine on lihtne, on see tegelikult arvutiteaduses väga keeruline valdkond. See peab tegelema mitme aasta jooksul välja arendatud keerukate võrguarhitektuuridega, nagu IP ja NAT, et luua omavaheline sessioon. Projekti käigus olen kogunud palju väärtuslikke teadmisi võrgustatud ja jõudluse optimeerimise kohta, seega soovitan kõigil proovida luua P2P-tooteid WebRTC abil.

  CloudRetro katab kõik kasutusskeemid, mida ootasin, retro-mänguri vaatenurgast. Siiski arvan, et projektis on palju kohti, kus saaksin parendada, näiteks võrgu usaldusväärsuse ja jõudluse suurendamine, mängude graafika kvaliteedi tõstmine või kasutajate vahel mängude jagamise võimalus. Töödan selle nimel kõvasti. Palun jälgige projektiga ja toetage seda, kui see teile meeldib.

Allikas: habr.com