Sincronização de relógio cliente-servidor: estimar o tempo sem esconder a incerteza

Mapear um relógio para outro

Um jogo em rede precisa de uma interpretação comum dos timestamps dos eventos, mas os clientes não começam com relógios idênticos. Use um relógio local monotônico para medir o tempo decorrido e mantenha um mapeamento para o tempo de sessão do servidor. Para muitos eventos de partida, a hora do calendário é desnecessária. O offset do relógio descreve uma diferença de tempo; a deriva (drift) descreve uma diferença de taxa. Sincronizar uma única vez não elimina a deriva posterior.

Mantenha o domínio de tempo explícito nas estruturas de dados. Um timestamp do servidor, um timestamp local de entrada e um timestamp de apresentação atrasada não são intercambiáveis só porque todos usam segundos.

Estimar o offset com uma troca de timestamps

Seja t1 o instante de envio no cliente, t2 o instante de recepção no servidor, t3 o instante da resposta do servidor e t4 o instante de recepção no cliente. Se os relógios avançarem quase à mesma taxa durante a troca, o estimador padrão é offset = ((t2 - t1) + (t3 - t4)) / 2, com a convenção de sinal "tempo do servidor menos tempo do cliente". O atraso de ida e volta da rede é delay = (t4 - t1) - (t3 - t2). Subtrair o tempo de processamento do servidor evita tratar esse intervalo como trânsito na rede. Essas são as relações de timestamps descritas pelo NTP. [1]

Exemplo prático: atraso de processamento e assimetria de caminho

Tome como exemplo os timestamps ilustrativos 10,000, 10,260, 10,280 e 10,120 segundos, nessa ordem. O processamento no servidor ocupa 0,020 segundo. O tempo estimado de ida e volta na rede é 0.120 - 0.020 = 0.100 segundo, e o offset é (0.260 + 0.160) / 2 = 0.210 segundo.

A estimativa de offset pressupõe atrasos simétricos na ida e na volta. Caminhos com 70 milissegundos na ida e 30 milissegundos na volta enviesariam essa estimativa em 20 milissegundos. A troca, por si só, não permite identificar em qual direção o atraso ocorreu. Um tempo de ida e volta pequeno reduz parte da incerteza, mas não prova que os caminhos eram simétricos.

Filtrar as medições e aplicar as correções de forma deliberada

Colete várias amostras, associe cada resposta à requisição pendente correspondente e descarte dados de sessões obsoletas. Acompanhe a variação do atraso e a dispersão do offset. O Mirror expõe uma estimativa de tempo sincronizado em precisão dupla, informações de ida e volta e a variação das medições, e documenta uma suavização por média móvel exponencial. Preserve a precisão do tipo de tempo fornecido. [2]

Filtre as amostras ruidosas em vez de fazer o relógio do gameplay saltar para o valor de cada resposta. Decida se as correções pequenas ajustam o mapeamento de forma gradual e como uma descontinuidade grande redefine os buffers dependentes. Uma linha do tempo monotônica do gameplay não pode retroceder por acidente quando a estimativa de offset diminui. Ressincronize após suspensão, reconexão ou mudança de época do servidor; invalide comparações entre épocas incompatíveis.

Validar os consumidores do tempo

Teste deriva de relógio, sessões longas, picos de processamento no servidor e enlaces assimétricos. Registre em log, separadamente, as amostras brutas, as estimativas filtradas e as correções. A variação das medições não é um limite certificado para o erro real de offset. O servidor ainda deve validar os tempos de evento informados pelo cliente. A sincronização fornece uma estimativa de tempo; ela não escolhe por si só um atraso de interpolação, não autoriza ações históricas e não torna o relógio de um cliente autoritativo.

Fontes

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