hi im making my mmorpg server multithreaded... right now it is single thread and it sucks like shit but i have a problem... im not sure what is the best structure to implement these threads.. should i created 3 threads (polling, sending, and updating) for every client connecting it? so that means if i have 10 clients, i will have 30 threads... or should i create 3 static threads... they never go away, and then just make each thread do more work no matter how many clients connect to my server? thanks in advance! thomas

Multiplexing I/O is going to be more scalable than a thread per each client. Context switches and locking mechanisms are (relatively) expensive y'see.

Threading to take advantage of multiple processors (or cores) of a server is a bit different a matter, and is basically just about balancing parallizable (or orthogonal) tasks.

We have two basic threads in our game. 1 that handles the network traffic and another that handles everything else. This means that network traffic is handled in order as it comes in. At the moment this is ok for the size of our project.

I can say for sure that spawning a new thread for each connection is not a good idea and especially on a single processor since the overhead for all those threads would be rather large. Plus there is the whole realm of issues of sharing the data across all those threads. If you can limit similar stuff into one thread it greatly reduces the complications that can show up.

One idea maybe that you can setup is the idea of worker threads. So you can have a 'pool' of threads that are used as needed. So if you have small network traffic it might only take 1 thread to handle it all. If you have 5,000 connections you might might need several threads operating on the incoming data.

But for now I would limit yourself to 1 thread for network traffic and 1 thread for everything else.


-------
Andrew.

My server runs with no threads at all. There is really no reason to thread the server and then deal with writing thread safe code. My server runs at usually over 100,000 cycles per second and thats more than enough speed to make sure all packets are being processed.

What does a cycle mean in this context?

Quote:Original post by eraser_iresa
hi im making my mmorpg server multithreaded... right now it is single thread and it sucks like shit
but i have a problem... im not sure what is the best structure to implement these threads..
should i created 3 threads (polling, sending, and updating) for every client connecting it? so that means if i have 10 clients, i will have 30 threads...
or should i create 3 static threads... they never go away, and then just make each thread do more work no matter how many clients connect to my server?

For udp based servers, the most simple way to write them is to use a single nonblocking unconnected socket and handle messages in a single thread.

For tcp based servers, the most simple way is to use non blocking sockets for all i/o. (nonblocking means a recv might return a partial buffer and a send might only send the first part of its buffer and select never blocks)

Any wait or blocking should only happen in the timing code, this way the server can run smoothly. More traffic than what the server can handle will stall a multithreaded server too, only it will add lock contention too. (extra overhead)

Blocking i/o, especially database requests should be handled in a separate thread (or threads) and the main thread should interatct with those threads in an asynchronous fashion. (basic rule: the main thread should not block on anything)

To answer your original question about multiple threads:
The pooling of theads only shortens their startup time, and this should only matter if you have to create and destroy theads too often. (like in a webserver)

Viktor

ps: Personally, I prefer to make database connections use a nonblocking packet interface wrapper, this way client messages and database messages can be treated the same from the perspective of the game server. (example: client asks the game server for a stat, the game server asks the db for the stat, the db sends back the stat, the server sends the stat to the client, protocol checks are everywhere, all interfaces use a nonblocking packet based event handling structure)

Hi,

Game Programming Gems 4, paragraph 6.2 entitled "Thousands of clients per server" should be an interesting article for you. I suggest you somehow get your hands on it.

Cheers.
JA