> If the sender->receiver pipe can hold N bytes and the sender
> is streaming (that is, keeping the pipe full), the sender
> *will* be ahead of the receiver by N bytes. So a *streaming*
> protcol has to allow it to be N bytes ahead.
i don't think this is the normal definition.
> Even if you have
> My impression is that it was pulled from mainline mostly because it
> was seen as being too much work to maintain for a small group. It's
> also not really sensible to talk about "as good as" without defining
> your context. Over fast, local networks, IL is faster than TCP. It's
> not as
On Thu, 29 Apr 2010 13:23:00 EDT erik quanstrom wrote:
> > > 9p, like aoe, is a ping-pong protocol. each message requires an ack.
> > > therefore, the transport layer doesn't need flow control.
> >
> > Therefore, it is also not able to utilise bandwidth
> > effectively over longhaul links. As a
ron said:
Oh, and, it is likely that when we issue that many or more reads, we
want a flow controlled network. Just guessing :-)
You'd want one, sure. But (unless I'm missing something) it doesn't
seem that increasing the number of outstanding messages would
*require* it (your performance
> I agree that NAT and stateful firewalls (e.g. 'ip inspect' in IOS)
> would need explicit support to understand the packet layout.
what il services would you apply spi to? one doesn't
ftp or http over il.
> NAT - it should simply die, until then
> run IL over IPv6 and avoid NAT?
il isn't defi
On Thu, Apr 29, 2010 at 01:32:23PM -0700, Christopher Nielsen wrote:
> It doesn't play well with firewalls, NAT, or deep inspection because
> none of the vendors have added support for it. I tried to get Cisco to
> add IL support back in 2001, but they politely refused.
Add support to what? Also
On Thu, Apr 29, 2010 at 13:40, erik quanstrom wrote:
>> It doesn't play well with firewalls, NAT, or deep inspection because
>> none of the vendors have added support for it. I tried to get Cisco to
>> add IL support back in 2001, but they politely refused.
>
> oddly, i'm not having trouble going
> It doesn't play well with firewalls, NAT, or deep inspection because
> none of the vendors have added support for it. I tried to get Cisco to
> add IL support back in 2001, but they politely refused.
oddly, i'm not having trouble going through 5 different nats
over 2 residential and 2 business d
There are a few dsl's which require you to use their routers with NAT
and other stuff, but I've never tried these out, I've always had real
IP connections here...
As long as we have enough ipv4 adresses I would say: Build your own
firewall, router or NAT...
On 4/29/10, Christopher Nielsen wrote:
On Thu, Apr 29, 2010 at 12:44 PM, C H Forsyth wrote:
> >But then I start to wonder why we feel we want to compete with HTTP when
> it
> >already works, and is still fairly simple.
>
> http is by no means simple, although yes, it could be still more
> complicated.
>
>
I guess I think it's simple b
On Thu, Apr 29, 2010 at 08:06, Gabriel Díaz wrote:
> Hello
>
>
> how well it works with firewalls, address translation, "deep inspection",
> etc.? never tried il outside home. . .
It doesn't play well with firewalls, NAT, or deep inspection because
none of the vendors have added support for it.
> On Thu Apr 29 15:55:44 EDT 2010, 9...@9netics.com wrote:
> > fyi:
> > from rangboom.com network (colo at a ISP):
> >
> > cpu% telnet il!minooka.coraid.com!4000
> > connected to il!minooka.coraid.com!4000 on /net/il/3
> >
> > from 9netics.com (centurytel DSL): still waiting :)
>
> inter
On Thu Apr 29 15:55:44 EDT 2010, 9...@9netics.com wrote:
> fyi:
> from rangboom.com network (colo at a ISP):
>
> cpu% telnet il!minooka.coraid.com!4000
> connected to il!minooka.coraid.com!4000 on /net/il/3
>
> from 9netics.com (centurytel DSL): still waiting :)
interesting. i was a
>>But then I start to wonder why we feel we want to compete with HTTP when it
>>already works, and is still fairly simple.
>
> http is by no means simple, although yes, it could be still more complicated.
they'll stop when the spec is massive enough to undergo gravitation
collapse.
fyi:
from rangboom.com network (colo at a ISP):
cpu% telnet il!minooka.coraid.com!4000
connected to il!minooka.coraid.com!4000 on /net/il/3
from 9netics.com (centurytel DSL): still waiting :)
> On Thu Apr 29 14:53:56 EDT 2010, lyn...@orthanc.ca wrote:
>> > due to a failure of vis
> Hmmm is Op the same Op from Octopus?
yes. nemo has put the op specific stuff here:
/n/sources/contrib/nemo/octopus/op.src.tgz
>> due to a failure of vision, the internet only does
>> well with certain types of ip packets.
>
> Well now *there* is a sweeping statement about the state of the universe
> circa 1980. Care to elaborate a teensy bit?
i think the point is IL v. TCP; this is dejavu all over again:
http://group
>But then I start to wonder why we feel we want to compete with HTTP when it
>already works, and is still fairly simple.
http is by no means simple, although yes, it could be still more complicated.
ladd; time fcp /n/c/n/other/quanstro/plan9.tar.bz2 /dev/null
0.00u 0.06s 105620.50r fcp /n/c/n/other/quanstro/plan9.tar.bz2 /dev/null #
status= interrupt
- erik
On Thu Apr 29 14:53:56 EDT 2010, lyn...@orthanc.ca wrote:
> > due to a failure of vision, the internet only does
> > well with certain types of ip packets.
>
> Well now *there* is a sweeping statement about the state of the universe
> circa 1980. Care to elaborate a teensy bit?
if you pick a ran
due to a failure of vision, the internet only does
well with certain types of ip packets.
Well now *there* is a sweeping statement about the state of the universe
circa 1980. Care to elaborate a teensy bit?
Hmmm is Op the same Op from Octopus?
Just making sure.
Dave
On Thu, Apr 29, 2010 at 11:41 AM, Skip Tavakkolian <9...@9netics.com> wrote:
> i think in almost all cases putting Op between 9P endpoints will
> solve the slowness problem of high rtt networks.
>
> >> But then I start to wonder why we
i think in almost all cases putting Op between 9P endpoints will
solve the slowness problem of high rtt networks.
>> 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 wh
> >> 9P doesn't require any flow control? That doesn't seem right :-) But then
> >> again it doesn't stream, at least in the traditional way I think of
> >> streaming. To stream you typically need flow control, so 9P isn't good for
> >> streaming in the sense I think of streaming. (yet?)
> >> F
On Thu, Apr 29, 2010 at 10:48 AM, Tim Newsham wrote:
> 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
>
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
> Oh, and, it is likely that when we issue that many or more reads, we
> want a flow controlled network. Just guessing :-)
the downside of course is that the set of suitable protocols
is then greatly reduced. tftp, rudp, il, cec to name a few simple
protocols (yes i've done 9p over cec) would the
> > 9p, like aoe, is a ping-pong protocol. each message requires an ack.
> > therefore, the transport layer doesn't need flow control.
>
> Therefore, it is also not able to utilise bandwidth
> effectively over longhaul links. As an example, US coast
> to coast round trip time latency is about 100
On Thu, Apr 29, 2010 at 10:08 AM, Bakul Shah wrote:
> Short of a sliding window that is as large as the capacity of
> the pipe, you can't expect to keep it full. As usual one has
> to trade off simplicity vs performance.
>
> I do hope 9p evolves.
>
>
The problem revealed by fcp is worse than th
On Thu, 29 Apr 2010 11:34:44 EDT erik quanstrom wrote:
> > Wasn't IL somewhat abandoned because to make it as good as TCP you
> > basically had to implement TCP anyway?
>
> due to a failure of vision, the internet only does
> well with certain types of ip packets.
:-)
> il is still an excelle
> > 9p, like aoe, is a ping-pong protocol. each message requires an ack.
> > therefore, the transport layer doesn't need flow control.
> >
> Right, but when you have one T message for many R messages, doesn't that
> change things a bit?
yes. if you were to add that, then a flow-controlled transp
On Thu, Apr 29, 2010 at 8:34 AM, erik quanstrom wrote:
> > Wasn't IL somewhat abandoned because to make it as good as TCP you
> > basically had to implement TCP anyway?
>
> due to a failure of vision, the internet only does
> well with certain types of ip packets.
>
> il is still an excellent pro
> Wasn't IL somewhat abandoned because to make it as good as TCP you
> basically had to implement TCP anyway?
due to a failure of vision, the internet only does
well with certain types of ip packets.
il is still an excellent protocol for local networks.
> 9P doesn't require any flow control? T
On Thu, Apr 29, 2010 at 10:16 AM, ron minnich wrote:
> On Thu, Apr 29, 2010 at 8:03 AM, David Leimbach wrote:
>
>> 9P doesn't require any flow control? That doesn't seem right :-) But then
>> again it doesn't stream, at least in the traditional way I think of
>> streaming. To stream you typica
On Thu, Apr 29, 2010 at 8:06 AM, David Leimbach wrote:
> I'm totally undecided on this, but just asking the question to make sure
> everyone feels good about adding streaming to 9P, which seems to indicate a
> need to add flow control as well.
the problem of multiplexing several streams onto one
On Thu, Apr 29, 2010 at 5:40 AM, roger peppe wrote:
> 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?
there are not replies -- the rstream is a reply. If the consumer is
sl
On Thu, Apr 29, 2010 at 8:03 AM, David Leimbach wrote:
> 9P doesn't require any flow control? That doesn't seem right :-) But then
> again it doesn't stream, at least in the traditional way I think of
> streaming. To stream you typically need flow control, so 9P isn't good for
> streaming in t
Hello
how well it works with firewalls, address translation, "deep inspection", etc.?
never tried il outside home. . .
gabi
- Original Message
From: erik quanstrom
To: 9fans@9fans.net
Sent: Thu, April 29, 2010 4:43:48 PM
Subject: Re: [9fans] A simple experiment
> What does 9P requ
On Thu, Apr 29, 2010 at 7:35 AM, erik quanstrom wrote:
> > 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
> chang
On Thu, Apr 29, 2010 at 7:43 AM, erik quanstrom wrote:
> > What does 9P require to function? If TStream has the same or lesser
> > requirements, then there's no problem right? This comes back to my
> > wondering why we don't just use 9P to set up HTTP streams.
>
> see /sys/src/doc/il/il.ps
> - r
> What does 9P require to function? If TStream has the same or lesser
> requirements, then there's no problem right? This comes back to my
> wondering why we don't just use 9P to set up HTTP streams.
see /sys/src/doc/il/il.ps
- reliable,
- in order.
(the other three are not hard requirements)
i
On Thu, Apr 29, 2010 at 7:22 AM, erik quanstrom wrote:
> > 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?
>
> the tcp window closes. and the producer blocks.
>
> > in fa
> 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 pr
> 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?
the tcp window closes. and the producer blocks.
> in fact, how do you stop it deadlocking if the consumer is in
> fact wait
On Wed, Apr 28, 2010 at 3:51 PM, ron minnich wrote:
> On Wed, Apr 28, 2010 at 1:36 PM, Francisco J Ballesteros
> wrote:
>
>> That's similar to a Tget in op with unlimited replies. The difference adds on
>> quickly.
>
> neat, I need to study op more than I did :-)
>
For the record, I kept tellin
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
On Thu, Apr 29, 2010 at 7:17 AM, erik quanstrom wrote:
>> I added two lines of code to /sys/src/cmd/aux/vga/radeon.h; compiled
>> vga and kernel; added line to /lib/vgadb.
>> Now kernel sees the device (and I see it too: cat /dev/vgactl), but
>> attempt to start framebuffer gives blank screen. Poi
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 result
> I added two lines of code to /sys/src/cmd/aux/vga/radeon.h; compiled
> vga and kernel; added line to /lib/vgadb.
> Now kernel sees the device (and I see it too: cat /dev/vgactl), but
> attempt to start framebuffer gives blank screen. Pointers are
> appreciated!
it didn't work for me, either. i
On Apr 26, 4:23 pm, quans...@quanstro.net (erik quanstrom) wrote:
> /sys/src/cmd/aux/vga/radeon.c uses radeon_pciids in radeon.h.
> it ignores the vids and dids in /lib/vgadb. this is probablly a
> mistake.
>
> - erik
I added two lines of code to /sys/src/cmd/aux/vga/radeon.h; compiled
vga and k
50 matches
Mail list logo
