한국어English日本語简体中文繁體中文DeutschไทยTiếng ViệtРусскийPortuguês (Brasil)EspañolBahasa Indonesia

Game-Lag-Whitepaper › Probleme, die nur einige betreffen

Verlust gebündelter Spawn-Daten direkt nach dem Betreten Initial spawn burst lost (unreliable channel, receive buffer, fragmentation)

Ursachen-ID pt-spawn-burst · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-Entwicklung (Entwicklungsteam)

In der interaktiven Fassung mit Grafiken und Experimenten öffnen →

Beim Betreten einer Zone schickt der Server die Spawn-Daten von Dutzenden bis Hunderten Objekten in der Umgebung auf einmal. Gehen sie über einen Unreliable-Kanal oder läuft der Empfangspuffer über, während der Client beim Laden den Socket nicht liest, verschwindet ein Teil davon und kommt nicht wieder.

Warum Direkt nach dem Betreten kommen Spawn-Daten gebündelt in kurzer Zeit an → Folge Ladender Client liest den Socket spät, und der Empfangspuffer des OS läuft über, oder große UDP-Pakete werden fragmentiert und gehen schon bei einem einzigen verlorenen Fragment komplett verloren. Ein Unreliable-Kanal sendet auch nicht erneut → Auf dem Bildschirm Nur beim langsamer ladenden Client fehlen einige NPCs. Verlässt man den Sichtbereich und kommt zurück, sind sie da

Symptome
Unsichtbar / Geisterobjekte
Faktoren
Paketverlust
Wer ist betroffen
Nur ein Client auf demselben PC, Nur ich
Wann
Direkt nach Login oder Wartung, Beim Bewegen oder Zonenwechsel
Zuständigkeit
Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Aufgaben Entwicklungsteam
Server: Spawn- und Despawn-Meldungen nur über einen zuverlässigen Kanal mit garantierter Retransmission senden, Anfangsdaten aufgeteilt senden. Client: Empfang in einem vom Laden getrennten Thread, Empfangspuffer vergrößern.
Größenordnungen
Der Standardwert des UDP-Empfangspuffers auf dem PC unterscheidet sich je nach OS, liegt aber meist bei einigen Dutzend bis einigen hundert KB. Sind die Eintrittsdaten einer belebten Stadt größer, läuft er über, sobald der Socket wegen des Ladens auch nur kurz nicht gelesen wird.
Im Graphen
Ansturm direkt nach Login oder Wartung · Empfangsmenge direkt nach dem Betreten, fehlende Spawn-Meldungen
Wo nachsehen
Zahl der direkt nach dem Betreten vom Server gesendeten Spawn-Meldungen mit der Zahl der vom Client empfangenen vergleichen und prüfen, über welchen Kanal (reliable oder unreliable) gesendet wurde. Im serverseitigen Paketmitschnitt die Datenmenge an diesen Spieler direkt nach dem Betreten und fragmentierte Pakete (Wireshark-Filter ip.flags.mf == 1 || ip.frag_offset > 0) prüfen
Spricht dafür
Weniger empfangen als gesendet, die fehlenden Meldungen liegen im gebündelten Abschnitt direkt nach dem Betreten, gesendet über einen Unreliable-Kanal oder große Pakete fragmentiert. Tritt beim langsamer ladenden Client häufiger auf
Spricht dagegen
Gesendet und empfangen gleich viele, trotzdem unsichtbar: nach dem Empfang verworfen („Verworfene Spawn-Meldungen während des Ladens“) oder Problem bei der Sichtbereichsberechnung. Fehlen unabhängig vom Betreten immer wieder: Paketverlust auf der Leitung
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig

Quellen

  1. RFC 8085: UDP Usage Guidelines IETF
    Ein fragmentiertes Paket geht komplett verloren, wenn auch nur ein Fragment fehlt
  2. UDP vs. TCP Gaffer On Games
    UDP garantiert weder Zustellung noch Reihenfolge, verlorene Pakete muss man selbst erkennen und erneut senden
  3. Socket.ReceiveBufferSize Property Microsoft
    Die Standardgröße des Socket-Empfangspuffers unterscheidet sich je nach OS
  4. Display Filter Reference: Internet Protocol Version 4 Wireshark
    Filtert fragmentierte IP-Pakete über ip.flags.mf (More fragments) und ip.frag_offset (Fragment Offset)

Verwandte Ursachen

Gleiche Schicht: Probleme, die nur einige betreffen

Ursachen aus anderen Schichten mit demselben Symptom (Unsichtbar / Geisterobjekte)

Karte in der interaktiven Fassung mit Grafiken und Experimenten ansehen