Does it make sense to use both TCP and UDP at once?

Question

After reading Is UDP still better than TCP for data-heavy realtime games?, I'm wondering if it makes sense to use both TCP and UDP at the same time, but for different things:

• TCP for sending information that is sent infrequently, but should be guaranteed to arrive reliably.
  Such as score updates, a player's name, or even the on/off state of a light in the game world.

• UDP for transmitting information that is updated constantly and can be lost occasionally, since newer information is always on the way.
  Such as position, rotation, etc.

Is this a reasonable idea? What are the possible drawbacks?
Are there better ways to handle this?

Answer 1

It results in packet loss for UDP due to contention between the two protocols - remember that UDP is not guaranteed delivery, while TCP is. More TCP packets will get through while UDP suffers - TCP induces UDP packet loss. There has also been the (historical) idea that router infrastructure favours TCP over UDP, though I doubt that is still true by this late stage.

I think you'd be better off finding one of the connection-oriented UDP protocols that is out there for use in games and the like, that offers you some of the benefits of TCP with none of its downsides. There are a few such, usually with a whitepaper detailing each concept.

An example of those is the open source Enet library, its primary feature being optional reliable, in-order delivery of packets over UDP.

Answer 2

Here's a quote by Sam Jansen from a comment on gafferongames.com:

Speaking as a network researcher and not a game developer, the conclusion to never use TCP and UDP together seems a bit strong. TCP will only have packet loss if it is sending too much data; in some ways just like the UDP data you are sending. The difference is you have no direct control on the rate TCP sends at, this is hidden to you.

If you just need to send some reliable data and do not want to worry about retransmission and implementing a reliable protocol, and you know the rate will be low, then there wont be any problems with using both TCP and UDP.

The relationship isn’t all that complex between the two really: TCP merely increases its send rate (if there is data to send) until it gets packet loss, in which case it dials back its rate, then starts increasing the rate again (this time more slowly). When its increase in rate causes packet loss, it is quite likely to hit any other streams of data as well, including your UDP packets.

The paper Characteristics of UDP Packet Loss: Effect of TCP Traffic got its results by opening multiple TCP connections at once and flooding the network with data. This leads to the congestion followed by global synchronization, both of which cause dropped packets. Obviously, a game client will not open a dozen connections at once and flood the network with data, and so your results will be different.

To answer your question:

I'm wondering if it makes sense to use both TCP and UDP at the same time, but for different things [...]

Yes, this is an acceptable thing to do assuming you stay within your bandwidth limits.

• TCP for sending information that is sent infrequently, but should be guaranteed to arrive reliably. Such as score updates, a player's name, or even the on/off state of a light in the game world.

When using both TCP and UDP, you should always prefer to send as much as possible over UDP and as little as possible over TCP.

Now, I ask you this: Is it really necessary to send the score, the player's name, and the state of a light over TCP? While it is true that you need to receive this data eventually, is it true that you need to receive this data strictly-in-order and exactly once?

Probably not.

UDP works fine for these cases, and Quake 3 is a good example of how.

So what's a good example of TCP alongside UDP then? Well, think of a game's chatbox. The updates to this chatbox (that is, the new lines of text) need to be sent both reliably and strictly-in-order. Thus, TCP is a good fit.

Answer 3

Is this a reasonable idea?

• Yes

What are the possible drawbacks?

• Packet Loss, more code complexity, another connection to manage == more chance for disconnects, time outs, exceptions, whatever ...

Are there better ways to handle this?

• Use an existing Reliable UDP Library. Two of the most popular are: Lidgren Network (C#), RakNet (C++). From experience I can say Lidgren is super easy to use, fast, and reliable.

Answer 4

There is an additional resource constraint to consider. Most implemenations (I Believe all, but have no reference) of TCP on the server has limits on how many concurrent TCP Connections the server can have open at the same time. This would limit the number of players you can have open at the same time if each player needs its own connection.

The limits are defined by settings in the network system. Additionally every Connection uses up some memory which has to come from somewhere on the server.

One solution is to only open a temporary TCP Connection while data is transferred and Close it immediately. This will make transactions slower, opening a tcp Connection is a rather "expensive" process. As Always, it is all about designing a robust system from the beginning in order to allow large growth.