当服务器只有1个UDP插座时，如何处理许多传入的UDP数据包？
当服务器只有1个UDP套接字，并且许多客户端向其发送UDP数据包时，处理所有传入数据包的最佳方法是什么？
我认为这也可能是TCP数据包的问题，因为线程计数有限，无法涵盖所有客户端TCP套接字接收事件。
但是在这种情况下，情况会更好，因为每个客户端有1个TCP插座，即使网络缓冲区已满，数据包接收也会被阻止，直到队列有空间（让我知道我是否错了）。
但是，当缓冲区填满时，UDP数据包被丢弃，并且只有1个插座，因此发生这种情况的机会更高。
我该如何解决这个问题？我已经搜索了一段时间，但是我找不到明确的答案。我应该实施自己的排队系统吗？还是只是最大化网络缓冲区大小？
When a server has only 1 UDP socket, and many clients are sending UDP packets to it, what would be the best approach to handle all of the incoming packets?
I think this can also be a problem with TCP packets, since there's a limited thread count, which cannot cover all client TCP socket receive events.
But things are better in this situation because there's 1 TCP socket per client, and even if the network buffer is full, packet receiving is blocked until the queue has space (let me know if I'm wrong).
UDP packets, however, are discarded when the buffer is full, and there's only 1 socket, so the chances of that happening are higher.
How can I solve this problem? I've searched for a while, but I couldn't get a clear answer. Should I implement my own queueing system? Or just maximize the network buffer size?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
没有办法保证您不会删除UDP消息。无论您做什么，如果发送的数据包率太大，您都会在接收主机或网络中的某个地方丢弃一些。
有些可能有助于的事情包括：
在Java应用中实现内部队列，并将其交给线程池进行处理。
增加内核的消息缓冲。
但是，这些都无法处理接收者处理它们或网络容量的能力高的平均消息到达率的情况。这将不可避免地导致丢失的消息（请求）。
那是因为没有一个！一些问题在根本上是无法解决的。对于其他人来说，最好的答案取决于难以衡量或预测的因素。
（如果您想要确定性...不要使用网络！）
在TCP情况下，您应该做的就是为每个客户使用（长期）插座。根据您需要支持的插座数量，您可以：
java.nio.channels.Selector和一个线程池。如果请求率超过服务器处理它们的能力，您仍然会遇到问题。但是，TCP连接将确保请求不会丢失，并且客户会得到一些“背压”。
There is no way to guarantee you won't drop UDP messages. No matter what you do, if the rate of packets being sent is too large, you will drop some, either on the receiving host or somewhere in the network.
Some things that can help include:
Implementing an internal queue for messages in your Java app, and handing them over to a thread pool to process.
Increasing the kernel's message buffering.
But neither of these can deal with the case where the average message arrival rate is higher that the receiver's ability to process them or the network capacity. This will inevitably lead to lost messages (requests).
That is because there isn't one! Some problems are fundamentally unsolvable. For others, the best answer depends on factors that are too hard to measure or predict.
(If you want certainty ... don't use networking!)
In the TCP case, what you should do is use a (long-term) socket for each client. Depending on the number of sockets you need to support, you could either:
java.nio.channels.Selectorand a thread pool.You will still get problems if the rate of requests exceeds your server's ability to process them. However, the TCP connections will ensure that requests are not lost, and that the clients get some "back pressure".