[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cap exchange race with map/unmap
From: |
Marcus Brinkmann |
Subject: |
Re: cap exchange race with map/unmap |
Date: |
Wed, 19 Oct 2005 15:10:58 +0200 |
User-agent: |
Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI) |
At Wed, 19 Oct 2005 09:52:40 +0200,
address@hidden (Ludovic Courtès) wrote:
>
> Hello,
>
> Marcus Brinkmann <address@hidden> writes:
>
> > At Tue, 18 Oct 2005 14:27:56 -0400,
> > "Jonathan S. Shapiro" <address@hidden> wrote:
> >
> > [A broken protocol snipped]
> >
> >> I believe that the only possible protocol that could be correct is for
> >> all object servers to return by way of CapServer.
> >
> > I agree. This is exactly what I proposed in my talk in Dijon.
> >
> > The server maps a revocable copy to the cap server. The cap server
> > maps another revocable copy to each client.
>
> Marcus, how is this different from what Jonathan described in
> <address@hidden>, that is:
>
> In the absence of any authority to fabricate new capabilities, the
> following chain of mappings is now in effect after the exchange:
>
> RevCopy RevCopy
> A ----------> CapServer -----------> B
Here, A and B are clients. Let me draw you a picture of the only
solution I know, which also Shapiro mentioned above:
Before copy operation:
RevCopy RevCopy
Server S ----------> CapServer -----------> A
After A initiated the copy operation to B:
RevCopy RevCopy RevCopy
Server S ----------> CapServer -----------> A ----------> B
After B initiated the copy operation from the cap server.
RevCopy RevCopy RevCopy
Server S ----------> CapServer -----------> A ----------> B
^ |
| RevCopy |
+----------------------------+
The revocable copy from B to the cap server proves to the cap server
that B possesses the capability, and furthermore allows the cap server
to identify the capability to copy in the first place!
At the end of copy operation:
RevCopy RevCopy RevCopy
Server S ----------> CapServer -----------> A ----------> B
| ^
| RevCopy |
+----------------------------+
The copy from B to the cap server has been removed. It's not needed
anymore.
After the copy operation:
RevCopy RevCopy
Server S ----------> CapServer -----------> A
|
| RevCopy
+------------> B
The copy from A to B has been removed. It is not needed anymore. Now
A and B have a co-equal copy.
Thanks,
Marcus
- Re: cap exchange race with map/unmap, (continued)
- Re: cap exchange race with map/unmap, Ludovic Courtès, 2005/10/19
- Re: cap exchange race with map/unmap, Bas Wijnen, 2005/10/19
- Re: cap exchange race with map/unmap, Jonathan S. Shapiro, 2005/10/19
- Re: cap exchange race with map/unmap, Bas Wijnen, 2005/10/19
- Re: cap exchange race with map/unmap, Marcus Brinkmann, 2005/10/19
- Re: cap exchange race with map/unmap, Marcus Brinkmann, 2005/10/19
- Re: cap exchange race with map/unmap, Jonathan S. Shapiro, 2005/10/19
- Re: cap exchange race with map/unmap, Neal H. Walfield, 2005/10/19
- Re: cap exchange race with map/unmap, Marcus Brinkmann, 2005/10/19
- Re: cap exchange race with map/unmap, Neal H. Walfield, 2005/10/19
- Re: cap exchange race with map/unmap,
Marcus Brinkmann <=
- Re: cap exchange race with map/unmap, Jonathan S. Shapiro, 2005/10/19
- Re: cap exchange race with map/unmap, Marcus Brinkmann, 2005/10/19
- Re: cap exchange race with map/unmap, Jonathan S. Shapiro, 2005/10/19
- Re: cap exchange race with map/unmap, Neal H. Walfield, 2005/10/19
- Re: cap exchange race with map/unmap, Jonathan S. Shapiro, 2005/10/19
- Why COPY != SIMULATED COPY, Jonathan S. Shapiro, 2005/10/19
- Re: Why COPY != SIMULATED COPY, Jonathan S. Shapiro, 2005/10/19
- Re: Why COPY != SIMULATED COPY, Marcus Brinkmann, 2005/10/19
- Re: Why COPY != SIMULATED COPY, Espen Skoglund, 2005/10/19
- Re: Why COPY != SIMULATED COPY, Espen Skoglund, 2005/10/19