Why do game developers avoid TCP and make UDP reliable in the application level?

Question

Many game developers choose to a make UDP reliable in the application level. Isn't that what TCP is made for? I made an API that enables Client-Server communication using UDP and TCP packets. Should I add Reliable UDP to the list? And why? Is there a problem if I use TCP?

I just want to know if RUDP has any benefits over TCP, so that I can choose whether to add RUDP support or not.

Answer 1

Short answer: TCP is not optimized for latency (at all); as a result - it has several properties which are latency killers for games (though they come into play only when a packet is lost). In particular, head-of-line blocking and exponential backoff tend to be very annoying for fast-paced games.

The one which hurts latency the most is head-of-line blocking (a.k.a. HOL blocking): if one packet is lost, all the subsequent packets within the same stream, even if they reach the other side of communication, are not allowed to reach app-level (ouch!), until the lost packet is retransmitted (and this is going to take around 2*RTT, which even for a per-continent Server, is around 100 ms (="in a shooter, you already got killed)).

Long answer:

It is a complicated subject, and we need to distinguish several distinct scenarios:

1. we DO need reliable ordered message (or byte) stream. In this case, RUDP benefits over TCP, while present, are very minimal (we can play a bit with reducing retransmission times - and eliminate exponential back-off, but that's pretty much it). In particular, head-of-line blocking is still inevitable with ANY kind of reliable ordered streams (whether TCP, RUDP, or whatever else).

2. we DO need a reliable but potentially-unordered message delivery. This MAY allow to avoid HOL blocking, but requires rather complicated app-level handling.

3. we DON'T need reliability at all (="fire and forget"). One prime example of such information is when we need to show a bullet hit - if we didn't show it right away, there is no need to show it half a second later, so if the packet didn't make it - well, it is better to just ignore it and not spend resources on re-sending the packet.

4. we DO need eventually-synchronized state (but we DON'T care about going through all the intermediate states); this is an extremely common scenario for simulations. This IS possible to implement over UDP (and without incurring HOL blocking penalty). However - enabling compression over non-reliable connections is not trivial, and compression is THE MUST for most of the games out there. Fortunately - such compression IS doable (see http://gafferongames.com/networked-physics/snapshot-compression/ and/or http://ithare.com/udp-from-mog-perspective/#low-latency-compression for discussion). If this approach is implemented (which can be done on top of completely unreliable packets) - it will provide VERY significant improvement over TCP (it does eliminate HOL blocking, so we're speaking about delays of the order of network ticks - and this can be as low as 1/120sec~=8ms - over delays-around-RTTs, and these are at least 100ms for one single packet lost).

Side comment:

Actually, it IS possible to simulate UDP over TCP (eliminating TCP latencies) - see http://ithare.com/almost-zero-additional-latency-udp-over-tcp/ . Note though that to utilize it, all the stuff above should be still done manually. There is still no magic bullet which allows to avoid HOL blocking for a reliable-ordered stream; instead - this technique allows to make several TCP connections to behave "almost as if" it is unreliable-but-non-blocking UDP.

Answer 2

The problem is with out-of-order packets.

After looking about I have learnt that the problem is that TCP wants to hog all the received packets until they are received in the order the application is expecting. This could be rather detrimental to performance for a reasonably-sized multi-player game where you only care about the latest player positions and not where they happened to be a few milliseconds ago.

RUDP changes all that and just provides the "most recent packet" as Erik from Unity states:

Erik-Juhl @ Unity Technologies

The main reason people would choose UDP/RUDP over TCP is because of how TCP handles out of order packets. You may only care about the most recently received packet and want that as soon as it arrives. In TCP, if your most recently received packet is not the next one in sequence, TCP will not deliver it to you until everything else has been received.

If you need to guarantee sequence and delivery then just use TCP. If you need to guarantee sequence and delivery plus get the most recent packets as soon as they arrive, then use RUDP. Tell me more...

Answer 3

If I'd directly say that UDP is faster, comparatively than TCP that it is used for such applications; you won't believe and accept. The developers, carrying on this, thus developed some reliability on UDP (called RUDP) to make it somewhat imitate TCP. Still, it doesn't implement TCP functionalities completely(in totality).

That's why I'd like to answer your question with reference to an article Reliable UDP (RUDP): The Next Big Streaming Protocol? :

TCP has a set of instructions that ensures that each packet of data gets to its recipient. It is comparable to recorded delivery in its most basic form. However, while it seems obvious at first that "making sure the message gets there" is paramount when sending something to someone else, there are a few extra considerations that must be noted. If a network link using TCP/IP notices that a packet has arrived out of sequence, then TCP stops the transmission, discards anything from the out-of-sequence packet forward, sends a "go back to where it went wrong" message, and starts the transmission again.

If you have all the time in the world, this is fine. So for transferring my salary information from my company to me, I frankly don't care if this takes a microsecond or an hour, I want it done right. TCP is fantastic for that.

In a video-centric service model, however, there is simply so much data that if a few packets don't make it over the link there are situations where I would rather skip those packets and carry on with the overall flow of the video than get every detail of the original source. Our brain can imagine the skipped bits of the video for us as long as it's not distracted by jerky audio and stop-motion video. In these circumstances, having an option to just send as much data from one end of the link to the other in a timely fashion, regardless of how much gets through accurately, is clearly desirable. It is for this type of application that UDP is optimal. If a packet seems not to have arrived, then the recipient waits a few moments to see if it does arrive -- potentially right up to the moment when the viewer needs to see that block of video -- and if the buffer gets to the point where the missing packet should be, then it simply carries on, and the application skips the point where the missing data is, carrying on to the next packet and maintaining the time base of the video. You may see a flicker or some artifacting, but the moment passes almost instantly and more than likely your brain will fill the gap.

If this error happens under TCP then it can take TCP upward of 3 seconds to renegotiate for the sequence to restart from the missing point, discarding all the subsequent data, which must be requeued to be sent again. Just one lost packet can cause an entire "window" of TCP data to be re-sent.

---

Many game developers choose to a make UDP reliable in the application level. Isn't that what TCP is made for?

If you can tolerate with the speed of how data is being processed at the both ends, it is OK.

But, in games, this is not OK. You have to pass video frames(and audio,etc.) many times per second an that too to many players(if multiplayer). It all needs much more speed, and faster data processing capability; instead of using the comparatively slower TCP. Even if some packets are dropped midway, it is OK for the application to move ON, as the brain too would move on to next rather than thinking about those jitters.

I made an API that enables Client-Server communication using UDP and TCP packets. Should I add Reliable UDP to the list? And why? Is there a problem if I use TCP?

That depends on how better you want to application to be responsive. I'd suggest you to add Reliable UDP to your list.

I've already mentioned the problems with the TCP.

I just want to know if RUDP has any benefits over TCP, so that I can choose whether to add RUDP support or not.

With low overhead, and higher speed, I'd bet for reliable UDP, than the bulky TCP - for developing such applications(gaming).

Answer 4

I do not understand too much about these protocols, but according to my current knowledge, TCP is a connection-oriented protocol and UDP is a connection-less protocol. UDP is mostly used in live online multiplayer games due to the fact that UDP is faster because error recovery is not attempted. In those games, UDP is used because reliability is not really crucial. TCP takes steps to make sure all packets that are sent are received by the client, while UDP just sends them without checking if they have been received. Please correct me if I am wrong!

Reference: http://www.diffen.com/difference/TCP_vs_UDP