Dans un jeu en ligne, chaque écran affiche un présent différent. Une commande prend du temps pour rejoindre le serveur, puis le nouvel état revient. Attendre ce trajet avant de bouger le personnage rendrait la manette lourde. Le client prédit localement, tandis que le serveur garde l’autorité.

À 60 Hz, l’écran se redessine toutes les 16,7 ms. Avec 80 ms de réseau, plusieurs images passent avant la réponse. Le client applique immédiatement l’entrée, lui donne un numéro de séquence et l’envoie. Le serveur simule dans l’ordre et retourne position confirmée et dernière entrée traitée.

Prédire, puis corriger sans sauter

Le flux ressemble à ceci :

1. client applique entrée 41 et affiche x=10,4;
2. entrée 41 part vers le serveur;
3. serveur valide et calcule x=10,2;
4. réponse confirme les entrées jusqu’à 41;
5. client remet l’état à 10,2;
6. il rejoue les entrées 42 et 43 encore en attente;
7. une petite interpolation masque l’écart visuel.

Un client modifié peut prétendre avancer trop vite. Le serveur limite accélération, cadence et collisions. Il ne fait pas confiance à la position finale envoyée. Cette autorité protège le jeu, mais augmente le coût de simulation centrale.

Les autres joueurs sont affichés avec un léger retard dans un tampon. Le client interpole entre deux états reçus plutôt que deviner chaque mouvement. Si un paquet manque, il extrapole brièvement puis corrige. Trop de tampon rend la partie stable mais retardée; trop peu produit des saccades.

La fiabilité complète serait trop lente

Les mises à jour fréquentes de position peuvent utiliser UDP et tolérer la perte : une position plus récente rend l’ancienne inutile. Un achat ou un changement d’inventaire exige accusé de réception, identifiant unique et persistance. Choisir la garantie par type de message évite qu’un paquet perdu de mouvement bloque tous les suivants.

Le serveur suit latence, gigue, pertes et tick rate. Sous surcharge, diminuer silencieusement la fréquence de simulation peut changer la physique. Des limites de joueurs, instances supplémentaires et dégradation contrôlée sont préférables. Les attaques par volume et les paquets malformés doivent être filtrés avant la boucle de jeu.

Réconcilier les collisions avec le temps du serveur

Un joueur peut voir son tir toucher alors que le serveur reçoit la commande plus tard. Pour certaines actions, le serveur garde une courte histoire des positions, replace temporairement les cibles au temps estimé du tir, puis valide la collision. Cette compensation de latence possède une limite pour ne pas avantager une connexion très lente. Les horodatages du client ne sont pas pleinement fiables; le serveur estime l’écart à partir des séquences et aller-retour. Les replays de test conservent entrées et ticks afin de reproduire un litige. Le mécanisme ne supprime pas le retard, mais rend explicite quelle version du passé arbitre l’action.

Je testerais avec latence artificielle, 5 % de pertes, paquets réordonnés et client hostile. Puis je regarderais correction maximale et budget serveur au 99e percentile. Le réseau ne peut pas livrer le présent; l’architecture choisit quelles actions prédire, lesquelles attendre et qui a le dernier mot.