Zuverlässige und unzuverlässige Spielnachrichten: Garantien nach ihrer Bedeutung wählen

Folgen eines Verlusts einordnen

Der zuverlässige Modus eines Transports sendet fehlende Daten erneut, solange die Verbindung tragfähig bleibt; bei unzuverlässiger Zustellung können Nachrichten verloren gehen. Die Reihenfolge ist eine eigene Eigenschaft, die eine API mit Zuverlässigkeit kombinieren kann. Die Garantien sind nach der Bedeutung der Nachricht zu wählen: Ein neuerer, vollständiger Positionszustand kann einen älteren ersetzen, eine Kaufanfrage dagegen braucht ein eindeutiges Ergebnis (akzeptiert oder abgelehnt). Keine der beiden Kategorien sagt etwas darüber aus, ob der Server den Inhalt für vertrauenswürdig halten soll.

Paketbestätigungen von Aktionsergebnissen trennen

Sequenznummern identifizieren Pakete oder Nachrichten innerhalb des Streams, für den sie definiert sind. Eine Paketbestätigung besagt, dass Transportdaten angekommen sind; sie belegt nicht, dass das Spiel eine Aktion validiert oder übernommen (committed) hat. Fiedlers Diskussion des Protokolls erklärt zudem, warum fehlende Bestätigungen Unsicherheit erzeugen und warum wiederholt gesendete Anwendungsdaten eine eigene Identität benötigen. [1]

Wichtige Befehle erhalten eine Kennung mit begrenztem Gültigkeitsbereich, und die Anwendung liefert ein Ergebnis zurück. Können Wiederholungen oder die Wiederherstellung nach einem Reconnect einen Befehl erneut auslösen, ist sein Ergebnis für das unterstützte Wiederholungsfenster aufzubewahren. Die Anfrage ist zu validieren; ihre Wirkung und das Ergebnis der Deduplizierung sind konsistent zu speichern. Ein zuverlässiger Socket allein bietet keine Exactly-once-Ausführung über Abstürze hinweg.

Praxisbeispiel: veralteter Zustand und wiederholter Befehl

Angenommen, der vollständige Bewegungszustand 41 setzt einen Avatar auf Koordinate 8, Zustand 42 auf Koordinate 9. Trifft 42 vor 41 ein, behält ein Empfänger, der nach Aktualität entscheidet, die Koordinate 9 und verwirft den älteren Zustand. Diese Strategie setzt in sich geschlossene Updates oder eine gültige Basis für die Rekonstruktion voraus; werden beliebige Deltas verworfen, kann die Zustandsrekonstruktion scheitern.

Davon unabhängig sendet ein Client den Befehl 17, um einen Gegenstand aufzusammeln. Der Server validiert ihn, vergibt den Gegenstand und speichert das Ergebnis. Wird Befehl 17 wiederholt, weil die Antwort der Anwendung verloren ging, liefert der Server das gespeicherte Ergebnis zurück, ohne einen weiteren Gegenstand zu vergeben. Befehlskennung und Bewegungssequenz lösen unterschiedliche Probleme und sollten keine zufällig gemeinsame Semantik haben.

Reihenfolgeabhängigkeiten isolieren und Datenverkehr budgetieren

Zuverlässige, geordnete Zustellung kann spätere Nachrichten desselben Streams zurückhalten, bis eine fehlende frühere Nachricht eintrifft. Valves Connection Lanes (Verbindungskanäle) erlauben es, unabhängigen Datenverkehr von dieser Reihenfolgeabhängigkeit zu entkoppeln: Zuverlässige Nachrichten sind innerhalb einer Lane geordnet, über Lanes hinweg gibt es keine entsprechende Garantie. Kausal abhängige Operationen dürfen nie ohne ausdrückliche Behandlung der Abhängigkeit auf mehrere Lanes verteilt werden. [2]

Flüchtiger Zustand ist von Massenübertragungen getrennt zu halten, sofern der Transport das unterstützt. Sendewarteschlangen sind zu begrenzen, das Alter der Nachrichten ist zu überwachen, und die Überlastkontrolle (Congestion Control) soll den Datenverkehr takten. Werden veraltete Zustände immer wieder zuverlässig eingereiht, kann eine wachsende Verzögerung entstehen, auch wenn die Zustellung letztlich funktioniert. Noch nicht gesendeter Zustand darf nur dort zusammengefasst oder ersetzt werden, wo seine Semantik es erlaubt.

Den Zustellvertrag testen

Verlust, Duplikate, Umordnung und Verbindungsabbrüche sind gezielt zu erzeugen. Zu prüfen sind die Zurückweisung veralteter Zustände, die Deduplizierung von Befehlen, Warteschlangengrenzen und die Wiederherstellung nach dem Reconnect. Festzulegen sind der Gültigkeitsbereich der Kennungen, der Umgang mit dem Überlauf der Sequenznummern und die Dauer, für die Ergebnisse abrufbar bleiben. Zuverlässigkeit macht einen abgelaufenen Befehl nicht nützlich, autorisiert keine ungültige Anfrage und garantiert keinen Abschluss nach einem dauerhaften Verbindungsabbruch. Die Zustände «ausstehend», «bestätigt» und «fehlgeschlagen» sind dem Gameplay offenzulegen, wo diese Unterscheidung relevant ist.

Quellen

• [1] Reliability and Congestion Avoidance over UDP — Glenn Fiedler, Gaffer On Games.
• [2] GameNetworkingSockets Interface: Message Delivery and Connection Lanes — Valve Software, Originalquelle der API.