Wird ein Spieler einem Server in einer weit entfernten Region zugewiesen, obwohl es eine nähere gibt, hat genau dieser Spieler dauerhaft hohen Ping, auch wenn seine Leitung in Ordnung ist.
Warum Fehlerhafte GeoIP-Daten, VPN, Zuweisung der ganzen Gruppe nach dem durchschnittlichen Ping der Mitglieder, Regel zur Ausweitung auf ferne Regionen bei zu wenigen Spielern, Zuweisung nach dem Standort des DNS-Resolvers → Folge Verbindung zu einem Server in einer Region in Übersee, obwohl eine nahe Region existiert → Auf dem Bildschirm In einem Spiel mit Servern in mehreren Regionen hat nur man selbst (oder nur die eigene Gruppe) dauerhaft hohen Ping, dazu Input-Lag, Rubberbanding und verschluckte Skills
Server: Regionen anhand des vom Client gemessenen Pings pro Region zuweisen, ohne sich auf GeoIP zu verlassen, Regel zur Ausweitung auf ferne Regionen mit einer Ping-Obergrenze versehen, bei Gruppen neben dem Durchschnitt auch den höchsten Ping eines Gruppenmitglieds berücksichtigen, zugewiesene Region und den Ping zu diesem Zeitpunkt loggen. Client: Ping pro Region per UDP messen und mit der Matchmaking-Anfrage mitschicken, verbundene Region und Ping auf dem Bildschirm anzeigen, manuelle Regionswahl anbieten.
Aufgaben Infrastrukturteam
Bei Regionswahl per DNS prüfen, ob der autoritative DNS-Server EDNS Client Subnet unterstützt (sendet der Resolver des Spielers es nicht mit, erfolgt die Zuweisung nach dem Standort des Resolvers), GeoIP-Datenbank regelmäßig aktualisieren, Verbindungslogs der regionalen Server mit GeoIP-Land und ASN anreichern, um Länder und Provider zu finden, die in ferne Regionen geleitet werden.
Aufgaben Extern
Spieler bitten, VPN oder Ping-Booster abzuschalten und sich neu zu verbinden, Spielern mit Firmen- oder Auslands-DNS empfehlen, auf den DNS ihres Providers umzustellen, beim GeoIP-Anbieter die Korrektur falscher Standorte beantragen.
Größenordnungen
Landet ein Spieler aus Seoul in der Region US-Westküste und nicht in Tokio, steigt der Ping von etwa 30 ms auf etwa 130 ms. GeoIP liegt auf Länderebene zu etwa 99,8 % richtig. Auf Stadtebene liegen selbst in den USA nur etwa 66 % innerhalb von 50 km, und bei VPN-Nutzung liefert GeoIP den Standort des VPN-Servers.
Im Graphen
Nur einzelne Ausreißer · RTT (Ping) pro Spieler, Verteilung der zugewiesenen Regionen
Wo nachsehen
Client-IPs aus den Verbindungsaufzeichnungen der regionalen Server (Zugriffslogs des Load-Balancers, VPC Flow Logs) mit GeoIP-Land und ASN anreichern und zählen, welche Länder und Provider sich mit welcher Region verbinden. Bei einem einzelnen Spieler die tatsächlich verbundene Region mit dem Ping zur nahen Region vergleichen (vom Spieler gemessen oder per mtr vom Server dieser Region zur Spieler-IP)
Spricht dafür
Spieler oder Länder mit hoher RTT sind mit einer fernen Region verbunden, obwohl eine nahe existiert, und der Ping zur nahen Region ist niedrig
Spricht dagegen
Korrekt der nahen Region zugewiesen, Ping trotzdem hoch: eher „Umweg-Routing“ oder Leitung bzw. WLAN des Spielers
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Bei der Regionswahl per DNS (geo- oder latenzbasiertes DNS) wird der Standort anhand der Adresse des DNS-Resolvers geschätzt, den der Spieler nutzt. Die Adresse des Spielers selbst sieht das DNS dabei nicht. Unterstützt der Resolver EDNS Client Subnet nicht (damit gibt er einen Teil der Spieleradresse weiter), werden Spieler mit Firmen-DNS oder weit entfernten DNS-Servern nach dem Standort des Resolvers zugewiesen. Auch Matchmaking-Systeme bewerten Gruppen teils nach dem durchschnittlichen Ping der Mitglieder oder lockern nach langer Wartezeit das Ping-Kriterium und weisen eine ferne Region zu. Bei AWS GameLift Servers ist der Durchschnitt ebenfalls das Standardkriterium für den Gruppen-Ping, und als Beispiel dient eine Konfiguration, die die Ping-Obergrenze schrittweise von 50 ms auf 100 ms und 200 ms anhebt. Bei Spielern mit VPN können sich die zusätzliche Latenz über den Relay-Server („Umweg über VPN oder Ping-Booster“) und die Zuweisung einer fernen Region überlagern. Unterscheiden lässt sich das daran, ob sich die zugewiesene Region ändert, wenn sie sich ohne VPN neu verbinden. Gibt es überhaupt keine nahe Region und verbindet man sich deshalb mit einer fernen, behandelt das „Signallaufzeit (physische Entfernung)“.
Quellen
RFC 7871: Client Subnet in DNS QueriesIETF DNS, das je nach Standort unterschiedlich antwortet, schätzt den Standort anhand der Adresse des anfragenden Resolvers. Nutzt der Anwender einen weit entfernten zentralen Resolver, fallen die Antworten unpassend aus. EDNS Client Subnet (optional) gibt einen Teil der Nutzeradresse weiter
How Amazon Route 53 uses EDNS0 to estimate the location of a userAWS Unterstützt der Resolver edns-client-subnet nicht, wird der Nutzerstandort anhand der Resolver-Adresse geschätzt und nach dem Standort des Resolvers geantwortet (gilt für geo- und latenzbasiertes Routing)
Geolocation accuracyMaxMind Länderebene etwa 99,8 %, US-Stadtebene (innerhalb von 50 km) etwa 66 %, bei VPN-Nutzung wird der Standort des VPN-Servers geliefert, Mobilfunk-IPs werden über große Gebiete genutzt und erlauben keinen genauen Standort, die Datenbank muss laufend aktualisiert werden, Korrekturanträge sind möglich
FlexMatch rule typesAWS Die Latenzregel (maxLatency) betrachtet die Spielerlatenz pro Standort, für Gruppen wird standardmäßig der Durchschnitt der Mitglieder verwendet (partyAggregation avg), die Queue kann auch in Regionen platzieren, die die Latenzregel nicht erfüllen
Create a player latency policyAWS Platzierung am Standort mit der niedrigsten durchschnittlichen Latenz aller Spieler, wobei auch Spieler mit extremer Latenz platziert werden, Beispiel für eine Richtlinie, die die Ping-Obergrenze von 50 ms auf 100 ms und 200 ms ausweitet
Amazon GameLift Servers UDP ping beaconsAWS Der Spielclient misst die Latenz zu UDP-Endpunkten an jedem Hosting-Standort und nutzt sie für Platzierung und Matchmaking, näher am echten Spiel-Traffic als ICMP-Ping