文档章节

理解GBN协议

o
 osc_gfpedeca
发布于 07/01 08:34
字数 1560
阅读 24
收藏 0

精选30+云产品,助力企业轻松上云!>>>

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

o
粉丝 0
博文 68
码字总数 0
作品 0
私信 提问
加载中
请先登录后再评论。
tcp是一个复杂的协议

tcp是一个很复杂的协议,这是每个人都知道的,但是它是很重要的,超过半数的公司在应届生面试时会提供tcp三次握手的面试题,我当年就碰到了N次,只可惜我对网络比较了解,这件事几乎没有给我...

晨曦之光
2012/04/10
134
0
程序员内功修炼(三)计算机网络之数据链路层

1、数据链路层功能概述 一、数据链路层功能概述 二、数据链路层基本概念 三、数据链路层功能概述 2、封装成帧&透明传输 一、数据链路层功能概述 二、封装成帧 三、透明传输 四、字符计数法 ...

程序员内功修炼之路
02/13
33
0
【计算计网络】可靠数据传输原理2(流水线可靠数据传输协议)

流水线可靠数据传输协议   如上篇文章所述所述的rdt3.0协议是一个功能正确的协议,但是因为它是停止等待协议,所以它的的性能并不高。它对信道的利用率十分低,为解决这个问题的简单方法便...

osc_zfz30hgc
2018/01/25
11
0
计算机网络自学笔记:可靠数据传输的原理

在这篇文章中,我们仅考虑在一般情况下可靠数据传输的问题,仅考虑单向数据传输的情况,即数据传输是从发送方到接收方的。可靠的、双向数据传输(即全双工数据传输)的情况从概念上讲是一样的。...

云时之间
2019/03/04
0
0
TCP可靠传输的保证

我们知道传输层提供最主要的两种协议,TCP和UDP,其中TCP是保证可靠传输,为什么他要保证可靠传输呢,IP说:当然是我不能,我只提供尽力而为的服务,不保证你能不能交付,不保证能不能正确的...

osc_pll3h24t
04/16
2
0

没有更多内容

加载失败,请刷新页面

加载更多

Kafka如何在千万级别时优化JVM GC问题?

大家都知道Kafka是一个高吞吐的消息队列,是大数据场景首选的消息队列,这种场景就意味着发送单位时间消息的量会特别的大,那既然如此巨大的数据量,kafka是如何支撑起如此庞大的数据量的分发...

hummerstudio
06/18
6
0
我打赌!90%程序员都破解不了这个粽子,不信你试!

放假了 各位读者朋友们,马上就是端午小长假啦,开心激动有木有? 新的故事文章还在创作中,写了初稿感觉不太满意又推倒重来。其实写故事还是挺难的,读者可能第一次第二次有新鲜感,写多了就...

轩辕之风
06/24
20
0
如何删库跑路?教你使用Binlog日志恢复误删的MySQL数据

前言 “删库跑路”是程序员经常谈起的话题,今天,我就要教大家如何删!库!跑!路! 开个玩笑,今天文章的主题是如何使用Mysql内置的Binlog日志对误删的数据进行恢复,读完本文,你能够了解...

后端技术漫谈
01/14
22
0
PHP设计模式之代理模式

PHP设计模式之代理模式 代理人这个职业在中国有另外一个称呼,房产经济人、保险经济人,其实这个职业在国外都是叫做房产代理或者保险代理。顾名思义,就是由他们来帮我们处理这些对我们大部分...

硬核项目经理
2019/09/23
7
0
Redis的复制模式

Redis的复制功能分为同步(sync)和命令传播(command propagate)两个操作。 同步 同步操作用于将从服务器的数据库状态更新至主服务器当前所处的数据库状态。 1. 旧版本的执行步骤 从服务器...

osc_s9cni3go
24分钟前
5
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部