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

[Pierre THIERRY]

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.

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

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.

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

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

Curiously,
Nowhere man
-- 
address@hidden
OpenPGP 0xD9D50D8A

signature.asc
Description: Digital signature