I'm working on a generic game server that manages games for an arbitrary number of TCP socket-networked clients playing a game. I have a 'design' hacked together with duct-tape that is working, but seems both fragile and inflexible. Is there a well-established pattern for how to write client/server communication that is robust and flexible? (If not, how would you improve what I have below?)
Roughly I have this:
- While setting up a game the server has one thread for each player socket handling synchronous requests from a client and responses from the server.
- Once the game is going, however, all threads except for one sleep, and that thread cycles through all players one at a time communicating about their move (in reversed request-response).
Here's a diagram of what I have currently; click for larger/readable version, or 66kB PDF.
Problems:
- It requires players to respond exactly in turn with exactly the right message. (I suppose I could let each player respond with random crap and only move on once they give me a valid move.)
- It does not allow players to talk to the server unless it's their turn. (I could have the server send them update about other players, but not process an asynchronous request.)
Final requirements:
Performance is not paramount. This will mostly be used for non-realtime games, and mostly for pitting AIs against each other, not twitchy humans.
The game play will always be turn-based (even if at a very high resolution). Each player always gets one move processed before all other players get a turn.
The implementation of the server happens to be in Ruby, if that makes a difference.