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

[Tyler Close]

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."

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.

>   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.

> 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.

Tyler