5

Considering UDP packets can get lost or arrive late to their target destination, does it make more sense to:

  • Use a TCP socket for important messages & events (ex: in a game where a player gets hit, attacks, dies, picks up item, saves the princess, etc.),

    OR...

  • Should a "reliability system" of some sort be developed in your UDP packets structure to confirm the reception of those particular events?

It seems that, at a minimum, for the few bytes difference that TCP have over UDP (min of 64b vs 52b, so 12b apart, according to this answer: https://stackoverflow.com/a/1846139/468206 ) that it would make more sense to let a TCP connection handle those events rather than re-invent the wheel in UDP. But maybe I'm missing the point?

Does keeping a TCP connection alive in the long-term / the duration of an app / game (let's say a minimum of 15mins) apply some overhead that can't be easily reduced or controlled as well as a custom-made "reliable" UDP implementation?

Would the bytes savings be more apparent in UDP because, for example, the reliable-event message in question could have some unreliable data piggy-back to it? (unreliable data = as in, basically any piece of data that would normally omit sending the extra "reliability" bytes, using a Fire-and-Forget approach)?

Note: There's probably some aspects of TCP that I forgotten or didn't take in consideration, which is why I reach out to you lovely experienced network developers to help bring up and drive the point home! :)

  • That are a few UDP based protocols with realibility on top, take NFS until v3 for instance. – Rui F Ribeiro Mar 23 '17 at 7:48
  • The choice of TCP or UDP is not up to the network engineer, it is up to the application designer. Which to choose is not a network engineering decision. Your question is more appropriate for, and heavily discussed on Stack Overflow. – Ron Maupin Mar 23 '17 at 12:52
  • Alright wasn't sure where to post this at first. If anyone has enough rep points to port this over stackoverflow you can go ahead. – bigp Mar 23 '17 at 13:25
5

Considering UDP packets can get lost or arrive late to their target destination, does it make more sense to: Use a TCP socket for important messages & events (ex: in a game where a player gets hit, attacks, dies, picks up item, saves the princess, etc.),

OR... Should a "reliability system" of some sort be developed in your UDP packets structure to confirm the reception of those particular events?

In short, neither.

There are a lot of resources online discussing precisely this (real-time protocol design, especially in gaming), but to summarise, the model whereby one host acts as a "server" and keeps track of game state (all players, statistics and object state in a world), and all clients communicate with the server via UDP is the industry standard.

UDP connections are used because you negate any round-trip latency associated with connection set-up or segment acknowledgement.

Because you have a server tracking state, it doesn't need to care about the client receiving frames or not - the client and server just send deltas, which they then update from the last known state.

This is of course an over-simplification of a very complex topic, but the gist is that there is no need for upper-layer protocols to be hacked over the top of UDP to make it "reliable" - the nature of real-time traffic, is that it is worthless if not delivered within a very short window.

I highly recommend the following article discussing experiments and observations by John Carmack when writing the Quake 3 networking code:

http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking

  • Note that the quake 3 networking implementation described at your link does have a form of reliability. The deltas are from the last state acknowlaged by the client, not the last state sent to the client. – Peter Green Sep 24 '17 at 20:23
4

Size overhead is negligable. Sending out acks doesn't block delivery of data to the application. Connection setup time is negligable for something like a game that keeps a session open for a long time.

The real problem with TCP is head of line blocking. If a single packet is lost on a TCP connection then the loss must be detected,the packet resent and the resent packet must be delivered to the application before any data coming after the lost packet can be delivered to the application.

It is possible to implement some level of reliability without head of line blocking and that is what I would expect any sensible developer of a realtime game to do.

Games where realtime isn't so critical can get away with just using TCP.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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