流水线机制与滑动窗口协议

1 流水线机制：提高资源利用率

流水线协议

• 允许发送方在收到ACK之前连续发送多个分组
  
  • 更大的***范围
  • 发送方和/或接收方需要更大的存储空间以缓存分组

2 滑动窗口协议

• 滑动窗口协议: Sliding-window protocol
• 窗口
  
  • 允许使用的***范围
  • 窗口尺寸为N：最多有N个等待确认的消息
• 滑动窗口
  
  • 随着协议的运行，窗口在***空间内向前滑动
  • 滑动窗口协议：GBN, SR

3 Go-Back-N协议

Go-Back-N(GBN)协议: 发送方

• 分组头部包含k-bit***
• 窗口尺寸为N，最多允许N个分组未确认

• ACK(n): 确认到***n(包含n)的分组均已被正确接收
  
  • 可能收到重复ACK
• 为空中的分组设置计时器(timer)
• 超时Timeout(n)事件: 重传***大于等于n，还未收到ACK的所有分组

GBN: 发送方扩展FSM

GBN: 接收方扩展FSM

• ACK机制: 发送拥有最高***的、已被正确接收的分组的ACK
  
  • 可能产生重复ACK
  • 只需要记住唯一的expectedseqnum
• 乱序到达的分组：
  
  • 直接丢弃接收方没有缓存
  • 重新确认***最大的、按序到达的分组

GBN示例

4 Selective Repeat协议

• BN有什么缺陷？
• 接收方对每个分组单独进行确认
  
  • 设置缓存机制，缓存乱序到达的分组
• 发送方只重传那些没收到ACK的分组
  
  • 为每个分组设置定时器
• 发送方窗口
  
  • N个连续的***
  • 限制已发送且未确认的分组

Selective Repeat：发送方/接收方窗口

SR协议

SR协议示例

SR协议：困境

• ***: 0, 1, 2, 3
• 窗口尺寸：3
• 接收方能区分开右侧两种不同的场景吗？
  
  • (a)中，发送方重发分组0, 接
    收方收到后会如何处理？
• 问题：***空间大小与窗口尺寸需满足什么关系？
  
  • NS+NR<=2＾ｋ（2＾ｋ表示窗口尺寸）