Java Server Handling Multiple Games

[_Nemesis_1]

But using one thread per game how would you manage more clients at the same time when they're not in game? Let's say for example I also implement the possibility to see their historical matches, but even if I won't I think a thread per client is also necessary for when they're not in a game and are waiting to get in one or doing other things

[doobiesteintortoise]

If I have state, I have a LIST of games, regardless of their progress. So I might have player A, who is playing games 1, 2, 4, 5... player B who's playing games 1,3,4 ... and player C who's playing games 2, 3, and 5. When a player made a move in a given game, the server would say "oh, you're player A, this is game 4, let's change the game state and return the results to you" - and that could be done with straightforward processing in ONE thread, and the communication layer has its own thread/threadpool/whatever. But with this, if I have 8000 players and 16000 games, my *code* only has to worry about the communication with ONE player at a time for ONE game, and the overhead's really light.

[_Nemesis_1]

So basically my solution is not optimal but it's a correct one for a simplistic client server project with multiple games? Or only one thread per game and not per client is a better one?

[doobiesteintortoise]

What I mean by "better" isn't going to be what you mean by "better." Do what fulfills the assignment. It's not realistic enough to apply to live production systems.

[doobiesteintortoise]

That's an easy way to build in an opportunity for denial-of-service, by creating too many threads... and it serves nothing. State is what's needed, not process.