如果您的網絡的延遲是足夠低(或定時精度要求足夠寬鬆),您可以安全地忽略了網絡延遲,然後發送「在10秒內執行」命令就足夠了。當然,在這種情況下,您也可以等待10次發送,然後發送「立即執行」命令。
既然你問這個問題,但是,你可能想一個解決方案,還爲您提供了良好的同步定時,即使在高延遲或可變延遲的臉。要做到這一點,同步時鐘是唯一真正可靠的方法。如果兩臺計算機的時鐘是同步的,那麼你可以在任何時候(*)發送一個類似於「在下午3點2分執行此命令的命令」,然後確信遠程計算機將在3: 02 PM。 NTP可能足以滿足您的需求,或者如果您需要非常高的準確度(例如在幾微秒內),請檢查ptpd作爲替代選擇。
如果你不想進入正式的時鐘同步,但仍然希望比只希望你的網絡延遲小到可以忽略的東西更好,另一種方法是從一臺計算機向另一臺計算機發送測試消息經常。測試消息應在其數據負載中包含消息發送時發送計算機的當前系統時間,並且接收計算機應立即在該消息的回覆消息中逐字回顯該時間戳。當發送計算機收到回覆時,它可以從當前系統時間中減去回覆數據包中找到的時間戳,以計算估計的往返時間。將該值除以2,然後得出估計的單向跳閘時間,然後可以使用該時間修改延遲時間(希望)以補償網絡延遲。注意,這種方法有兩個缺點限制了它的準確性,但是:(1)它假設網絡延遲相對恆定(不一定是這種情況,尤其是在通過TCP發送數據的情況下,丟棄的數據包可能會導致偶然的顯着延遲尖峯由於重新發送和強制執行FIFO數據排序),以及(2)它假設網絡是對稱的 - 也就是說,在一個方向上的數據包大致與在另一個方向上返回的數據包相同的時間量;取決於網絡設置的方式,這個假設可能會也可能不會。
(*)好了,任何時候充分下午3點02分之前,當然,這裏的「充分之前」將是你的網絡的預期最壞情況等待時間的功能。
通常今天在互聯網上,你的是具有類似取決於跳的距離和數量的10至300毫秒包圓時間之旅。所以,如果你告訴客戶在10秒內開始,它可能是10,01到10,3秒。一般而言,網絡中的變化總是會產生很大的影響,當網絡運行良好時,預計它會成爲RTT的10%,而不是更多。在第二種情況下,任何同步都是浪費時間。 –
除非你通過衛星發送東西? :) – gabhijit