Re: Reliability of RPC services

[Jonathan S. Shapiro]

On Sat, 2006-04-22 at 19:24 +0200, Marcus Brinkmann wrote:

> At Sat, 22 Apr 2006 10:22:25 -0400,
> "Jonathan S. Shapiro" <address@hidden> wrote:
> > 1. The behavior that you want can *only* be accomplished with reference
> > counting.
> 
> This is not true.  A send-once capability does not require reference
> counting as only ever one reference is extant (guaranteed by move vs
> copy semantics).

We have a miscommunication. I was referring here to the proposal that
multiple reply capabilities should be permitted to exist, but a notify
would be sent on the last overwrite.

> However, my suspicion is
> that without any such mechanisms, no useful, persistent, fault
> tolerant, user-extensible multi-server system can be built (for some
> definition of useful, which includes running a browser and sharing
> files with friends).

Fascinating, since there is a known counterexample that was used in
production without a problem for a very long time. Also, note that
AS/400 doesn't have this either!
 
> > > I think the following
> > > condition should be sufficient: The kernel guarantees that a reply
> > > message is sent _at the latest_ when the callee process is destroyed.
> > > This should hold true independent of what the callee does between
> > > being invoked and exiting.  In particular, simply dropping the reply
> > > capability should not change this guarantee (which in effect means
> > > that the kernel has to invoke the reply capability when it is
> > > dropped).
> > 
> > Several problems:
> > 
> > 1. This requires dynamic storage allocation in the kernel. Dynamic
> > storage allocation in the kernel implies denial of resource
> > vulnerabilities and makes any statement of kernel robustness impossible.
> 
> Can you elaborate why you think that dynamic storage allocation is
> required?

You stated that "simply dropping the capability [does not remove the
obligation]". In order to satisfy this requirement, the kernel must keep
track of every reply capability that a service ever receives. It can
shrink the list when it notices that some of these capabilities have
become invalid, but in abstract this could require an arbitrarily large
amount of storage.

> > 2. Your description fails in the case where C calls S which forwards to
> > T, because the exit of S will cause an improper reply.
> 
> My description (above) does not even include this case.  You snipped
> the following:
> 
> "Going back to the simple case of one caller and one callee,

I saw this, but it is necessary for the proposal to function in all
cases.

> If you combine this description with the idea of send-once
> capabilities, which are moved, not copied, you get a description which
> works with forwarding.

Given my expansion of the storage allocation problem, do you still think
so?
 
> > 3. Your proposal seems to have the side effect (I am not certain) of
> > dictating a hierarchical calling relationship. This is bad.
> 
> I am not sure what that is supposed to mean.

I am concerned that move-only capabilities will tend to encourage a
structure in which out of order reply is difficult. I haven't thought
about it, so please do not take this concern too seriously at this
point.

> I want an RPC mechanism that's "better" than UDP.

I want a pony for Christmass. I predict that I will get my wish
first. :-)

Oh, but I only want the pony if it comes with a person to shovel out the
stable. Otherwise, forget it.

> 
> > So this implies that every IPC must check the destination slots to see
> > if they cause such an overwrite, and must issue death notice calls on
> > those capabilities. If the IPC payload contains up to N capabilities,
> > and we assume that the death notice itself does not transfer a
> > capability, then every IPC has just been multiplied by up to N IPCs.
> 
> The common case is that no capability that is overwritten is a valid
> reply capability.  The common case is thus N checks on memory that is
> going to become hot anyway.

Dynamically, 50% of all IPCs will overwrite a reply capability. In many
cases the overwritten capability will be dead, but the FCRB that it
names will still need to be paged in so that this can be checked.



shap