Introducing a cmp() operation

[Marcus Brinkmann]

At Wed, 15 Jun 2005 11:20:22 +0200,
Bernhard Kauer <kauer at os.inf.tu-dresden.de> wrote:
> > > Just as reminder:
> > > 
> > > Situation:  S -> C -> (1 reference) A -> B
> > >     
> > > Goal:             /-> (1 reference) A
> > >             S-> C
> > > 	          \-> (1 reference) B
> > > 
> > > 1. In the start situation A is trusted by B to provide the endpoint to S.
> > >    Since A could unmap this endpoint everytime.
> > > 
> > > 2. Therefore B can ask A for a new reference. Since A can not provide this
> > >    service, it asks C and attaches a [1] return endpoint to B in its message.
> > > 
> > > 3. C answers directly to B and maps them a new reference.
> > 
> > This protocol requires that the receiver of the capability, in this
> > case B, makes a blocking call to the sender, in this case A.  But in
> > many cases B does not trust A enough to block indefinitely until A
> > does the right thing. 
> 
> To get into the start situation B has to receive a mapping from A.
> If this mapping was done, as an result of an RPC (because B requested the
> mapping) B blocked on A.

Mmmh.  Maybe I should have said a few words about what the Hurd is.
The Hurd is a multi-server operating system which tries to limit the
amount of system code that is enforced on the users.  Thus, many
services, even system services, are entirely optional (but if you
don't use them, certain other features of course become unavailable).
But more importantly, users can start their own services,
extending/overriding the system services.  For examples, users can
start their own filesystems, and link them into the filesystem
hierarchy.

The Hurd is designed to not require mutual trust in many instances of
communication and protocol.

To get back to your protocol: No.  B does not need to block on A to
receive a message.  A needs to block on B to send a message.  B just
needs to eventually receive from A.  If it is a server, it might be
busy currently and only eventually enter into an (relatively open)
receive.

> If A send this capability within a request to B, it could easily ask
> C to send this request.

It could ask, but C had to decline, because C is a system service not
trusting A at all, and definitely won't make blocking calls on
arbitrary capabilities provided by users.  The part in your protocol
where C sends a reply message to B was OK.  C can make replies, but it
won't make requests.
 
> > For example, in the case where a client wants to submit a 
> > capability reference to a server (let's say a name server).
> 
> Assume B is a nameserver and A wants to "upload" a capability reference.
> Then A calls C, which sends a new reference to B.

See above.  The nameserver is not necessarily trusted by C.  If C
wants to send the capability to B (which it must, to get the mapping
hierarchy right), then it must be as a reply message.  Thus B must send
the request to C, as C is the trusted system server, not A (which B
doesn't trust that much).  The required protocol is pretty much
enforced from start to end given the border conditions (trust
parameters).

Thanks,
Marcus