Sincronización de reloj cliente-servidor: estimar la hora sin ocultar la incertidumbre

Hacer corresponder un reloj con otro

Un juego en red necesita una interpretación común de las marcas de tiempo de los eventos, pero los clientes no parten de relojes idénticos. Usa un reloj local monotónico para medir el tiempo transcurrido y mantén una correspondencia con el tiempo de sesión del servidor. Para muchos eventos de una partida no hace falta la hora de calendario. El desfase del reloj (offset) describe una diferencia de tiempo; la deriva (drift) describe una diferencia de ritmo. Sincronizar una sola vez no elimina la deriva posterior.

Mantén explícito el dominio temporal en las estructuras de datos. Una marca de tiempo del servidor, una marca de tiempo local de una entrada y una marca de tiempo de presentación retrasada no son intercambiables solo porque todas se expresen en segundos.

Estimar el desfase con un intercambio de marcas de tiempo

Sean t1 el instante de envío en el cliente, t2 el instante de recepción en el servidor, t3 el instante de respuesta del servidor y t4 el instante de recepción en el cliente. Si los relojes avanzan a un ritmo casi idéntico durante el intercambio, el estimador estándar es offset = ((t2 - t1) + (t3 - t4)) / 2, con la convención de signo hora del servidor menos hora del cliente. El retardo de ida y vuelta de la red es delay = (t4 - t1) - (t3 - t2). Restar el tiempo de procesamiento del servidor evita tratar ese intervalo como si fuera trayecto de red. Estas son las relaciones entre marcas de tiempo que describe NTP. [1]

Ejemplo resuelto: retardo de procesamiento y asimetría de la ruta

Tomemos como marcas de tiempo ilustrativas 10.000, 10.260, 10.280 y 10.120 segundos, en ese orden. El procesamiento en el servidor ocupa 0.020 segundos. El viaje de ida y vuelta estimado de la red es 0.120 - 0.020 = 0.100 segundos, y el desfase es (0.260 + 0.160) / 2 = 0.210 segundos.

La estimación del desfase supone que los retardos de ida y de vuelta son simétricos. Si el trayecto de ida tardara 70 milisegundos y el de vuelta 30, esa estimación quedaría sesgada en 20 milisegundos. El intercambio por sí solo no permite identificar en qué dirección se produjo el retardo. Un tiempo de ida y vuelta pequeño reduce parte de la incertidumbre, pero no demuestra que las rutas fueran simétricas.

Filtrar las mediciones y aplicar las correcciones de forma deliberada

Recoge muestras repetidas, asocia cada respuesta con la solicitud pendiente que le corresponde y descarta los datos de sesiones obsoletas. Haz seguimiento de la variación del retardo y de la dispersión del desfase. Mirror expone una estimación del tiempo sincronizado en doble precisión, información del tiempo de ida y vuelta y la variación de la medición, y documenta un suavizado mediante media móvil exponencial. Conserva la precisión del tipo de tiempo suministrado. [2]

Filtra las muestras ruidosas en lugar de forzar el reloj de juego a saltar a cada respuesta. Decide si las correcciones pequeñas ajustan la correspondencia de forma gradual y cómo una discontinuidad grande reinicia los búferes dependientes. Una línea temporal monotónica de juego no debe retroceder por accidente cuando la estimación del desfase disminuye. Vuelve a sincronizar tras una suspensión, una reconexión o un cambio de época del servidor, e invalida las comparaciones entre épocas incompatibles.

Validar los consumidores del tiempo

Prueba la deriva del reloj, las sesiones largas, los picos de procesamiento del servidor y los enlaces asimétricos. Registra por separado las muestras sin procesar, las estimaciones filtradas y las correcciones. La variación de la medición no es una cota certificada del error real del desfase. El servidor debe seguir validando los tiempos de eventos que aporta el cliente. La sincronización proporciona una estimación del tiempo; no elige por sí misma un retardo de interpolación, no autoriza acciones sobre el pasado ni convierte el reloj de un cliente en autoridad.

Fuentes

• [1] Network Time Protocol Version 4: Protocol and Algorithms Specification — David L. Mills, Jim Martin, Jack Burbank y William Kasch, IETF RFC 5905.
• [2] Time Synchronization — colaboradores de Mirror Networking.