Lojëra në cloud me burim të hapur në WebRTC: p2p, multiplayer, zero vonesë

Softueri si shërbim, infrastruktura si shërbim, platforma si shërbim, platforma komunikimi si shërbim, video-konferencat si shërbim, po lojërat në cloud si shërbim? Tashmë ka pasur disa përpjekje për të krijuar lojëra në cloud (Cloud Gaming), siç është Stadia, e lançuar së fundi nga Google. Stadia jo e re në WebRTC, por a mund të përdorin të tjerët WebRTC në të njëjtën mënyrë?

Thanh Nguyen vendosi ta testonte këtë mundësi në projektin e tij me burim të hapur CloudRetro. CloudRetro bazohet në Pion, popullore Biblioteka WebRTC e bazuar në Go (faleminderit Treguar nga ekipi i zhvillimit të Pion për ndihmën e tyre në përgatitjen e këtij artikulli). Në këtë artikull, Thanh ofron një pasqyrë të arkitekturës së projektit të tij, dhe gjithashtu flet për gjërat e dobishme që mësoi dhe cilat sfida hasi gjatë punës së tij.

Hyrje

Vitin e kaluar, kur Google njoftoi Stadia, më shpërtheu mendjen. Ideja është kaq unike dhe inovative saqë vazhdimisht pyesja veten se si ishte e mundur kjo me teknologjinë ekzistuese. Dëshira për të kuptuar më mirë këtë temë më shtyu të krijoj versionin tim të një loje cloud me burim të hapur. Rezultati ishte thjesht fantastik. Më poshtë do të doja të ndaja procesin e punës në vitin tim projekti.

TLDR: version i shkurtër rrëshqitës me pikat kryesore

Pse lojërat në cloud janë e ardhmja

Unë besoj se Cloud Gaming së shpejti do të bëhet gjenerata e ardhshme jo vetëm e lojërave, por edhe fushave të tjera të shkencës kompjuterike. Lojëra në renë kompjuterike është kulmi i modelit të klientit/serverit. Ky model maksimizon menaxhimin e backend-it dhe minimizon punën e front-endit duke pritur logjikën e lojës në një server të largët dhe duke transmetuar imazhe/audio te klienti. Serveri bën përpunimin e rëndë në mënyrë që klienti të mos jetë më në mëshirën e kufizimeve të harduerit.

Google Stadia në thelb ju lejon të luani Lojëra AAA (d.m.th. lojëra të nivelit të lartë blockbuster) në një ndërfaqe si YouTube. E njëjta metodologji mund të zbatohet për aplikacione të tjera të rënda offline si sistemi operativ ose dizajni grafik 2D/3D, etj. në mënyrë që t'i ekzekutojmë ato vazhdimisht në pajisje me specifika të ulëta nëpër platforma të shumta.

E ardhmja e kësaj teknologjie: Imagjinoni nëse Microsoft Windows 10 funksiononte në shfletuesin Chrome?

Lojërat në renë kompjuterike janë teknikisht sfiduese

Lojërat e lojërave janë një nga ato fusha të rralla ku kërkohet reagim i vazhdueshëm dhe i shpejtë i përdoruesit. Nëse herë pas here hasim një vonesë prej 2 sekondash kur klikojmë në një faqe, kjo është e pranueshme. Transmetimet e drejtpërdrejta të videove priren të vonojnë disa sekonda, por megjithatë ofrojnë një përdorshmëri të arsyeshme. Sidoqoftë, nëse loja shpesh vonon me 500 ms, ajo thjesht nuk mund të luhet. Qëllimi ynë është të arrijmë vonesë jashtëzakonisht të ulët në mënyrë që hendeku midis hyrjes dhe medias të jetë sa më i vogël. Prandaj, qasja tradicionale për transmetimin e videos nuk është e zbatueshme këtu.

Modeli i lojës së përgjithshme Cloud

Projekti me burim të hapur CloudRetro

Vendosa të krijoj një mostër provë të një loje cloud për të parë nëse e gjithë kjo ishte e mundur me kufizime kaq të ngushta të rrjetit. Zgjodha Golang për vërtetimin e konceptit sepse ishte gjuha me të cilën njihesha më shumë dhe ishte e përshtatshme për këtë zbatim për shumë arsye të tjera, siç zbulova më vonë. Go është e thjeshtë dhe zhvillohet shumë shpejt; Kanalet në Go janë të shkëlqyera për menaxhimin e multithreading.

