一種基於廣播通訊的時間同步方案猜想

2021-10-01 12:45:29 字數 1563 閱讀 2508

本方案只是猜想,未驗證。

因為網路時延,通常的時間同步方案都是基於雙向通訊,從而測出網路時延,但顯然雙向通訊相對於廣播通訊是很複雜的,在一些簡單的場景,也許我們不需要建立複雜的雙向通訊機制,只需要簡單的通知網內成員就行了。

那麼在廣播通訊中如何解決時延的問題呢?我們可以總結出,需要被同步的從機只需要知道當前的真實時間,更新自己的系統時間就可以了。而這個真實時間=主機同步時間+時延。主機同步時間是主機廣播訊息的傳送時間,是已知的,而時延是未知的。現在的問題便是是否在某種機制中可以得到這個時延資訊?

在這裡我們假定資料傳播途中的時間都是光速,是可以忽略的,而主要的時延來自於自己的機器傳送資料或接收資料的時間,換言之,對於每乙個機器而言,他自己的時延都是固定值。如果有中繼器,中繼器也應當被看作乙個從機來管理自己的時間。

假如每台機器都傳送兩個資料:[timestamp delay],同時在接收到任意其他機器發來的這個資料後做兩件事情:

所有機器的delay初始值都是0,在接收到資料後更新delay:delay_own = abs(timestamp_rev - timestamp_own)/2;

很顯然,我們應該先執行第二步,接下來執行第一步。

我們來考慮一下這樣會發生什麼:

圖1:

現在假設只有從機更新時間,主機不更新時間,那麼最終從機的時間必然趨於同步,但必然比主機有乙個延時,這個延時應該是距離主機最近的從機到主機的延時,即主機到a的延時1。

但這裡必然會因為時延對從機的不一致給這個同步機制中帶來比剛才更大的抖動因素,而這個抖動**於從機更新主機時間時主機到該從機時延的不一致,比如對從機a、b來說,主機給出的同步時間都是一樣的,但真實時間不一致,因此從機a、b更新的時間不會一致(因為從機自己的系統時鐘會將時延計算在內),從而帶來抖動。於是我們可以增加乙個資料位,從而消除從機對系統的影響,使從機可以很快的與主機時間同步。

我們可以修改資料位為[timestamp delay p],前兩個與之前一樣,增加乙個p表示權重,主機的權重高於從機,比方說主機為9,從機為1,那麼在接受到資料後需要做的事情改為:

從機:所有機器的delay初始值都是0,在接收到資料後更新delay:delay_own = abs(timestamp_rev - timestamp_own)/2;

主機:所有機器的delay初始值都是0,在接收到資料後更新delay:delay_own = abs(timestamp_rev - timestamp_own)/2;

現在考慮時延的問題,在沒有時延的情況下從機時間趨於一致穩定,而與主機時間有乙個穩定的偏差,那麼通過所有機器對delay的更新,必然可以使delay收斂於該偏差,從而消除主機的時延。

最後說明

xx_own表示己方系統變數,xx_rev表示接受資料中的變數。

本方案只是猜想,沒有經過實踐檢驗,同時很可能論證過程中有些地方有問題,所以僅供啟發參考使用。

給出的幾個計算公式可能會出現問題,此外很有可能會有更好的計算方法。

基於OkHttp的一種防抓包方案

最近在讀okhttp3.9.0的原始碼,在了解了其 機制之後發現了一種繞過 避免被抓包的方法。在介紹這種防抓包方法之前,需要先了解一下okhttp中socket連線建立的過程。由於這個過程比較複雜,我簡述一下,在建立socket連線之前,okhttp會獲取系統的 資訊,如果設定 那麼通過dns解析其...

基於OkHttp的一種防抓包方案

最近在讀okhttp3.9.0的原始碼,在了解了其 機制之後發現了一種繞過 避免被抓包的方法。在介紹這種防抓包方法之前,需要先了解一下okhttp中socket連線建立的過程。由於這個過程比較複雜,我簡述一下,在建立socket連線之前,okhttp會獲取系統的 資訊,如果設定 那麼通過dns解析其...

一種基於Modbus的工業通訊網關設計

近年來,隨著工業自動化領域的發展,工業現場對網路的可靠性及成本有極高的要求。傳統基於串列埠的工業閘道器可以滿足工業現場的應用,但卻要付出高額成本。一種基於 modbus 設計的工業通訊網關就走進人們的眼中,可以滿足現場匯流排可靠性和低成本的要求。佰馬bmg500工業物聯網閘道器,支援modbus協議...