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.