我在检测到离散和连续手势时发送消息。对于连续的，UDP 应该没问题，因为即使丢失几个数据包，也有如此多的更改事件，这应该不重要。
我想知道离散事件，例如点击或滑动。由于只会发送一个数据包，因此数据包未到达并且另一端的应用程序没有收到该手势的通知的风险是什么？
我知道 TCP 可以保证传送，但我认为对于连续手势生成的高频率消息来说，这可能会带来太大的开销。
I'm sending messages upon detection of both discrete and continuous gestures. For continuous, UDP should be fine because even if a couple packets are lost, there's so many change events that it shouldn't matter.
I'm wondering about discrete events though, for example tap or swipe. Since there would only be a single packet sent, what is the risk that it doesn't arrive, and the application at the other end isn't notified of the gesture?
I understand that TCP guarantees delivery, but I'm thinking it might be too much overhead for the high frequency of messages generated from continuous gestures.
发布评论
评论（1）
如果您对 TCP 唯一关心的是额外的开销，那么我不会太担心。当然，TCP 比 UDP 有更多的开销。然而，开销并没有那么大，尤其是对于您可能发送的少量数据而言。一些快速的粗略计算：
假设您希望每毫秒发送一次状态信息。 （可能比您真正需要的频率更高。）
假设您的各个消息可以轻松容纳在每条 50 字节之内。 （可能比您真正需要的大。）
总带宽 50 字节/毫秒 = 400 位/毫秒 = 400 kbps
即使这些大于- 必要的消息和比所需更快的更新，您的总带宽仅为速度较慢的 802.11b 无线网络的 5% 左右。 TCP 的额外开销在这里不太可能产生很大的影响。
就我个人而言，我倾向于坚持使用 TCP，除非我有充分的理由不这样做。当然，您可以通过使用 UDP 节省一些额外的位，但对我来说，可靠的交付（包括正确排序的数据、非重复数据）值得额外的开销。少了一件需要担心的事情。
编辑：TCP 确实还有一些其他缺点。特别是，可能需要更多的编程工作来创建初始连接并从字节流中解析各个消息。 UDP 当然可以使这些任务变得更容易。但是，您没有将编程复杂性列为您的标准之一，因此我改为关注您的开销问题。
延迟：正如下面的评论所述，延迟是一个关键因素。在这种情况下，UDP 有一些显着的优点： 如果数据包丢失，TCP 将等待该数据包重新传输，然后再发送其他数据包。这种方法的好处是保证数据按原始顺序到达。 （当消息必须按顺序处理时，这是一个很大的优势。）当然，缺点是新数据可能会出现明显的延迟。
另一方面，UDP 将继续发送后续数据包，即使其中一个数据包被丢弃。好消息是 UDP 减少了剩余数据包的延迟。但坏消息是，您必须添加某种“重试”，以防离散事件丢失 - 如果您这样做，您现在会遇到手势到达顺序不正确的情况，这可能会很严重所以。您的应用程序可以处理“移动然后单击”更改为“单击然后移动”的情况吗？如果您选择采用 UDP 路线，则需要仔细考虑所有这些情况，以确保它不会在您的应用程序中导致（可能是微妙的）问题。
If your only concern with TCP is the extra overhead, then I wouldn't worry too much. Certainly, TCP has more overhead than UDP. However, the overhead isn't that much, especially for the modest amount of data you are likely to be sending. Some quick back-of the envelope calculations:
Assume you want to send status information every millisecond. (Likely more often than you really need to.)
Assume your individual messages can easily fit within 50 bytes / each. (Likely larger than you really need.)
Total bandwidth 50 bytes / ms = 400 bits / ms = 400 kbps
Even with these larger-than-necessary messages, and faster-than-needed updates, your total bandwidth is only around 5% of a slowish 802.11b wireless network. The extra overhead of TCP isn't likely to make a big difference here.
Personally, I tend to stick with TCP unless I have a strong reason not to. Sure, you could save some extra bits by using UDP, but to me, having the reliable delivery (including correctly ordered data, non duplicated data) is worth the extra overhead. One less thing to worry about.
EDIT: TCP does have some other drawbacks. In particular, it can take a bit more programming effort to create the initial connection, and to parse individual messages from the byte stream. UDP can certainly make these tasks easier. However, you didn't list programming complexity as one of your criteria, so I focused on your overhead questions instead.
LATENCY: As noted in comments below, latency is a critical factor. In this case, UDP has some significant advantages: If a packet is dropped, TCP will wait for that packet to be retransmitted before sending others. The benefit of this approach is that data are guaranteed to arrive in the original order. (A big plus when messages must be processed sequentially.) The drawback, of course, is that there could be a significant delay for new data.
UDP, on the other hand, will continue sending subsequent packets, even if one is dropped. The good news is that UDP reduces the latency of the remaining packets. The bad news, though, is that you must add some sort of "retry" in case discrete events are lost-- if you do so, you now have cases of gestures arriving out of order, perhaps significantly so. Can your app handle a case where a "move then click" gets changed to a "click then move"? If you chose to go the UDP route, you'll need to carefully think through all these cases to make sure it won't cause (perhaps subtle) problems in your app.