Pakete zum Gameserver werden über Amerika umgeleitet?

Smagjus

Rear Admiral
Dabei seit
Feb. 2011
Beiträge
6.108
Hallo allerseits, ich habe ein paar Fragen und ich hoffe mir kann ein Experte weiterhelfen.

Folgendes Problem:
Bei einem Online Egoshooter haben derzeit mehrere 1000 Spieler Probleme mit dem Ping. Das merkwürdige an der ganzen Sache ist, dass es nur einen geringeren Prozentsatz aller Spieler betrifft und die Probleme nur auftreten, wenn viele Spieler online sind (d.h. in der Woche ab Nachmittag und am Wochenende praktisch 24h durch).

Ich habe also ein wenig recherchiert und die IP des Servers in Erfahrung gebracht. Mit traceroute erhalte ich folgendes Ergebnis:
PHP:
C:\Windows\system32>tracert -d 109.203.116.222

Routenverfolgung zu 109.203.116.222 über maximal 30 Abschnitte

  1    <1 ms    <1 ms    <1 ms  192.168.178.1
  2    17 ms    17 ms    17 ms  217.0.119.205
  3    18 ms    19 ms    18 ms  217.0.89.230
  4    20 ms    48 ms    20 ms  62.154.14.138
  5    20 ms    20 ms    19 ms  80.156.161.46
  6    20 ms    20 ms    20 ms  129.250.4.73
  7    31 ms    35 ms    32 ms  129.250.3.137
  8    34 ms    34 ms    35 ms  129.250.2.78
  9   124 ms   121 ms   121 ms  83.231.148.19
 10   123 ms   122 ms   127 ms  92.48.95.13
 11   121 ms   128 ms   124 ms  213.229.117.86
 12   127 ms   130 ms   135 ms  109.203.116.222

Ablaufverfolgung beendet.
Diese Ausgabe in etwa dieser Form erhalten alle Leute, die die Ping-Probleme haben. Das merkwürdige ist der 6. Schritt. Über utrace lässt sich ermitteln, dass die IP aus Amerika stammt. Nun sollten die Pakete aber doch eigentlich von Deutschland möglichst direkt zum Gameserver (in UK) gelangen oder etwa nicht? Jedenfalls taucht bei allen Leuten, die die Probleme NICHT haben, die amerikanische IP auch nicht auf.

So, nun zu meinen Fragen:
Ist die Weiterleitung der Pakete tatsächlich der Grund für die hohen Pings? Das merkwürdige dabei ist, dass auch wenn die Pings niedrig sind, traceroute das gleiche Ergebnis liefert.

Was kann ich da tun? Ich kenne zwar jemanden von der Telekom, aber er ist kein Techniker. Ich müsste ihm schon genau sagen, was das Problem ist bzw. was zu tun ist.

Bevor jemand fragt. Bei dem Gamesupport habe ich es bereits probiert. Seit 2 Monaten keine Antwort.


Ich bin für jede Antwort dankbar :)
 
Ich denke, dass das Zufall ist.
Jeder Provider hat Übergänge in andere Netze. Das kann schon so sein, dass es bei ein paar Leuten so, und bei ein paar wieder anders ist.

Des Weiteren sollte man wissen, wie ein traceroute funktioniert:
Der Rechner sendet einen Ping, mit einer TTL (time to live) von 1 hop, wenn das dann erreicht ist, antwortet der Router, der das Paket gerade hat, dass in einem Hop das Ziel nicht erreicht werden konnte. (praktisch nur eine Antwort auf einen ICMP, also Ping, das Zielnetzwerk ist nicht erreichbar)
Danach sendet dein Rechner einen ping mit einer TTL von 2 hops. Dann mit 3. usw usw. Damit antworten dann alle Router auf dem Weg.

Da TCP/IP nicht wie ATM eine feste Route hat, nehmen die Pakete auch gerne mal unterschiedliche Wege. Das alles hängt mit "Kosten" für einen Hop/die Route zusammen, und auch mit der Lastenteilung.

Daher, wenn du das verstanden hast, kann ein Traceroute auch mal die Ergebnisse von 3 Routen vermischen.

-.-
 
Schwer zu verstehen für einen Anfänger wie mich, aber ich versuchs mal.

Wenn ich dich richtig verstanden habe, listet mir Traceroute alle möglichen Knotenpunkte (Hops?), die ein Paket nehmen kann, auf. Aus dem geht dann aber nicht hervor, welche mein Paket tatsächlich nimmt, richtig?

