Sign in to follow this  

Am I overcomplicating things my server?

This topic is 3859 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 wondering if I may be overcomplicating my server a little. When the comms thread receives data from the clients, I package it into a command buffer that is later picked up by the game thread when it next ticks. Every comms thread tick I package up updates from the game thread thats to go back to the clients (using a massive command output buffer). The output buffer is then processed and data is setn back to the clients. Would it be more efficient to simply pass input from the clients directly to the game thread acting upon it immediately then return any updated data back to the clients? Thanks again for any advice Mat

Share this post


Link to post
Share on other sites
Your not necessaraly overcomplicating it. There are pro's and cons to your approch of course. It will hinder response times slighly im sure, but the way im reading it its also making sure things happen in the proper order and provides a "timeframe" for clients to respond. This can help level the playing field quite a bit. It can also be used to prevent "flooding", ala the server sending a huge amount of actions all at once , because its then easier to disregard more then 1 action in a particular frame. Most of the overhead of what your providing is negated by the fact your going to have more complicated collission detection and such and have built in ordering in the engine which would require more work in the long run.

Share this post


Link to post
Share on other sites
What CPU utilization do you have on the Comms thread? My guess is it uses less than 10% of a CPU core. If that's the case, it's just sitting there, doing not much, and you could just as well do all your processing in the main thread.

Note that it's still a good idea to separate receiving/buffering, processing, and then filtering/sending data in three separate phases.

Share this post


Link to post
Share on other sites
My view is that MMO servers should be "asynchronous" and "network driven", meaning that unless an operation could potentially block, it should be handled in the thread that pulled the request off the network. That said, I believe that game servers are an execption to this. It's really convienent to have the game server split into asynchronous and synchronous contexts, the async context roughly defined as the set of threads that pull messages off the network, and the synchronous context being a single thread that drives the game's app-level server-side operations. There may be multiple synchronous contexts in your game server process - say if you're running multiple isolated maps or zones - but only ever a single asynchronous side. The basic idea is as you said: Net recv threads queue commands in the appropriate synchronous context's command queue for processing in that context. Some benefits to this method are:

* Ease of scripting: If you have scripted logic running on the server, the interpreter may not be able to handle concurrent calls. Even if you're scripting in native code, you can rest easy knowing you're writing single-threaded code which allows you to more quickly and easily develop your game logic.

* Segfault isolation: If you're running multiple synchronous contexts within your game server process, you can put a big 'ol try/except block around the thread's main loop which will serve to isolate fatal crashes to the context in which they occur (very handy!).

* Shared code: You can link with existing client libraries that may not be thread-safe (for things like resource loading).

* Replayability: You can only playback a game if you can recreate the exact sequence of commands in the same order. This is much easier to do single threaded.

HTH

Share this post


Link to post
Share on other sites
This is basically what I was asking about in my thread...
http://www.gamedev.net/community/forums/topic.asp?topic_id=448993
I have a thread that does the connections, one using select (probably will change) to call receive on sockets that need it, which in turns takes the packets and packs them into a receive buffer. Then the last thread processes the receive buffer constantly, but this will change more than likely into just a method that will get called every so often.

Share this post


Link to post
Share on other sites

This topic is 3859 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this