DE112021003383T5 - Inhaltsadaptives routing und weiterleiten an datenzentren in cloud-computing-umgebungen - Google Patents

Inhaltsadaptives routing und weiterleiten an datenzentren in cloud-computing-umgebungen Download PDF

Info

Publication number
DE112021003383T5
DE112021003383T5 DE112021003383.2T DE112021003383T DE112021003383T5 DE 112021003383 T5 DE112021003383 T5 DE 112021003383T5 DE 112021003383 T DE112021003383 T DE 112021003383T DE 112021003383 T5 DE112021003383 T5 DE 112021003383T5
Authority
DE
Germany
Prior art keywords
application
data center
data
request
network
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE112021003383.2T
Other languages
English (en)
Inventor
Bojan Vukojevic
Jason Baurick
Khurrum Islam
Yury Taradzei
Siddeheshwar Mahesh
Rachid Ennaji
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nvidia Corp
Original Assignee
Nvidia Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nvidia Corp filed Critical Nvidia Corp
Publication of DE112021003383T5 publication Critical patent/DE112021003383T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A63F13/35—Details of game servers
    • A63F13/358—Adapting the game course according to the network or server load, e.g. for reducing latency due to different connection speeds between clients
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A63F13/35—Details of game servers
    • A63F13/352—Details of game servers involving special game server arrangements, e.g. regional servers connected to a national server or a plurality of servers managing partitions of the game world
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/50—Testing arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/18—End to end
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2425—Traffic characterised by specific attributes, e.g. priority or QoS for supporting services specification, e.g. SLA
    • H04L47/2433—Allocation of priorities to traffic types
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/101—Server selection for load balancing based on network conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63—Routing a service request depending on the request content or context
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0823—Errors, e.g. transmission errors
    • H04L43/0829—Packet loss
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852—Delays
    • H04L43/0864—Round trip delays
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852—Delays
    • H04L43/087—Jitter
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H04L43/0894—Packet rate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/562—Brokering proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/62—Establishing a time schedule for servicing the requests

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Hochleistungsapplikationen wie Cloud-Spiele-Streaming, Cloud-Virtual-Reality (VR), Remote-Desktop und andere reagieren sensibel auf verschiedene Netzwerkbedingungen wie Latenz, Jitter und Paketverlust. Systeme der vorliegenden Offenbarung können Netzwerkcharakteristiken für ein Benutzergerät mit Latenzanforderungen für einen bestimmten Applikationstyp abgleichen, und Applikationssitzungen können an ein geeignetes Datenzentrum weitergeleitet oder verteilt werden. Um dies zu erreichen, können applikationsspezifische Netzwerktests durchgeführt werden, um die Anforderungen für die Ausführung einer hochleistungsfähigen Applikationssitzung für einen Benutzer zu bestimmen. Das Ergebnis dieser Tests kann zusätzlich zu den applikationsspezifischen Leistungsanforderungen verwendet werden, um aus einer Reihe verfügbarer Datenzentren ein geeignetes Datenzentrum zu finden, das in der Lage ist, die Applikationssitzung ohne Degradation zu hosten. Auf diese Weise kann eine effiziente Verwendung verteilter Infrastrukturen erreicht werden, während gleichzeitig Überlastungen und Hotspots vermieden werden und eine optimierte Applikationserfahrung für die Endnutzer bereitgestellt wird.