Gibt es etwas, was genauer als Traceroute funktioniert?

Theoretisch gesehen sollte ja aber auch unter keinen Umständen ein Amrikanischer Server in der Liste auftauchen. Denn sobald meine Pakete darüber gehen, ist das Spiel de facto unspielbar. Da wäre ich aber auch schon wieder bei der Ursprungsfrage, ob sich das ändern lässt.
 
Bin schon auf die Antwort von Merle gespannt :)

Vermutlich kann man in einem Netzwerkmitschnitt(Wireshark) erkennen wie die Pakete hergekommen sind, richtig? Aber ob man das in Echtzeit für ein anderes Programm beeinflußen kann .... k.A., dazu fällt mir grad nix ein :(
 
Das ist nicht ganz so einfach wie du denkst, es muss nicht zwingen sein das der Weg über Amerika langsamer ist z.B. wenn deine Weg nach UK über 3 Hops geht und jeweils nur eine 1mbit Leitung anliegt und bei dem Weg über Amerika 2 Hops und 100mbit anliegen. Da würde der Traffic erstmal über Amerika gehen weil die Verbindung schneller ist und weniger Hops gemacht werden müssen. Aber wenn z.B. viel Traffic über Amerika geht kann es sein das deine Pakete über die 3 Hops und die langsamere Leitungsgeschwindigkeit läuft, weil es für den Moment einfach schneller ist (ist jetzt nur ein hypothetischer Aufbau).

Natürlich gib es auch noch mehr Faktoren und nein du kannst nicht einfach sagen über welche Route deine Pakete geschickt werden, weil du ganz einfach nicht die Routen kennst, was auch unmöglich ist. Die Router werden schon versuchen immer die beste verfügbare Route zunehmen.
 
Der einzige der dir helfen kann ist der Gameserver Provider. Der kann sich den Traceroute anschauen und Maßnahmen ergreifen.

Der DTAG ist es ziemlich egal wo der Traffic hingeroutet wird.
 
Ist ja alles recht ernüchternd, was ich hier lesen muss.

Dass die Route über Amerika die schnellere ist, kann ich mir nur schwer vorstellen, da die Leute ohne diesen Hop einen erheblichen besseren Ping haben. Es geht hier um den Unterschied zwischen 30ms und 130ms.

Das mit dem Gameserver-Provider wäre vielleicht noch eine Idee. Das wäre in diesem Fall laut utrace.de EUKHOST LTD. Werde gleich mal ein kleines Schreiben aufsetzen.
 
Hallo,

du hast doch selber geschrieben, dass der Ping nicht unbedingt schlechter wird, wenn die Pakete den *Umweg* über die USA nehmen. Viel wird dir der Gameserver Betreiber auch nicht sagen. Wenn es dir überhaupt etwas sagt. Einzelne Provider haben auch selten Zugriff auf den Weg der Route.

Viel Erfolg.

Grüße,

Blubbs
 
@BlubbsDE
Wäre mir nicht bewusst, dass ich etwas derartiges gesagt hätte. Sobald die Pakete den Umweg über die USA nehmen, ist das Spiel schlichtweg unspielbar, da die Engine extrem empfindlich auf Pings reagiert. Ab 50ms kann man den Lag schon spüren, ab 80ms grenzt es da schon an eine Zumutung. Bei 130ms fangen Spieler an durch die Luft zu fliegen und sich über die Map zu Porten.

Dass die Provider auch nicht viel tun können, ist mir bewusst. Nur wären die Alternativen mit dem Spiel komplett aufzuhören oder sich nachts den Wecker zu stellen.
 
Wir reden von Latenz, und die ist immer größer je weiter der Weg ist.

Wenn ich mir den Traceroute so anschaue, dann scheint mir eher der Retourweg das Problem zu sein (von Gameserver zur DTAG). Die NTT Router antworten nämlich unter 40ms, während der erste as29550 hop die sehr hohe Latenz hat. Deshalb ist der Traceroute auch derselbe bei Leuten wo der Ping ok ist.

Interessanter wäre deshalb der Traceroute von Gameserver zur DTAG und darauf hat der Gameserver Provider (simplytransit) sehr wohl Einfluss. Melden musst du dich aber direkt bei EUKHOST.
 
Hallo,

ich hatte es so verstanden, dass es eben mit der Uhrzeit und nicht mit der Route zusammen liegt. Du hast ja befriedigende Ergebnisse die aber in den Keller gehen, zu gewissen Tageszeiten.

Deine Überschrift stimmt im Grunde auch so nicht. Wie schon die Vorschreiber geschrieben haben. Eine Verbindung von Dir zu den Inseln über die USA muss kein Umweg sein. Und es muss auch nicht *langsamer* sein. Ein Blick auf die Struktur des INets hilft das zu erklären.

Grüße,

Blubbs
 
Wie schon geschrieben ein Routing über Amerika ist immer langsamer (im Sinne von Latenz), denn schneller als Lichtgeschwindigkeit gehts nun mal auch bei den Unterseekabeln nicht.
 
Nun, ich bin bei weitem kein Experte auf dem Gebiet, da ich hier erst seit wenigen Wochen aktiv lerne. Daher bitte ich die paar Unstimmigkeiten in dem Thread zu entschuldigen.
 
Dass die Route über Amerika die schnellere ist, kann ich mir nur schwer vorstellen, da die Leute ohne diesen Hop einen erheblichen besseren Ping haben. Es geht hier um den Unterschied zwischen 30ms und 130ms.

Oh wow.
Im Routen-Bereich (Routingprotokolle) wird mit "Kosten" gerechnet. Das kann heißen, dass ein 10MBit interface 100 "Punkte" kostet, und ein Gigabitinterface 1 Punkt. Allerdings rechnet das Protokoll dann mit Bandbreite, und nicht Delay! Dennoch wären hier 15 Hops mit Gigabit besser, als 1 Hop mit 10MBit.
So (oberflächlich und vereinfacht) geht das in etwa.
Es gibt natürlich auch andere Protokolle. Im Internet (mit BGP) funktioniert das alles noch etwas anders. Aber sorry, das sprengt den Rahmen, das sind 3 Tage in nem Ciscokurs...

Und nein: Tools wie Traceroute waren nie vorgesehen im Protokoll! Daher gibts nichts "natives". Das verkrüppeln von ICMP/Ping ist leider die einzige Möglichkeit. Und die ist, wie oben richtig vom TE wiederholt, jedes Mal anders und nicht statisch. Oft wird es gleich sein, aber wenn dann mal eine Leitung voll ist, wird per Lastenteilung vielleicht ne andere genommen. Das kennt man auch: Manchmal kommt in der Mitte im Traceroute * * *. Das bedeuted, dass dieser Hop DIESES MAL schon nicht mehr genommen wurde, das Paket kam vorher an. Und danach ist dann plötzlich wieder ein Wert in millisekunden und IP. Da ist das Paket dann über mehr Hops geroutet worde.

Hoffe es wurde etwas klar.

*edit:
Jetzt mehr Zeit:
Vermutlich kann man in einem Netzwerkmitschnitt(Wireshark) erkennen wie die Pakete hergekommen sind
Nein. Also du kannst auslesen, woher diese kommen, aber nicht wie. Zumindest nicht du am Ende. Mit dem Auslesen von Infos, die sich die Provider untereinender senden (BGP Protokollinformationen, Routingupdates), kannst du den ASPATH sehen, woher dieses BGP-Paket kommt und welche Autonomen Systeme (Netzwerke der Provider) es hinter sich hat.

Also nein. TCP/IP war nie dafür gedacht, sich darum zu scheren. Es gibt einen Weg? Nimm den. Ob es da noch einen anderen Weg gibt, ist irrelevant.
Der Header beinhaltet neben CRC (eigentlich nicht im Header) und diversen Flags eigentlich nur 4 Infos:
Destination MAC, Destination IP, Source MAC, Source IP.
Die MAC Adresse ist für das Switching wichtig. Geswitcht wird aber nur in einem Netzwerk. D.h. wenn du mit der IP 192.168.0.10/24 ein Paket an die 192.168.0.11/24 schickst, bleibt die MAC gleich und dient auch als Zieladresse.
Wenn du aber etwas zu 150.10.10.10 senden willst, was nicht in deinem Netzwerk ist, schickt dein PC das Paket an deinen Router. In der Source MAC steht deine. In der Destination MAC steht dann die des Routers (denn an den muss das Paket nun, damit er es weitervermittelt). In der Destination IP steht die 150.10.10.10.
Wenn dein Router nun das Paket weiterleitet, dann ersetzt er die Source MAC durch seine am WAN Port. Und die Destination MAC durch den next Hop (der ihm durch Routingprotokolle bekannt ist). Die Destination IP muss ja gleich bleiben, sonst würde es nie ankommen. Normalerweise würde die Source IP deine bleiben. Bei unseren Heimroutern (und überall, wo NAT betrieben wird) wird diese aber durch seine öffentliche ersetzt, damit die Antwort wieder ankommt.
Der Router merkt sich dabei in einer Tabelle, was er durch was ersetzt, und wenn der Server dann wieder an den Router ein Paket geschickt hat, ersetzt der Router die Daten wieder, damit du das Paket bekommst.

Nun ist es etwas detaillierter. Es gibt in dieser Art von Kommunikation keine Möglichkeit, den Weg herauszufinden.

Mit Routingprotokollen kann man nun einen Einfluss nehmen. Aber die entscheiden das nunmal selbst, je nach Konfiguration. In Netzwerken mit OSPF oder EIGRP kann man da schon Einfluss nehmen. Aber in dem größten Netz der Welt, dem Internet, ist nunmal BGP Standard. Da ist es nicht so einfach.

Das ganze Zeugs oben ist noch ein bissle komplexer, denn L2/Switching sind andere Datenpakete als L3/Routing. Aber prinzipiell sollte das reichen, um es ein wenig zu verstehen.

*edit2:
Hier noch was zur prinzipiellen Wahl von Pfaden in Protokollen.
http://de.wikipedia.org/wiki/Algorithmus_von_Dijkstra
 
Zuletzt bearbeitet:
Den ersten Teil habe ich noch verstanden, den zweiten nicht. War aber wohl nicht ganz an mich gerichtet ;)

