From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <5fa9fbfe115a9cd5a81d0feefe413192@quintile.net> <4fa1305e0f56a0ef89c2e05320fa5997@coraid.com> Date: Thu, 29 Apr 2010 05:54:34 -0700 Message-ID: From: David Leimbach To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=000e0cdf1c40ec5b3a04855fa022 Subject: Re: [9fans] A simple experiment Topicbox-Message-UUID: 123c0cf8-ead6-11e9-9d60-3106f5b1d025 --000e0cdf1c40ec5b3a04855fa022 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 29, 2010 at 5:40 AM, roger peppe wrote: > On 28 April 2010 19:42, ron minnich wrote: > > We did a simple experiment recently: added a new 9p type called > > Tstream, because this issue of streams vs. transactions has been > > bugging me for years. The semantics are simple: it's a lot like Tread > > (almost same packet) but a single Tstream results in any number of > > Rstreams, until you hit no more data (/dev/mouse) or maybe EOF > > (/usr/rminnich/movie). Andrey tossed a sample implementation into > > newsham's 9p library. We saw a 27x improvement in performance from > > calgary to sandia for a big file. Fcp did not come close. > > what happens if the consumer is slow and the Rstream writer > blocks? how do you stop all the other replies on the connection > waiting for the consumer to get on with it? > > in fact, how do you stop it deadlocking if the consumer is in > fact waiting for one of those replies? > > i suppose this comes down to what the API looks like. > isochronous might be easier, as a slow reader is a bad reader > so you could just throw away some data. > > It sounds ok on the surface so far. Does RStream signal the end of the stream chunks, or does the TStreamer already know that answer? Is there any sort of realtime constraint for handling incoming RStream chunks? I would think this could be ok, even if it forces the client to put the streamed blocks somewhere handy while processing is going on. Streaming audio and video over plan 9 links this way might be nice. But then I start to wonder why we feel we want to compete with HTTP when it already works, and is still fairly simple. Nothing wrong with improving 9P I suppose, but what's so wrong with HTTP transfers that it warrants changing our beloved resource sharing protocol? Maybe I'm being too practical, and not feeling adventurous or something :-) Dave --000e0cdf1c40ec5b3a04855fa022 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Apr 29, 2010 at 5:40 AM, roger p= eppe <rogpeppe@g= mail.com> wrote:
On 28 April 2010 19:42, ron minnich <rminnich@gmail.com> wrote:
> We did a simple experiment recently: added a new 9p type called
> Tstream, because this issue of streams vs. transactions has been
> bugging me for years. The semantics are simple: it's a lot like Tr= ead
> (almost same packet) but a single Tstream results in any number of
> Rstreams, until you hit no more data (/dev/mouse) or maybe EOF
> (/usr/rminnich/movie). Andrey tossed a sample implementation into
> newsham's 9p library. We =A0saw a 27x improvement in performance f= rom
> calgary to sandia for a big file. Fcp did not come close.

what happens if the consumer is slow and the Rstream writer
blocks? how do you stop all the other replies on the connection
waiting for the consumer to get on with it?

in fact, how do you stop it deadlocking if the consumer is in
fact waiting for one of those replies?

i suppose this comes down to what the API looks like.
isochronous might be easier, as a slow reader is a bad reader
so you could just throw away some data.


It sounds ok on the surface so far. = =A0Does RStream signal the end of the stream chunks, or does the TStreamer = already know that answer? =A0Is there any sort of realtime constraint for h= andling incoming RStream chunks? =A0 I would think this could be ok, even i= f it forces the client to put the streamed blocks somewhere handy while pro= cessing is going on. =A0Streaming audio and video over plan 9 links this wa= y might be nice.

But then I start to wonder why we feel we want to compe= te with HTTP when it already works, and is still fairly simple. =A0Nothing = wrong with improving 9P I suppose, but what's so wrong with HTTP transf= ers that it warrants changing our beloved resource sharing protocol? =A0May= be I'm being too practical, and not feeling adventurous or something :-= )

Dave

--000e0cdf1c40ec5b3a04855fa022--