Re: Reliability of RPC services

[Marcus Brinkmann]

At Sat, 22 Apr 2006 19:00:54 +0200,
Marcus Brinkmann wrote:
> But it is you who is not thinking clearly: I have not said that the
> client should rely on unreliable code for anything.  I have said that
> the client should rely on the kernel to send a notification when the
> reply capability is dropped.  I also claim that such a guarantee
> allows me to state invariants of the system that allow me to reason
> about the ability to recover from bugs or hostile behaviour in some
> use cases.

Here is, in an informal manner, one of the invariants I mean: When a
process is in a call, and waiting on a reply (send-once) capability,
from a global system perspective one can identify a process "on which"
the caller is waiting: Namely the process holding the reply
capability.  This is true of course because the reply capability can
only be moved around (or invalidated by generating a message on it via
invocation or implicitely by dropping it).

This sounds like a useful property to have, because now one can, in
principle, always find a task responsible for another task waiting on
a call.  I do realize that this is a narrow view, ie I am not claiming
that this is generally useful.  However, I do not know how to
efficiently implement the above invariant without a kernel extension,
which leaves only one possible alternative: That the system should be
designed so that the above invariant is not required in argueing about
functional aspects of the system behaviour.  But what would replace it?

Thanks,
Marcus