> 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
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,
> On Tue, May 4, 2010 at 11:16 AM, erik quanstrom
> 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 differen
On Tue, May 4, 2010 at 11:16 AM, erik quanstrom
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
> 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 m
On Tue, May 4, 2010 at 3:46 PM, Jorden M 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
On Mon, May 3, 2010 at 4:22 PM, Russ Cox wrote:
> On Mon, May 3, 2010 at 11:10 AM, David du Colombier <0in...@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 b
On Mon, May 3, 2010 at 11:10 AM, David du Colombier <0in...@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 ba
> 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
Hi David,
On Sunday, May 2, 2010, David du Colombier <0in...@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-
> 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/
On Tue, Apr 27, 2010 at 9:46 PM, erik quanstrom wrote:
> On Tue Apr 27 00:31:03 EDT 2010, news...@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 strengt
On Tue Apr 27 00:31:03 EDT 2010, news...@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
On Tue Apr 27 00:33:52 EDT 2010, lu...@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.
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'.
> 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
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
On Mon Apr 26 18:04:40 EDT 2010, aku...@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!
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 wrot
>
> "...
> 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
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
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
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 wrote:
> Take a look at Noah's PUSH shell. It's not there yet, but
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
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
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 wrote:
>> cpu -c 'procdata' | process
>> ...
>> Per
> 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
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
27 matches
Mail list logo
