Open-Source-Cloud-Gaming auf WebRTC: P2P, Multiplayer, keine Latenz

Software as a Service, Infrastructure as a Service, Platform as a Service, Kommunikationsplattform as a Service, Videokonferenzen als Service und was ist mit Cloud Gaming as a Service? Es gab bereits mehrere Versuche, Cloud-Gaming (Cloud Gaming) zu schaffen, wie beispielsweise Stadia, das kürzlich von Google gestartet wurde. Stadien Nicht neu für WebRTC, aber können andere WebRTC auf die gleiche Weise verwenden?

Thanh Nguyen beschloss, diese Möglichkeit an seinem Open-Source-Projekt CloudRetro zu testen. CloudRetro basiert auf Pion, Beliebt WebRTC-Bibliothek basierend auf Go (Danke). Shownu vom Pion-Entwicklungsteam für die Hilfe bei diesem Artikel). In diesem Artikel gibt Thanh einen Überblick über die Architektur seines Projekts und spricht auch darüber, was er Nützliches gelernt hat und auf welche Herausforderungen er bei der Arbeit gestoßen ist.

Eintrag

Als Google letztes Jahr Stadia ankündigte, war ich überwältigt. Die Idee ist so einzigartig und innovativ, dass ich mich ständig gefragt habe, wie das mit bestehenden Technologien überhaupt möglich ist. Der Wunsch, dieses Thema besser zu verstehen, veranlasste mich, meine eigene Version eines Open-Source-Cloud-Spiels zu erstellen. Das Ergebnis war einfach fantastisch. Im Folgenden möchte ich den Prozess der Arbeit an meinem Jahresbericht mit Ihnen teilen Projekt.

TLDR: kurze Folienversion mit Highlights

Warum Cloud-Gaming die Zukunft ist

Ich glaube, dass Cloud Gaming bald eine neue Generation nicht nur von Spielen, sondern auch von anderen Bereichen der Informatik sein wird. Cloud-Gaming ist der Höhepunkt des Client/Server-Modells. Dieses Modell maximiert die Backend-Verwaltung und minimiert den Frontend-Aufwand, indem es die Spiellogik auf einem Remote-Server hostet und Bilder/Audio an den Client streamt. Der Server übernimmt die schwere Verarbeitung, sodass der Client keinen Hardwareeinschränkungen mehr unterliegt.

Mit Google Stadia können Sie im Wesentlichen spielen AAA-Spiele (d. h. High-End-Blockbuster-Spiele) auf einer Oberfläche wie YouTube. Die gleiche Methodik kann auf andere anspruchsvolle Offline-Anwendungen wie Betriebssysteme oder 2D-/3D-Grafikdesign usw. angewendet werden. damit wir sie plattformübergreifend auf Geräten mit geringer Spezifikation stabil ausführen können.

Die Zukunft dieser Technologie: Stellen Sie sich vor, Microsoft Windows 10 würde im Chrome-Browser laufen?

Cloud-Gaming ist technisch schwierig

Gaming gehört zu den seltenen Bereichen, in denen eine stets schnelle Reaktion des Nutzers erforderlich ist. Wenn wir beim Klicken auf eine Seite gelegentlich eine Verzögerung von 2 Sekunden feststellen, ist dies akzeptabel. Live-Videostreams liegen in der Regel ein paar Sekunden zurück, bieten aber dennoch ein gutes Maß an Benutzerfreundlichkeit. Wenn das Spiel jedoch häufig um 500 ms verzögert ist, ist ein Spielen einfach nicht möglich. Unser Ziel ist es, eine extrem niedrige Latenz zu erreichen, damit die Lücke zwischen Eingabe und Medien so gering wie möglich ist. Daher ist der herkömmliche Ansatz zum Streamen von Videos hier nicht anwendbar.

Allgemeine Cloud-Spielvorlage

Open-Source-Projekt CloudRetro

Ich habe beschlossen, ein Testbeispiel eines Cloud-Spiels zu erstellen, um zu sehen, ob das alles bei so starken Netzwerkeinschränkungen möglich ist. Ich habe Golang für den Proof of Concept ausgewählt, weil es die Sprache ist, mit der ich am besten vertraut bin, und weil sie, wie ich später herausfand, aus vielen anderen Gründen gut für diese Implementierung geeignet ist. Go ist einfach und entwickelt sich sehr schnell; Kanäle in Go eignen sich hervorragend für die Verwaltung von Multithreading.

