我有一个服务器 - 客户端应用程序,其中应用程序的一般用途是让一个客户端同时连接到多个服务器。客户端请求每个服务器开始在服务器本地记录数据,从某个DateTime
开始,某些TimeSpan
。发出请求后,客户端将断开与服务器的连接。然后,一段时间后,客户端重新连接到服务器以检索记录的数据。为了使客户端能够正确地解析记录的数据,所有服务器之间的时间参考必须匹配(在一定程度的准确度内,比如1秒)。
所以我需要能够在录制期间在该客户端引用的所有服务器上实现同步时间。
我不能保证服务器在线(它们可能只在本地局域网上),因此我不能让他们在UTC时间内调查一些互联网数据库。我无法保证客户端在整个录制过程中都能保持连接状态,因此我不能让客户端不断发送它作为参考的时间。
我认为这只留下一个选项:客户端必须告诉每个服务器它认为设置记录的时间是什么,服务器必须计算出该时间与他们认为时间之间的差异。然后,服务器必须将该增量应用于任何记录的数据。
我担心这种方法。是否会在很长一段时间内(例如10天)保持服务器的准确时间?如果其中一台服务器无法保持良好的时间,delta会随着时间的推移而漂移吗?
或者,有更好的方法吗?
答案 0 :(得分:1)
我不能让他们在UTC时间内调查一些互联网数据库... 然而,即使只是不时访问互联网UTC(例如NTP服务器)也可以得到一个估计当地时间与互联网UTC相比如何进展这基本上可用于在一段时间内预测offset
。典型的现代硬件显示每秒5至20微秒的漂移率。一些实施努力允许使漂移率达到约1微秒/秒的精度。因此,1 us / s的剩余“不准确度”将产生3.6毫秒/小时或~90毫秒/天的误差。
您的要求在一定程度的准确度内,例如1秒和长时间,比如10天可以通过这样的方案实现,偏差1 us / s累积到大约900 ms / 10天。
怎么做:(一个非常基本的描述)
这也可以在客户端完成。客户端不仅接收记录的数据,还接收服务器的时间戳。这样,客户端可以估计自上次请求处理以来服务器端经过的时间。它将服务器端的经过时间与客户端的经过时间进行比较,估算漂移率,并对记录的数据进行校正。这基本上可以在没有任何互联网UTC的情况下工作。
答案 1 :(得分:1)
您主要关注的是内部一致性,而不是绝对时间,所以:
答案 2 :(得分:1)
如果我正确理解您的任务,您需要测量从请求开始到数据收集结束的相对时间,即您必须知道何时收集了确切的某些数据。要解决此任务,您的服务器只需要跟踪其活动的相对时间(在Windows上,这可以使用GetTickCount函数完成,在unix上存在类似的函数)并记录自数据收集开始以来的相对时间。在客户端上,您只需添加客户端发送数据收集请求的绝对时间(您也可以将此时间存储在客户端上)。