[E-Lang] remote comms: Timeouts and Connection Failure

[Karp, Alan]

MarkS wrote:
> 
> It is certainly the case that one needs to be able to 
> implement impatience
> policies other than (or in addition to) the keepalive stream. 
> That is why I
> posted the code that enables one to construct such policies 
> easily. In my
> experiences to date, however, the keepalive stream has been 
> both necessary
> and sufficient most of the time. In other words, my 
> experiences suggest it
> makes a reasonable default policy.
> 

A colleague of mine likes to state the problem as being due to 3 possible
outcomes from sending a message that requires a reply.

OK - I got what I expected when I expected it.

BURP (bad or unexpected response processed) - I got something when I
expected it, but it wasn't what I expected.

NAP (not answering promply) - I didn't get anything when I expected it.

Of course this last case is the one that causes all the problems.

Obviously, notification of a lost connection is a BURP.  I choose to
categorize missing keepalives the same way.  That means that I still need a
default policy to deal with NAP due to a slow or erroneous application.

_________________________
Alan Karp
Principal Scientist
Decision Technology Department
Hewlett-Packard Laboratories MS 1U-2
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-6278
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp/
 

> -----Original Message-----
> From: Marc Stiegler [mailto:marcs@skyhunter.com]
> Sent: Friday, April 20, 2001 9:20 AM
> To: zooko@zooko.com; Karp, Alan
> Cc: e-lang@eros-os.org
> Subject: Re: [E-Lang] remote comms: Timeouts and Connection Failure 
> 
> 
> > It boils down to:
> >
> >   If you use the `stream of unforgeable keepalives' 
> impatience policy, you
> are
> >   depending on the behaviour of your counterparty to implement your
> impatience
> >   policy.  This may or may not be correct behaviour from 
> the point of view
> of
> >   your actual top-down requirements.
> 
> It is certainly the case that one needs to be able to 
> implement impatience
> policies other than (or in addition to) the keepalive stream. 
> That is why I
> posted the code that enables one to construct such policies 
> easily. In my
> experiences to date, however, the keepalive stream has been 
> both necessary
> and sufficient most of the time. In other words, my 
> experiences suggest it
> makes a reasonable default policy.
> 
> --marcs
> 
> _______________________________________________
> e-lang mailing list
> e-lang@mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/e-lang
>