* [9fans] streams @ 2011-02-20 1:35 Charles Forsyth 2011-02-20 16:55 ` Nemo 2011-02-21 0:01 ` Bakul Shah 0 siblings, 2 replies; 11+ messages in thread From: Charles Forsyth @ 2011-02-20 1:35 UTC (permalink / raw) To: 9fans 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] streams 2011-02-20 1:35 [9fans] streams Charles Forsyth @ 2011-02-20 16:55 ` Nemo 2011-02-20 21:37 ` erik quanstrom 2011-02-20 21:59 ` Russ Cox 2011-02-21 0:01 ` Bakul Shah 1 sibling, 2 replies; 11+ messages in thread From: Nemo @ 2011-02-20 16:55 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] streams 2011-02-20 16:55 ` Nemo @ 2011-02-20 21:37 ` erik quanstrom 2011-02-20 21:59 ` Russ Cox 1 sibling, 0 replies; 11+ messages in thread From: erik quanstrom @ 2011-02-20 21:37 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] streams 2011-02-20 16:55 ` Nemo 2011-02-20 21:37 ` erik quanstrom @ 2011-02-20 21:59 ` Russ Cox [not found] ` <96B1444A-B40A-4F42-A387-1129C87D1387@gmail.com> 1 sibling, 1 reply; 11+ messages in thread From: Russ Cox @ 2011-02-20 21:59 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs; +Cc: Nemo 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <96B1444A-B40A-4F42-A387-1129C87D1387@gmail.com>]
* Re: [9fans] streams [not found] ` <96B1444A-B40A-4F42-A387-1129C87D1387@gmail.com> @ 2011-02-20 23:25 ` Nemo 2011-02-21 18:53 ` Nemo 0 siblings, 1 reply; 11+ messages in thread From: Nemo @ 2011-02-20 23:25 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] streams 2011-02-20 23:25 ` Nemo @ 2011-02-21 18:53 ` Nemo 2011-02-21 20:41 ` Mechiel Lukkien 2011-02-22 10:15 ` roger peppe 0 siblings, 2 replies; 11+ messages in thread From: Nemo @ 2011-02-21 18:53 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] streams 2011-02-21 18:53 ` Nemo @ 2011-02-21 20:41 ` Mechiel Lukkien 2011-02-22 10:15 ` roger peppe 1 sibling, 0 replies; 11+ messages in thread From: Mechiel Lukkien @ 2011-02-21 20:41 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] streams 2011-02-21 18:53 ` Nemo 2011-02-21 20:41 ` Mechiel Lukkien @ 2011-02-22 10:15 ` roger peppe 2011-02-22 13:25 ` erik quanstrom 1 sibling, 1 reply; 11+ messages in thread From: roger peppe @ 2011-02-22 10:15 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] streams 2011-02-22 10:15 ` roger peppe @ 2011-02-22 13:25 ` erik quanstrom 2011-02-22 13:44 ` roger peppe 0 siblings, 1 reply; 11+ messages in thread From: erik quanstrom @ 2011-02-22 13:25 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] streams 2011-02-22 13:25 ` erik quanstrom @ 2011-02-22 13:44 ` roger peppe 0 siblings, 0 replies; 11+ messages in thread From: roger peppe @ 2011-02-22 13:44 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] streams 2011-02-20 1:35 [9fans] streams Charles Forsyth 2011-02-20 16:55 ` Nemo @ 2011-02-21 0:01 ` Bakul Shah 1 sibling, 0 replies; 11+ messages in thread From: Bakul Shah @ 2011-02-21 0:01 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2011-02-22 13:44 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-02-20 1:35 [9fans] streams Charles Forsyth 2011-02-20 16:55 ` Nemo 2011-02-20 21:37 ` erik quanstrom 2011-02-20 21:59 ` Russ Cox [not found] ` <96B1444A-B40A-4F42-A387-1129C87D1387@gmail.com> 2011-02-20 23:25 ` Nemo 2011-02-21 18:53 ` Nemo 2011-02-21 20:41 ` Mechiel Lukkien 2011-02-22 10:15 ` roger peppe 2011-02-22 13:25 ` erik quanstrom 2011-02-22 13:44 ` roger peppe 2011-02-21 0:01 ` Bakul Shah
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).