Re: [9fans] Regarding 9p based "protocols" message framing

[erik quanstrom <quanstro@quanstro.net>]

> >    I would beg to differ on this subject... Because a lot of tools in
> > the Plan9 environment expose their facilities as 9p file systems, but
> > expose other semantics than that of "generic" files -- i.e. a
> > contiguous stream of bytes from start to EOF -- like for example RPC
> > semantic in case of factotum; thus I would say that 9p is used as a
> > "session" layer in the OSI terminology. (But as in TCP/IP stack we
> > don't have other layers between "transport" and "application" I would
> > call it a "transport" layer in such a context.)
> 
> That's one way of looking at it.  However, the "file as a stream of
> bytes" abstraction is mapped onto 9P at a higher layer; 9P itself is
> really about discrete messages.  The canonical "transport" layer in
> TCP/IP is TCP.

i think you can put a finer point on this.  section 5 of the manual
defines 9p by defining its messages, and the relationship between them.
what it doesn't define is semantics.

what does it mean to "write n bytes at offset o".  well, nothing in particular,
other than you send the appropriate Twrite and get the matching Rwrite back.
it's perfectly valid for the file server to ignore the write (/dev/null) or to
halt and catch fire.  file servers as a whole are unfortunately rather more
ordinary.

i think it's important to note (see /sys/doc/net.ps) that this would all
be utter chaos if it weren't for conventions.  plan 9 has strong conventions,
but there aren't any cops.

- erik