Re: Do we want a server on `/servers/machine' (or similar)?

[Neal H. Walfield]

At Sun, 13 May 2007 15:13:12 +0200,
Thomas Schwinge <tschwinge@gnu.org> wrote:
> 
> [1  <text/plain; us-ascii (quoted-printable)>]
> Hello!
> 
> On Sat, May 12, 2007 at 09:20:26PM +0200, Neal H. Walfield wrote:
> > At Sat, 12 May 2007 21:01:02 +0200,
> > Thomas Schwinge <tschwinge@gnu.org> wrote:
> > > Yes, but that would require keeping some state in the server, which I
> > > wanted to avoid, because...
> > 
> > As you have PORT and presumably an associated peropen, I am not
> > convinced by your argument.
> 
> Sorry, I can't follow you here.  In my opinion, the server running on
> `/servers/io_perm' should be a simple proxy with some sort of internal
> access control.  It should not needd to keep any state for every request.

Are you writing your server from scratch or are you using libports and
libtrivfs?  If so, these libraries allocate state (a handle)
associated with each open.  When an RPC on the port is received,
libports finds the associated handle state by looking up the port name
in a hash table and then it calls the appropriate demuxer function.
Instead of a raw port number, this structure is (essentially) what
gets passed to your server stub.

If you are trying to avoid server state, then how do you plan to work
around the lack of an open handle?  I imagine you are still going to
be using IBAC, so you'll first need to authenticate the client
presumably using the normal Hurd handshake.  After this completes, you
would normally return a new handle to the client on which the client
invokes the server implemented functionality.  What's your approach?

Neal