我是靠谱客的博主 高高鸡翅,最近开发中收集的这篇文章主要介绍后退N帧协议(GBN),觉得挺不错的,现在分享给大家,希望可以做个参考。

概述

前言: GBN协议和SR协议,都是为了提高信道利用率。

 

流水线技术

在这里插入图片描述
在流水线技术中:
1.发送方需要缓存多个分组,可以发送多个分组。
2.如果发生帧丢失或者帧差错,那么就会用到帧的副本。(后文会提及)。我们需要更大的空间来存放这些副本。

 

后退N帧协议中的滑动窗口

建议大家认真看下图:
在这里插入图片描述
窗口的移动:
原来的发送窗口中是0~5帧,发送0帧之后,如果接收窗口接收到0帧,窗口后移一格,并发送确认帧ACK0。接收到确认帧后,发送窗口就会移动,移动一格,这时要发送1 ~ 6帧。
我们发送1和2帧,当然后面窗口中的其他帧也是可以发送的。

 

运行中的GBN(具体细节)

在这里插入图片描述
若接收成功:
发送方如果发送0帧,那么接收方就要接受0帧并返回确认帧ACK0。这个时候,接收方就会根据帧编码推算下一个帧为1号帧。
那么根据上图发送窗口发送1号帧,接受窗口成功接收到了1号帧,并返回ACK1。接收端推算出下一个帧应该为2号帧。

若接收失败:
可是2号帧在发送中意外丢失,没有给到接收窗口。而接收方继续发送3号帧,这时在接收窗口接收到了3号帧。可惜接收窗口很专一啊,2号帧没有来,谁来也不好使,接收窗口就会把3号帧丢弃,继续发送确认帧1,提醒发送窗口该发送2号帧了,4、5帧也是同等待遇。(专一的接收窗口,我哭了~~)。

接收失败的措施:
在发送窗口,每发送一个帧,就会启动超时计时器。比如我们的2号帧一旦发送,就会启动超时计时器。没有接收到确认帧2,就会超过计时器时间导致重新发送。
上面我们的发送窗口一直接收的是确认帧1,迟迟没来确认帧2,那么就会导致确认帧2以及2之后的,发送过的帧重新发送(即使这些帧在接收窗口接收到了)。

 

滑动窗口长度

很多人会问这个问题,既然为了提高信道利用率,那我的发送窗口岂不是越多越好?

这样显然是不对的。

若采用n个比特对帧编号,那么发送窗口的尺寸w应满足:1<=w<=2n-1
如果发送窗口尺寸过大,会使的接收方无法区别新帧和旧帧。
我们举个例子:
如果n=2,那么编号为00、01、10、11对应0、1、2、3,w最大为3。
如果我们w=4,也就是发送窗口大小为4,在发送过程中,很不幸,所有数据帧发送失败,超时计时器结束之后,那么必然要全部重新发送
再次发送编号为0、1、2、3的数据帧,问题就来了,这是重新发送的,还是下一次全部发送过来的,接收方就会搞不清楚。

 

GBN协议性能分析

1.因连续发送数据帧而提高了信道利用率
2.在重传时必须把原来已经正确传送的数据帧重传,使传送效率降低。

最后

以上就是高高鸡翅为你收集整理的后退N帧协议(GBN)的全部内容,希望文章能够帮你解决后退N帧协议(GBN)所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(49)

评论列表共有 0 条评论

立即
投稿
返回
顶部