通过UDP实现ack？

我们有一个系统(内置C),可以通过UDP进行通信.最近我们发现有必要保证数据包的传送.我的问题是:基于UDP的系统最少增加什么才能确保使用ack数据包进行传输？此外,理想情况下无需操纵数据包标头.我们对数据包进行应用程序级控制,包括序列号和ack/nack标志.我想知道这是否是一个失败的原因,我们尝试做的任何事情基本上都是一个有缺陷和破坏的TCP版本.基本上,我们可以通过极简主义改进来实现有保证的交付(我们不需要TCP的许多功能,例如拥塞控制等).谢谢!

TCP交织了3个可能相关的服务(好的TCP做得更多,但我只会谈论3.)

按顺序交货

可靠的交付

流量控制

你只是说你不需要流量控制,所以我甚至不会解决这个问题(如何宣传窗口大小等等,除非你可能需要一个窗口.我会接受它. )

你确实说过你需要可靠的交付.这不是太难 - 您使用ACK来表明发件人已收到数据包.基本可靠的交付看起来像:

发件人发送数据包

接收方接收数据包,然后发送确认

如果发送者没有得到确认(通过计时器),他重新发送数据包.

这三个步骤没有解决这些问题:

如果ACK丢失怎么办？

如果数据包无法到达怎么办？

因此,对于您的应用程序,您说您只需要可靠的交付 - 但没有说明需要它们.这将影响您实施协议的方式.

(顺序无关紧要的例子:你将员工记录从一台计算机复制到另一台计算机.如果Alice的记录在Bob之前收到,只要两者都到达那里就没关系.)

因此,假设您只需要可靠(因为这就是您在帖子中所说的内容),您可以通过以下几种方式实现这一目标.

您的发件人可以跟踪未确认的数据包.因此,如果它发送#3,4,5和6,并且没有获得3和4的ACK,则发送方知道它需要重新发送.(虽然发送方不知道数据包3和4是否很多,或者它们的ACK是否丢失.无论哪种方式,我们都必须重新发送.)

但是后来你的发送者可以做累积的ACK - 所以在上面的例子中,如果它已经收到3,4和5,那么它只会发出#6.这意味着如果没有接收到数据包,接收者将丢弃数据包6. .如果您的网络非常可靠,那么这可能不是一个糟糕的选择.

但是,上述协议确实有一个窗口 - 即发送方一次发送多少个数据包？这意味着您确实需要某种窗口,但不是出于流量控制的目的.你将如何传输窗口大小？

您可以通过窗口大小不变或通过执行类似停止等操作的方式在没有窗口的情况下执行此操作.前者可能是更好的选择.

无论如何,我没有直接回答你的问题,但我希望我已经指出了一些在构建这个问题时值得考虑的事情.没有流量控制部分(如窗口)而不考虑有序的"可靠传输"的任务很难!(让我知道我是否应该提供一些关于这些东西的更多细节!)

祝好运!

看一下Steven的UNIX网络编程第1卷第8章和第20章.他介绍了许多不同的方法.第20.5节"为UDP应用程序添加可靠性"可能对您最感兴趣.