From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Fri, 16 Mar 2012 19:55:24 +0200 Message-ID: From: Ciprian Dorin Craciun 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: 6a165b08-ead7-11e9-9d60-3106f5b1d025 On Fri, Mar 16, 2012 at 19:36, Russ Cox wrote: > On Fri, Mar 16, 2012 at 7:40 AM, Ciprian Dorin Craciun > 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. > > Even outside Plan 9, this is not always the case. > UDP, IP, ethernet, Unix datagram sockets, email, HTTP. > They're all message-based protocols. > > Russ I am aware that there are other types of transports with other semantics. Nevertheless I guess that at least 90% of the existing protocols are built directly on top of stream based transports than datagram ones. (I'm not speaking of ubiquity / underlaying technology, or else we'd conclude that we use Ethernet in 99.999% of the cases.) And what is even more funny, is that I guess a good majority of the protocols are in the end message-based (as you've mentioned HTTP, SMTP, etc.) although they are built ontop of a stream based protocol. Furthermore 9p exposes a semantic more similar with TCP than with UDP, and only when you take into account the read / write atomicity you see it as a datagram protocol. My concert was that in general a programmer used to implement things ontop of stream based protocols was "thought" to expect that one read on the client is not in general one read on the server due to fragmentation, etc., and that he must frame his messages accordingly. Thus my question was if when working with 9p it is a good choice to do explicit framing (as in the case building ontop of TCP) or to take for granted the read / write atomicity. Ciprian.