From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Tue, 20 Mar 2012 21:52:54 -0400 To: 9fans@9fans.net Message-ID: In-Reply-To: References: <011b9189eff1a19b0e074faf782dd598@coraid.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Regarding 9p based "protocols" message framing Topicbox-Message-UUID: 6c7ec4c0-ead7-11e9-9d60-3106f5b1d025 > > =C2=A0 =C2=A0I would beg to differ on this subject... Because a lot o= f 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.) >=20 > 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 parti= cular, other than you send the appropriate Twrite and get the matching Rwrite ba= ck. 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 mo= re 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 conventi= ons, but there aren't any cops. - erik