Sind die selbst gebauten Retransmission-Regeln auf UDP zu vorsichtig, erholt sich die Übertragung erst spät. Sind sie zu aggressiv, verstopfen sie die Leitung zusätzlich.
Warum Einstellungen für Retransmission-Intervall, Anzahl der Versuche und Window-Größe passen nicht zur Leitung → Folge Späte Wiederherstellung oder mehr Überlast durch doppelt gesendete Daten → Auf dem Bildschirm Verschluckte Skills, Zeitraffer, bei Überlast noch stärkerer Lag
Server: Retransmission auf Basis der gemessenen Umlaufzeit, Kanäle nach Wichtigkeit trennen. Client: dieselben Retransmission- und Kanaleinstellungen wie der Server verwenden.
Im Graphen
Vereinzelte Spitzen ohne Muster · Retransmission-Rate bei zuverlässigem UDP, RTT im Spiel
Wo nachsehen
Statistiken der verwendeten Bibliothek pro Verbindung (Retransmissions, geschätzte Umlaufzeit, Wartezeit bis zur Retransmission) auf Server und Client protokollieren und mit der tatsächlichen Verlustrate der Leitung desselben Spielers vergleichen (per mtr gemessen)
Spricht dafür
Retransmission-Rate um ein Mehrfaches höher als die tatsächliche Verlustrate der Leitung: zu aggressive Einstellung. Wartezeit bis zur Retransmission ein Mehrfaches der gemessenen Umlaufzeit: zu vorsichtige Einstellung
Spricht dagegen
Retransmission-Rate ähnlich der Verlustrate der Leitung und Wartezeit passend zur Umlaufzeit: kein Einstellungsproblem. Den Paketverlust der Leitung selbst untersuchen
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Quellen
RFC 8085: UDP Usage GuidelinesIETF Retransmissions können Überlast verstärken und unterliegen daher der Congestion Control, die Umlaufzeit wird als gleitendes Mittel mehrerer Messungen (EWMA) geschätzt, Startwert 1 s, bei Timer-Ablauf Senderate senken