我正在研究可靠的UDP网络，我必须知道一些事情。我认为UDP可靠算法就是这样工作的（IDK，我想）;可靠的UDP算法？
现在是可靠的UDP这是真的呢？
编辑（回答后，也许这可以为别人有用）：我goint使用TCP可靠，因为UDP是不处理我操作的好方法。我会发送像不重要的时间变量的位置。也许如果我为可靠的UDP创建一个算法，这个可靠的过程将花费3-4个UDP send-recv，这意味着我可以在这个时候发送3-4个其他不可靠的位置数据，并且我发送的数据量可以更高比可靠的UDP。
的“正确的方法”获得可靠的UDP是使用TCP。
如果您仍希望通过UDP来完成此操作，您可以通过发送带校验和的消息来验证消息的完整性，然后重新计算另一端的校验和以查看它是否与您发送的校验和相匹配。
如果不匹配，请再次请求数据包。请注意，这基本上是重新创建TCP。
您还需要一种机制来处理丢失，而不仅仅是损坏的数据包。 –
头+校验和（如crc）可以是有用的，我认为。我现在吗？ – MonoLightGS
UDP带有一个校验和，添加一个不会使其可靠性下降（这种情况自然会伴随着网络拥塞）。 –
你的问题听起来就像是量身订做的Data Distribution Service。
我会送样未重要，时间变量
事实上，位置坐标是许多厂商的最典型的例子位置。 RTI has a demonstration which goes well with your use case。
呀，当他们听到“IDL”很多人的呻吟，但我建议你给它一个公平待遇。 DDS不像很多流行的pub-sub/distribution/etc协议，因为它不是一个简单的封装/管道。
我觉得很酷的事情是，经常有很多逻辑和设计元素的进入的问题，“我怎么反应的底层网络或我同行（S）胡作非为（S）？” DDS提供服务质量协商，并在您的代码不符合QoS条款时响应您的代码。
我建议不要轻易做出这个决定，它比TCP，UDP，AMQP等复杂得多。但是如果你能承受复杂性并且可以在足够大的系统上分摊它 - 它可以支付真实分红。
最后，DDS确实提供了UDP“可靠”的消息。它旨在支持许多不同的传输和QoS的许多不同维度。当您看到此服务考虑的QoS的所有不同维度时，确实令人目不暇接。
感谢您的支持！我会看看是否需要这样的实现。 – MonoLightGS
好，即使有：
- Client receive: (header:6)abdf, sends back "I got 4 data, they are abdf"
- Server send: (header:2)ce
什么，如果服务器将不会收到您的回复（可能在UDP发生）？因此，如果您不关心连接速度，切换到TCP是更好的选择。
作为一个说明，在大多数操作系统实现UDP不会给你一个部分数据包。你要么收到它的所有部分，要么没有。请注意，单个数据包的顺序不能保证，甚至根本不会收到数据包。 –
@DaveS数据可能完全丢失！谢谢。 – MonoLightGS
如果你想要的是一个可靠的面向数据报的协议，请考虑[SCTP]（http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol）。 –