Jump to content
  • Advertisement
Sign in to follow this  
eraser_iresa

MMORPG Server Threads

This topic is 4316 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
The right forum for this question is Multiplayer and Networking.

And the forum FAQ for that forum actually has some answers to those questions :-)

Share this post


Link to post
Share on other sites
A thread per connection is surely a bad idea. Im a total newbie in this topic, but my current design uses a thread for listening and another to do server operations. Maybe you would like to use an extra thread to deal with AI.
Anyway, perhaps Im just totally wrong about this.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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)

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Quote:
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


recv() may return a partial buffer even if it is blocking, and send() may send part of its data even if it's blocking.

The difference is that recv() on a completely empty buffer will wait if it's blocking, and return an error if it's non-blocking (same for send).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!