GBN协议的弊端
- 累计确认 批量重传
- 比如发送 2，3，4三个数据包，如果2号数据丢失，进行数据重传，那么3，4号数据包也需要重新传输。即使他们已经发送给接收端，但是接收端考虑到2号数据包丢失，也不会接收3号和4号数据包
- 可不可以只重传 出错的帧？？？
- 解决办法：设置单个确认，同时加大确认窗口，设置接收缓存，缓存乱序到达的数据帧
SR选择重传协议
- 3号是发完被确认的，但是他不处于滑动窗口的下界，因此滑动窗口不会进行平移
- 2和4是已经发送的帧，但是等待确认
- 接收方5号是希望接收但是 还没有接收到数据的，同理不可以移动滑动窗口
接收方要做的事情
- 收到了窗口序号外（小于窗口下界）的数据帧，就返回ACK进行确认；这种情况是因为接收方 对 发送方的数据进行确认，但是超时了，因此发送方进行了超时重传
滑动窗口的长度
- 发送窗口最好等于接收窗口
- 问题：如果循环使用同一个帧号，如何判断这个帧是新的数据还是旧的数据
协议重点总结
- 对于数据帧逐个确认，收一个帧 确认一个帧
- 只重传 错误的数据帧
- 接收方有缓存
- 发送窗口大小和接收方窗口大小一致，都是2的（n-1）次大小
