Sign in to follow this  

A rethink for my server design

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
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

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