Синхронизация часов клиента и сервера: оценивать время с учётом неопределённости

Сопоставить одни часы с другими

Сетевой игре нужна общая интерпретация временных меток событий, но исходно часы клиентов не совпадают. Используйте монотонные локальные часы для прошедшего времени и поддерживайте отображение в сессионное время сервера. Календарное время не требуется для многих событий матча. Смещение часов описывает разницу времени; дрейф — разницу темпа хода. Однократная синхронизация не устраняет последующий дрейф.

Явно обозначайте временную область в структурах данных. Метка сервера, метка локального ввода и задержанная метка отображения не взаимозаменяемы лишь потому, что все выражены в секундах.

Оценить смещение обменом временными метками

Пусть t1 — время отправки клиентом, t2 — приёма сервером, t3 — ответа сервера, а t4 — приёма клиентом. Если во время обмена часы идут почти с одинаковой скоростью, стандартная оценка равна offset = ((t2 - t1) + (t3 - t4)) / 2; знак соответствует серверному времени минус клиентское. Сетевая задержка туда и обратно равна delay = (t4 - t1) - (t3 - t2). Вычитание времени обработки сервером исключает этот интервал из времени сетевого пути. Такие отношения временных меток описаны в NTP. [1]

Расчётный пример: обработка и асимметрия путей

Возьмём условные метки 10.000, 10.260, 10.280 и 10.120 секунды в указанном порядке. Обработка на сервере занимает 0.020 секунды. Оценка сетевого пути туда и обратно составляет 0.120 - 0.020 = 0.100 секунды, а смещение — (0.260 + 0.160) / 2 = 0.210 секунды.

Оценка смещения предполагает симметричные задержки прямого и обратного путей. Пути длительностью 70 миллисекунд туда и 30 миллисекунд обратно дали бы ошибку этой оценки в 20 миллисекунд. Сам обмен не позволяет определить, какое направление внесло задержку. Короткий полный путь уменьшает часть неопределённости, но не доказывает симметричность путей.

Фильтровать измерения и осознанно применять поправки

Собирайте повторные выборки, сопоставляйте ответы с ожидающими запросами и отклоняйте данные устаревших сессий. Отслеживайте изменения задержки и разброс смещения. Mirror предоставляет синхронизированную оценку времени двойной точности, данные о полном пути и колебаниях измерений, а также описывает сглаживание экспоненциальным скользящим средним. Сохраняйте точность предоставленного типа времени. [2]

Фильтруйте шумные выборки вместо скачка игровых часов при каждом ответе. Решите, будут ли малые поправки постепенно менять отображение и как большой разрыв сбросит зависимые буферы. Монотонная игровая шкала не должна случайно идти назад при уменьшении оценки смещения. Повторно синхронизируйтесь после приостановки, переподключения или смены эпохи сервера; запрещайте сравнения несовместимых эпох.

Проверить потребителей времени

Тестируйте дрейф часов, долгие сессии, скачки времени обработки сервером и асимметричные соединения. Записывайте исходные выборки, отфильтрованные оценки и поправки раздельно. Разброс измерений не является гарантированной границей истинной ошибки смещения. Сервер по-прежнему должен проверять присланное клиентом время событий. Синхронизация даёт оценку времени; сама по себе она не выбирает задержку интерполяции, не разрешает действия в прошлом и не делает часы клиента авторитетными.

Источники

• [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.