BitTorrent uTP uTorrent传输协议ACK策略（BEP29）

Question

我正在编写BitTorrent uTorrent Transport Protocol的Boost版本（一种基于UDP数据报构建的缓冲区敏感的可靠流协议）。我的目标是拥有一个发送＆amp;的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)

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

我认为规则必须是：

1. 收件人总是发送已收到的最高连续 SEQ_NR的ACK（不是它收到的最后一个数据包的SEQ_NR，如规范所述）
2. 即使没有收到一个ACK（如上例所示），发件人也可以认为已收到所有数据包直至ACK_NR（加上任何选择性ACK数据包）
3. 如果接收器有任何间隙，它将继续在第一个丢失的数据包之前确认收到的最后一个数据包的SEQ_NR（加上它所做的任何选择性确认）。
4. 发送者在收到3个重复的ACK或ACK_NR后的3个数据包通过选择性ACK确认时，在ACK_NR + 1重新发送数据包。）

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

Answer 1

请看一下这个项目：https://github.com/rtttech/utp，它具有精心设计的API和非常清晰的实现。