What kind of connection to use and how to send your data depends quite much on what kind of game are you writing.

TCP is a nice protocol, because it makes sure that no data is lost, and that it arrives in order. API-wise, it is quite often represented simply as a stream of bytes, with all the packet-related hassle hidden from the programmer. TCP is connection-based: hosts must first establish a connection, and then they exchange data over it. Should the connection be lost, they will try to reconnect, which may take some time. Also, checking whether the packets are all in order also introduces some overhead.

UDP, on the other hand, is connectionless - you just hurl packets out into the net and hope they will reach their destination. There is no guarantee packets won't be lost nor will they arrive in order - so yes, you must include your own frameno/timestamp data somewhere in the packet. But because UDP is much simpler than TCP, it doesn't have that much overhead and is usually much faster.

So, regarding the type of game you're writing:
  • With turn-based games, you could even go for TCP - most of the time the players will be waiting for their turn, and unless you incur some kind of turn length limit, a loss of few seconds because of packets resend/sort or reconnecting won't really matter.
  • With some kind of RTS, a good choice is going for UDP and simply postponing executing player actions. When a player issues an order to the unit, you keep it in memory and postpone its execution for X game cycles. Unless latency is bad, the other players should receive this info before the scheduled game cycle, so everything will be perfectly synchronised. You can check packets dropped simply by requesting a delivery report on each packet and resending it if no report arrives in some amount of time.
  • With some fast-paced games like shooters, things start to get tricky. If you plan only on local play, then yeah, you could go with sending input states every frame and only advancing the game once all players send their data. But on the web, you have latency, packets dropping and all that stuff. So it's simpler to just send state changes to the server and other players, and simply try to calculate as much as possible client-side. This article explains some quirks related to networking in fast-paced environments.


Obviously I'm no expert, since I haven't written much network code, but well, that's what I know. Hope you'll find my answer useful.