java - 以编程方式增加 UDP 缓冲区 - 这有意义吗？

Question

大家好!
我正在开发 java UDP 服务器。我向我的服务器发送了大量数据，但由于接收缓冲区较小而丢失了部分传入数据包。现在我以这种方式设置接收缓冲区 -

DatagramChannel serverChannel;<br/>
serverChannel.setOption(StandardSocketOptions.SO_RCVBUF, 1024*1024*10); // 10 MB

有意义吗？这段代码没有解决丢包问题。我的操作系统 - 64 位 Windows 7。

还有一个问题 - 我的网络 Controller 的接收缓冲区属性默认为 512 - 它是字节还是兆字节？如果它是 512 bytes，是否需要手动增加此属性？我认为以编程方式增加缓冲区实际上会增加操作系统缓冲区，但这没有意义，因为最初 udp 数据包“来到”我的网卡。

Answer 1

I send a lot of data to my server and lose part of incoming packets due to small recieve buffer size.

你不知道。可能的原因有很多。

Now I'm setting recieve buffer in a such way -

DatagramChannel serverChannel;
serverChannel.setOption(StandardSocketOptions.SO_RCVBUF, 1024*1024*10); // 10 MB

Does it make sense?

实际上，这是一个巨大的缓冲区，操作系统可能会将其截断为更合理的大小。设置后尝试获取选项，看看实际大小是多少。

This code didn't solve problem of packet loosing.

没有人说会。你只是假设了。

One more question - My network controller's recieve buffer property is 512 by default - is it bytes or megabytes?

除非您告诉我们您使用的是什么 NIC，否则没人能回答这个问题，但您应该能够从制造商的数据中自行发现。

Is it necessary to increase manually this property if it's 512 bytes?

不仅没有必要，而且不可能。

I think increasing buffer programatically actually increases operating system buffer

如果您的意思是 SO_RCVBUF 控制套接字接收缓冲区大小，那是正确的。

but this doesn't make sense

是的。

because initially udp packets "come" to my network card.

然后从那里进入操作系统，从那里进入 IP 堆栈，从那里进入 UDP 堆栈，然后从那里进入套接字接收缓冲区。当大多数路径 MTU 高达 1500 字节时，NIC 似乎不太可能有 512 字节的缓冲区，但它确实有意义，例如 512k。你可以假设它就足够了，毕竟它确实有效。

您的基本假设有缺陷。 UDP 数据包可能由于多种原因而丢失:它们从未被发送，它们被中间路由器丢弃，它们被分成碎片并且不是所有碎片都到达接收者，或者接收者的套接字接收缓冲区已满，这反过来可能是因为它太小或因为接收方跟不上发送方。仅使用巨大的套接字接收器缓冲区只能解决这些问题之一。如果您需要可靠性，请使用 TCP，或者实现带有重试的 ACK 或 NACK 机制。