Apparently from what I can gather Starcraft 2 moved to UDP in a patch. Now obviously with fps games there is no dispute that UDP is the only way to go. But with RTS games what benefits does UDP give over TCP given that the network model is lockstep?

I suppose another way to phrase this is: what features of TCP make TCP inferior compared to UDP with resend, etc. implemented in the context of rts lockstep networking model?


3 Answers 3


While UDP is bad at emulating TCP's feature-set as a whole, you could still see a potential performance benefit from picking and choosing features for different kinds of packets, e.g., one might choose to use UDP for voice chat functionality (where we really don't need things to stay in perfect lock-step anyway) and TCP for actual gameplay. Further, we could use UDP for some parts of gameplay, with some weak synchronization done through spare packets.

This would make your game even hungrier for network resources, but might have some sort of performance benefit if done right.


Because TCP buffers data at both the client (prior to sending a packet) and the remote host (remote host might not be notified a packet was received until several packets are received and combined together into a data buffer). See my article why TCP is unsuitable for games.

You hear it said, but you don't believe it until you try it (or until a major game vendor tries it then has to patch).

From the article:

You know that when you call .send() on a TCP socket, TCP WILL NOT NECESSARILY DELIVER THE MESSAGE IMMEDIATELY! TCP has a buffer BOTH at the sender (messages might pile up for a number of seconds before actually being fired off across the net) AND at the recipient (messages might stock up for a number of seconds before the remote user’s TCP subsystem alerts HIM that you have sent some bytes). This is precisely what makes TCP so inappropriate for use for games: it might withhold the data from you, even if its already at your machine, as you can see here, for up to 2 seconds (or more!).

  • 3
    \$\begingroup\$ From glancing at your article I would attribute this to Nagle's Algorithm. Unless you explicitly define TCP_NODELAY the socket subsystem is going to stack small packets to reduce packet overhead. This is clearly defined and expected behavior and has to be controlled by the person employing TCP. Unless I'm mistaken and you're referring to some other type of buffering. \$\endgroup\$
    – Brett W
    Dec 12, 2012 at 22:47
  • \$\begingroup\$ Yes, I believe it was Nagle's. \$\endgroup\$
    – bobobobo
    Dec 12, 2012 at 23:08
  • \$\begingroup\$ I seem to recall disabling Nagle's didn't work, I plan to revisit this article though, \$\endgroup\$
    – bobobobo
    Dec 13, 2012 at 0:46
  • 1
    \$\begingroup\$ We have been using TCP for our RTS and recently discovered about NO_DELAY. Lags reduced by half and our are the same as with UDP now. Plus we don't need to care about packet delivery and etc. \$\endgroup\$
    – Kromster
    Dec 13, 2012 at 5:16

You can build a layer of redundancy on top of UDP that allows you to:

  • Recover your message even if you've lost packets, using a multi datagram checksum.
  • Spam the other machine you are connecting to until you receive an ack in your layer.

Both strategies will allow you to minimise the effect of the round trip travel when you are losing packets.

You also avoid getting burnt by the tcp slow start if you are regularly dropping packets due to issues other than network congestion.


You must log in to answer this question.

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