Multi threading and server design
Author
I'm in the UML-ish phase of my next game which is going to be online multiplayer connect four. I plan HawkNL and TCP. The purpose of this game is to learn server design.
As I currently have it there's one thread that runs a meeting room, in which all the players that are not playing a game can challenge each other. When two players are ready to play, a new thread is spawned for their game.
What I want to know is if my reason for a multithreaded design is correct. I haven't taken any networking classes yet (damn general ed).
-----------
The reason I want to use a multithreaded design is because if there's 1000 people on the server (yeah it's not going to happen, but let's pretend there is), and the first 500 players are 56kers, players 500 and 501 would have to wait if I had it like this:
check for activity on socket 0
check for activity on socket 1
check for activity on socket 2
...
...
...
check for activity on socket 500
etc, etc
Where as with concurrent threads I'll have something like this per thread:
while(!gameOver)
{
handle socket events from player 1
handle socket events from player 2
logic
send sync data to players
}
that way at the most they'll have to wait for one user since all the games are running concurrently.
-----------
So is my reasoning correct and my design ok?
Not exactly. First, with multiple threads, things still don't actually run concurrently. Each core can only run one thread at a time. It is however, free to switch to executing another thread whenever the OS likes.
But if each of your 500 threads still have to constantly poll fort activity on their sockets (the way you showed in your nonthreading example), then it won't really make a difference.
Usually though, you don't need to do that.
Either use blocking sockets, where the thread is set to sleep until there's activity on the socket (maybe that was what you meant in your threading example?)
Alternatively, you can use nonblocking sockets, in which case a single thread gets information on *which* sockets are currently available for receiving/sending. That way, you dont need to check all sockets sequentially, only the ones that actually have something for you to do.
But if each of your 500 threads still have to constantly poll fort activity on their sockets (the way you showed in your nonthreading example), then it won't really make a difference.
Usually though, you don't need to do that.
Either use blocking sockets, where the thread is set to sleep until there's activity on the socket (maybe that was what you meant in your threading example?)
Alternatively, you can use nonblocking sockets, in which case a single thread gets information on *which* sockets are currently available for receiving/sending. That way, you dont need to check all sockets sequentially, only the ones that actually have something for you to do.
Instead of running all those threads you just program your sockets to run asynchronasly. When you get a message it does a callback that processes the information, this keeps your thread from being blocked (not being able to do anything else until the information is processed).
TheTroll
TheTroll
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
