Should my server use both TCP and UDP?

Question

I'm writing a client/server application and really can't find guides that fit my need. Doing it on my own leads me to many design flaws before I've even begun. For instance the server should update every client as to its state many times each second. I assumed I couldn't update every client individually, but UDP broadcasts should fix that. But I still need a TCP channel to reliably communicate with each client for things like: Chat messages, user input etc.

Researching this topic it seems that it's possible for a server to use both protocols simultaneously - but only possible (not sensical). Nobody suggests such an approach, in fact I gather from this article that it's rather bad to use both.

---

Now I'm very confused as to how I should handle data in my server. Unless I've completely misunderstood something about packet loss, I want to guarantee that user input resulting in 'server-request-packets' are not lost. Every answer on SO about guaranteeing delivery with UDP say, without fail, use TCP. What's more frustrating is that every server/client program I can imagine at the very least needs some of its messages guaranteed delivered (for instance 'disconnect' messages?).

Should I use UDP, TCP, both or am I just thinking completely wrong about this?

Answer 1

Lets get some facts on the table:

• UDP is not reliable. Ever.

• Under some circumstances, UDP can be particularly lossy; e.g. if there is network congestion, rate limiting or traffic profiling, or if the UDP message size is larger than the MTU.

• UDP broadcast only works on your local network segment. Internet routers generally don't allow broadcasts to propagate further than that. That really limits its usefulness.

• UDP multicast might be a possibility except that that tends to be blocked too.

So this probably leaves you with two main possibilities:

• UDP point-to-point messaging from your server to each of the clients.
• TCP from the server to each of the clients.

Another possibility is some kind of peer-to-peer mesh communications using UDP or TCP, but that gets really complicated. Don't go there unless you really need to, and really know what you are doing.

So to your question.

Should I use UDP, TCP, both or am I just thinking completely wrong about this?

I recommend using TCP between the server and each client, because it is simplest. To simplify even further, use multiple TCP connections per client to avoid the complexity of multiplexing multiple "conversations" a single socket.

The network performance won't be optimal, but it could well be good enough your application. And I doubt that this is the part of your application where you want to be spending all your developer time.

When you get to the point of having a working application (client & server sides) and there are people using it, you may find (or not!) that the networking is a major bottleneck and cause of user dissatisfaction. Then you look at optimizing the communications in version 2.0 of your application.

When you come to implement version 2.0 (or 3.0 ...) to address scalability, you will need to move a way from dependence on a single server. Put simply, if you have N clients, and N keeps increasing, then at some point a single server won't be able to cope. Other things in the application design can be problematic too. For example, in a gaming application, you can't send continual updates about each player to all other players ... where the number of players keeps growing. But note that these issues are largely independent of the network protocols that you use.