Облак игри со отворен код на WebRTC: p2p, мултиплеер, нула латентност

Софтвер како услуга, инфраструктура како услуга, платформа како услуга, комуникациска платформа како услуга, видео конференции како услуга, што е со облак игрите како услуга? Веќе имаше неколку обиди за создавање облак игри (Cloud Gaming), како што е Stadia, неодамна лансирана од Google. Стадиа не е ново за WebRTC, но дали другите можат да користат WebRTC на ист начин?

Тан Нгуен реши да ја тестира оваа можност на неговиот проект со отворен код CloudRetro. CloudRetro е базиран на Pion, популарна WebRTC библиотека базирана на Go (благодарам Прикажани од тимот за развој на Pion за нивната помош при подготовката на овој напис). Во оваа статија, Тан дава преглед на архитектурата на неговиот проект, а исто така зборува за тоа кои корисни работи ги научил и со какви предизвици наишол во текот на неговата работа.

Влегување

Минатата година, кога Google ја објави Stadia, ми го разнесе паметот. Идејата е толку уникатна и иновативна што постојано се прашував како тоа воопшто е можно со постоечката технологија. Желбата подобро да ја разберам оваа тема ме поттикна да создадам своја сопствена верзија на игра во облак со отворен код. Резултатот беше едноставно фантастичен. Подолу би сакал да го споделам процесот на работа на мојата година проект.

TLDR: кратка слајд верзија со нагласувања

Зошто облак игрите се иднината

Верувам дека Cloud Gaming наскоро ќе стане следната генерација на не само игри, туку и други области од компјутерската наука. Играњето во облак е врв на моделот клиент/сервер. Овој модел го максимизира управувањето со задниот дел и ја минимизира работата на предниот дел со хостирање на логиката на играта на оддалечен сервер и проследување слики/аудио до клиентот. Серверот врши тешка обработка, така што клиентот повеќе не е на милост и немилост на хардверските ограничувања.

Google Stadia во суштина ви овозможува да играте ААА игри (т.е. врвни блокбастер игри) на интерфејс како YouTube. Истата методологија може да се примени и на други тешки офлајн апликации како оперативен систем или 2D/3D графички дизајн итн. за да можеме постојано да ги извршуваме на уреди со ниски спецификации на повеќе платформи.

Иднината на оваа технологија: Замислете ако Microsoft Windows 10 работи на прелистувачот Chrome?

Играњето во облак е технички предизвик

Игрите се една од оние ретки области каде што е потребен постојан, брз одговор на корисникот. Ако повремено наидеме на доцнење од 2 секунди при кликнување на страница, тоа е прифатливо. Видео преносите во живо имаат тенденција да заостануваат неколку секунди, но сепак нудат разумна употребливост. Меѓутоа, ако играта често заостанува за 500 ms, таа едноставно не може да се игра. Нашата цел е да постигнеме екстремно ниска латентност, така што јазот помеѓу влезот и медиумот е што е можно помал. Затоа, традиционалниот пристап за видео стриминг не е применлив овде.

Шаблон за игри за генерален облак

Проект со отворен код CloudRetro

Решив да создадам примерок за тестирање на игра во облак за да видам дали сето ова е можно со толку строги ограничувања на мрежата. Го избрав Golang за докажување на концептот бидејќи тоа беше јазикот со кој најмногу бев запознаен и беше добро прилагоден за оваа имплементација од многу други причини, како што подоцна открив. Go е едноставен и се развива многу брзо; Каналите во Go се одлични за управување со повеќенишки.

Проект CloudRetro.io е услуга за облак игри со отворен код за ретро игри. Целта на проектот е да се донесе најудобното гејмерско искуство во традиционалните ретро игри и да се додаде мултиплеер.
Можете да дознаете повеќе за проектот овде: https://github.com/giongto35/cloud-game.

CloudRetro функционалност

CloudRetro користи ретро игри за да ја покаже моќта на игрите во облак. Што ви овозможува да добиете многу уникатни искуства со игри.

• Преносливост на играта
  • Инстант репродукција при отворање на страница; не е потребно преземање или инсталација
  • Работи во мобилен прелистувач, така што не е потребен софтвер за да се стартува

