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

[Sean Riley]

sister_* instead of distributed_* is probably a good idea.

I'm not convinced of the need for shadow objects. They could lead to an
explosion (N^2 !) in the number of python objects in a distributed system.
If they do exist they at least should be transient if possible.

I agree there probably needs to be a better mechanism for identifying the
calling object and allowing it to present information, but I dont have a
solution to suggest yet. Working on it. I'm going to complete distributed
login with multiple services before focusing on inter-object communication
across sisters.



-----Original Message-----
From: twisted-python-admin at twistedmatrix.com
[mailto:twisted-python-admin at twistedmatrix.com]On Behalf Of Glyph
Lefkowitz
Sent: Monday, July 08, 2002 5:35 PM
To: twisted-python at twistedmatrix.com
Subject: Re: [Twisted-Python] distributed method calls in twisted.sister


----Security_Multipart(Mon_Jul__8_17:35:13_2002_516)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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      |

----Security_Multipart(Mon_Jul__8_17:35:13_2002_516)--
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA9KhOnvVGR4uSOE2wRAjdBAJ9VR7vIXHCuX1iMgV2jDyyJixBNCgCdHyG7
t4FifGq+MMb579KMU6/ZkqM=
=3A6W
-----END PGP SIGNATURE-----

----Security_Multipart(Mon_Jul__8_17:35:13_2002_516)----