[9fans] streams

[9fans] streams

[Charles Forsyth]

i think it might be helpful to have a transport protocol along the lines
of Bryan Ford's SST, which allows a stream to create substreams
with separate flow control and other attributes. a primary 9p stream
might create a substream for a large Tread or Twrite.
the facility could be emulated for existing protocols, although addressing
puzzles make that trickier that one might like. the demo SST implementation
was built on UDP. a service to resolve addressing puzzles might be useful too.

Re: [9fans] streams

[Nemo]

why not mux tcp instead?

On Feb 20, 2011, at 2:35 AM, Charles Forsyth <forsyth@terzarima.net> wrote:

> i think it might be helpful to have a transport protocol along the lines
> of Bryan Ford's SST, which allows a stream to create substreams
> with separate flow control and other attributes. a primary 9p stream
> might create a substream for a large Tread or Twrite.
> the facility could be emulated for existing protocols, although addressing
> puzzles make that trickier that one might like. the demo SST implementation
> was built on UDP. a service to resolve addressing puzzles might be useful too.
> 

Re: [9fans] streams

[erik quanstrom]

On Sun Feb 20 11:48:58 EST 2011, nemo.mbox@gmail.com wrote:
> why not mux tcp instead?
>

there's more to the world than tcp?

- erik

Re: [9fans] streams

[Russ Cox]

On Sun, Feb 20, 2011 at 11:55 AM, Nemo <nemo.mbox@gmail.com> wrote:
> why not mux tcp instead?

See the paper.  Among other things, independent flow control
on the different sub-streams.

http://www.brynosaurus.com/pub/net/sst-abs.html

Re: [9fans] streams

[Nemo]

> i did read it before asking, and i'm still wondering why
> not mux tcp instead (provided you dont want/need that extra feature
> or dont implement it that way)
>
>
> On Feb 20, 2011, at 10:59 PM, Russ Cox <rsc@swtch.com> wrote:
>
>> On Sun, Feb 20, 2011 at 11:55 AM, Nemo <nemo.mbox@gmail.com> wrote:
>>> why not mux tcp instead?
>>
>> See the paper.  Among other things, independent flow control
>> on the different sub-streams.
>>
>> http://www.brynosaurus.com/pub/net/sst-abs.html

Re: [9fans] streams

[Nemo]

i reply myself; i think they use sst to mix multimedia streams, and
in that case a lost packet in one stream (say text) would
delay other streams (say audio) that do not need to be delayed if
you use sst.

But otherwise I still think that muxing a tcp stream might provide
something similar (without some of sst ffeatures, i admit) and a lot
easier to implement. I'll write a toy to see if this is wrong.

thanks for your reply, Russ,  btw.

On Feb 21, 2011, at 12:25 AM, Nemo <nemo.mbox@gmail.com> wrote:

>
>> i did read it before asking, and i'm still wondering why
>> not mux tcp instead (provided you dont want/need that extra feature
>> or dont implement it that way)
>>
>>
>> On Feb 20, 2011, at 10:59 PM, Russ Cox <rsc@swtch.com> wrote:
>>
>>> On Sun, Feb 20, 2011 at 11:55 AM, Nemo <nemo.mbox@gmail.com> wrote:
>>>> why not mux tcp instead?
>>>
>>> See the paper.  Among other things, independent flow control
>>> on the different sub-streams.
>>>
>>> http://www.brynosaurus.com/pub/net/sst-abs.html

Re: [9fans] streams

[Mechiel Lukkien]

On Mon, Feb 21, 2011 at 07:53:30PM +0100, Nemo wrote:
> i reply myself; i think they use sst to mix multimedia streams, and
> in that case a lost packet in one stream (say text) would
> delay other streams (say audio) that do not need to be delayed if
> you use sst.
>
> But otherwise I still think that muxing a tcp stream might provide
> something similar (without some of sst ffeatures, i admit) and a lot
> easier to implement. I'll write a toy to see if this is wrong.

fwiw, just put this code i had in my homedir online:

	http://www.ueber.net/code/r/fdmux

the readme has info & warnings, appl/lib/fdmux.b starts with a description
of the protocol.

yes, sst can (and does seem to) improve on many levels.

Re: [9fans] streams

[roger peppe]

On 21 February 2011 18:53, Nemo <nemo.mbox@gmail.com> wrote:
> i reply myself; i think they use sst to mix multimedia streams, and
> in that case a lost packet in one stream (say text) would
> delay other streams (say audio) that do not need to be delayed if
> you use sst.
>
> But otherwise I still think that muxing a tcp stream might provide
> something similar (without some of sst ffeatures, i admit) and a lot
> easier to implement. I'll write a toy to see if this is wrong.

i've been playing around with something similar in Go, layering
rpc (analogous to 9p) over netchan (analogous to SST), which
seems to work quite well, although i haven't done many
performance experiments.

this by itself doesn't entirely mitigate 9p performance though.
there are many sequences of operations that still
require multiple unnecessary round trips.

i've also been experimenting with a 9p modification that
suggested some while ago, allowing multiple outstanding
requests to be queued in sequence. it works, but the code
still needs quite a bit of polishing.

the summary is here:
http://code.google.com/p/rog-go/source/browse/new9p/doc.txt

Re: [9fans] streams

[erik quanstrom]

> i've also been experimenting with a 9p modification that
> suggested some while ago, allowing multiple outstanding
> requests to be queued in sequence. it works, but the code
> still needs quite a bit of polishing.

queued or sent?

- erik

Re: [9fans] streams

[roger peppe]

On 22 February 2011 13:25, erik quanstrom <quanstro@quanstro.net> wrote:
>> i've also been experimenting with a 9p modification that
>> suggested some while ago, allowing multiple outstanding
>> requests to be queued in sequence. it works, but the code
>> still needs quite a bit of polishing.
>
> queued or sent?

sent, then queued at the server side if necessary.

Re: [9fans] streams

[Bakul Shah]

On Sun, 20 Feb 2011 01:35:28 GMT Charles Forsyth <forsyth@terzarima.net>  wrote:
> i think it might be helpful to have a transport protocol along the lines
> of Bryan Ford's SST, which allows a stream to create substreams
> with separate flow control and other attributes. a primary 9p stream
> might create a substream for a large Tread or Twrite.
> the facility could be emulated for existing protocols, although addressing
> puzzles make that trickier that one might like. the demo SST implementation
> was built on UDP. a service to resolve addressing puzzles might be useful too
> .

Thanks.  Read the paper but need to think about it more....
Seems quite interesting.  The idea of using substreams for
large xfers is clever! A stream analogue of worker threads.
Not sure what addressing puzzle you are talking about.