Распределенная синхронизация времени и веб-приложения

Мне кажется, что вам нужно прослушивать широковещательное событие с сервера во многих разных местах. Поскольку вы можете принять 2-3-секундные вариации, вы можете просто поместить всех своих клиентов в долгоживущие запросы в стиле комет и просто получить ответ от сервера? Мне кажется, клиентам не нужно было бы иметь дело со временем таким образом?

Для этого вы можете использовать ajax, чтобы избежать блокировок на стороне клиента при ожидании новых данных.

Возможно, я здесь чего-то полностью упускаю.

Позвольте мне подвести итог, чтобы убедиться, что я понял вопрос.

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

Если предположить, что я более-менее точно описал ситуацию:

Можете ли вы сделать так, чтобы серверы сохраняли определенное состояние для каждого клиента (например, начальное время соединения - время сервера), и когда известно время события, которое должно произойти, уведомить клиента сообщением, содержащим количество миллисекунд после начального значения, которое должно пройти до запуска события?

Проиллюстрировать:

   client A connects to server S at time t0 = 0
   client B connects to server S at time t1 = 120
   server S decides an event needs to happen at time t3 = 500
   server S sends a message to A:
   S->A : {eventName, 500}
   server S sends a message to B:
   S->B : {eventName, 380}

Это вообще не зависит от времени клиента; просто от способности клиента отслеживать время в течение некоторого достаточно короткого периода (один сеанс).

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

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

Если вы можете предположить, что часы достаточно стабильны, то есть они установлены неправильно, но тикают с более или менее правильной скоростью.

Пусть серверы получают свое смещение из одного определенного источника (например, одного из ваших серверов, или сервера базы данных, или чего-то еще).

Затем попросите каждого клиента вычислить его смещение от своего сервера (возможные сложности с двусторонним обменом, если вам нужна большая точность).

Сохраните это, а затем вы объедините смещение для каждого клиента, чтобы вызвать событие в нужное время.

(client-time-to-trigger-event) = (scheduled-time) + (client-to-server-difference) + (server-to-reference-difference)

Google нашел способ определить время как абсолютное. Это звучит еретично для физика и по отношению к общей теории относительности: время течет с разной скоростью в зависимости от вашего положения в пространстве и времени, на Земле, во Вселенной ...

Вы можете ознакомиться с базой данных Google Spanner: http://en.wikipedia.org/wiki/Spanner_(database)

Я предполагаю, что сейчас он используется Google и будет доступен через Google Cloud Platform.