Mensajes de juego fiables y no fiables: elegir las garantías según su significado

Clasificar las consecuencias de la pérdida

El modo fiable de un transporte retransmite los datos perdidos mientras la conexión siga siendo viable; la entrega no fiable puede perder mensajes. El orden es una propiedad distinta que una API puede combinar con la fiabilidad. Las garantías deben elegirse según el significado del mensaje: un estado de posición completo y más reciente puede sustituir a uno anterior, mientras que una solicitud de compra necesita un resultado definitivo, aceptada o rechazada. Ninguna de las dos categorías determina si el servidor debe confiar en el contenido del mensaje.

Separar los acuses de recibo de paquetes de los resultados de las acciones

Los números de secuencia identifican paquetes o mensajes dentro del flujo para el que se definen. Un acuse de recibo de paquete indica que los datos del transporte llegaron; no demuestra que el juego haya validado o confirmado (commit) una acción. El análisis de protocolos de Fiedler explica además por qué la falta de acuses de recibo genera incertidumbre y por qué los datos de aplicación repetidos necesitan su propia identidad. [1]

Asigna a los comandos importantes un identificador con alcance definido y devuelve un resultado de aplicación. Si los reintentos o la recuperación tras una reconexión pueden repetir un comando, conserva su resultado durante la ventana de reintentos admitida. Valida la solicitud y registra de forma coherente su efecto y el resultado de la deduplicación. Un socket fiable por sí solo no garantiza una ejecución exactamente una vez ante caídas.

Ejemplo práctico: estado antiguo y comando repetido

Supongamos que el estado de movimiento completo 41 sitúa a un avatar en la coordenada 8 y que el estado 42 lo sitúa en la coordenada 9. Si el 42 llega antes que el 41, un receptor basado en la actualidad conserva la coordenada 9 y descarta el estado más antiguo. Esta política exige actualizaciones autocontenidas o una base de reconstrucción válida; descartar deltas arbitrarios puede impedir reconstruir el estado.

Por otro lado, un cliente envía el comando 17 para recoger un objeto. El servidor lo valida, entrega el objeto y registra el resultado. Si el comando 17 se reintenta porque se perdió la respuesta de la aplicación, el servidor devuelve ese resultado registrado sin entregar otro objeto. El identificador del comando y la secuencia de movimiento resuelven problemas distintos y no deben compartir semánticas por accidente.

Aislar las dependencias de orden y presupuestar el tráfico

La entrega fiable y ordenada puede retener mensajes posteriores detrás de un mensaje anterior perdido dentro del mismo flujo. Los carriles de conexión (connection lanes) de Valve permiten que el tráfico independiente no comparta esa dependencia de orden: los mensajes fiables se ordenan dentro de un carril, sin garantía equivalente entre carriles. Nunca repartas entre carriles operaciones con dependencia causal sin gestionar esa dependencia de forma explícita. [2]

Si el transporte lo permite, mantén el estado transitorio separado de las transferencias voluminosas. Limita las colas de envío, supervisa la antigüedad de los mensajes y deja que el control de congestión regule el ritmo del tráfico. Encolar repetidamente estados fiables ya obsoletos puede generar un retraso creciente aunque la entrega acabe funcionando. El estado aún no enviado solo debe compactarse o sustituirse cuando su semántica lo permita.

Probar el contrato de entrega

Inyecta pérdida, duplicación, reordenamiento y desconexiones. Comprueba el rechazo de estados obsoletos, la deduplicación de comandos, los límites de las colas y la recuperación tras reconectar. Define el alcance de los identificadores, el tratamiento del desbordamiento (wrap) de la secuencia y durante cuánto tiempo siguen disponibles los resultados. La fiabilidad no puede hacer útil un comando caducado, autorizar una solicitud inválida ni garantizar la finalización tras una desconexión permanente. Expón al juego los resultados pendientes, confirmados y fallidos cuando esas distinciones importen.

Fuentes

• [1] Reliability and Congestion Avoidance over UDP — Glenn Fiedler, Gaffer On Games.
• [2] GameNetworkingSockets Interface: Message Delivery and Connection Lanes — Valve Software, fuente original de la API.