FlappCommand does not reconnect on DeadReferenceError to flappserver.

[nathan-at-least]

The FlappCommand caches a foolscap reference, but does not handle DeadReferenceError, such as if the underlying TCP connection breaks in https://github.com/LeastAuthority/leastauthority.com/blob/master/lae_util/flapp.py#L19

[warner]

Yeah, RemoteReferences are mortal. Simplest+safest thing to do is to call tub.getReference() each time. If that succeeds, there's a good chance an immediate callRemote() will succeed to (although it isn't guaranteed, of course).

[nathan-at-least]

Does foolscap reuse TCP connections for the same furl, or will N calls to getReference() lead to N TCP sockets being allocated / connected?

On Fri, Jun 6, 2014 at 3:40 PM, Brian Warner notifications@github.com wrote:

Yeah, RemoteReferences are mortal. Simplest+safest thing to do is to call tub.getReference() each time. If that succeeds, there's a good chance an immediate callRemote() will succeed to (although it isn't guaranteed, of course).

— Reply to this email directly or view it on GitHub https://github.com/LeastAuthority/leastauthority.com/issues/223#issuecomment-45391191 .

Nathan Wilcox Least Authoritarian

[warner]

It uses one TCP connection per (Tub/Tub) connection (specifically one per Broker), so calling getReference() multiple times won't waste connections. I think it should also give you the same RemoteReference object each time (if the connection wasn't dropped in between). The only inefficiency is that it will make a round trip (with a "getReferenceByName" call) each time, whereas if the connection was still intact, it really ought to be able to complete getReference() without touching the network.

[daira]

Probably the cause of #188 (but not the similar-sounding #192).