Как на udp сервере подсчитать one-way latency и верменной offset клиента?

Question

[Владимир]

Я с каждым пакетом к клиенту я на сервере сохраняю его серийник + timestamp отправки и отправляю серийный номер этого пакета.
А клиент при получении ставит timestamp получения и возвращает серверу.
Получив пакет с клиента. Сервер знает время отправки, время получения на клиенте и время получения ответа с клиента.
Но что если ЧАСЫ на клиенте медленнее/бестрее чем на сервере? Нет гарантии что они одинаковые.
Как серверу мониторить one-way latency и верменной offset клиента?

Answer 1

[Сергей Соловьев]

То что причина в часах понятна. Я вижу тут несколько решений:
1. Синхронизация часов клиента. Возможно какой-нибудь NTP поможет (не работал с ним). Но синхронизировать надо только клиента, т.к. если сервер затронет, то и других клиентов тоже
2. Использовать глобальный синхронизатор (время по gps синхронизировать)
3. Делать бенчмарки + вычисления

Насчет 3 -
1. Предполагаем, что в обе стороны время одинаковое
2. Делаем несколько замеров (например, можно каждые 100 пакетов)
3. Рассчитываем время как avg / 2 , где avg - это среднее время отправки в обе стороны

Answer 2

[Wataru]

Надо клиенту в пакете отправлять время получения и отправления в пакете.

В итоге сервер получит 4 таймстампа: сервер отправил, клиент получил, клиент отправил, сервер получил. При этом два серверных и два клиентских - могут быть в разных часах. Поэтому надо взять t4-t1+t2-t3 - и вы получите rtt. Поделите на 2, получите оценку нужной задержки. И это надо сглаживать по многим пакетам.

Проблема будет, если часы тикают с разной скоростью, а не просто отстают на фиксированное время. Это надо смотреть на динамику t2-t1. Если там линейная регрессия с отличным от 1 коэффициентом получается, то надо это учесть и делить на этот коэффициент t2-t3 в формуле. Но это редко делают. Если время обработки пакета клиентом мало по сравнению с сетевой задержкой, то лишь малая часть этого времени пойдет в ответ ошибкой.

Однако, если вы часы синзронизируете, то вам надо постоянно пересчитывать отставание по последнему пакету и оценке rtt. И этот сдвиг часов будет изменятся со временем а соответствии с разной скоростью часов.