Re: cap exchange race with map/unmap

[Jonathan S. Shapiro]

On Wed, 2005-10-19 at 12:10 +0100, Neal H. Walfield wrote:
> At Tue, 18 Oct 2005 14:27:56 -0400,
> Jonathan S. Shapiro wrote:
> > I believe that the only possible protocol that could be correct is for
> > all object servers to return by way of CapServer. In practice, this
> > makes locally trusted CapServers impossible, because a general-purpose
> > server cannot make assumptions about how the objects it creates will
> > later be transferred.
> 
> I'm having difficult understanding this paragraph.
> 
> What does "return by way of CapServer" mean?  Does it mean that when a
> server returns, it doesn't respond directly to the caller but has the
> capserver respond to the caller?

Yes.

> 
> Why types of assumptions can't a server make about how the objects it
> creates will later be transferred?  Do you mean, for instance, if a
> server uses the cap server any client must also use the cap server to
> transfer the capability?  I don't think this example is true as a
> client can still provide revocable mappings.

TERMINOLOGY CHANGE: I will explain in my next mail, but I am going to
start using the term SIMULATED COPY to describe our implementation of
COPY using the capability exchange server. The problem is that I have
realized that the cap server just doesn't work at all, so I want to
start distinguishing the two clearly. More on this in a moment.

I do not mean that a client cannot use REVOCABLE COPY. I mean that if
any client *ever* wishes to perform a SIMULATED COPY, then the CapServer
must have a non-revocable capability. Since an object server cannot know
how a receiver will use its capabilities, it must unconditionally return
via CapServer in order to ensure that SIMULATED COPY is later possible.

Note: this doesn't work, and I know it doesn't work, and I am about to
explain why in my next note.

shap