我目前正在尝试构建一个本质上需要在服务器和每个客户端之间进行良好时间同步的应用程序。我的应用程序有其他设计可以消除这种同步需求，但是当我的应用程序不存在时，它很快就会开始崩溃。
万一我遗漏了一些东西，我的基本问题是:在同一时刻在多个位置触发一个事件。据我所知，这样做的唯一方法是需要某种时间同步，但是我可能是错的。我尝试过以不同的方式对问题进行建模，但全部归结为a)糟糕的应用程序，或者b)需要时间同步。
假设我真的真的需要同步时间。
我的应用程序基于Google AppEngine构建。尽管AppEngine无法保证其服务器之间的时间同步状态，但通常情况下，它是相当不错的，大约为几秒钟(即，比NTP更好)，但是有时会很糟，例如，大约浪费10秒同步。我的应用程序可以处理2-3秒的不同步，但是10秒对于用户体验来说是不可能的。因此，基本上，我选择的服务器平台无法提供非常可靠的时间概念。
我的应用程序的客户端部分是用JavaScript编写的。同样，我们也遇到客户也没有可靠的时间观念的情况。我没有进行任何测量，但是我完全希望我的某些最终用户的计算机时钟设置为1901、1970、2024，依此类推。因此，基本上，我的客户平台没有提供可靠的时间概念。
这个问题开始使我发疯。到目前为止，我能想到的最好的事情就是在HTTP之上实现类似NTP的功能(这听起来并不疯狂)。通过在Internet的不同部分中调试2或3台服务器，并使用传统方式(PTP，NTP)来尝试确保它们的同步至少在几百毫秒的数量级，这将起作用。
然后，我将创建一个JavaScript类，该类使用这些HTTP时间源(以及可从XMLHTTPRequest获得的关联往返信息)实现NTP交集算法。
如您所知，此解决方案也很费时间。它不仅非常复杂，而且只能解决一半的问题，即给客户一个很好的当前时间概念。然后，我不得不在服务器上做出让步，要么允许客户端根据他们发出请求的时间告诉服务器当前时间(安全性高，不可以，但是我可以减轻一些明显的滥用)，或让服务器向我的其中一个神奇的HTTP-over-NTP服务器发出单个请求，并希望该请求能尽快完成。
这些解决方案都糟透了，我迷路了。
提醒:我希望一堆Web浏览器(希望多达100个或更多)能够完全同时触发一个事件。
最佳答案
在我看来，您似乎需要在许多不同的地方收听来自服务器的广播事件。由于您可以接受2-3秒的变化，因此您可以将所有客户端置于长生命周期的 cometd 式请求中，而仅从服务器获得响应？在我看来，客户根本不需要这样处理时间吗？
您可以使用ajax来执行此操作，因此在等待新数据时应避免任何客户端锁定。
我可能在这里完全错过了一些东西。
关于time - 分布式时间同步和Web应用程序，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/432432/