Re: [9fans] remote 9p multiplexing

[rog@vitanuova.com]

> when afd != -1, the fd in mount(fd, afd, where, flags) is redundant.
> if you mounted 9P services by opening them, running authentication,
> and then calling mount(afd, where, flags), we could adopt the convention
> that the 9P connection for the mount is the one where afd is a fid.

yes.

> then Tauth invents a fid out of thin air to bootstrap a connection,
> but if the fid has been gotten by open, mounting this fid can be 
> handled without further encapsulation.

actually, i was imagining that you would not be allowed
to open an auth file, only Tauth it. the open doesn't really
give you much and you've got to call auth to provide
the uname and aname before you can read or write it anyway.

this does change current 9p semantics (currently the auth fid
must not currently exist; in this scheme it could optionally exist),
but in a compatible way.

> of course, they'd more properly be called something else, since this
> has nothing to do with authentication and everything to do with
> setting up the context of a new 9P conversation.  maybe session fids.

i'm not sure - i think auth fids is *exactly* what they are. by
walking to it and calling fauth(2) on it, you're introducing yourself
(authenticating) to whatever's at the other end.

the 'A' that you might see in an ls -l listing could also stand for "attach"...
but they'd be potentially useful even without doing the attach, as a way
for a client to ascertain the identity of a party at the other end.

> that's really neat.  it separates the setup from the actual session
> in a nice clean way without the clumsy 9P1 kernel hack and 
> without any encapsulation overhead.

there's more to it than that.

it makes possible some useful 9p server designs that were not
previously possible.

for instance, it becomes much more reasonable to implement a web
browser in the namespace.  the server could provide a namespace for a
single web page, holding the data for the page, but also an auth file
for each link in the page.  mounting the auth file would provide the
namespace for the page linked to.  (https authentication falls out
naturally).  deciding which web pages to keep current (i.e.  mounted)
is a matter for the client, as it should be.

it also makes sense for servers that wish to provide multiple
instances of a service, but don't care about letting clients see all
the instances that have been created, in the same way that the #|
device does.

to take a specific example, the Inferno grid scheduler program exports
a single namespace to all its clients.  one of those files, when
opened, represents a single worker instance to the server.  if i'm on
a multi-process machine, i can open the file several times, and the
server sees several workers.  the difficulty comes when i wish to send
an abort message to a particular worker - the same worker might have
opened the "stoptask" file, but i have no way of associating the two
opens, so i am forced to provide one such file for each attach, and
let the client do the multiplexing.

the current alternative would be to provide a "clone"-style interface,
with one directory for each worker, each containing two files.  not
only does that make the server implementation more complex (have to be
able to enumerate all clients, have to allocate appropriate qid space,
etc) but it also makes the client interface more complex
(open clone file, read id, etc, vs. open file).

the auth file interface gives me the best of both worlds: i could
provide an auth file for workers to attach to, giving each a namespace
containing the two files (and any others necessary), and wouldn't have
to worry about enumerability or qid space at all.

oh yes, it also seems a natural representation for dynamically loaded
device drivers.

and it can solve world hunger too.