然而,你的发送方可以做累积确认 - 因此在上面的示例中,仅当发送方收到3、4和5时,它才会确认#6。这意味着如果接收方没有收到前面的包,它将丢弃包6。如果您的网络非常可靠,则可能不是一个坏选择。
然而,上述描述的协议确实有一个窗口 - 即发送方一次发送多少个数据包?这意味着您确实需要某种形式的分窗机制,但不是为了流控制的目的。您将如何传输窗口大小?
您可以通过使窗口大小恒定或执行类似于停止和等待的操作来实现无需窗口的传输。前者可能是更好的选择。
总之,我没有直接回答您的问题,但我希望我已指出了一些在设计时值得考虑的事情。在没有任何与顺序相关的流控制(例如分窗)且不考虑按顺序传输的情况下实现“可靠传输”的任务很难!(让我知道是否应该提供有关某些内容的更多详细信息!)
祝你好运!
请查看Steven的UNIX网络编程卷1的第8章和第20章。他涵盖了许多不同的方法。第20.5节“向UDP应用程序添加可靠性”可能对您最有兴趣。
我有一个问题正在这里收集关于“当需要可靠的UDP时你会使用什么”的答案。这些答案可能比你想要或需要的更多,但你可以看一些已经基于UDP构建的协议,并抓取你需要的ACK部分。
从我使用ENet协议(一种可靠的UDP协议)的经验来看,我认为每个UDP数据报中都需要一个序列号,一种发送已接收数据报的ACK的方式,一种保留已发送数据报直到你收到ACK或它们超时的方法以及定时重新发送尚未收到ACK的数据报的方法... 我还会添加一个总体超时时间,用于决定你永远无法传递特定数据报的情况,并且,我猜测,回调你的应用层以通知它无法传递此数据报的失败...
实现确认应答的最佳方式是在应用层中进行。CoAP是一个应用协议的例子,它运行在UDP上但提供可靠的数据传输。它为所有的Confirmable(CON)消息保留一个消息ID,并发送一个带有相同消息ID的确认包。所有确认和消息ID字段都保存在应用程序层部分。因此,如果发送者没有收到带有他发送的消息ID的Ack包,它将重新发送该数据包。应用程序开发人员可以修改协议以满足所需的可靠数据传输。