Bei einem Client, für den sich immer mehr zu sendende Daten anstauen, verwirft der Server veraltete Updates oder trennt die Verbindung.
Warum Leitung des Clients kommt mit der Datenmenge des Servers nicht mit → Folge Server verwirft veraltete Updates oder trennt bei Überschreiten des Limits die Verbindung → Auf dem Bildschirm Nur bei diesem Spieler Teleportieren oder Verbindungsabbruch
Sendevolumen senken (Update-Frequenz nach Entfernung), mit reduzierter Qualität weitersenden, im Kernel gepufferte Menge begrenzen (TCP_NOTSENT_LOWAT unter Linux).
Größenordnungen
Bei 256 KB Sendepuffer stauen sich auf einer Leitung mit 30 KB/s Daten für über 8 s an. Linux vergrößert diesen Puffer automatisch teils auf mehrere MB.
Im Graphen
Nur einzelne Ausreißer · Send-Q pro Verbindung, verworfene Updates pro Client
Wo nachsehen
Vom Spielserver protokollierte Länge der Sende-Queue, verworfene Updates und Trennungsgründe pro Client prüfen, auf dem Server mit ss -tni Send-Q und cwnd dieser Verbindung zusammen kontrollieren
Spricht dafür
Nur bei Spielern mit Sprüngen oder Abbrüchen bleibt die Send-Q ständig gefüllt, und das Spiel-Log verzeichnet für sie verworfene Updates oder Trennungen wegen überlaufender Sende-Queue
Spricht dagegen
Send-Q leer, trotzdem Teleportieren: kein Problem beim Senden des Servers. Eher Paketverlust auf der Leitung des Spielers („Verlust auf der Funkstrecke“) oder die Interpolation auf dem Bildschirm
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Quellen
IP SysctlLinux kernel tcp_wmem: Maximum des automatisch angepassten Sendepuffers standardmäßig 64 KB bis 4 MB (je nach Speicher), tcp_notsent_lowat bzw. TCP_NOTSENT_LOWAT begrenzt die Menge noch nicht gesendeter Daten
net/ipv4/tcp_diag.c (Linux v6.12)Linux kernel Werte Recv-Q und Send-Q in ss: beim Listen-Socket die Zahl der Verbindungen, die auf accept warten, und das Backlog-Limit, beim verbundenen Socket die von der Anwendung noch nicht gelesenen Bytes und die gesendeten, noch nicht per ACK bestätigten Bytes