Re: Cancellation forwarding protocol (was Re: Reliability of RPC services)

[Pierre THIERRY]

Scribit Jonathan S. Shapiro dies 27/04/2006 hora 09:06:
> No no. You *really* don't understand. The process that is forwarding
> *cannot* change the PP. You can only change the PP on an FCRB that
> *you* allocated.

That was clear for me.

> > I understand that, really. The problem is, what happens when payload
> > match, when invocation purpose was to test the validity of the FCRB?
> You don't invoke the sender capability for this.

I was partly confused by this in a previous mail:

> there is no difference in behavior between invoking a Null cap and
> invoking a cap with a non-matching payload

That led me to think that your check was to invoke the capability. And
it didn't make sense a check.

> You invoke Discrim, passing the reply capability as an argument.
> Discrim will respond with:
> 
>    clOther  if capability is a reply capability and PP *does* match
>    clVoid   if capability is invalid
> 
>             [Note bug: this should be called clInvalid, and I will
>             update the spec.]
> 
> A capability is considered invalid exactly if:
> 
>   1. The target object that it names has been destroyed (severed), or
>   2. The capability is a sender capability to an FCRB, the PM bit of
>   the FCRB is set, and the PP does not match the PP of its target.

Then the specification is incomplete, IMHO. Section 6.1 tells that
invoking a capability with wrong PP where there is PM triggers an
InvalidCap exception, but nothing tells that the cap in itself has
become a void capability, and that discrim would see it that way.

> Does my description above answer your question?

Almost completely. Will coyotos.cap.getType() return the ID of a void
capability, or only Discrim could see the invalidity?

So the protocol becomes:


Successful operation:
=====================

- C invokes a cap to S, giving S a cap c1 to a FCRB->C
- S sets up a watchdog that check that discrim.classify(c1) != clVoid
- S invokes a cap to T, giving T a cap c2 to a FCRB->S
- T sets up a watchdog that check that discrim.classify(c2) != clVoid

( T successfully treat the request, now goes completion )

- T invokes c2
- S reads the answer, and increment the PP of the FCRB->S
- S invokes c1
- C reads the answer, and increment the PP of the FCRB->C


Uncomplete operation:
=====================

- C invokes a cap to S, giving S a cap c1 to a FCRB->C
- S sets up a watchdog that check that discrim.classify(c1) != clVoid
- S invokes a cap to T, giving T a cap c2 to a FCRB->S
- T sets up a watchdog that check that discrim.classify(c2) != clVoid

( for any reason, C decides to stop, now goes cancellation )

- C increments the PP of the FCRB->C
- S watchdog notifies S of cancellation
- S increments the PP of the FCRB->S
- T watchdog notifies T of cancellation


Which shows that the only thing needed to add cancellation forwarding is
a watchdog on the validity of the reply cap. Which is quite marvelous.

Clearly,
Nowhere man
 
PS: is there a way to access to the source of the specification, to
propose a patch?
-- 
address@hidden
OpenPGP 0xD9D50D8A

signature.asc
Description: Digital signature