Re: auth handshake and rendevouz objects

[Marcus Brinkmann]

On Tue, Nov 05, 2002 at 05:32:34PM +0100, Niels Möller wrote:
> Marcus Brinkmann <address@hidden> writes:
> 
> > Well, one question is surely resource allocation.  I think A should provide
> > the resource to S that contains the note that B should get a reference to
> > the handle.
> 
> Hmm. Sounds a little hairy. I think one would really want the
> following protocol:
> 
> 1. A->B:    I'd like to give you the handle (S,x).
> 2.  B->S:   Gimme handle x. A said I could have it.
> 3.   S->A:  Do you really want to give x to B?
> 4.   A->S:  Sure.
> 5.  S->B:   Ok, here's the handle.
> 6. B->A:    Thanks, I've got it now.
> 
> Except that there's one S->A message, 3, and you say you'd like to
> avoid that. I'd be a little surprised if one can come up with an
> alternative that avoids both the callback from S to A, and state in S.

I agree.  Well, the reason that messages from S to A are annoying is that
you never, never want the server to block on a message to an untrusted
client.  So, you definitely want a zero timeout.  Which means that A has to
be ready for receiving.  Which could be setup, of course, but that would
mean devoting a special thread for this _per handle passing_.  Only one
global thread would not work if you have high concurrency.

Beside that, your suggestion is also fine.  It prevents the need of
resources in the server, but otoh, having A provide a page of memory to the
server in a container doesn't sound too bad either.

> One interesting detail here is that most tasks would need special
> bookkeping threads (A for receiving 3, and S for receiving 2), so
> these thread id:s must be passed around to all parties that need them.

Step 2 is taken care of by normal RPC processing in the server.

I think you need an object management thread in every program providing
objects.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/