l4-hurd@gnu.org
[Top] [All Lists]

Re: Cancellation forwarding protocol (was Re: Reliability of RPC service

Subject: Re: Cancellation forwarding protocol was Re: Reliability of RPC services
From: Pierre THIERRY
Date: Thu, 27 Apr 2006 14:29:52 +0200
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
-- 
nowhere.man@xxxxxxxxxxxxxxxx
OpenPGP 0xD9D50D8A
_______________________________________________
L4-hurd mailing list
L4-hurd@xxxxxxx
http://lists.gnu.org/mailman/listinfo/l4-hurd
<Prev in Thread] Current Thread [Next in Thread>