Re: Reliability of RPC services

[Jonathan S. Shapiro]

On Mon, 2006-04-24 at 17:58 +0200, Michal Suchanek wrote:
> > Let us start closer to the beginning.
> >
> > 1. Capabilities are only overwritten as a consequence of invoking some
> > capability. Every capability invocation has input and output arguments.
> > All capability writes happen as a side effect of delivering output
> > arguments. That is: in a capability system, IPC is a special case of
> > capability invocation.
> >
> > 2. All notifications are delivered by IPC. This includes death
> > notifications.
> >
> > These two statements together lead to a reductio problem: every IPC may
> > be required to send other IPCs before it can proceed. The reductio can
> > be solved provided that the death notification does NOT transfer any
> > capabilities (which, fortunately, it does not).
> >
> > However, we now have the situation that if the initial invocation sends
> > K capabilities, there may need to be as many as K death notices -- one
> > for each overwrite. In Coyotos, K may be as high as 256. Sending K
> > notices is certainly not the usual case, but it must be a case that
> > works well if the system architecture is to be clean.
> >
> > It is difficult to imagine how to make things slower than Mach, but this
> > approach would definitely do the job.
> 
> It is the job of the server to manage its capabilities so that no such
> notices have to be sent. Ideally, the server will either drop the
> capabilities intentionally one by one (when it decides it will not use
> them) or use them to return results.

This is impossible. The rule being considered is that every overwrite
generates a notice. A drop is an overwrite.

> The case when many capabilities are overwriten with a single IPC is
> most likely a bug in the server.

Actually, it is the near-universal practice for a single-threaded
server. Arguments are commonly accepted in a way that overwrites the
arguments from the last invocation.

> > In any case, it does not achieve the desired objective. What this design
> > provides is "notify on capability overwrite", which is MUCH too strong.
> > It provides the recipient with very fine grain information about
> > capability drops (which should not be disclosed).
> 
> In the standard case the capability should be used to return a result
> to C. Why is it a problem if C receives an error when that capability
> is dropped instead of waiting indefinitely?

Since drop == overwrite, and a message has now been sent, and the
capability is "invalidate on send", it is now impossible for C to ever
receive a *valid* response.

> > Also, remember that these capabilities must be "invoke only once", so
> > any overwrite of any of these capabilities will send a death notice, and
> > that death notice will guarantee that the client will never get a reply
> > from any other copy.
> >
> > So in Marcus's scenario where C calls S which delegates to T, note that
> > S must not overwrite its capability until T replies. This essentially
> > defeats the purpose of delegation.
> >
> 
> I do not understand this. If it is a send-once capability, and S
> delegates it to T, how can S overwrite it? Since it has delegeted
> (moved) it to T it no longer possesses any copies that can be
> overwritten.

Delegation != move. Delegation can be accomplished by capability copy.

Or to put it another way

        move =def= copy + drop
        drop => drop notice
        drop notice => invoked capability
        invoked capability => invalid capability
        invalid capability => no valid response ever