I am currently planning to make a card game project where the clients will communicate with the server in a turn-based and synchronous manner using messages sent over sockets. The problem I have is how to handle the following scenario:

(Client takes it turn and sends its action to server)

  1. Client sends a message telling the server its move for the turn (e.g. plays the card 5 from its hand which needs to placed onto the table)

  2. Server receives messages and updates game state (server will hold all game state).

  3. Server iterates through a list of connected clients and sends a message to tell of them change in state

  4. Clients all refresh to display the state

This is all based on using TCP, and looking at it now it seems a bit like the Observer pattern. The reason this seems to be an issue to me is this message doesn't seem to be point-to-point like the others as I want to send it to all the clients, and doesn't seem very efficient sending the same message in that way.

I was thinking about using multicasting with UDP as then I could send the message to all the clients, however wouldn't this mean that the clients would in theory be able to message each other? There is of course the synchronous aspect as well, though this could be put on top of the UDP I guess.

Basically, I would like to know what would be good practice as this project is really all about learning, and even though it won't be big enough to encounter performance issues from this I would like to consider them anyway.

However, please note I am not interested in using message oriented middleware as a solution (I have experience with using MOM and I'm interested in considering other options excluding MOM if TCP sockets is a bad idea!).


2 Answers 2


Don't optimize prematurely. Keep it simple. Using TCP in this case is OK, and I don't see any problems with your current scheme.

UDP is usually used for performance critical scenarios such as in an online action game, because it allows explicit control over individual packets as opposed to working on top of a layer abstraction of streams like TCP. However, although you have some speed gain by controlling exactly how you want data to be sent, UDP does not handle packet loss or packet ordering like TCP, in which case you have to code it yourself. So, since this is a turn-based card game, I doubt you'll want to sacrifice reliability over speed, so use TCP.

  • \$\begingroup\$ Thanks for your answer, it was clear and appears to answer everything I asked. \$\endgroup\$
    – LDM91
    Commented Mar 30, 2012 at 14:23

Even many large, popular MMOs are using TCP exclusively. It will do everything you need with all the efficiency characteristics you required.

UDP requires a lot of extra complexity, multicast requires even more complexity, and you're not going to get anything out of them. If you're just interested in learning, by all means put together a tech demo for yourself, but don't think that the project itself will in any way be better off because of it.

If you're interested in using UDP at all, your very first task is basically going to be to reimplement TCP on top of UDP, just to make sure that you actually understand how to deal with all the problems that TCP solves for you: congestion control, lost packet retransmission, delayed duplicate handling, packet ordering, reliable connection handshake, reliably disconnection sequence, etc.

It's not necessarily difficult to solve all those, but it requires a deep understanding of networking, the IP protocol, and how those problems are solved.

From there, building up the library to offer features that TCP lacks is where the fun really starts. Using a message stream multiplexed over a packet stream, more efficient congestion control, rate limit handling, multi channels, channel configuration (whether the channel requires in-order messages or not, whether dropped packets are allowed, etc.), and so on.

I would suggest you read the following article series. It's not perfect, and makes a few very questionable claims (starting with its "never use TCP in games" nonsense), but its technical details are helpful to new network programmers: http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/

  • 1
    \$\begingroup\$ In the introduction to that article the author stated: "The choice you make depends entirely on what sort of game you want to network. So from this point on, and for the rest of this article series, I’m going to assume you want to network an action game. You know games like Halo, Battlefield 1942, Quake, Unreal, CounterStrke, Team Fortress and so on." \$\endgroup\$ Commented Mar 30, 2012 at 1:16
  • \$\begingroup\$ Ah, I missed that when I skimmed it to make sure it was as good as I remember it. My bad, sorry. \$\endgroup\$ Commented Mar 30, 2012 at 1:35
  • \$\begingroup\$ -1 for "If you're interested in using UDP at all, your very first task is basically going to be to reimplement TCP on top of UDP" it is very wrong IMO. Much more useful to learn UDP actually doing things for which UDP gets chosen. \$\endgroup\$
    – o0'.
    Commented Mar 30, 2012 at 8:45
  • \$\begingroup\$ @Lohoris: That's unhelpful and not even correct. You MUST have the capability to send in-order guaranteed messages even with UDP. You need to be able to send in- order non-guaranteed messages. You need to be able to send guanteed out-of-order messages. It's simplest to start with the TCP-like behavior because it requires implementing all required features and is easiest to test, and even on its own still give useful features like a more direct control of bandwidth usage and latency. \$\endgroup\$ Commented Mar 30, 2012 at 22:16
  • \$\begingroup\$ @seanmiddleditch wrong. There's nothing wrong with using both UDP and TCP in the same game, so you aren't required to implement a guaranteed delivery over UDP. \$\endgroup\$
    – o0'.
    Commented Mar 31, 2012 at 9:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .