Jump to content
  • Advertisement
Sign in to follow this  
sipickles

A rethink for my server design

This topic is 3767 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, At present, I use Stackless Python for my game servers. Networking is thru twisted. I have a 'gateway' server which validate clients and passes them on to the 'zones'. I am stumbling on the 'zones' a little. My code seems to get a little spaghetti-fied after a certain level of complexity is reached. So I am after advice about how to structure the server? Stackless lends itself to the actor-model well, which I have used. I have a player (connection) manager, spatial(quadtree) manager, object manager. Database access is asynchronous through twisted too. I'm trying to keep everything OO, but after a while there seems to be so much interdependancy building up! _back_to_the_drawing_board_ Thanks for any advice, thoughts, motivation! ;) Si

Share this post


Link to post
Share on other sites
Advertisement
That's the problem with current async programming model. There's currently no language that would adequately support active objects.

The only way to get by this would be through IDL generation that would construct the underlying scaffolding and hide the message passing, which is what J2EE and other enterprise frameworks do through RMI and equivalents.


In a pure actor model, you wouldn't have any dependencies at all, you'd be passing everything recipient needs to know through messages, and actor's members would be completely hidden from everyone else. In practice however, actor model is only suitable for coarse-grained communication due to considerable overhead associated with communication.

For example: Object objects would know only about object manager. Object manager would know about "World" master object. Of object wishes to say something, it sends a message ("MyName", [24.50,88.70], "SAY", "Hello World!", "everyone") to object manager. which in turns delivers it to every ("everyone") object it knows about ("MyName", [24.50,88.70], "SAID_SOMETHING, "Hello World!").

As such, recipients don't need to know about sender.

Under proper actor model, you'd have zero coupling, similar to event dispatching. That's the primary premise behind scalability, minimally/no shared state.

As such, it's then possible to distribute the actors arbitrarily, or if need be, run multiple instances of same type of actor to reduce the load.

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!