GBN&&SR窗口大小讨论
GBN&&SR窗口大小讨论
本文旨在分析GBN&&SR窗口大小与分组序号数量之间的关系.
引用博客：计算机网络——滑动窗口协议的窗口大小
总体结论
- 对于GBN而言，只需要满足: 发送端滑动窗口的序号数目 <= 分组编号数目 - 1，便不会造成接受端识别错误的问题。
- 对于SR而言，只需要满足: 发送端滑动窗口的序号数目 + 接受端滑动窗口的序号数目 <= 分组编号数目，便不会造成接受端识别错误的问题。
- 虽然，GBN没有接受窗口，但是，我们可以假定其接受窗口为1，那么，可以综合以上问题，得到：对于GBN && SR而言，只需要满足: 发送端滑动窗口的序号数目 + 接受端滑动窗口的序号数目 <= 分组编号数目，便不会造成接受端识别错误的问题。
GBN分析
PS：这一部分引用，做了些许修改
- 分组编号数目 = 8
- 发送端滑动窗口的序号数目 = 8
发送方给接收方发送了帧编号0A，1A，2A，3A，4A，5A，6A，7A，共计8个帧，接收方均收到，并处理后提交给网络层，并向发送方回馈ACK 0A~7A,并期待帧0B
然而回馈电路被雷劈了，所以ACK全部丢失，接收方等了好久，没等到确认，认定自己工作失误，发出去的东西没有到达地点，于是重发了之前的0A~7A号帧
但是接收方不知道自己的信道被劈了啊！他还以为自己的ACK（A系列）被对方接收到了，还在喜滋滋等着第二波新帧，没想到来的居然还是老人物。但是接收方脸盲啊，不把熟人当兄弟，一看来的还是0号大爷(它可分不清0B还是0A)，打头的正好编号和自己需要的一样，也看不出是不是新来的，就还是接收
这不就出错了吗！
所以我们得想办法防止这种事出现：
窗口如果等于7，就不会有这种狗东行为出现：
发送方发出0A,1A,2A,3A,4A,5A,6A共计7个帧，接收方还是接收并发送A系列的ACK，且依旧全部丢失，发送方超时重传0A~6A
但是这次情况不同了！
接收方发现来的人虽然数量没变，但是编号对不上了啊！自己等的是7爷，怎么来的是0爷？来的人不对，混日子的不是我的兄弟，不收！
于是数据传输断裂，但至少不会出错了……最后黑锅由闪电完美背起，鼓掌
SR分析
参看如下图示，很容易想到只要满足：发送端滑动窗口的序号数目 + 接受端滑动窗口的序号数目 <= 分组编号数目，就不会造成接受端识别错误问题。
