Handling Lots of Clients: UDP or TCP?

0
votes

I want to create a communications server that all the clients can connect to. The only problem I'm having is deciding whether to use TCP or UDP. I want to be able to handle hundreds of clients at once (500 - 1000) and each one would have their own thread to handle them. Would either TCP or UDP be able to do this and if so which one would be suit my needs? If anyone has any ideas on a better way to handle lots of clients please let me know. Thanks.

EDIT: The server would basically be a message communication server. So all the game servers (clients) could send a message to it and it would broadcast it to all the other game servers (clients). I would want all message deliveries to be as reliable as possible.

2
javanetworkingtcpudp
What information are you sending? Do you care about state? Do you care about potentially losing some packets? - admdrew
Since you don't care about performance ("each one would have their own thread to handle them"), just use whichever one you know best. - David Schwartz

2 Answers

1
votes

Both TCP and UDP can do this. Which one you use depends on whether you want unreliable datagrams or reliable streams. Only you know that, but almost certainly you should use TCP,

0
votes

There are three major considerations here.

First, do you need to make such a server yourself? There are many products (most of the free and open source) which can do pretty much what you're describing: Kafka, Redis, ZeroMQ, RabbitMQ, and that's just to get started. If there's some game or other application you want to make, then grab one of those and spend your time working on the real application.

Second, do you need a reliable communication channel or not? If so, you want TCP. If not, then you want UDP. Don't worry about which is faster. Use the one which fits your needs. Also... If you're not 110% sure you need UDP, then you definitely want TCP.

Finally, the biggest lever to pull when trying to scale inbound network connections is Synchronous vs Asychronous I/O. Using the former, you'll need to have one thread/process per inbound connection, and you'll quickly top out the resources on your machine. With the latter, you can handle pretty much everything with a single thread, and scale out much bigger. Compare something like Ruby on Rails vs Node.js for a specific example.