iT邦幫忙

0

企業資料通訊Week7 (1) | rdt(reliable data transfer)[上]

rdt 可靠資料傳輸協定

由於運輸層(transport)的下面那一層~網路層(network)的傳輸很不可靠,所以我們想了個rdt這個辦法來解決資料資料在運輸過程遺失或是錯誤。這裡就從簡單版本到複雜版本循序來說明。

看看下圖,
https://ithelp.ithome.com.tw/upload/images/20211104/20135414uca5wtKe3X.png

sender端是called from above,意思是在傳送端,上層的訊息往下傳,receiver端就是called from below,從下面來的資料往上傳。

開始之前的行前通知

如下圖,我們等等用FSM 來說明rdt
https://ithelp.ithome.com.tw/upload/images/20211104/20135414wjV5T1vkFu.png
說明:有event觸發,使state(狀態)改變,圖中event下面一條橫線後就是action(伴隨的動作)

rdt1.0

最理想的假設(也最不切實際),rdt1.0假設下面的傳輸非常可靠,不會出錯或是資料遺失的發生。
如圖,虛線箭頭指的是初始狀態,sender等上面的資料傳上來,傳完訊息下去就回原狀態;receiver等待下方訊息到來,收完訊息之後往上傳完就回原狀態。
https://ithelp.ithome.com.tw/upload/images/20211104/20135414fOOPlWxwg1.png

rdt2.0

該假設中有考慮到flip bits的出現,我們用checksum來偵錯。
問題是我們如果找到錯要怎麼處理?這時我們有了回饋機制,正確無誤時receiver傳"ACK"(acknowledgement);錯誤時傳"NAKs"(也稱"NACKs"),一旦接收NACKs,sender就重傳該錯誤封包。

下圖是rdt2.0的互動:
https://ithelp.ithome.com.tw/upload/images/20211105/20135414IBqbfSATJu.png

有沒有想過,如果傳送過程中,回饋也有可能出錯?rdt2.0只有考慮到sender可能出錯,但是沒有考慮receiver出錯!
https://ithelp.ithome.com.tw/upload/images/20211105/20135414xAYmmbnw2W.png

要解決這個問題,出現了rdt2.1!

注:sender傳送之後等待receiver這樣的行為叫作"stop and wait"!

rdt2.1

它是怎麼解決2.0的回饋時出現錯誤呢?
ACK或NACK 出錯時,只要sender看不懂,sender就會重傳該封包,如果是NACK發生錯誤還好,但如果是ACK發生錯誤,receiver不就重複收到兩個一樣的封包嗎?事實上在rdt2.1有料到這件事情,因此sender會在封包上添加序號。如此receiver就會丟掉重複的封包。

看看下圖,這是sender的狀態圖:
https://ithelp.ithome.com.tw/upload/images/20211105/20135414Ljm8t1wyxF.png

而這張是receiver的狀態,課本的圖需要上下兩張交替看
https://ithelp.ithome.com.tw/upload/images/20211105/20135414osoCh2sI5U.png

下面是我對上面兩張圖合起來作流程的解釋,如果看圖就懂了可以直接跳過。

這裡是0號、1號兩種編號交替用。
(再提醒一次,從虛線箭頭開始)
一開始上面這一層傳0號封包下來,sender送第0號封包出去,進入等待回饋狀態;receiver收到,發現錯誤封包後回傳NACK,幸好receiver的NACK沒有出錯,sender收到回饋後重傳0號封包,進入等待回饋狀態,receiver收到正確的0號封包後往上面傳,並傳回ACK,sender收到ACK,於是0號這一輪結束,進入1號回合。

上面這一層傳1號封包下來,sender送第1號封包出去,進入等待回饋狀態;receiver收到,確認是正確的封包,但是在傳的過程它的ACK壞掉了,sender收到看不懂,於是又重傳一次1號封包,receiver收到,因為封包上有標序列,所以receiver知道那是重複的,把序列1的1號封包丟掉,傳ACK,這次sender收到的ACK是對的,1號回合結束。

https://ithelp.ithome.com.tw/upload/images/20211105/201354148YSxEO4Cvv.png

rdt2.2

在rdt2.2,在回饋機制上我們把NACK省略掉,只留ACK。
https://ithelp.ithome.com.tw/upload/images/20211105/20135414FwYMgc7NUh.png
機制與rdt2.1相似,但是在回應的ACK上有標輪次序號,因為這樣如果sender送的封包是錯的,sender就回「標有上一輪序號的ACK」,sender收到重複的ACK,它會重傳封包;如果sender送的封包是對的,sender就回「標有這一輪序號的ACK」,就沒事。例如:sender在第0輪錯了,receiver會回(ACK,1);sender在第0輪對了,receiver會回(ACK,0)。

不知道你有沒有發現,目前為止都沒有考慮到訊息遺失(loss)的情況
下一篇將會介紹如果考慮loss該怎麼處理,敬請期待囉!

參見:
CSDN|rdt 可靠數據傳輸協定


圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言