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

[Jonathan S. Shapiro]

On Thu, 2006-04-27 at 14:29 +0200, Pierre THIERRY wrote:
> Scribit Jonathan S. Shapiro dies 27/04/2006 hora 06:36:
> > If the payloads do not match, the destination process will never know
> > that the capability was invoked.
> 
> But what if the PP match? We need a way for a watchdog to chech that
> reply can be made.

If the PP matches, then the FCRB is not cancelled! See below before you
respond to this part -- I think I understand the confusion, and the
comments below may clarify.

> It is cheaper but I still ain't convinced it achieves the same features.
> 
> And severing the FCRB would only occur when operation is cancelled. In
> fact, it would only occur when operation is cancelled and should be
> forwarded... Maybe an optimization to the protocol would be to advertise
> it is handled. Then any process who's next server in the chain did not
> advertise cancellation forwarding would not sever the FCRB and only
> increment PP.

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.

> > > But section 6.1 describes the invocation of a FCRB sender's
> > > capability, and it seems to always lead to a delivery.
> > Go back and read step 1 again. Look more carefully what happens when
> > the payload does not match.
> 
> 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. 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.

> > The capability does not need to be invoked to determine whether it is
> > still valid. the Discrim.classify operation will tell you what you
> > need
> 
> Could you elaborate? Does incrementing the PP will invalidate the
> previous sender's capability? If not, what would be the result of
> classify() before and after PP increment? I.e., would they be different?

Does my description above answer your question?

thanks


shap.