* [9fans] Distributed Pipelines @ 2010-04-25 23:56 Akshat Kumar 2010-04-26 0:40 ` Steve Simon 0 siblings, 1 reply; 27+ messages in thread From: Akshat Kumar @ 2010-04-25 23:56 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs In running some computationally intensive processes between my terminal(s) and cpu server(s), I noticed a problem in trying to join data together by a pipeline: procdata | cpu -c 'process' doesn't really send the output of `procdata' to `process', as the latter is being run on a CPU server. Since there are some use cases where `procdata' might take a long time to get to EOF (or possibly may never reach it), it isn't in my interest to first send the output of `procdata' to a file and then run `process' on the CPU after it's finished. Likewise, there is the inverse problem: cpu -c 'procdata' | process outputs to rio terminal instead of sending output to `process'. It seems to me that the two problems would have similar solutions. Perhaps I'm overlooking some simple solutions here. Any suggestions? Best, ak ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] Distributed Pipelines 2010-04-25 23:56 [9fans] Distributed Pipelines Akshat Kumar @ 2010-04-26 0:40 ` Steve Simon 2010-04-26 0:50 ` Akshat Kumar 0 siblings, 1 reply; 27+ messages in thread From: Steve Simon @ 2010-04-26 0:40 UTC (permalink / raw) To: 9fans > cpu -c 'procdata' | process > ... > Perhaps I'm overlooking some simple solutions here. > Any suggestions? cpu(1) works by starting exportfs on the remote machine and serving the local machines filespace. The remote shell is started with its stdin/out/err attached to /mnt/term/dev/cons, thus the command you tried will not work (by design). what you want is rx(1) which does exactly what you want, somthing like rsh(1) from the Unix world, except it uses plan9' secure authentication; e.g.: rx $cpu | process -Steve ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] Distributed Pipelines 2010-04-26 0:40 ` Steve Simon @ 2010-04-26 0:50 ` Akshat Kumar 2010-04-26 5:45 ` Eric Van Hensbergen 0 siblings, 1 reply; 27+ messages in thread From: Akshat Kumar @ 2010-04-26 0:50 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Thanks Steve, rx $cpu 'procdata' | process works well for one way. However, procdata | rx $cpu 'process' is in the same way as with cpu(1). Any suggestions for piping in that direction? Best, ak On Sun, Apr 25, 2010 at 5:40 PM, Steve Simon <steve@quintile.net> wrote: >> cpu -c 'procdata' | process >> ... >> Perhaps I'm overlooking some simple solutions here. >> Any suggestions? > > cpu(1) works by starting exportfs on the remote machine and serving > the local machines filespace. The remote shell is started with its > stdin/out/err attached to /mnt/term/dev/cons, thus the command you > tried will not work (by design). > > what you want is rx(1) which does exactly what you want, somthing > like rsh(1) from the Unix world, except it uses plan9' secure > authentication; e.g.: > > rx $cpu | process > > -Steve > > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] Distributed Pipelines 2010-04-26 0:50 ` Akshat Kumar @ 2010-04-26 5:45 ` Eric Van Hensbergen 2010-04-26 7:33 ` Akshat Kumar 0 siblings, 1 reply; 27+ messages in thread From: Eric Van Hensbergen @ 2010-04-26 5:45 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Take a look at Noah's PUSH shell. It's not there yet, but maybe later today. Sent from my iPhone On Apr 26, 2010, at 2:50 AM, Akshat Kumar <akumar@mail.nanosouffle.net> wrote: > Thanks Steve, > > rx $cpu 'procdata' | process > > works well for one way. > However, > > procdata | rx $cpu 'process' > > is in the same way as with cpu(1). > Any suggestions for piping in that > direction? > > > Best, > ak > > On Sun, Apr 25, 2010 at 5:40 PM, Steve Simon <steve@quintile.net> > wrote: >>> cpu -c 'procdata' | process >>> ... >>> Perhaps I'm overlooking some simple solutions here. >>> Any suggestions? >> >> cpu(1) works by starting exportfs on the remote machine and serving >> the local machines filespace. The remote shell is started with its >> stdin/out/err attached to /mnt/term/dev/cons, thus the command you >> tried will not work (by design). >> >> what you want is rx(1) which does exactly what you want, somthing >> like rsh(1) from the Unix world, except it uses plan9' secure >> authentication; e.g.: >> >> rx $cpu | process >> >> -Steve >> >> > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] Distributed Pipelines 2010-04-26 5:45 ` Eric Van Hensbergen @ 2010-04-26 7:33 ` Akshat Kumar 2010-04-26 7:55 ` Eric Van Hensbergen 0 siblings, 1 reply; 27+ messages in thread From: Akshat Kumar @ 2010-04-26 7:33 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Hi Eric, The only reference to PUSH I see is at http://code.google.com/p/push where the site reads, "This is the new unix port of push." Where might I find the native Plan 9 version? Best, ak On 4/25/10, Eric Van Hensbergen <ericvh@gmail.com> wrote: > Take a look at Noah's PUSH shell. It's not there yet, but maybe later > today. > > Sent from my iPhone > > On Apr 26, 2010, at 2:50 AM, Akshat Kumar > <akumar@mail.nanosouffle.net> wrote: > >> Thanks Steve, >> >> rx $cpu 'procdata' | process >> >> works well for one way. >> However, >> >> procdata | rx $cpu 'process' >> >> is in the same way as with cpu(1). >> Any suggestions for piping in that >> direction? >> >> >> Best, >> ak >> >> On Sun, Apr 25, 2010 at 5:40 PM, Steve Simon <steve@quintile.net> >> wrote: >>>> cpu -c 'procdata' | process >>>> ... >>>> Perhaps I'm overlooking some simple solutions here. >>>> Any suggestions? >>> >>> cpu(1) works by starting exportfs on the remote machine and serving >>> the local machines filespace. The remote shell is started with its >>> stdin/out/err attached to /mnt/term/dev/cons, thus the command you >>> tried will not work (by design). >>> >>> what you want is rx(1) which does exactly what you want, somthing >>> like rsh(1) from the Unix world, except it uses plan9' secure >>> authentication; e.g.: >>> >>> rx $cpu | process >>> >>> -Steve >>> >>> >> > > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] Distributed Pipelines 2010-04-26 7:33 ` Akshat Kumar @ 2010-04-26 7:55 ` Eric Van Hensbergen 2010-04-26 20:00 ` Akshat Kumar 0 siblings, 1 reply; 27+ messages in thread From: Eric Van Hensbergen @ 2010-04-26 7:55 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs The version there is Plan9ports and should work under Plan 9 as well -- if it doesn't, beat on Noah :) -eric On Apr 26, 2010, at 9:33 AM, Akshat Kumar wrote: > Hi Eric, > > The only reference to PUSH I see is > at http://code.google.com/p/push > where the site reads, > > "This is the new unix port of push." > > Where might I find the native Plan 9 > version? > > > Best, > ak > > > On 4/25/10, Eric Van Hensbergen <ericvh@gmail.com> wrote: >> Take a look at Noah's PUSH shell. It's not there yet, but maybe later >> today. >> >> Sent from my iPhone >> >> On Apr 26, 2010, at 2:50 AM, Akshat Kumar >> <akumar@mail.nanosouffle.net> wrote: >> >>> Thanks Steve, >>> >>> rx $cpu 'procdata' | process >>> >>> works well for one way. >>> However, >>> >>> procdata | rx $cpu 'process' >>> >>> is in the same way as with cpu(1). >>> Any suggestions for piping in that >>> direction? >>> >>> >>> Best, >>> ak >>> >>> On Sun, Apr 25, 2010 at 5:40 PM, Steve Simon <steve@quintile.net> >>> wrote: >>>>> cpu -c 'procdata' | process >>>>> ... >>>>> Perhaps I'm overlooking some simple solutions here. >>>>> Any suggestions? >>>> >>>> cpu(1) works by starting exportfs on the remote machine and serving >>>> the local machines filespace. The remote shell is started with its >>>> stdin/out/err attached to /mnt/term/dev/cons, thus the command you >>>> tried will not work (by design). >>>> >>>> what you want is rx(1) which does exactly what you want, somthing >>>> like rsh(1) from the Unix world, except it uses plan9' secure >>>> authentication; e.g.: >>>> >>>> rx $cpu | process >>>> >>>> -Steve >>>> >>>> >>> >> >> > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] Distributed Pipelines 2010-04-26 7:55 ` Eric Van Hensbergen @ 2010-04-26 20:00 ` Akshat Kumar 2010-04-26 21:20 ` erik quanstrom 2010-04-27 4:29 ` Tim Newsham 0 siblings, 2 replies; 27+ messages in thread From: Akshat Kumar @ 2010-04-26 20:00 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs For the record: rx(1) man pages imply the sort of behaviour from rx(1) that I would like: "... eqn paper | rx kremvax troff -ms | rx deepthought lp Parallel processing: do each stage of a pipeline on a different machine. " however, it seems not to work this way. My basic test has been something like: echo '1 2 3' | rx $cpu awk -f $home/comp.awk | gview ... just a simple sample use case. Is there something special about awk(1) that would cause it not to receive standard input the way rx(1) provides it? Even just: rx $cpu awk -f $home/comp.awk wants to take standard input, but apparently doesn't get it. Thanks, ak On 4/26/10, Eric Van Hensbergen <ericvh@gmail.com> wrote: > The version there is Plan9ports and should work under Plan 9 as well -- if > it doesn't, beat on Noah :) > > -eric > > On Apr 26, 2010, at 9:33 AM, Akshat Kumar wrote: > >> Hi Eric, >> >> The only reference to PUSH I see is >> at http://code.google.com/p/push >> where the site reads, >> >> "This is the new unix port of push." >> >> Where might I find the native Plan 9 >> version? >> >> >> Best, >> ak >> >> >> On 4/25/10, Eric Van Hensbergen <ericvh@gmail.com> wrote: >>> Take a look at Noah's PUSH shell. It's not there yet, but maybe later >>> today. >>> >>> Sent from my iPhone >>> >>> On Apr 26, 2010, at 2:50 AM, Akshat Kumar >>> <akumar@mail.nanosouffle.net> wrote: >>> >>>> Thanks Steve, >>>> >>>> rx $cpu 'procdata' | process >>>> >>>> works well for one way. >>>> However, >>>> >>>> procdata | rx $cpu 'process' >>>> >>>> is in the same way as with cpu(1). >>>> Any suggestions for piping in that >>>> direction? >>>> >>>> >>>> Best, >>>> ak >>>> >>>> On Sun, Apr 25, 2010 at 5:40 PM, Steve Simon <steve@quintile.net> >>>> wrote: >>>>>> cpu -c 'procdata' | process >>>>>> ... >>>>>> Perhaps I'm overlooking some simple solutions here. >>>>>> Any suggestions? >>>>> >>>>> cpu(1) works by starting exportfs on the remote machine and serving >>>>> the local machines filespace. The remote shell is started with its >>>>> stdin/out/err attached to /mnt/term/dev/cons, thus the command you >>>>> tried will not work (by design). >>>>> >>>>> what you want is rx(1) which does exactly what you want, somthing >>>>> like rsh(1) from the Unix world, except it uses plan9' secure >>>>> authentication; e.g.: >>>>> >>>>> rx $cpu | process >>>>> >>>>> -Steve >>>>> >>>>> >>>> >>> >>> >> > > > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] Distributed Pipelines 2010-04-26 20:00 ` Akshat Kumar @ 2010-04-26 21:20 ` erik quanstrom 2010-04-26 21:57 ` Akshat Kumar 2010-04-27 4:29 ` Tim Newsham 1 sibling, 1 reply; 27+ messages in thread From: erik quanstrom @ 2010-04-26 21:20 UTC (permalink / raw) To: 9fans > > "... > eqn paper | rx kremvax troff -ms | rx deepthought lp > Parallel processing: do each stage of a pipeline on a > different machine. > " > > however, it seems not to work this way. > My basic test has been something like: > > echo '1 2 3' | rx $cpu awk -f $home/comp.awk | gview cool that you tracked this down. this just doesn't work. the problem seems to be that tcp is eating the eof. awk doesn't know to exit. if you are using il, this does work. ; echo 1 2 3| 8.rx bureau sed s/1/x/ | sed s/2/y/ x y 3 but if you are using tcp, it hangs. sed never sees the eof and doesn't generate output (because it's buffered). the answer isn't obvious to me with tcp as i don't know of a way to half-close a tcp connection — from userspace anyway. - erik ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] Distributed Pipelines 2010-04-26 21:20 ` erik quanstrom @ 2010-04-26 21:57 ` Akshat Kumar 2010-04-26 22:17 ` erik quanstrom 0 siblings, 1 reply; 27+ messages in thread From: Akshat Kumar @ 2010-04-26 21:57 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Hi Erik, Thanks for figuring that bit out! Indeed, it seems TCP is the problem, and IL seems to work fine for me for the moment: echo '1 2 3' | rx il!$cpu!17009 awk -f $home/comp.awk | gview works perfectly! I'll try to dig deeper into the TCP case. Best, ak On 4/26/10, erik quanstrom <quanstro@labs.coraid.com> wrote: >> >> "... >> eqn paper | rx kremvax troff -ms | rx deepthought lp >> Parallel processing: do each stage of a pipeline on a >> different machine. >> " >> >> however, it seems not to work this way. >> My basic test has been something like: >> >> echo '1 2 3' | rx $cpu awk -f $home/comp.awk | gview > > cool that you tracked this down. > > this just doesn't work. the problem seems to be that tcp > is eating the eof. awk doesn't know to exit. > > if you are using il, this does work. > > ; echo 1 2 3| 8.rx bureau sed s/1/x/ | sed s/2/y/ > x y 3 > > but if you are using tcp, it hangs. sed never sees the > eof and doesn't generate output (because it's buffered). > > the answer isn't obvious to me with tcp as i don't > know of a way to half-close a tcp connection — > from userspace anyway. > > - erik > > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] Distributed Pipelines 2010-04-26 21:57 ` Akshat Kumar @ 2010-04-26 22:17 ` erik quanstrom 2010-04-27 8:48 ` Derek Fawcus 0 siblings, 1 reply; 27+ messages in thread From: erik quanstrom @ 2010-04-26 22:17 UTC (permalink / raw) To: 9fans On Mon Apr 26 18:04:40 EDT 2010, akumar@mail.nanosouffle.net wrote: > Hi Erik, > > Thanks for figuring that bit out! > Indeed, it seems TCP is the > problem, and IL seems to work > fine for me for the moment: > > echo '1 2 3' | rx il!$cpu!17009 awk -f $home/comp.awk | gview > > works perfectly! > > I'll try to dig deeper into the TCP case. tcp doesn't preserve message boundaries, so the 0-byte write should get tossed. i don't think there's any hope with rx's current setup. you'd need to resort to stuffing or some other how-to- hide-yer-oob data trick or alternately a tcp half-close. - erik ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] Distributed Pipelines 2010-04-26 22:17 ` erik quanstrom @ 2010-04-27 8:48 ` Derek Fawcus 0 siblings, 0 replies; 27+ messages in thread From: Derek Fawcus @ 2010-04-27 8:48 UTC (permalink / raw) To: 9fans On Mon, Apr 26, 2010 at 06:17:38PM -0400, erik quanstrom wrote: > you'd > need to resort to stuffing or some other how-to- > hide-yer-oob data trick or alternately a tcp > half-close. Urgent pointer? but the half close sounds 'better'. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] Distributed Pipelines 2010-04-26 20:00 ` Akshat Kumar 2010-04-26 21:20 ` erik quanstrom @ 2010-04-27 4:29 ` Tim Newsham 2010-04-27 4:31 ` lucio 2010-04-27 12:46 ` erik quanstrom 1 sibling, 2 replies; 27+ messages in thread From: Tim Newsham @ 2010-04-27 4:29 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs What about some mounting/binding hackery where you replace /dev/cons so that the original "cpu" command works? Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] Distributed Pipelines 2010-04-27 4:29 ` Tim Newsham @ 2010-04-27 4:31 ` lucio 2010-04-27 12:04 ` erik quanstrom 2010-04-27 12:46 ` erik quanstrom 1 sibling, 1 reply; 27+ messages in thread From: lucio @ 2010-04-27 4:31 UTC (permalink / raw) To: 9fans > What about some mounting/binding hackery where you replace > /dev/cons so that the original "cpu" command works? I was going to suggest using UDP instead of TCP or IL. Is that a silly idea? ++L ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] Distributed Pipelines 2010-04-27 4:31 ` lucio @ 2010-04-27 12:04 ` erik quanstrom 0 siblings, 0 replies; 27+ messages in thread From: erik quanstrom @ 2010-04-27 12:04 UTC (permalink / raw) To: lucio, 9fans On Tue Apr 27 00:33:52 EDT 2010, lucio@proxima.alt.za wrote: > > What about some mounting/binding hackery where you replace > > /dev/cons so that the original "cpu" command works? > > I was going to suggest using UDP instead of TCP or IL. Is that a silly > idea? cpu/rx require a stream protocol. udp will not do. - erik ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] Distributed Pipelines 2010-04-27 4:29 ` Tim Newsham 2010-04-27 4:31 ` lucio @ 2010-04-27 12:46 ` erik quanstrom 2010-05-01 18:51 ` Ryousei Takano 1 sibling, 1 reply; 27+ messages in thread From: erik quanstrom @ 2010-04-27 12:46 UTC (permalink / raw) To: 9fans On Tue Apr 27 00:31:03 EDT 2010, newsham@lava.net wrote: > What about some mounting/binding hackery where you replace > /dev/cons so that the original "cpu" command works? why the resistance to il? rx is a good example of il's strengths. in order for cpu to work, it uses 2 extra processes. rx is much more efficient. (and 1/4 the code) great for your trusted network. or perhaps your local supercomputer. rx doesn't do encryption. a srx using ssl/tls would be able to sneak a 0 write through since the record layer should expand that into a application record with application data length of 0. - erik ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] Distributed Pipelines 2010-04-27 12:46 ` erik quanstrom @ 2010-05-01 18:51 ` Ryousei Takano 2010-05-01 19:40 ` David du Colombier 0 siblings, 1 reply; 27+ messages in thread From: Ryousei Takano @ 2010-05-01 18:51 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Tue, Apr 27, 2010 at 9:46 PM, erik quanstrom <quanstro@quanstro.net> wrote: > On Tue Apr 27 00:31:03 EDT 2010, newsham@lava.net wrote: >> What about some mounting/binding hackery where you replace >> /dev/cons so that the original "cpu" command works? > > why the resistance to il? rx is a good example of il's strengths. > in order for cpu to work, it uses 2 extra processes. rx is much > more efficient. (and 1/4 the code) great for your trusted network. > or perhaps your local supercomputer. > > rx doesn't do encryption. a srx using ssl/tls would be > able to sneak a 0 write through since the record layer > should expand that into a application record with > application data length of 0. > I became interested in IL protocol. Please tell me why IL is removed from the main distribution. Thanks, Ryousei ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] Distributed Pipelines 2010-05-01 18:51 ` Ryousei Takano @ 2010-05-01 19:40 ` David du Colombier 2010-05-03 3:19 ` Ryousei Takano 0 siblings, 1 reply; 27+ messages in thread From: David du Colombier @ 2010-05-01 19:40 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > Please tell me why IL is removed from the main distribution. From the Fourth Edition Release Notes [1] : "We are phasing out the IL protocol since it doesn't handle long-distance connections well (and long-distance networks don't handle it well, either)" [1] http://plan9.bell-labs.com/sys/doc/release4.html -- David du Colombier ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] Distributed Pipelines 2010-05-01 19:40 ` David du Colombier @ 2010-05-03 3:19 ` Ryousei Takano 2010-05-03 18:10 ` David du Colombier 0 siblings, 1 reply; 27+ messages in thread From: Ryousei Takano @ 2010-05-03 3:19 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Hi David, On Sunday, May 2, 2010, David du Colombier <0intro@gmail.com> wrote: >> Please tell me why IL is removed from the main distribution. > > From the Fourth Edition Release Notes [1] : > > "We are phasing out the IL protocol since it doesn't > handle long-distance connections well (and long-distance > networks don't handle it well, either)" > > [1] http://plan9.bell-labs.com/sys/doc/release4.html > Thanks for your quick response. Does it mean IL has performance issue on long-distance networks? Thanks, Ryousei ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] Distributed Pipelines 2010-05-03 3:19 ` Ryousei Takano @ 2010-05-03 18:10 ` David du Colombier 2010-05-03 20:22 ` Russ Cox 0 siblings, 1 reply; 27+ messages in thread From: David du Colombier @ 2010-05-03 18:10 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > Does it mean IL has performance issue on long-distance networks? As I understand it, the real problem is that Internet doesn't handle IL well. -- David du Colombier ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] Distributed Pipelines 2010-05-03 18:10 ` David du Colombier @ 2010-05-03 20:22 ` Russ Cox 2010-05-04 15:46 ` Jorden M 0 siblings, 1 reply; 27+ messages in thread From: Russ Cox @ 2010-05-03 20:22 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, May 3, 2010 at 11:10 AM, David du Colombier <0intro@gmail.com> wrote: >> Does it mean IL has performance issue on long-distance networks? > > As I understand it, the real problem is that Internet > doesn't handle IL well. They are both problems. Routing issues aside, IL is particularly bad on asymmetric networks like cable modems (download much faster than upload). Russ ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] Distributed Pipelines 2010-05-03 20:22 ` Russ Cox @ 2010-05-04 15:46 ` Jorden M 2010-05-04 17:44 ` ron minnich 0 siblings, 1 reply; 27+ messages in thread From: Jorden M @ 2010-05-04 15:46 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, May 3, 2010 at 4:22 PM, Russ Cox <rsc@swtch.com> wrote: > On Mon, May 3, 2010 at 11:10 AM, David du Colombier <0intro@gmail.com> wrote: >>> Does it mean IL has performance issue on long-distance networks? >> >> As I understand it, the real problem is that Internet >> doesn't handle IL well. > > They are both problems. Routing issues aside, > IL is particularly bad on asymmetric networks like > cable modems (download much faster than upload). > Did anyone experiment with using sliding windows in IL? Could help. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] Distributed Pipelines 2010-05-04 15:46 ` Jorden M @ 2010-05-04 17:44 ` ron minnich 2010-05-04 18:16 ` erik quanstrom 0 siblings, 1 reply; 27+ messages in thread From: ron minnich @ 2010-05-04 17:44 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Tue, May 4, 2010 at 3:46 PM, Jorden M <jrm8005@gmail.com> wrote: > Did anyone experiment with using sliding windows in IL? Could help. The question I have, based on probably not enough knowledge: how much of what IL was intended to do is remedied by IPV6? One thing I recall is that a big problem with v4 was that it did not preserve record boundaries, which seems won't be an issue in v6. What else did IL remedy, and how much of what v6 does not remedy is important? ron ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] Distributed Pipelines 2010-05-04 17:44 ` ron minnich @ 2010-05-04 18:16 ` erik quanstrom 2010-05-04 18:36 ` ron minnich 0 siblings, 1 reply; 27+ messages in thread From: erik quanstrom @ 2010-05-04 18:16 UTC (permalink / raw) To: 9fans > The question I have, based on probably not enough knowledge: how much > of what IL was intended to do is remedied by IPV6? One thing I recall > is that a big problem with v4 was that it did not preserve record > boundaries, which seems won't be an issue in v6. What else did IL > remedy, and how much of what v6 does not remedy is important? i believe that it is tcp that doesn't preserve record boundaries, not ip. - erik ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] Distributed Pipelines 2010-05-04 18:16 ` erik quanstrom @ 2010-05-04 18:36 ` ron minnich 2010-05-04 18:50 ` erik quanstrom 2010-05-04 19:51 ` Russ Cox 0 siblings, 2 replies; 27+ messages in thread From: ron minnich @ 2010-05-04 18:36 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Tue, May 4, 2010 at 11:16 AM, erik quanstrom <quanstro@labs.coraid.com> wrote: > i believe that it is tcp that doesn't preserve record boundaries, not > ip. Let me rephrase. My understanding is that tcp on v6 preserves record boundaries. Is that wrong? ron ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] Distributed Pipelines 2010-05-04 18:36 ` ron minnich @ 2010-05-04 18:50 ` erik quanstrom 2010-05-04 19:51 ` Russ Cox 1 sibling, 0 replies; 27+ messages in thread From: erik quanstrom @ 2010-05-04 18:50 UTC (permalink / raw) To: 9fans > On Tue, May 4, 2010 at 11:16 AM, erik quanstrom > <quanstro@labs.coraid.com> wrote: > > > i believe that it is tcp that doesn't preserve record boundaries, not > > ip. > > Let me rephrase. My understanding is that tcp on v6 preserves record > boundaries. Is that wrong? perhaps you mean sctcp? i don't see any differences in processing in /sys/src/9/ip/tcp.c that depend on ip4/ip6. here's wiki's take on the matter: http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol (scroll down to the table) - erik ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] Distributed Pipelines 2010-05-04 18:36 ` ron minnich 2010-05-04 18:50 ` erik quanstrom @ 2010-05-04 19:51 ` Russ Cox 2010-05-04 19:59 ` erik quanstrom 1 sibling, 1 reply; 27+ messages in thread From: Russ Cox @ 2010-05-04 19:51 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs TCP doesn't preserve message boundaries. The pre-9P2000 kernels relied on having a transport protocol that preserved message boundaries in order to work one 9P packet at a time with ordinary read calls. You could work around it by pushing an "fcall" stream module to reinsert the boundaries on TCP, but it was extra hassle. In the 9P2000 rewrite, we introduced a read9pmsg function to the C library and fixed the kernel to do the same, so that the protocol and its implementations would not depend on the underlying transport for message boundaries. So it doesn't matter anymore. The fix was in the 9P implementations, not IPv6. Russ ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [9fans] Distributed Pipelines 2010-05-04 19:51 ` Russ Cox @ 2010-05-04 19:59 ` erik quanstrom 0 siblings, 0 replies; 27+ messages in thread From: erik quanstrom @ 2010-05-04 19:59 UTC (permalink / raw) To: 9fans > So it doesn't matter anymore. The fix was in the 9P > implementations, not IPv6. it doesn't matter anymore for 9p. but rx is still broken over tcp. - erik ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2010-05-04 19:59 UTC | newest] Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-04-25 23:56 [9fans] Distributed Pipelines Akshat Kumar 2010-04-26 0:40 ` Steve Simon 2010-04-26 0:50 ` Akshat Kumar 2010-04-26 5:45 ` Eric Van Hensbergen 2010-04-26 7:33 ` Akshat Kumar 2010-04-26 7:55 ` Eric Van Hensbergen 2010-04-26 20:00 ` Akshat Kumar 2010-04-26 21:20 ` erik quanstrom 2010-04-26 21:57 ` Akshat Kumar 2010-04-26 22:17 ` erik quanstrom 2010-04-27 8:48 ` Derek Fawcus 2010-04-27 4:29 ` Tim Newsham 2010-04-27 4:31 ` lucio 2010-04-27 12:04 ` erik quanstrom 2010-04-27 12:46 ` erik quanstrom 2010-05-01 18:51 ` Ryousei Takano 2010-05-01 19:40 ` David du Colombier 2010-05-03 3:19 ` Ryousei Takano 2010-05-03 18:10 ` David du Colombier 2010-05-03 20:22 ` Russ Cox 2010-05-04 15:46 ` Jorden M 2010-05-04 17:44 ` ron minnich 2010-05-04 18:16 ` erik quanstrom 2010-05-04 18:36 ` ron minnich 2010-05-04 18:50 ` erik quanstrom 2010-05-04 19:51 ` Russ Cox 2010-05-04 19:59 ` erik quanstrom
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).