[E-Lang] New Page: Partially Ordered Message Delivery

[Karp, Alan]

> -----Original Message-----
> From: Tyler Close [mailto:tclose@oilspace.com]
> Sent: Monday, March 05, 2001 1:44 AM
> To: Karp, Alan; zooko@zooko.com
> Cc: E Language Discussions
> Subject: RE: [E-Lang] New Page: Partially Ordered Message Delivery 
> 
> 
> Alan Karp wrote:
> > You say "each programmer has to implement logic ...", but
> > that's not the
> > case if you provide the appropriate library running in the
> > sender's address
> > space.
> 
> Yes, I tried this as well, but I didn't like it. First, there are two
> barriers to it:
> 
> 1) Point 2 I made in the email: "Often, the recovery strategy was
> "Just send the message again".
> Client code is not in a good position to know when to resend the
> message. Really, you want the Vat to do this work, since it is in a
> good position to notice that the remote Vat is online again and that
> the lost messages can be retried."

A good point consistent with our experience.  It was simply outweighed by
our other requirements.

> 
> 2) It requires that the client code have the abilility to instantiate
> the receiving side of the message handling protocol on the remote
> host. It's not clear to me that all clients should be given this
> capability. It's also not clear to me how they would express it. The
> client code is not supposed to have to think about what Vat the target
> object is in.

Everything in e-speak is done via messages between a client and its core.
It doesn't matter if the other end is local or remote.  Also, e-speak
messages have two parts.  The payload is application specific; the envelope
that wraps the payload is architected.  Hence, every e-speak client must be
able to handle the envelopes.  The payload is application specific, and
e-speak allows 3 approaches for the receiving client to get the code for the
payload.  An IDL compiler for known interfaces, the ability to download the
IDL and compile locally, and downloading the stubs themselves.  The last is
allowed only if both client and server permit it.

> 
> >   That's what's been done in e-speak, and it works
> > quite well.  In
> > particular, we provide send(), sendSynchronous(),
> > sendReliable(), and
> > sendTransactional().
> 
> And these are the reasons that I didn't like it. Sending a message has
> to be easy. The syntax for sending messages is very easy:
> 
> 	define r := foo <- bar()
> 
> Requiring the use of a separate method call essentially means that
> this syntax never actually gets used. You'd always be using a library
> call. I think the better strategy is to make the semantics for a
> message send work right for all cases.

Well then, which do you use?  Some requests need transactional semantics;
others only UDP reliability.  Do you want to force everyone to pay the
overhead of the most complex messaging?  Early on we decided to base our
design on the principle that "if you don't need it, you don't pay for it."
Hence, the basic messaging in e-speak is asynchronous, best effort.
Anything more reliable is handled in client-side libraries.  As far as using
the object message syntax goes, that's up to the library designer.  For
example, the e-speak Java interface, JESI, assumes synchronous, reliable
messaging as the default.  If you want more or less, you have to use a
library call.

> 
> > An earlier comment mentioned handling the logic in the Vat.
> >  We rejected
> > this idea when desinging e-speak because of the danger of
> > building up too
> > much state.  Instead, an undeliverable message is returned
> > to the sender.
> > It's up to the library routine to decide what to do.
> 
> It's easy to get rid of the "state build up" problem. On the receiving
> side, there is no state buildup, just the same references that the Vat
> is already supporting. On the sending side, the Vat is free to smash
> the reference at any time, and thus get rid of the pending messages. I
> think a good policy would be to continue to hold the messages for as
> long as the client code is still holding either the target reference
> or the return value promise. If, through local garbage collection, it
> is discovered that the client code no longer cares about these
> references, then it is fine to give up on the pending messages.

We're talking a matter of degrees here.  You propose keeping some state; we
keep none.  We wanted to avoid the problem of picking the right heuristics
on how much to keep.  The design goal is for an e-speak core to be able to
handle 500 clients with adequate performance.  (The latest results show that
it handles over 250 with OK performance on a Pentium III machine.)  We just
didn't see an easy way to figure out how much space to reserve for each
client.  Besides, the proxies that forward messages between machines can
save messages waiting for the link to come back up, so we didn't need to
have the core do it.

> 
> Tyler
> 
> _______________________________________________
> e-lang mailing list
> e-lang@mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/e-lang
> 

_________________________
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/