Reseña del código fuente de Quake 3: modelo de red (2012)

Modelo de red

• El modelo de red de Quake 3 es una de las partes más elegantes del motor, y destaca que en entornos rápidos no vale la pena reenviar información que no fue recibida en la primera transmisión.
• Usa UDP/IP, y no utiliza la transmisión confiable de TCP/IP porque introduce latencia.
• La pila de red se amplía con dos capas mutuamente excluyentes: cifrado con claves previamente compartidas y compresión con claves Huffman precalculadas.
• Destaca un sistema del lado del servidor que minimiza el tamaño de los datagramas UDP mientras compensa la falta de confiabilidad de UDP.

Arquitectura

• El lado del cliente es simple: en cada frame envía comandos al servidor y recibe actualizaciones del estado del juego.
• El servidor debe propagar el estado maestro del juego a cada cliente y considerar la pérdida de paquetes UDP.
• Hay tres elementos principales: el estado maestro del juego, la transmisión de comandos del cliente mediante Netchannel, y snapshots almacenados en un arreglo circular con los 32 estados de juego más recientes.

Sistema de snapshots

• Cuando el servidor envía actualizaciones al cliente, siempre copia el estado maestro del juego al siguiente slot del historial del cliente y lo compara con otros snapshots.
• Si no hay un snapshot válido, usa un "snapshot dummy" para generar una actualización completa.
• Si el cliente confirma que recibió la actualización anterior, solo se envían actualizaciones parciales.
• Incluso si se pierde un paquete, se sigue el mismo proceso y se envían en un solo mensaje tanto la información no recibida antes como la nueva.

Resistencia en memoria y C

• Quake3 compara snapshots sin introspection, y la posición de cada campo se configura de antemano mediante arreglos y directivas del preprocesador.
• Usa la estructura netField_t para definir la posición y el tamaño de los campos, y con eso transmite las diferencias por la red.

Prefragmentación

• El módulo NetChannel divide los mensajes en chunks de 1400 bytes antes de enviarlos, lo que evita que los routers fragmenten los paquetes.
• La fragmentación en routers es costosa porque al entrar a la red bloquea el paquete y al salir de la red obliga a esperar todos los fragmentos.

Mensajes confiables y no confiables

• El sistema de snapshots compensa los datagramas UDP perdidos en la red, pero algunos mensajes y comandos deben entregarse sin falta.
• Esa garantía se abstrae mediante NetChannel.

[GN⁺]

Comentarios de Hacker News

• Este artículo es muy interesante, al igual que los anteriores. Pero mi trabajo actual es aburrido, así que no me queda energía para proyectos de hobby.
• Escuché por primera vez el término "isócrono" cuando salió FireWire, y se mencionaba para justificar el uso de UDP. Actualmente es una parte importante de las especificaciones de USB/Thunderbolt.
• Enlace al primer artículo de la serie: https://fabiensanglard.net/quake3/index.php
• La predicción y corrección de latencia es interesante, y no usa complejas transformaciones operacionales (OT). Es más simple, y el estado compartido necesita una fuente de verdad independiente, no un documento de edición colaborativa; además, el desarrollo es más rápido y el rendimiento es mejor.
• El código de red del cliente original de Q3A funcionaba bien en LAN, pero era sensible a la latencia en partidas remotas. Uno de los cambios interesantes de Quake Live fue un código de red actualizado para juego remoto. Las conexiones a Internet también han mejorado en general con el tiempo.
• Parece que el sitio está sufriendo el HN Hug of Death: <la conexión excedió el tiempo de espera>
• Es una buena lectura para una mañana de sábado, tomando mate despacio. Uno de los pequeños placeres de la vida.
• P: ¿Hay recursos para aprender enfoques modernos sobre protocolos de juegos en tiempo real?
• Supongo que los números de ID de snapshot también se envían al cliente para su verificación, ¿no?
• ¿Sigue existiendo middleware open source a prueba de balas?