10
\$\begingroup\$

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?

\$\endgroup\$
  • \$\begingroup\$ Be sure to read the rest of the threads on this site concerning udp and tcp. You will find several details that essentially deal with your questions. As a hypothesis: I suspect there are hybrid protocols over UDP that try to get the best out of both worlds, i.e. lower latency, contention strategy, load balancing and delivery guarantees. As suggested, search for related questions on the topic and narrow down your question to something that you feel was not addressed here yet. \$\endgroup\$ – teodron Apr 19 '16 at 7:41
  • \$\begingroup\$ @teodron You needn't suspect. As stated in my answer, it is a fact. \$\endgroup\$ – Engineer Apr 19 '16 at 8:14
8
\$\begingroup\$

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.

\$\endgroup\$
  • 1
    \$\begingroup\$ To make the answer a bit "meatier", could you provide a short (very short) list of options/references for UDP-based transport libraries? (perhaps ENET, RakNet, zeroMQ, UDT?). As per my comment above, I am sure I have seen a discussion on these somewhere on this site, but it might be worth replicating a fragment of that informaiton. \$\endgroup\$ – teodron Apr 19 '16 at 8:42
  • 1
    \$\begingroup\$ @Arcane Engineer What if the UDP and TCP sockets are running on different ports? \$\endgroup\$ – KaareZ Apr 19 '16 at 9:59
  • \$\begingroup\$ @KaareZ Should not make any difference at all. The studies that have been done (see link in edit) would not be valid if it was a simple matter of divvying up into ports. At the end of the day, a port is just a software port. It doesn't really affect network characteristics, which is what this boils down to. \$\endgroup\$ – Engineer Apr 19 '16 at 10:27
  • \$\begingroup\$ What you say makes sense, but I can't help but wonder if this still applies where there is very little TCP traffic. If only small amounts of information are transmitted over TCP, say on an average of once or twice every ~10 seconds, would that really affect UDP traffic noticeably? \$\endgroup\$ – gandalf3 Apr 19 '16 at 18:02
  • 2
    \$\begingroup\$ The "TCP induces UDP packet loss" paper has no date. Its most recent references are from 1996. From when is the paper? Is the conclusions valid still? \$\endgroup\$ – Andreas Apr 20 '16 at 5:38
4
\$\begingroup\$

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.

\$\endgroup\$
3
\$\begingroup\$

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.
\$\endgroup\$
1
\$\begingroup\$

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.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.