[Twisted-Python] a proposed extension for pb
sean at twistedmatrix.com
Mon Feb 11 21:26:33 EST 2002
"Publishable" extension to Twisted PB
Publishable is a proposed new type of distributed object for twisted.spread.
It is similar to the Cacheable class (which caches object state information
for the duration of a session), but it adds the capability to cache object
state information on remote nodes across multiple sessions.
Publishable objects would use the local file system on remote nodes to cache
object state information. This "published" state data would include
identifying information that allows the cached objects to re-establish their
relationships with their server-side counterparts the next time that the
object is activated during a session with the same server.
The published data for an object would include:
- the server that it came from
- the service that the object was part of
- the perspective/identity that it was accessed through
- the identity of the object
- the date and time of the state snapshot
Some of this data would be shared for multiple objects instances from the
same publishing location and could possibly be embedded in the file names or
directory structure of the local cache.
The timestamp of the snapshot of the object state could be used to allow
auto-refreshing of state of published objects. When a published object is
re-activated, if it's timestamp is before the timestamp of it's server-side
counterpart, the it could be updated with the new state of the server-side
object. (this should happen transparently _before_ the object instance is
available to client-side user code)
Published objects on the client would only be re-activated by the server
"sending" a new instance of the same to the client. Of course, it doesnt
actually send the entire new state for the object, just the identifying
information and timestamp - this initiates a handshake sequence that results
in the full updating and re-activation of the object.
This functionality was originally designed for dealing with persistent world
data for online games - the world state data including houses, terrain,
items on the ground, etc. However, it appears to have much broader
applicability and could be used for fairly generic replication and
clustering of application data.
* "stateless" object references could be a generic solution to the server
identification problem. some kind of pb:// URL to identify publishable
objects... (and/or all types of Twisted objects)
* Re-caching or re-publishing of objects through hierarchies of Twisted
* the overhead of the handshaking process that re-activates published
objects could introduce significant latency. care should be taken to minize
the amount of back-and-forth between client and server
"If it's not running programs or fusing atoms, it's just bending space.",
"That's it, I'm outta here.", Homer Simpson's Brain
sean at ninjaneering.com
More information about the Twisted-Python