Do I need multithreading?
Author
I''m making a small MUD server, and I wonder if I need multiple threads. Currently my server is rather naive, it parses and obeys the commands that players write, and when it has nothing to do, it waits.
When does this become a problem?
I made some simple profiling, and the server currently can execute about 1000 player commands per second, depending a little on the command. I''m not expecting this to become a grand-scale game, but being able to handle 50 online players would be nice. That gives 20 commands per second, per player. (Which is more than necessary. Many MUDs have a limit, 2 per second or so.)
Is stability an issue? Are jammed threads easier to ignore? Currently, if a command crashes the parser, or throws it into an infinite loop, all players are halted. The project is not enormous, so nailing down crashbugs shouldn''t be impossible. *knocks wood*.
Most servers out there are multithreaded, and there must be a reason. I just can''t think of one good enough.
Do you have more than 1 processor?
If not, then multithreading is just for your own amusment. Non-blocking sockets are just fine for single processor systems.
Ben
If not, then multithreading is just for your own amusment. Non-blocking sockets are just fine for single processor systems.
Ben
Author
Single processor here. Thanks for the fast reply.
I doubt it would work as amusement, though. From browsing the MUD developement mailing list, people are having enormous trouble getting multithreading to work, with locking objects and whatnot. Without being armed with a good reason, I''m not stepping there.
I doubt it would work as amusement, though. From browsing the MUD developement mailing list, people are having enormous trouble getting multithreading to work, with locking objects and whatnot. Without being armed with a good reason, I''m not stepping there.
>> Non-blocking sockets are just fine for single processor systems.
Gotta disagree there..
I''ve written numerous network servers and multi-threading is used in all but the most trivial of cases.
If one thread is servicing 100 people, and one client makes a request (or command, etc) that takes, say, 200ms to process [an SQL lookup, perhaps? lots of possibilities..] then ALL other clients are blocked during those 200ms. Get 5 out of the 100 people doing that semi-consistently, and you''ll start to see significant lag across the board.
At one extreme, you have 1 thread handling all clients (with non-blocking sockets, of course.)
At the other extreme, you have 1 thread for EACH client. Best scenario for throughput, but can be "expensive" with lots of clients.
What a lot of people do is go for the middle-ground.. 1 thread to handle UP TO (N) clients, where (N) <= 64 or 32 or 16.. you pick the number that best works.
As far as locks and synchronizing, etc.. It''s something you''ll have to learn. Best way to do that is to pound out some mini test projects until you understand exactly how they do (and don''t) work.
Hope this helps!
// CHRIS
Gotta disagree there..
I''ve written numerous network servers and multi-threading is used in all but the most trivial of cases.
If one thread is servicing 100 people, and one client makes a request (or command, etc) that takes, say, 200ms to process [an SQL lookup, perhaps? lots of possibilities..] then ALL other clients are blocked during those 200ms. Get 5 out of the 100 people doing that semi-consistently, and you''ll start to see significant lag across the board.
At one extreme, you have 1 thread handling all clients (with non-blocking sockets, of course.)
At the other extreme, you have 1 thread for EACH client. Best scenario for throughput, but can be "expensive" with lots of clients.
What a lot of people do is go for the middle-ground.. 1 thread to handle UP TO (N) clients, where (N) <= 64 or 32 or 16.. you pick the number that best works.
As far as locks and synchronizing, etc.. It''s something you''ll have to learn. Best way to do that is to pound out some mini test projects until you understand exactly how they do (and don''t) work.
Hope this helps!
// CHRIS
quote:Original post by win32mfc
As far as locks and synchronizing, etc.. It''s something you''ll have to learn. Best way to do that is to pound out some mini test projects until you understand exactly how they do (and don''t) work.
Heh, I think the rest of your advice is good, but I have to disagree with that last line. There are a lot of non-obvious problems that can be caused by threads, locks, synchronization, etc, that I doubt anyone can pick up just by writing test projects (unless you know exactly what types of test projects to try and write). I would definitely recommend getting a book for this stuff.
A small MUD-server doesn''t need any multi-threading. Games with hundreds of players work just fine by calling select 4 or 8 times a second and servicing all input requests that way. Obviously if you have a lot more traffic than the average small MUD or need to have something more like real-time response then you might consider threading as one of several options available.
[ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost
Asking Questions | Organising code files | My stuff | Tiny XML | STLPort]
[ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost
Asking Questions | Organising code files | My stuff | Tiny XML | STLPort]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
