Есть ли алгоритм для оценки перекоса часов, который будет работать над Http?

Question

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

Беда в том, что я видел ситуации, когда часы не точные - они могут выйти за пару секунд. Поэтому я хотел бы оценить, насколько часы телефона отличаются от времени сервера. Конечно, нужно учитывать задержку в сети, в частности, поскольку единственный открытый мне сетевой протокол - Http.

Итак, мой вопрос: кто-нибудь знает алгоритм, который я могу использовать для оценки разницы во времени между клиентом и сервером с точностью около 100 мс?

Из моих дней бакалавриата по математике я, кажется, помню, что существовала статистическая модель, которая могла бы использоваться в этой ситуации, когда мы выбираем значение, которое, как предполагается, состоит из константы плюс величина ошибки (задержка) это можно предположить, чтобы следовать некоторому распределению. Кто-нибудь знает об этом, и действительно ли это применимо?

Answer 1

Алгоритм Кристиана (обнаруженный в презентации, связанной с ответом ааа ) оказался именно тем, что мне было нужно.

В моем блоге есть полная (и довольно элегантная, если я так говорю!) Реализация с использованием WCF Rest на стороне сервера и RestSharp и Reactive Framework на стороне клиента.

Вот выдержка из в блоге , объясняющая алгоритм:

1. Клиент отправляет сообщение на сервер: «Сколько времени?» [добавив г-нВолк не является обязательным.Важно отметить, что он отмечает время, когда он отправил сообщение (назовите его T _sent )
2. Сервер отвечает так быстро, как может, давая время в соответствии со своими часами, T _сервер .
3. Когда Клиент получает сообщение, он отмечает время получения (назовите его T _{полученный} ).Затем он выполняет некоторые математические расчеты: время приема-передачи, RTT, равно T _{, получено} - T _{, отправлено} .Если предположить, что сервер отреагировал мгновенно и задержка в сети была одинаковой в обоих направлениях, это означает, что сервер фактически отправил сообщение RTT / 2 секунды назад.Таким образом, в момент, когда Клиент получает сообщение, время на сервере равно T _server + RTT / 2.Затем Клиент может сравнить со своими часами и определить разницу - перекос часов.

Answer 2

Не статистическая модель / алгоритм, но ...
Я бы сделал это, записав время, затраченное на вызов сервера и получив ответ.

Тогда я быиспользуйте половину этого количества времени (при условии, что для отправки запроса и ответа требуется столько же времени), чтобы оценить любую разницу.Я передал бы значение половинного временного интервала серверу с фактическим временем устройства и позволил бы серверу отработать любую разницу (учитывая это смещение половинного временного интервала).

Это предполагает, что второй вызов серверу (один с половиной временного интервала) занимает столько же времени, сколько первый (синхронизированный) запрос.Это может скомпрометировать веб-ферму, балансировщик нагрузки или неравномерную нагрузку на сервер.
Убедитесь, что ваши методы выполнения этого процесса делают как можно меньше, чтобы избежать дополнительных задержек.

Вы можете попробовать сделать несколько вызовов ииспользуя среднее время для учета различного времени запроса.Поэкспериментируйте, чтобы понять, стоит ли это того.

Все зависит от того, насколько точные вещи вам нужны.Если вам действительно нужна (почти) идеальная точность, вам может не повезти.