Texas Hold'em: Technical stuff

How to implement client-server solutions is fairly well known in the Java programming community, so I'm not exactly giving away any trade secrets explaining the structure of the poker game. This is intended as a rough overview for beginners.

On the server side there is a Java application, running 24 hours a day (not counting crashes), which listens for socket connections. Its most important part is a table manager object that keeps track of everything going on at each poker table -- the number of players, which cards they have, how much they bet, etc. More permanent information, like the passwords, user names and spare cash of the players is stored in an MSQL database.

The applet on the client side consists of the login box and, obviously, the game window in which all the action takes place. There is also a communication thread, working behind the scenes, which sends and receives information (coded text strings) according to the sketch below.

Each time a message is passed to the server, a temporary data receiver thread is created, which is active only for as long as the connection is open. It passes the data on to the table manager, picks up the response and everything that has accumulated since last time, and finally sends that back to the client.

Once every few seconds the client communication thread initiates such a transfer. Its timing is independent of what happens in the game window, so all user input (typically mouse clicks) gets stored in a queue, waiting to be sent.

Regarding the incoming messages, it is necessary to implement an extra queue on the client side, since each message may correspond to more than one visual event. For example, when cards are dealt, each player should get one card at a time with a short delay in between, to make things more "realistic". So this gets split up into a set of separate events. Only when each one has been carried out is the next message fetched from the incoming queue.