Re: [9fans] Do we have a catalog of 9P servers?

[sqweek <sqweek@gmail.com>]

On Wed, Nov 12, 2008 at 9:32 AM, Eris Discordia
<eris.discordia@gmail.com> wrote:
> And some stuff for troll-clubbers to club me with:
>
> 1. What is 9P's edge over text-based protocol X?

 It has a simple mapping to basic file operations, which makes it easy
to transparently use on the client side. Aside from the debugging tool
aux/9pcon, I'm not sure that any plan 9 programs do explicit 9p client
calls.

> 4. Intelligence is not something peculiar to 9fans and the creators of Plan
> 9. Simplicity of design is not something peculiar to 9P. It could appear out
> of the blue any day with the latest protocol X.

 Could do. However, part of the simplicity of 9p stems from its
implementation in Plan 9:
* 9p doesn't need to worry about the details of auth - that's the
responsibility of authsrv + factotum.
* 9p doesn't need to support symlinks; the kernel provides that sort
of functionality through bind.
* 9p doesn't care about different user id mappings because plan 9 only
deals with user names (and those are verified by the auth server).

 It doesn't stop at 9p:
* rc/bc/dc/hoc don't need to implement line editing or tab completion
because the "terminal" (win from rio/acme) does the job.
* rc/awk don't need to explicitly support tcp/ip because we have /net.
* fossil doesn't need hardlinks, since venti coalesces identical data blocks.
* plan 9 doesn't need to bother with NAT, since you can just import
/net from your gateway.

 Just some examples. But you're right, simplicity of design does
happen elsewhere, but it's less likely to arise elsewhere simply
because other systems have a lot more crap to deal with. When you're
stuck with vt100 emulators, of course every shell implements its own
line editing. Of course utf8+tcp/ip support creeps into every app one
by one when you don't have a ubiquitous interface to them.
 Much of plan 9's simplicity comes from its structure and consistency.
Note that all the simplicity gains I've listed come from *removing*
features. To be able to do that sort of thing it helps to have a
system where each component meshes well with the other components.
Everything in its right place, so to speak. Not that I'm suggesting
plan 9 is 100% perfect, I'm sure there are shortcomings but it makes
so much more effort than any other system I've seen as far as elegance
goes.

> Since protocol X is
> supposedly new it will break nothing but if it manages to get a foothold by
> its designers _not_ acting up the way the average 9fan does when 9P is
> minimally criticized then 9P will be out the window forever. Do you have a
> solution to that?

 Does "improve 9p to the point where no one will even minimally
criticise it" count? :)
 9p certainly deserves some criticism as it stands - its sensitivity
to latency means it works great on a local network, but poorly over
something as wide as the internet. Though as Erik pointed out not so
long ago, this is a limitation plan 9's 9p client code (and probably
the client portion of every other 9p implementation), not the 9p
protocol itself. The problem is it forces the server and client to
synchronise on every read/write syscall, which results in terrible
bandwidth utilisation. Unless we see some remarkable improvements in
network technology in the near future, I'd be surprised to see 9p gain
any foothold outside local networks before this problem is solved (I
should really take a close look at Op). NFS or something similar that
is only concerned with serving "regular" files could do a much better
job here; 9p is at a disadvantage because it is so general. Having to
support arbitrary file semantics makes it difficult to come up with
any sort of safe lookahead scheme to avoid waiting for a network round
trip on every read()...
 OTOH, I wonder what semantics are generally used... the common sorts
of files are:

* "regular files" - a persistent array of bytes, whatever you write()
to a certain offset will show up again when you read() the same
offset.

* ctl files - write()s are not preserved, but affect the state of the
file server in some arbitrary way. read()s tend to give some brief
information about the state.

* event files - read()s block until something interesting happens.
write()s might allow bi-directional events.

* clone files - a read() of this file creates a new heirachy.

 I'm sure I've missed something, but readahead is safe for all these
constructs except event files, where if you readahead (and get data)
but the client closes the file before actually read()-ing the buffered
data, you really want to tell the file server to "put back" those
events. Buggerit, I'm stumped already. :S
-sqweek