Ich habe derweil bereits eine Antwort vom Customer Support von eukhost erhalten:
I'll get one of our Network Administrators involved, as this problem is very complicated and it will need high level technical assistance to get this problem resolved.
Das ist schonmal ein sehr guter Ansatz.

Mit der Telekom hatte ich sicherheitshalber auch Kontakt aufgenommen. Dort war man sich aber nicht ganz schlüssig, was man dagegen tun könne.
 
Mit der Telekom hatte ich sicherheitshalber auch Kontakt aufgenommen. Dort war man sich aber nicht ganz schlüssig, was man dagegen tun könne.
Hihi, ja. Das muss an die echten Spezialisten. Und die tragen wegen dir keine statische Route ein. Vor allem, da sich deine IP dauernd ändert. Aber auch so würden die das mit an Sicherheit grenzender Wahrscheinlichkeit nicht machen. Dynamische Routingprotokolle sind für sich ständig ändernde Netzwerke gedacht. Und das Internet ist ja eben das größte solche.
Viel Erfolg :)
 
Ja gut, es ist ja nicht nur mein Problem, sondern eine Anzahl von Schätzungsweise zwischen 100 und 1000 Spielern. Eventuell ist das etwas untergegangen. Das wäre dann aber mein Fehler ;)
 
Statische Routen haben in der DFZ überhaupt nichts verloren, BGP hat genug Mittel zum Traffic Engineering implementiert (von loc-pref, MED über path prepending oder communities).

