[Twisted-Python] distributed method calls in twisted.sister

Glyph Lefkowitz glyph at twistedmatrix.com
Mon Jul 8 18:35:13 EDT 2002


From: "Sean Riley" <sean at ninjaneering.com>
Date: Mon, 8 Jul 2002 11:49:53 -0500

> twisted.sister is a piece of clustering infrastructure to allow a single
> application or simulation to be distributed across multiple servers on
> multiple hosts.

... with unit tests that aren't currently passing ;)

> twisted.sister has a concept of a "parent" server ...

We do need to rename this to the "mother" server sometime soon.

> I implemented a "callDistributed" on the sister server which looks like:
...
> This appears to be inconsistent with the common twisted notion of knowing
> "who" is calling a method for security reasons. Maybe there should be
> another type of remote method called "distributed_" which takes the
> identifying information of the calling distributed object as the first
> arguments:

Hmm.  I agree with the "distributed_" idea, but I'm not so sure about the
identifying information being presented as such.  This seems like a use case
for "shadow" objects; if you're getting a message from another user, your
sister-server must know _something_ about that user.  In this case, it looks OK
to simply present their resource-ID (which should be the same, as far as we
know, as their username).

I can easily imagine adding to this use-case so that each user has a face-icon
associated with them, or some other immediately displayed information.  On IRC
this mirrors the userhost/nickname pair (immediately visible information) and
the userinfo/whois database (key queryable information).  This is a balance
point which has to be easily tunable for an application.

The other problem with this identifying information is that it's not presented
as part of a path.  My initial attempt at shoehorning twisted.sister into the
callPath paradigm was unfortunate :-)... but having an abstract hierarchy where
resources can be mounted/unmounted seems like a good idea to me, still.

I don't know if callPath is necessarily the best way to do that, though.  It
seems that twisted.web's got the best way of handling that so far; a
formalization of what twisted.web.distrib does would probably be best.  (It
would be really, REALLY nice if we could get twisted.sister clustered web
services for free out of that, somehow)

> where the resourecType and resourceName identify the distributed resource
> that invoked the distributed method call. this distributed_ method would
> only ever be invoked by remote objects managed in a twisted.sister network.

Maybe sister_... would be a better naming convention, considering its source?

> I thought about adding the location of the distributed caller object also,
> but this information probably isnt required as it is known by the parent who
> can route any further communication. the location could also change if an
> object migrated between sisters which would invalidate any location
> information stored on a sister, so not sending it is a better option.

Agreed -- routing information has to be handled by the parent.  I take it this
means that messages will also be queued by the parent, in order to avoid losing
them?

-- 
 |    <`'>    |  Glyph Lefkowitz: Traveling Sorcerer   |
 |   < _/ >   |  Lead Developer,  the Twisted project  |
 |  < ___/ >  |      http://www.twistedmatrix.com      |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://twistedmatrix.com/pipermail/twisted-python/attachments/20020708/f123dc9b/attachment.pgp 


More information about the Twisted-Python mailing list