My game uses UDP sockets to stream updates between server and client and I've also made a reliable channel that resends messages if there's no response and makes sure same message isn't processed multiple times.

But TCP is specifically designed to be reliable and the people who made it probably have more experience than me. So would it be good to use TCP to send commands such as "attack", "play animation", etc. instead of my UDP implementation?
(Of course I mean TCP sockets that don't delay sending the data (Nagle algorithm))


2 Answers 2


One of the most common misunderstandings of TCP vs UDP is that TCP's main feature is reliability.

The main feature of TCP is that it abstracts a stream of data to send from one socket to another. Reliability, as provided by TCP is a requirement for the abstraction to work, but is not the central idea behind TCP. You might want to consider basing your decisions on whether or not a stream abstraction is appropriate for your needs.

A stream abstraction means that you have a place where you put bytes, and the same bytes appear on the other end as soon as possible. That's all there is to it.

TCP has no concept of messages. As so, it is perfectly possible that you make two sends of 10 bytes each, and you get one receive of 20 bytes. Also it is possible that you get 3 receives, one of 1 byte, one of 14 bytes and one of 5 bytes. If you need to have messages on TCP, you will have to implement your own messaging abstraction over TCP.

Additionally, TCP makes no guarantees as of when the messages will arrive on the other side. It is perfectly possible for you to do one million minus one 10-byte sends, wait 1 hour and then do one final 10 byte send, and only get one 10 megabyte receive at the other end.

There are ways to get around some of these limitations, but the main idea is that TCP abstracts a stream of bytes, and should be used when you need a stream of bytes that you want to send as soon as possible to another place. File sends are an awesome example of an application that makes good use of TCP.

On the other hand, UDP offers you a messaging abstraction. You send messages, and they get immediately sent to the other side. Since messages are completely independent of each other, there is no concept of order, and as such it is perfectly possible for sent messages to arrive in disorder, or not arrive at all. If you want order, and delivery guarantees, you will have to implement those on top of UDP.

However, unlike TCP, each message on UDP is a separate entity. Each send will result in one receive at the other side (supposing the message did not get lost). Messages won't be buffered, split or reassembled anywhere. Also, UDP guarantees that each message will be sent as soon as possible.

For games, you may want to think which abstraction works best for you (stream or messages), and build your communications infrastructure on top of that. If there are additional requirements that the abstraction does not offer, you can build on top of them according to your needs.

For action-based, I would most likely use UDP, as each action can probably be converted into one message. Since UDP does not have any concept of order and reliability, I would insert a few bytes on top of each message, which state a sequence number for that message, and the last sequence number I have received from the other end.

If both hosts are constantly exchanging messages, a host that notices that the most recent messages have not been received by the other host, can assume that a particular message was lost, and could try retransmitting it. This is a very simple order/reliability system that can be easily implemented on top of UDP.

There are many other fun things you can do with UDP, like creating separate channels, each with different sequence numbers, so a message lost on one channel won't affect the rest, or a specific channel without sequence numbers.

Unfortunately, I find it way too common for people to stop at "TCP:Reliable:GOOD!, UDP:Unreliable:BAD!", without considering the more important difference between the protocols.


Panda Pajamas excellent answer has covered a lot of the topic, but if you want more detailed information I suggest taking a look at Gaffer on Games series of blogs on 'UDP vs TCP'. There Glenn Fiedler goes into more detail about the problem with using TCP for games with real-time requirements, and suggests how you can build reliability into your own UDP-based solution.

  • \$\begingroup\$ You're welcome :) It should have been a comment to Pandas answer, but I don't yet have enough ranking to create comments on other answers.. \$\endgroup\$
    – Erik_W_B
    Jul 3, 2015 at 13:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .