时间同步码

发布于 2024-08-09 12:25:37 字数 166 浏览 4 评论 0原文

我正在编写一些代码,需要知道客户端和单个服务器的时间有多少不同步。

我尝试通过在服务器托管的 SMB 共享上创建临时文件并读取其上次修改时间来实现此目的。我认为(也许是错误的)时间戳将由服务器而不是客户端生成。因为否则客户似乎真的会把事情搞砸。

有人可以确认这种行为或想出不同的方法吗?

I'm writing some code that needs to know how much out of sync the client and the single server's time are.

I'm trying to do it by creating a temp file on a SMB share hosted on the server and reading of its last modified time. I thought (maybe incorrectly) that the timestamp would be generated by the server and not the client. since it seemed like the client could really mess things up otherwise.

Can someone confirm this behaviour or come up with a different way of doing this?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

凹づ凸ル 2024-08-16 12:25:37

为什么不在客户端上获取纪元时间,并在客户端开始与服务器通信时将其发送到服务器,这样就不需要 smb 共享了。通过比较纪元时间,您将得到以秒为单位的时间偏移。可以使用rest/soap、套接字等在客户端和服务器之间进行通信,具体取决于您的客户端/服务器模型的外观。

Why not get the epoch time on the client and send that to the server when the client starts communication with the server, no need for smb share then. By comparing the epoch time against one another you will have your time offset in seconds. Can use rest/soap, socket, etc to communicate this between the client and server depending on what your client/server model looks like.

春风十里 2024-08-16 12:25:37

您可以将两者与公共 NTP 服务器同步,而不必担心。拥有(更)正确的时钟的额外好处!

You could synchronize both against a common NTP server and not worry about it. Added bonus of having a (more) correct clock!

谜兔 2024-08-16 12:25:37

我猜这里涉及的可变延迟(例如IO)是关键问题。您正在寻找多精细的测量方法?我也不确定这(严格来说)与Java有关。

无论如何,我认为你需要进行比较操作。

两台不同的机器正在写入共享设备(您的 SMB),并且每台机器都创建一个包含 他们的时代。理想情况下,为了最大限度地减少延迟问题,您可能希望在写入之前获取此纪元,然后立即关闭文件。

然后,客户端将自己的纪元和文件时间戳与服务器的文件及其纪元内容进行比较。这 4 个度量应该提供足够的信息来深入了解两个 JVM 纪元时间之间的相对差异。

[编辑以澄清]

例如,服务器的元组是({epoch,ts}):{S_t,SMB_ts},客户端的元组是{C_S_t,SMB_C_ts}。假设您得到(这里有趣的数字){5000, 4800} 和 {5100, 5000}。获取服务器时间戳和客户端时间戳之间的差异(此处为 4800 - 5000 => -200),并添加到客户端的纪元(此处为 5100+(-200)=>4900)。所以客户端比服务器落后 100 个单位。

[最终编辑]:(请注意,这里需要处理 3 个时钟:SMB、服务器和客户端。)

I guess the variable latencies involved (such as IO) here are the key issue. How fine a measure are you looking for? I am also not sure this is (strictly speaking) related to Java.

In any event, I think you need a comparative operation.

Two distinct machines are writing to a shared device (your SMB) and each creates a file which contains their epoch. Ideally, to minimize latency issues, you would want to obtain this epoch obtained just before you write and then immediately close the file.

The client then compares its own epoch and file timestamp to the server's file and its epoch content. These 4 measures should provide sufficient information to gain insight regarding the relative diff between the two JVM's epoch time.

[Edit to clarify]

For example, the server's tuple is ({epoch, ts}): {S_t, SMB_ts}, and the client {C_S_t, SMB_C_ts}. Lets say you get (funny numbers here) {5000, 4800} and {5100, 5000}. Take the diff between server's timestamp and client's stamp (here 4800 - 5000 => -200), and add to the client's epoch (here 5100+(-200)=>4900). So the client is 100 units behind the server.

[Final edit]: (Note that you have 3 clocks to deal with here: SMB's, servers', and the client's.)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文