Projekt CloudRetro.io është një shërbim i lojërave cloud me burim të hapur për lojëra retro. Qëllimi i projektit është të sjellë përvojën më të rehatshme të lojërave në lojërat tradicionale retro dhe të shtojë shumë lojtarë.
Ju mund të mësoni më shumë rreth projektit këtu: https://github.com/giongto35/cloud-game.

Funksionaliteti CloudRetro

CloudRetro përdor lojëra retro për të demonstruar fuqinë e lojërave cloud. E cila ju lejon të merrni shumë përvoja unike të lojërave.

• Transportueshmëria e lojës
  • Rishikim i menjëhershëm kur hapni një faqe; nuk nevojitet shkarkim apo instalim
  • Punon në një shfletues celular, kështu që nuk nevojitet asnjë softuer për ta ekzekutuar atë

• Seancat e lojërave mund të ndahen në pajisje të shumta dhe të ruhen në renë kompjuterike për herën tjetër që të identifikoheni
• Loja mund të transmetohet, ose mund të luhet nga disa përdorues në të njëjtën kohë:
  • Crowdplay si TwitchPlayPokemon, vetëm më shumë ndër-platformë dhe më shumë në kohë reale
  • Lojëra offline në internet. Shumë përdorues mund të luajnë pa krijuar një rrjet. Samurai Shodown tani mund të luhet nga 2 lojtarë në rrjetin CloudRetro

  
  Versioni demo i lojës me shumë lojtarë në internet në pajisje të ndryshme

  Infrastrukturë

  Kërkesat dhe grumbulli i teknologjisë

  Më poshtë është një listë e kërkesave që kam vendosur përpara fillimit të projektit.

  1. Një lojtar
  Kjo kërkesë mund të mos duket shumë e rëndësishme ose e dukshme këtu, por është një nga pikat e mia kryesore, ajo lejon që lojërat në cloud të qëndrojnë sa më larg nga shërbimet tradicionale të transmetimit. Nëse përqendrohemi në një lojë me një lojtar, ne mund të heqim qafe një server të centralizuar ose CDN sepse nuk kemi nevojë të transmetojmë tek masat. Në vend të ngarkimit të transmetimeve në një server sink ose kalimit të paketave në një server të centralizuar WebSocket, transmetimet e shërbimit i dorëzohen drejtpërdrejt përdoruesit nëpërmjet një lidhjeje WebRTC peer-to-peer.

  2. Rrjedha e medias me vonesë të ulët
  Duke lexuar për Stadia, shpesh shoh WebRTC të përmendur në disa artikuj. Kuptova që WebRTC është një teknologji e jashtëzakonshme dhe është e përsosur për t'u përdorur në lojërat në cloud. WebRTC është një projekt që u ofron shfletuesve të internetit dhe aplikacioneve celulare komunikim në kohë reale përmes një API të thjeshtë. Ofron lidhje peer-to-peer, është optimizuar për media dhe ka kode standarde të integruara si VP8 dhe H264.

  I dhashë përparësi sigurimit të përvojës më të mirë të mundshme të përdoruesit mbi ruajtjen e grafikëve me cilësi të lartë. Disa humbje janë të pranueshme në algoritëm. Google Stadia ka një hap shtesë për zvogëlimin e madhësisë së imazhit në server dhe kornizat përmirësohen në një cilësi më të lartë përpara se të transmetohen te kolegët.

  3. Infrastrukturë e shpërndarë me rrugëzim gjeografik
  Pavarësisht se sa të optimizuar janë algoritmi dhe kodi i kompresimit, rrjeti është ende faktori vendimtar që kontribuon më shumë në vonesën. Arkitektura duhet të ketë një mekanizëm për të çiftuar serverin më të afërt me përdoruesin për të reduktuar kohën e vajtje-ardhjes (RTT). Arkitektura duhet të ketë 1 koordinator dhe disa serverë transmetimi të shpërndarë në të gjithë botën: SHBA Perëndimore, SHBA Lindore, Evropë, Singapor, Kinë. Të gjithë serverët e transmetimit duhet të jenë plotësisht të izoluar. Sistemi mund të rregullojë shpërndarjen e tij kur një server bashkohet ose largohet nga rrjeti. Kështu, me trafik të madh, shtimi i serverëve shtesë lejon shkallëzim horizontal.

  4. Pajtueshmëria e shfletuesit
  Lojëra në renë kompjuterike është më e mira kur kërkon më së paku nga përdoruesit. Kjo do të thotë që është e mundur të ekzekutohet në një shfletues. Shfletuesit ndihmojnë për ta bërë përvojën e lojës sa më komode për përdoruesit, duke i shpëtuar ata nga instalimi i softuerit dhe harduerit. Shfletuesit ndihmojnë gjithashtu në ofrimin e funksionalitetit ndër-platformë midis versioneve celulare dhe desktopit. Për fat të mirë, WebRTC mbështetet mirë në një sërë shfletuesish.

  5. Ndarja e qartë e ndërfaqes dhe shërbimit të lojës
  Unë e shoh shërbimin e lojërave cloud si një platformë. Të gjithë duhet të jenë në gjendje të lidhin çdo gjë me platformën. Tani jam integruar LibRetro me shërbimin e lojërave cloud sepse LibRetro ofron një ndërfaqe të bukur emulatori lojërash për lojëra retro si SNES, GBA, PS.

  6. Dhomat për shumë lojtarë, lojë me turmë dhe lidhje të jashtme (deep-link) me lojën
  CloudRetro mbështet shumë lojëra të reja si CrowdPlay dhe Online MultiPlayer për lojëra retro. Nëse disa përdorues hapin të njëjtën lidhje të thellë në kompjuterë të ndryshëm, ata do të shohin të njëjtën lojë në punë dhe madje do të mund të bashkohen me të.

  Për më tepër, gjendjet e lojës ruhen në ruajtjen e cloud. Kjo i lejon përdoruesit të vazhdojnë të luajnë në çdo kohë në çdo pajisje tjetër.

  7. Shkallëzimi horizontal
  Ashtu si çdo SAAS në ditët e sotme, lojërat në cloud duhet të dizajnohen të jenë të shkallëzueshme horizontalisht. Dizajni koordinator-punëtor ju lejon të shtoni më shumë punëtorë për të shërbyer më shumë trafik.

  8. Nuk ka lidhje me një re
  Infrastruktura e CloudRetro është e pritur në ofrues të ndryshëm cloud (Digital Ocean, Alibaba, ofrues me porosi) për rajone të ndryshme. Aktivizoj ekzekutimin në një kontejner Docker për infrastrukturën dhe konfiguroj cilësimet e rrjetit duke përdorur një skript bash për të shmangur mbylljen në një ofrues të vetëm cloud. Duke e kombinuar këtë me NAT Traversal në WebRTC, ne mund të kemi fleksibilitetin për të vendosur CloudRetro në çdo platformë cloud dhe madje edhe në makineritë e çdo përdoruesi.

  Dizajni arkitektonik

  Punëtor: (ose serveri i transmetimit i përmendur më sipër) shumëfishon lojërat, drejton tubacionin e kodimit dhe transmeton median e koduar te përdoruesit. Instancat e punëtorëve shpërndahen në të gjithë botën dhe çdo punonjës mund të trajtojë seanca të shumta përdoruesish njëkohësisht.

  Koordinatori: është përgjegjës për çiftimin e përdoruesit të ri me punëtorin më të përshtatshëm për transmetim. Koordinatori ndërvepron me punëtorët nëpërmjet WebSocket.

  Ruajtja e gjendjes së lojës: ruajtje qendrore në distancë për të gjitha gjendjet e lojës. Kjo hapësirë ​​ruajtëse ofron funksione të rëndësishme si ruajtja/ngarkesa në distancë.

  
  Arkitektura e nivelit të lartë të CloudRetro

  Skript i personalizuar

  Kur një përdorues i ri hap CloudRetro në hapat 1 dhe 2 të paraqitur në figurën më poshtë, koordinatori së bashku me listën e punonjësve të disponueshëm i kërkohet në faqen e parë. Pas kësaj, në hapin 3 klienti llogarit vonesat për të gjithë kandidatët duke përdorur një kërkesë ping HTTP. Kjo listë e vonesave i dërgohet më pas koordinatorit në mënyrë që ai të mund të përcaktojë punëtorin më të përshtatshëm për t'i shërbyer përdoruesit. Hapi 4 më poshtë krijon lojën. Krijohet një lidhje transmetimi WebRTC midis përdoruesit dhe punonjësit të caktuar.
  
  Skripti i përdoruesit pas fitimit të aksesit

  Çfarë ka brenda punëtorit

  Tubacionet e lojës dhe transmetimit ruhen brenda punonjësit në izolim dhe shkëmbejnë informacion atje përmes ndërfaqes. Aktualisht, ky komunikim kryhet duke transferuar të dhëna në memorie nëpërmjet Kanalet Golang në të njëjtin proces. Qëllimi tjetër është segregacioni, d.m.th. nisja e pavarur e lojës në një proces tjetër.

  
  Ndërveprimi i komponentëve të punëtorëve

  Përbërësit kryesorë:

  • WebRTC: një komponent klienti që pranon hyrjen e përdoruesit dhe nxjerr media të koduara nga serveri.
  • Emulator i lojës: komponenti i lojës. Falë bibliotekës Libretro, sistemi është në gjendje të ekzekutojë lojën brenda të njëjtit proces dhe të përgjojë nga brenda mediat dhe rrymën hyrëse.
  • Kornizat në lojë kapen dhe dërgohen te koduesi.
  • Koduesi i imazhit/audio: një tubacion kodues që merr kornizat mediatike, i kodon ato në sfond dhe nxjerr imazhe/audio të koduara.

  Zbatimi

  CloudRetro mbështetet në WebRTC si teknologjinë e saj kurrizore, kështu që përpara se të zhytem në detajet e zbatimit të Golang, vendosa të flas për vetë WebRTC. Kjo është teknologji e mahnitshme që më ka ndihmuar shumë në arritjen e vonesës së nën-sekondës për transmetimin e të dhënave.

  WebRTC

  WebRTC është projektuar për të ofruar lidhje të cilësisë së lartë peer-to-peer në aplikacionet dhe shfletuesit celularë vendas duke përdorur API të thjeshta.

  Kalimi NAT

  WebRTC është i njohur për funksionalitetin e tij NAT Traversal. WebRTC është projektuar për komunikim peer-to-peer. Qëllimi i tij është të gjejë rrugën më të përshtatshme direkte, duke shmangur portat e NAT dhe muret e zjarrit për komunikim peer-to-peer përmes një procesi të quajtur ICE. Si pjesë e këtij procesi, API-të WebRTC gjejnë adresën tuaj IP publike duke përdorur serverët STUN dhe e përcjellin atë te serveri rele (TURNI) kur nuk mund të vendoset një lidhje e drejtpërdrejtë.

  Megjithatë, CloudRetro nuk e shfrytëzon plotësisht këtë veçori. Lidhjet e tij peer-to-peer nuk ekzistojnë midis përdoruesve, por midis përdoruesve dhe serverëve cloud. Ana e serverit të modelit ka më pak kufizime të drejtpërdrejta të komunikimit sesa një pajisje tipike përdoruesi. Kjo ju lejon të hapni paraprakisht portet hyrëse ose të përdorni adresat IP publike drejtpërdrejt, pasi serveri nuk është prapa NAT.

  Më parë, doja ta ktheja projektin në një platformë shpërndarjeje lojërash për Cloud Gaming. Ideja ishte që të lejonin krijuesit e lojërave të ofrojnë lojëra dhe burime transmetimi. Dhe përdoruesit do të ndërveprojnë drejtpërdrejt me ofruesit. Në këtë mënyrë të decentralizuar, CloudRetro është vetëm një kornizë për lidhjen e burimeve të transmetimit të palëve të treta me përdoruesit, duke e bërë atë më të shkallëzuar kur nuk është më i pritur. Roli i WebRTC NAT Traversal këtu është shumë i rëndësishëm për të lehtësuar inicializimin e lidhjes peer-to-peer në burimet e transmetimit të palëve të treta, duke e bërë më të lehtë për krijuesin të lidhet me rrjetin.

  Kompresimi i videos

  Kompresimi i videos është një pjesë e domosdoshme e tubacionit dhe kontribuon shumë në një rrjedhje të qetë. Ndërsa nuk është e nevojshme të dini çdo detaj të kodimit të videos VP8/H264, të kuptuarit e koncepteve mund t'ju ndihmojë të kuptoni opsionet e shpejtësisë së transmetimit të videos, të korrigjoni sjelljen e papritur dhe të rregulloni vonesën.

  Kompresimi i videos për një shërbim transmetimi është sfidues sepse algoritmi duhet të sigurojë që koha totale e kodimit + koha e transmetimit të rrjetit + koha e dekodimit të jetë sa më e ulët që të jetë e mundur. Për më tepër, procesi i kodimit duhet të jetë konsistent dhe i vazhdueshëm. Disa kompromise kodimi nuk zbatohen - për shembull, ne nuk mund të favorizojmë kohët e gjata të kodimit mbi madhësitë më të vogla të skedarëve dhe kohën e deshifrimit, ose të përdorim kompresim të paqëndrueshëm.

  Ideja pas kompresimit të videos është të eliminohen pjesët e panevojshme të informacionit duke ruajtur një nivel të pranueshëm saktësie për përdoruesit. Përveç kodimit të kornizave individuale statike të imazheve, algoritmi nxjerr përfundimin e kornizës aktuale nga ato të mëparshme dhe të ardhshme, kështu që vetëm ndryshimi i tyre dërgohet. Siç shihet nga shembulli me Pacman, transmetohen vetëm pika diferenciale.

  
  Krahasimi i kornizave video duke përdorur Pacman si shembull

  Kompresimi i audios

  Po kështu, algoritmi i kompresimit të audios nuk i jep të dhëna që nuk mund të perceptohen nga njerëzit. Opus është aktualisht kodiku audio me performancën më të mirë. Është projektuar për të transmetuar një valë audio mbi një protokoll të porositur të datagramit si RTP (Real Time Transport Protocol). Vonesa e tij është më e ulët se mp3 dhe aac, dhe cilësia është më e lartë. Vonesa është zakonisht rreth 5~66,5ms.

  Pion, WebRTC në Golang

  Pengu është një projekt me burim të hapur që sjell WebRTC në Golang. Në vend të mbështjelljes së zakonshme të bibliotekave amtare C++ WebRTC, Pion është një implementim vendas Golang i WebRTC me performancë më të mirë, integrim Go dhe kontroll versioni në protokollet WebRTC.

  Biblioteka gjithashtu mundëson transmetimin me shumë integruara të shkëlqyera me vonesë nën-sekonde. Ka implementimin e vet të STUN, DTLS, SCTP, etj. dhe disa eksperimente me QUIC dhe WebAssembly. Vetë kjo bibliotekë me burim të hapur është një burim me të vërtetë i mirë mësimor me dokumentacion të shkëlqyer, zbatime të protokollit të rrjetit dhe shembuj të mrekullueshëm.

  Komuniteti Pion, i udhëhequr nga një krijues shumë i pasionuar, është mjaft i gjallë, me shumë diskutime cilësore që po zhvillohen rreth WebRTC. Nëse jeni të interesuar për këtë teknologji, bashkohuni http://pion.ly/slack – do të mësoni shumë gjëra të reja.

  Shkrimi i CloudRetro në Golang

  
  Zbatimi i një punëtori në Go

  Shkoni në kanalet në veprim

  Falë dizajnit të bukur të kanalit Go, problemet e transmetimit të ngjarjeve dhe të njëkohshme janë thjeshtuar shumë. Ashtu si në diagram, GoRoutines të ndryshme kanë shumë komponentë që funksionojnë paralelisht. Çdo komponent menaxhon gjendjen e tij dhe komunikon përmes kanaleve. Pohimi selektiv i Golang detyron një ngjarje atomike të përpunohet çdo herë në lojë (shënoni lojën). Kjo do të thotë që nuk nevojitet mbyllje për këtë dizajn. Për shembull, kur një përdorues ruan, kërkohet një pamje e plotë e gjendjes së lojës. Kjo gjendje duhet të mbetet e vazhdueshme, duke u identifikuar derisa të përfundojë ruajtja. Gjatë çdo tik-takimi të lojës, backend-i mund të trajtojë vetëm një operacion ruajtjeje ose futjeje, duke e bërë fillin e procesit të sigurt.

  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

  Ky shabllon Golang përshtatet në mënyrë të përkryer me rastin tim të përdorimit të CrowdPlay dhe Multiple Player. Duke ndjekur këtë model, të gjitha hyrjet e përdoruesit në një dhomë janë të integruara në kanalin qendror të hyrjes. Media e lojës më pas shpërndahet për të gjithë përdoruesit në të njëjtën dhomë. Në këtë mënyrë, ne arrijmë ndarjen e gjendjes së lojës midis disa seancave të lojës të përdoruesve të ndryshëm.

  
  Sinkronizimi midis seancave të ndryshme

  Disavantazhet e Golang

  Golang nuk është perfekt. Kanali është i ngadalshëm. Krahasuar me bllokimin, kanali Go është thjesht një mënyrë më e lehtë për të trajtuar ngjarjet e njëkohshme dhe të ndërlidhura, por kanali nuk ofron performancën më të mirë. Ekziston një logjikë komplekse bllokuese nën kanal. Kështu që bëra disa rregullime në zbatim, duke riaplikuar bravat dhe vlerat atomike kur zëvendësoja kanalet për të optimizuar performancën.

  Përveç kësaj, mbledhësi i plehrave në Golang është i pamenaxhuar, gjë që ndonjëherë shkakton pauza të gjata të dyshimta. Kjo ndërhyn shumë me aplikacionin e transmetimit në kohë reale.

  COG

  Projekti përdor bibliotekën ekzistuese me burim të hapur Golang VP8/H264 për kompresimin e mediave dhe Libretro për emulatorët e lojërave. Të gjitha këto biblioteka janë thjesht mbështjellës të bibliotekës C në Go duke përdorur COG. Disa nga disavantazhet janë renditur në ky postim nga Dave Cheney. Problemet që kam hasur:

  • pamundësia për të kapur një përplasje në CGO, edhe me Golang RecoveryCrash;
  • dështimi për të identifikuar pengesat e performancës kur nuk jemi në gjendje të zbulojmë probleme të detajuara në CGO.

  Përfundim

  E arrita qëllimin tim për të kuptuar shërbimet e lojërave cloud dhe krijimin e një platforme që më ndihmon të luaj lojëra nostalgjike retro me miqtë e mi në internet. Ky projekt nuk do të ishte i mundur pa bibliotekën Pion dhe mbështetjen e komunitetit Pion. Unë jam jashtëzakonisht mirënjohës për zhvillimin e tij intensiv. API-të e thjeshta të ofruara nga WebRTC dhe Pion siguruan integrim pa probleme. Prova ime e parë e konceptit u publikua në të njëjtën javë, edhe pse nuk kisha njohuri paraprake për komunikimin peer-to-peer (P2P).

  Pavarësisht nga lehtësia e integrimit, transmetimi P2P është me të vërtetë një fushë shumë komplekse në shkencën kompjuterike. Ajo duhet të merret me kompleksitetin e arkitekturave të rrjetit afatgjatë si IP dhe NAT për të krijuar një seancë peer-to-peer. Ndërsa punoja në këtë projekt, fitova shumë njohuri të vlefshme për rrjetëzimin dhe optimizimin e performancës, kështu që i inkurajoj të gjithë të provojnë ndërtimin e produkteve P2P duke përdorur WebRTC.

  CloudRetro kujdeset për të gjitha rastet e përdorimit që prisja nga perspektiva ime si një lojtar retro. Megjithatë, mendoj se ka shumë fusha në projekt që mund t'i përmirësoj, të tilla si bërja e rrjetit më të besueshëm dhe më performues, ofrimi i grafikave të lojës me cilësi më të lartë ose aftësia për të ndarë lojërat midis përdoruesve. Unë jam duke punuar shumë për këtë. Ju lutem ndiqni projekti dhe mbështeteni nëse ju pëlqen.

Burimi: www.habr.com