Re: VatTP and Waterken protocols compared

On Fri, Sep 19, 2008 at 5:54 PM, Bill Frantz <[email protected]> wrote:
> Tyler described some of the Waterken protocol in this Friday's
> morning meeting. Here are some notes from his description.
>
> Both the VatTP protocol part of E on Java
> <http://www.erights.org/elib/distrib/vattp/index.html>, and the
> Waterken protocol <http://waterken.sourceforge.net/> allow vats to
> send messages to other vats. There are some significant differences
> in their implementation which affect their behavior during
> checkpoints and during message flood conditions.
>
> In VatTP, messages are sent as soon as they are generated. The
> receiving thread takes the message and places it on the single vat
> queue, and then returns to read another message. There is no
> specific message acknowledgement.
>
> In Waterken, each vat keeps a queue of messages to be sent. A
> message is only discarded when the remote vat acknowledges having
> processed it. Message which aren't idempotent include a serial
> number to prevent double processing. The receiving process receives
> a message from TCP, gains the vat lock, passes the message to the
> vat, waits for the response, releases the vat lock, and returns the
> response to the sender. Messages which a vat sends to itself are
> handled with the same logic.
>
> Both systems only save persistent state between vat "turns". It is
> not clear from the (non)documentation if the vat queue is included
> in what is saved by the persistence mechanism. (And I can't
> remember that detail.) In Waterken, the output queue is saved as
> part of the persistent state (including messages a vat sends to
> itself).
>
> These differences give Waterken different failure modes than VatTP:
>
> (1) Message sends are back-pressured into the sending vat using the
> TCP flow control mechanism. This prevents run-away sending programs
> from crashing the receiving vat by running it out of message buffer
> space. However, there may be situations where both vats can not
> process more messages because they are waiting for space to send
> the other vat a message.
>
> (2) In the Waterken system, a message which causes a serious
> program failure (e.g. running out of space in the current
> implementation) will be repeated, possibly causing that failure
> over and over, until someone repairs the offending program.

Also, an evil recipient can stall the sender by never processing messages.

>
> Cheers - Bill
>
> -----------------------------------------------------------------------
> Bill Frantz        | gets() remains as a monument | Periwinkle
> (408)356-8506      | to C's continuing support of | 16345 Englewood Ave
> www.pwpconsult.com | buffer overruns.             | Los Gatos, CA 95032
> _______________________________________________
> e-lang mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/e-lang
>