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

Question

我正在编写Boost版本的BitTorrent uTorrent Transport Protocol（基于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'd 2，接收者是否也会发送ACK = 1？

我认为规则必须是：

1. 收件人始终针对已收到的最高continuous SEQ_NR发送ACK（作为规范说明，不是接收到的最后一个数据包的SEQ_NR）
2. 发件人可以假设即使没有收到一个ACK，也已经收到到ACK_NR为止的all
个数据包（加上任何选择性ACK数据包）（如上述示例）
3. 如果接收方有任何间隙，它将继续对第一个丢失的数据包之前接收到的最后一个数据包的SEQ_NR进行ACK（加上它所做的任何选择性ACK）。>>
4. [发送方在收到3个重复的ACK或ACK_NR之后的3个数据包已通过选择ACK进行ACK的情况下，在ACK_NR +1处重新发送数据包]]

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

我正在编写BitTorrent uTorrent传输协议（基于UDP数据报的对缓冲区敏感的可靠流协议）的Boost版本。我的目标是要有一个UDP套接字管理器来发送＆...

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

Answer 1

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