• Сесиите за игри може да се споделат на повеќе уреди и да се складираат во облакот за следниот пат кога ќе се најавите
• Играта може да се емитува или може да ја играат неколку корисници одеднаш:
  • Crowdplay како TwitchPlayPokemon, само повеќе меѓу-платформски и повеќе во реално време
  • Офлајн игри онлајн. Многу корисници можат да играат без да поставуваат мрежа. Samurai Shodown сега може да го играат 2 играчи преку мрежата CloudRetro

  
  Демо верзија на онлајн игра со повеќе играчи на различни уреди

  Инфраструктура

  Барања и технолошки оџак

  Подолу е листа на барања што ги поставив пред да започнам со проектот.

  1. Еден играч
  Ова барање можеби не изгледа премногу важно или очигледно овде, но тоа е еден од моите клучни моменти, овозможува облак игрите да останат што подалеку од традиционалните услуги за стриминг. Ако се фокусираме на игра за еден играч, можеме да се ослободиме од централизиран сервер или CDN затоа што не мораме да пренесуваме до масите. Наместо прикачување на преноси на сервер за мијалник или пренесување пакети на централизиран WebSocket сервер, преносите на услуги се доставуваат директно до корисникот преку peer-to-peer WebRTC конекција.

  2. Проток на медиуми со ниска латентност
  Читајќи за Stadia, често гледам WebRTC да се споменува во некои написи. Сфатив дека WebRTC е извонредна технологија и е совршена за употреба во облак игри. WebRTC е проект кој им овозможува на веб-прелистувачите и мобилните апликации комуникација во реално време преку едноставен API. Обезбедува peer-to-peer поврзување, оптимизиран е за медиуми и има вградени стандардни кодеци како VP8 и H264.

  Дадов приоритет на обезбедувањето на најдоброто можно корисничко искуство пред одржувањето на висококвалитетна графика. Некои загуби се прифатливи во алгоритмот. Google Stadia има дополнителен чекор за намалување на големината на сликата на серверот, а кадрите се зголемуваат до повисок квалитет пред да се пренесат на врсниците.

  3. Дистрибуирана инфраструктура со географско рутирање
  Без разлика колку се оптимизирани алгоритмот и кодот за компресија, мрежата е сепак одлучувачкиот фактор кој најмногу придонесува за латентноста. Архитектурата мора да има механизам за спарување на серверот најблиску до корисникот за да се намали времето за повратен пат (RTT). Архитектурата мора да има 1 координатор и неколку сервери за стриминг дистрибуирани низ целиот свет: САД Запад, САД Исток, Европа, Сингапур, Кина. Сите сервери за стриминг мора да бидат целосно изолирани. Системот може да ја прилагоди својата дистрибуција кога серверот се приклучува или ја напушта мрежата. Така, со голем сообраќај, додавањето дополнителни сервери овозможува хоризонтално скалирање.

  4. Компатибилност со прелистувачот
  Играњето во облак е најдобро кога бара најмалку од корисниците. Ова значи дека е можно да се изврши во прелистувач. Прелистувачите им помагаат на корисниците да го направат искуството со игри што е можно поудобно, заштедувајќи ги од инсталирање софтвер и хардвер. Прелистувачите исто така помагаат да се обезбеди меѓуплатформска функционалност помеѓу мобилните и десктоп верзиите. За среќа, WebRTC е добро поддржан во различни прелистувачи.

  5. Јасно одвојување на интерфејсот и услугата на играта
  Ја гледам услугата за игри во облак како платформа. Секој треба да може да поврзе што било на платформата. Сега се интегрирав LibRetro со услугата за облак игри бидејќи LibRetro нуди прекрасен интерфејс за емулатор на игри за ретро игри како што се SNES, GBA, PS.

  6. Простории за мултиплеер, игра на гужва и надворешно поврзување (длабока врска) со играта
  CloudRetro поддржува многу нови игри, како што се CrowdPlay и Online Multiplayer за ретро игри. Ако неколку корисници отворат иста длабока врска на различни компјутери, тие ќе ја видат истата игра што работи, па дури и ќе може да и се придружат.

  Покрај тоа, состојбите на играта се зачувуваат во складирање на облак. Ова им овозможува на корисниците да продолжат да играат во секое време на кој било друг уред.

  7. Хоризонтално скалирање
  Како и секој SAAS во денешно време, игрите во облак мора да бидат дизајнирани да бидат хоризонтално скалабилни. Дизајнот координатор-работник ви овозможува да додадете повеќе работници за да опслужувате поголем сообраќај.

  8. Нема врска со еден облак
  Инфраструктурата на CloudRetro е хостирана на различни даватели на облак (Digital Ocean, Alibaba, прилагоден провајдер) за различни региони. Овозможувам работа во контејнер на Docker за инфраструктурата и ги конфигурирам мрежните поставки користејќи баш скрипта за да изберам да бидам заклучен во еден провајдер на облак. Со комбинирање на ова со NAT Traversal во WebRTC, можеме да имаме флексибилност да го распоредиме CloudRetro на која било облак платформа, па дури и на машините на секој корисник.

  Архитектонски дизајн

  Работник: (или серверот за стриминг споменат погоре) ги множи игрите, ја води линијата за кодирање и ги пренесува шифрираните медиуми до корисниците. Работничките примероци се дистрибуираат низ целиот свет и секој работник може да се справи со повеќе кориснички сесии истовремено.

  Координатор: е одговорен за спарување на новиот корисник со најсоодветниот работник за пренос. Координаторот комуницира со работниците преку WebSocket.

  Складирање на состојбата на играта: централно далечинско складирање за сите состојби на играта. Ова складирање обезбедува важни функции како далечинско зачувување/вчитување.

  
  Архитектура на највисоко ниво на CloudRetro

  Прилагодена скрипта

  Кога нов корисник ќе го отвори CloudRetro во чекорите 1 и 2 прикажани на сликата подолу, координаторот заедно со списокот на достапни работници се бара на првата страница. По ова, во чекор 3 клиентот ги пресметува доцнењата за сите кандидати користејќи барање за пинг HTTP. Оваа листа на одложувања потоа се испраќа назад до координаторот за да може да го одреди најсоодветниот работник за да му служи на корисникот. Чекор 4 подолу ја креира играта. Помеѓу корисникот и доделениот работник е воспоставена врска за стриминг WebRTC.
  
  Корисничка скрипта по добивањето пристап

  Што има внатре во работникот

  Нафтоводите за игри и стриминг се чуваат во работникот изолирано и разменуваат информации таму преку интерфејсот. Во моментов, оваа комуникација се врши со пренос на податоци во меморијата преку Голанг канали во истиот процес. Следна цел е сегрегација, т.е. независно лансирање на играта во друг процес.

  
  Интеракција на работничките компоненти

  Главни компоненти:

  • WebRTC: клиентска компонента која прифаќа кориснички влез и излегува кодирани медиуми од серверот.
  • Емулатор за игри: компонента на играта. Благодарение на библиотеката Libretro, системот може да ја води играта во истиот процес и внатрешно да ги пресретнува медиумите и влезниот поток.
  • Рамките во играта се снимаат и се испраќаат до енкодерот.
  • Кодер за слика/аудио: цевковод за кодирање што зема медиумски рамки, ги кодира во позадина и излегува кодирани слики/аудио.

  Реализация

  CloudRetro се потпира на WebRTC како нејзина технологија на 'рбетот, па пред да се фрлам во деталите за имплементацијата на Golang, решив да зборувам за самиот WebRTC. Ова е неверојатна технологија која многу ми помогна да постигнам доцнење во секунда за пренос на податоци.

  WebRTC

  WebRTC е дизајниран да обезбеди висококвалитетни peer-to-peer врски на домашните мобилни апликации и прелистувачи користејќи едноставни API.

  NAT Traversal

  WebRTC е познат по својата NAT Traversal функционалност. WebRTC е дизајниран за peer-to-peer комуникација. Неговата цел е да ја најде најсоодветната директна рута, избегнувајќи ги NAT портите и заштитните ѕидови за peer-to-peer комуникација преку процес т.н. ICE. Како дел од овој процес, WebRTC API-ите ја наоѓаат вашата јавна IP адреса користејќи STUN сервери и ја проследуваат до релејниот сервер (ВРЕМЕ) кога не може да се воспостави директна врска.

  Сепак, CloudRetro не ја искористува целосно оваа функција. Неговите peer-to-peer врски не постојат помеѓу корисниците, туку помеѓу корисниците и облак серверите. На страната на серверот на моделот има помалку директни ограничувања за комуникација од типичен кориснички уред. Ова ви овозможува однапред да ги отворите дојдовните порти или директно да ги користите јавните IP адреси, бидејќи серверот не стои зад NAT.

  Претходно, сакав да го претворам проектот во платформа за дистрибуција на игри за Cloud Gaming. Идејата беше да им се дозволи на креаторите на игри да обезбедат игри и ресурси за стриминг. И корисниците директно би комуницирале со провајдерите. На овој децентрализиран начин, CloudRetro е само рамка за поврзување на ресурсите за стриминг од трети страни со корисниците, што го прави поскалабилен кога веќе не е хостиран. Улогата на WebRTC NAT Traversal овде е многу важна за да се олесни иницијализацијата на peer-to-peer конекција на ресурсите за стриминг од трета страна, што го олеснува поврзувањето на креаторот на мрежата.

  Видео компресија

  Видео компресијата е незаменлив дел од цевководот и во голема мера придонесува за непречен проток. Иако не е неопходно да се знае секој детал од кодирањето на видеото VP8/H264, разбирањето на концептите може да ви помогне да ги разберете опциите за брзина на стриминг видео, да дебагирате неочекувано однесување и да ја прилагодите латентноста.

  Компресирањето на видеото за услуга за стриминг е предизвик бидејќи алгоритмот мора да осигура дека вкупното време на кодирање + време на пренос на мрежа + време на декодирање е што е можно пониско. Покрај тоа, процесот на кодирање мора да биде конзистентен и континуиран. Некои компромиси за кодирање не се применуваат - на пример, не можеме да ги фаворизираме долгите времиња на кодирање пред помалите големини на датотеки и времињата на декодирање или да користиме неконзистентна компресија.

  Идејата зад компресија на видеото е да се елиминираат непотребните делови од информации додека се одржува прифатливо ниво на точност за корисниците. Покрај кодирањето на поединечни статични рамки на слики, алгоритмот ја заклучува тековната рамка од претходната и следната, така што се испраќа само нивната разлика. Како што може да се види од примерот со Pacman, се пренесуваат само диференцијални точки.

  
  Споредба на видео рамки користејќи Pacman како пример

  Аудио компресија

  Слично на тоа, алгоритмот за компресија на аудио ги испушта податоците што луѓето не можат да ги перцепираат. Opus моментално е аудио кодек со најдобри перформанси. Тој е дизајниран да пренесува аудио бран преку нарачан протокол за датаграм како што е RTP (Real Time Transport Protocol). Неговата латентност е помала од mp3 и aac, а квалитетот е повисок. Латентноста е обично околу 5~66,5ms.

  Pion, WebRTC во Голанг

  Пион е проект со отворен код кој го носи WebRTC во Golang. Наместо вообичаеното завиткување на природните библиотеки на C++ WebRTC, Pion е домашна Golang имплементација на WebRTC со подобри перформанси, Go интеграција и контрола на верзијата на протоколите WebRTC.

  Библиотеката, исто така, овозможува стриминг со многу одлични вградени со под-втора латентност. Има своја имплементација на STUN, DTLS, SCTP итн. и некои експерименти со QUIC и WebAssembly. Оваа библиотека со отворен код сама по себе е навистина добар ресурс за учење со одлична документација, имплементација на мрежен протокол и одлични примери.

  Заедницата на Pion, предводена од многу страстен креатор, е доста жива, со многу квалитетни дискусии кои се водат за WebRTC. Доколку сте заинтересирани за оваа технологија, придружете се http://pion.ly/slack – ќе научите многу нови работи.

  Пишување CloudRetro на Golang

  
  Имплементација на работник во Го

  Одете на канали во акција

  Благодарение на прекрасниот дизајн на каналот на Go, проблемите со преносот на настани и истовременото се значително поедноставени. Како и на дијаграмот, различни GoRoutines имаат повеќе компоненти кои работат паралелно. Секоја компонента управува со својата состојба и комуницира преку канали. Селективното тврдење на Голанг принудува еден атомски настан да се обработува секој пат во играта (штиклирање на играта). Ова значи дека не е потребно заклучување за овој дизајн. На пример, кога корисникот зачувува, потребна е целосна слика од состојбата на играта. Оваа состојба треба да остане континуирана, најавувајќи се додека не заврши зачувувањето. За време на секој штиклирање на играта, задниот дел може да се справи само со операција за зачувување или внесување, што ја прави нишката на процесот безбедна.

  func (e *gameEmulator) gameUpdate() {
  for {
  	select {
  		case <-e.saveOperation:
  			e.saveGameState()
  		case key := <-e.input:
  			e.updateGameState(key)
  		case <-e.done:
  			e.close()
  			return
  	}
      }
  }

  Вентилатор/влез

  Овој шаблон Golang совршено одговара на мојата футрола за употреба на CrowdPlay и повеќе играчи. Следејќи ја оваа шема, сите кориснички влезови во една просторија се вградени во централниот влезен канал. Медиумите за игри потоа се распоредуваат на сите корисници во иста просторија. На овој начин, постигнуваме поделба на состојбата на играта помеѓу неколку сесии на игри на различни корисници.

  
  Синхронизација помеѓу различни сесии

  Недостатоци на Голанг

  Голанг не е совршен. Каналот е бавен. Во споредба со блокирањето, каналот Go е едноставно полесен начин за справување со истовремени и поврзани настани, но каналот не обезбедува најдобри перформанси. Има сложена блокирачка логика под каналот. Така, направив некои прилагодувања на имплементацијата, повторно применувајќи брави и атомски вредности при замена на каналите за да ги оптимизирам перформансите.

  Покрај тоа, собирачот на ѓубре во Голанг не е управуван, што понекогаш предизвикува сомнително долги паузи. Ова во голема мера се меша со апликацијата за стриминг во реално време.

  ЦГО

  Проектот ја користи постоечката библиотека со отворен код Golang VP8/H264 за компресија на медиуми и Libretro за емулатори на игри. Сите овие библиотеки се едноставно обвивки на библиотеката C во Go користејќи ЦГО. Некои од недостатоците се наведени во овој пост на Дејв Чејни. Проблеми на кои наидов:

  • неможност да се фати несреќа во CGO, дури и со Golang RecoveryCrash;
  • неуспехот да се идентификуваат тесните грла во изведбата кога не можеме да откриеме детални проблеми во CGO.

  Заклучок

  Ја постигнав мојата цел да ги разберам услугите за облак игри и да создадам платформа која ми помага да играм носталгични ретро игри со моите пријатели онлајн. Овој проект немаше да биде возможен без библиотеката Пион и поддршката од заедницата Пион. Јас сум исклучително благодарен за неговиот интензивен развој. Едноставните API обезбедени од WebRTC и Pion обезбедија беспрекорна интеграција. Мојот прв доказ за концептот беше објавен истата недела, иако немав претходно познавање на peer-to-peer (P2P) комуникација.

  И покрај леснотијата на интеграција, P2P стримингот е навистина многу сложена област во компјутерската наука. Таа мора да се справи со сложеноста на долготрајните мрежни архитектури како што се IP и NAT за да создаде peer-to-peer сесија. Додека работев на овој проект, стекнав многу вредни знаења за вмрежување и оптимизација на перформансите, затоа ги охрабрувам сите да се обидат да градат P2P производи користејќи WebRTC.

  CloudRetro одговара на сите случаи на употреба што ги очекував од моја перспектива како ретро гејмер. Сепак, мислам дека има многу области во проектот што можам да ги подобрам, како што е да ја направам мрежата посигурна и пофункционална, да обезбедувам поквалитетна графика на играта или способност за споделување игри меѓу корисниците. Напорно работам на ова. Ве молиме следете проект и поддржете го ако ви се допаѓа.

Извор: www.habr.com