[Twisted-Python] Recovering PB references on broken connection?
I've been experimenting with the perspective broker in Twisted 1.1.0 and am wondering? Is there any graceful way to reconnect and continue to use PB references if you temporarily lose a connection due to a network outage? For example, I can envision my application as being a client that connects to a remote application server, and while running may have any number of PB references to that remote application server in various data structures in the client. Should there be a transient network outage such that the TCP session to the server is interrupted, I'd like to be able to reconnect without having to flush all such data in the client. I'm still experimenting, but the docs and some early tests would seem to imply that if the TCP link breaks for any reason then any of my object references can never be used again. Is that in fact true and/or is there any way to avoid such a condition? I was hoping that I could catch network errors in some manner such that I could try to re-establish the PB link, and then permit existing references from the prior connection to continue to function could severely impact a client (or certainly impose a potentially large effort to restore any remote state to newly viable references). What do other perspective broker applications do about being as robust as possible in the presence of transient network conditions? Thanks for any info/suggestions. -- David
On Mon, Dec 22, 2003 at 07:23:45PM -0500, David Bolen wrote:
I've been experimenting with the perspective broker in Twisted 1.1.0 and am wondering? Is there any graceful way to reconnect and continue to use PB references if you temporarily lose a connection due to a network outage?
PB references are managed by the connection's Broker object, which is created anew in the factory's buildProtocol method, and the object/reference cache of which is cleared when connections are lost. Having references which can withstand disconnects should be doable relatively easily - all you need to do is make sure the same Broker objects get used for all subsequent reconnections. This may be a little tricky, since you need to differentiate between new connections and reconnections (which you can't do easily with PB, because you'll already have a Broker), but should be entirely possible. I'm not sure if there is any reason, other than trickiness factor, that this isn't implemented directly in twisted.spread. Perhaps there is a hidden issue I am unaware of, or maybe it is simply that no one has wanted it badly enough to write it :) Hope this helps, Jp
On Dec 29, 2003, at 11:52 AM, Jp Calderone wrote:
I'm not sure if there is any reason, other than trickiness factor, that this isn't implemented directly in twisted.spread. Perhaps there is a hidden issue I am unaware of, or maybe it is simply that no one has wanted it badly enough to write it :)
Reference counting. There has to be a meta-connection around to hold references to the "live" state, which, IMHO, would be better implemented as an extra-robust byte-level stream at a lower level. Even with such a connection, it's bad to count on the stateful existence of references to individual objects which stay live over a long period of time. The initial login handshake should get you to a "naming" object within a few steps, and then have a higher-level API for loading published objects from persistence or wherever. Right now this has to be ad-hoc because there is no clear universal way to specify persistent, reliable object IDs that are "macro" enough not to change when small implementation details of the protocol shift. Any object has to have an ID number that can be compared for identity but some objects are more equal than others.
participants (3)
-
David Bolen -
Glyph Lefkowitz -
Jp Calderone