Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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?

share|improve this question

3 Answers 3

up vote 1 down vote accepted

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.

share|improve this answer

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!).

share|improve this answer
3  
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. –  Brett W Dec 12 '12 at 22:47
    
Yes, I believe it was Nagle's. –  bobobobo Dec 12 '12 at 23:08
    
I seem to recall disabling Nagle's didn't work, I plan to revisit this article though, –  bobobobo Dec 13 '12 at 0:46
1  
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. –  Krom Stern Dec 13 '12 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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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