Revue du code source de Quake 3 : le modèle réseau (2012)

Le modèle réseau

• Le modèle réseau de Quake 3 est la partie la plus élégante du moteur, car il met en avant l’idée que, dans un environnement rapide, une information non reçue lors du premier envoi ne vaut pas la peine d’être retransmise.
• Il utilise UDP/IP, et n’emploie pas le transport fiable de TCP/IP, car celui-ci introduit de la latence.
• La pile réseau est étendue par deux couches mutuellement exclusives : le chiffrement avec clé pré-partagée et la compression avec une clé Huffman précalculée.
• Le système côté serveur se distingue par sa capacité à compenser le manque de fiabilité d’UDP tout en minimisant la taille des datagrammes UDP.

Architecture

• Le côté client est simple : à chaque frame, il envoie des commandes au serveur et reçoit des mises à jour de l’état du jeu.
• Le serveur doit diffuser l’état maître du jeu à chaque client, tout en tenant compte des pertes de paquets UDP.
• Trois éléments principaux : l’état maître du jeu, la transmission des commandes du client via Netchannel, et des snapshots stockés dans un tableau circulaire de 32 états récents du jeu.

Système de snapshots

• Lorsque le serveur envoie des mises à jour au client, il copie toujours l’état maître du jeu dans le prochain emplacement d’historique du client, puis le compare aux autres snapshots.
• S’il n’existe pas de snapshot valide, il utilise un "snapshot factice" pour générer une mise à jour complète.
• Lorsque le client confirme avoir reçu la mise à jour précédente, seules des mises à jour partielles sont envoyées.
• Même en cas de perte de paquets, le même processus est suivi, en envoyant dans un seul message les informations précédemment non reçues et les nouvelles informations.

Résilience mémoire et C

• Quake3 compare les snapshots sans introspection, et la position de chaque champ est préconfigurée via des tableaux et des directives du préprocesseur.
• La structure netField_t est utilisée pour définir la position et la taille des champs, puis pour transmettre les différences sur le réseau.

Pré-segmentation

• Le module NetChannel découpe les messages en blocs de 1400 octets avant l’envoi, ce qui évite que les routeurs fragmentent les paquets.
• La fragmentation par les routeurs est coûteuse, car elle peut bloquer les paquets à l’entrée du réseau et oblige à attendre tous les fragments à la sortie.

Messages fiables et non fiables

• Le système de snapshots compense les datagrammes UDP perdus sur le réseau, mais certains messages et certaines commandes doivent impérativement être livrés.
• Cette garantie est abstraite via NetChannel.

[GN⁺]

Avis Hacker News

• Cet article est très intéressant, comme les précédents d’ailleurs. Mais mon travail actuel est ennuyeux, donc il ne me reste plus d’énergie pour des projets perso.
• J’ai entendu le terme « isochrone » pour la première fois à l’arrivée du FireWire, où il était mentionné pour justifier l’usage de l’UDP. C’est aujourd’hui un élément important dans les spécifications USB/Thunderbolt.
• Lien vers le premier article de la série : https://fabiensanglard.net/quake3/index.php
• La prédiction et la correction de latence sont intéressantes, et cela n’utilise pas de transformations opérationnelles (OT) complexes. C’est plus simple, cela suppose qu’un état partagé a besoin d’une source de vérité indépendante plutôt que d’un document d’édition collaborative, et c’est plus rapide à développer avec de meilleures performances.
• Le code réseau du client Q3A d’origine fonctionnait bien en LAN, mais il était sensible à la latence pour le jeu à distance. L’un des changements intéressants de Quake Live a été la mise à jour du code réseau pour le jeu à distance. Les connexions Internet se sont aussi globalement améliorées avec le temps.
• On dirait que le site subit l’effet HN Hug of Death : <connexion expirée>
• C’est le genre d’article idéal à lire un samedi matin en sirotant doucement un maté. Un petit plaisir de la vie.
• Q : existe-t-il des ressources pour apprendre les approches modernes des protocoles de jeu en temps réel ?
• J’imagine que le numéro d’identifiant du snapshot est lui aussi envoyé au client à des fins de vérification ?
• Existe-t-il encore un middleware open source vraiment à toute épreuve ?