[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