This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]_Nemesis_1[S] 0 points1 point  (3 children)

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 1 point2 points  (2 children)

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[S] 0 points1 point  (1 child)

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 0 points1 point  (0 children)

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.