Desig decisions on multiplayer-multitable poker game

You're giving us way too little information. What's your deployment OS? Language? Framework? Are you using an application server? Are you using HTTP and a browser, or Flash, or an installable client for your game client?

Multithread for each client is a terrible idea, no matter what the host OS.

If you want to scale reasonably with threads, I'd suggest one thread per table, serving all the clients for that table. It'll probably still create too many threads to be optimal, but it's a good start.

Best would probably be to have one worker thread per CPU in the server box, and use asynchronous I/O (I/O completion ports on Windows, aio on Java, kpoll or libevent on Linux, etc). The boost::asio library abstracts this for you pretty nicely.

Quote:

Original post by hplus0603 Best would probably be to have one worker thread per CPU in the server box, and use asynchronous I/O (I/O completion ports on Windows, aio on Java, kpoll or libevent on Linux, etc). The boost::asio library abstracts this for you pretty nicely.

I tried boost::asio library specially its async io and socket and its very good. Thank you for this info :)

Now how do i implement my game tables? Is having the table as a separate thread ok? my original plan is 1 thread per game table and just to suspend the thread when it is waiting for "action" from players and to resume/wake-up the thread when there is computation needed.

Is this a good approach?

I was looking for a way that a certain thread or function (similar to asynchronous IO) will be triggered only when a certain action is needed. Because in poker its not all the time that game tables need to compute something.

Quote:

Original post by cebugdev Now how do i implement my game tables? Is having the table as a separate thread ok? my original plan is 1 thread per game table and just to suspend the thread when it is waiting for "action" from players and to resume/wake-up the thread when there is computation needed.

You didn't grok the asio approach then.

The idea is, you create either a single thread, or as many threads as there are cores. These are workers which handle completions from io_service.

When a request completes, you perform whatever action needs to be done in response. So for each player, you post an async read request. Whenever that completes, if the data received is complete (not fragmented via TCP or similar), you execute the action. Player is obviously associated with a table they joined. Then post the responses, and new receive request.

If running with single worker thread, then no synchronization is needed. If multiple threads are used, a simple lock on table should be enough.

Quote:

I was looking for a way that a certain thread or function (similar to asynchronous IO) will be triggered only when a certain action is needed. Because in poker its not all the time that game tables need to compute something.

Everything should happen in completion handler. Periodic actions can be scheduled via timer, but shouldn't be needed.


Note that while the API and its usage doesn't change with number of workers, only single worker thread may be used without synchronization, everything else must be manually synchronized.

Strands achieve the same goal, but don't really scale all that well in hundreds since they're intended for different purpose.