2013-10-22 88 views
0

我有一个服务器 - 客户端应用程序,其中应用程序的一般用途是让一个客户端同时连接到多个服务器。客户端请求每台服务器开始在服务器本地开始记录数据,从DateTime某些TimeSpan开始。提出请求后,客户端与服务器断开连接。然后,一段时间后,客户端重新连接到服务器以检索记录的数据。为了让客户正确解析记录的数据,所有服务器之间的时间参考必须匹配(在某种合理的准确度内,比如说1秒)。跨多台计算机的DateTime同步

所以我需要能够实现在记录期间该客户端引用的所有服务器的同步时间。

我不能保证服务器在线(它们可能只在本地局域网上),因此我不能让它们在UTC时间轮询一些互联网数据库。我无法保证客户在整个录音过程中都保持连接,因此我不能让客户不断地发送时间作为参考。

我想这只剩下一个选项:客户端必须告诉每个服务器它认为时间是什么时候设置记录,服务器必须找出当时和他们认为时间之间的差异。然后服务器必须将该增量应用于任何记录的数据。

我担心这种方法。它会在很长一段时间内保持准确的时间,比如10天吗?如果其中一台服务器无法保持良好时间,三角洲能否随时间漂移?

或者,有没有更好的方法来做到这一点?

+0

我建议你重新考虑一下你的vasic假设:你想要电脑,可能无法正确保持时间,做出基于时间的desicions。还是我得到这个错误? –

+0

我完全同意。不幸的是,我无法控制安装我的软件的硬件。硬件有可能是坏的CMOS或者无法保持时间。在没有互联网连接的情况下保持准确的时间实际上并非微不足道。漂移的百分比可能会惊人地高。 –

+0

这就是我的意思:如果你不能保证计时,你不能保证准确的时间desicions。 –

回答

1

如果我正确理解你的任务,你需要从请求开始测量相对时间数据的结尾收集,即你必须知道何时收集到完全确定的数据。为了解决这个任务,你的服务器只需要跟踪他们活动的相对时间(在Windows上,这可以使用GetTickCount函数来完成,在unix上存在类似的功能),并记录数据收集开始以来的相对时间。在客户端上,您可以添加客户端发送数据收集请求的绝对时间(也可以将这次存储在客户端上)。

1

我不能让他们为UTC时间轮询一些互联网数据库......但是,即使只是有时间访问互联网UTC(例如NTP服务器),也可以估计本地与互联网UTC相比,时间进步更快。这可以基本上用于在一段时间内预测offset。典型的现代硬件显示每秒5到20微秒的漂移速率。一些实施工作可以使漂移率达到大约1微秒/秒的精确度。因此,1 us/s的剩余“不准确性”将产生3.6 ms /小时或〜90 ms /天的误差。

你的要求准确性的一些合理的程度内,说了很长一段时间1秒,说10天可以用这样的方案,1我们的偏差满足/ s的积累到大约900毫秒/ 10天。

如何做到这一点:(一个非常基本的描述)

  • 收集互联网UTC(NTP服务器)时,有机会获得网络连接。
  • 建立本地UTC和互联网UTC对。
  • 预测漂移率(使用数学来提高其准确度,例如平均值,异常值拒绝等)
  • 将漂移率校正应用于您的数据包。

这也可以在客户端完成。客户端不仅接收记录的数据,还接收服务器的时间戳。通过这种方式,客户端可以估计自上次请求处理以来在服务器端花费的时间。它将服务器端的流逝时间与客户端流逝的时间进行比较,估计漂移率,并对记录的数据进行校正。这基本上没有任何互联网UTC的工作。

1

您主要关注内部一致性,而不是绝对的时间,所以:

  1. 设置NTP服务器的局域网。
  2. 让所有基于局域网的机器从此同步。
  3. (可选:得到这个NTP服务器从INET进行同步时,它连接。)