Re: Reliability of RPC services

[Jonathan S. Shapiro]

On Sat, 2006-04-22 at 19:00 +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.

There are only two cases in which a capability can be dropped:

 1. The holder overwrites it. This is a bug. This is exactly the
    case of a client relying on a flawed server.

 2. The holder is destroyed. The *only* reason that it is sensible
    to consider a death notice is that the service is being denied
    the opportunity for orderly cleanup.

If the server is malicious, the presence of a "notify on drop" bit (or
even a "notify on container destroy" bit) is insufficient to achieve the
robustness that you are looking for.

Since the feature you are requesting is "best effort", it definitely
does NOT permit you to reason about the cases you mention. The only
effective way to manage these issues is with watchdogs. Watchdogs are
unfortunate for other reasons, but at least they do not perturb the rest
of the architecture.

shap