BitTorrent uTP uTorrent传输协议ACK策略(BEP29)

Question

我正在编写BitTorrent uTorrent传输协议的Boost版本（一种基于UDP数据报的缓冲区敏感可靠流协议）。我的目标是拥有一个UDP套接字管理器，它发送&接收数据报并管理所有拥塞&许多uTP连接的错误控制。客户端线程可以通过说utp_manager.async_connect( endpoint )来创建新的uTP连接，或者通过说utp_manager.async_accept( handler ) 来接受入站连接

uTP规范有点单薄，我不知道如何在以下情况下处理ACK号码：

DATA (seq=1) ----------------> received OK
                     X-------- ACK=1 (not received)
DATA (seq=2) ----------------> received OK
             <---------------- ACK=2 (received OK)

发送方是否因为接收到ACK=2而将DATA-1视为ACK？还是会重新发送DATA-1？在这种情况下，接收方是否会发送ACK=1，即使它已经确认了2？

我认为规则应该是：

1. 接收方总是针对其接收到的最高连续SEQ_NR发送ACK（而不是规范中所述的其接收的最后一个数据包的SEQ_NR）
2. 发送方可以假设直到ACK_NR的所有数据包都已收到（加上任何选择性ACK数据包），即使没有收到一个ACK（如我上面的示例）
3. 如果在接收器处存在任何间隙，则它将保持对在第一个丢失分组之前接收到的最后分组的SEQ_NR进行ACK（加上它所做的任何选择性ACK）
4. 当发送器接收到3个重复ACK时或者当在ACK_NR之后的3个分组已经用选择性ACK进行了ACK时，发送器在ACK_NR+1处重传分组）

我知道我可以尝试设置这些场景，并在现有的实现中运行它们，但我不认为有任何参考实现可以保证是正确的，而且设置起来很乏味。我希望研究或实施过该协议的人能够说出我是否做对了，或者我遗漏了什么。

Answer 1

让我们看看这个项目：https://github.com/rtttech/utp，它有一个设计良好的API和非常清晰的实现。