0
votes

I'm trying to optimize a UDP server to handle more throughput, it's based on Java IO Datagram Socket(not NIO). when this UDP server receives a UDP packet, it needs to process this packet, and send the processed data to background resources, then responds the client. Currently this server will allocate a thread for each incoming packet to process.

I've read some articles, I understood that for some cases, for example, a chat server based TCP: that needs to manage thousands of open connections simultaneously, which each only send a little data, implementing the server in NIO is probably an advantage. Very few threads could handle lots of connections (Thread Per Request), because only a few of connections send requests to server at a given time point. So, we don't need to maintain a thread for each connections. This is a huge advantage to use Java TCP NIO.

Whereas in UDP, every packet (datagram) is effectively a self-contained message, each packet could be considered as a request, even we use NIO Datagram channel, we still need to create a thread for each request.

So, what the advantage to use NIO Datagram channel?

1

1 Answers

2
votes

Even we use NIO Datagram channel, we still need to create a thread for each request

Why? Not if you're an echo server, a time server, ... it all depends exactly what you're doing.

And you might consider a thread per client rather than per request, if your application is such that the clietns keep requesting (as opposed to one-shot requests: time or DNS for example).

Your assumptions don't stand up to scrutiny.

However it is certainly true that NIO is oversold and that most applications don't need it. There are servers out there supporting hunreds of thousands of connections in blocking mode.