「gbn协议java」GBN协议的应用
今天给各位分享gbn协议java的知识，其中也会对GBN协议的应用进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
本文目录一览：
滑动窗口协议——GBN
在 回退N步协议 中，允许发送方发送多个分组而不需要等待确认，但它也 受限于在流水线中未确认的分组数不能超过某个最大允许数N.
接收方 ：
GBN发送方必须相应三种类型的事件：
在GBN中，如果一个序号为n的分组被正确接收并且按序（即上次交付给上层到上层的数据是序号为n-1的分组），则接收方为分组n发送一个ACK，并将该分组中的数据交付到上层。在其他情况下，接收方丢弃该分组，并为最近按序接收的分组重新发送ACK.
下面是窗口长度为4个分组的GBN协议运行情况。
简述GBN协议的工作过程
你大概说的是3步握手吧，这跟传真机的5部握手很类似。 下面的资料希望对你有用 TCP/IP 是很多的不同的协议组成，实际上是一个协议组，TCP 用户数据报表协议(也 称作TCP 传输控制协议，Transport Control Protocol。可靠的主机到主机层协议。这里要先 强调一下，传输控制协议是OSI 网络的第四层的叫法，TCP 传输控制协议是TCP/IP 传输的 6 个基本协议的一种。两个TCP 意思非相同。)。TCP 是一种可靠的面向连接的传送服务。 它在传送数据时是分段进行的，主机交换数据必须建立一个会话。它用比特流通信，即数据 被作为无结构的字节流。通过每个TCP 传输的字段指定顺序号，以获得可靠性。是在OSI 参考模型中的第四层，TCP 是使用IP 的网间互联功能而提供可靠的数据传输，IP 不停的把 报文放到网络上，而TCP 是负责确信报文到达。在协同IP 的操作中TCP 负责：握手过程、
数据链路层流量控制GBN协议
需重传4－7帧。后退N帧协议具有捎带确认作用，在协议中，数据帧呈段式传输，当计时器超时，收到3号帧确认表示其及其以前的帧均正确接收，只是1的确认信息丢失。另外，传输层确认位ACK=1表示确认字段有效，确认号ack取服务器正确接收报文字段序号的下一个数。
流量控制之GBN协议
停等协议的弊端：
改善：
引入GBN、SR协议
接收窗口接收到0#帧之后，就会返回一个0#确认帧，紧接着接收窗口的窗口就会向后移动一个，接收窗口变成1；然后，发送窗口收到0#确认帧之后，发送窗口也会向后移动一个窗口
发送窗口有6个并不表示这6个都会连续发送，而是可能会2个、3个连续发送。发送窗口可能不一定会被填满，6个窗口的发送窗口，可能目前只有2、3个帧，剩下位置是空的。
GBN发送方必须做的三件事：
GBN接收方要做的三件事：
帧编号（比特位数）和发送窗口长度的关系： 发送窗口长度小于帧编号
帧编号(由比特位数决定，比如max{0 1 2 3 4 5 6 7}) 发送窗口长度
GBN协议的性能：
缺点：丢失的帧出错，不仅要把丢失的帧重传，还要把丢失的帧之后的帧也得重传
因为连续发送提高了信道利用率
重传时必须把原来正确的数据帧重传，传送效率降低
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比特对帧编号，为了保证接收方向向前移动窗口后，新窗口序号与旧窗口序号没有重叠部分，需要满足条件：接受窗口+发送窗口=2^n。假定仍然采用累计确认的方法，并且接受窗口显然不应超过发送窗口，那么接受窗口尺寸不应超过序号范围的一半=2^(n-1)。
假设n取3,序号空间即0~7 （S:sender R:receiver）
S 发送了0,1,2,3,4,5,6 号帧
R 接受上述帧并且捎带发送 ACK6,但是丢失了
S的0号帧首先超时，S 重发发送0号帧
R收到0号帧，但是因为之前它已经接受0~6,发送了ACK6，它会认为0号帧是一个新的帧，而在0号帧之前的一个7号帧丢失（注意这里是一个环的结构）。因为是选择重传协议，R会接受0号帧( the old)作为新帧(暂时放在缓存区)，并通知S重发7号帧。
S 发送7号帧
R接受了7和0号帧，并且发送ACK0
这就出现了问题：
1、R接受错误的0号帧作为新的帧
2、S在发送完7号帧之后收到了ACK0，而不是ACK7，此时对于S而言，它的0号帧早已在ACK6中确认。
出现这个问题的主要原因是我们不能区别新旧帧，现在我们将序号空间一分为二，首先发送0~3，继续上面的步骤。走到步骤4的时候R不会接受0作为新帧，因为R知道新的帧是4而不是0。这样就避免了上面的问题。
gbn协议java的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于GBN协议的应用、gbn协议java的信息别忘了在本站进行查找喔。