我目前正在尝试构建一个应用程序,该应用程序本质上需要跨服务器和每个客户端进行良好的时间同步。我的应用程序有一些替代设计可以消除这种同步需求,但是当它不存在时,我的应用程序很快就会开始变得糟糕。
万一我遗漏了什么,我的基本问题是:同时在多个位置触发一个事件。据我所知,这样做的唯一方法需要某种时间同步,但我可能错了。我尝试以不同的方式对问题进行建模,但这一切都归结为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 服务器发出单个请求,并希望该请求足够快地完成。
这些解决方案都很糟糕,我迷路了。
提醒:我想要一堆网络浏览器,希望多达 100 个或更多,能够同时触发一个事件。