[E-Lang] Hash Chaining & Capabilities, Proposal #1b: SimplifyingPluribus

[Mark S. Miller]

At 01:12 AM 11/9/00, Tyler Close wrote:
>I had assumed that the pipelining was only with respect to a single
>batch of invocations. I didn't realize that Pluribus additionally
>pipelined the batches. I do not pipeline the batches in Droplets. I
>wait for a response, and smash the return value promises if I don't
>get it. When does E smash the return value promises if the remote Vat
>never responds?

Every inter-vat connection is implemented at the Data-Pluribus level by 
SSL-like bi-directional reliable-up-to-fail-stop secure byte streams on top 
of TCP.  Because we can't rely on the TCP keep-alive-timeout mechanism (I 
don't remember why, but I think it's because the timeout functionality isn't 
available on all platforms), we implement our own keep-alive-timeout 
mechanism at the Data-Pluribus layer.  Every so often, each side sends a 
keep alive token to the other.  If the timeout period goes by without one 
side hearing from the other, it unilaterally decides that this connection is 
dead.  Eventually, if the other side is still alive, this must result in the 
other side realizing the connection is dead as well.  (Formally, the two 
sides must have "eventual common knowledge" of connection death.)

(Bill, please correct or clarify any of my confusions.)

When the Data-Pluribus handler reports connection death to the 
Object-Pluribus handler, the Object-Pluribus handler smashes all remote 
references from this vat to the other vat, including the unresolved promises 
(RemoteVows) for earlier messages sent from this vat to the other vat.