企业资料通讯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 可靠数据传输协定


<<:  Ubuntu巡航记(5) -- Kaldi 安装

>>:  Day 48. 下载个范例ios app来试着build

第39天~~又是JSON+动态增加按钮不是用XML

这篇的上一篇:https://ithelp.ithome.com.tw/articles/10283...

爬取多个页面

这次是要一次爬取多个页面的资料,延续抓取漫画资料的程序码。因为我知道每个漫画的路由後面都是编号,所以...

Android x Kotlin : EditText与软键盘常见设定

简介 editText有些常用设定,有时候会不小心忽略掉。虽然有些不是必备,但使用者体验的优化还是很...

Day 16 : 模型衡量指标

由於我们需要有指标来衡量一个模型的好坏,而问题可以粗略分成「分类」和「回归」问题。而根据不同的问题,...

【Day 18】Complexity & Graphs

接下来我们要针对复杂度做介绍,首先要说的就是高手们常常说的「Big O」! 但是到底什麽是 big ...