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

rdt3.0

rdt3.0 开始考虑到packet loss的情形，它怎麽解决呢?

喔喔~原来是采用"倒数计时"的方式，sender每送一个封包就会设定一个timer，如果超过时间还没收到receiver的回馈，sender就会重传该封包。如果receiver有回馈，但可能因为网路太慢使得ACK迟到sender会如何?sender还是重传啊!於是receiver就会收到重复的封包，不过没关系，有sequence number就可以辨认哪个是重复的封包。

注意这里，rdt3.0的重传机制只绑定在timer身上，可以看红色圈起来的地方(图中描述ACK坏掉或是ACK编号错误)

这里也是rdt2.2与rdt3.0另外一个差别，这个意思是回馈如果是错的sender也不重传、不停止倒数，直等到timerout才重传(rdt2.2收到错误的回馈就会重传)。

几种状况

下图分别为正常情况与sender packet loss

sender 等到timerout 重传

而这是ACK中途loss

sender 等到timerout 重传，receiver收到重复的封包，於是再传一次ACK。

这是回馈晚到的情形，比较复杂一点，这会导致双方的时间不一致，所以会多送几次封包与ACK

rdt3.0性能

它也是采用 stop and wait 的方式，中间在等回馈的时候sender除了倒数计时之外都没做事。

注:1RTT 大约等於两个propagation delay(sender发出封包的最後一个bit到sender收到ACK的时间)；L/R 是 transmition delay
注意receiver要等到收到最後一个packet的bit才会发出ACK。

假设RTT是30，sender完整发出一个封包是0.008所以一个回合sender使用效率只有0.008/30.008，使用率很差。
怎麽改良呢?请继续看~

Pipelined protocols

所以我们又想到一个方法，如果一次可以送很多封包就不用花时间等那麽多次了!
使用"in flight"(在途，就是还未被确认的packet)的概念。
有两个特色:

它有一个未被确认封包的上限 N (WindowSize)
有buffering(缓冲)机制
Pipelined protocols 主要分两类:(1)go-back-N (2)selective repeat
如果在理想的状态下，它的使用效率可达100%，因为可以一边传一边收。

1.go-back-N (GBN)

下图的框框是一个WindowSize

每一根长长的代表一个segment(请容我叫它封包QUQ)

绿色的是送出且被checked部分
黄色的是已经送出但还没被checked部分
框框内蓝色的是还没被送出，但还可以再送的空间
白色的是还不能送的，因为go-back-N对於未确认的封包有WindowSize的上限

名词解释:

send_base:最老的未被确认封包
nextseqnum:下一个准备要传的封包

go-back-N 特色

timer: 这go-back-N的 timer 会设定在send_base上面，并等待receiver 送 ACK(n)。
cumulative ACK: 甚麽是ACK(n)?
举个例子，如果ACK(7)就代表第七个封包以下(包含)都没问题，所以这也称**“cumulative
ACK”**!
timeout的处理:sender会从send_base直到最後的未确认封包都重送，如果Window是满的就会重送N个封包(最糟的状况)，这也是为甚麽它叫go-back-N。
如果中间有缺失:举例，8号封包不见了，但是sender送的9、10、11都是正常的，receiver还是只会一直送ACK(7)。
之後window满的就不能送、卡在那里等timeout，从8号封包到 8+N-1号封包都会重送。