How to sync a list on a server with many clients?

Question

Consider a poker game server which hosts many tables. While a player is at the lobby he has a list of all the active tables and their stats. These stats constantly change while players join, play, and leave tables. Tables can be added and closed. Somehow, these changes must be notified to the clients.

How would you implement this functionality? Would you use TCP/UDP for the lobby (that is, should users connect to server to observe the lobby, or would you go for a request-response mechanism)? Would the server notify clients about each event, or should the client poll the server?

Keep that in mind: Maybe the most important goal of such a system is scalability. It should be easy to add more servers in order to cope with growing awdience, while all the users should see one big list that consists from multiple servers.

Answer 1

This specific issue is a manifestation of a very basic issue in your application design - how should clients be connecting to the server.

When scalability is an issue, always resort to a scalable solution, using non-blocking I/O patterns, such as the Reactor design pattern. Much preferred is to use standard solutions which already have a working and tested implementation of such patterns.

Specifically in your case, which involves a fast-acting game which is constantly updating, it sounds reasonable to use a scalable server (again, non-blocking I/O), which holds a connection to each client via TCP, and updates him on information he needs to know.

Request-response cycle sounds less appropriate for your case, but this should be verified against your exact specifications for your application.

Answer 2

That's my basic suggestion:

The server updates the list (addition, removal, and altering exsisting items) through an interface that keeps a queue of a fixed length of operations that have been applied on the list. Each operation is given a timestamp. When the queue is full, the oldest operations are progressivly discarded.

When the user first needs to retrive the list, it asks the server to send him the complete list. The server sends the list with the current timestamp.

Once each an arbitary period of time (10-30 seconds?) the client asks the server to send him all the operations that have been applied to the list since the timestamp he got. The server then checks if the timestamp still appears in the list (that is, it's bigger than the timestamp of the first item), and if so, sends the client the list of operations that have occured from that time to the present, plus the current timestamp. If it's too old, the server sends the complete list again.

UDP seems to suit this approach, since it's no biggy if once in a while an "update cycle" get's lost.