[E-Lang] security, comms, ordering guarantees

[Bill Frantz]

At 3:54 PM -0700 4/21/01, zooko@zooko.com wrote:
> MarkM wrote:
>So one elegant fix to this problem is to define the No-Late-Messages guarantee
>to apply to the stream of messages that MarcS thought it applied to: all
>messages sent to this capability.  This is what would result if MarcS had used
>the "revokable proxy" technique.  (Hm.  Delegation weirdness?  Please see
>[footnote 1])
>
>To me this issue seems so tightly related to other notions of capability and
>other notions of ordering and robustness that we should at least consider
>whether to integrate it into the fundamental comms abstraction.

I have a question about how to implement this suggestion without some kind
of global ordering concept.  As far as I can tell, once you use a different
object to send messages, as happened when the impatient bidder went to a
different vat, then a No-Late-Messages guarantee seems to require ordering
between the two objects sending messages.

The revokable proxy produces a much stronger guarantee, that is: I am now
the only entity that can send messages to this object.  (Since I have the
only capability to the new revokable proxy, and the old one is broken.)


>Now let's look at what MarcS's code does with its No-Late-Messages guarantee.
>It sends a "state query" message to the server and displays the response
>to the
>user.  The user then decides whether to resend his original message or not
>based
>on the results of the state-query.
>
>Now what if these two steps had also been implemented in the E comms layer
>instead of by the user?  It could have sent, for a state-query message,
>"Did the
>bid message arrive here?", and then if the answer was "No.", it could have
>resent the bid message.
>
>This would then be an implementation of Up-To-Here ordering guarantee.
>Instead
>of the user remembering that he wanted to make a bid, examining the
>state-query-
>response, and deciding to resend his bid, the user's local agent would do
>that.
>This of course requires more local (client-side) state.  (In the computer that
>is!  Actually both approaches require the exact same amount of local
>state, but
>in MarcS's approach, the user is maintaining some of it in his head.)

This is an implementation for the "from one object" case.  (The "from one
vat" case implies the from one object case.)


Since at least some of the underlying protocols we are likely to use have a
built in impatience policy (for example, TCP), if we want to remove the
impatience policy from the VatTP layer, we need a good story about what
happens when TCP says it is giving up.

If we want to maintain ordering guarantees, even while we use other
underlying communication protocols (messages thru a mix, UDP, postings to
alt.anon.messages, etc.), we will need much of the functionality of TCP in
the VatTP layer.  My immediate approach would be to use the TCP
specification to implement that functionality.
>[footnote 1]
>
>This has interesting implications with the delegation issue, doesn't it?
>Let's say you had implemented a No-Late-Messages guarantee in the context
>of the
>capability, with a revokable forwarder.  This actually provides two kinds of
>guarantees: No messages from before a "revoke and regenerate forwarder"
>transaction will be processed after said transaction, and in between
>"revoke and
>regenerate forwarder" transactions, you get an Up-To-Here guarantee (or
>whatever
>kind of guarantee the comms offers here.  In current E, it is an
>Up-To-Here-or-failure guarantee).
>
>But Alice only gets this as long as she is the only person with the
>capability!
>If she shares the capability with Bob, then every time she does a "revoke and
>regenerate forwarder" transaction, it causes all of Bob's unprocessed messages
>to get thrown away, until *he* next does a revoke-and-regenerate, etc.  The
>result: no useful guarantees of ordering/reliability at all for either of
>them.
>
>It isn't immediately obvious to me if this is an artifact of the proxy
>implementation or a consequence of the No-Late-Messages ordering guarantee
>itself.

Actually, Bob probably looses all connection to the object, since the
revoke and regenerate forwarder is likely to be a message to the forwarder.
This is exactly the behavior you want if Bob is some other object you use
as part of implementing your current transaction.

Cheers - Bill


-------------------------------------------------------------------------
Bill Frantz       | Microsoft Outlook, the     | Periwinkle -- Consulting
(408)356-8506     | hacker's path to your      | 16345 Englewood Ave.
frantz@netcom.com | hard disk.                 | Los Gatos, CA 95032, USA