UDP数据包等待然后一起到达答案

【问题标题】：UDP packets waiting and then arriving togetherUDP数据包等待然后一起到达
【发布时间】：2012-05-20 04:03:40
【问题描述】：

我有一个简单的 Java 程序，它充当服务器，监听 UDP 数据包。然后我有一个通过 3g 发送 UDP 数据包的客户端。

我注意到偶尔会出现以下情况：我发送了一个数据包，但几秒钟后仍未收到。然后我发送另一个数据包，突然它们都到达了。

我想知道是否有可能存在某种系统来等待一定数量的数据，而不是发送一个尺寸过小的数据包。在我的应用程序中，我每个数据包只发送大约 2-3 个字节的数据 - 尽管 UDP 标头和其他什么不会使消息变大一点。

我的应用程序的目的是尽可能快地从 A 到 B 获取这几个字节的数据。非常强调速度。这一切只是巧合吗？我想我可以增加数据包的大小，但似乎传输时间会增加，而且 3g 并不完美。

【问题讨论】：

停止猜测。进行数据包跟踪。获取真实数据。
要记住的一点是，通常接收端会被命令在返回之前检索一定数量的字节——使用 Wireshark（或类似的）来验证数据是否正在发送并在两端收到。
这看起来像是 Wireshark 之类的工作。
@Redmumba 由谁订购的？ UDP是UDP。数据报应在收到后立即交付给应用程序。
对，但是如果您的接收应用程序显示“read(10)”，其中 10 是在程序中处理它之前要缓冲的字节数，那么您的物理机/套接字/任何可能已经收到这些字节但缓冲不足以触发读取操作。就像@Jon 说的：使用 Wireshark。

标签： java udp

【解决方案1】：

由于 cmets 变得相当冗长，最好将它们完全变成答案。

如果您的应用在检索到一定数量之前没有接收数据，那么很有可能在幕后进行了某种缓冲。一个很好的例子（不是说这直接适用于您）是，如果您或底层库正在使用InputStream.readLine() 或InputStream.read(bytes)，那么它将阻塞，直到收到换行符或bytes 返回之前的字节数。从您的程序似乎在达到某个阈值时检索所有数据这一事实来看，听起来就是这样。

调试它的一个好方法是使用 Wireshark。 Wireshark 并不关心你的程序——它会分析传入和传出你计算机的原始数据包，并可以告诉你问题出在发送方还是接收方。

如果您使用 Wireshark 并看到第一次发送的数据在第二次发送之前到达您的物理计算机，那么问题出在您的接收端。如果您看到第一个数据包与第二个数据包同时到达，那么问题出在发送者身上。没有看到代码，很难说你在做什么，具体来说，是什么导致数据仅在收到超过 2-3 个字节后才显示 - 但在那之前，这种行为准确地描述了你所看到的.

【讨论】：

【解决方案2】：

这有几个可能的原因：

蜂窝数据网络并非“永远在线”。根据底层技术，在发送第一个数据包和实际建立 IP 连接之间可能会有相当长的延迟。这将在 IP 网络空闲一段时间后最为明显。
您的接收器可能未正确检查套接字的可读性。无论您使用什么高级 API，都需要调用select() 来检查套接字是否可读。当数据报到达时，select()应该解除阻塞并发出套接字描述符可读的信号。或者，但效率较低，您可以将套接字设置为非阻塞并通过读取对其进行轮询。轮询会在没有数据时浪费 CPU 时间，并将到达检测延迟至轮询间隔，但如果由于某种原因您无法腾出一个线程等待select()，这可能会很有用。
我在上面说过select() 应该在数据到达时在被监视的套接字上发出可读性信号，但是这种行为可以通过套接字的“接收低水位标记”来修改。默认值通常为 1，这意味着任何数据都表示可读性。但是如果SO_RCVLOWAT 设置得更高（通过setsockopt() 或更高级别的等价物），则在超过指定数量的数据到达之前不会发出可读性信号。您可以使用 getsockopt() 或您环境中的任何等效 API 检查该值。

第 1 项将导致第一个数据报实际上被延迟，但仅在 IP 网络空闲一段时间而不是一旦它启动时才有效。第 2 项和第 3 项只会让您的程序认为第一个数据报被延迟：接收方的数据包嗅探器会显示第一个数据报准时到达。

【讨论】：