Zeitsynchronisation zwischen Client und Server: Zeit schätzen, ohne die Unsicherheit zu verbergen

Eine Uhr auf eine andere abbilden

Ein Netzwerkspiel braucht eine gemeinsame Deutung der Ereigniszeitstempel, doch die Uhren der Clients stimmen anfangs nicht überein. Für die verstrichene Zeit eine monotone lokale Uhr verwenden und eine Abbildung auf die Server-Sitzungszeit pflegen. Kalenderzeit ist für viele Match-Ereignisse nicht nötig. Der Offset beschreibt eine Zeitdifferenz, die Drift eine Differenz der Laufgeschwindigkeit. Einmaliges Synchronisieren beseitigt spätere Drift nicht.

Die Zeitdomäne in Datenstrukturen explizit halten. Ein Server-Zeitstempel, ein lokaler Eingabe-Zeitstempel und ein verzögerter Darstellungs-Zeitstempel sind nicht austauschbar, nur weil alle in Sekunden angegeben sind.

Offset mit einem Zeitstempelaustausch schätzen

Es seien t1 die Sendezeit des Clients, t2 die Empfangszeit des Servers, t3 die Antwortzeit des Servers und t4 die Empfangszeit des Clients. Laufen die Uhren während des Austauschs nahezu gleich schnell, lautet der Standardschätzer offset = ((t2 - t1) + (t3 - t4)) / 2, mit Serverzeit minus Clientzeit als Vorzeichenkonvention. Die Netzwerk-Umlaufverzögerung beträgt delay = (t4 - t1) - (t3 - t2). Durch das Abziehen der Serververarbeitungszeit wird dieses Intervall nicht fälschlich als Netzwerklaufzeit gewertet. Dies sind die im NTP beschriebenen Zeitstempelbeziehungen. [1]

Rechenbeispiel: Verarbeitungsverzögerung und Pfadasymmetrie

Als Beispielwerte dienen die Zeitstempel 10,000 s, 10,260 s, 10,280 s und 10,120 s in der genannten Reihenfolge. Die Serververarbeitung dauert 0,020 Sekunden. Die geschätzte Netzwerk-Umlaufzeit beträgt 0.120 - 0.020 = 0.100 Sekunden, der Offset (0.260 + 0.160) / 2 = 0.210 Sekunden.

Die Offset-Schätzung setzt voraus, dass Hin- und Rückweg gleich lang verzögern. Bei 70 Millisekunden auf dem Hinweg und 30 Millisekunden auf dem Rückweg wäre die Schätzung um 20 Millisekunden verfälscht. Aus dem Austausch allein lässt sich nicht erkennen, in welcher Richtung die Verzögerung entstand. Eine kleine Umlaufzeit verringert manche Unsicherheit, beweist aber nicht, dass die Pfade symmetrisch waren.

Messwerte filtern und Korrekturen gezielt anwenden

Mehrere Messwerte sammeln, Antworten den offenen Anfragen zuordnen und veraltete Sitzungsdaten verwerfen. Schwankung der Verzögerung und Streuung des Offsets verfolgen. Mirror stellt eine synchronisierte Zeitschätzung in doppelter Genauigkeit (double), Informationen zur Umlaufzeit und die Messschwankung bereit und dokumentiert eine Glättung mit einem exponentiell gleitenden Mittelwert. Die Genauigkeit des gelieferten Zeittyps erhalten. [2]

Verrauschte Messwerte filtern, statt die Spieluhr bei jeder Antwort auf den neuen Wert zu setzen. Festlegen, ob kleine Korrekturen die Abbildung schrittweise anpassen und wie ein grosser Sprung davon abhängige Puffer zurücksetzt. Eine monotone Spielzeitlinie darf nicht versehentlich rückwärts laufen, wenn eine Offset-Schätzung sinkt. Nach einem Ruhezustand, einer Wiederverbindung oder einem Wechsel der Server-Epoche neu synchronisieren; Vergleiche über inkompatible Epochen hinweg ungültig machen.

Die Verbraucher der Zeit validieren

Uhrendrift, lange Sitzungen, Verarbeitungsspitzen auf dem Server und asymmetrische Verbindungen testen. Rohmesswerte, gefilterte Schätzungen und Korrekturen getrennt protokollieren. Die Messschwankung ist keine zertifizierte Schranke für den tatsächlichen Offset-Fehler. Der Server muss vom Client gelieferte Ereigniszeiten weiterhin validieren. Die Synchronisation liefert eine Zeitschätzung; sie legt weder eine Interpolationsverzögerung fest noch autorisiert sie Aktionen aus der Vergangenheit, und sie macht die Uhr eines Clients nicht massgebend.

Quellen

• [1] Network Time Protocol Version 4: Protocol and Algorithms Specification — David L. Mills, Jim Martin, Jack Burbank and William Kasch, IETF RFC 5905.
• [2] Time Synchronization — Mirror Networking contributors.