Projekt CloudRetro.io ist ein Open-Source-Cloud-Gaming-Dienst für Retro-Gaming. Ziel des Projekts ist es, traditionellen Retro-Spielen das komfortabelste Spielerlebnis zu verleihen und Multiplayer hinzuzufügen.
Mehr zum Projekt erfahren Sie hier: https://github.com/giongto35/cloud-game.

CloudRetro-Funktionalität

CloudRetro nutzt Retro-Spiele, um die Leistungsfähigkeit von Cloud-Gaming zu demonstrieren. Dadurch erhalten Sie viele einzigartige Spielerlebnisse.

• Spielportabilität
  • Sofortige Wiedergabe beim Öffnen einer Seite; Kein Download und keine Installation erforderlich
  • Läuft auf einem mobilen Browser, sodass zum Ausführen keine Software erforderlich ist

• Spielsitzungen können auf mehreren Geräten geteilt und für die nächste Anmeldung in der Cloud gespeichert werden
• Das Spiel kann gestreamt werden, oder Sie können es mit mehreren Benutzern gleichzeitig spielen:
  • Crowdplay wie TwitchPlayPokemon, nur plattformübergreifend und mehr in Echtzeit
  • Offline-Spiele online. Viele Benutzer können spielen, ohne ein Netzwerk einzurichten. Samurai Shodown kann jetzt von 2 Spielern über das CloudRetro-Netzwerk gespielt werden

  
  Demoversion des Online-Multiplayer-Spiels auf verschiedenen Geräten

  Infrastruktur

  Anforderungen und Technologie-Stack

  Nachfolgend finden Sie eine Liste der Anforderungen, die ich vor Beginn des Projekts festgelegt habe.

  1. Ein Spieler
  Diese Anforderung erscheint hier vielleicht nicht allzu wichtig und offensichtlich, aber sie ist eine meiner wichtigsten Erkenntnisse: Sie hält Cloud-Gaming so weit wie möglich von herkömmlichen Streaming-Diensten fern. Wenn wir uns auf das Einzelspieler-Spiel konzentrieren, können wir den zentralen Server oder das CDN loswerden, weil wir nicht an die Massen streamen müssen. Anstatt Streams auf einen Aufnahmeserver hochzuladen oder Pakete an einen zentralen WebSocket-Server weiterzuleiten, werden Service-Streams über eine WebRTC-Peer-Verbindung direkt an den Benutzer gestreamt.

  2. Medienstream mit geringer Latenz
  Wenn ich über Stadia lese, sehe ich oft, dass WebRTC in einigen Artikeln erwähnt wird. Mir wurde klar, dass WebRTC eine herausragende Technologie ist und sich perfekt für den Einsatz im Cloud-Gaming eignet. WebRTC ist ein Projekt, das Webbrowsern und mobilen Anwendungen über eine einfache API Echtzeitkommunikation ermöglicht. Es bietet Peer-to-Peer-Konnektivität, ist für Medien optimiert und verfügt über integrierte Standard-Codecs wie VP8 und H264.

  Für mich war es wichtiger, die bestmögliche Benutzererfahrung zu gewährleisten, als die Aufrechterhaltung hochwertiger Grafiken. Einige Verluste sind im Algorithmus akzeptabel. Google Stadia verfügt über einen zusätzlichen Schritt zur Reduzierung der Bildgröße auf dem Server, und Frames werden auf eine höhere Qualität hochskaliert, bevor sie an Peers übertragen werden.

  3. Verteilte Infrastruktur mit geografischem Routing
  Unabhängig davon, wie optimiert der Komprimierungsalgorithmus und der Code sind, ist das Netzwerk immer noch der entscheidende Faktor, der am meisten zur Latenz beiträgt. Die Architektur sollte über einen Mechanismus zum Koppeln des Servers verfügen, der dem Benutzer am nächsten ist, um die Round-Trip-Zeit (RTT) zu reduzieren. Die Architektur sollte einen Koordinator und mehrere auf der ganzen Welt verteilte Streaming-Server haben: USA West, USA Ost, Europa, Singapur, China. Alle Streaming-Server müssen vollständig isoliert sein. Das System kann seine Verteilung anpassen, wenn der Server dem Netzwerk beitritt oder es verlässt. Bei hohem Datenverkehr ermöglicht das Hinzufügen zusätzlicher Server daher eine horizontale Skalierung.

  4. Browserkompatibilität
  Cloud-Gaming ist dann am besten, wenn es den Benutzern am wenigsten abverlangt. Dies bedeutet, dass die Ausführung in einem Browser möglich ist. Browser tragen dazu bei, das Spielerlebnis für Benutzer so angenehm wie möglich zu gestalten und ihnen die Installation von Software und Hardware zu ersparen. Browser helfen auch dabei, plattformübergreifende Funktionen zwischen mobilen und Desktop-Versionen bereitzustellen. Glücklicherweise wird WebRTC von einer Vielzahl von Browsern gut unterstützt.

  5. Klare Trennung von Spieloberfläche und Dienst
  Ich sehe den Cloud-Gaming-Dienst als Plattform. Jeder sollte in der Lage sein, alles mit der Plattform zu verbinden. Ich habe mich jetzt integriert LibRetro mit Cloud-Spieledienst, da LibRetro eine schöne Spieleemulatorschnittstelle für Retro-Spiele wie SNES, GBA, PS bietet.

  6. Räume für Multiplayer, Crowdplay und externe Verlinkung (Deep-Link) mit dem Spiel
  CloudRetro unterstützt viele neue Gameplays wie CrowdPlay und Online MultiPlayer für Retro-Spiele. Wenn mehrere Benutzer denselben Deep-Link auf verschiedenen Computern öffnen, sehen sie dasselbe Spiel und können sogar daran teilnehmen.

  Darüber hinaus werden Spielstände im Cloud-Speicher gespeichert. Dadurch können Benutzer das Spiel jederzeit auf jedem anderen Gerät fortsetzen.

  7. Horizontale Skalierung
  Wie jedes SAAS heutzutage muss auch Cloud-Gaming horizontal skalierbar gestaltet sein. Das Koordinator-Arbeiter-Design ermöglicht es Ihnen, mehr Mitarbeiter hinzuzufügen, um mehr Verkehr zu bedienen.

  8. Nicht an eine Wolke gebunden
  Die CloudRetro-Infrastruktur wird von verschiedenen Cloud-Anbietern (Digital Ocean, Alibaba, benutzerdefinierter Anbieter) für verschiedene Regionen gehostet. Ich ermögliche die Ausführung in einem Infrastruktur-Docker-Container und konfiguriere Netzwerkeinstellungen mit einem Bash-Skript, um die Abhängigkeit von einem einzelnen Cloud-Anbieter zu vermeiden. Durch die Kombination mit NAT Traversal in WebRTC können wir CloudRetro flexibel auf jeder Cloud-Plattform und sogar auf dem Computer jedes Benutzers bereitstellen.

  Architekturdesign

  Arbeiter: (oder der oben erwähnte Streaming-Server) vervielfacht die Spiele, führt die Codierungspipeline aus und streamt die codierten Medien an Benutzer. Worker-Instanzen sind über die ganze Welt verteilt und jeder Worker kann mehrere Benutzersitzungen gleichzeitig bearbeiten.

  Koordinator: ist dafür verantwortlich, den neuen Benutzer mit dem am besten geeigneten Streaming-Worker zusammenzubringen. Der Koordinator kommuniziert mit den Arbeitern über WebSocket.

  Spielstatusspeicher: zentraler Remote-Speicher für alle Spielstände. Dieser Speicher bietet wichtige Funktionen wie Remote-Speichern/Laden.

  
  Top-Level-Architektur von CloudRetro

  Benutzerdefiniertes Skript

  Wenn ein neuer Benutzer CloudRetro in den in der Abbildung unten gezeigten Schritten 1 und 2 öffnet, wird der Koordinator zusammen mit einer Liste der verfügbaren Mitarbeiter zur ersten Seite aufgefordert. Anschließend berechnet der Client in Schritt 3 mithilfe einer HTTP-Ping-Anfrage Verzögerungen für alle Kandidaten. Diese Liste der Verzögerungen wird dann an den Koordinator zurückgesendet, damit dieser den am besten geeigneten Mitarbeiter für die Betreuung des Benutzers ermitteln kann. Schritt 4 unten erstellt das Spiel. Zwischen dem Benutzer und dem zugewiesenen Worker wird eine WebRTC-Streaming-Verbindung hergestellt.
  
  Benutzerdefiniertes Skript nach Erhalt des Zugriffs

  Was ist im Inneren des Arbeiters?

  Spiel- und Streaming-Pipelines werden isoliert im Worker gespeichert und tauschen dort über die Schnittstelle Informationen aus. Derzeit erfolgt diese Kommunikation durch die Übertragung von Daten im Speicher Golang-Kanäle im selben Prozess. Das nächste Ziel ist die Segregation, d.h. eigenständiger Start des Spiels in einem anderen Prozess.

  
  Interaktion von Worker-Komponenten

  Hauptbestandteile:

  • WebRTC: eine Client-Komponente, die Benutzereingaben akzeptiert und die codierten Medien vom Server ausgibt.
  • Spielemulator: Spielkomponente. Dank der Libretro-Bibliothek ist das System in der Lage, das Spiel im selben Prozess auszuführen und den Medien- und Eingabestream intern abzufangen.
  • Frames im Spiel werden erfasst und an den Encoder gesendet.
  • Bild-/Audio-Encoder: eine Codierungspipeline, die Medienframes empfängt, sie im Hintergrund codiert und codierte Bilder/Audio ausgibt.

  Implementierung

  CloudRetro setzt auf WebRTC als Backbone-Technologie. Bevor ich mich mit den Details der Golang-Implementierung befasse, beschloss ich, über WebRTC selbst zu sprechen. Es ist eine erstaunliche Technologie, die mir enorm dabei geholfen hat, Streaming mit einer Latenz von weniger als einer Sekunde zu erreichen.

  WebRTC

  WebRTC wurde entwickelt, um mithilfe einfacher APIs qualitativ hochwertige Peer-to-Peer-Verbindungen in nativen mobilen Apps und Browsern bereitzustellen.

  NAT-Traversal

  WebRTC ist für seine NAT-Traversal-Funktionalität bekannt. WebRTC ist für die Peer-to-Peer-Kommunikation konzipiert. Sein Zweck besteht darin, unter Vermeidung von NAT-Gateways und Firewalls den am besten geeigneten direkten Weg zum Peer-to-Peer durch einen Prozess namens zu finden EIS. Als Teil dieses Prozesses ermitteln die WebRTC-APIs mithilfe von STUN-Servern Ihre öffentliche IP-Adresse und leiten sie an einen Relay-Server weiter (WENDE), wenn keine direkte Verbindung hergestellt werden kann.

  Allerdings nutzt CloudRetro diese Funktion nicht vollständig aus. Seine Peer-to-Peer-Verbindungen bestehen nicht zwischen Benutzern, sondern zwischen Benutzern und Cloud-Servern. Auf der Serverseite des Modells gelten weniger Einschränkungen für die direkte Kommunikation als auf einem typischen Benutzergerät. Dadurch können Sie eingehende Ports vorab öffnen oder öffentliche IP-Adressen direkt verwenden, da der Server nicht hinter NAT steht.

  Zuvor wollte ich das Projekt in eine Spielevertriebsplattform für Cloud Gaming umwandeln. Die Idee bestand darin, Spieleentwicklern die Bereitstellung von Spielen und Streaming-Ressourcen zu ermöglichen. Und Benutzer würden direkt mit Anbietern interagieren. Auf diese dezentrale Weise ist CloudRetro lediglich ein Medium zum Verbinden von Streaming-Ressourcen von Drittanbietern mit Benutzern, was es skalierbarer macht, wenn das Hosting nicht mehr daran hängt. Die Rolle von WebRTC NAT Traversal ist hier sehr wichtig, um die Initialisierung einer Peer-to-Peer-Verbindung auf Streaming-Ressourcen von Drittanbietern zu erleichtern, was es dem Ersteller erleichtert, eine Verbindung zum Netzwerk herzustellen.

  Video-Kompression

  Die Videokomprimierung ist ein unverzichtbarer Bestandteil der Pipeline und trägt wesentlich zu einem reibungslosen Ablauf bei. Es ist zwar nicht notwendig, jedes Detail der VP8/H264-Videokodierung zu kennen, aber das Verständnis der Konzepte kann Ihnen helfen, die Geschwindigkeitsoptionen für Streaming-Videos zu verstehen, unerwartetes Verhalten zu beheben und die Latenz anzupassen.

  Das Komprimieren von Videos für einen Streaming-Dienst stellt eine Herausforderung dar, da der Algorithmus sicherstellen muss, dass die Gesamtkodierungszeit + Netzwerkübertragungszeit + Dekodierungszeit so gering wie möglich ist. Darüber hinaus muss der Codierungsprozess konsistent und kontinuierlich sein. Einige Kompromisse bei der Kodierung gelten nicht – wir können beispielsweise keine lange Kodierungszeit einer kleineren Dateigröße und Dekodierungszeit vorziehen oder eine inkonsistente Komprimierung verwenden.

  Die Idee hinter der Videokomprimierung besteht darin, unnötige Informationsbits zu eliminieren und gleichzeitig ein akzeptables Maß an Wiedergabetreue für Benutzer aufrechtzuerhalten. Zusätzlich zur Codierung einzelner statischer Bildrahmen leitet der Algorithmus den aktuellen Rahmen aus dem vorherigen und dem nächsten ab, sodass nur deren Differenz gesendet wird. Wie am Beispiel mit Pacman zu sehen ist, werden nur Differenzpunkte übertragen.

  
  Vergleich von Videobildern am Beispiel von Pacman

  Audiokomprimierung

  Ebenso werden beim Audiokomprimierungsalgorithmus Daten weggelassen, die für den Menschen nicht wahrnehmbar sind. Opus ist derzeit der leistungsstärkste Audio-Codec. Es wurde entwickelt, um eine Audiowelle über ein geordnetes Datagrammprotokoll wie RTP (Real Time Transport Protocol) zu übertragen. Die Latenz ist geringer als bei MP3 und AAC und die Qualität ist höher. Die Latenz beträgt normalerweise etwa 5 bis 66,5 ms.

  Pion, WebRTC in Golang

  Bauer ist ein Open-Source-Projekt, das WebRTC nach Golang bringt. Anstelle der üblichen Verpackung nativer C++-WebRTC-Bibliotheken ist Pion eine native Golang-Implementierung von WebRTC mit besserer Leistung, Go-Integration und Versionskontrolle für WebRTC-Protokolle.

  Die Bibliothek bietet außerdem Streaming-Daten mit vielen tollen integrierten Modulen mit einer Verzögerung von weniger als einer Sekunde. Es verfügt über eine eigene Implementierung von STUN, DTLS, SCTP usw. und einige Experimente mit QUIC und WebAssembly. An sich ist diese Open-Source-Bibliothek eine wirklich gute Lernquelle mit großartiger Dokumentation, Netzwerkprotokollimplementierungen und coolen Beispielen.

  Die Pion-Community, angeführt von einem sehr leidenschaftlichen Entwickler, ist recht lebhaft und führt viele hochwertige Diskussionen über WebRTC. Wenn Sie an dieser Technologie interessiert sind, melden Sie sich an http://pion.ly/slack - Sie werden viel Neues lernen.

  CloudRetro in Golang schreiben

  
  Worker-Implementierung in Go

  Go-Kanäle in Aktion

  Durch das schöne Design der Go-Kanäle werden die Probleme des Event-Streamings und der Parallelität erheblich vereinfacht. Wie im Diagramm laufen mehrere Komponenten parallel in verschiedenen GoRoutines. Jede Komponente verwaltet ihren eigenen Status und kommuniziert über Kanäle. Golangs selektive Behauptung führt dazu, dass jedes Mal im Spiel (Spieltick) ein atomares Ereignis verarbeitet wird. Dies bedeutet, dass für dieses Design keine Blockierung erforderlich ist. Wenn beispielsweise ein Benutzer gespeichert wird, ist ein vollständiger Spielstatus-Snapshot erforderlich. Dieser Zustand muss bei der Anmeldung kontinuierlich bleiben, bis der Speichervorgang abgeschlossen ist. Während jedes Spielticks kann das Backend nur einen Speicher- oder Eingabevorgang verarbeiten, was den Prozess threadsicher macht.

  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

  Diese Golang-Vorlage eignet sich hervorragend für meinen CrowdPlay- und Multiple-Player-Anwendungsfall. Nach diesem Muster werden alle Benutzereingaben im selben Raum in den mittleren Eingangskanal integriert. Die Spielmedien werden dann allen Benutzern im selben Raum bereitgestellt. Auf diese Weise erreichen wir die Aufteilung des Spielstatus auf mehrere Spielsitzungen verschiedener Benutzer.

  
  Synchronisierung zwischen verschiedenen Sitzungen

  Nachteile von Golang

  Golang ist nicht perfekt. Der Kanal ist langsam. Im Vergleich zum Blockieren ist ein Go-Kanal einfach eine einfachere Möglichkeit, gleichzeitige und Streaming-Ereignisse zu verarbeiten, aber ein Kanal bietet nicht die beste Leistung. Unter dem Kanal befindet sich eine komplexe Sperrlogik. Daher habe ich einige Anpassungen an der Implementierung vorgenommen, indem ich beim Ersetzen von Kanälen erneut Sperren und atomare Werte angewendet habe, um die Leistung zu optimieren.

  Darüber hinaus ist der Garbage Collector von Golang unüberschaubar, was manchmal zu verdächtig langen Pausen führt. Dies beeinträchtigt die Echtzeit-Streaming-Anwendung erheblich.

  CGO

  Das Projekt nutzt die bestehende Open-Source-Golang-Bibliothek VP8/H264 für die Medienkomprimierung und Libretro für Spieleemulatoren. Alle diese Bibliotheken sind lediglich Wrapper für die C-Bibliothek in Go CGO. Einige der Nachteile sind in aufgeführt dieser Beitrag Dave Cheney. Probleme, auf die ich gestoßen bin:

  • Unfähigkeit, einen Absturz in CGO abzufangen, selbst mit Golang RecoveryCrash;
  • die Unfähigkeit, einen Leistungsengpass zu erkennen, wenn wir keine granularen Probleme in CGO erkennen können.

  Abschluss

  Ich habe mein Ziel erreicht, Cloud-Gaming-Dienste zu entdecken und eine Plattform zu schaffen, die mir hilft, nostalgische Retro-Spiele online mit meinen Freunden zu spielen. Ohne die Pion-Bibliothek und die Unterstützung der Pion-Community wäre dieses Projekt nicht möglich gewesen. Für die intensive Entwicklung bin ich außerordentlich dankbar. Die einfachen APIs von WebRTC und Pion sorgten für eine nahtlose Integration. Mein erster Proof of Concept wurde noch in derselben Woche veröffentlicht, obwohl ich vorher nichts von der Peer-to-Peer-Kommunikation (P2P) wusste.

  Trotz der einfachen Integration ist P2P-Streaming tatsächlich ein sehr komplexes Gebiet in der Informatik. Es muss die Komplexität mehrjähriger Netzwerkarchitekturen wie IP und NAT bewältigen, um eine Peer-to-Peer-Sitzung zu erstellen. Während der Arbeit an diesem Projekt habe ich viele wertvolle Kenntnisse über Netzwerke und Leistungsoptimierung gesammelt. Daher empfehle ich jedem, die Entwicklung von P2P-Produkten mit WebRTC auszuprobieren.

  CloudRetro deckt alle Anwendungsfälle ab, die ich aus meiner Sicht als Retro-Gamer erwartet habe. Ich denke jedoch, dass es in dem Projekt viele Bereiche gibt, die ich verbessern kann, wie z. B. die Zuverlässigkeit und Leistung des Netzwerks, die Bereitstellung qualitativ hochwertigerer Spielgrafiken oder die Möglichkeit, Spiele zwischen Benutzern zu teilen. Ich arbeite hart daran. Bitte Folge Projekt und unterstütze es, wenn es Dir gefällt.

Source: habr.com