Synchronisation d'horloge client-serveur : estimer le temps sans masquer l'incertitude

Faire correspondre une horloge à une autre

Un jeu en réseau a besoin d'une interprétation commune des horodatages d'événements, mais les clients ne partent pas avec des horloges identiques. Utilisez une horloge locale monotone pour le temps écoulé et maintenez une correspondance avec le temps de session du serveur. L'heure calendaire est inutile pour de nombreux événements de partie. Le décalage d'horloge (offset) décrit une différence de temps ; la dérive (drift) décrit une différence de rythme. Une synchronisation unique n'élimine pas la dérive ultérieure.

Gardez le domaine temporel explicite dans les structures de données. Un horodatage serveur, un horodatage d'entrée local et un horodatage de présentation différé ne sont pas interchangeables du simple fait qu'ils sont tous exprimés en secondes.

Estimer le décalage par un échange d'horodatages

Soit t1 l'heure d'envoi côté client, t2 l'heure de réception côté serveur, t3 l'heure de réponse du serveur et t4 l'heure de réception côté client. Si les horloges avancent à un rythme quasi identique pendant l'échange, l'estimateur standard est offset = ((t2 - t1) + (t3 - t4)) / 2, avec la convention de signe « heure serveur moins heure client ». Le délai d'aller-retour réseau est delay = (t4 - t1) - (t3 - t2). Soustraire le temps de traitement du serveur évite de compter cet intervalle comme du transit réseau. Ce sont les relations entre horodatages décrites par NTP. [1]

Exemple détaillé : délai de traitement et asymétrie des chemins

Prenons, à titre d'illustration, les horodatages 10,000, 10,260, 10,280 et 10,120 secondes, dans cet ordre. Le traitement par le serveur occupe 0,020 seconde. L'aller-retour réseau estimé vaut 0.120 - 0.020 = 0.100 seconde, et le décalage vaut (0.260 + 0.160) / 2 = 0.210 seconde.

L'estimation du décalage suppose des délais aller et retour symétriques. Des chemins de 70 millisecondes à l'aller et de 30 millisecondes au retour fausseraient cette estimation de 20 millisecondes. L'échange seul ne permet pas d'identifier dans quel sens le délai s'est produit. Un aller-retour court réduit une partie de l'incertitude ; il ne prouve pas que les chemins étaient symétriques.

Filtrer les mesures et appliquer les corrections de façon réfléchie

Collectez des échantillons répétés, associez les réponses aux requêtes en attente et rejetez les données de sessions obsolètes. Suivez la variation du délai et la dispersion du décalage. Mirror expose une estimation du temps synchronisé en double précision, des informations sur l'aller-retour et la variation de mesure, et documente un lissage par moyenne mobile exponentielle. Préservez la précision du type de temps fourni. [2]

Filtrez les échantillons bruités plutôt que de caler l'horloge de jeu sur chaque réponse. Décidez si les petites corrections ajustent la correspondance progressivement et comment une discontinuité importante réinitialise les tampons qui en dépendent. Une chronologie de jeu monotone ne doit pas reculer par accident lorsque l'estimation du décalage diminue. Resynchronisez après une mise en veille, une reconnexion ou un changement d'époque du serveur ; invalidez les comparaisons entre époques incompatibles.

Valider les consommateurs du temps

Testez la dérive d'horloge, les longues sessions, les pics de temps de traitement du serveur et les liaisons asymétriques. Journalisez séparément les échantillons bruts, les estimations filtrées et les corrections. La variation de mesure n'est pas une borne certifiée de l'erreur réelle sur le décalage. Le serveur doit toujours valider les horodatages d'événements fournis par le client. La synchronisation fournit une estimation du temps ; elle ne choisit pas elle-même un délai d'interpolation, n'autorise pas d'actions situées dans le passé et ne fait pas de l'horloge d'un client une référence faisant autorité.

Sources

• [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.