Re: Reliability of RPC services

[Bas Wijnen]

On Mon, Apr 24, 2006 at 12:23:18PM -0400, Jonathan S. Shapiro wrote:
> > 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.

We still aren't talking about the same thing.  Marcus and I are talking about
what we call "send-once" capabilities.  They are held by exactly one party,
and *cannot be copied*.  They can be moved, which is copy+drop, but this drop
doesn't invoke a notification (because they aren't lost, only moved).  A
normal drop (or overwrite) does invoke the capability first.  It can also be
invoked normally.  After invoking, it is no longer valid.

So the invariants here are:
- As long as the capability has not been invoked, it is held by exactly one
  party.
- After is is invoked (in any way), it is held by noone.

This is not what you were talking about, but this is the interesting thing
(that is, I fully agree that the things you talk about don't solve the problem
we identified).  So forget about all others for the moment, please.

> > 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.

This is not a problem.  The invocation only happens when valid send-once
capabilities get overwritten.  Each and every valid send-once capability is
directly related to a client waiting for a response.  If you overwrite it, it
will never get that response, because you are guaranteed to be the only party
who is capable of responding.

If you first invoke the capability, or move it to an other process, and
overwrite it after this (which will be the usual operation, I suppose), then
this overwrite does not trigger anything: on invocation, the capability is
invalidated, so there is no send-once capability being overwritten (but only
an invalid capability).

> > > 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.

You are thinking of copyable capabilities.  That is not what the other people
in this discussion are talking about.

Indeed, drop == overwrite, and if you drop _the_ (not _a_) reply capability
for a client, then indeed it is impossible for C to ever receive a valid
response: it is impossible to receive any response at all!  In that situation,
it makes sense to notify C about this, so it can recover.  If this
notification does not happen, it can only resort to timeouts.  I thought you
would agree that timeouts are a Bad Thing(tm) on anything except real-time
systems.  But in the new thread you started you seem to maybe support them.

> > > 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.

The capabilities we talk about cannot be copied, only moved.

> 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

As Marcus also pointed out already, this does not define the send-once
capabilities we were talking about.  Instead of such technical definitions, I
would rather write them conceptually:

        - The capability will exist exactly until it has been invoked once.
          If it is destroyed before being invoked otherwise, it is invoked as
          part of the destruction.
        - As long as the capability exists, there is exactly one holder.

I hope you now understand what we are talking about.  I am very interested in
your opinion about it in that case.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature