[cap-talk] Petnames versus E-order with ocaps

[Bill Frantz]

erights at gmail.com (Mark Miller) on Friday, January 30, 2009 wrote:

>On Fri, Jan 30, 2009 at 8:17 AM, Karp, Alan H <alan.karp at hp.com> wrote:
>
>> Charles Landau wrote:
>> > I imagine a system in which a reference coming into an object (such as
>> > Bob) is (efficiently) compared (using some form of EQ) with all existing
>> > references in the object. If there is a match, the system says "here is
>> > a reference that you know as foo". If there is no match, a new unique
>> > petname is somehow generated for the incoming reference.
>> >
>> If there is a match, and Bob sends a message to Carol using foo, i.e.,
>> foo<-bar(), is the message guaranteed to arrive after the message Alice sent
>> to Carol?  My contention is that we can't say, which means we can't enforce
>> E-order in a petname system.
>>
>
>Please reread the explanation of WormholeOp <
>http://www.erights.org/elib/distrib/captp/WormholeOp.html>. With WormholeOp,
>if Alice sends a resolved reference to Bob, it arrives resolved, so it can
>immediately be assigned a petname on arrival. But VatA also sends to VatB
>all of VatA's remaining traffic for VatC that was unacked at the time it is
>sending this message to VatB, all encrypted so only VatC can decrypt. This
>includes all of Alice's prior messages for Carol. VatB will present this
>encrypted traffic to VatC prior to redeeming the serialized ref to Carol.
>Therefore, with WormholeOp, Bob can immediately assign a petname without
>losing pipelining.

It sounds to me like this algorithm gives Bob a way to deny Carol's service
to Alice by just throwing the redirected communication on the floor.

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