企业资料通讯Week7 (1) | rdt(reliable data transfer)[上]

rdt 可靠资料传输协定

由于运输层(transport)的下面那一层~网路层(network)的传输很不可靠，所以我们想了个rdt这个办法来解决资料资料在运输过程遗失或是错误。这里就从简单版本到複杂版本循序来说明。

看看下图，

sender端是called from above，意思是在传送端，上层的讯息往下传，receiver端就是called from below，从下面来的资料往上传。

开始之前的行前通知

如下图，我们等等用FSM 来说明rdt

说明:有event触发，使state(状态)改变，图中event下面一条横线后就是action(伴随的动作)

rdt1.0

最理想的假设(也最不切实际)，rdt1.0假设下面的传输非常可靠，不会出错或是资料遗失的发生。
如图，虚线箭头指的是初始状态，sender等上面的资料传上来，传完讯息下去就回原状态；receiver等待下方讯息到来，收完讯息之后往上传完就回原状态。

rdt2.0

该假设中有考虑到flip bits的出现，我们用checksum来侦错。
问题是我们如果找到错要怎么处理?这时我们有了回馈机制，正确无误时receiver传"ACK"(acknowledgement)；错误时传"NAKs"(也称"NACKs")，一旦接收NACKs，sender就重传该错误封包。

下图是rdt2.0的互动:

有没有想过，如果传送过程中，回馈也有可能出错?rdt2.0只有考虑到sender可能出错，但是没有考虑receiver出错!

要解决这个问题，出现了rdt2.1!

注:sender传送之后等待receiver这样的行为叫作"stop and wait"!

rdt2.1

它是怎么解决2.0的回馈时出现错误呢?
ACK或NACK 出错时，只要sender看不懂，sender就会重传该封包，如果是NACK发生错误还好，但如果是ACK发生错误，receiver不就重複收到两个一样的封包吗?事实上在rdt2.1有料到这件事情，因此sender会在封包上添加序号。如此receiver就会丢掉重複的封包。

看看下图，这是sender的状态图:

而这张是receiver的状态，课本的图需要上下两张交替看

下面是我对上面两张图合起来作流程的解释，如果看图就懂了可以直接跳过。

这里是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号回合结束。

rdt2.2

在rdt2.2，在回馈机制上我们把NACK省略掉，只留ACK。

机制与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 可靠数据传输协定