ПЗ як паслуга, інфраструктура як паслуга, платформа як паслуга, камунікацыйная платформа як паслуга, відэаканферэнцыі як паслуга, а што наконт хмарных гульняў як паслугі? Ужо было зроблена некалькі спроб стварэння хмарных гульняў (Cloud Gaming), напрыклад, Stadia, нядаўна запушчаная кампаніяй Google. Stadia , але ці могуць іншыя выкарыстоўваць WebRTC гэтак жа?
Тхань Нгуен (Thanh Nguyen) вырашыў праверыць гэтую магчымасць на сваім апенсорсным праекце CloudRetro. CloudRetro заснаваны на Pion, WebRTC бібліятэцы на базе Go (дзякуй з групы распрацоўшчыкаў Pion за дапамогу ў падрыхтоўцы гэтага артыкула). У дадзеным артыкуле Тхань робіць агляд архітэктуры свайго праекту, а таксама распавядае, што карыснага ён даведаўся і з якімі челенджамі сутыкнуўся падчас працы.
Уступленне
У мінулым годзе, калі Google анансаваў Stadia, мне проста знесла дах. Ідэя настолькі ўнікальная і інавацыйная, што я ўвесь час задаваўся пытаннем, як такое наогул магчыма пры існуючых тэхналогіях. Жаданне лепш разабрацца ў гэтай тэме заахвоціла мяне стварыць сваю версію апенсорснай хмарнай гульні. Вынік быў проста фантастычны. Ніжэй я хацеў бы падзяліцца працэсам працы над маім гадавым .
TLDR: кароткая слайд-версія з асноўнымі момантамі
Чаму за хмарнымі гульнямі будучыня
Я веру, што Cloud Gaming хутка стане новым пакаленнем не толькі гульняў, але і іншых абласцей інфарматыкі. Хмарныя гульні - гэта вяршыня мадэлі кліент / сервер. Такая мадэль максымізуе кіраванне бэкэндам і мінімізуе працу фронтэнда за кошт размяшчэння гульнявой логікі на выдаленым серверы і струменевай перадачы малюнкаў / аўдыё кліенту. Сервер выконвае цяжкую апрацоўку, таму кліент больш не залежыць ад апаратных абмежаванняў.
Google Stadia, па сутнасці, дазваляе гуляць у (г.зн. высакакласныя гульні-блокбастары) на інтэрфейсе накшталт YouTube. Тая ж метадалогія можа быць прыменена і да іншых цяжкіх афлайнавых прыкладанняў, такім як аперацыйная сістэма або 2D/3D графічны дызайн і г.д. каб мы маглі стабільна запускаць іх на прыладах з нізкімі тэхнічнымі характарыстыкамі на розных платформах.
Будучыня гэтай тэхналогіі: уяўляеце, калі б Microsoft Windows 10 працаваў у браўзэры Chrome?
Хмарныя гульні тэхнічна складаныя
Геймінг - адна з тых рэдкіх абласцей, дзе патрабуецца пастаянная хуткая рэакцыя карыстальніка. Калі зрэдку мы сустракаемся з затрымкай у 2 секунды пры кліку на старонцы, гэта прымальна. Відэаструмені ў прамым эфіры, як правіла, адстаюць на некалькі секунд, але ўсё роўна прапануюць дастатковую зручнасць у выкарыстанні. Аднак, калі гульня часта затрымоўваецца на 500 мс, гуляць проста немагчыма. Наша мэта - дасягнуць надзвычай нізкай затрымкі, каб разрыў паміж уводам і медыя быў як мага менш. Таму традыцыйны падыход да струменевага відэа тут непрымяняльны.
Агульны шаблон хмарнай гульні
Апенсорсны праект CloudRetro
Я вырашыў стварыць тэставы ўзор хмарнай гульні, каб праверыць, ці магчыма ўсё гэта пры такіх цвёрдых сеткавых абмежаваннях. Для праверкі канцэпцыі я абраў Golang, паколькі гэта найбольш знаёмая мне мова і добра прыдатны для дадзенай рэалізацыі па многіх іншых прычынах, як высветлілася пазней. Go просты і развіваецца вельмі хутка; каналы ў Go выдатна падыходзяць для кіравання шматструменнасцю.
праект - хмарны гульнявой сэрвіс з адкрытым зыходным кодам для рэтра-гульні. Мэта праекта - прыўнесці ў традыцыйныя рэтра-гульні найбольш камфортныя гульнявыя адчуванні і дадаць мультыплэер.
Падрабязна азнаёміцца з праектам можна тут: .
Функцыянальнасць CloudRetro
Для дэманстрацыі ўсёй моцы хмарных гульняў у CloudRetro выкарыстоўваюцца рэтра-гульні. Што дазваляе атрымаць мноства ўнікальных гульнявых уражанняў.
- Партатыўнасць гульні
- Імгненнае ўзнаўленне пры адкрыцці старонкі; загрузка і ўстаноўка не патрэбны
- Працуе ў мабільным браўзэры, так што для запуску не трэба ніякае праграмнае забеспячэнне
- Гульнявыя сеансы можна сумесна выкарыстоўваць на некалькіх прыладах і захоўваць у воблаку для наступнага ўваходу
- Гульню можна стрымаць, а можна гуляць у яе адразу некалькімі карыстальнікамі:
- Crowdplay тыпу TwitchPlayPokemon, толькі больш кросплатформавы і больш рыялтаймавы
- Афлайн гульні ў анлайне. Гуляць могуць шмат карыстальнікаў без наладкі сеткі. У Samurai Shodown зараз можна гуляць 2 гульцам па сетцы CloudRetro
Дэма-версія шматкарыстальніцкай анлайн-гульні на розных прыладахІнфраструктура
Патрабаванні і стэк тэхналогій
Ніжэй прыведзены спіс патрабаванняў, якія я ўстанавіў перад пачаткам праекта.
1. Адзін гулец
Гэтае патрабаванне можа здацца не занадта важным і відавочным тут, але гэта адна з маіх ключавых высноваў, гэта дазваляе хмарным гульням трымацца як мага далей ад традыцыйных струменевых сэрвісаў. Калі мы засяродзімся на аднакарыстальніцкай гульні, мы зможам пазбавіцца ад цэнтралізаванага сервера або CDN, таму што нам не трэба рабіць струменевую перадачу ў масы. Замест таго, каб загружаць патокі на паглынальны сервер або перадаваць пакеты на цэнтралізаваны сервер WebSocket, сэрвісныя патокі перадаюцца карыстачу напрамую праз аднарангавае злучэнне WebRTC.2. Медыяпаток з нізкай затрымкай
Чытаючы пра Stadia, я часта сустракаю ў некаторых артыкулах згадка WebRTC. Я зразумеў, што WebRTC - выбітная тэхналогія, і яна выдатна падыходзіць для выкарыстання ў хмарных гульнях. WebRTC – гэта праект, які дае вэб-браўзэрам і мабільным дадаткам сувязь у рэальным часе праз просты API. Ён забяспечвае аднарангавае злучэнне, аптымізаваны для медыя і мае убудаваныя стандартныя кодэкі, такія як VP8 і H264.Я аддаў перавагу забеспячэнню максімальна камфортнай працы карыстальнікаў, а не захаванню высокай якасці графікі. У алгарытме дапушчальныя некаторыя страты. У Google Stadia ёсць дадатковы крок па памяншэнні памеру выявы на серверы, і кадры маштабуюцца да больш высокай якасці перад перадачай аднарангавым вузлам.
3. Размеркаваная інфраструктура з геаграфічнай маршрутызацыяй
Незалежна ад таго, наколькі аптымізаваны алгарытм сціску і код, сетка ўсё роўна з'яўляецца вырашальным фактарам, які больш за ўсё спрыяе затрымцы. Архітэктура павінна мець механізм спалучэння бліжэйшага да карыстача сервера для скарачэння часу прыёму-перадачы (RTT). Архітэктура павінна мець 1 каардынатара і некалькі струменевых сервераў, размеркаваных па ўсім свеце: Захад ЗША, Усход ЗША, Еўропа, Сінгапур, Кітай. Усе струменевыя серверы павінны быць цалкам ізаляваныя. Сістэма можа рэгуляваць сваё размеркаванне, калі сервер далучаецца да сеткі ці выходзіць з яе. Такім чынам, пры вялікім трафіку, даданне дадатковых сервераў дазваляе ажыццяўляць гарызантальнае маштабаванне.4. Браўзэрная сумяшчальнасць
Воблачнае гульні паўстаюць у найлепшым святле, калі патрабуе ад карыстачоў па мінімуме. Гэта значыць, што ёсць магчымасць запуску ў браўзэры. Браўзэры дапамагаюць зрабіць гульнявы працэс максімальна камфортным для карыстачоў, пазбавіўшы іх ад усталёўкі праграмнага і апаратнага забеспячэння. Браўзэры таксама дапамагаюць забяспечыць крос-платформеннасць для мабільных і дэсктопных версій. На шчасце, WebRTC выдатна падтрымліваецца ў розных браўзэрах.5. Выразны падзел гульнявога інтэрфейсу і сэрвісу
Я разглядаю сэрвіс хмарных гульняў як платформу. У кожнага павінна быць магчымасць падлучаць да платформы што заўгодна. Цяпер я інтэграваў з сэрвісам хмарных гульняў, таму што LibRetro прапануе прыгожы інтэрфейс гульнявога эмулятара для рэтра-гульняў, такіх як SNES, GBA, PS.6. Пакоі для мультыплэера, crowd play і вонкавае звязванне (deep-link) з гульнёй
CloudRetro падтрымлівае мноства новых геймплэяў, такіх як CrowdPlay і Online MultiPlayer для рэтра-гульняў. Калі некалькі карыстачоў адкрыюць адзін і той жа deep-link на розных кампутарах, яны ўбачаць адну і тую ж запушчаную гульню і нават змогуць далучыцца да яе.Больш за тое, станы гульні захоўваюцца ў хмарным сховішчы. Гэта дазваляе карыстальнікам працягваць гульню ў любы час на любой іншай прыладзе.
7. Гарызантальнае маштабаванне
Як і любы SAAS у цяперашні час, хмарныя гульні павінны быць спраектаваны так, каб быць гарызантальна якія маштабуюцца. Канструкцыя "каардынатар-воркер" дазваляе дадаваць больш воркераў, каб абслугоўваць большы трафік.8. Няма прывязкі да аднаго воблаку
Інфраструктура CloudRetro размяшчаецца на розных хмарных правайдэрах (Digital Ocean, Alibaba, карыстацкі правайдэр) для розных рэгіёнаў. Я актывую запуск у кантэйнеры Docker для інфраструктуры і наладжваю сеткавыя параметры з дапамогай bash-скрыпту, каб пазбегнуць залежнасці ад аднаго хмарнага правайдэра. Спалучаючы гэта з NAT Traversal у WebRTC, мы можам атрымаць гнуткасць для разгортвання CloudRetro на любой хмарнай платформе і нават на машынах любога карыстача.Архітэктурны дызайн
Воркер: (або струменевы сервер, згаданы вышэй) памнажае гульні, запускае кадавальны пайплайн і перадае закадаванае медыя карыстачам. Інстансы воркера распаўсюджваюцца па ўсім свеце, і кожны воркер можа апрацоўваць некалькі карыстацкіх сесій адначасова.
Каардынатар: адказвае за спалучэнне новага карыстальніка з найбольш прыдатным воркерам для струменевай перадачы. Каардынатар узаемадзейнічае з воркерамі праз WebSocket.
Сховішча гульнявых станаў: цэнтральнае выдаленае сховішча для ўсіх станаў гульні. Гэтае сховішча забяспечвае такія важныя функцыі, як, напрыклад, выдаленае захаванне/загрузка.
Верхнеўзроўневая архітэктура CloudRetroКарыстацкі сцэнар
Калі новы карыстач адчыняе CloudRetro на кроках 1 і 2, паказаных на малюнку ніжэй, каардынатар разам са спісам даступных воркераў запытваецца на першую старонку. Пасля гэтага на этапе 3 кліент разлічвае затрымкі для ўсіх кандыдатаў з дапамогай HTTP запыту ping. Гэты спіс затрымак затым адпраўляецца зваротна каардынатару, каб ён мог вызначыць найболей падыходнага воркера для абслугоўвання карыстача. На кроку 4 ніжэй ствараецца гульня. Паміж карыстачом і прызначаным воркерам усталёўваецца струменевае злучэнне WebRTC.
Карыстацкі сцэнар пасля атрымання доступуШто ўнутры воркера
Гульнявыя і струменевыя пайплайны захоўваюцца ўсярэдзіне воркера ізалявана і абменьваюцца там інфармацыяй праз інтэрфейс. У цяперашні час гэтая сувязь ажыццяўляецца з дапамогай перадачы дадзеных у памяці па у тым жа працэсе. Наступнай мэтай з'яўляецца сегрэгацыя, г.зн. незалежны запуск гульні ў іншым працэсе.
Узаемадзеянне кампанентаў воркераАсноўныя складнікі:
- WebRTC: кліенцкі кампанент, які прымае карыстацкі ўвод і выводзіць закадаванае медыя з сервера.
- Гульнявы эмулятар: гульнявы кампанент. Дзякуючы бібліятэцы Libretro сістэма здольная запускаць гульню ўсярэдзіне аднаго і таго ж працэсу і ўнутрана перахапляць медыя і струмень уводу.
- Нутрагульнявыя кадры захопліваюцца і адпраўляюцца ў кадавальнік.
- Выява/аўдыё кадавальнік: кадавальны пайплайн, які прымае медыякадры, кадуе іх у фонавым рэжыме і выводзіць закадаваныя выявы/аўдыё.
Рэалізацыя
CloudRetro належыць на WebRTC як на магістральную тэхналогію, таму перад тым, як паглыбіцца ў падрабязнасці рэалізацыі на Golang, я вырашыў расказаць аб самім WebRTC. Гэта неверагодная тэхналогія, якая моцна дапамагла мне ў дасягненні затрымкі струменевай перадачы дадзеных роўнай усяго толькі дзелі секунды.
WebRTC
WebRTC прызначаны для забеспячэння высакаякасных аднарангавых злучэнняў на натыўным мабільным дадатку і ў браўзэрах з дапамогай простых API.
Праходжанне NAT
WebRTC вядомы сваёй функцыянальнасцю NAT Traversal. WebRTC прызначаны для аднарангавай камунікацыі. Яго мэта - знайсці найбольш прыдатны прамы маршрут, пазбягаючы NAT-шлюзаў і брандмаўэраў для аднарангавай сувязі праз працэс пад назвай . У рамках гэтага працэсу API WebRTC знаходзяць ваш публічны IP-адрас з дапамогай сервераў STUN і пераадрасоўваюць яго на сервер рэтрансляцыі (), калі прамое злучэнне не можа быць устаноўлена.
Аднак CloudRetro не поўнасцю выкарыстоўвае гэтую магчымасць. Яго аднарангавыя злучэнні існуюць не паміж карыстальнікамі, а паміж карыстальнікамі і хмарнымі серверамі. Серверная частка мадэлі мае менш абмежаванняў на прамую сувязь, чым звычайная карыстацкая прылада. Гэта дазваляе рабіць папярэдняе адкрыццё ўваходных портаў або выкарыстанне публічных IP-адрасоў напрамую, бо сервер не знаходзіцца за NAT.
Раней я хацеў ператварыць праект у платформу распаўсюджвання гульняў для Cloud Gaming. Ідэя складалася ў тым, каб дазволіць стваральнікам гульняў падаваць гульні і струменевыя рэсурсы. А карыстачы ўзаемадзейнічалі б з правайдэрамі напроста. У такой дэцэнтралізаванай манеры CloudRetro з'яўляецца ўсяго толькі асяроддзем для падлучэння іншых струменевых рэсурсаў да карыстачоў, што робіць яго больш які маштабуецца, калі на ім больш не вісіць хостынг. Роля WebRTC NAT Traversal тут вельмі важная для палягчэння ініцыялізацыі аднарангавага злучэння на іншых струменевых рэсурсах, што спрашчае падлучэнне стваральніка да сеткі.
Сціск відэа
Сціск відэа - гэта незаменная частка пайплайн, якая ў значнай ступені спрыяе плыўнасці патоку. Нягледзячы на тое, што не абавязкова ведаць усе дэталі кадавання відэа ў VP8/H264, разуменне канцэпцыі дапамагае разбірацца ў параметрах хуткасці струменевага відэа, адладжваць нечаканыя паводзіны і наладжваць затрымку.
Сціск відэа для струменевага сэрвісу з'яўляецца складанай задачай, таму што алгарытм павінен гарантаваць, што агульны час кадавання + час перадача па сетцы + час дэкадавання настолькі мала, наколькі гэта магчыма. Акрамя таго, працэс кадавання павінен быць паслядоўным і бесперапынным. Некаторыя ўзаемныя саступкі пры кадаванні не дастасавальныя - напрыклад, мы не можам аддаць перавагу працяглы час кадавання меншаму памеру файла і часу дэкадавання, або выкарыстоўваць непаслядоўны сціск.
Ідэя сціску відэа складаецца ў тым, каб выключыць непатрэбныя біты інфармацыі, захоўваючы пры гэтым дапушчальны ўзровень дакладнасці для карыстачоў. Акрамя кадавання асобных статычных кадраў выявы, алгарытм робіць выснову для бягучага кадра з папярэдняга і наступнага, таму пасылаецца толькі іх розніца. Як відаць з прыкладу c Pacman'ом, перадаюцца толькі дыферэнцыяльныя кропкі.
Параўнанне відэакадраў на прыкладзе PacmanСціск аўдыё
Аналагічным чынам, алгарытм сціску гуку апускае дадзеныя, якія не могуць быць успрыняты чалавекам. Opus на дадзены момант з'яўляецца аўдыёкодэкам з найлепшай прадукцыйнасцю. Ён распрацаваны для перадачы аўдыёхвалі па пратаколе спарадкаванай датаграмы, такому як RTP (Real Time Transport Protocol – пратакол перадачы трафіку рэальнага часу). Яго затрымка меншая, чым у mp3 і aac, а якасць вышэйшая. Затрымка звычайна складае каля 5-66,5 мс.
Pion, WebRTC у Golang
– гэта праект з адчыненым зыходным кодам, які перацягвае WebRTC на Golang. Замест звычайнага ўрапінгу натыўных C++ бібліятэк WebRTC, Pion з'яўляецца натыўнай Golang-рэалізацыяй WebRTC з лепшай прадукцыйнасцю, інтэграцыяй з Go, а таксама кантролем версій на пратаколах WebRTC.
Бібліятэка таксама забяспечвае струменевую перадачу дадзеных з вялікай колькасцю выдатных убудаваных модуляў з затрымкай менш за секунду. Яна мае ўласную рэалізацыю STUN, DTLS, SCTP і г.д. і некаторыя эксперыменты з QUIC і WebAssembly. Сама па сабе гэтая апенсорсная бібліятэка з'яўляецца сапраўды добрай крыніцай навучання з выдатнай дакументацыяй, рэалізацыяй сеткавых пратаколаў і класнымі прыкладамі.
Кам'юніці Pion, узначаленае вельмі гарачым стваральнікам, даволі ажыўленае, тамака вядзецца шмат якасных дыскусій аб WebRTC. Калі вас цікавіць гэтая тэхналогія, далучайцеся да - вы даведаецеся шмат новага.
Напісанне CloudRetro на Golang
Рэалізацыя воркера на GoКаналы Go у дзеянні
Дзякуючы прыгожаму дызайну каналаў Go, праблемы струменевай перадачы падзей і паралелізму значна спрашчаюцца. Як і на дыяграме, у розных GoRoutines раўналежна працуюць некалькі кампанентаў. Кожны кампанент кіруе сваім станам і мае зносіны па каналах. Выбарачнае зацвярджэнне Golang прымушае апрацаваць па адной атамарнай падзеі кожны момант часу ў гульні (game tick). Гэта азначае, што для такога дызайну блакаванне не патрэбна. Напрыклад, калі карыстач захоўваецца, патрабуецца поўны снэпшот стану гульні. Гэты стан павінен заставацца бесперапынным, выконваючы ўваход да таго часу, пакуль захаванне не будзе завершана. Падчас кожнага game tick'а бэкэнд можа апрацоўваць толькі аперацыю захавання ці ўводу, што робіць працэс струменебяспечным.
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 выдатна падыходзіць для майго сцэнара выкарыстання CrowdPlay і Multiple Player. Прытрымліваючыся гэтага шаблону, усе карыстацкія ўваходы ў адным пакоі ўбудоўваюцца ў цэнтральны ўваходны канал. Гульнявыя медыя затым разгортваюцца на ўсіх карыстачоў у адным пакоі. Такім чынам, мы дасягаем падзелу стану гульні паміж некалькімі гульнявымі сесіямі розных карыстачоў.
Сінхранізацыя паміж рознымі сеансаміНедахопы Golang
Golang не дасканалы. Канал павольны. У параўнанні з блакіроўкай канал Go - гэта проста больш просты спосаб апрацоўкі паралельных і струменевых падзей, але канал не дае найлепшай прадукцыйнасці. Пад каналам ёсць складаная логіка блакіроўкі. Таму я ўнёс некаторыя карэктывы ў рэалізацыю, паўторна прымяніўшы блакіроўкі і атамарныя значэння пры замене каналаў для аптымізацыі прадукцыйнасці.
Акрамя таго, garbage collector у Golang некіравальны, з-за чаго часам узнікаюць падазроныя доўгія паўзы. Гэта моцна замінае працы струменевага прыкладання ў рэальным часе.
COG
У праекце выкарыстоўваецца існуючая VP8/H264 бібліятэка Golang з адчыненым зыходным кодам для сціску медыя і Libretro для гульнявых эмулятараў. Усе гэтыя бібліятэкі з'яўляюцца проста абгорткамі бібліятэкі C у Go з выкарыстаннем . Некаторыя з недахопаў пералічаны ў . Праблемы, з якімі я сутыкнуўся:
- немагчымасць злавіць краш у CGO, нават з дапамогай Golang RecoveryCrash;
- немагчымасць вызначыць вузкае месца ў прадукцыйнасці, калі мы не можам выявіць дэталізаваныя праблемы ў CGO.
Заключэнне
Я дасягнуў сваёй мэты - разабраўся ў хмарных гульнявых сэрвісах і стварыў платформу, якая дапамагае гуляць у настальгічныя рэтра-гульні з маімі сябрамі анлайн. Стварэнне гэтага праекту было б немагчымым без бібліятэкі Pion і падтрымкі супольнасці Pion. Я надзвычай удзячны за яго інтэнсіўнае развіццё. Простыя API, прадстаўленыя WebRTC і Pion, забяспечылі плыўную інтэграцыю. Мой першы доказ канцэпцыі быў выпушчаны на тым жа тыдні, нягледзячы на тое, што я загадзя не ведаў аб аднарангавай сувязі (P2P).
Нягледзячы на прастату інтэграцыі, P2P-струменевае вяшчанне сапраўды з'яўляецца вельмі складанай вобласцю ў кампутарнай навуцы. Ёй даводзіцца мець справу са складанасцю шматгадовых сеткавых архітэктур, такіх як IP і NAT для стварэння аднарангавай сесіі. За час працы над гэтым праектам я назапасіў шмат каштоўных ведаў аб сетцы і аптымізацыі прадукцыйнасці, таму рэкамендую ўсім паспрабаваць пабудаваць P2P-прадукты з дапамогай WebRTC.
CloudRetro абслугоўвае ўсе сцэнары выкарыстання, якія я чакаў, з майго пункту гледжання, як рэтра-геймера. Тым не менш, я думаю, што ёсць шмат абласцей у праекце, якія я магу палепшыць, напрыклад, зрабіць сетку больш надзейнай і прадукцыйнай, забяспечыць больш высокую якасць графікі гульняў, або магчымасць дзяліцца гульнямі паміж карыстальнікамі. Я ўпарта працую над гэтым. Калі ласка, сачыце за і падтрымайце яго, калі ён вам падабаецца.
Крыніца: habr.com