my question about the player position sender protocol. In this article, he says "Never use TCP for networking a multiplayer game". Ok but UDP datas are not ordered. In this case, if somebody walking, his position will be received and sent to other players. While walking other players can see the player's NPC teleporting like movement. Some positions will be incorrect. Otherwise TCP isn't suitable, I agree but how can we use UDP? (UDP reliability?)

EDIT (Question): There is an other problem. If player1 send his data to server this data can be lost. Otherwise if data received by server, server will send it back to other clients. In this case some datas can be lost again. Namely UDP creates an undefined position update (namely everybody -clients- can see player at different positions). What can we do about that?

EDIT: Oh, I'll use TCP for login-room like request because they are important (must be reliable) datas. There is no problem about this.

EDIT2: I don't know how can I use UDP for player positions.


closed as not a real question by Anko, msell, bummzack, MichaelHouse, Josh May 14 '13 at 14:44

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center. If this question can be reworded to fit the rules in the help center, please edit the question.


You can solve the ordering problem by adding a sequence number to messages where order matters and simply ignore any messages which were made obsolete by a message with a later sequence number.

So when your client receives a position message which position 2 although it already got position 3, it keeps the object at position 3.

  • \$\begingroup\$ Namely last timed data will be new position and after (timestamp) position 3, if position 2 received it'll be old and never effects player position, right? \$\endgroup\$ – Mehmet Fatih Marabaoğlu May 11 '13 at 13:54
  • \$\begingroup\$ @MehmetFatihMarabaoğlu exact. \$\endgroup\$ – Philipp May 11 '13 at 13:55
  • \$\begingroup\$ Ok but there is an other problem. If player1 send his data to server this data can be lost. Otherwise if data received by server, server will send it back to other clients. In this case some datas can be lost again. Namely UDP creates an undefined position update (namely everybody -clients- can see player at different positions). What do you think about that? \$\endgroup\$ – Mehmet Fatih Marabaoğlu May 11 '13 at 13:58
  • 1
    \$\begingroup\$ Lack of reliability is the price you pay for using UDP instead of TCP. When you want 100% reliability, use TCP. Otherwise you will end up just reinventing TCP on top of UDP with all of its drawbacks. \$\endgroup\$ – Philipp May 11 '13 at 14:12
  • \$\begingroup\$ Ok. That's a true answer. And in a MMOFPS, we can be tolerant to positioning because there is a 20 times per second update. Some data can be lost :) (Am I right?) \$\endgroup\$ – Mehmet Fatih Marabaoğlu May 11 '13 at 14:24

If you use UDP for ordering-sensitive data such as player positions, you will have to implement it yourself. At minimum, you need to drop packets that arrive late. Which requires some sort of sequencing/timestamping.

Flow control with TCP might mean a laggy game compared to a crashed server due to network congestion. And nagling with TCP can be disabled.

Using UDP-only as that article suggests might require a lot of extra work (essentially reimplementing parts of TCP) that is already built into TCP.

  • \$\begingroup\$ Ok but TCP is slower than UDP. I don't want to establish a connection like TCP. I want to send positions fast only, in this case we need to create something different with UDP. \$\endgroup\$ – Mehmet Fatih Marabaoğlu May 11 '13 at 13:52

If you want to save effort, use TCP. TCP does a lot of things automatically for you, including:

  • retransmission (unacknowledged packets are automatically resent),
  • reordering (packets received out of order are buffered until they can be processed in correct order),
  • flow control (the maximum transmission rate is automatically adjusted up and down to maximize throughput without excessive packet loss),
  • MTU discovery (finding out the largest packet size a given connection will handle), and possibly
  • fragmentation (splitting packets into smaller pieces along the connection and reassembling them at the receiver).

The problem with TCP is that it's a general-purpose protocol, and the way it handles these things is not always optimal for games. For example, it your game sends two position updates to the server, and first update packet is lost along the way, then TCP will hold on to the second packet until the first one has been successfully retransmitted, and only then let the server process both. In a fast-paced game, you'd probably prefer to have the second update processed as soon as it arrives and just forget about the lost first update.

Unfortunately, while TCP does offer some options to tweak the buffering and retransmission algorithms, there's no way to tell it to just drop lost packets. For that, you'll need a lower-level protocol like UDP. The problem with UDP, on the other hand, is that it's a very low-level protocol — a very thin wrapper over raw IP, in fact — and takes care of none of the things listed above.

Thus, if you want to use UDP, you basically have two choices: either use an existing UDP-based networking library like OGP that takes care of some of the things that TCP handles, but in a more game-friendly manner, or study network protocols like TCP and figure out how to implement the same features yourself. Unless you really like network programming, I'd only recommend the latter option as a last resort.

  • \$\begingroup\$ Ok. I understand this: If I need send unimportant (position like) data I'll use UDP. If I need send important data (like login) I'll use TCP. UDP can lost some data but If we send position 10 times (or more) per second this can be tolerated and after some (like 0.2-0.3 seconds later) player'll send new position and ~0.2ms lag'll be unimportant data (because nobody can see this lag). (I think that is a basic way to do it if we aren't make a high-quality MMO game). Am I right? \$\endgroup\$ – Mehmet Fatih Marabaoğlu May 12 '13 at 12:51
  • \$\begingroup\$ Pretty much. Just remember that, as the other answers have noted, there are a lot of things you'll need to handle yourself if you use UDP that TCP would handle for you, like numbering (or timestamping) your packets so that you can tell which one was sent first. You'll also very likely want to combine multiple messages into one packet to improve performance, but then you need to worry about not exceeding the maximum packet size (MTU) for the user's connection. \$\endgroup\$ – Ilmari Karonen May 12 '13 at 17:53

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