我正在研究可靠的UDP网络，我必须知道一些事情。我认为UDP可靠的算法就像那样（IDK，我猜）;
现在这是可靠UDP的真正方法吗？
编辑（回答之后，也许这对某人有帮助）：我想使用TCP，因为可靠的UDP不是处理我的操作的好方法。我将发送位置，如不重要的时间变量。也许如果我为可靠的UDP创建一个算法，这个可靠的过程将花费3-4 UDP send-recv，这意味着我此时可以发送3-4个其他不可靠的位置数据而且我发送的数据更小，效率更高比可靠的UDP。
答案 0 :(得分：2)
获得可靠UDP的“真正方法”是使用TCP。
如果您仍希望通过UDP执行此操作，则可以通过发送带有消息的校验和来验证消息的完整性，然后在另一端重新计算校验和以查看它是否与您发送的校验和相匹配。
如果不匹配，请再次请求数据包。请注意，这基本上是重新发明TCP。
答案 1 :(得分：1)
嗯，即使是：
- Client receive: (header:6)abdf, sends back "I got 4 data, they are abdf"
- Server send: (header:2)ce
如果服务器无法收到您的响应（可能在UDP中发生），该怎么办？因此，如果您不关心连接速度，切换到TCP是更好的选择。
答案 2 :(得分：0)
您的问题听起来像为Data Distribution Service量身定做。
我会发送不重要的时间变量等位置
事实上，位置纵坐标是许多供应商的流行示例。 RTI has a demonstration which goes well with your use case
是的，很多人听到“IDL”时都会呻吟，但我建议你给它一个公平的动摇。 DDS与许多流行的pub-sub / distribution / etc协议不同，它不是一个简单的封装/管道。
我认为非常酷的事情是，很多逻辑和设计元素经常涉及“我如何对底层网络或我的同行做出错误的反应？”的问题？ DDS提供高质量的服务协商，并为您的代码提供挂钩，以便在不满足QoS条款时做出反应。
我建议不要轻易做出这个决定，这比TCP，UDP，AMQP等要复杂得多。但是如果你能负担得起复杂性并且可以在一个足够大的系统上摊还它 - 它可以支付真正的红利
最后，DDS确实通过UDP提供“可靠”消息。它旨在支持许多不同的传输，以及许多不同的QoS维度。当您看到此服务考虑的所有不同维度维度时，它真的令人眼花缭乱。