25

This is a question I see a lot. Most people say UDP is always better for real-time games than TCP. My understanding is that TCP tries to re-send packets over and over til the other side gets them whereas UDP doesn't care.

Most of the things I've read is that UDP is a must for any realtime game and TCP is terrible. But the thing is, most people seem to implement some form of TCP on top of UDP anyways. And I've also heard that the difference between the two is negligible given that we're not in the 80s anymore and the internet is now pretty fast and reliable.

Is my general understanding here wrong? Can someone clear this up for me?

Improve this question
10
  • 7
    internet is now pretty fast and reliable No, it's not. The bandwidth has dramatically increased, yes, but latency is still quite high. With pure TCP you need the server tick time to be more than the max affordable latency, unless you do packet squishing - which is best done at the client via UDP. The problem is that some info in a game needs to be reliable, while some other needs to be fast. Custom protocols on top of UDP allow for that, as well as a bunch of proprietary ones that give you everything you need in a nice package.
    – Ordous
    Feb 14, 2017 at 18:34
  • 5
    They don't exactly implement TCP over UDP. There are some features that TCP offer which are desirable and that are implemented on top of UDP. A major point of using UDP is that if you send a packet containing the world state at time t0 that is never received, then you send the new world state at time t1, you don't have to wait until the client actually receive the first package, which is already obsolete.
    – Vincent Savard
    Feb 14, 2017 at 18:51
  • @Ordous I think this answers my question :) Thanks
    – flooblebit
    Feb 14, 2017 at 18:54
  • 4
    Also be aware that UDP is prone to IP spoofing which could make your server open to DDoS attacks if that is a concern. You could avoid that by having a "control" TCP connection that sends the clients IP address and other details to the server which then accepts UDP packets from the "authenticated" address. Also you may have to implement your own encryption layer as there are no open standards for that over UDP.
    – ARau
    Feb 14, 2017 at 19:21
  • @blownie55 good points there
    – onkkno
    Feb 14, 2017 at 19:34

2 Answers 2

Reset to default
13

Depends on if you're talking about peer-to-peer, client/server with the users running the server, or client/server with a data center running the server. Only in the latter-most case is the internet really fast and reliable. Your users' computers are not guaranteed to be fast, and certainly won't be reliable.

UDP allows you greater control over the sort of TCP-like implementation you're making. It gives you greater flexibility to execute packets out of order, discard packets that you consider unnecessary while retrying packets you consider important, that sort of thing. But this should only be done if needed and if you have the necessary expertise.

If you can do without that flexibility, TCP works well enough and saves you a whole lot of time. Even professional studios (like one I worked at) use TCP if they don't absolutely need UDP, and they have people dedicated to network programming.

Improve this answer
2
  • I'd also suggest that "for what" matters - e.g. for an in-game chat system I wouldn't even consider UDP. The other thing I'd consider (at least for "client server") is how efficiently server can handle traffic - modern NICs have a lot of built-in "offloading" stuff for TCP (splitting and merging packets, sorting packets into streams, etc) that are designed to reduce CPU overhead, and most of that can't work for UDP.
    – Brendan
    Feb 15, 2017 at 14:42
  • 1
    Things may change now that QUIC (en.wikipedia.org/wiki/QUIC) which will be part of HTTP/3 which uses UDP and is encrypted using TLS by default. It will take some time for this to be widely available and is something to look forward to. More details on some issues that need to be handled here blog.cloudflare.com/the-road-to-quic
    – ARau
    Dec 3, 2018 at 3:15
4

It would be an assumption to say "Internet is now pretty fast and reliable" as @Ordous pointed out, and a dangerous one too.

The reason why UDP+custom protocol for delivery-critical packets does magic on most games is that, there are times when it could be "okay" if you lose some packet (just for. e.g. secondary non-critical events to complete game play), there are also times where its "not at all okay" to lose some data for e.g cursor movement etc. (I don't do game development for a living so pardon my vague-ish examples)

UDP doesn't waste time in pushing them again and again, by default.

And, many games incidentally seem to have the "okay to lose sometimes" packets more than "always need to deliver without fail" packets. Hence making a natural fit for this task.

All that was needed on UDP was to use a custom protocol that just helps deliver the "always need to deliver without fail" packets properly, leaving the rest of game data to the mercy of the network connection.

Now deciding on what kind of traffic makes up most of YOUR data to be transmitted across will help you decide better.

The point against TCP would be that time spent on retries could rather be spent on sending packets that matter NOW.

There is also a chance that if there is any issue during transmission, TCP could cascade to a more broken down game-play scenario for the user, spoiling their experience compared to UDP+Custom Stack (This last part is just hunch. I will leave this to other experts here to comment on this. Would love to learn about possibilities of this scenario).

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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