On Mar 28, 2008, at 9:18 AM, Simon Pickles wrote:

Midway thru my server dev, I am seeing the light... well, a light anyway.

Its a stackless python server and not too bad, running on Ubuntu Linux. Stackless Python is great, but single threaded (I DO do my DB lookups and network comms in other threads).

I figure its GOT to be more concurrent, if I'm looking to use future architecture.

So I planned to rewrite the server into modules, each a separate app. I guess this is a virtualisation process. Labour could be subdivided spatially, or by task (db access/playermanager/AI), or both

I'm going to go ahead assuming you know where your load problems are (or will be), and which things are most in need of being separated into components. Of course, this is pretty much the hardest part.

The modules plug in to each other, communicating thru the network (twisted).

This means the prototype server would run all the module apps on a single machine, then spreading to other machines to allow scalability. Being async networked (hinged on twisted.deferred), these modules run concurrently, using all the cores available.

SO - Am I reinventing the wheel? Does Twisted do this, or other Frameworks? In my limited experience, I need to create a server hub then have all the component modules connect to that as clients.

Is there a better way?

I don't believe there's nothing in Twisted that implicitly provides the functionality you're talking about, but you have a wide array of options on how to implement this yourself. It all depends on what kind of information you'll need to pass between modules, and how much refactoring you're willing to do to the existing application. The biggest issue will probably be making a uniform and maintainable way for modules to discover each other and make connections without introducing security holes. If you are sure to have complete control over the network they're running on (say, in a private IP space) this may be a non-issue, so it's really just about logistics. My initial reaction was to suggest Perspective Broker, but someone else might recommend AMP, which I'm just starting to learn the ins and outs of.... -phil

On Mar 29, 2008, at 12:53 PM, Simon Pickles wrote:

Linux user #458601 - http://counter.li.org.

Phil Christensen wrote:

...

If you are sure to have complete control over the network they're running on (say, in a private IP space) this may be a non-issue, so it's really just about logistics.

Yes, This system would be in Private IP space.

...

My initial reaction was to suggest Perspective Broker, but someone else might recommend AMP, which I'm just starting to learn the ins and outs of....

I'll look at PB, but have not found twisted doc very accessible. As for AMP, what is that?

I found the PB docs pretty reasonable, but I was already fairly comfortable with asynchronous network programming, which is really a required step before Twisted starts making sense. This one was the most help: http://twistedmatrix.com/projects/core/documentation/howto/pb- usage.html I'm pretty fond of PB, but I don't really use a lot of the more advanced features. Its applicability is definitely dependent on what kind of data you need to send between your various nodes... As for amp, I was recently passed this link: http://twistedmatrix.com/documents/current/api/ twisted.protocols.amp.html But I'm still processing it ;-)... On Mar 29, 2008, at 8:51 AM, Simon Pickles wrote:

Particularly I hope to be able to make deferred requests across a network. I'd like to have a hub server, with many small apps (modules) which are all clients of the hub server.

I'd like the modules to be able to request information from each other, via the hub, in a deferred way, so the callback will be triggered when the requested information arrives.

This is definitely the standard behavior of PB, and in fact, much of Twisted. Network requests always happen asynchronously, and trigger their Deferred's callback function like any other deferred event.

So I need a chain like this:

ModuleA.RequestName(id).addCallback(modACallback) -> Hub Hub.RequestName(id).addCallback(hubCallback)-> ModuleB ModuleB.SendNameToHub() -> Hub Hub.hubCallback triggered: SendNameToModA() -> ModuleA ModuleA.modACallback triggered - request is complete.

Perhaps one issue is that I have a client->server->client sequence.

That shouldn't be an issue. This is a very reasonable command flow, and dealing with it elegantly in your app is more a matter of design choices than protocol.

Although it looks slow, I am designing my system to be as concurrent as possible. Also, the hub can make decisions about sharing requests with several modules on a round-robin, or sending requests (and events, particularly) to more than one module.

I know I can do this through TCP or similar, but hoped someone might suggest which elements of twisted (a very large framework) I should look at more closely.

I think you'll find that PB is easier to pick up initially than AMP, but if you require a more advanced protocol (e.g., something that can't be expressed in terms of python method calls and responses, or that needs very robust exception handling), AMP will probably work better in the long run. I do have to emphasize though that this is my opinion based on limited exposure to AMP, perhaps someone else can chime in with better info... -phil