requirements for comms (was: Re: [E-Lang] Security Breach: Nominee for the Stock Exchange Prize)

[zooko@zooko.com]

 Bill wrote:
>
> At one point, application level keep-alives were suggested as an
> alternative to system level ones.  I was showing that application level
> keep-alives probably would have the same problem as system level ones in
> the case where the requestor expected a response, and the requestee decided
> that no response was necessary.

Good point.  I was thinking of an impatience policy that didn't have keepalives
at all, which means that the keepalives never predict nor mispredict the
eventual results, for good and for ill.


> That makes sense.  I don't know that E will be supporting the Mojo Nation
> abstraction of, "Many sources, any of which can provide a useful response"
> as a basic primitive.  That is the environment where the Mojo Nation
> timeout dilemma becomes most acute.

Good point!  I'm not sure what a "typical" E app needs in this respect.  The
other kind of transaction we have in Mojo Nation is where a given source is the
only one that can provide the response, but in that case we can definitely not
time-out, nor allow low-level keepalives to deter us from retrying until we get
what we want -- that is when doing transactions with the Token Server.


> One thing we could provide is the recent minimum observed round-trip time
> on a path.  Than people could avoid a 60 second timeout on a Mixmaster
> email path.  :-)

Good point.  On the other hand, if I were using a keepalive impatience policy, 
I think I would be happy to let the lower-layer code decide how to do keepalives
in order to have early and accurate prediction.


Regards,

Zooko