• Advertisement
Sign in to follow this  

MMORPG Server Threads

This topic is 4136 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
Would a thread pool be a good idea? Like, if every message received was put in a pool and processed.

Share this post


Link to post
Share on other sites
>Would a thread pool be a good idea? Like, if every message received
>was put in a pool and processed.
Look into i/o completion ports - that's probably what you need
(more or less works this way with a few threads processing
events in the iocp 'pool' ).

You could check out codeproject, it has an article 'echo server'...
I used that tutorial to get my (work-in-progress) iocp implementation running

[Edited by - Kitt3n on October 27, 2006 3:08:01 AM]

Share this post


Link to post
Share on other sites
Does your mmorpg have distict areas of some kind ?
if so its not a bad idea to let each area be managed by its own thread. or even by its own physical server.

dividing the load this way has multiple advantages.

1. very little sharing of data, if the areas are 100% separated (zoning) the only shared data is chat traffic. (if you got global chats), if they aren't fully separated you only need to share border information, this could be done easily using sockets.

2. makes it easy to move highly populated areas such as cities , pvp arenas etc to their own server. If your going to selfhost it also allows you to spread the network load over multiple connections easily. (getting one huge connection is generally alot harder than asking a few friends to help you with hosting)

Share this post


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

  • Advertisement