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

Question

我正在编写BitTorrent uTorrent传输协议 (基于UDP数据报构建的对缓冲区敏感的可靠流协议)的Boost版本。我的目标是拥有一个UDP套接字管理器，它发送和接收数据报，并管理许多uTP连接的所有拥塞和错误控制。客户端线程可以通过声明uTP创建新的utp_manager.async_connect( endpoint )连接，也可以通过表示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而将数据-1作为ACK处理？还是会重新发送数据-1？在这种情况下，接收方是否会发送ACK=1，即使它已经有了ACK 2？

我认为规则应该是：

1. 接收方总是将ACK发送给它所接收到的最高连续SEQ_NR (而不是它所接收到的最后一个数据包的SEQ_NR，因为规范状态)
2. 发送者可以假设直到ACK_NR的所有数据包都已经接收到(加上任何选择性的- ACK数据包)，即使没有接收到一个ACK(如我上面的例子)。
3. 如果在接收端有任何漏洞，它将保留在第一个丢失数据包之前接收的最后一个数据包的ACKing - SEQ_NR (加上它所做的任何选择性的-ACK)。
4. 发送方在ACK_NR +1处重新发送数据包，当它接收到3个重复的ACK或在ACK_NR之后的3个数据包被选择性-ACK重新发送时)。

我知道我可以尝试设置这些场景，并在现有的实现中运行它们，但我认为没有任何保证是正确的引用实现，设置起来很繁琐。我希望那些研究过或实施过该协议的人能够说出我是否做对了，或者我错过了什么。

Answer 1

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