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

[Jonathan S. Shapiro]

On Thu, 2006-04-27 at 11:37 +0200, Pierre THIERRY wrote:
> Scribit Jonathan S. Shapiro dies 27/04/2006 hora 05:18:
> > > But I'm not sure it is what I want. In fact, now I'm pretty sure
> > > it's not. To just block subsequent replies is needed upon
> > > completion, but for cancellation forwarding you need a bit more.
> > Can you say why you believe this? I think there is a hidden assumption
> > here that may be mistaken.
> 
> My assumption, confirmed by what you say just below, is that the check
> you're suggesting needs to invoke the capability to the FCRB, thus
> needing to page it in, and the owner of the FCRB then to process the
> incoming activation.

You misunderstand. The payload comparison check is performed entirely in
the kernel. If the payloads do not match, the destination process will
never know that the capability was invoked.

This is also true if the process tests to determine whether the
capability is invalid.

Yes, the target FCRB object must be in memory, but consider the
alternative: in your plan, you will sever the FCRB, but after you do
this you immediately need to go buy a new one so that you can make your
next call. Incrementing the payload has the same effect at much cheaper
cost.

Indeed, one way to think about the way the payload is used for reply
capabilities is that it reduces the number of required sever operations
by 2^32.

In fact, the implementation of an FCRB that will accept at most one
reply is accomplished exactly by changing the protected payload in this
way.

> 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.

> So how do you intend the watchdog to perform the test? And how the
> client is supposed to discriminate between the test and the actual
> answer?

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:

   http://www.coyotos.org/docs/ukernel/spec.html#55

[I just noticed that link targets are getting generated incorrectly for
the object reference section. This means, unfortunately, that the link
above will go stale. It is a link to the "operations" subsection of the
Discrim capability.]