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

[Pierre THIERRY]

Scribit Jonathan S. Shapiro dies 26/04/2006 hora 20:14:
> In general, the only subsystem that has permission to sever is the
> storage allocator. C can *request* that the object be severed by
> returning it to the allocator. This is a multiple-IPC sequence.

OK, it's heavy, but it will only occur at cancellation. I said it would
also upon completion, but that defeat the very purpose of having a
protected payload match.

So, my cancellation forwarding protocol adds a big overhead, but only
upon cancellation.

> It is better and faster to just update the payload if what you are
> trying to accomplish is to block the second and subsequent replies.

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.

> But this requires periodic polling, a.k.a. a watchdog. In which case,
> why not use the watchdog in the first place!

I do use a watchdog. The fact is, I want the watchdog to add the
smallest overhead possible. And my watchdog does not set a timeout (for
now, watchdogs and timeout have been said equivalent, obviously they're
not). Now here are the two scenarios in my protocol:

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

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

( T successfully treat the request, now goes completion )

- T invokes c2
- S reads the answer, and increment the protected payload of the
  FCRB->S, thus blocking subsequent replies
- S invokes c1
- C reads the answer, and increment the protected payload of the
  FCRB->C, thus blocking subsequent replies


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

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

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

- C severs the FCRB->C, c1 becomes a null cap
- S watchdog notifies S of cancellation
- S severs the FCRB->S, c2 becomes a null cap
- T watchdog notifies T of cancellation



Now the benefits of this protocol are:
- I'm not sure it is possible to make the watchdog's checks more
  lightweight, both in terms of the number and simplicity of operation
  (one getType() on a cap, compared to a constant) and of memory
  pressure (neither the client nor only it's FCRB need to be paged in)
- the watchdog apart, there is no modification to the existing
  communication protocol nor in the use of the FCRB (you use the
  ligthweight feature of modifying the protected paylaod to block
  subsequent replies)
- only cancellation needs a heayweight operation, severing the FCRB,
  which is a multiple IPC mechanisms with the allocator

Note also that when N clients in the chain support cancellation
forwarding, and M not, you will have at most N of these heavyweight
operations (any of the N clients being successors of any of the M ones
won't get the 'cancellation signal').

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

signature.asc
Description: Digital signature