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

[Mark S. Miller]

At 10:48 AM Friday 4/6/01, Tyler Close wrote:
>At 10:28 AM 4/6/01 -0700, Mark S. Miller wrote:
>>[...] would that be good enough for a deal?
>
>Since you seem so thin on time lately, I think I'd need some sort of 
>guaranteed minimum expenditure of MarkM hours.

Fair enough.  Since the resulting parallelism could very significantly 
shorten the delay to E 1.0, I consider this high priority.  I'll negotiate a 
quantitative answer with you privately, as soon as I get some feedback from 
some current customers of E, and the time-urgency of their need for a 
revived CapTP.


>For the implementation I have in mind, one in N checkpoints would be an "all 
>BLOBs" checkpoint, whose runtime would obviously be linear with the number 
>of BLOBs in the Vat. All checkpoints N - 1 would only write out the diff to 
>the previous checkpoint and so should be just as fast as in Lock.

However amnesia turns out, this sounds very promising. If someone wants a 
large scalable system serving paying customers at high performance and 
without occasional long delay, I have no problem saying to them "buy a Lock 
license and upgrade to Lock".  In fact, I think this kind of split is one of 
the better open source revenue models.

However, the cheezy system has to be adequate for smaller scale and amateur 
use, so it depends on the length and frequency of these delays.  What 
penalty results from making N larger? In any case, I suspect your occasional 
delays are about the same length as the delays I would have subjected them 
to at every checkpoint, so yours is probably a strict win.


>So, you could forget about amnesia if you're willing to suffer block-up once 
>every N. We could try to put some thought into how to schedule this Nth 
>checkpoint so that it was as palatable as possible. Maybe N is of variable 
>length and is only done if the Vat has been idle for some preset amount of 
>time.

Depending on the tradeoffs of N, and the resulting frequency and length of 
these delays, I suspect this is all something we can live with.

 From a dinner conversation last night, it sounds like Dean may have some 
further reasons for wanting amnesia support, having to do with recovery from 
larger disasters, which I'll leave to Dean to explain.  But it sound like a 
*normal* crash and revive may no longer have to result in a rollback visible 
to other vats.  It's at least promising.


>>In any case, this offer makes me very hopeful.  On to persistence!!
>
>Not so fast buster, lets finish up collections first! ;)
>
>Something done is progress. Something half done is not.

;) 

Once I do start in on persistence, my first task will be to try to resolve 
the Hydro question.  But reviving CapTP may have to come first.


        Cheers,
        --MarkM