So oder so, das Routing muss eh bei Simply Transit geändert werden, und nicht bei der DTAG. Ob die extra eine DTAG spezifische Konfiguration alla AS_PATH _3320$ machen ist eine andere Frage.
 
Kleines Update:
Der Spielevertreiber arbeitet gegen mich. Nachdem der Server Hoster die Arbeit an dem Problem aufgenommen hatte und dies dem Vertreiber mitgeteilt hatte, scheint dieser einfach abzustreiten, dass es irgendwelche Probleme gebe. Unter diesen Umständen ist der Server Hoster nicht gewillt, weiter der Sache nachzugehen.

Ich weiß nicht, was ich dazu sagen soll und kann es auch nicht verstehen...
 
Ich kann es sehr gut verstehen. Die haben alle keine Lust dazu, weil sich nicht genug Kunden aufgeregt haben.

Ist das ein kostenloses Spiel oder per Bezahlung?

Frage beim Server Hoster nach, ob er dir von seinen Server aus ein traceroute auf 217.0.119.205 machen kann (dein DTAG PoP), das sollte in diesem Fall aussagekräftiger sein als dein eigener Tracerouter Richtung Server.

An diesem sollte dann ersichtlich sein, wo wirklich das Problem liegt, und eventuell kannst du deinen Server Hoster dann nochmal mit einer spezifischeren Frage zum Handeln zwingen.
 
Werbebanner
Zurück
Top