Description

  • HINTERGRUND DER ERFINDUNG
  • Leistungsstarke Netzwerk-Streaming-Applikationen - wie Cloud-Gaming, Cloud-Virtual-Reality (VR), Remote Workstation und/oder andere Typen von Applikationen - reagieren in der Regel sensibel auf Netzwerkleistungsparameter wie Latenz, Jitter, Bandbreite und Paketverluste. Auswirkungen auf die Leistung können durch eine Kombination von Netzwerkleistungsparametern eines lokalen Netzwerks, das von einem Gerät des Benutzers genutzt wird, von Internetverbindungen zwischen einem Gerät des Benutzers und einem Datenzentrum (z.B. verursacht durch die Entfernung zwischen dem Gerät des Benutzers und dem Datenzentrum, durch die vom Datenzentrum verwendete Netzwerkinfrastruktur des Internet Service Providers (ISP) usw.) und/oder durch Hardware- oder andere Ressourcen- und Leistungsanforderungen einer bestimmten Applikation entstehen. Bei Datenzentren, die sich weiter vom Gerät des Benutzers entfernt befinden (z.B. 500 oder mehr Meilen), kann die Latenzzeit, die die Applikation bei der Datenübertragung über solch weite Entfernungen erfährt, auf ein Niveau ansteigen, das für die korrekte oder akzeptable Ausführung der Applikation ungeeignet ist. Infolgedessen kann die Latenz (und/oder Jitter, Paketverluste, Bandbreite usw.), z. B. bei einer auf Cloudbasierten Spielapplikation, dazu führen, dass das Spiel nicht mehr spielbar ist, da die von den Eingaben in das Spiel erzeugten Effekte zu lange nach dem Empfangen der Eingaben auf der Anzeige erscheinen.
  • Herkömmliche Infrastrukturen - z.B. Datenzentren (dt. auch Rechenzentren) - zur Unterstützung von Hochleistungsapplikationen sind nicht ausreichend, um ein optimales Nutzererlebnis zu gewährleisten. Das Internetprotokoll (IP) Geolocation (GeoIP) kann verwendet werden, um ein Gerät eines Benutzers zu einem zugewiesenen Datenzentrum zu leiten - wobei die Zuweisung unabhängig von den Hardware-, Netzwerk- und Ressourcenanforderungen für die jeweilige Applikation erfolgt. Beispielsweise kann ein Anbieter von Applikationen in den USA nur ein Datenzentrum an der Ostküste und eines an der Westküste bereitstellen. Dies kann dazu führen, dass Benutzer in der Mitte der USA zu einem dieser Datenzentren geroutet (dt. auch geleitet) werden, das mehr als 1500 Meilen vom heimischen Netzwerk des Benutzers entfernt ist, was eine Degradation der Leistung der Applikation verursacht. Selbst wenn ein Benutzer an der Westküste an das Datenzentrum an der Westküste weitergeleitet wird, kann es sein, dass die Hardwareressourcen, die Kapazität und/oder die Leistung des Netzwerks nicht für die jeweilige Applikation geeignet sind. Weiter kann es sein, dass bei der Neuzuweisung von IP-Adressen unter Verwendung von GeoIP diese Informationen nicht an das Gerät des Benutzers zurückgeleitet werden. Wird eine IP-Adresse beispielsweise von der Westküste an das Datenzentrum an der Ostküste neu zugewiesen, müssen Benutzergeräte, die sich an der Westküste befinden und der IP-Adresse zugewiesen sind, bei der Ausführung der entsprechenden Applikation nun möglicherweise mit einem Datenzentrum am anderen Ende des Landes kommunizieren. Dies kann Leistungsprobleme verursachen, die die Applikation unbrauchbar machen.
  • Einige herkömmliche Systeme setzen zur Unterstützung von Applikationen auf Content Delivery Networks (CDNs) - z.B. weit verteilte Edge-Server. Den derzeitigen CDNs fehlen jedoch die Rechenressourcen für bedarfsgesteuerte Hochleistungsapplikationen - wie Cloud-Gaming, Remote Desktop, Cloud-VR usw. - verursacht durch ihre Implementierung für weniger anspruchsvolle Applikationen (z.B. Web-Inhalte, Video-Streaming, etc.). Darüber hinaus werden bei der Zuweisung einer Applikation zu einem bestimmten Edge-Server eines CDN die Hardware- oder Netzwerk-Leistungsanforderungen der Applikation nicht berücksichtigt. Wird ein CDN für eine On-Demand-Applikation verwendet, kann es daher aufgrund von Latenzzeiten zu häufigen Pufferungen kommen, und die Qualität der Applikation kann beeinträchtigt werden, da die Server des CDN möglicherweise nicht genügend Hardware, Netzwerkleistung oder andere Ressourcen umfassen, um die On-Demand-Applikation effektiv zu hosten.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Ausführungsbeispiele der vorliegenden Offenbarung beziehen sich auf die Distribution und Weiterleitung an Datenzentren für Cloud-Computing-Applikationen. Es werden Systeme und Verfahren offenbart, die applikationsspezifische Netzwerktests durchführen - für das Netzwerk des Benutzers und/oder das/die Netzwerk(e), das/die ein Gerät des Benutzers mit einem Datenzentrum oder einer Region von Datenzentren verbindet/verbinden -, um ein Applikationsprofil für den Benutzer und ein geeignetes Datenzentrum/geeignete Datenzentren zu bestimmen, um eine Applikationssitzung gemäß dem Applikationsprofil zu hosten. Wenn beispielsweise die Datenzentren weiter verteilt sind (z.B. ein oder mehrere pro Metropolregion), kann eine Messung von Netzwerkcharakteristiken aus der Perspektive des Benutzers in Richtung der verschiedenen Datenzentren - oder Datenzentrumsregionen - durchgeführt werden. Die Netzwerktests können auf einen bestimmten Applikationstyp zugeschnitten werden, so dass die Testergebnisse Aufschluss über die Leistung der jeweiligen Applikation für den individuellen Nutzer geben. Bei einer stark verteilten Infrastruktur ist es daher möglich, dass eine Vielzahl von Datenzentren eine akzeptable Netzwerk- und/oder Hardwareleistung für das Hosting der Applikation aufweisen. Ein Gerät des Nutzers kann ein bestimmtes Applikationsprofil an ein Datenzentrum übermitteln, das auch Informationen über andere geeignete Datenzentren umfassen kann, und ein Planer, der im Datenzentrum ausgeführt wird, kann einen geeigneten Host für die Applikationssitzung bestimmen. Beispielsweise kann der Planer Hardware- und/oder Netzwerk-Leistungsanforderungen für die bestimmte Applikation - z.B. ein bestimmtes Spiel in einer Cloud-Gaming-Umgebung - bestimmen und entweder bestimmen, dass die Applikation gehostet wird, oder die Hosting-Anforderungen an die anderen geeigneten Datenzentren weiterleiten. Schließlich können ein Applikationsprofil des Geräts und des Netzwerks des Benutzers, die spezifischen Applikationsanforderungen, die Anforderungen an die Host-Hardwarekonfiguration und/oder andere Kriterien bei der Bestimmung eines geeigneten Host-Datenzentrums - oder eines Servers davon - für die Ausführung einer Applikationssitzung berücksichtigt werden.
  • Darüber hinaus kann eine Netzwerküberlastung und eine Ressourcennutzung von einem ausgewählten Datenzentrum berücksichtigt werden, wenn es die Distribution oder Weiterleitung von Applikationssitzungen bestimmt. So können beispielsweise historische Daten verwendet werden, um vorherzusagen, wann bestimmte Datenzentren überlastet oder ausgelastet sein werden, und Host-Anfragen können an weniger überlastete Datenzentren weitergeleitet werden. Ein weiteres Beispiel: Wenn eine erste Applikation (z.B. ein Spiel, das nicht so stark von höheren Latenzzeiten betroffen ist) die Rechenressourcen eines bestimmten Datenzentrums nicht benötigt, eine zweite Applikation (z.B. eine latenzempfindliche Applikation) jedoch häufig, kann die Host-Anfrage an ein anderes Datenzentrum mit weniger Rechenressourcen (z.B. mit Hardware älterer Modelle) weitergeleitet werden, um die Überlastung zu verringern und die Ressourcennutzung zu maximieren, ohne die Leistung der ersten und zweiten Applikation zu beeinträchtigen. In einigen Ausführungsbeispielen, bei denen ein Datenzentrum mit mehreren Anbietern ausgewählt wird, können Metriken zur Dienstgüte (Quality of Service, QoS) von Applikationen für verschiedene ISPs des Datenzentrums analysiert werden, um den am besten geeigneten ISP für das jeweilige Endbenutzergerät - und/oder die jeweilige von ihm ausgeführte Applikation - zu bestimmen.
  • Figurenliste
  • Die vorliegenden Systeme und Verfahren zur Distribution und Weiterleitung an Datenzentren für Cloud-Rechenapplikationen werden im Folgenden unter Bezugnahme auf die beigefügten Figuren detailliert beschrieben, wobei:
    • 1 ist ein Blockdiagramm, das ein System zur Distribution und Weiterleitung von Applikationssitzungen zeigt, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
    • 2A zeigt eine beispielhafte Darstellung einer Netzwerk-Testumgebung für Applikationssitzungs-Host-Anforderungen, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
    • 2B-2C zeigen Ausführungsbeispiele für die Distribution und Weiterleitung von Applikationssitzungen, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
    • 2D zeigt eine beispielhafte Darstellung von Internet Service Provider (ISP) Switching basierend auf In-Stream Quality of Service (QoS) Feedback, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
    • 3 ist ein Flussdiagramm, das ein Verfahren zur Applikationssitzungsdistribution und -weiterleitung zeigt, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
    • 4 ist ein Flussdiagramm, das ein Verfahren zur Generierung von Applikationsprofilen zeigt, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
    • 5 ist ein Blockdiagramm eines Beispiels für ein Spiele-Streaming-System, das zur Verwendung bei der Implementierung einiger Ausführungsbeispiele der vorliegenden Offenbarung geeignet ist; und
    • 6 ist ein Blockdiagramm eines beispielhaften Rechengerätes, das zur Verwendung bei der Implementierung einiger Ausführungsbeispiele der vorliegenden Offenbarung geeignet ist.
  • DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
  • Es werden Systeme und Verfahren offenbart, die sich auf die Distribution und Weiterleitung an Datenzentren für Cloud-Computing-Applikationen beziehen. Die hier beschriebenen Systeme und Verfahren können implementiert werden, um die Applikationsleistung für beliebige Applikationstypen zu erhöhen, wie z. B. Streaming, Cloud-Gaming, Cloud-Virtual-Reality (VR), Remote-Workstation-Applikationen und/oder andere Applikationstypen. Beispielsweise können Applikationen empfindlich auf verschiedene Netzwerk-Leistungsparameter wie Latenz, Paketverlust, Bandbreite und/oder Jitter und/oder Applikationsleistungsparameter wie Sitzungsausbeute und/oder Applikations-QoS-Metriken (Quality of Service) reagieren. Daher können das hier beschriebene System und die Verfahren in einem beliebigen System implementiert werden, um die Netzwerk- und Applikationsleistung für jeden Typ von Applikation zu erhöhen, der über ein oder mehrere Netzwerke - wie z. B. das Internet - ausgeführt wird. Obwohl das Border-Gateway-Protokoll (BGP) hier in erster Linie als das Protokoll beschrieben wird, an das Routing-Aktualisierungen oder Richtlinien zu leiten sind, ist dies nicht als Einschränkung zu verstehen, und jedes geeignete Protokoll kann verwendet werden - z.B. das Routing-Informationsprotokoll (RIP), Secure BGP (sBGP), Secure Origin BGP (soBGP), usw.
  • Die Infrastruktur für hochleistungsfähige Applikationen - wie z. B. Spiele-Streaming, Cloud-basierte VR, etc. - wird häufig auf eine größere Anzahl von Datenzentren verteilt, so dass zumindest ein Datenzentrum näher an der Nutzerpopulation liegt. Durch eine solche Verteilung der Datenzentren kann die Ressourcenmenge in einem einzelnen Datenzentrum begrenzt werden, und um alle Nutzer effektiv zu versorgen, optimiert das System der vorliegenden Offenbarung die Distribution und Allokation dieser Ressourcen. Beispielsweise können Netzwerkcharakteristiken aus der Perspektive eines Benutzergeräts gegenüber Datenzentren für die jeweilige Applikation gemessen werden. Diese Messung kann Latenz, Jitter, Paketverlust, Bandbreite und/oder andere Messungen des Netzwerks umfassen. Die Messung kann als applikationsspezifischer oder benutzerdefinierter Netzwerktest durchgeführt werden, der den Netzwerkverkehr für die jeweilige Applikation zwischen einem oder mehreren Datenzentren und dem Benutzergerät simuliert. In einer Cloud-Umgebung für Spielapplikationen kann der simulierte Datenverkehr zum Beispiel „burst-artig“ sein (gekennzeichnet durch kurze Perioden mit intermittierender Datenübertragung mit hohem Volumen, die von Perioden mit wenig oder gar keinem Datenaustausch unterbrochen werden), und ein herkömmlicher Bandbreitentest kann ungenaue Ergebnisse hinsichtlich der Fähigkeit des Netzwerks des Benutzers liefern, die Bandbreitenanforderungen einer Spielapplikation zu erfüllen. Daher kann ein kundenspezifischer Netzwerktest durchgeführt werden, um die Fähigkeit des Netzwerks und/oder Geräts des Benutzers zu bestimmen, den Netzwerkverkehr eines Spiele-Streams für ein bestimmtes Spiel zu bewältigen.
  • Darüber hinaus ist es bei einer stark verteilten Infrastruktur wahrscheinlich, dass mehr als ein Datenzentrum akzeptable Netzwerkcharakteristiken - z.B. Latenzzeiten - aufweist, so dass das Benutzergerät Informationen (z.B. über eine Programmierschnittstelle (API)) über jedes der verfügbaren Datenzentren erhalten kann. Sobald die verfügbaren Datenzentren bestimmt sind, kann ein vorläufiger Netzwerktest durchgeführt werden, um eine Teilmenge der Datenzentren - oder Regionen von Datenzentren - zu bestimmen, die akzeptable vorläufige Netzwerkcharakteristiken (z.B. Latenzcharakteristiken) aufweisen. Anschließend kann eine einzelne Region oder ein Datenzentrum ausgewählt und der hier beschriebene detailliertere und angepasste Netzwerktest unter Verwendung des ausgewählten Datenzentrums durchgeführt werden. Dieser Test kann verwendet werden, um ein Streaming-Profil für das Benutzergerät und das Netzwerk des Benutzers (z.B. ein lokales Netzwerk) zu generieren - z.B. einschließlich Bandbreitenfähigkeiten, Bildqualität oder Auflösungsinformationen, Bitrateninformationen, Audioqualität oder Auflösungsinformationen, Gerätetyp (z.B. Smartphone, Tablet, Hochleistungsrechner usw.). Das Streaming-Profil kann generiert und/oder aktualisiert werden, wenn eine Applikation zum ersten Mal auf dem Benutzergerät ausgeführt wird, wenn Änderungen der Netzwerkcharakteristiken festgestellt werden (z.B. wenn neue Datenzentren in Betrieb genommen werden, wenn sich ein Gerätetyp ändert, wenn ein neues Benutzernetzwerk erkannt wird usw.), in regelmäßigen Abständen, in einem Intervall, usw.
  • Sobald ein Streaming-Profil für ein Benutzergerät generiert wurde, kann beim Starten einer Applikationssitzung auf dem Benutzergerät ein vorläufiger Netzwerktest (z.B. ein Latenztest) durchgeführt werden. Als Ergebnis können ein oder mehrere Datenzentren zurückgegeben werden, die eine geeignete Latenz aufweisen, und eine Anfrage für das Hosting der Applikationssitzung kann an ein geeignetes Datenzentrum (z.B. das Datenzentrum mit der niedrigsten Latenz) gesendet werden. Ein Planer des Datenzentrums kann diese Anfrage empfangen - sie umfasst Daten, die das Streaming-Profil repräsentieren, Daten, die andere geeignete Datenzentren repräsentieren, die im Rahmen des vorläufigen Netzwerktests ermittelt wurden, usw. - und kann bestimmen, ob das Datenzentrum in der Lage ist, die Applikationssitzung (z.B. eine Spielapplikation einer Cloud-Gaming-Applikation) zu hosten. Beispielsweise kann das Streaming-Profil die Qualität des/der vom Benutzergerät unterstützten und angeforderten Streams (z.B. 4K, 8K usw.) und die Netzwerkcharakteristiken (z.B. Latenz, Jitter, Paketverlust, Bandbreite oder andere Charakteristiken) angeben. Darüber hinaus können die Anforderungen an die jeweilige Applikation (z.B. ein bestimmter Typ von Spiel) analysiert werden, um zu bestimmen, ob das Datenzentrum das Spiel mit der gewünschten Dienstgüte (QoS) hosten kann. Unter Berücksichtigung dieser Kriterien kann der Planer bestimmen, ob das Datenzentrum das Spiel hosten kann oder nicht.
  • Wenn das Datenzentrum das Spiel nicht hosten kann - z.B. aufgrund einer falschen Hardwarekonfiguration, aufgrund von Netzwerkproblemen, aufgrund von Überlastung, aufgrund einer erwarteten Überlastung, um die Ressourcen zu maximieren, usw. - kann der Planer die Anfrage an ein oder mehrere andere geeignete Datenzentren weiterleiten (z.B. alle gleichzeitig, eines nach dem anderen, usw.). Die weitergeleitete Anfrage kann Informationen aus der ursprünglichen Anfrage des Benutzergeräts umfassen, zusätzlich zu ergänzenden Informationen wie den Hardware-Anforderungen, den Leistungsanforderungen der jeweiligen Applikation (z.B. des jeweiligen Spiels), usw. Die Anfragen können weitergeleitet werden, bis ein anderes Datenzentrum die Annahme der Anfrage indiziert. Nach der Annahme kann der Planer des ursprünglichen Datenzentrums eine Antwort an das Benutzergerät senden, in der er (z.B. über eine IP-Adresse) das Datenzentrum angibt, in dem die Applikationssitzung stattfinden wird. Die Applikationssitzung kann dann mit dem zugewiesenen Datenzentrum beginnen, das die Applikationssitzung für das Benutzergerät hostet.
  • Für das ausgewählte Datenzentrum können in Ausführungsbeispielen zusätzliche Kriterien berücksichtigt werden. Beispielsweise kann es sich bei dem Datenzentrum um ein Multihomed-Datenzentrum handeln, in dem zwei oder mehr ISPs den Internetzugang bereitstellen. Das Datenzentrum kann dann applikationsspezifische (und/oder instanzspezifische) QoS-Metriken der Applikationssitzung über zwei oder mehr der ISPs hinweg analysieren und den ISP bestimmen, der die beste QoS bereitstellt. Wenn sich der ISP mit der besten Leistung vom aktuellen ISP unterscheidet (oder ein anderer ISP eine höhere QoS oberhalb eines Schwellenwerts aufweist), kann das Datenzentrum Import-Routing-Maps und/oder Export-Routing-Maps für ein oder mehrere Netzwerkgeräte (z.B. einen Core Switch) des Datenzentrums aktualisieren, um das Routing des Netzwerkverkehrs über den gewünschten ISP zu steuern. Beispielsweise können einige Benutzer-ISPs nicht optimal mit den ISPs des Datenzentrums zusammenarbeiten, und die hier beschriebenen ISP-Switching-Verfahren können diesen Problemen Rechnung tragen, um die Ende-zu-Ende-Leistung des Netzwerks zu erhöhen.
  • Durch die Abstimmung der Netzwerkcharakteristiken für ein Benutzergerät mit den Latenzanforderungen für einen bestimmten Applikationstyp (z.B. ein bestimmtes Spiel) können Applikationssitzungen ohne Degradation der Leistung an verschiedene Datenzentren weitergeleitet oder verteilt werden. Darüber hinaus kann aufgrund der Weiterleitung ohne Degradation eine Überlastungssteuerung implementiert werden, um von Datenzentren, für die eine höhere Auslastung prognostiziert wird (z.B. basierend auf historischen Daten), wegzuwechseln, oder um zu Datenzentren zu wechseln, die weiter entfernt sind - und eine höhere Latenz aufweisen -, die aber dennoch den Latenzanforderungen für eine bestimmte Applikation entsprechen. Infolgedessen können Datenzentren für Benutzer reserviert werden, die einen näheren Ort haben und/oder latenzsensitivere Applikationen ausführen. Die hier beschriebenen Systeme und Verfahren können eine effektive und effiziente Verwendung verteilter Infrastrukturen bereitstellen, Überlastungen und Hotspots vermeiden und gleichzeitig ein optimiertes Applikationserlebnis für Endnutzer bieten.
  • 1 zeigt ein Beispiel für ein System 100 zur Distribution und Weiterleitung von Applikationssitzungen (im Folgenden auch als „System 100“ bezeichnet), gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung. Es ist zu verstehen, dass diese und andere hier beschriebene Anordnungen nur als Beispiele dargestellt werden. Andere Anordnungen und Elemente (z.B. Maschinen, Schnittstellen, Funktionen, Anordnungen, Gruppierungen von Funktionen usw.) können zusätzlich zu den gezeigten oder anstelle von diesen verwendet werden, und einige Elemente können ganz weggelassen werden. Weiter handelt es sich bei vielen der hier beschriebenen Elemente um funktionale Entitäten, die als diskrete oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und an jedem geeigneten Ort implementiert werden können. Verschiedene hier beschriebene Funktionen, die von Entitäten durchgeführt werden, können von Hardware, Firmware und/oder Software ausgeführt werden. Zum Beispiel können verschiedene Funktionen von einem Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt. In einigen Ausführungsbeispielen können die Komponenten, Merkmale und/oder die Funktionalität des Systems 100 denen des beispielhaften Spiele-Streaming-Systems 500 und/oder des beispielhaften Rechengeräts 600 ähnlich sein.
  • Das System 100 kann ein oder mehrere Datenzentren 102 (z.B. Datenzentren 102A, 102B und 102C) und/oder ein oder mehrere Client-Geräte 104 umfassen, die über das Internet 106 über einen oder mehrere Internet-Service-Provider (ISP), wie z.B. Datenzentrum (DC) ISP 110A und 110B, und/oder Client-ISP(s) 108 kommunizieren. In einigen Ausführungsbeispielen kann das System 100 einer Cloud-Computing- und/oder einer verteilten Rechenumgebung entsprechen. Wenn die Host-Applikation 112 beispielsweise einer Cloud-Gaming-Applikation entspricht, kann das beispielhafte Spiele-Streaming-System 500 von 5 eine geeignete Architektur oder Plattform zur Unterstützung der Cloud-Spieleapplikation umfassen.
  • Die DC-ISPs 110 können den Datenzentren 102 Zugang zum Internet 106 (und/oder einem anderen WAN) bereitstellen, und der/die Client-ISP(s) 108 kann/können dem/den Client-Gerät(en) 104 Zugang zum Internet bereitstellen. In einigen Ausführungsbeispielen kann einer oder mehrere der DC-ISP 110 und/oder der Client-ISP 108 ein und derselbe ISP sein, während in anderen Ausführungsbeispielen einer oder mehrere der DC-ISP 110 und 108 unterschiedlich sein können. Wenn mehr als ein Datenzentrum 102 implementiert ist, können verschiedene Datenzentren 102 verschiedene DC-ISPs 110 verwenden und/oder wenn mehr als ein Client-Gerät 104 implementiert ist, können verschiedene Client-Geräte 104 verschiedene Client-ISPs 108 verwenden.
  • Das System 100 kann für beliebige Typen von Netzwerken implementiert werden, z. B. für WANs (Wide Area Networks), LANs (Local Area Networks), zellulare Netzwerke, andere Typen von Netzwerken oder eine Kombination davon. Obwohl die Datenzentren 102 als multihomed gezeigt werden - z.B. mit zwei DC ISPs 110A und 110B - ist dies nicht als Einschränkung gedacht und in einigen Ausführungsbeispielen können eines oder mehrere der Datenzentren 102 nicht multihomed sein. Obwohl gezeigt wird, dass nur ein Client-ISP 108 vorhanden ist, ist dies nicht als Einschränkung zu verstehen, und das/die Client-Gerät(e) 104 können mehr als einen Client-ISP 108 umfassen. Auch wenn nur eine einzige Verbindung durch jeden ISP gezeigt wird, soll dies nicht einschränkend sein, und in einigen Ausführungsbeispielen kann ein individueller ISP - wie der DC ISP 110A - eine Vielzahl von separaten Routings oder Edge-Router-Zugangspunkten oder Knoten für die Datenzentren 102 umfassen. In einigen Ausführungsbeispielen kann dies beispielsweise beim Wechsel von einem ISP zu einem anderen einem Wechsel von einer ersten Route (z.B. über einen ersten Edge-Router des ISP) durch einen ISP zu einer zweiten Route (z.B. über einen zweiten Edge-Router des ISP) durch denselben ISP entsprechen.
  • Die Datenzentren 102 können eine Host-Applikation 112 hosten - z.B. eine HochleistungsApplikation, eine Cloud-Spielestreaming-Applikation, eine Virtual-Reality (VR)-Inhaltsstreaming-Applikation, eine Inhaltsstreaming-Applikation, eine Remote-Desktop-Applikation, usw. - die beispielsweise eine oder mehrere Applikationsprogrammierschnittstellen (APIs) verwenden. Die Datenzentren 102 können eine beliebige Anzahl von Untergeräten umfassen, z. B. Server, Netzwerkspeicher (NAS), APIs, andere Backend-Geräte und/oder einen anderen Typ von Untergerät. Beispielsweise können die Datenzentren 102 eine Vielzahl von Rechengeräten (z.B. Server, Speichergeräte usw.) umfassen, die einige oder alle der hierin beschriebenen Komponenten des Beispiel-Rechengeräts 600 von 6 umfassen oder ihnen entsprechen. In einigen Ausführungsbeispielen kann die Host-Applikation 112 eine oder mehrere Grafikverarbeitungseinheiten (GPUs) und/oder virtuelle GPUs verwenden, um eine Client-Applikation 122 zu unterstützen, die auf dem oder den Client-Geräten 104 ausgeführt wird. In einigen Ausführungsbeispielen kann zumindest ein Teil der Verarbeitungen der Datenzentren 102 parallel ausgeführt werden, indem eine oder mehrere parallele Verarbeitungseinheiten verwendet werden, wie z.B. GPUs, Kerne davon (z.B. CUDA-Kerne), applikationsspezifische integrierte Schaltungen (ASICs), Vektorprozessoren, massiv parallele Prozessoren, symmetrische Multiprozessoren usw. In Ausführungsbeispielen, in denen das Rendern unter Verwendung der Datenzentren 102 ausgeführt wird, können die Datenzentren 102 eine oder mehrere Ray-Tracing- und/oder Path-Tracing-Techniken implementieren, um die Qualität von Bildern und/oder Videos in einem Stream zu verbessern (z.B. wenn das Client-Gerät 104 in der Lage ist, hochauflösende - z.B. 4K, 8K, etc. - Grafiken anzeigen kann und/oder die Netzwerkcharakteristiken derzeit das Streaming derselben unterstützen).
  • Die Datenzentren 102 können ein oder mehrere Netzwerkgeräte 120 umfassen - z.B. Switches, Router, Gateways, Hubs, Bridges, Access Points, etc. - die so konfiguriert sein können, dass sie den Verkehr innerhalb eines Netzwerks der Datenzentren 102 zu leiten, eingehenden oder eintretenden Verkehr aus dem Internet zu leiten, ausgehenden oder austretenden Verkehr in das Internet zu leiten und/oder zumindest teilweise das Routing des Netzwerkverkehrs durch verschiedene autonome Systeme des Internets zu steuern (z.B. über Edge-Router der autonomen Systeme, die das BGP-Protokoll verwenden). Um beispielsweise den eingehenden Verkehr aus dem Internet und/oder den ausgehenden Verkehr in das Internet zu leiten, können ein oder mehrere Kern-Switches implementiert werden, die als Gateway zum Internet (und/oder einem anderen WAN) dienen. Die Kern-Switches können Import-Routen-Karten (z.B. für ausgehenden Netzwerk-Verkehr) und/oder Export-Routen-Karten (z.B. für eingehenden Netzwerk-Verkehr) umfassen, die so konfiguriert werden können, dass sie das Routing des Netzwerk-Verkehrs, der zu den Datenzentren 102 kommt und/oder die Datenzentren 102 verlässt, unterstützen. Darüber hinaus können die Routing-Richtlinien der Kern-Switches - oder anderer NetzwerkGeräte 120 - lokale Präferenzwerte für bestimmte Ausgangs-Ports und/oder Eingangs-Ports umfassen, die vom System 100 verwendet werden können, um den Verkehr entlang eines bestimmten Pfades zu routen (z.B. über einen bevorzugten DC-ISP 110). Obwohl es sich bei den hierin beschriebenen Netzwerkgeräten 120 in erster Linie um Kern-Switches handelt, ist dies nicht als Einschränkung zu verstehen, und die hierin für die Kern-Switches beschriebenen Techniken können zusätzlich oder alternativ für andere Typen von Netzwerkgeräten 120 implementiert werden, ohne dass der Applikationsbereich der vorliegenden Offenbarung verlassen wird - wie z. B. Distribution-Switches, Edge-Geräte, Router, Zugangspunkte, Geräte der Kernschicht, Geräte der Verteilungsschicht, Geräte der Zugangsschicht usw. In einigen Ausführungsbeispielen kann/können der/die Netzwerkkonfigurator(en) 118 direkt auf den Kern-Switches ausgeführt oder eingesetzt werden - z.B., wenn die Kern-Switches oder andere Netzwerkgeräte 120 containerisierte Applikationen unterstützen.
  • Wie hierin beschrieben, kann in einigen Ausführungsbeispielen, sobald eine Applikationssitzung zwischen dem Client-Gerät 104 und dem Datenzentrum 102 initiiert wurde - z.B. über die Client-Applikation 122 und die Host-Applikation 112 - ein Dienstgüte-Monitor 116 die Dienstgüte der Applikationssitzung über zwei oder mehr DC ISPs 110 überwachen und den/die Netzwerk-Konfigurator(en) 118 und das/die Netzwerkgerät(e) 120 verwenden, um das Routing über einen ausgewählten DC ISP 110 (z.B. den DC ISP 110 mit der besten Dienstgüte) zu leiten. In einigen Beispielen kann dies das Wechseln von einem aktuellen DC ISP 110 zu einem anderen oder alternativen DC ISP 110 umfassen, um die QoS der Applikationssitzung zu erhöhen. Um dies zu erreichen, können in einigen Ausführungsbeispielen die internen Richtlinien des/der Netzwerkgeräte(s) 120 aktualisiert werden, um einen bestimmten DC ISP 110 zu bevorzugen - z.B. durch Aktualisierung der Import-Routen-Maps für BGP. In einigen Beispielen können zusätzlich oder alternativ zur Aktualisierung von Import-Routing-Maps Export-Routing-Maps aktualisiert werden - z.B. durch Voranstellen von Präfixen für autonome Systeme an die BGP-Kopfzeilen von Paketen -, um den Ingress-Verkehr von dem/den Client-Gerät(en) 104 so zu beeinflussen, dass er auch über einen gewünschten DC ISP 110 übertragen wird. In einigen Ausführungsbeispielen können Netzwerkprotokollattribute in der Host-Applikation 112 geändert werden, um einen der DC-ISPs 110 zu bevorzugen. Beispielsweise kann ein Attribut des IP-Netzwerkprotokolls (z.B. ein DSCP-Feld (Differentiated Services Code Point)) geändert werden, was dazu führen kann, dass der Verkehr über einen bestimmten Egress-ISP geroutet wird. In solchen Beispielen kann das Netzwerk-Routing durch richtlinienbasiertes Routing (policy based routing, PBR) konfiguriert werden, das basierend auf den DSCP-Werten routet und das normale BGP-Routing außer Kraft setzt (z.B. die Standard- oder eine BGP-Route, die von den Netzwerkkonfiguratoren festgelegt wurde).
  • Die Datenzentren 102 können einen Planer 114 umfassen, um die Durchführung von Netzwerktests in Verbindung mit einem Netzwerktester 124 des/der Client-Gerätes/e 104 zu unterstützen und/oder um die Distribution und Weiterleitung von Applikationssitzungs-Hostanfragen von einem Client-Gerät/en 104 zwischen und unter anderen Datenzentren 102 zu bestimmen. Wenn beispielsweise ein Planer 114 eines Datenzentrums 102 bestimmt, dass das Datenzentrum 102 nicht in der Lage ist, die Applikationssitzung zu hosten - z.B. verursacht durch Kapazitätsgrenzen, Überlastung, Ressourcendefizite, Lastausgleich, etc. - kann der Planer 114 die Anfrage an andere Datenzentren 102 routen, um ein geeignetes Datenzentrum zu finden, in dem die Applikationssitzung stattfinden kann. Sobald ein geeignetes Datenzentrum 102 bestimmt ist, können Verbindungsinformationen (z.B. eine IP-Adresse) des ausgewählten Datenzentrums 102 an das/die Client-Gerät(e) 104 gesendet werden, so dass das/die Client-Gerät(e) 104 die Applikationssitzung unter Verwendung des ausgewählten Datenzentrums 102 ausführt.
  • Das (die) Client-Gerät(e) 104 kann (können) einen oder mehrere Typen von Endbenutzer-Geräten umfassen, wie z. B. ein Smartphone, einen Laptop-Computer, einen Tablet-Computer, einen Desktop-Computer, ein tragbares Gerät, eine Spielkonsole, ein Smart-Home-Gerät, das einen KI-Agenten oder -Assistenten enthalten kann, ein Gerät oder System der virtuellen oder erweiterten Realität und/oder einen anderen Typ von Gerät. In einigen Beispielen kann (können) das (die) Client-Gerät(e) 104 eine Kombination von Geräten umfassen (z.B. ein Smartphone und eine kommunikativ gekoppelte Smartwatch oder ein anderes tragbares Gerät), und die damit assoziierten Client-Applikationen 122, einschließlich Interaktionen mit der Host-Applikation 112, können unter Verwendung eines oder mehrerer der Geräte ausgeführt werden (z.B. Smartphone-Applikation sendet Benachrichtigung an Smartwatch-Applikation, Benutzer stellt Eingabe an Smartwatch bereit, Daten, die die Eingabe repräsentieren, werden über das Smartphone an ein anderes Gerät des Systems 100 weitergeleitet).
  • Das/die Client-Gerät(e) 104 kann/können ein oder mehrere Eingabe/Ausgabe-Geräte umfassen, wie z.B. eine Tastatur, eine Maus, einen Controller, einen Touchscreen, eine Anzeige(n), einen Lautsprecher, ein Mikrofon, Kopfhörer, ein Headset (z.B. AR, VR, etc., das Eingaben basierend auf der Bewegung des Benutzers bereitstellen kann) und/oder andere Typen von Eingabe/Ausgabe-Geräten. Als solches kann die Applikationssitzung in einigen Ausführungsbeispielen einen Stream von Daten von dem/den Client-Gerät(en) 104 zu dem/den Datenzentrum(en) 102 und von dem/den Datenzentrum(en) 102 zu dem/den Client-Gerät(en) 104 umfassen. Die Streaming-Daten können ohne Einschränkung einen Audio-Stream von dem/den Client-Gerät(en) 104, einen Audio-Stream von dem/den Datenzentrum(en) 102, einen Video-Stream von dem/den Datenzentrum(en) 102, einen Eingabe-Stream von dem/den Client-Gerät(en) 104 und/oder andere Typen von Streams umfassen.
  • Das/die Client-Gerät(e) 104 kann/können die Client-Applikation 122 umfassen, die - zusammen mit der Host-Applikation 112 - eine Applikationssitzung ausführen kann. Wenn die Client-Applikation 122 und die Host-Applikation 112 Cloud-Gaming unterstützen, kann die Client-Applikation 122 beispielsweise auf eine API der Host-Applikation 112 zugreifen, um eine Instanz eines bestimmten Spiels (z.B. eine Applikationssitzung) auszuführen. In Ausführungsbeispielen können die applikationsspezifischen Tests, die vom Netzwerk-Tester 124 durchgeführt werden, dem Typ des Spiels entsprechen, das das Cloud-Gaming-System verwendet. In ähnlicher Weise kann die Applikationssitzung für Cloud-VR einer Cloud-VR-Instanz entsprechen, die Applikationssitzung für Remote-Desktop kann einer Remote-Desktop-Instanz entsprechen, usw. In allen Ausführungsbeispielen können die Applikationen unter Verwendung von Stream-Daten in Echtzeit ausgeführt werden, z.B. um die hohe Leistung und die geringen Latenzzeiten der Applikationen zu erfüllen. Die Netzwerktests können daher dem Echtzeit-Streaming entsprechen. Beispielsweise können die applikationsspezifischen Tests so durchgeführt werden, dass ein geeignetes Datenzentrum in der Lage ist, das Streaming der Daten der Applikationssitzung in Echtzeit auszuführen.
  • Der Netzwerktester 124 kann einen oder mehrere Netzwerktests durchführen oder deren Durchführung (z.B. durch das/die Datenzentrum(e) 102) veranlassen. Die Netzwerktests können beispielsweise einen Latenztest, einen Jitter-Test, einen Paketverlusttest, einen Bandbreitentest, einen anderen Typ von Test oder eine Kombination davon umfassen. In einigen Beispielen können die Netzwerktests verwendet werden, um ein Applikationsprofil unter Verwendung des Profilgenerators 126 zu generieren. Beispielsweise kann der Netzwerktester 124 für eine gegebene Client-Applikation 122, Applikationssitzung, UnterApplikation oder ein Programm innerhalb der Client-Applikation 122 usw. applikationsspezifische Tests durchführen, um die Fähigkeit des/der Client-Geräte(s) 104 und des assoziierten lokalen Netzwerks (z.B. einschließlich Wi-Fi, Ethernet, des Client-ISP 108 oder einer Kombination davon) zur Ausführung der Client-Applikation 122 - oder einer Applikationssitzung davon - zu bestimmen. In einigen Ausführungsbeispielen kann der Profilgenerator 126 ein Applikationsprofil auf der Applikationsebene generieren - z.B. für Cloud-Gaming, das Applikationsprofil kann für jede Verwendung der Client-Applikation 122 verwendet werden, wie z.B. für Spiele vom Typ Ego-Shooter, Sportspiele, Strategiespiele und andere Typen von Spielen. In anderen Ausführungsbeispielen kann das Applikationsprofil applikationsspezifisch sein - z.B. kann für Cloud-Gaming ein erstes Applikationsprofil für Spiele vom Typ Ego-Shooter generiert werden, ein zweites Applikationsprofil für Sportspiele, und so weiter. In weiteren Ausführungsbeispielen kann das Applikationsprofil jedem einzelnen Programm entsprechen, das die Client-Applikation 122 ausführt - z.B. kann für Cloud-Gaming ein Applikationsprofil für jedes individuelle Spiel generiert werden, und für Deep Learning kann ein Applikationsprofil für jedes Modell eines neuronalen Netzwerks oder für ein Deep Learning Framework generiert werden, usw. In einem anderen Ausführungsbeispiel kann das Applikationsprofil programmübergreifenden Typen entsprechen - z.B. kann für ein Ego-Shooter-Spiel in einer Cloud-Gaming-Umgebung ein erstes Applikationsprofil für einen Capture-the-Flag-Spieltyp innerhalb des Ego-Shooter-Spiels generiert werden und ein zweites Applikationsprofil für einen Team-Death-Match-Spieltyp. Das Applikationsprofil kann vom Profilgenerator 126 - und basierend auf den vom Netzwerktester 124 durchgeführten Netzwerktests - für verschiedene Granularitätsebenen innerhalb der Client-Applikation 122 generiert werden.
  • Das Applikationsprofil kann einer Qualität des Streams entsprechen, die das/die Client-Gerät(e) 104 während des Spielablaufs effektiv unterstützen kann/können. Beispielsweise kann das Applikationsprofil Informationen wie eine Bildauflösung (z.B. 720p, 1080p, 4K, 8K, etc.), eine Bitrate, eine Audioqualität (z.B. zu und von dem/den Client-Gerät(en) 104) und/oder andere Informationen - wie hierin beschrieben - umfassen, die für das System 100 informativ sein können, wenn es ein geeignetes Datenzentrum 102 für die Applikationssitzung auswählt, und informativ für das ausgewählte Datenzentrum 102, um eine Qualität des Streams an das/die Client-Gerät(e) 104 zu bestimmen - z.B, um einen Stream höchster Qualität zu senden, der unterstützt wird, um die Leistung nicht zu degradieren, aber auch um keine zu hohe Qualität eines Streams zu senden, den das/die Client-Gerät(e) 104 und/oder das assoziierte lokale Netzwerk nicht unterstützen könnte. So kann das Applikationsprofil verwendet werden, um die Qualitätserwartungen und - anforderungen eines bestimmten Benutzers für eine bestimmte Applikationssitzung zu erfüllen und auch um einen Lastausgleich (z.B. Weiterleitung von Applikationssitzungen an weniger überlastete Datenzentren 102) zu erreichen und Ressourcen in den Datenzentren 102 zu sparen (z.B. keine Zuweisung einer ganzen GPU für die Applikationssitzung, wenn eine partielle oder virtuelle GPU (vGPU) akzeptabel ist).
  • Als solches kann das Applikationsprofil - in Ausführungsbeispielen - auf dem (den) Client-Gerät(en) 104 gespeichert werden, so dass bei der Übermittlung einer Anfrage für einen Host (dt. auch nach einem Host, oder für ein Hosten) der Applikationssitzung an ein oder mehrere Datenzentren 102 das Applikationsprofil (oder entsprechende Informationen) in der Anfrage umfasst sein kann. In einigen Ausführungsbeispielen kann das Applikationsprofil zusätzlich oder alternativ in einem oder mehreren Datenzentren 102 (oder einem anderen, nicht dargestellten Gerät, wie z. B. einem anderen Rechengerät einer Web-Support-Plattform, das Applikationsprofile für Benutzer erhalten kann) gespeichert werden. In jedem Beispiel kann das Applikationsprofil mit einem Identitätsverwaltungssystem (IDS) des Systems 100 assoziiert sein.
  • In einigen Ausführungsbeispielen kann das Applikationsprofil den Ergebnissen der Tests im Netzwerk entsprechen. Beispielsweise kann das Applikationsprofil einen Latenzwert, einen Paketverlustwert, einen Jitterwert, einen Bandbreitenwert und/oder andere Werte umfassen, und diese Informationen können von dem Datenzentrum 102, das die Applikationssitzung hostet, verwendet werden, um die Qualität des Streams zu bestimmen (z.B. Videostream, Audio-Stream zu dem/den Client-Geräten) 104, Audio-Stream von dem/den Client-Gerät(en) 104, Eingabe-Stream von dem/den Client-Gerät(en) 104, usw.). In anderen Ausführungsbeispielen kann das Applikationsprofil der bekannten (oder getesteten) unterstützten Qualität des Streams entsprechen und Daten zur Bildqualität (z.B. Standard Dynamic Range (SDR) vs. High Dynamic Range (HDR)), zur Audioqualität, zur Codierung usw. umfassen. So kann das Applikationsprofil beispielsweise Informationen umfassen, die den Encoder-Einstellungen, einem Codierungsprotokoll (z.B. Real Time Messaging Protocol (RTMP), Common Media Application Format (CMAF) usw.), einem Video-Codec-Typ, einer Einzelbildrate, einer Keyframe-Sequenz, einem Audio-Codec, einem Bitraten-Codierungstyp, einer Bitrate, einem Pixel-Seitenverhältnis (z.B., quadratisch, 4:3, 16:9, 24:11 usw.), ein Typ des Einzelbildes (z.B. progressive Abtastung, zwei B-Frames, ein Referenz-Frame), ein Entropie-Codierungstyp, eine Audio-Abtastrate, eine Audio-Bitrate und/oder andere Einstellungen.
  • Zur Durchführung des/der Netzwerktests und unter Bezugnahme auf 2A kann der Netzwerktester 124 des/der Client-Geräte(s) 104 einen vorläufigen Netzwerktest - z.B. für die Latenz - zwischen dem Client-Gerät 104 und einer Vielzahl von Datenzentren 102 durchführen. Beispielsweise kann das Client-Gerät 104 - z.B. über Anforderungssignale 204A, 204B und 204C - eine exponierte API abfragen, um die für das Client-Gerät 104 verfügbaren Datenzentren 102 zu bestimmen, und das Client-Gerät 104 kann einen vorläufigen Netzwerktest durchführen (oder jedes der Datenzentren 102 zur Durchführung veranlassen). In einigen Ausführungsbeispielen, wie gezeigt, kann die API DNS-Informationen für Regionen zurückgeben (z.B. die Regionen 202A, 202B und 202C, die Regionen eines Staates, Landes, Kontinents usw. entsprechen können), und die Anforderungssignale 204 können zu einer auf einer Region basierenden IP-Adresse geleitet werden. Sobald das Anforderungssignal 204 empfangen wird, kann es an ein bestimmtes Datenzentrum innerhalb der Region weitergeleitet werden. Die Auswahl eines Datenzentrums 102 innerhalb der Region kann auf einer abwechselnden Auswahl basieren - z.B. kann für die Region 202A ein erstes Anforderungssignal 204 von einem ersten Client-Gerät 104 an das Datenzentrum 102A weitergeleitet werden, ein zweites Anforderungssignal 204 von einem Client-Gerät 104 kann an das Datenzentrum 102B weitergeleitet werden, ein drittes Anforderungssignal 204 kann an das Datenzentrum 102A weitergeleitet werden, und so weiter. In anderen Ausführungsbeispielen kann die Auswahl des Datenzentrums 102 für die Region 202 basierend auf Überlastung, Kapazität, Rechenressourcen, Hardware-Typen usw. in jedem der Datenzentren 102 in der Region 202 erfolgen. Das Verwenden von Regionen, anstatt Anfragen an jedes Datenzentrum zu leiten, kann die Laufzeit der Tests reduzieren, da weniger Tests durchgeführt werden müssen (z.B. kann davon ausgegangen werden, dass Datenzentren 102 derselben Region dieselben Leistungsmerkmale aufweisen). In einigen Ausführungsbeispielen kann die exponierte API dem Client-Gerät 104 jedoch spezifische Adressen von Datenzentren bereitstellen, und die Anforderungssignale 204 können nicht auf einer Region basieren.
  • Wenn der vorläufige Test die Latenz betrifft, kann der vorläufige Netzwerktest Latenzwerte für jedes der Datenzentren 102 zurückgeben - z.B. können ein oder mehrere Pakete von dem Client-Gerät 104 an die Datenzentren 102 übertragen werden, ein oder mehrere Pakete können von den Datenzentren 102 an das Client-Gerät 104 übertragen werden, oder eine Kombination davon, und die Zeit der Übertragung kann berechnet werden, um Latenzwerte zu bestimmen. Sobald die Latenzwerte bekannt sind, kann das Client-Gerät 104 ein initiales Host-Datenzentrum 102 für das Client-Gerät 104 auswählen - oder ein Planer von einem oder mehreren Datenzentren 102 kann ein solches auswählen -, um einen Test des Netzwerks durchzuführen. Beispielsweise kann das Datenzentrum 102 mit der niedrigsten Latenz ausgewählt werden, jedes der Datenzentren 102 unter einer Schwellenwertlatenz kann ausgewählt werden, und/oder es können andere Auswahlkriterien verwendet werden.
  • Sobald ein Datenzentrum 102 ausgewählt ist, kann das Client-Gerät 104 ein weiteres Anforderungssignal 204 an das ausgewählte Datenzentrum 102 übertragen, um einen oder mehrere zusätzliche Netzwerktests durchzuführen. Wenn beispielsweise das Datenzentrum 102A ausgewählt ist, kann das Client-Gerät 104 eine Anforderung für einen Jitter-Test, einen Paketverlusttest, einen Bandbreitentest, einen Latenztest und/oder einen anderen Typ von Test an das Datenzentrum 102A übertragen. Der Planer 114 des Datenzentrums 102 und/oder der Netzwerktester 124 des Client-Geräts 104 können dann einen oder mehrere Netzwerktests durchführen. In einigen Ausführungsbeispielen können die Netzwerktests unter Verwendung von applikationsspezifischem Datenverkehr durchgeführt werden, wie hier beschrieben. Wenn beispielsweise ein Bandbreitentest durchgeführt wird, kann ein standardmäßiger, nicht applikationsspezifischer Bandbreitentest keine genauen Ergebnisse für ein Spiel mit niedriger Latenz und hoher Leistung in einer Cloud-Spielumgebung liefern. Dies kann darauf zurückzuführen sein, dass ein Standard-Bandbreitentest den mit dem Spiel assoziierten stoßartigen Netzwerkverkehr nicht wiedergibt. Bei einer Verbindung mit hoher Latenz für ein Spiel mit niedriger Latenz kann es zum Beispiel sein, dass zu dem Zeitpunkt, an dem eine Eingabe an das Client-Gerät 104 an das Datenzentrum 102 übertragen, der Video-Stream aktualisiert und vom Client-Gerät 104 empfangen und angezeigt wird, die Anzeige zu spät erfolgt - was zu einem schlechten Spielerlebnis führt oder verursacht, dass der Benutzer das Spiel schlecht durchführt. Um dem Rechnung zu tragen, kann bei der Anforderung des Bandbreitentests das Spiel angegeben werden, dem der Netzwerktest entspricht, und das Datenzentrum 102A kann simulierten Netzwerkverkehr generieren, der dem Spiel entspricht. Auf diese Weise können die Testergebnisse der Bandbreite des lokalen Netzwerks des Client-Geräts 104 die Bandbreite des Netzwerks für das jeweilige Spiel genauer widerspiegeln. Diese Bandbreiteninformationen können dann mit dem Applikationsprofil für das Client-Gerät 104 assoziiert werden. In ähnlicher Weise können andere Tests unter Verwendung von simuliertem applikationsspezifischem Datenverkehr durchgeführt werden, um ein Applikationsprofil zu generieren, das direkt der Fähigkeit des Client-Geräts 104 und des assoziierten lokalen Netzwerks entspricht, Applikationssitzungen der Applikation (z.B. Spielinstanzen des Spiels in einer Cloud-Spielumgebung) zu unterstützen.
  • Das Applikationsprofil kann in regelmäßigen Abständen aktualisiert werden. Beispielsweise kann das Applikationsprofil in einem wiederkehrenden Intervall aktualisiert werden - z.B. jede Woche, jeden Monat, usw. - und/oder basierend auf Änderungen der Netzwerkcharakteristik aktualisiert werden. Wenn beispielsweise ein neues Datenzentrum 102 für das Client-Gerät 104 verfügbar wird, kann das Applikationsprofil im Hinblick auf das neue Datenzentrum 102 aktualisiert werden. Ein weiteres Beispiel: Wenn sich ein lokales Netzwerk des Client-Geräts 104 ändert - z.B. verursacht durch einen Umzug des Client-Geräts 104 an einen neuen Ort, eine Aktualisierung des Heimnetzwerks usw. - kann das Applikationsprofil aktualisiert werden.
  • In einigen Ausführungsbeispielen können benutzerseitige Informationen basierend auf den Netzwerktests generiert werden. Wenn beispielsweise die Netzwerkverbindung nicht stark ist, die Bandbreite gering ist usw., kann eine Empfehlung für den Benutzer generiert werden, die angibt, dass er - wenn das Benutzergerät 104 über Wi-Fi verbunden ist - näher an den Router heranrücken, 5 GHz anstelle von 2,4 GHz verwenden sollte, oder umgekehrt usw. Ein weiteres Beispiel ist die Empfehlung an den Benutzer, die Einstellungen seines Geräts anzupassen, die Internetgeschwindigkeit beim Client-ISP 108 zu erhöhen, usw. Sobald der Benutzer Aktualisierungen vornimmt, können die Netzwerktests erneut durchgeführt werden, um das Client-Gerät 104 und die assoziierten Netzwerkfähigkeiten genauer zu bestimmen, damit der Benutzer optimale Qualitätseinstellungen für seine Applikation erhält..
  • Sobald ein Applikationsprofil generiert worden ist, kann das Client-Gerät 104 ein Host-Anforderungssignal 206 an ein Datenzentrum 102 übertragen, um anzufordern, dass das Datenzentrum 102 oder ein anderes Datenzentrum 102 eine Applikationssitzung hostet (siehe 2B). Wenn beispielsweise ein Benutzer eine Eingabe an das Client-Gerät 104 bereitstellt, die angibt, dass der Benutzer eine Applikationssitzung starten möchte (z.B. an einer Instanz eines Spiels in einer Cloud-Spielumgebung teilnehmen möchte), kann das Client-Gerät 106 das Host-Anforderungssignal 206 generieren und übertragen. In einigen Ausführungsbeispielen, ähnlich der Beschreibung in 2A, kann ein vorläufiger Netzwerktest - z.B. ein Latenztest - durchgeführt werden, um ein Datenzentrum 102A zum Übertragen des Host-Anforderungssignals 206 auszuwählen. Sobald ein ausgewähltes Datenzentrum 102A ausgewählt ist, kann das Host-Anforderungssignal 206 an das Datenzentrum 102A übertragen werden. Der vorläufige Netzwerktest kann mehr als ein geeignetes Datenzentrum 102 ergeben (z.B. mehr als ein Datenzentrum 102 mit akzeptabler Latenzzeit). In solchen Beispielen kann das Host-Anforderungssignal 206 Daten umfassen, die den Adressen (z.B. IP-Adressen) der anderen geeigneten Datenzentren 102 entsprechen, die vom Datenzentrum 102A verwendet werden können, um zu bestimmen, wohin die Weiterleitungsanforderungssignale 208 zu senden sind. In einigen Ausführungsbeispielen kann das Host-Anforderungssignal 206 weiter Daten umfassen, die dem Applikationsprofil des Client-Geräts 104 entsprechen, so dass das Datenzentrum 102A die Qualität der Streams bestimmen kann, ob das Datenzentrum 102A die Applikationssitzung hosten kann und/oder die Applikationsprofil-Informationen in die Weiterleitungs-Anforderungssignale 208 umfassen kann.
  • Der Planer 114 des Datenzentrums 102A kann das Host-Anforderungssignal 206 empfangen und bestimmen, ob die Applikationssitzung gehostet oder weitergeleitet werden soll. In einigen Ausführungsbeispielen kann der Planer 114 basierend auf den Daten im Host-Anforderungssignal 206 den Applikationstyp (oder Programmtyp, wie z. B. ein bestimmtes Spiel oder einen Spieltyp) und die assoziierten Applikationsleistungsanforderungen bestimmen. Damit eine bestimmte Applikation ordnungsgemäß oder effektiv ausgeführt werden kann, kann die Applikation beispielsweise eine Latenzzeit unterhalb eines Schwellenwerts, eine Bitrate oberhalb eines Schwellenwerts usw. erfordern, und diese Informationen können - in Verbindung mit den Leistungsanforderungen aus dem Applikationsprofil - verwendet werden, um zu bestimmen, ob das Datenzentrum 102A die Applikationssitzung hosten kann. Wenn das Datenzentrum 102A die Applikationssitzung nicht beherbergen kann, können die Applikationsleistungsanforderungen, Applikationsprofilinformationen und/oder andere Informationen in den Weiterleitungsanforderungssignalen 208 an andere Datenzentren 102 umfasst sein.
  • Der Planer 114 kann - z.B. basierend auf der Feststellung, dass das Datenzentrum 102A die Applikationssitzung nicht hosten kann - ein oder mehrere Vorwärtsanforderungssignale 208 an andere geeignete Datenzentren 102 übertragen. Die geeigneten Datenzentren 102 können in Ausführungsbeispielen basierend auf den Daten aus dem Host-Anforderungssignal 206 vom Client-Gerät 104 bestimmt werden, das Daten umfasste, die anderen Datenzentren 102 entsprechen, die einen oder mehrere Werte (z.B. Latenzwerte) aus dem/den vorläufigen Netzwerktest(en) erfüllten. In einigen Ausführungsbeispielen können die geeigneten Datenzentren 102 zusätzlich oder alternativ zu dem Ergebnis der vorläufigen Netzwerktests basierend auf Applikationsleistungsanforderungen (z.B. kann es bekannt sein, dass bestimmte Datenzentren 102 bestimmte Applikationen nicht unterstützen können), Netzwerkleistungsanforderungen (z.B, es kann bekannt sein, dass bestimmte Datenzentren 102 die Qualität von Streams nicht unterstützen können, die ein Client-Gerät 104 und das assoziierte Netzwerk verarbeiten können, oder dass DC ISPs 110 bestimmter Datenzentren 102 nicht gut mit dem Client ISP 108 interagieren), Hardwarebeschränkungen (z.B. kann bekannt sein, dass bestimmte Datenzentren 102 nicht über Hardware zum Generieren von Streams der erforderlichen Qualität verfügen, die GPUs, CPUs, Speicher, ein bestimmtes Modell oder eine bestimmte Fähigkeit einer GPU, CPU oder eines Speichers usw. umfassen kann). Im Beispiel von 2B können die geeigneten Datenzentren 102 die Datenzentren 102B, 102C und 102D umfassen, und das Datenzentrum 102E kann als nicht geeignet bestimmt worden sein (z.B. kann die Latenz zu hoch sein, verursacht durch das Datenzentrum 102E, das sich in der Region 202C befindet, die weit entfernt sein kann - z.B., 500+ Meilen - von einem Ort des Client-Geräts 104 entfernt ist, verfügt das Datenzentrum 102E möglicherweise nicht über die erforderliche Hardware, um einen qualitativ hochwertigen Stream zu generieren, wie z. B. einen Videostream, der unter Verwendung von Ray-Tracing- oder Path-Tracing-Techniken generiert wird, usw.). Die gleichen Gründe, aus denen ein anderes Datenzentrum 102 - wie z. B. das Datenzentrum 102E - möglicherweise nicht geeignet ist, können auch von dem ausgewählten Datenzentrum 102A analysiert werden, um zu bestimmen, dass das Datenzentrum 102A die Applikationssitzung nicht hosten kann.
  • Die Vorwärtsanforderungssignale 208 können auf einmal an jedes geeignete Datenzentrum 102, an eine Teilmenge der geeigneten Datenzentren usw. übertragen werden, oder sie können jeweils an ein geeignetes Datenzentrum 102 übertragen werden und basierend auf Ablehnungen der Vorwärtsanforderungssignale 208 an weitere Datenzentren 102. Wenn die Vorwärtsanforderungssignale 208 individuell übertragen werden, kann die Reihenfolge, in der die Vorwärtsanforderungssignale 208 übertragen werden, basierend auf den vorläufigen Netzwerktestdaten (z.B. niedrigste Latenz zuerst, höchste Latenz zuletzt), der Entfernung von den Datenzentren (z.B. nächstgelegene Datenzentren 102 zum Datenzentrum 102A zuerst, weiter entfernte Datenzentren 102 vom Datenzentrum 102A zuletzt) und/oder einigen anderen Kriterien bestimmt werden. Zum Beispiel kann ein Datenzentrum 102 immer zuerst an ein Datenzentrum in derselben Region 202 weiterleiten und dann andere Regionen 202 in Betracht ziehen, wenn keines der Datenzentren 102 in der Region 202 die Weiterleitungsanforderung aus dem Weiterleitungsanforderungssignal 208 akzeptiert.
  • Die Weiterleitungsanforderungssignale 208 können von den Planern 114 der empfangenden Datenzentren 102 analysiert werden, und die Planer 114 können - unter Berücksichtigung aller verfügbaren Informationen - bestimmen, ob das Datenzentrum die Applikationssitzung empfangen kann. Wenn das Datenzentrum 102 die Applikationssitzung nicht aufnehmen kann, kann das Datenzentrum 102 ein Verweigerungssignal (nicht gezeigt) an das Datenzentrum 102A zurücksenden. Im Beispiel von 2B können die Datenzentren 102B und 102C die Weiterleitungsanforderung ablehnen, und das Datenzentrum 102D kann das Weiterleitungsanforderungssignal annehmen. Nach der Annahme kann der Planer 114 des Datenzentrums 102A diese Informationen empfangen und ein Annahmesignal (nicht gezeigt) an das Client-Gerät 104 übertragen. Das Annahmesignal kann Daten umfassen, die eine Adresse des Datenzentrums 102D repräsentieren, so dass das Client-Gerät 104 eine kommunikative Kopplung mit dem Datenzentrum 102D herstellen kann, und das Datenzentrum 102D kann die Applikationssitzung zwischen der Client-Applikation 122 und der Host-Applikation 112, die im Datenzentrum 102D ausgeführt wird, hosten.
  • Unter Bezugnahme auf 2C kann in einigen Ausführungsbeispielen das Datenzentrum 102A geeignet sein, die Applikationssitzung zu hosten - z.B. kann das Datenzentrum 102A die erforderliche Hardware, Netzwerkcharakteristiken usw. haben, um das Spiel ohne Degradation zu hosten -, kann aber dennoch die Anforderung an ein anderes Datenzentrum 102 weiterleiten. Beispielsweise kann das Datenzentrum 102A auch auf Überlastung überwachen, und wenn das Datenzentrum 102A - basierend auf historischen Daten oder aktuell verfügbaren Daten (z.B. eine große Warteschlange von Nutzern oder eine große Welle von Nutzern, die kürzlich die Initialisierung der Applikation angefordert haben) - eine Spitze im Datenverkehr zu einem aktuellen Zeitpunkt oder einem zukünftigen Zeitpunkt, während dem die Applikationssitzung gehostet werden kann, erwartet, kann das Datenzentrum 102A versuchen, die Anforderung (z.B., über das Weiterleitungsanforderungssignal 208D) an ein anderes geeignetes Datenzentrum 102 weiterzuleiten, das nicht die gleichen Überlastungsprobleme aufweist, aber dennoch die Dienstqualitätsanforderungen der Applikationssitzung erfüllt. Beispielsweise kann der Planer 114 des Datenzentrums 102A historische Daten anderer Datenzentren speichern und ein Datenzentrum mit geringerer Überlastung bestimmen (z.B. kann sich das Datenzentrum 102A an der Westküste der Vereinigten Staaten befinden und das Host-Anforderungssignal 206 um 21:00 PM PST empfangen werden, wenn starker Verkehr normal ist; das Datenzentrum 102E kann sich jedoch an der Ostküste der Vereinigten Staaten befinden, wo es 12:00 PM EST ist und der Verkehr geringer ist). In einigen Ausführungsbeispielen können zusätzlich oder alternativ zur Überlastung oder zum erwarteten Datenverkehr die Leistungsanforderungen der Applikationssitzung bei dem Bestimmen, ob die Anfrage weitergeleitet werden soll, berücksichtigt werden. Wenn beispielsweise ein Spiel keine niedrige Latenz erfordert, kann sich das Datenzentrum 102A für Benutzer, die latenzempfindliche Spiele spielen, aufsparen und die Anfrage an das Datenzentrum 102E weiterleiten, um die Applikationssitzung zu hosten - z.B. weil das Datenzentrum 102E die Latenzanforderungen des Spiels erfüllen kann, obwohl es weiter vom Client-Gerät 104 entfernt ist. Zusätzlich zum Bestimmen, ob die Datenzentren 102 die Leistungsanforderungen der Applikationssitzung ohne Degradation unterstützen können, kann der Planer 114 zusätzliche Faktoren analysieren, um zu bestimmen, ob die Applikationssitzung lokal gehostet oder an ein anderes Datenzentrum 102 weitergeleitet werden soll.
  • Mit Bezug auf 2D, sobald eine Applikationssitzung initiiert wurde, können die QoS-Metriken vom QoS-Monitor 116 überwacht werden, um die Routing-Einstellungen für den Netzwerkverkehr der Applikationssitzung zu bestimmen. Beispielsweise können verschiedene DC-ISPs 110 für das Datenzentrum 102D bessere Leistungen erbringen als andere DC-ISPs 110, und die Leistung der verschiedenen DC-ISPs 110 kann während der Applikationssitzung überwacht werden, um zu bestimmen, ob Routing-Aktualisierungen vorgenommen werden sollten. So kann der aktuelle DC-ISP 110A auf QoS überwacht werden (z.B. auf die Ausbeute der Applikationssitzung oder andere Metriken zur Applikationsqualität) und der DC-ISP 110B kann auf dieselben oder ähnliche Metriken überwacht werden. Interne Netzwerkqualitätsprobleme bei den DC ISPs 110 können die Applikationssitzungsleistung beeinträchtigen, und der/die Netzwerkkonfigurator(en) 118 des Datenzentrums 102D kann/können eine Indikation vom QoS-Monitor 116 empfangen, dass der Netzwerkverkehr vom DC ISP 110A weg und zum DC ISP 110B geschaltet werden sollte. Wenn die Applikationsleistung der Applikationssitzung unter einen Schwellenwert fällt und die Leistung über einen anderen DC ISP 110 besser ist, kann der QoS-Monitor 116 eine Warnung übermitteln, um den Netzwerkverkehr auf einen Netzwerkpfad zu schalten, der den DC ISP 110B mit der besseren Leistung umfasst. In einigen Ausführungsbeispielen kann der QoS-Monitor die Applikationsleistung aus den Metriken des Streamings der Applikation abfragen.
  • Der QoS-Monitor 116 kann die Netzwerk- und/oder Applikationsleistung überwachen, indem er Netzwerkleistungsmetriken (z.B. Latenz, Paketverluste, Jitter, mit verschiedenen DC ISPs 110 assoziierte Kosten, mit verschiedenen DC ISPs 110 assoziierte Kapazitäten usw.) und/oder Applikationsleistungsmetriken (z.B. Streaming-Sitzungsausbeute, Applikations-QoS-Metriken usw.) als Eingaben verwendet. Diese Eingaben können durch das Übertragen von Testproben (z.B. Pings) und/oder das Simulieren von applikationsspezifischem Netzwerkverkehr zwischen dem Client-Gerät 104 und dem Datenzentrum 102 sowie durch das Analysieren der resultierenden Kommunikation bestimmt werden, um die Netzwerk- und/oder Applikationsleistungsmetriken zu ermitteln. Beispielsweise kann eine REST-Schnittstelle (z.B. eine API) offengelegt werden, um den QoS-Monitor 116 in die Lage zu versetzen, Informationen über den Netzwerkpfad zu veröffentlichen, wie z.B. Informationen über den tatsächlichen Pfad (z.B. welche autonomen Systeme für die Kommunikation mit anderen autonomen Systemen konfiguriert sind), Metriken zur Netzwerkleistung (und/oder Daten, die analysiert werden können, um dieselben zu bestimmen) und/oder Metriken zur Applikationsleistung (oder Daten, die analysiert werden können, um dieselben zu bestimmen).
  • Die QoS-Monitore 116 können innerhalb des Systems 100 verteilt werden, je nach Typ der Netzwerkverkehrsinformationen und/oder der Geräte, zwischen denen der Netzwerkverkehr überwacht werden soll. So kann der QoS-Monitor 116 einen Monitor umfassen, der im Datenzentrum 102 ausgeführt wird (z.B. zur Überwachung des Ausgangs- und/oder Eingangsverkehrs zwischen dem Datenzentrum 102 und dem/den Client-Gerät(en) 104 und zur Übermittlung von Informationen zurück an den QoS-Monitor 116 des Client-Geräts 104) und/oder einen QoS-Monitor 116, der auf dem/den Client-Gerät(en) 104 ausgeführt wird (z.B. zur Prüfung des Verkehrs zwischen dem/den Client-Gerät(en) 104 und dem Datenzentrum 102 und zur Übermittlung von Informationen zurück an den QoS-Monitor 116 des Datenzentrums 102). In einigen Ausführungsbeispielen kann ein einzelner QoS-Monitor 116 auf zwei oder mehr Datenzentren 102 und/oder das/die Client-Gerät(e) 104 aufgeteilt werden. Beispielsweise kann ein erster Teil eines QoS-Monitors 116 im Datenzentrum 102 und ein zweiter Teil auf dem Client-Gerät 104 ausgeführt werden, und die Kommunikation kann zwischen den beiden ausgetauscht werden, um verschiedene Netzwerkpfade zu überwachen und Ende-zu-Ende-Netzwerk- und/oder Applikationsleistungsmetriken zu testen.
  • Sobald ein aktualisierter Pfad für das Routing bestimmt ist, können die Änderungen im Routing des Netzwerks als Nachrichten an den/die Netzwerkkonfigurator(en) 118 veröffentlicht oder gepostet werden. Der/die Netzwerkkonfigurator(en) 118 kann/können die Routing-Aktualisierungen an den Endpunkten des Zielnetzwerks (z.B. Netzwerkgerät(e) 120) implementieren, z.B. durch Aktualisieren von Import-Routing-Maps und/oder Export-Routing-Maps von Kern-Switches (z.B. durch Aktualisieren lokaler Präferenzwerte für einen bestimmten Egress-Port und/oder Voranstellen von Präfixen autonomer Systeme an Export-Routing-Maps zur Steuerung des Ingress-Verkehrs unter Verwendung eines Route-Injectors).
  • Bezug nehmend auf 3-4, umfasst jeder Block der hier beschriebenen Verfahren 300 und 400 einen Rechenprozess, der unter Verwendung einer beliebigen Kombination von Hardware, Firmware und/oder Software durchgeführt werden kann. Zum Beispiel können verschiedene Funktionen von einem Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt. Die Verfahren 300 und 400 können auch als computerverwendbare Anweisungen, die auf Computerspeichermedien gespeichert sind, verkörpert werden. Die Verfahren 300 und 400 können durch eine eigenständige Applikation, einen Dienst oder gehosteten Dienst (eigenständig oder in Kombination mit einem anderen gehosteten Dienst) oder ein Plug-in für ein anderes Produkt bereitgestellt werden, um nur einige zu nennen. Darüber hinaus werden die Verfahren 300 und 400 beispielhaft in Bezug auf das System 100 von 1 beschrieben. Diese Verfahren können jedoch zusätzlich oder alternativ durch ein beliebiges System oder eine beliebige Kombination von Systemen ausgeführt werden, einschließlich, aber nicht beschränkt auf die hier beschriebenen.
  • 3 ist ein Flussdiagramm, das ein Verfahren 300 zur Distribution und Weiterleitung von Applikationssitzungen gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung zeigt. Das Verfahren 300 umfasst in Block B302 ein Empfangen von Daten, die eine erste Anforderung für einen Host einer Applikationssitzung repräsentieren. Zum Beispiel kann das Datenzentrum 102A das Host-Anforderungssignal 206 von dem Client-Gerät 104 empfangen, das Daten umfassen kann, die den Applikationstyp (z.B. das spezifische Spiel) und das Applikationsprofil für das Client-Gerät 104 angeben.
  • Das Verfahren 300 umfasst in Block B304 ein Bestimmen von Applikationsleistungsanforderungen für eine mit der Applikationssitzung assoziierte Applikation. Zum Beispiel kann das Datenzentrum 102A den Applikationstyp - oder den Programmtyp, wie z.B. ein spezifisches Spiel in einer Game-Streaming-Umgebung - und die assoziierten Leistungsanforderungen für die Applikation (z.B. Latenz, Hardware, etc.) bestimmen.
  • Das Verfahren 300 umfasst in Block B306 ein Bestimmen, basierend auf einer Analyse eines Streaming-Profils eines Benutzergeräts und der Applikationsleistungsanforderungen, dass die Applikationssitzung nicht in einem ersten Datenzentrum gehostet werden soll. Beispielsweise kann das Datenzentrum 102A basierend auf dem Bestimmen, dass die Netzwerkqualität, Hardwareressourcen, Überlastungsprobleme und/oder andere Kriterien nicht erfüllt sind, die es erlauben würden, die Applikationsleistungsanforderungen und die Applikationsprofilanforderungen zu erfüllen, bestimmen, die Applikationssitzung nicht zu hosten.
  • Das Verfahren 300 umfasst in Block B308 ein Senden von Daten, die eine zweite Anforderung zum Hosten der Applikationssitzung repräsentieren, an ein zweites Datenzentrum. Zum Beispiel kann das Datenzentrum 102A ein Weiterleitungsanforderungssignal 208 an das Datenzentrum 102B übertragen, das Daten umfasst, die den Applikationsleistungsanforderungen und den Applikationsprofil-Leistungsanforderungen entsprechen.
  • Das Verfahren 300 umfasst in Block B310 ein Empfangen von Daten, die eine Annahme der Applikationssitzung von dem zweiten Datenzentrum repräsentieren. Beispielsweise kann das Datenzentrum 102A ein Akzeptanzsignal vom Datenzentrum 102B als Antwort auf das Weiterleitungsanforderungssignal 208 empfangen.
  • Das Verfahren 300 in Block B312 umfasst ein Verursachen, basierend auf der Annahme, dass Netzwerkverkehr, der der Applikationssitzung entspricht, zu dem zweiten Datenzentrum geroutet wird. Zum Beispiel kann das Datenzentrum 102A Daten an das Client-Gerät 104 übertragen, die anzeigen, dass die Applikationssitzung vom Datenzentrum 102B gehostet wird, und die Applikationssitzung kann unter Verwendung des Datenzentrums 102B ausgeführt werden - z.B. kann der Netzwerkverkehr, der der Applikationssitzung entspricht, an das Datenzentrum 102B übertragen werden.
  • 4 ist ein Flussdiagramm, das ein Verfahren 400 zum Generieren von Applikationsprofilen gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung zeigt. Das Verfahren 400 umfasst in Block B402 das Bestimmen einer Vielzahl von Datenzentren mit einer assoziierten Latenz, die geringer ist als eine Schwellenwertlatenz. Zum Beispiel kann das Client-Gerät 104 einen vorläufigen Netzwerk-Test mit einer Vielzahl von Datenzentren 102 durchführen, um geeignete Datenzentren für eine Applikationssitzung zu bestimmen.
  • Das Verfahren 400 umfasst in Block B404 ein Übertragen einer Anforderung zum Ausführen eines oder mehrerer an eine Applikation angepasster Tests der Netzwerkleistung. Sobald beispielsweise ein Datenzentrum 102 ausgewählt ist, kann das Client-Gerät 104 eine Anforderung zur Ausführung eines oder mehrerer Netzwerktests übertragen, die simulierten Datenverkehr für die Applikation verwenden, die Gegenstand einer Applikationssitzung sein wird.
  • Das Verfahren 400 umfasst in Block B406 ein Austauschen von Netzwerkverkehr und assoziierten Leistungsmetriken für den/die Netzwerktest(e). Beispielsweise können Daten, die den Netzwerkverkehr der Applikation repräsentieren, zwischen dem Client-Gerät 104 und dem Datenzentrum 102 übertragen werden, und die aus den Tests gewonnenen Daten können zwischen den Geräten und untereinander gemeinsam genutzt werden.
  • Das Verfahren 400 umfasst in Block B408 ein Generieren eines Applikationsprofils, das der Applikation basierend auf den assoziierten Leistungsmetriken entspricht. Zum Beispiel kann der Profilgenerator 126 ein Applikationsprofil generieren, das dem Applikationstyp (oder einem Unterprogramm davon) entspricht, basierend auf den assoziierten Leistungsmetriken aus dem/den Netzwerktest(en) (z.B. Latenz, Paketverlust, Jitter, Bandbreite, etc.). Zum Beispiel kann die Qualität des Video-Streams, des Audio-Streams, des Eingabe-Streams und/oder eine andere Qualitätsbestimmung vorgenommen werden.
  • Das Verfahren 400 umfasst in Block B410 das Übertragen von Daten, die eine Anforderung für einen Host einer Applikationssitzung repräsentieren, wobei die Anforderung Informationen umfasst, die dem Applikationsprofil entsprechen. Beispielsweise können die Applikationsprofil-Informationen in einem Host-Anforderungssignal 206 an ein Datenzentrum 102 enthalten sein, wenn ein geeigneter Host für eine Applikationssitzung gefunden wird.
  • Beispielhaftes Spiele-Streaming-System
  • 5 ist ein beispielhaftes Systemdiagramm für ein Spiele-Streaming-System 500, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung. 5 umfasst Spieleserver 502 (die ähnliche Komponenten, Merkmale und/oder Funktionalität wie das Beispiel-Rechengerät 600 von 6 umfassen können), Client-Gerät(e) 504 (die ähnliche Komponenten, Merkmale und/oder Funktionalität wie das Beispiel-Rechengerät 600 von 6 umfassen können) und Netzwerk(e) 506 (die dem/den hier beschriebenen Netzwerk(en) ähnlich sein können). In einigen Ausführungsbeispielen der vorliegenden Offenbarung kann das System 500 implementiert werden.
  • Im System 500 kann das (die) Client-Gerät(e) 504 für eine Spielesitzung nur Eingabedaten als Antwort auf Eingaben an das (die) Eingabegerät(e) empfangen, die Eingabedaten an den (die) Spieleserver 502 übertragen, kodierte Anzeigedaten von dem (den) Spieleserver(n) 502 empfangen und die Anzeigedaten auf dem Display 524 anzeigen. Somit wird das rechenintensivere Rechnen und Verarbeiten auf den/die Spieleserver 502 verlagert (z.B. wird das Rendern - insbesondere das Ray- oder Pfad-Tracing - für die grafische Ausgabe der Spielesitzung von der/den GPU(s) des/der Spieleserver(s) 502 ausgeführt). Mit anderen Worten: Die Spielesitzung wird von dem/den Spieleserver(n) 502 an das/die Client-Gerät(e) 504 gestreamt, wodurch die Anforderungen des/der Client-Gerät(e) 504 zum grafischen Verarbeiten und Rendern reduziert werden.
  • Zum Beispiel kann ein Client-Gerät 504 bei einer Instanziierung einer Spielesitzung ein Einzelbild der Spielesitzung auf der Anzeige 524 basierend auf dem Empfang der Anzeigedaten von dem/den Spieleserver(n) 502 anzeigen. Das Client-Gerät 504 kann eine Eingabe an eines der Eingabegeräte empfangen und daraufhin Eingabedaten generieren. Das Client-Gerät 504 kann die Eingabedaten über die Kommunikationsschnittstelle 520 und über das Netzwerk (die Netzwerke) 506 (z.B. das Internet) an den/die Spieleserver 502 übertragen, und der/die Spieleserver 502 kann die Eingabedaten über die Kommunikationsschnittstelle 518 empfangen. Die CPU(s) kann/können die Eingabedaten empfangen, die Eingabedaten verarbeiten und Daten an die GPU(s) übertragen, die die GPU(s) veranlassen, ein Generieren der Spielsitzung zu erzeugen. Die Eingabedaten können beispielsweise eine Bewegung einer Spielfigur des Benutzers repräsentieren, das Abfeuern einer Waffe, das Nachladen, das Abgeben eines Balls, das Wenden eines Fahrzeugs, usw. Die Rendering-Komponente 512 kann die Spielsitzung rendern (z.B. repräsentativ für das Ergebnis der Eingabedaten), und die Rendering-Erfassungskomponente 514 kann das Rendering der Spielsitzung als Anzeigedaten erfassen (z.B. als Bilddaten, die das gerenderte Einzelbild der Spielsitzung erfassen). Das Rendern der Spielsitzung kann strahlen- oder pfadverfolgte Beleuchtungs- und/oder Schatteneffekte umfassen, die unter Verwendung einer oder mehrerer paralleler Verarbeitungseinheiten - wie GPUs, die weiter die Verwendung eines oder mehrerer dedizierter Hardwarebeschleuniger oder Verarbeitungskerne zum Durchführen von Strahlen- oder Pfadverfolgungstechniken verwenden können - des/der Spieleserver(s) 502 berechnet werden. Der Kodierer 516 kann dann die Anzeigedaten kodieren, um kodierte Anzeigedaten zu generieren, und die kodierten Anzeigedaten können über das/die Netzwerk(e) 506 über die Kommunikationsschnittstelle 518 an das Client-Gerät 504 übertragen werden. Das Client-Gerät 504 kann die kodierten Anzeigedaten über die Kommunikationsschnittstelle 520 empfangen und der Dekodierer 522 kann die kodierten Anzeigedaten dekodieren, um die Anzeigedaten zu generieren. Das Client-Gerät 504 kann dann die Anzeigedaten über die Anzeige 524 anzeigen.
  • Beispielhaftes Rechengerät
  • 6 ist ein Blockdiagramm eines beispielhaften Rechengeräts 600, das zur Verwendung bei der Implementierung einiger Ausführungsbeispiele der vorliegenden Offenbarung geeignet ist. Das Rechengerät 600 kann ein Verbindungssystem 602 enthalten, das direkt oder indirekt die folgenden Geräte koppelt: Speicher 604, eine oder mehrere zentrale Verarbeitungseinheiten (CPUs) 606, eine oder mehrere Grafikverarbeitungseinheiten (GPUs) 608, eine Kommunikationsschnittstelle 610, Ein-/Ausgabeanschlüsse (E/A) 612, Eingabe-/Ausgabekomponenten 614, eine Stromversorgung 616, eine oder mehrere Präsentationskomponenten 618 (z.B. Anzeige(n)) und eine oder mehrere Logikeinheiten 620.
  • Obwohl die verschiedenen Blöcke in 6 als über das Verbindungssystem 602 mit Leitungen verbunden dargestellt sind, ist dies nicht als Einschränkung zu verstehen und dient nur der Übersichtlichkeit. In einigen Ausführungsbeispielen kann z.B. eine Präsentationskomponente 618, wie ein Anzeigegerät, als E/A-Komponente 614 betrachtet werden (z.B. wenn die Anzeige ein Touchscreen ist). Als weiteres Beispiel können die CPUs 606 und/oder GPUs 608 einen Speicher umfassen (z.B. kann der Speicher 604 ein Speichergerät zusätzlich zum Speicher der GPUs 608, der CPUs 606 und/oder anderer Komponenten repräsentieren). Mit anderen Worten, das Rechengerät von 6 ist lediglich illustrativ. Es wird nicht zwischen Kategorien wie „Workstation“, „Server“, „Laptop“, „Desktop“, „Tablet“, „Client-Gerät“, „mobiles Gerät“, „Handheld-Gerät“, „Spielkonsole“, „elektronische Steuereinheit (ECU)“, „Virtual-Reality-System“ und/oder anderen Typen von Geräten oder Systemen unterschieden, da alle im Rahmen des Rechengeräts von 6 in Betracht gezogen werden.
  • Das Verbindungssystem 602 kann eine oder mehrere Verbindungen oder Busse repräsentieren, wie z. B. einen Adressbus, einen Datenbus, einen Steuerbus oder eine Kombination davon. Das Verbindungssystem 602 kann einen oder mehrere Bus- oder Verbindungstypen umfassen, wie einen ISA-Bus (Industry Standard Architecture), einen EISA-Bus (Extended Industry Standard Architecture), einen VESA-Bus (Video Electronics Standards Association), einen PCI-Bus (Peripheral Component Interconnect), einen PCIe-Bus (Peripheral Component Interconnect Express) und/oder einen anderen Typ von Bus oder Verbindung. In einigen Ausführungsbeispielen gibt es direkte Verbindungen zwischen den Komponenten. So kann die CPU 606 beispielsweise direkt mit dem Speicher 604 verbunden sein. Weiter kann die CPU 606 direkt mit der GPU 608 verbunden sein. Bei direkten oder Punkt-zu-Punkt-Verbindungen zwischen Komponenten kann das Verbindungssystem 602 einen PCIe-Link umfassen, um die Verbindung herzustellen. In diesen Beispielen braucht das Rechengerät 600 keinen PCI-Bus zu umfassen.
  • Der Speicher 604 kann eine Vielzahl von computerlesbaren Medien umfassen. Bei den computerlesbaren Medien kann es sich um alle verfügbaren Medien handeln, auf die das Rechengerät 600 zugreifen kann. Die computerlesbaren Medien können sowohl flüchtige als auch nicht-flüchtige Medien sowie entfernbare und nicht-entfernbare Medien umfassen. Als Beispiel und ohne Einschränkung können die computerlesbaren Medien Computerspeichermedien und Kommunikationsmedien umfassen.
  • Die Computer-Speichermedien können sowohl flüchtige als auch nicht-flüchtige Medien und/oder entfernbare und nicht-entfernbare Medien umfassen, die in einem beliebigen Verfahren oder einer Technologie zur Speicherung von Informationen wie computer-implementierten Anweisungen, Datenstrukturen, Programm-Modulen und/oder anderen Typen von Daten implementiert sind. Der Speicher 604 kann z.B. computerlesbare Anweisungen speichern (z.B., die ein oder mehrere Programme und/oder ein oder mehrere Programmelemente repräsentieren, wie z.B. ein Betriebssystem. Computerspeichermedien können unter anderem RAM, ROM, EEPROM, Flash-Speicher oder andere Speichertechnologien, CD-ROM, Digital Versatile Disks (DVD) oder andere optische Plattenspeicher, Magnetkassetten, Magnetbänder, Magnetplattenspeicher oder andere magnetische Speichergeräte oder jedes andere Medium umfassen, das zur Speicherung der gewünschten Informationen verwendet werden kann und auf das das Rechengerät 600 zugreifen kann. Wie hier verwendet, umfassen Rechner-Speichermedien nicht per se Signale.
  • Die Computer-Speichermedien können computerlesbare Anweisungen, Datenstrukturen, Programm-Module und/oder andere Typen von Daten in einem modulierten Datensignal, wie z. B. einer Trägerwelle oder einem anderen Transportmechanismus, verkörpern und umfassen beliebige Informationsübertragungsmedien. Der Begriff „moduliertes Datensignal“ kann sich auf ein Signal beziehen, bei dem eine oder mehrere seiner Charakteristiken so eingestellt oder verändert wurden, dass Informationen in dem Signal kodiert werden. Die Speichermedien des Rechners können beispielsweise verdrahtete Medien wie ein verdrahtetes Netzwerk oder eine direkt verdrahtete Verbindung sowie drahtlose Medien wie Akustik-, HF-, Infrarot- und andere drahtlose Medien umfassen, ohne darauf beschränkt zu sein. Kombinationen der oben genannten Möglichkeiten sollten ebenfalls den Bereich der computerlesbaren Medien umfassen.
  • Die CPU(s) 606 können so konfiguriert sein, dass sie zumindest einige der computerlesbaren Anweisungen ausführen, um eine oder mehrere Komponenten des Rechengeräts 600 zu steuern, um eines oder mehrere der hierin beschriebenen Verfahren und/oder Verarbeitungen durchzuführen. Die CPU(s) 606 können jeweils einen oder mehrere Kerne umfassen (z.B. einen, zwei, vier, acht, achtundzwanzig, zweiundsiebzig usw.), die in der Lage sind, eine Vielzahl von Software-Threads gleichzeitig zu verarbeiten. Die CPU(s) 606 kann/können jeden beliebigen Typ von Prozessor umfassen und je nach dem Typ des implementierten Rechengeräts 600 unterschiedliche Typen von Prozessoren umfassen (z.B. Prozessoren mit weniger Kernen für mobile Geräte und Prozessoren mit mehr Kernen für Server). Je nach Typ des Rechengeräts 600 kann der Prozessor beispielsweise ein Advanced RISC Machines (ARM)-Prozessor sein, der Reduced Instruction Set Computing (RISC) verwendet, oder ein x86-Prozessor, der Complex Instruction Set Computing (CISC) verwendet. Das Rechengerät 600 kann eine oder mehrere CPUs 606 umfassen, zusätzlich zu einem oder mehreren Mikroprozessoren oder zusätzlichen Co-Prozessoren, wie z. B. mathematischen Co-Prozessoren.
  • Zusätzlich zu oder alternativ zu der/den CPU(s) 606 kann/können die GPU(s) 608 so konfiguriert sein, dass sie zumindest einige der computerlesbaren Anweisungen zur Steuerung einer oder mehrerer Komponenten des Rechengeräts 600 ausführen, um eines oder mehrere der hierin beschriebenen Verfahren und/oder Prozesse durchzuführen. Eine oder mehrere der GPU(s) 608 können eine integrierte GPU sein (z.B. mit einer oder mehreren der CPU(s) 606) und/oder eine oder mehrere der GPU(s) 608 können eine diskrete GPU sein. In Ausführungsbeispielen kann eine oder mehrere der GPU(s) 608 ein Koprozessor einer oder mehrerer der CPU(s) 606 sein. Der/die GPU(s) 608 kann/können vom Rechengerät 600 verwendet werden, um Grafiken zu rendern (z.B. 3D-Grafiken) oder allgemeine Berechnungen durchzuführen. Die GPU(s) 608 kann/können beispielsweise für das allgemeine Rechnen auf GPUs (GPGPU) verwendet werden. Die GPU(s) 608 kann Hunderte oder Tausende von Kernen umfassen, die in der Lage sind, Hunderte oder Tausende von Software-Threads gleichzeitig zu verarbeiten. Der/die Grafikprozessor(en) 608 kann/können als Reaktion auf Rendering-Befehle (z.B. Rendering-Befehle von der/den CPU(s) 606, die über eine Host-Schnittstelle empfangen werden) Pixeldaten für die Ausgabe von Bildern generieren. Die GPU(s) 608 kann/können einen Grafikspeicher, z. B. einen Anzeigespeicher, zum Speichern von Pixeldaten oder anderen geeigneten Daten, wie z. B. GPGPU-Daten, umfassen. Der Anzeigespeicher kann einen Teil des Speichers 604 umfassen. Die GPU(s) 608 kann/können zwei oder mehr GPUs umfassen, die parallel operieren (z.B. über eine Verbindung). Der Link kann die GPUs direkt zu leiten (z.B. unter Verwendung von NVLINK) oder über einen Switch (z.B. unter Verwendung von NVSwitch) verbinden. In Kombination kann jede GPU 608 Pixeldaten oder GPGPU-Daten für verschiedene Teile einer Ausgabe oder für verschiedene Ausgaben generieren (z.B. eine erste GPU für ein erstes Bild und eine zweite GPU für ein zweites Bild). Jede GPU kann ihren eigenen Speicher umfassen oder den Speicher gemeinsam mit anderen GPUs nutzen.
  • Zusätzlich zu oder alternativ zu der (den) CPU(s) 606 und/oder der (den) GPU(s) 608 kann (können) die Logikeinheit(en) 620 so konfiguriert sein, dass sie zumindest einige der computerlesbaren Anweisungen zur Steuerung einer oder mehrerer Komponenten des Rechengeräts 600 ausführen, um eines oder mehrere der hier beschriebenen Verfahren und/oder Prozesse durchzuführen. In Ausführungsbeispielen können die CPU(s) 606, die GPU(s) 608 und/oder die Logikeinheit(en) 620 diskret oder gemeinsam jede Kombination der Verfahren, Prozesse und/oder Teile davon durchführen. Eine oder mehrere der Logikeinheiten 620 können Teil einer oder mehrerer der CPU(s) 606 und/oder der GPU(s) 608 sein und/oder eine oder mehrere der Logikeinheiten 620 können diskrete Komponenten sein oder anderweitig außerhalb der CPU(s) 606 und/oder der GPU(s) 608 liegen. In Ausführungsbeispielen kann eine oder mehrere der Logikeinheiten 620 ein Koprozessor einer oder mehrerer der CPU(s) 606 und/oder einer oder mehrerer der GPU(s) 608 sein.
  • Beispiele für die Logikeinheit(en) 620 umfassen einen oder mehrere Verarbeitungskerne und/oder Komponenten davon, wie Tensor Cores (TCs), Tensor Processing Units (TPUs), Pixel Visual Cores (PVCs), Vision Processing Units (VPUs), Graphics Processing Clusters (GPCs), Texture Processing Clusters (TPCs), Streaming-Multiprozessoren (SMs), Tree Traversal Units (TTUs), Artificial Intelligence Accelerators (AIAs), Deep Learning Accelerators (DLAs), Arithmetik-Logik-Einheiten (ALUs), applikationsspezifische integrierte Schaltungen (ASICs), Fließkommaeinheiten (FPUs), Eingabe/Ausgabe (E/A)-Elemente, Peripheral Component Interconnect (PCI)- oder Peripheral Component Interconnect Express (PCIe)-Elemente und/oder dergleichen.
  • Die Kommunikationsschnittstelle 610 kann einen oder mehrere Empfänger, Sender und/oder Transceiver umfassen, die es dem Rechengerät 600 ermöglichen, mit anderen Rechengeräten über ein elektronisches Kommunikationsnetzwerk zu kommunizieren, einschließlich drahtgebundener und/oder drahtloser Kommunikation. Die Kommunikationsschnittstelle 610 kann Komponenten und Funktionen umfassen, um die Kommunikation über eine Reihe verschiedener Netzwerke zu ermöglichen, wie z.B. drahtlose Netzwerke (z.B. Wi-Fi, Z-Wave, Bluetooth, Bluetooth LE, ZigBee, etc.), verdrahtete Netzwerke (z.B. Kommunikation über Ethernet oder InfiniBand), Low-Power-Wide-Area-Netzwerke (z.B. LoRaWAN, SigFox, etc.), und/oder das Internet.
  • Die E/A-Anschlüsse 612 können eine logische Kopplung des Rechengeräts 600 mit anderen Geräten ermöglichen, darunter die E/A-Komponenten 614, die Präsentationskomponente(n) 618 und/oder andere Komponenten, von denen einige in das Rechengerät 600 eingebaut (z.B. integriert) sein können. Beispielhafte E/A-Komponenten 614 umfassen ein Mikrofon, eine Maus, eine Tastatur, einen Joystick, ein Gamepad, einen Gamecontroller, eine Satellitenschüssel, einen Scanner, einen Drucker, ein drahtloses Gerät usw. Die E/A-Komponenten 614 können eine natürliche Benutzerschnittstelle (NUI) bereitstellen, die von einem Benutzer generierte Luftgesten, Sprache oder andere physiologische Eingaben verarbeitet. In einigen Instanzen können die Eingaben zur weiteren Verarbeitung an ein geeignetes Netzwerkelement übertragen werden. Eine NUI kann eine beliebige Kombination aus Spracherkennung, Stifterkennung, Gesichtserkennung, biometrischer Erkennung, Gestenerkennung sowohl auf dem Bildschirm als auch neben dem Bildschirm, Luftgesten, Kopf- und Augenverfolgung und Berührungserkennung (wie unten detaillierter beschrieben) implementieren, die mit einer Anzeige des Rechengeräts 600 assoziiert ist. Das Rechengerät 600 kann Tiefenkameras, wie z. B. stereoskopische Kamerasysteme, Infrarotkamerasysteme, RGB-Kamerasysteme, Touchscreen-Technologie und Kombinationen davon, zur Gestenerkennung und -erfassung umfassen. Zusätzlich kann das Rechengerät 600 Beschleunigungsmesser oder Gyroskope (z.B. als Teil einer Trägheitsmesseinheit (IMU)) umfassen, die das Detektieren von Bewegungen ermöglichen. In einigen Beispielen kann die Ausgabe der Beschleunigungsmesser oder Gyroskope vom Rechengerät 600 verwendet werden, um immersive Augmented Reality oder Virtual Reality zu rendern.
  • Die Stromversorgung 616 kann eine festverdrahtete Stromversorgung, eine Batteriestromversorgung oder eine Kombination davon umfassen. Die Stromversorgung 616 kann dem Rechengerät 600 Strom bereitstellen, damit die Komponenten des Rechengeräts 600 operieren können.
  • Die Präsentationskomponente(n) 618 kann/können eine Anzeige (z.B. einen Monitor, einen Touchscreen, einen Fernsehbildschirm, ein Heads-up-Display (HUD), andere Anzeigetypen oder eine Kombination davon), Lautsprecher und/oder andere Präsentationskomponenten umfassen. Die Präsentationskomponente(n) 618 kann/können Daten von anderen Komponenten (z.B. der/den GPU(s) 608, der/den CPU(s) 606 usw.) empfangen und die Daten ausgeben (z.B. als Bild, Video, Ton usw.).
  • Beispielhafte Netzwerkumgebungen
  • Netzwerkumgebungen, die zur Verwendung bei der Implementierung von Ausführungsbeispielen der Offenbarung geeignet sind, können ein oder mehrere Client-Geräte, Server, Network Attached Storage (NAS), andere Backend-Geräte und/oder andere Typen von Geräten umfassen. Die Client-Geräte, Server und/oder andere Typen von Geräten (z.B. jedes Gerät) können auf einer oder mehreren Instanzen des/der Rechengerät(e) 600 von 6 implementiert werden - z.B. kann jedes Gerät ähnliche Komponenten, Merkmale und/oder Funktionen des/der Rechengerät(e) 600 umfassen.
  • Komponenten einer Netzwerkumgebung können über ein oder mehrere Netzwerke miteinander kommunizieren, die drahtgebunden, drahtlos oder beides sein können. Das Netzwerk kann mehrere Netzwerke oder ein Netzwerk von Netzwerken umfassen. Beispielsweise kann das Netzwerk ein oder mehrere Wide Area Networks (WANs), ein oder mehrere Local Area Networks (LANs), ein oder mehrere öffentliche Netzwerke wie das Internet und/oder ein öffentliches Telefonnetz (PSTN) und/oder ein oder mehrere private Netzwerke umfassen. Umfasst das Netzwerk ein drahtloses Telekommunikationsnetz, können Komponenten wie eine Basisstation, ein Kommunikationsturm oder sogar Zugangspunkte (sowie andere Komponenten) eine drahtlose Verbindung bereitstellen.
  • Kompatible Netzwerkumgebungen können eine oder mehrere Peer-to-Peer-Netzwerkumgebungen umfassen - in diesem Fall darf ein Server nicht in einer Netzwerkumgebung enthalten sein - und eine oder mehrere Client-Server-Netzwerkumgebungen - in diesem Fall können ein oder mehrere Server in einer Netzwerkumgebung enthalten sein. In Peer-to-Peer-Netzwerkumgebungen kann die hier beschriebene Funktionalität in Bezug auf einen oder mehrere Server auf einer beliebigen Anzahl von Client-Geräten implementiert werden.
  • In mindestens einem Ausführungsbeispiel kann eine Netzwerkumgebung eine oder mehrere Cloud-basierte Netzwerkumgebungen, eine verteilte Rechenumgebung, eine Kombination davon usw. umfassen. Eine Cloud-basierte Netzwerkumgebung kann eine Framework-Schicht, einen Planer für Aufgaben, einen Verwalter für Ressourcen und ein verteiltes Dateisystem umfassen, die auf einem oder mehreren Servern implementiert sind, die einen oder mehrere Kern-Netzwerkserver und/oder Edge-Server umfassen können. Eine Framework-Schicht kann ein Framework zur Unterstützung von Software einer Software-Schicht und/oder einer oder mehrerer Applikation(en) einer Applikationsschicht umfassen. Die Software bzw. Applikation(en) können webbasierte Dienstsoftware oder Applikationen umfassen. In Ausführungsbeispielen können eines oder mehrere der Geräte die webbasierte Dienstsoftware oder Applikationen verwenden (z.B. durch Zugriff auf die Dienstsoftware und/oder Applikationen über eine oder mehrere Applikationsprogrammierschnittstellen (APIs)). Bei der Applikationsschicht kann es sich um einen Typ von freiem und quelloffenem Software-Webapplikations-Framework handeln, das z.B. ein verteiltes Dateisystem zum Verarbeiten großer Datenmengen (z.B. „Big Data“) verwendet, ist aber nicht darauf beschränkt.
  • Eine Cloud-basierte Netzwerkumgebung kann Cloud-Computing und/oder Cloud-Speicher bereitstellen, die eine beliebige Kombination der hier beschriebenen Rechen- und/oder Datenspeicherfunktionen (oder einen oder mehrere Teile davon) ausführen. Jede dieser verschiedenen Funktionen kann von zentralen oder Kern-Servern (z.B. von einem oder mehreren Datenzentren, die über einen Staat, eine Region, ein Land, den Globus usw. verteilt sein können) auf mehrere Orte verteilt werden. Befindet sich eine Verbindung zu einem Benutzer (z.B. einem Client-Gerät) relativ nahe an einem oder mehreren Edge-Servern, kann ein Kern-Server mindestens einen Teil der Funktionalität dem oder den Edge-Servern zuweisen. Eine auf einer Cloud basierende Netzwerkumgebung kann privat (z.B. auf eine einzelne Organisation beschränkt), öffentlich (z.B. für viele Organisationen verfügbar) und/oder eine Kombination davon (z.B. eine hybride Cloud-Umgebung) sein.
  • Das (die) Client-Gerät(e) kann (können) zumindest einige der Komponenten, Merkmale und Funktionen des (der) Rechengerät(e) 600 umfassen, die hier in Bezug auf 6 beschrieben sind. Als Ausführungsbeispiel und ohne Einschränkung kann ein Rechengerät ein Personal Computer (PC), ein Laptop, ein mobiles Gerät, ein Smartphone, ein Tablet-Computer, eine Smartwatch, ein tragbarer Computer, ein Personal Digital Assistant (PDA), ein MP3-Player, ein Virtual-Reality-Headset, ein Global Positioning System (GPS) oder ein Gerät, ein Videoplayer, eine Videokamera, ein Überwachungsgerät oder -system, ein Fahrzeug, ein Boot, ein fliegendes Schiff, eine virtuelle Maschine, eine Drohne, ein Roboter, ein Handheld-Kommunikationsgerät, ein Krankenhausgerät, ein Spielgerät oder -system, ein Unterhaltungssystem, ein Fahrzeugrechnersystem, eine eingebettete Systemsteuerung, eine Fernbedienung, ein Gerät, ein elektronisches Gerät für Verbraucher, eine Workstation, ein Edge-Gerät, eine beliebige Kombination dieser beschriebenen Geräte oder jedes andere geeignete Gerät.
  • Die Offenbarung kann im allgemeinen Kontext von Computercode oder maschinell verwendbaren Anweisungen, einschließlich computerausführbarer Anweisungen wie Programmmodule, beschrieben werden, die von einem Rechner oder einer anderen Maschine, wie einem persönlichen Datenassistenten oder einem anderen tragbaren Gerät, ausgeführt werden. Im Allgemeinen umfassen Programmmodule, einschließlich Routinen, Programme, Objekte, Komponenten, Datenstrukturen usw., einen Code, der bestimmte Aufgaben durchführt oder bestimmte abstrakte Datentypen implementiert. Die Offenbarung kann in einer Vielzahl von Systemkonfigurationen praktiziert werden, einschließlich Handheld-Geräten, Unterhaltungselektronik, allgemeinen Rechnern, spezielleren Rechengeräten usw. Die Offenbarung kann auch in verteilten Rechenumgebungen angewandt werden, in denen Aufgaben von ferngesteuerten Geräten durchgeführt werden, die über ein Kommunikationsnetzwerk verbunden sind.
  • Wie hier verwendet, sollte eine Erwähnung von „und/oder“ in Bezug auf zwei oder mehr Elemente so interpretiert werden, dass nur ein Element oder eine Kombination von Elementen gemeint ist. So kann beispielsweise „Element A, Element B und/oder Element C“ nur Element A, nur Element B, nur Element C, Element A und Element B, Element A und Element C, Element B und Element C oder die Elemente A, B und C umfassen. Darüber hinaus kann „mindestens eines der Elemente A oder B“ mindestens eines der Elemente A, mindestens eines der Elemente B oder mindestens eines der Elemente A und mindestens eines der Elemente B umfassen. Ferner kann „mindestens eines der Elemente A und B“ mindestens eines der Elemente A, mindestens eines der Elemente B oder mindestens eines der Elemente A und mindestens eines der Elemente B umfassen.
  • Der Gegenstand der vorliegenden Offenbarung wird hier mit einer Genauigkeit beschrieben, die den gesetzlichen Anforderungen entspricht. Die Beschreibung selbst soll jedoch den Umfang dieser Offenbarung nicht einschränken. Vielmehr haben die Erfinder in Betracht gezogen, dass der beanspruchte Gegenstand auch auf andere Weise verkörpert werden könnte, um verschiedene Schritte oder Kombinationen von Schritten ähnlich den in dieser Druckschrift beschriebenen in Verbindung mit anderen gegenwärtigen oder zukünftigen Technologien zu umfassen. Auch wenn die Begriffe „Schritt“ und/oder „Block“ hier verwendet werden, um verschiedene Elemente der angewandten Verfahren zu bezeichnen, sollten die Begriffe nicht so ausgelegt werden, dass sie eine bestimmte Reihenfolge unter oder zwischen den verschiedenen hier offenbart dargestellten Schritten implizieren, es sei denn, die Reihenfolge der einzelnen Schritte wird ausdrücklich beschrieben.

Claims (20)

  1. Verfahren umfassend: Empfangen, durch ein erstes Datenzentrum, von Daten, die eine erste Anforderung für einen Host einer Applikationssitzung von einem Benutzergerät repräsentieren, wobei die erste Anforderung ein mit dem Benutzergerät assoziiertes Streaming-Profil anzeigt; Bestimmen, zumindest teilweise basierend auf der ersten Anforderung, von Applikationsleistungsanforderungen für eine mit der Applikationssitzung assoziierte Applikation; Bestimmen, zumindest teilweise basierend auf einer Analyse des Streaming-Profils und der Applikationsleistungsanforderungen, die Applikationssitzung nicht unter Verwenden des ersten Datenzentrums zu hosten; zumindest teilweise basierend auf der Information, Senden von Daten, die eine zweite Anforderung repräsentieren, die Applikationssitzung zu hosten, an ein zweites Datenzentrum; Empfangen, unter Verwenden des Planers, von Daten, die eine Annahme repräsentieren, die Applikationssitzung zu hosten von dem zweiten Datenzentrum; und Veranlassen, basierend auf der Annahme von dem zweiten Datenzentrum, dass Netzwerkverkehr, der der Applikationssitzung entspricht, zu dem zweiten Datenzentrum geroutet wird.
  2. Verfahren nach Anspruch 1, wobei das Streaming-Profil zumindest teilweise basierend auf einem Netzwerktest generiert wird, der eine Übertragung von Echtzeit-Streaming-Netzwerkverkehr umfasst, der spezifisch für die Applikation der Applikationssitzung ist.
  3. Verfahren nach Anspruch 2, wobei das Streaming-Profil mindestens eine der folgenden Eigenschaften umfasst: eine von dem Benutzergerät unterstützte Audioqualität, eine von dem Benutzergerät unterstützte Videoqualität, oder Bandbreitenfähigkeiten eines lokalen Netzwerks des Benutzergeräts.
  4. Verfahren nach Anspruch 2, wobei der Netzwerktest einen oder mehrere der folgenden Tests umfasst: Einen Jittertest, einen Paketverlusttest, einen Bandbreitentest oder einen Latenztest.
  5. Verfahren nach Anspruch 1, wobei die Applikation eine Spielapplikation ist, die Applikationssitzung eine Instanz der Spielapplikation ist und das erste Datenzentrum und das zweite Datenzentrum mit einer Cloud-Gaming-Umgebung assoziiert sind.
  6. Verfahren nach Anspruch 1, wobei das erste Datenzentrum und das zweite Datenzentrum zumindest teilweise basierend darauf bestimmt werden, dass von einem Netzwerktest zurückgegebenen assoziierte Latenzen unter einer Schwellenwertlatenz liegen.
  7. Verfahren nach Anspruch 1, weiter umfassend: Senden, unter Verwenden des Planers und an ein drittes Datenzentrum und vor dem Senden der zweiten Anforderung, von Daten, die eine dritte Anforderung repräsentieren, die Applikationssitzung zu hosten; und Empfangen, in dem ersten Datenzentrum und von dem dritten Datenzentrum, von Daten, die eine Indikation repräsentieren, dass das dritte Datenzentrum die dritte Anforderung abgelehnt hat, wobei das Senden der zweiten Anforderung zumindest teilweise darauf basiert, dass das dritte Datenzentrum die dritte Anforderung abgelehnt hat.
  8. Verfahren nach Anspruch 1, wobei das Bestimmen, die Applikationssitzung nicht unter Verwenden des ersten Datenzentrums zu hosten, zumindest teilweise auf mindestens einem der folgenden Punkte basiert: Einer Vorhersage einer Überlastung des ersten Datenzentrums während der Applikationssitzung; einer unzureichende Hardware im ersten Datenzentrum zur Unterstützung der Applikationssitzung; oder einem Mangel an Rechenkapazität im ersten Datenzentrum.
  9. Verfahren nach Anspruch 1, weiter umfassend: Testen von Dienstgüte-Metriken für einen aktuellen Internet Service Provider (ISP) des zweiten Datenzentrums und einen alternativen ISP des zweiten Datenzentrums; Bestimmen, zumindest teilweise basierend auf den Dienstgüte-Metriken, dass der alternative ISP bessere Netzwerkcharakteristiken aufweist als der aktuelle ISP; und Aktualisieren von Routing-Richtlinien im zweiten Datenzentrum, um zu veranlassen, dass mindestens einer von Eingangsverkehr oder Ausgangsverkehr vom aktuellen ISP weg und durch den alternativen ISP geroutet wird.
  10. Verfahren umfassend: Bestimmen, zumindest teilweise basierend auf einem Latenztest, einer Vielzahl von Datenzentren mit einer assoziierten Latenz, die kleiner als eine Schwellenwertlatenz ist; Übertragen einer Anforderung an ein Datenzentrum der Vielzahl von Datenzentren, einen oder mehrere Netzwerkleistungstests auszuführen, die an eine Applikation angepasst sind; Austauschen von Netzwerkverkehr und assoziierten Leistungsmetriken, die dem einen oder den mehreren Netzwerkleistungstests entsprechen, mit dem Datenzentrum; Generieren eines Applikationsprofils, das der Applikation entspricht, basierend zumindest teilweise auf den assoziierten Leistungsmetriken; und vor dem Ausführen einer Applikationssitzung der Applikation, Übertragen von Daten, die eine Anfrage für einen Host der Applikationssitzung repräsentieren, an eines oder mehrere der Vielzahl von Datenzentren, wobei die Anfrage Informationen enthält, die dem Applikationsprofil entsprechen.
  11. Verfahren nach Anspruch 10, wobei das Verfahren von einem Endbenutzergerät ausgeführt wird.
  12. Verfahren nach Anspruch 10, wobei ein oder mehrere Netzwerkleistungstests mindestens einen von einem Jittertest, einem Paketverlusttest, einem Bandbreitentest oder einem Latenztest umfassen.
  13. Verfahren nach Anspruch 10, wobei die Anforderung weiter einen Applikationstyp der Applikation angibt und das Verfahren weiter umfasst: Empfangen, von dem einen oder den mehreren der Vielzahl von Datenzentren und mindestens teilweise basierend auf der Anforderung, von Adressinformationen, die einem zweiten Datenzentrum der Vielzahl von Datenzentren entsprechen, das die Anforderung akzeptiert hat, die Applikationssitzung zu hosten, wobei die Anforderung zumindest teilweise basierend darauf akzeptiert wird, dass das zweite Datenzentrum über Rechenressourcen verfügt, die in der Lage sind, den Applikationstyp gemäß dem Applikationsprofil zu hosten.
  14. Verfahren nach Anspruch 10, weiter umfassend: Empfangen von Adressinformationen, die einem zweiten Datenzentrum der Vielzahl von Datenzentren entsprechen, das die Anforderung akzeptiert hat; Kommunizieren während der Ausführung der Applikationssitzung über einen ersten Internet Service Provider (ISP) des zweiten Datenzentrums; Empfangen von aktualisierten Routing-Informationen vom zweiten Datenzentrum; und Kommunizieren, mindestens teilweise basierend auf den aktualisierten Routing-Informationen, über einen zweiten ISP des zweiten Datenzentrums.
  15. Verfahren nach Anspruch 14, wobei die aktualisierten Routing-Informationen zumindest teilweise auf Dienstgüte-Metriken basieren, die mit der Applikationssitzung für den ersten ISP und den zweiten ISP assoziiert sind.
  16. Verfahren nach Anspruch 10, wobei die Anforderung weiterhin Informationen über die Vielzahl von Datenzentren umfasst, und die Informationen von einem Planer des einen oder mehrerer der Vielzahl von Datenzentren verwendet werden, um die Anforderung an andere der Vielzahl von Datenzentren weiterzuleiten.
  17. System umfassend: einen oder mehrere Prozessoren; ein oder mehrere Speichergeräte, die Anweisungen darauf speichern, die, wenn sie unter Verwenden des einen oder der mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren veranlassen, Operationen auszuführen, die die folgenden Schritte umfassen: Empfangen, unter Verwenden eines Planers eines ersten Datenzentrums und von einem Benutzergerät, erster Daten, die eine Anforderung für einen Host einer Applikationssitzung repräsentieren, wobei die erste Anforderung Informationen umfasst, die einem oder mehreren zweiten Datenzentren entsprechen; Bestimmen, zumindest teilweise basierend auf der ersten Anforderung, von Applikationsleistungsanforderungen für eine mit der Applikationssitzung assoziierte Applikation; Bestimmen, dass aktuelle Rechenressourcen des ersten Datenzentrums die Applikationsleistungsanforderungen nicht erfüllen können; zumindest teilweise basierend auf den Informationen, Senden, unter Verwenden des Planers und an ein zweites Datenzentrum des einen oder der mehreren zweiten Datenzentren, von zweiten Daten, die eine zweite Anforderung repräsentieren, die Applikationssitzung zu hosten, wobei die zweite Anforderung die Applikationsleistungsanforderungen umfasst; Empfangen, unter Verwenden des Planers und von dem zweiten Datenzentrum, von dritten Daten, die eine Annahme repräsentieren, die Applikationssitzung zu hosten; und Senden, unter Verwenden des Planers und an das Benutzergerät, von vierten Daten, die die Annahme indizieren, so dass das Benutzergerät Netzwerkverkehr, der der Applikationssitzung entspricht, an das zweite Datenzentrum leitet.
  18. System nach Anspruch 17, wobei die erste Anforderung und die zweite Anforderung weiter Applikationsprofilinformationen des Benutzergeräts enthalten, wobei die Applikationsprofilinformationen zumindest teilweise basierend auf einem Netzwerktest einschließlich der Übertragung von applikationsspezifischem Netzwerkverkehr für die Applikationssitzung generiert werden.
  19. System nach Anspruch 17, wobei die Applikation eine Spielapplikation ist, die Applikationssitzung eine Instanz der Spielapplikation ist, und das erste Datenzentrum und das eine oder die mehreren zweiten Datenzentren mit einer Cloud-Gaming-Umgebung assoziiert sind.
  20. System nach Anspruch 17, wobei die Operationen weiter umfassen: Senden, unter Verwenden des Planers und an ein drittes Datenzentrum des einen oder der mehreren zweiten Datenzentren und vor dem Senden der zweiten Anforderung, von fünften Daten, die eine dritte Anforderung repräsentieren, die Applikationssitzung zu hosten; und Empfangen, an dem ersten Datenzentrum und von dem dritten Datenzentrum, von sechsten Daten, die eine Indikation repräsentieren, dass das dritte Datenzentrum die dritte Anforderung abgelehnt hat, wobei das Senden der zweiten Anforderung mindestens teilweise darauf basiert, dass das dritte Datenzentrum die dritte Anforderung abgelehnt hat.
DE112021003383.2T 2020-07-21 2021-07-07 Inhaltsadaptives routing und weiterleiten an datenzentren in cloud-computing-umgebungen Pending DE112021003383T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US16/935,091 US11857872B2 (en) 2020-07-21 2020-07-21 Content adaptive data center routing and forwarding in cloud computing environments
US16/935,091 2020-07-21
PCT/US2021/040655 WO2022020092A1 (en) 2020-07-21 2021-07-07 Content adaptive data center routing and forwarding in cloud computing environments

Publications (1)

Publication Number Publication Date
DE112021003383T5 true DE112021003383T5 (de) 2023-04-27

Family

ID=77412317

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112021003383.2T Pending DE112021003383T5 (de) 2020-07-21 2021-07-07 Inhaltsadaptives routing und weiterleiten an datenzentren in cloud-computing-umgebungen

Country Status (4)

Country Link
US (1) US11857872B2 (de)
CN (1) CN116210212A (de)
DE (1) DE112021003383T5 (de)
WO (1) WO2022020092A1 (de)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11456941B2 (en) * 2020-07-24 2022-09-27 Nvidia Corporation Extensible network traffic engineering platform for increasing network resiliency in cloud applications
CN114265648B (zh) * 2020-09-16 2023-12-26 阿里巴巴集团控股有限公司 编码调度方法、服务器及客户端和获取远程桌面的系统
US11588842B2 (en) * 2020-09-28 2023-02-21 Charter Communications Operating, Llc Network anomaly detection and mitigation simulation tool
US11652725B2 (en) * 2021-04-19 2023-05-16 Rakuten Mobile, Inc. Performance testing of a test application in a network-as-a-service environment
US20220337493A1 (en) * 2021-04-19 2022-10-20 Rakuten Mobile, Inc Report generation from testing a test application in a network-as-a-service
US11609754B2 (en) * 2021-06-17 2023-03-21 Sap Se Tool for latency optimized system placement
US12082051B2 (en) * 2021-09-13 2024-09-03 Guavus, Inc. Determining QoE requirements for 5G networks or hybrid 5G networks
US11711279B2 (en) * 2021-10-26 2023-07-25 Juniper Networks, Inc. Application records using session information
US11983085B1 (en) 2022-03-31 2024-05-14 Amazon Technologies, Inc. Dynamic usage-based segmentation
US11818227B1 (en) * 2022-03-31 2023-11-14 Amazon Technologies, Inc. Application usage analysis-based experiment generation
CN115022334A (zh) * 2022-05-13 2022-09-06 深信服科技股份有限公司 流量分配方法、装置、电子设备及存储介质
CN114666640B (zh) * 2022-05-23 2023-03-07 创意信息技术股份有限公司 一种边缘网关接入服务器
WO2024008320A1 (en) * 2022-07-06 2024-01-11 Lenovo (Singapore) Pte. Ltd Discovery of devices in a virtual experience service in a wireless communication network
WO2024008319A1 (en) * 2022-07-06 2024-01-11 Lenovo (Singapore) Pte. Ltd Quality of service coordination for a virtual experience service in a wireless communications network
US20240015099A1 (en) * 2022-07-11 2024-01-11 Check Point Software Technologies Ltd. Network traffic routing in an sd-wan
US20240113956A1 (en) * 2022-09-30 2024-04-04 HCL America Inc. Method and system for selecting data centers based on network metering

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002104046A1 (en) * 2001-06-15 2002-12-27 Nokia Corporation Mapping of packets to pdp contexts in multisession connection
US9001688B2 (en) * 2012-08-10 2015-04-07 Ixia Dynamic balancing of a traffic mix for data center device testing
US10142406B2 (en) * 2013-03-11 2018-11-27 Amazon Technologies, Inc. Automated data center selection
US10037656B2 (en) * 2014-12-16 2018-07-31 Igt Canada Solutions Ulc Techniques of performing cloud-based hosting of shared gaming activities
US10709988B2 (en) * 2015-03-06 2020-07-14 Sony Interactive Entertainment America Llc Predictive instant play for an application over the cloud
US10110511B2 (en) * 2015-03-16 2018-10-23 Liveperson, Inc. Resource prioritization and communication-channel establishment
US10791162B2 (en) * 2015-12-31 2020-09-29 Hughes Network Systems, Llc Maximizing quality of service for QoS adaptive video streaming via dynamic application-layer throughput rate shaping
US10742767B2 (en) * 2016-02-02 2020-08-11 Sony Interactive Entertainment LLC Systems and methods for downloading and updating save data to a data center
EP4336800A3 (de) * 2017-10-10 2024-05-29 Google LLC Verteilte musterbasierte spielprofilierung mit spielmetadaten und metriken und api-spielplattform zur unterstützung von inhalten dritter
EP3769576A1 (de) * 2018-03-23 2021-01-27 Nokia Technologies OY Zuweisung von funkzugriffsnetzressourcen auf der grundlage vorhergesagter videocodierungsraten
US11077364B2 (en) * 2018-04-02 2021-08-03 Google Llc Resolution-based scaling of real-time interactive graphics
US10749795B2 (en) * 2018-07-06 2020-08-18 Citrix Systems, Inc. Systems and methods for selecting communication paths for applications sensitive to bursty packet drops

Also Published As

Publication number Publication date
US11857872B2 (en) 2024-01-02
US20220023755A1 (en) 2022-01-27
WO2022020092A1 (en) 2022-01-27
CN116210212A (zh) 2023-06-02

Similar Documents

Publication Publication Date Title
DE112021003383T5 (de) Inhaltsadaptives routing und weiterleiten an datenzentren in cloud-computing-umgebungen
DE112014000358B4 (de) Regionales Firewall-Clustering in einer vernetzten Datenverarbeitungsumgebung
WO2022222755A1 (zh) 业务处理方法、装置及存储介质
US10065122B1 (en) Spectator feedback and adaptation
Ahmadi et al. A game attention model for efficient bit rate allocation in cloud gaming
DE112017000017T5 (de) Kameraeinstellungsanpassung basierend auf vorhergesagten umgebungsfaktoren und nachverfolgungssysteme, die diese einsetzen
US8930565B1 (en) Method and system for providing data streams in a virtual environment
JP2014505913A (ja) 汎用プロセッサとグラフィックスプロセッサとの間の負荷平衡化
JP7375203B2 (ja) アカウントアクセス方法及びその装置、記憶媒体、並びに電子機器
CN105391974B (zh) 一种用于数据的对等供应的方法和系统
Shurman et al. Collaborative execution of distributed mobile and IoT applications running at the edge
Mishra et al. Clouds+ games: A multifaceted approach
CN113157418A (zh) 服务器资源分配方法和装置、存储介质及电子设备
CN117695619A (zh) 多会话远程游戏渲染
CN107920108A (zh) 一种媒体资源的推送方法、客户端及服务器
CN111211984B (zh) 优化cdn网络的方法、装置及电子设备
DE112005003037T5 (de) Bestimmen höchster Arbeitslasten für Knoten in einem Überlagerungsnetzwerk
Ahmadi et al. Efficient bitrate reduction using a game attention model in cloud gaming
US11411826B2 (en) Monitoring a peer-to-peer network
DE102022107672A1 (de) Cloud-ausführung von audio/video compositing-anwendungen
DE102022200313A1 (de) Client-gesteuertes cloud-netzwerkzugriffs-system und verfahren
Sun et al. A hybrid remote rendering method for mobile applications
US10441891B1 (en) Associated content item instances
Vogt et al. QoEyes: towards virtual reality streaming QoE estimation entirely in the data plane
Aljaafreh et al. An efficient object discovery and selection protocol in 3D streaming-based systems over thin mobile devices

Legal Events

Date Code Title Description
R012 Request for examination validly filed