Ping-/Disconnect-Probleme

[Raijin]

Jein. Dass gänzlich verschiedene Programme identische Ports nutzen, ist vergleichsweise unwahrscheinlich. Jeder Programmierer, der eine Anwendung erstellt, wird zumindest kurz darüber nachdenken welchen Port er nutzt und gerade Voice-Chats werden ja gern bei Spielen eingesetzt und ich bezweifle stark, dass jemand so blöd wäre, Steam-Ports, o.ä. zu nutzen...

Ich meinte das auch nicht unbedingt in Bezug auf Fremdprogramme, sondern auf das Spiel selbst. Ein Spiel ist nichts anderes als eine normale Anwendung, die über Netzwerk kommuniziert. Ein Programm heißt nicht zwingend nur ein Port. Ein Programm kann Dutzende, Hunderte von Verbindungen aufbauen, siehe Torrent und ähnliche p2p Tools, die ja auch mit etlichen anderen Teilnehmern kommunizieren - jeweils auf einer eigenen Verbindung. Das klassische Beispiel bei Spielen wären zB eine Verbindung für die Spieldaten und eine separate Verbindung für den internen Voice-Chat. Je nach Spiel werden vielleicht noch weitere Verbindungen benötigt, um beliebige Daten zu übertragen.


Beim Voice-Chat ist die Bandbreite nicht unbedingt das Problem. Die ist vergleichbar mit einem simplen MP3-Stream, kbit/s Bereich. Entscheidender ist da eher der Ping bzw. die Paketverluste. Wenn unterwegs aus irgendwelchen Gründen jedes 3. Paket verloren geht, kann es eben passieren, dass auch jedes 3. Wort von dir nicht beim Gesprächspartner ankommt.

 

[nciht]

Wenn ich meinen Ping von verschiedenen Webseiten checken lasse oder auch im Spiel anzeigen lasse, ist der eigentlich nicht so schlecht (immer unter 50ms). Kann der Medienkonverter zwischen meinem Router und der Glasfaserdose ggf. verantwortlich sein, dass Pakete verloren gehen oder der Ping kurzzeitig, ohne dass ich es gerade im Blick habe in die Höhe geht? Ist ein Verlust von Paketen durch einen nicht freigegebenen Port zu vermuten? Ich vermute mal, dass ein Verlust von Paketen auch im Spiel dazu führen kann, dass ich disconnecte, oder?

Nachtrag: Kannst du evtl. ein Programm empfehlen, mit dem ich Ping und Paketverlust über einen längeren Zeitraum überprüfen kann, ggf. sogar zu verschiedenen Servern?

 

[Raijin]

Rudimentär kann man den Ping ganz simpel testen, mit .. .. .. ping. Dabei sollte zB der Ping auf 8.8.8.8 (google-dns) <30 ms liegen.

Start --> cmd
--> ping 8.8.8.8 -t

(Strg+C beendet den Dauerping)

Pingplotter ist ein Tool, das zudem noch den Weg protokolliert, also einen Traceroute macht.


Paketverlust hat mit Ports an sich nichts zu tun. Paketverluste treten auf, wenn unterwegs das Paket einfach .. .. verloren geht. Das kann zB passieren, wenn eine Zwischenstation auf dem Weg überlastet ist und "alte" Pakete einfach fallen lässt. Oder die Pakete sind zu groß, weil man mit der MTU gespielt hat, um die letzten 0,0000001% aus der Leitung zu holen und .. .. naja .. .. ein Router im www spielt nicht mit und kickt die großen Pakete nach Lust und Laune. Es kann auch passieren, dass ein Paket unterwegs kaputt geht. Ein Beispiel dafür wäre WLAN, das durch Funkstörungen vereinzelt nicht sauber funken kann und daher Pakete nur "defekt" beim Empfänger ankommen (Checksumme, etc).

 

[nciht]

Wenn ich kleine Pakete mit 32 Bytes schicke hab ich einen Ping von 18ms durchgehend. Verschicke ich 65000 Bytes pro Paket ist der Ping bei 288ms durchgehend. Je 100 Pings gesendet, kein Paket verloren...

edit: habe gestern noch in der Fritzbox und in der Windows Firewall alle Ports, die Steam benötigt freigegeben und danach eine halbe Stunde EU4 im Multiplayer probiert. Lief soweit problemlos. Allerdings habe ich vergessen vor dem Portsfreigeben den Multiplayer bei EU4 zu testen. Entweder deaktiviere ich die Portfreigaben in der Fritzbox und in der Firewall heute Abend und vergleiche das Ergebnis, oder ich schaue, ob mein Freund in D sich eine halbe Stunde Zeit nehmen kann um den Multiplayer in EU4 zu testen.

 

[Raijin]

Kein Wunder, die MTU - Maximum Transmission Unit - liegt bei max 1500 Byte. Alles was größer ist wird zwangsläufig fragmentiert, also in mehrere Pakete mit max 1500 Byte geteilt. Ein einzelner Ping mit 65000 Byte ist so also gar nicht möglich. Mit sogenannten Jumbo Frames kann ein Paket auf 9000 Byte aufgeblasen werden, aber das steht auf einem anderen Blatt.

Tools wie TCP-Optimizer versprechen, die MTU auf das Maximum zu schrauben. Je größer die MTU umso niedriger der Overhead des Protokolls, da der Kopfteil des Pakets gleich bleibt, aber die Nutzlast vergrößert wird, die eigentlichen Daten. In der Theorie steigt dadurch die Datenrate. In der Praxis bedeutet eine zu große MTU aber, dass Pakete fragmentiert werden, mutwillig auseinandergerissen. Im worst case werden sie sogar komplett ignoriert und laufen ins Leere.

Die MTU sollte man tunlichst nicht anfassen, da eine falsche MTU zu massiven Problemen im Netzwerk führen kann. Selbst wenn man die MTU um ein paar Byte vergrößern kann, ohne dass es Probleme gibt, hält sich der Nutzen in Grenzen. Daher kann ich von der Nutzung solcher Tools nur abraten.

 

[nciht]

Ich wollte auch eher mal schauen, ob irgendwas verloren geht, wenn ich mit der Paketgröße etwas übertreibe. Ich gebe heute Abend bescheid, ob sich die Probleme beim zocken durch die Portfreigaben erledigt haben und bedanke mich vorher für den Hinweis und die Hilfe...

 

[Raijin]

Das ist nicht aussagekräftig, da die MTU vom Betriebssystem verwaltet wird. Selbst wenn du zB ein Linux-Image mit 600 MByte aus dem Internet herunterlädst, wird das nicht in einem Paket bzw. fragmentierten Paket übertragen, sondern in handliche ~1500 Byte Stücke zerhackt und nacheinander verschickt.

Wenn du bei Ping einfach nur die Datengröße änderst, siehst du auch keine Paketverluste, da das Paket dann eben mit dem Vorschlaghammer zertrümmert und in 1500er Stücke gesplittet wird.

Versuch stattdessen mal das:

ping 8.8.8.8 -f -l 65000

Du wirst sehen, dass das nicht funktioniert, weil der Schalter -f verhindert, dass das Paket fragmentiert wird und daher nicht übertragen werden kann. Verringerst du den Wert auf zB 1450, sollte das Paket durchkommen, weil es nicht fragmentiert werden muss. Die Grenze wird irgendwo um und bei 1472