Rdt2.1 和 Rdt2.2的详细解释

Rdt2.1 和 Rdt2.2的详细解释

🌵可靠数据传递中Rdt1.0, Rdt2.0, Rdt3.0 都很好理解,但是就是这两个毒瘤一直在我脑袋里面刺痛着我,经过一段时间的总结,我相信我能给大家一个比较好理解的解释。

这俩为啥会出现?

既然大版本好是2.0,我们可以回忆一下2.0阶段做了什么事情
Rdt2.0中增加了检验纠错的结构,也就是应答。

sequenceDiagram
sender -->> receiver: 发送消息(备注:你看看对不对?)(跳转到等待态)
receiver -->> sender: 啊对对对,这玩意是我想要的(receiver验货,正常ACK返回)
sender -->> sender: 爷终于放心了,可以发下一个了(状态回溯到初始状态)
receiver -->> sender: 不对啊,我不收(异常NAK)
sender -->> receiver: 重发

按理来说这个过程非常自然啊,receiver检验,sender等待,整个流程走完了,数据也发出去了,如果数据异常,sender也能够重发,但是问题就在于,如果象征着异常数据的标志NAK也错了,象征着正常数据的ACK也错了,sender该如何判断????它唯一的相信的东西没了!!这个流程自然说不通了。

上述流程要完美发生就必须要求ACK,NAK绝对不能出错

可以事实上,非常容易出错,好在我们还是有解决办法的

解决之道

书中给出了三条解决之道:

  1. 通过另外的响应规则来应对突发情况,但是这个策略很明显有问题,如果另外的响应也错了怎么办?,所以书中没有考虑这个策略
  2. 加一堆校验码,让NAK,ACK拥有自我救赎的能力(自己把自己纠正过来,即使错了),可行,但是划不来,新的校验数据无疑会增大报文的体积,减低传输的效率
  3. 冗余报文响应(这个名字是我按照我的理解起的,建议以书为标准 - 重发):故名思义
graph LR
ACK不合法 --> 重发
NAK不合法 --> 重发
NAK拒绝 --> 重发
重发 --> 直到格式合法了数据正常了
Rdt 2.1

Rdt2.1 和 Rdt2.2的详细解释插图

Rdt2.1 和 Rdt2.2的详细解释插图1

从发送端入手,虚线部分:

发送端先是不管三七二十一把数据封装起来了,然后填上了0标志位和校验和发送到发送端,自己进入等待状态。

此时接收到来自发送端的数据,接收端也从等待状态进入到wait for 1 from below, 并且向发送发抛出了一个数据,内部有ACK,表示接受

如果接收方接受到了这个完整的ACK,那么就是Rdt2.0的节奏了,这里假设ACK错了,不合法,由于接收方接收到了一个不合法的数据,那么自然就重发

此时接收方还在等待1状态,一检查,发现发送发又给我发了一份数据,那我没办法啊,只能又发一个ACK回去,

如此往复直到发送方接收到数据之后,状态转移,向接受发发送了一个带有1的报文,若接受方也能接受,那么就皆大欢喜了

接受方和发送方都回到了最初状态了,一次传递结束了!!!

很容易不是吗?

注意点:发送发和接收方都在考验彼此,一旦对面的数据给的不合法,或者发现了错误,就会通知对方,让对方重发一次,直到双方通信完成,状态回到初始态时候终止。

也许你会问,那这种等待,想Rdt2.0 那样不是也行吗?为啥得这样做呢,这么多状态,不会眼花吗?

其实这两个状态是有道理的,

Rdt2.0 中接受方只有一个状态,就是初始态,但是初始态无法辨识当前接收方是否出现了问题,所以必须给接收方多安排一个状态。

如此发送方也必须调整一下,

发送方从 0 - 1 - 0

接收方也从 0 - 1 - 0

当其中一方或者几方处于1状态时,必然意味着出现了意外状况,就可以实现干预了。

Rdt2.2

Rdt2.2 的思想与Rdt2.1 是相同的,只是简化了步骤,其实根本不需要发NAK,只需要发ACK,区别在于带上不同的标志以区分不同的阶段

graph LR
NAK --> ACK_0
NAK不合法
ACK --> ACK_1

如此就简化了既要判断ACK,又要判断NAK的复杂场面,

只要报文不合法就重发只要ACK 带的值不是我想要的,你也得给我重发!!

文章来源于互联网:Rdt2.1 和 Rdt2.2的详细解释

THE END
分享
二维码