zoukankan      html  css  js  c++  java
  • 理解GBN协议

    在理解GBN协议之前,先了解滑动窗口是怎么回事?
    在任意时刻,发送方都维持了一个连续的允许发送的帧的序号,称为发送窗口;同时,接收方也维持了一个连续的允许接收的帧的序号,称为接收窗口。发送窗口和接收窗口的序号的上下界不一定要一样,甚至大小也可以不同。不同的滑动窗口协议窗口大小一般不同。发送方窗口内的序列号代表了那些已经被发送,但是还没有被确认的帧,或者是那些可以被发送的帧。

    若从滑动窗口的观点来统一看待停等、后退n及选择重传三种协议,它们的差别仅在于各自窗口尺寸的大小不同而已。停等:发送窗口= 1,接收窗口=1; 后退n协议:发送窗口>1,接收窗口=1;选择重传协议:发送窗口>1,接受窗口>1;

    停等协议很好理解,这里主要解释后退n协议和选择重传协议。

    GBN协议中,发送方在发完一个数据帧后,连续发送若干个数据帧,即使在连续发送过程中收到了接收方发来的应答帧,也可以继续发送。且发送方在每发送完一个数据帧时都要设置超时定时器。只要在所设置的超时时间内仍未收到确认帧,就要重发相应的数据帧。如:当发送方发送了N个帧后,若发现该N帧的前一个帧在计时器超时后仍未返回其确认信息,则该帧被判为出错或丢失,此时发送方就不得不重新发送出错帧及其后的N帧。

    接受帧只允许按顺序接受帧。为了减少开销,累计确认允许接收端在连续收到好几个正确的确认帧后,只对最后一个数据帧发确认信息,或者可以在自己有数据要发送时才将对以前正确收到的帧加以捎带确认。这就是说,对某一数据帧的确认就表明该数据帧和这以前所有的数据帧均已正确无误地收到了。
    后退N帧协议的接受窗口为1,可以保证按序接受数据帧。若采用n个比特对帧编号,则其发送窗口的尺寸应满足:1~2(n-1)。若发送窗口的尺寸大于2(n-1),则会造成接受方无法分辨新帧和旧帧。(具体例子见书)

    SR协议是当接收方发现某帧出错后,其后继续送来的正确的帧虽然不能立即递交给接收方的高层,但接收方可收下来,存放在一个缓冲区中,同时要求发送方重新传送出错的那一帧。一旦收到重新传来的帧后,就可以原已存于缓冲区中的其余帧一并按正确的顺序递交高层。显然,SR减少了浪费,但要求接收方有足够大的缓冲区空间。

    若采用n比特对帧编号,为了保证接收方向向前移动窗口后,新窗口序号与旧窗口序号没有重叠部分,需要满足条件:接受窗口+发送窗口<=2n。假定仍然采用累计确认的方法,并且接受窗口显然不应超过发送窗口,那么接受窗口尺寸不应超过序号范围的一半<=2(n-1)。

        假设n取3,序号空间即0~7 (S:sender R:receiver)
    

    1、S 发送了0,1,2,3,4,5,6 号帧
    2、R 接受上述帧并且捎带发送 ACK6,但是丢失了
    3、S的0号帧首先超时,S 重发发送0号帧
    4、R收到0号帧,但是因为之前它已经接受0~6,发送了ACK6,它会认为0号帧是一个新的帧,而在0号帧之前的一个7号帧丢失(注意这里是一个环的结构)。因为是选择重传协议,R会接受0号帧( the old)作为新帧(暂时放在缓存区),并通知S重发7号帧。
    5、S 发送7号帧
    6、R接受了7和0号帧,并且发送ACK0

        这就出现了问题
    

    1、R接受错误的0号帧作为新的帧 
    2、S在发送完7号帧之后收到了ACK0,而不是ACK7,此时对于S而言,它的0号帧早已在ACK6中确认。

    出现这个问题的主要原因是我们不能区别新旧帧,现在我们将序号空间一分为二,首先发送0~3,继续上面的步骤。走到步骤4的时候R不会接受0作为新帧,因为R知道新的帧是4而不是0。这样就避免了上面的问题。

        先提个问题:回退N步协议中,如果接收方发送的ACK1丢失,ACK2到达发送方,这时还没有超时发生,发送方是否因为收到了 ACK2 就不会重新发送 帧 1了?
    

    我的答案是不会重发帧 1 。在累计确认中,即使ACK1丢失,但是在超时时间内接收到ACK2,那么发送方立即就知道1号帧已经被成功接收,只是对应的ACK1丢失而已,因此无需重传帧1。

    类似的这道题,发送发没有收到帧1的确认,但是却收到帧2、3的确认消息,说明此时还没有超时,在这超时时间内是依然可以收到后序帧的确认,一个原因可能是接收方发送帧1的确认,但丢在路上,另一个原因是“累计确认”即捎带确认,接受方根本没有发送帧1的确认,而是通过2、3帧的确认告诉我们帧1已经接收成功。

    所以,帧0、1、2、3均已正确接收到,需要重发的是4、5、6、7帧,答案选C。

  • 相关阅读:
    四则运算——结对编程
    《构建之法》第4章、第17章阅读与思考
    2016012063 小学四则运算练习软件项目报告
    基于《构建之法》的几个小见解
    结缘软件工程
    散列函数的应用及其安全性
    结对项目作业
    《构建之法》第四章第十七章阅读作业
    2016012048+小学四则运算练习软件项目报告
    读《构建之法》
  • 原文地址:https://www.cnblogs.com/yifeichongtian/p/10091235.html
Copyright © 2011-2022 走看看