From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <011b9189eff1a19b0e074faf782dd598@coraid.com> From: Dan Cross Date: Tue, 20 Mar 2012 08:32:02 -0400 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Regarding 9p based "protocols" message framing Topicbox-Message-UUID: 6c1d8ffc-ead7-11e9-9d60-3106f5b1d025 On Tue, Mar 20, 2012 at 7:42 AM, Yaroslav wrote: >> =C2=A0Why was I puzzled: because as a non Plan9 user / developer, I >> usually think of the underlaying transport technology (be it sockets >> or 9p) as a stream of bytes without explicit framing. > > As I understand, 9P itself is designed to operate on top of a > message-oriented transport; however, it has everything required to run > over a stream, esp. message length at beginning of every message. > Framing is done by the library: the read9pmsg routine performs as many > reads as necessary to return a complete 9P message to the caller. Perhaps initially: over an IP network, 9P used to run over IL. With 9P2000, IL was deprecated and 9P was most typically run over TCP. There was a very old message to 9fans (like, early 90's kind of old) that implied that IL was much more efficient than TCP on the wire, but it probably doesn't matter now. 9P itself is not a stream-oriented protocol, nor is it what one would generally call, 'transport technology.' - Dan C.