[Twisted-Python] distributed method calls in twisted.sister
background: twisted.sister is a piece of clustering infrastructure to allow a single application or simulation to be distributed across multiple servers on multiple hosts. twisted.sister has a concept of a "parent" server which acts as a central locking facility for objects distributed on any number of "sister" servers in the network. security in distributed sister servers: example use case: player1 logged into on one sister server wishes to send a text message to player2 logged into another - unknown - sister server. I implemented a "callDistributed" on the sister server which looks like: def callDistributed(self, resourceType, resourceName, methodName, *args, **kw): this goes off to the parent which looks up the sister that has the specified resource locked, then passes the method call off to that sister to actually be invoked. all results of course being deferred so the result is passed all the way back to the originating caller. so player1 would call: self.service.callDistributed( 'avatar', 'player2', 'chatMsg', 'hi there') and player2 would get the chat message. It currently prepends "remote_" to the method name on the callee's end. 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: def distributed_chatMsg(self, resourceType, resourceName, message) 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. 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. thoughts?
From: "Sean Riley" <sean@ninjaneering.com> Date: Mon, 8 Jul 2002 11:49:53 -0500
... 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.
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)
Maybe sister_... would be a better naming convention, considering its source?
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 |
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@twistedmatrix.com [mailto:twisted-python-admin@twistedmatrix.com]On Behalf Of Glyph Lefkowitz Sent: Monday, July 08, 2002 5:35 PM To: twisted-python@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@ninjaneering.com> Date: Mon, 8 Jul 2002 11:49:53 -0500
... 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.
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)
Maybe sister_... would be a better naming convention, considering its source?
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)----
On Thu, 11 Jul 2002 22:41:12 -0500, "Sean Riley" <sean@twistedmatrix.com> wrote:
Transience is a good idea, I agree. It should be possible to cache the shadow objects if you need to, but I imagine that would be a pretty rare case. Remember that a tuple of strings is an object too; it's just an object you can't edit the interface on.
Encapsulating the identification information into an instance (this is all I mean by "shadow object"; not that we should, by default, have lots of replicated-everywhere state) seems like it would give some leeway, since any modifications to what information was necessary could be modifications to the expected interface of that object, and not the signature of the methods. -- | <`'> | Glyph Lefkowitz: Traveling Sorcerer | | < _/ > | Lead Developer, the Twisted project | | < ___/ > | http://www.twistedmatrix.com |
From: "Sean Riley" <sean@ninjaneering.com> Date: Mon, 8 Jul 2002 11:49:53 -0500
... 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.
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)
Maybe sister_... would be a better naming convention, considering its source?
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 |
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@twistedmatrix.com [mailto:twisted-python-admin@twistedmatrix.com]On Behalf Of Glyph Lefkowitz Sent: Monday, July 08, 2002 5:35 PM To: twisted-python@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@ninjaneering.com> Date: Mon, 8 Jul 2002 11:49:53 -0500
... 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.
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)
Maybe sister_... would be a better naming convention, considering its source?
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)----
On Thu, 11 Jul 2002 22:41:12 -0500, "Sean Riley" <sean@twistedmatrix.com> wrote:
Transience is a good idea, I agree. It should be possible to cache the shadow objects if you need to, but I imagine that would be a pretty rare case. Remember that a tuple of strings is an object too; it's just an object you can't edit the interface on.
Encapsulating the identification information into an instance (this is all I mean by "shadow object"; not that we should, by default, have lots of replicated-everywhere state) seems like it would give some leeway, since any modifications to what information was necessary could be modifications to the expected interface of that object, and not the signature of the methods. -- | <`'> | Glyph Lefkowitz: Traveling Sorcerer | | < _/ > | Lead Developer, the Twisted project | | < ___/ > | http://www.twistedmatrix.com |
participants (3)
-
Glyph Lefkowitz -
Sean Riley -
Sean Riley