Re: [9fans] Do we have a catalog of 9P servers?

Re: [9fans] Do we have a catalog of 9P servers?

[Eris Discordia]

Thanks a lot, Nathaniel Filardo. Your clean and detailed explanation is
very much appreciated. Although, Micah Stetson did post a similar, albeit
far more concise, explanation before.

Despite the impression I seem to have made, I understand--as of a few days
ago, at least--why a Plan 9 gateway can be transparent and hassle-free. I
even pointed out on a previous post that comparable forms of transparency
are provided at different layers of the network by tunnelling protocols
such as L2TP and PPTP. I also explained why there's an oxymoronic quality
to the transparency provided in Plan 9, i.e. that network layer operations
are delegated to application layer. Many network devices, if implemented as
they ought to be, should operate at specific layers of the stack--a
full-blown network host should in principle be different from a router
which in turn should be different from a bridge. An application layer is a
luxury not always granted. Also, the delegation of a network layer
operation to higher layers has an undertone of blasphemy, of violating the
principles of layered design.

Anyhow, the issue is resolved. I believe we understand each other.

--------------------------------------------------------------------------------

Regarding two specific claims:

> ... you get the idea.  It does this with no special tools, no complex
> code, and a very minimal per-connection overhead (just the IC and G
> kernels and G's exportfs tracking a file descriptor).

I haven't seen--and even if I did I wouldn't understand--the source code
required for:

a. Plan 9's abstraction of a network into a filesystem or part of a
filesystem,
b. a UNIX-clone NAT implementation,

so I really can't comment on, or offhandedly accept the comments on, the
complexity of these codes.

On the other hand, the one unresolved issue on this thread was a factual
comparison of NAT overhead compared to the transport+application layer
overheads generated on a Plan 9 gateway. I remain rather convinced that NAT
overhead will be meaningfully smaller _if_ the implementation is sane. Why?
Because the problem solved is the same and as a rule of thumb the effort
required to solve a problem is distributed between the computer and the
programmer's mind. If the  programmer's mind does more effort to solve the
problem then the computer will be relieved of some of the effort required
to carry out the solution (I'm not taking into account "quantum leaps," by
the way, I doubt they actually exist). Apparently, NAT takes more
brainpower to implement. The other, probably more agreeable, reason for
NAT's lesser overhead is that it operates (mostly) at network layer while
things that go through a hypothetical Plan 9 gateway necessarily involve
transport and application layer interaction. Abstraction costs,
doubtlessly, but I am willing to concede that the cost may well prove
tolerable in view of the hassle of creating and deploying a more "concrete"
solution.

> There can, in fact, be multiple IP stacks on a Plan 9 box, bound to
> multiple Ethernet cards, as you claim.  (In fact, one can import another
> computer's ethernet cards and run snoopy, or build a network stack, using
> those instead.)  I don't think that's relevant to the example at hand,
> though, as should be clear from the above.

This was pointed out on another thread by Ron Minnich. I actually was
surprised by the fact that *BSDs are (normally) limited to one instance of
network stack. And I later used this same difference to justify the claim
that each /net imported from a Plan 9 gateway will necessarily require a
new copy of the gateway's protocol stack. This was rebuked and your
explanation makes it even more clear why.

Nevertheless, the same machinations that allow for transparency in Plan 9
disallow certain functions that can be naturally provided by a NAT
implementation, or any of a number of software categories that involve
packet filtering/rewriting/inspection. For example, the one I referred to
in the posting you have quoted in your response: load balancing. Add to the
list: rate control, intrusion detection, QoS earmarking, honeynetting, et
cetera ad [put you favorite -um, -am here].

--------------------------------------------------------------------------------

--On Tuesday, November 18, 2008 8:59 PM -0500 Nathaniel W Filardo
<nwf@cs.jhu.edu> wrote:

> On Sun, Nov 16, 2008 at 09:24:19PM +0000, Eris Discordia wrote:
>>> That isn't happening.  All we have is one TCP connection and one small
>>> program exporting file service.
>>
>> I see. But then, is it the "small program exporting file service" that
>> does the multiplexing? I mean, if two machines import a gateway's /net
>> and both run HTTP servers binding to and listening on *:80 what takes
>> care of which packet belongs to which HTTP server?
>
> I don't think you've quite got it yet.... also I swore I wouldn't post in
> this thread.  Oh well, here goes.
>
> First, let me draw a picture, just to introduce the characters:
>
> +----------+              +---------+
>| Internal |<--Ethernet-->| Gateway |<--Ethernet-->(Internet)
>| Computer |   ^          +---------+
> +----------+   |
>                |
> +----------+   |
>|  Other   |<--+
>| Internal |
>| Computer |
> +----------+
>
> OK.  Here, we have two internal computers (IC and OIC) and a gateway G.
> There are two Ethernet networks in flight, one connecting IC, OIC, and G,
> and the other connecting G to the internet at large, somehow (e.g. ADSL).
>
> IC and OIC both initialize somehow, say using DHCP from G, and bring their
> network stacks up using this information.  Their kernels now provide the
> services that will be mounted, by convention, at /net, again using this
> private information.  G initializes statically, bringing its IP stack up
> using two interfaces, with two routes: one for internal traffic, and one
> default route.
>
> So far, it's all very similar between Plan 9 and Linux.  Here's where
> our story diverges.
>
> In Linux, IC and OIC are both taught that they have default routes to the
> Internet At Large by sending IP datagrams to G's internal ethernet
> interface.  How this works in more detail, they don't care.  G will also
> send them corresponding IP datagrams from its interface; that's all they
> care about.  G works furiously to decode the network traffic bound for the
> internet and NA(P)T it out to its gateway, maintaining very detailed
> tables about TCP connections, UDP datagrams, etc, etc.  How could it be
> but any other way?
>
> Let's redraw the picture, as things stand now, under Plan 9, just so
> things are clear:
>
>                                                   (OIC similar to IC)
> +----Internal Computer--------------------+               |
>| bind '#I' /net                          |               |
>| # I : Kernel IP stack (192.168.1.2)      |               |
>| # l : Kernel ethernet driver             |<---Ethernet---+
> +-----------------------------------------+               |
>                                                           |
> +----Gateway------------------------------+               |
>| bind '#I' /net                          |               |
>| # I : Kernel IP stack (192.168.1.1)      |               |
>|                      (4.2.2.2)          |               |
>| # l : Kernel ethernet driver  (ether0)   |<---Ethernet---+
>|                              (ether1)   |<---Ethernet----->(Internet)
> +-----------------------------------------+
>
> In Plan 9, G behaves like any other machine, building a /net out of pieces
> exported by its kernel, including the bits that know how to reach the
> internet at large through the appropriate interface.  Good so far?
>
> Let's have G run an exportfs, exposing its /net on the internal IP
> address. This /net knows how to talk to the internal addresses and the
> external ones.
>
> Meanwhile, IC can reach out and import G's /net, binding it at /net.alt,
> let's say.  Now, programs can talk to the Internet by opening files in
> /net.alt.  These open requests will be carried by IC's mount driver, and
> then IC's network stack, to G, whereupon the exportfs (in G's userland)
> will forward them to its idea of /net (by open()ing, read()ing,
> write()ing, etc.), which is the one built on G's kernel, which knows how
> to reach the Internet.  Tada!  Picture time:
>
>                                                         (OIC)
> +----Internal Computer-------------------------+          |
>| abaco: open /net.alt/tcp/clone               |          |
>|                                              |          |
>| import tcp!192.168.1.1!9fs /net.alt (devmnt) |          |
>| bind '#I' /net                               |          |
>| # I : Kernel IP stack (192.168.1.2)           |          |
>| # l : Kernel ethernet driver                  |<---------+
> +----------------------------------------------+          |
>                                                           |
> +----Gateway------------------------------+               |
>| exportfs -a -r /net                     |               |
>|                                         |               |
>| bind '#I' /net                          |               |
>| # I : Kernel IP stack (192.168.1.1)      |               |
>|                      (4.2.2.2)          |               |
>| # l : Kernel ethernet driver  (ether0)   |<---Ethernet---+
>|                              (ether1)   |<---Ethernet----->(Internet)
> +-----------------------------------------+
>
> This works perfectly for making connections: IC's IP stack is aware only
> of devmnt requests, and G's IP stack is aware of some trafic to&from a
> normal process called exportfs, and that that process happens to be
> making network requests via #I bound at /net.
>
> The beauty of this design is just how well it works, everywhere, for
> everything you'd ever want.
>
> Now, suppose IC goes to listen on TCP:80, by opening /net.alt/tcp/clone.
> The same flow of events happen, and to a certain extent, G's network stack
> thinks that the exportfs program (running on G) is listening on TCP:80.
> exportfs dutifully copies the /net data back to its client.
>
> Naturally, if another program on G were already listening on TCP:80, or
> the same program (possibly exportfs) attempted to listen twice (if, say,
> OIC played the same game and also tried to listen on G's TCP:80), it
> would be told that the port was busy.  This error would be carried back
> along the exportfs path just as any other.
>
> So as you see, there is no need to take care of "which packet belongs to
> which server" since there can, of course, be only one server listening on
> TCP:80.  That server is running on G, and behaves like any other program.
> That it just so happens to be an exportfs program, relaying data to and
> from another computer, is immaterial.
>
> This also works for FTP, and UDP, and ESP (which are notorious problems in
> the NAT world), and for IL, and for IPv6, and for ethernet frames (!), and
> ... you get the idea.  It does this with no special tools, no complex
> code, and a very minimal per-connection overhead (just the IC and G
> kernels and G's exportfs tracking a file descriptor).
>
> There are no connection tracking tables anywhere in this design.  There
> are just normal IP requests over normal ethernet frames, and a few more
> TCP (or IL) connections transporting 9P data.
>
>> On a UNIX clone, or on Windows, because there is exactly one TCP/IP
>> protocol stack in usual setups no two programs can bind to the same port
>> at the same time. I thought Plan 9's approach eliminated that by keeping
>> a distinct instance of the stack for each imported /net.
>
> There can, in fact, be multiple IP stacks on a Plan 9 box, bound to
> multiple Ethernet cards, as you claim.  (In fact, one can import another
> computer's ethernet cards and run snoopy, or build a network stack, using
> those instead.)  I don't think that's relevant to the example at hand,
> though, as should be clear from the above.
>
> --nwf;

Re: [9fans] Do we have a catalog of 9P servers?

[Anant Narayanan]

> Nevertheless, the same machinations that allow for transparency in
> Plan 9 disallow certain functions that can be naturally provided by
> a NAT implementation, or any of a number of software categories that
> involve packet filtering/rewriting/inspection. For example, the one
> I referred to in the posting you have quoted in your response: load
> balancing. Add to the list: rate control, intrusion detection, QoS
> earmarking, honeynetting, et cetera ad [put you favorite -um, -am
> here].

I wouldn't go so far as to say Plan 9 "disallows" certain functions
that are implicit in NAT. As someone mentioned in the thread before,
it is certainly possible and rather easy to write something similar to
trampoline(8) to perform load balancing. Add in packet analysis to the
mix and you have rate control, intrusion detection etc.

Plan 9, in the end, is infinitely more malleable than most other
OSes :-)

--
Anant

Re: [9fans] Do we have a catalog of 9P servers?

[Eris Discordia]

> I wouldn't go so far as to say Plan 9 "disallows" certain functions that
> are implicit in NAT. As someone mentioned in the thread before, it is
> certainly possible and rather easy to write something similar to
> trampoline(8) to perform load balancing. Add in packet analysis to the
> mix and you have rate control, intrusion detection etc.

Perhaps my choice of wording wasn't exactly correct. Make it "does not
function in this capacity unless modified." But there's a missed point: add
in packet analysis and you're doing NAT. The boasted transparency of Plan 9
is a product of bringing most (or really all?) functions, including
networking, into a single framework. That single framework exists as an
application of networking, i.e. 9P, hence living in the application layer.
Descending to network layer is expulsion from the Plan 9 Eden.

I have come to believe it was in the wisdom of Plan 9's creators that
sooner or later the meaningless variations of network stacks up until
application layer will vanish and the entire standardized stack will
probably be implemented as fast and reliable hardware. In such a
world--which isn't very far actually--the programmer will have to do
everything they want done at the application layer so Plan 9's approach to
adding additional networking capability becomes natural and obvious; it
will become much harder to introduce ad hoc modifications of something as
essential as the network stack and call them features. You want an
_application_, you create an application, you don't mess with basics of
networking.

--On Wednesday, November 19, 2008 9:08 PM +0100 Anant Narayanan
<anant@kix.in> wrote:

>
>> Nevertheless, the same machinations that allow for transparency in
>> Plan 9 disallow certain functions that can be naturally provided by
>> a NAT implementation, or any of a number of software categories that
>> involve packet filtering/rewriting/inspection. For example, the one
>> I referred to in the posting you have quoted in your response: load
>> balancing. Add to the list: rate control, intrusion detection, QoS
>> earmarking, honeynetting, et cetera ad [put you favorite -um, -am
>> here].
>
> I wouldn't go so far as to say Plan 9 "disallows" certain functions that
> are implicit in NAT. As someone mentioned in the thread before, it is
> certainly possible and rather easy to write something similar to
> trampoline(8) to perform load balancing. Add in packet analysis to the
> mix and you have rate control, intrusion detection etc.
>
> Plan 9, in the end, is infinitely more malleable than most other OSes :-)
>
> --
> Anant
>
>

Re: [9fans] Do we have a catalog of 9P servers?

[blstuart]

> Perhaps my choice of wording wasn't exactly correct. Make it "does not
> function in this capacity unless modified." But there's a missed point: add
> in packet analysis and you're doing NAT. The boasted transparency of Plan 9
> is a product of bringing most (or really all?) functions, including
> networking, into a single framework. That single framework exists as an
> application of networking, i.e. 9P, hence living in the application layer.
> Descending to network layer is expulsion from the Plan 9 Eden.

I've tried to stay out of most of these, but I think this
might help you get a better feel for it.  First, don't
get too hung up on application vs. network layers.
The OSI protocols are  largely forgotten for a reason.
It's not bad as a conceptual model, but as soon as you
try to force any predefined definitions of layers on real
networks, you soon lose your grip on sanity.

So how to think about it?  First, it's *not* NAT,  because
there's no address translation going on.  So when importing
the router's /net, your messages are carried from your
machine to the router as part of 9P Twrite messages.  And
your responses come back with Rread messages coming
from the router to your machine.  Notice here that the
router doesn't get an IP datagram that it needs to pass
on.  Instead the router creates a TCP packet to carry the
message.  This is the fundamental difference.  The
encapsulation of the message in TCP/IP is done on the
gateway, obviating the need for any translation and
obviating the need for the router to care what is being
sent from your machine.

Using NAT, your machine does the encapsulating
of the message in TCP/IP and passes that packet to
the router.  Because the encapsulating IP datagram
carries the IP address of your machine,the router is
required to translate the address, hence the name,
NAT.  Because the router isn't transparent in the sense
that it doesn't pass what is sent from your machine
unchanged, protocols like ftp are a nightmare.  With
9P, there's no issue because what your machine sends
(only the ftp messages) are not changed or even looked
at by the router.

So bottom line: importing /net is not NAT in any
way.  It's so much cleaner than NAT and it falls out
for free from the structure of the system.  There's
not much better than getting functionality with no
additional code that is better in many ways than
the approaches that require special and kludgy
code.

BLS

Re: [9fans] Do we have a catalog of 9P servers?

[Eris Discordia]

> So how to think about it?  First, it's *not* NAT,  because
> there's no address translation going on.

I know. I understood this after the discussions of the past few days.

What I pointed out to Anant Narayanan was that his proposed _new_
capability which involved _packet analysis_ would _have to_ operate on
network layer data units, ergo, NAT again.

Packet analysis == Network layer operations ~= NAT

Because packet is the name for specific data units, entities at network
layer. Above it you have datagrams (UDP) or streams (TCP), below it you
have frames.

> The OSI protocols are  largely forgotten for a reason.
> It's not bad as a conceptual model, but as soon as you
> try to force any predefined definitions of layers on real
> networks, you soon lose your grip on sanity.

There are rather clearly-defined boundaries in TCP/IP, too. Without the
layered design approach one would lose one's sanity, not with it. Many an
"ugly" IP software is "ugly" because it, by mistake or by (mistaken)
design, mingles awareness from various layers into operations at one
layer--a violation of layered design.

--On Wednesday, November 19, 2008 11:55 PM -0500 blstuart@bellsouth.net
wrote:

>> Perhaps my choice of wording wasn't exactly correct. Make it "does not
>> function in this capacity unless modified." But there's a missed point:
>> add  in packet analysis and you're doing NAT. The boasted transparency
>> of Plan 9  is a product of bringing most (or really all?) functions,
>> including  networking, into a single framework. That single framework
>> exists as an  application of networking, i.e. 9P, hence living in the
>> application layer.  Descending to network layer is expulsion from the
>> Plan 9 Eden.
>
> I've tried to stay out of most of these, but I think this
> might help you get a better feel for it.  First, don't
> get too hung up on application vs. network layers.
> The OSI protocols are  largely forgotten for a reason.
> It's not bad as a conceptual model, but as soon as you
> try to force any predefined definitions of layers on real
> networks, you soon lose your grip on sanity.
>
> So how to think about it?  First, it's *not* NAT,  because
> there's no address translation going on.  So when importing
> the router's /net, your messages are carried from your
> machine to the router as part of 9P Twrite messages.  And
> your responses come back with Rread messages coming
> from the router to your machine.  Notice here that the
> router doesn't get an IP datagram that it needs to pass
> on.  Instead the router creates a TCP packet to carry the
> message.  This is the fundamental difference.  The
> encapsulation of the message in TCP/IP is done on the
> gateway, obviating the need for any translation and
> obviating the need for the router to care what is being
> sent from your machine.
>
> Using NAT, your machine does the encapsulating
> of the message in TCP/IP and passes that packet to
> the router.  Because the encapsulating IP datagram
> carries the IP address of your machine,the router is
> required to translate the address, hence the name,
> NAT.  Because the router isn't transparent in the sense
> that it doesn't pass what is sent from your machine
> unchanged, protocols like ftp are a nightmare.  With
> 9P, there's no issue because what your machine sends
> (only the ftp messages) are not changed or even looked
> at by the router.
>
> So bottom line: importing /net is not NAT in any
> way.  It's so much cleaner than NAT and it falls out
> for free from the structure of the system.  There's
> not much better than getting functionality with no
> additional code that is better in many ways than
> the approaches that require special and kludgy
> code.
>
> BLS
>
>

Re: [9fans] Do we have a catalog of 9P servers?

[Brian L. Stuart]

This is why I've been trying to stay out of it.

> > So how to think about it?  First, it's *not* NAT,  because
> > there's no address translation going on.
>
> I know. I understood this after the discussions of the past few days.

Yet you're still contending the following:

> What I pointed out to Anant Narayanan was that his proposed _new_
> capability which involved _packet analysis_ would _have to_ operate on
> network layer data units, ergo, NAT again.
>
> Packet analysis == Network layer operations ~= NAT

That's not correct.  NAT is network address translation.  It
implicitly requires that IP headers be rewritten, and when
doing port translation as well, the TCP header must also
be rewritten.  It is a technique that allows machines with
non-routable addresses to talk outside the local network.
Hence the need for translating addresses.  Importing /net
doesn't involve any translation of addresses.  In fact,
as Erik pointed out, the machine on the local network
might not even be talking TCP/IP at all!  The "packet
analysis" that appears to have arisen from a discussion
of load balancing is a red herring.  NAT is not a technique
for load balancing.  RFC1631 is where NAT is described.
If you're not rewriting the IP header, then it's not NAT,
it's not approximately NAT, it has no similarity to NAT
at all.

> Because packet is the name for specific data units, entities at network
> layer. Above it you have datagrams (UDP) or streams (TCP), below it you
> have frames.

It is true that I wasn't particularly pedantic with my
terms, but if we're going to be pedantic, we might as
well get it right.  RFC791 defines IP and the proper terminology
associated with it.  Comer does an excellent job distilling
the RFCs and phrases it this way: "The internet calls its
basic transfer unit an _Internet datagram_, sometimes referred
to as an _IP datagram_ or merely a _datagram_."  You can find
the definition of UDP in RFC768.  Again Comer's phrasing:
"Each UDP message is called a _user datagram_."  Finally,
read RFC793 for the details on TCP.  Comer's phrasing
is "The unit of transfer between the TCP software on two
machines is called a _segment_."  Comer's definition of
a packet is also instructive:

"The unit of data sent across a packet switching network.
The term is used loosely.  While some TCP/IP literature
uses it to refer specifically to data sent across a
physical network, other literature views an entire TCP/IP
internet as a packet switching network and describes IP
datagrams as packets."

(BTW the reason I've chosen to use Comer's phrasing is that
his book arose as a result of an IETF meeting where even
some of the attendees didn't understand how it all worked--at
least that's the story I heard when I was at Purdue.)

> > The OSI protocols are  largely forgotten for a reason.
> > It's not bad as a conceptual model, but as soon as you
> > try to force any predefined definitions of layers on real
> > networks, you soon lose your grip on sanity.
>
> There are rather clearly-defined boundaries in TCP/IP, too. Without the
> layered design approach one would lose one's sanity, not with it.

Of course TCP/IP has layers.  Indeed layering can be seen
in most good designs.  It is especially natural in network
stacks because of the encapsulation of messages.  For that
matter, I doubt any student of mine has ever gotten away
without hearing me say something about the value of layering;
I even mentioned it in my book.

And it's true that we sometimes are a bit loose with the
terms and allow ourselves to use OSI terminology when
talking about TCP/IP.  However, you can't take that usage
too literally, and certainly can't base an argument on
that usage.  The layers in the two just don't line up
exactly.  The division of responsibilities among the layers
is different between TCP/IP and OSI.  For that matter,
they don't even have the same number of layers.

The luxury I have in this situation is that because you're
not my student, I don't have any obligation to make sure
you've understood it all.  But if you were my student, my
first recommendation would be to read *and understand*
the RFCs, and the best way to know that you've understood
them is to write some network protocol code.  If you would
like to have help understanding something, I, and I'm sure
others here, would be happy to answer if you present your
questions as questions.  I don't plan to answer any more
incorrect assertions.

BLS

Re: [9fans] Do we have a catalog of 9P servers?

[akumar]

While debunking these statements has been somewhat efficient thus far,
I think something has not been explicitly addressed --
> The boasted transparency of Plan 9 is a product of bringing most
> (or really all?) functions, including networking, into a single
> framework.  That single framework exists as an application of
> networking, i.e.  9P, hence living in the application
> layer. Descending to network layer is expulsion from the Plan 9 Eden.

This seems to be the premise of the _current_ discussion.  And the
problem here is that `networking', which ought to apply here as a name
for two distinct ideas, is confused as a name for the same thing.
That is, the concept of 9P and filesystesms thereof, is an idea of
`networking' in a very general sense -- whereas, the "networking"
provided by /net, is an application of 9P, and completely distinct
from the 9P concept!  Now, to say, essentially, that "9P is networking
whose application, /net, is itself networking, and so to fondle with
this application is to fondle with the fundamentals of Plan 9, which
is contradictory to Plan 9 methodology", is absurd (I hope I've
properly paraphrased your statement above)!

The /net FS is directly an application of 9P, and to add further
functionality, such as packet analysis (which seems to be the new hot
topic now), is only to go so far as to change the /net "application"
-- if, for example, an application on top of /net cannot be made to
handle this task -- and this is not, in any sense, fundamentally
conradictory to the (abstraction) layer at which one ought to work, in
Plan 9 (since, again, we're just working atop 9P).
Your further points -- aside from the misconception of NAT and packet
analysis and what not -- seem to be fueled by this intuition, so
hopefully this clears something up (or at least gives you new material
to "debate").


Regards

Re: [9fans] Do we have a catalog of 9P servers?

[erik quanstrom]

> The /net FS is directly an application of 9P, and to add further
> functionality, such as packet analysis (which seems to be the new hot
> topic now), is only to go so far as to change the /net "application"

this is nitpicking, i apologize....

but /net is not a fs.  '#I' the ip stack and '#l' the ethernet device
are usually bound in union on /net.  ip subsumes its subprotocols and
arp.  there is nothing preventing one from adding a new networking
protocol nor is there anything preventing one from adding a new type
of networking device.  for example, one could run ip over atm
networking with no problems.  i think this sort of thing is done with
blue gene.  you could also run (say) xns over ethernet and have it all
appear like a big, happy family in /net.

- erik

Re: [9fans] Do we have a catalog of 9P servers?

[Brian L. Stuart]

> but /net is not a fs.  '#I' the ip stack and '#l' the ethernet device
> are usually bound in union on /net.  ip subsumes its subprotocols and
> arp.  there is nothing preventing one from adding a new networking
> protocol nor is there anything preventing one from adding a new type
> of networking device.  for example, one could run ip over atm
> networking with no problems.  i think this sort of thing is done with
> blue gene.  you could also run (say) xns over ethernet and have it all
> appear like a big, happy family in /net.

Oooh, oooh, the gauntlet has been thrown down.  Who will
pick up the challenge of finding a way to implement
RFC1149 (or 2549, if you want QoS) and binding it to
/net?  /net/speckled_jim0?  (That's a reference to
Blackadder for those who aren't fans of British comedy
and in particular Rowan Atkinson (who, slightly apropos
to our community, holds a degree in electrical engineering).)
Bonus points if you can figure out how to get paid for
it or get it funded by DARPA.

And no, I haven't been drinking save for the Cherry
Coke I'm finishing off after lunch.

BLS

Re: [9fans] Do we have a catalog of 9P servers?

[Eris Discordia]

> wrong.  binary would be the opposite of text.

Now I'm becoming convinced you are trying to infuriate me. That "9P is
actually binary" is a _fact_, which you presented to me, thank you, okay?
But, the _idea_, which existed in the posting you had quoted, remained and
remains the same nonetheless. The idea in question is not the fact you
mentioned, neither vice versa.

> thus, if you're following along, your statement did not inform.

I believe I explained in what way it _did_ inform _a lot_. Are you
asserting there's something wrong with the explanation? Did you read the
explanation at all?

--On Thursday, November 20, 2008 7:42 PM -0500 erik quanstrom
<quanstro@quanstro.net> wrote:

> On Thu Nov 20 19:21:51 EST 2008, eris.discordia@gmail.com wrote:
>> this correction: 9P is _not_ all text, but it consists of a well-defined
>> set of messages. The idea, anyway, is the same.
>
> wrong.  binary would be the opposite of text.
>
>>
>> >> That's wrong (or maybe I'm wrong). Whatever "network glue" /net uses
>> >> to get  the host represented on the network lies _entirely_ outside
>> >> of 9P's domain.
>> >
>> > this is a tautology; 9p does not define semantics.  equivalently,
>> > everything telnet does is outside of the domain of tcp/ip.  or, the
>> > vehicle i use to get to work has no bearing on what i do at work.
>>
>> In what way is an informative statement a tautology?
>
> thus, if you're following along, your statement did not inform.
>
> - erik
>

Re: [9fans] Do we have a catalog of 9P servers?

[erik quanstrom]

On Thu Nov 20 19:21:51 EST 2008, eris.discordia@gmail.com wrote:
> this correction: 9P is _not_ all text, but it consists of a well-defined
> set of messages. The idea, anyway, is the same.

wrong.  binary would be the opposite of text.

>
> >> That's wrong (or maybe I'm wrong). Whatever "network glue" /net uses to
> >> get  the host represented on the network lies _entirely_ outside of 9P's
> >> domain.
> >
> > this is a tautology; 9p does not define semantics.  equivalently,
> > everything telnet does is outside of the domain of tcp/ip.  or, the
> > vehicle i use to get to work has no bearing on what i do at work.
>
> In what way is an informative statement a tautology?

thus, if you're following along, your statement did not inform.

- erik

Re: [9fans] Do we have a catalog of 9P servers?

[Eris Discordia]

>> "hey, 9P is all text [...]
>
> wrong.

Upon reading this:

> Each message consists of a sequence of bytes. Two–, four–, and
> eight–byte fields hold unsigned integers represented in little–endian
> order (least significant byte first). Data items of larger or variable
> lengths are represented by a two–byte field specifying a count, n,
> followed by n bytes of data.

-- 0intro(5)

I see that you are correct (how could you not be?). I apologize and supply 
this correction: 9P is _not_ all text, but it consists of a well-defined 
set of messages. The idea, anyway, is the same.

--------------------------------------------------------------------------------

>> That's wrong (or maybe I'm wrong). Whatever "network glue" /net uses to
>> get  the host represented on the network lies _entirely_ outside of 9P's
>> domain.
>
> this is a tautology; 9p does not define semantics.  equivalently,
> everything telnet does is outside of the domain of tcp/ip.  or, the
> vehicle i use to get to work has no bearing on what i do at work.

In what way is an informative statement a tautology? Specifically 
"everything telnet does is outside of the domain of tcp/ip" which you have 
used in comparison is very much informative indeed and not a tautology. The 
meaning it conveys is something akin to "since things telnet does is 
outside the domain of TCP/IP one can say, a. telnet can exist independent 
of TCP/IP, and b. TCP/IP can't possibly be relying on telnet to work." 
Likewise my remark conveys a meaning akin to "since things /net does lie 
outside the domain of 9P one can say, a. 9P can exist independent of /net 
(and it probably does, I guess your Plan 9 kernel uses it to talk to local 
file servers, or do you always need a loopback for that purpose?), and b. 
/net can't possibly be relying on 9P to work."

SUMMARY: /net is an interface to which programs talk in 9P but which does 
not talk 9P to the layers beneath it because the layers beneath don't 
_understand_ 9P. They are implementations of transport protocol X which is 
an existence unrelated to 9P.

--------------------------------------------------------------------------------

>> Erik Quanstrom has put this in 9speak in his response to your posting.
>> Please check it out.
>>
>> --On Thursday, November 20, 2008 10:30 AM -0800
>> akumar@sounine.nanosouffle.net wrote:
>> [...]
>
> i wrote none of the quoted material.

That's not "quoted material." It's the posting I was replying to, naturally 
occurring after my reply. I suggested that akumar read what you had posted 
before this one.

--On Thursday, November 20, 2008 5:42 PM -0500 erik quanstrom 
<quanstro@quanstro.net> wrote:

>> "hey, 9P is all text [...]
>
> wrong.
>
>> That's wrong (or maybe I'm wrong). Whatever "network glue" /net uses to
>> get  the host represented on the network lies _entirely_ outside of 9P's
>> domain.
>
> this is a tautology; 9p does not define semantics.  equivalently,
> everything telnet does is outside of the domain of tcp/ip.  or, the
> vehicle i use to get to work has no bearing on what i do at work.
>
>> Erik Quanstrom has put this in 9speak in his response to your posting.
>> Please check it out.
>>
>> --On Thursday, November 20, 2008 10:30 AM -0800
>> akumar@sounine.nanosouffle.net wrote:
>> [...]
>
> i wrote none of the quoted material.
>
> - erik
>
>

Re: [9fans] Do we have a catalog of 9P servers?

[Roman V. Shaposhnik]

On Thu, 2008-11-20 at 07:08 -0500, Dan Cross wrote:
> >   term% cat /n/unix-fs-symlinks/home/glenda/mama
> >   /
> >   # Best of all -- it all works as expected
> >   term% cd /n/unix-fs/home/glenda/mama
> >   term% ls
> >   bin   cdrom  etc   initrd      initrd.img.old  lib32  lost+found  mnt
> >  proc  sbin  sys  usr  vmlinuz
> >   boot  dev    home  initrd.img  lib             lib64  media       opt
> >  root  srv   tmp  var  vmlinuz.old
>
> There's certainly an esthetic niceness to that for symlinks and the
> rest of the weird POSIX gunk;

Thank you for saying that.

> I don't know how well it might work for something like locks,

Well, nobody yet offered any arguments for why it shouldn't.

> I guess the two considerations there are overall system consistency
> and how much one wants to try and make something weird "fit in" with
> the rest of the system.

I got a feeling that Eric was implying that this approach would somehow
be more difficult for building the servers. I also got an impression
that he was suggesting implementing one in order to feel the difference.

Sadly, I can't really commit to doing that just yet.

Thanks,
Roman.

Re: [9fans] Do we have a catalog of 9P servers?

[erik quanstrom]

> "hey, 9P is all text [...]

wrong.

> That's wrong (or maybe I'm wrong). Whatever "network glue" /net uses to get
> the host represented on the network lies _entirely_ outside of 9P's domain.

this is a tautology; 9p does not define semantics.  equivalently, everything telnet
does is outside of the domain of tcp/ip.  or, the vehicle i use to get to work has
no bearing on what i do at work.

> Erik Quanstrom has put this in 9speak in his response to your posting.
> Please check it out.
>
> --On Thursday, November 20, 2008 10:30 AM -0800
> akumar@sounine.nanosouffle.net wrote:
> [...]

i wrote none of the quoted material.

- erik

Re: [9fans] Do we have a catalog of 9P servers?

[Eris Discordia]

> That is, the concept of 9P and filesystesms thereof, is an idea of
> `networking' in a very general sense

In what very general sense? File servers and 9P seem to me to be mostly
ideas about abstracting a computing platform's functionality, aka
resources--I'm thinking udev or Windows HAL.

The networking part only gains significance when one thinks, "hey, 9P is
all text, and it's atomized, and it relies on no magical awareness, and it
looks just like the interactions in a client-server model." Then one
decides to put 9P in a, say, TCP connection and create a
network-transparent environment augmented by 9P in two ways:

1. by making all applications use a consistent method of accessing resources

2. by providing a network-friendly manner of doing (1)

Of course, the actual design of 9P must have taken place in the opposite
direction. That is, (1) and (2) required the creation of 9P in the first
place.

--------------------------------------------------------------------------------

> whereas, the "networking" provided by /net, is an application of 9P, and
> completely distinct from the 9P concept!

True, but how does that negate the paragraph you have quoted?

Do read the last section of this email to see in what sense I am agreeing
with you and in what sense I am not.

--------------------------------------------------------------------------------

> from the 9P concept!  Now, to say, essentially, that "9P is networking
> whose application, /net, is itself networking, and so to fondle with
> this application is to fondle with the fundamentals of Plan 9, which
> is contradictory to Plan 9 methodology", is absurd (I hope I've
> properly paraphrased your statement above)!

You have wrongly paraphrased me, and it is rather obvious why.

Statement 1: 9P in the capacity of providing network transparency is an
application of networking. (strictly true)

Statement 2: Applications of networking, i.e. things other than "network
glue," ought to occur at application layer. (strictly true)

Statement 3: Statement 1 + Statement 2 + rules of inference = 9P must live
in application layer (and it does).

(Before you hit back, these assume networking, or rather internetworking,
means packet-switched networking as it is prevalent on this planet at this
time).

--------------------------------------------------------------------------------

> The /net FS is directly an application of 9P, and to add further
> functionality, such as packet analysis (which seems to be the new hot
> topic now), is only to go so far as to change the /net "application"

That's wrong (or maybe I'm wrong). Whatever "network glue" /net uses to get
the host represented on the network lies _entirely_ outside of 9P's domain.
It is conceivable that in an ideal world everything in /net, below the
application layer 9P, is moved to and works just fine on any other platform
with a C compiler. Is that an application of 9P _without_ 9P?

Perhaps it will serve educational purposes to point out that _you_ have
created a perfect vicious circle common with some 9fans. I have said this
before and I say it again: abstraction doesn't do work for you. If /net
talks 9P to layers of abstraction _beneath_ it, and 9P is the language your
programs use to talk to /net, then who does the modest work of fetching the
frames from your NIC, putting them in order, sprinkling your messages with
network layer awareness, "the real thing," and all? Note that these are
_not_ 9P-talk.

Erik Quanstrom has put this in 9speak in his response to your posting.
Please check it out.

--On Thursday, November 20, 2008 10:30 AM -0800
akumar@sounine.nanosouffle.net wrote:

>
> While debunking these statements has been somewhat efficient thus far,
> I think something has not been explicitly addressed --
>> The boasted transparency of Plan 9 is a product of bringing most
>> (or really all?) functions, including networking, into a single
>> framework.  That single framework exists as an application of
>> networking, i.e.  9P, hence living in the application
>> layer. Descending to network layer is expulsion from the Plan 9 Eden.
>
> This seems to be the premise of the _current_ discussion.  And the
> problem here is that `networking', which ought to apply here as a name
> for two distinct ideas, is confused as a name for the same thing.
> That is, the concept of 9P and filesystesms thereof, is an idea of
> `networking' in a very general sense -- whereas, the "networking"
> provided by /net, is an application of 9P, and completely distinct
> from the 9P concept!  Now, to say, essentially, that "9P is networking
> whose application, /net, is itself networking, and so to fondle with
> this application is to fondle with the fundamentals of Plan 9, which
> is contradictory to Plan 9 methodology", is absurd (I hope I've
> properly paraphrased your statement above)!
>
> The /net FS is directly an application of 9P, and to add further
> functionality, such as packet analysis (which seems to be the new hot
> topic now), is only to go so far as to change the /net "application"
> -- if, for example, an application on top of /net cannot be made to
> handle this task -- and this is not, in any sense, fundamentally
> conradictory to the (abstraction) layer at which one ought to work, in
> Plan 9 (since, again, we're just working atop 9P).
> Your further points -- aside from the misconception of NAT and packet
> analysis and what not -- seem to be fueled by this intuition, so
> hopefully this clears something up (or at least gives you new material
> to "debate").
>
>
> Regards
>
>

Re: [9fans] Do we have a catalog of 9P servers?

[Eris Discordia]

> Yet you're still contending the following:
>
>> What I pointed out to Anant Narayanan was that his proposed _new_
>> capability which involved _packet analysis_ would _have to_ operate on
>> network layer data units, ergo, NAT again.
>>
>> Packet analysis == Network layer operations ~= NAT
>
> That's not correct.  NAT is network address translation.  It
> implicitly requires that IP headers be rewritten, and when
> doing port translation as well, the TCP header must also
> be rewritten.  It is a technique that allows machines with
> non-routable addresses to talk outside the local network.
> Hence the need for translating addresses.  Importing /net
> doesn't involve any translation of addresses.  In fact,
> as Erik pointed out, the machine on the local network
> might not even be talking TCP/IP at all!  The "packet
> analysis" that appears to have arisen from a discussion
> of load balancing is a red herring.  NAT is not a technique
> for load balancing.  RFC1631 is where NAT is described.
> If you're not rewriting the IP header, then it's not NAT,
> it's not approximately NAT, it has no similarity to NAT
> at all.

1. Thanks for helping me revise previous learning.

2. I read RFC 1631 for the sole purpose of supporting a few assertions I
made on this thread. I also did reference it on this same thread. Why not
read previous postings before acting as if your intended audience
understood nothing?

3. You are (deliberately?) taking this out of context. I said, and continue
to say, that NAT and a number of other applications, nearly all implemented
in the Linux netfilter and *BSD ipfw/pf/dummynet/natd, depend on operating
on network layer entities, i.e. packets. And that it would be a violation
of layered design to handle this task at application layer.

4. There are no red herrings here. It's a change of course and I didn't
initiate it. Anant Narayanan pointed out that Plan 9's native application
layer protocol, 9P, did not forbid implementing whatever network layer
hijinks one felt like. I responded by merely saying that would be exactly
the sort of "ugly" software Plan 9 wants to avoid. To summarize: Plan 9's
network-transparent environment, or _any_ network-transparent for that
matter, relies on assuming a measure of homogeneity in the network. IP was
conceived with exactly the opposite premise, hence the name
_inter_networking/_inter_net. So when it comes to adding a feature of IP,
e.g. NAT, to Plan 9 there will be no shortage of trouble. There's all the
trouble operating system X has to go through, and then some. Of course,
there may be nearly-solutions to the problem that preserve the original
foundation the network-transparent environment was built upon but it will
never be quite the same. One of Murphy's "bylaws" forbids for a specific
functionality to become available without less than a specific amount of
toil, pre-determined by the problem at hand.

5. You do understand the difference between ~= and ==, don't you? At least,
you have to suspect there _must_ be a difference. NAT relies totally on
packet "analysis," i.e. analyzing of packets (== network layer data units),
which is why it is nearly equivalent but not necessarily equal to packet
analysis. This is a strictly true statement.

--------------------------------------------------------------------------------

> It is true that I wasn't particularly pedantic with my
> terms, but if we're going to be pedantic, we might as
> well get it right.  [...]

1. Thanks again. The definitions do help a lot.

2. But you are so obviously sidestepping the meaning of the paragraph you
have quoted. In particular, you have quoted is aside from the paragraph
above with reference to which my comment could be qualified. The remark on
the meaning of packets was _certainly_ not pedantry on my part--it amounted
to turning your attention to a certain fact; namely, that "packet analysis"
is network layer hijinks.

--------------------------------------------------------------------------------

> Of course TCP/IP has layers.  Indeed layering can be seen
> in most good designs.  It is especially natural in network
> stacks because of the encapsulation of messages.  For that
> matter, I doubt any student of mine has ever gotten away
> without hearing me say something about the value of layering;
> I even mentioned it in my book.

So what? It wasn't I who wrote:

> The OSI protocols are  largely forgotten for a reason.
> It's not bad as a conceptual model, but as soon as you
> try to force any predefined definitions of layers on real
> networks, you soon lose your grip on sanity.

My comment wasn't at all about forcing any predefined definitions on
TCP/IP. It was about the reality of TCP/IP, in which "packets" are mainly
network layer entities no matter what other significations a "packet" may
have to the academically inclined. It was also about that most good IP
software pays attention to a certain de facto layering, which I referred to
as "rather clearly-defined boundaries." A perfectly fine name.

--------------------------------------------------------------------------------

> And it's true that we sometimes are a bit loose with the
> terms and allow ourselves to use OSI terminology when
> talking about TCP/IP.  However, you can't take that usage
> too literally, and certainly can't base an argument on
> that usage.  The layers in the two just don't line up
> exactly.  The division of responsibilities among the layers
> is different between TCP/IP and OSI.  For that matter,
> they don't even have the same number of layers.

I happen to know that. I also happen to have read Andrew Tanenbaum's
"Computer Networks"--and always have a copy nearby for reference--which is
the usual canon all over the planet for non-CS/CE majors, enthusiasts, and
the like (your book isn't). That book happens to feature a pedagogic
instrument dubbed the "hyprid reference model" which is used _not only_ to
introduce _both_ OSI and TCP/IP to new learners but also to teach them good
design by enlightening them as to what in general is expected from each
layer--and why, under current circumstances, it is more or less good to
have like 5 layers with such-and-such functions and neither 2 nor 10.

--------------------------------------------------------------------------------

> The luxury I have in this situation is that because you're
> not my student, I don't have any obligation to make sure
> you've understood it all.  But if you were my student, my
> first recommendation would be to read *and understand*
> the RFCs, and the best way to know that you've understood
> them is to write some network protocol code.  If you would
> like to have help understanding something, I, and I'm sure
> others here, would be happy to answer if you present your
> questions as questions.  I don't plan to answer any more
> incorrect assertions.

I was about to use seriously foul language in response to this but then I
thought to myself, "why bother." Heed this, Mr. Professor: you _always_
have the luxury of keeping silent, but when you do speak please reserve the
right for your audience to respond, even if you deem them dim. It's pretty
philosophical, nah?

Also, thank you for the offering of help. I may rage quite often but I
appreciate, value, and always remember any helpful act on part of others.

--On Thursday, November 20, 2008 5:34 PM +0000 "Brian L. Stuart"
<blstuart@bellsouth.net> wrote:

> This is why I've been trying to stay out of it.
>
>> > So how to think about it?  First, it's *not* NAT,  because
>> > there's no address translation going on.
>>
>> I know. I understood this after the discussions of the past few days.
>
> Yet you're still contending the following:
>
>> What I pointed out to Anant Narayanan was that his proposed _new_
>> capability which involved _packet analysis_ would _have to_ operate on
>> network layer data units, ergo, NAT again.
>>
>> Packet analysis == Network layer operations ~= NAT
>
> That's not correct.  NAT is network address translation.  It
> implicitly requires that IP headers be rewritten, and when
> doing port translation as well, the TCP header must also
> be rewritten.  It is a technique that allows machines with
> non-routable addresses to talk outside the local network.
> Hence the need for translating addresses.  Importing /net
> doesn't involve any translation of addresses.  In fact,
> as Erik pointed out, the machine on the local network
> might not even be talking TCP/IP at all!  The "packet
> analysis" that appears to have arisen from a discussion
> of load balancing is a red herring.  NAT is not a technique
> for load balancing.  RFC1631 is where NAT is described.
> If you're not rewriting the IP header, then it's not NAT,
> it's not approximately NAT, it has no similarity to NAT
> at all.
>
>> Because packet is the name for specific data units, entities at network
>> layer. Above it you have datagrams (UDP) or streams (TCP), below it you
>> have frames.
>
> It is true that I wasn't particularly pedantic with my
> terms, but if we're going to be pedantic, we might as
> well get it right.  RFC791 defines IP and the proper terminology
> associated with it.  Comer does an excellent job distilling
> the RFCs and phrases it this way: "The internet calls its
> basic transfer unit an _Internet datagram_, sometimes referred
> to as an _IP datagram_ or merely a _datagram_."  You can find
> the definition of UDP in RFC768.  Again Comer's phrasing:
> "Each UDP message is called a _user datagram_."  Finally,
> read RFC793 for the details on TCP.  Comer's phrasing
> is "The unit of transfer between the TCP software on two
> machines is called a _segment_."  Comer's definition of
> a packet is also instructive:
>
> "The unit of data sent across a packet switching network.
> The term is used loosely.  While some TCP/IP literature
> uses it to refer specifically to data sent across a
> physical network, other literature views an entire TCP/IP
> internet as a packet switching network and describes IP
> datagrams as packets."
>
> (BTW the reason I've chosen to use Comer's phrasing is that
> his book arose as a result of an IETF meeting where even
> some of the attendees didn't understand how it all worked--at
> least that's the story I heard when I was at Purdue.)
>
>> > The OSI protocols are  largely forgotten for a reason.
>> > It's not bad as a conceptual model, but as soon as you
>> > try to force any predefined definitions of layers on real
>> > networks, you soon lose your grip on sanity.
>>
>> There are rather clearly-defined boundaries in TCP/IP, too. Without the
>> layered design approach one would lose one's sanity, not with it.
>
> Of course TCP/IP has layers.  Indeed layering can be seen
> in most good designs.  It is especially natural in network
> stacks because of the encapsulation of messages.  For that
> matter, I doubt any student of mine has ever gotten away
> without hearing me say something about the value of layering;
> I even mentioned it in my book.
>
> And it's true that we sometimes are a bit loose with the
> terms and allow ourselves to use OSI terminology when
> talking about TCP/IP.  However, you can't take that usage
> too literally, and certainly can't base an argument on
> that usage.  The layers in the two just don't line up
> exactly.  The division of responsibilities among the layers
> is different between TCP/IP and OSI.  For that matter,
> they don't even have the same number of layers.
>
> The luxury I have in this situation is that because you're
> not my student, I don't have any obligation to make sure
> you've understood it all.  But if you were my student, my
> first recommendation would be to read *and understand*
> the RFCs, and the best way to know that you've understood
> them is to write some network protocol code.  If you would
> like to have help understanding something, I, and I'm sure
> others here, would be happy to answer if you present your
> questions as questions.  I don't plan to answer any more
> incorrect assertions.
>
> BLS
>
>

Re: [9fans] Do we have a catalog of 9P servers?

[Dan Cross]

On Fri, Nov 14, 2008 at 12:52 AM, Roman Shaposhnik <rvs@sun.com> wrote:
> On Nov 13, 2008, at 8:37 AM, Dan Cross wrote:
>>
>> [...]
>
> But along the very same line of thought -- wouldn't it also then be
> much more reasonable to stick with an "alternative aname"
> approach when adopting 9P for symlinks, FIFOs and the
> rest of the POSIX paraphernalia?
>
> You pay with a slightly more complicated server, but you
> reap a huge benefit in a form of:
>
>   term% srvssh unix unix-fs
>   term% mount /srv/unix-fs /n/unix-fs
>   term% mount /srv/unix-fs /n/unix-fs-symlinks posix-symlinks
>   # Look ma, I'm creating a symbolic link from a Plan9 terminal
>   # I'll name it after you and it'll point to the root
>   term% echo / > /n/unix-fs-symlinks/home/glenda/mama
>   # And I can even do readlink()
>   term% cat /n/unix-fs-symlinks/home/glenda/mama
>   /
>   # Best of all -- it all works as expected
>   term% cd /n/unix-fs/home/glenda/mama
>   term% ls
>   bin   cdrom  etc   initrd      initrd.img.old  lib32  lost+found  mnt
>  proc  sbin  sys  usr  vmlinuz
>   boot  dev    home  initrd.img  lib             lib64  media       opt
>  root  srv   tmp  var  vmlinuz.old

There's certainly an esthetic niceness to that for symlinks and the
rest of the weird POSIX gunk; I don't know how well it might work for
something like locks, but maybe I'm just blinded by too many years
drinking at the Unixbar and not seeing beyond my own conceptual
roadblocks.  It does strike me that a similar approach may be more
elegant for getting weird types of metadata in and out of some funky
filesystem than overloading a directory type in stat and wstat (which
itself could be a slippery slope).  I guess the two considerations
there are overall system consistency and how much one wants to try and
make something weird "fit in" with the rest of the system.

        - Dan C.

Re: [9fans] Do we have a catalog of 9P servers?

[erik quanstrom]

> Now, suppose IC goes to listen on TCP:80, by opening /net.alt/tcp/clone.
> The same flow of events happen, and to a certain extent, G's network stack
> thinks that the exportfs program (running on G) is listening on TCP:80.
> exportfs dutifully copies the /net data back to its client.

great post.

small point:
it turns out that running httpd, or any proc that becomes none,
doesn't work because the importee won't let none run exportfs.

also, i wanted to point out another scheme for dealing with the
external interface.  what i typically do is keep the external network
on /net.alt and the internal network on /net on all machines.
for example

term; ipifc
0:/net/ether0 	001b21028754	1514
	192.168.0.57/120	192.168.0.0
term; cpu -c ipifc
0:/net/ether0 	001b2102873b	1514
	192.168.0.136/120	192.168.0.0
0:/net.alt/ether1 	001d92350045	1514
	192.168.10.1/120	192.168.10.0

so if i "import $cpu /net.alt /net.alt" from the terminal,
the networking appears the same on the terminal and cpu server.

- erik

Re: [9fans] Do we have a catalog of 9P servers?

[Nathaniel W Filardo]

[-- Attachment #1: Type: text/plain, Size: 7631 bytes --]

On Sun, Nov 16, 2008 at 09:24:19PM +0000, Eris Discordia wrote:
>> That isn't happening.  All we have is one TCP connection and one small
>> program exporting file service.
>
> I see. But then, is it the "small program exporting file service" that 
> does the multiplexing? I mean, if two machines import a gateway's /net 
> and both run HTTP servers binding to and listening on *:80 what takes 
> care of which packet belongs to which HTTP server?

I don't think you've quite got it yet.... also I swore I wouldn't post in
this thread.  Oh well, here goes.

First, let me draw a picture, just to introduce the characters:

+----------+              +---------+              
| Internal |<--Ethernet-->| Gateway |<--Ethernet-->(Internet)
| Computer |   ^          +---------+              
+----------+   |
               |
+----------+   |
|  Other   |<--+
| Internal |
| Computer |
+----------+

OK.  Here, we have two internal computers (IC and OIC) and a gateway G.
There are two Ethernet networks in flight, one connecting IC, OIC, and G,
and the other connecting G to the internet at large, somehow (e.g. ADSL).

IC and OIC both initialize somehow, say using DHCP from G, and bring their
network stacks up using this information.  Their kernels now provide the
services that will be mounted, by convention, at /net, again using this
private information.  G initializes statically, bringing its IP stack up
using two interfaces, with two routes: one for internal traffic, and one
default route.

So far, it's all very similar between Plan 9 and Linux.  Here's where
our story diverges.

In Linux, IC and OIC are both taught that they have default routes to the
Internet At Large by sending IP datagrams to G's internal ethernet
interface.  How this works in more detail, they don't care.  G will also
send them corresponding IP datagrams from its interface; that's all they
care about.  G works furiously to decode the network traffic bound for the
internet and NA(P)T it out to its gateway, maintaining very detailed tables
about TCP connections, UDP datagrams, etc, etc.  How could it be but any
other way?

Let's redraw the picture, as things stand now, under Plan 9, just so things
are clear:

                                                  (OIC similar to IC)
+----Internal Computer--------------------+               |
| bind '#I' /net                          |               |
| #I : Kernel IP stack (192.168.1.2)      |               |
| #l : Kernel ethernet driver             |<---Ethernet---+
+-----------------------------------------+               |
                                                          |
+----Gateway------------------------------+               |
| bind '#I' /net                          |               |
| #I : Kernel IP stack (192.168.1.1)      |               |
|                      (4.2.2.2)          |               |
| #l : Kernel ethernet driver  (ether0)   |<---Ethernet---+
|                              (ether1)   |<---Ethernet----->(Internet)
+-----------------------------------------+

In Plan 9, G behaves like any other machine, building a /net out of pieces
exported by its kernel, including the bits that know how to reach the
internet at large through the appropriate interface.  Good so far?

Let's have G run an exportfs, exposing its /net on the internal IP address.
This /net knows how to talk to the internal addresses and the external ones.

Meanwhile, IC can reach out and import G's /net, binding it at /net.alt,
let's say.  Now, programs can talk to the Internet by opening files in
/net.alt.  These open requests will be carried by IC's mount driver, and
then IC's network stack, to G, whereupon the exportfs (in G's userland) will
forward them to its idea of /net (by open()ing, read()ing, write()ing,
etc.), which is the one built on G's kernel, which knows how to reach the
Internet.  Tada!  Picture time:

                                                        (OIC)
+----Internal Computer-------------------------+          |
| abaco: open /net.alt/tcp/clone               |          |
|                                              |          |
| import tcp!192.168.1.1!9fs /net.alt (devmnt) |          |
| bind '#I' /net                               |          |
| #I : Kernel IP stack (192.168.1.2)           |          |
| #l : Kernel ethernet driver                  |<---------+
+----------------------------------------------+          |
                                                          |
+----Gateway------------------------------+               |
| exportfs -a -r /net                     |               |
|                                         |               |
| bind '#I' /net                          |               |
| #I : Kernel IP stack (192.168.1.1)      |               |
|                      (4.2.2.2)          |               |
| #l : Kernel ethernet driver  (ether0)   |<---Ethernet---+
|                              (ether1)   |<---Ethernet----->(Internet)
+-----------------------------------------+

This works perfectly for making connections: IC's IP stack is aware only of
devmnt requests, and G's IP stack is aware of some trafic to&from a normal
process called exportfs, and that that process happens to be making network
requests via #I bound at /net.

The beauty of this design is just how well it works, everywhere, for
everything you'd ever want.

Now, suppose IC goes to listen on TCP:80, by opening /net.alt/tcp/clone.
The same flow of events happen, and to a certain extent, G's network stack
thinks that the exportfs program (running on G) is listening on TCP:80.
exportfs dutifully copies the /net data back to its client.

Naturally, if another program on G were already listening on TCP:80, or the
same program (possibly exportfs) attempted to listen twice (if, say, OIC
played the same game and also tried to listen on G's TCP:80), it would be
told that the port was busy.  This error would be carried back along the
exportfs path just as any other.

So as you see, there is no need to take care of "which packet belongs to
which server" since there can, of course, be only one server listening on
TCP:80.  That server is running on G, and behaves like any other program.
That it just so happens to be an exportfs program, relaying data to and from
another computer, is immaterial.

This also works for FTP, and UDP, and ESP (which are notorious problems in
the NAT world), and for IL, and for IPv6, and for ethernet frames (!), and
... you get the idea.  It does this with no special tools, no complex code,
and a very minimal per-connection overhead (just the IC and G kernels and
G's exportfs tracking a file descriptor).

There are no connection tracking tables anywhere in this design.  There are
just normal IP requests over normal ethernet frames, and a few more TCP (or
IL) connections transporting 9P data.

> On a UNIX clone, or on Windows, because there is exactly one TCP/IP  
> protocol stack in usual setups no two programs can bind to the same port 
> at the same time. I thought Plan 9's approach eliminated that by keeping 
> a distinct instance of the stack for each imported /net.

There can, in fact, be multiple IP stacks on a Plan 9 box, bound to multiple
Ethernet cards, as you claim.  (In fact, one can import another computer's
ethernet cards and run snoopy, or build a network stack, using those
instead.)  I don't think that's relevant to the example at hand, though, as
should be clear from the above.

--nwf;

[-- Attachment #2: Type: application/pgp-signature, Size: 204 bytes --]

Re: [9fans] Do we have a catalog of 9P servers?

[Eris Discordia]

> Oops!  Hopefully as list moderator you will accept my apologies
> for having drawn out a discussion beyond its useful time!!

You have misread my tone--it was suggestive, not assertive. Note that it
was I who raised a question, and then it was I who felt the question was
(more than) adequately answered and thanked list members for helping me
understand something. Not to mention, your remark was little more than a
sarcastic bite out of me.

_I_ am the troll here, by the way. How come _you_ bark at me instead of the
other way?

--On Monday, November 17, 2008 11:50 AM -0500 Dave Eckhardt
<davide+p9@cs.cmu.edu> wrote:

>> I believe your are a little late with your remark. The issue
>> has been resolved.
>
> Oops!  Hopefully as list moderator you will accept my apologies
> for having drawn out a discussion beyond its useful time!!
>
> Dave Eckhardt
>

Re: [9fans] Do we have a catalog of 9P servers?

[Dave Eckhardt]

> I believe your are a little late with your remark. The issue
> has been resolved.

Oops!  Hopefully as list moderator you will accept my apologies
for having drawn out a discussion beyond its useful time!!

Dave Eckhardt

Re: [9fans] Do we have a catalog of 9P servers?

[Eris Discordia]

> Are there any NAT solutions which handle millions of hosts?  Are
> we having a discussion about unicorns?

No. Which is why "not that existing ones have been." And "wreak of havoc
occurs _long_ before" refers to the hypothetical gateway being brought down
with far fewer connections, irrespective of which OS it ran. There remained
the question of which OS/approach required less resources for performing
the task at hand. The resolution I think was that NAT requires less
resources but creates more hassle. Some 9fans pointed out the trade-off
between elegance and performance. Some others pointed out the technical
details and what could/could not be done with each approach. The most
notable comment, in my opinion, was Ron Minnich's that brought to light the
single essentially and irrefutably advantageous feature of Plan 9's
approach.

I believe your are a little late with your remark. The issue has been
resolved.

--On Monday, November 17, 2008 5:20 AM -0500 Dave Eckhardt
<davide+p9@cs.cmu.edu> wrote:

>> Every sensible NAT solution must be implemented with that in
>> mind--not that existing ones have been. Even imagining persistent
>> connections from an entire Class A network makes one shudder.
>> Needless to say, the wreak of havoc occurs _long_ before over 16
>> million hosts need persistent connections.
>
> Especially since you get only 64k TCP connections between any pair
> of IP addresses, e.g., between a NAT box and www.cnn.com.
>
> Are there any NAT solutions which handle millions of hosts?  Are
> we having a discussion about unicorns?
>
> Dave Eckhardt
>

Re: [9fans] Do we have a catalog of 9P servers?

[Dave Eckhardt]

> Every sensible NAT solution must be implemented with that in
> mind--not that existing ones have been. Even imagining persistent
> connections from an entire Class A network makes one shudder.
> Needless to say, the wreak of havoc occurs _long_ before over 16
> million hosts need persistent connections.

Especially since you get only 64k TCP connections between any pair
of IP addresses, e.g., between a NAT box and www.cnn.com.

Are there any NAT solutions which handle millions of hosts?  Are
we having a discussion about unicorns?

Dave Eckhardt

Re: [9fans] Do we have a catalog of 9P servers?

[Eris Discordia]

It was a pleasure and quite educational to read your posting, Micah Stetson.

> The Plan 9 kernel doesn't do load balancing like that.  (Why should
> it?)  To do it in Plan 9, you'd write a small program that listened on
> a particular address and multiplexed connections to a list of other
> addresses.  It wouldn't be hard -- aux/trampoline is halfway there.

Except the program wouldn't be any smaller than its UNIX equivalent. It
would simply be the same port forwarding that is present in NAT. Because
multiplexing a port requires either separate protocol stacks or a (complex)
endpoint translation scheme, i.e. NAT. (as I noted before aux/trampoline is
a transport layer proxy, by the way).

This last note aside, I think the issue of address translation has been
succinctly reviewed now (to my advantage, for I have learnt a lot along the
way :-). We can let it rest for a while and wait to see what Erik
Quanstrom's NAT implementation will look like.

--On Sunday, November 16, 2008 9:12 PM -0800 Micah Stetson
<micah@stetsonnet.org> wrote:

>>> That isn't happening.  All we have is one TCP connection and one small
>>> program exporting file service.
>>
>> I see. But then, is it the "small program exporting file service" that
>> does the multiplexing? I mean, if two machines import a gateway's /net
>> and both run HTTP servers binding to and listening on *:80 what takes
>> care of which packet belongs to which HTTP server?
>
> The Plan 9 kernel doesn't do load balancing like that.  (Why should
> it?)  To do it in Plan 9, you'd write a small program that listened on
> a particular address and multiplexed connections to a list of other
> addresses.  It wouldn't be hard -- aux/trampoline is halfway there.
>
> I think you're still thinking of importing /net in terms of NAT.  It
> can be used to solve some of the same problems, but it isn't the same
> at all.  Exportfs (the small program above) doesn't know that it's
> exporting a network stack or any kind of "special" files because the
> files in /net aren't special.  The network stack doesn't know it's
> being used by a different computer -- it just sees exportfs reading
> and writing its files.  The HTTP server doesn't know it's using
> somebody else's network stack, it's just reading and writing files in
> /net that it expects to work a certain way.  The only component that
> knows there's a network stack being forwarded from one machine to
> another is the person at the controls.
>
> This is nothing like NAT.  No packets are rewritten, and no code
> exists solely to support one computer using another's network stack.
> So FTP and other protocols that frustrate NAT work without special
> treatment.  The same principal obviates the need for port forwarding.
> (In Plan 9 networks, that is.)
>
> Micah
>

Re: [9fans] Do we have a catalog of 9P servers?

[Eris Discordia]

This explanation isn't immediately comprehensible to me--I guess I'll have
to read the man pages and some other documentation and then come back to
understand this.

Thanks anyway.

--On Sunday, November 16, 2008 4:52 PM -0500 erik quanstrom
<quanstro@quanstro.net> wrote:

>> the same time. I thought Plan 9's approach eliminated that by keeping a
>> distinct instance of the stack for each imported /net.
>
> not quite.
>
> referencing '#In' for the first time will cause the nth
> ip stack to be created.  subsequent references do not create
> a copy.
>
> it's also important to note that import doesn't operate on
> devices directly (except in the degnerate case of
> '#D' for some device D).  import builds a new namespace
> according to the recipie in /lib/namespace (cf. namepace(6))
> on the importee. so /net references that namespace, not a device.
> obviously '#t' still references a device on the importee.
>
> - erik
>
>

Re: [9fans] Do we have a catalog of 9P servers?

[Micah Stetson]

>> That isn't happening.  All we have is one TCP connection and one small
>> program exporting file service.
>
> I see. But then, is it the "small program exporting file service" that does
> the multiplexing? I mean, if two machines import a gateway's /net and both
> run HTTP servers binding to and listening on *:80 what takes care of which
> packet belongs to which HTTP server?

The Plan 9 kernel doesn't do load balancing like that.  (Why should
it?)  To do it in Plan 9, you'd write a small program that listened on
a particular address and multiplexed connections to a list of other
addresses.  It wouldn't be hard -- aux/trampoline is halfway there.

I think you're still thinking of importing /net in terms of NAT.  It
can be used to solve some of the same problems, but it isn't the same
at all.  Exportfs (the small program above) doesn't know that it's
exporting a network stack or any kind of "special" files because the
files in /net aren't special.  The network stack doesn't know it's
being used by a different computer -- it just sees exportfs reading
and writing its files.  The HTTP server doesn't know it's using
somebody else's network stack, it's just reading and writing files in
/net that it expects to work a certain way.  The only component that
knows there's a network stack being forwarded from one machine to
another is the person at the controls.

This is nothing like NAT.  No packets are rewritten, and no code
exists solely to support one computer using another's network stack.
So FTP and other protocols that frustrate NAT work without special
treatment.  The same principal obviates the need for port forwarding.
(In Plan 9 networks, that is.)

Micah

Re: [9fans] Do we have a catalog of 9P servers?

[erik quanstrom]

> the same time. I thought Plan 9's approach eliminated that by keeping a
> distinct instance of the stack for each imported /net.

not quite.

referencing '#In' for the first time will cause the nth
ip stack to be created.  subsequent references do not create
a copy.

it's also important to note that import doesn't operate on
devices directly (except in the degnerate case of
'#D' for some device D).  import builds a new namespace
according to the recipie in /lib/namespace (cf. namepace(6))
on the importee. so /net references that namespace, not a device.
obviously '#t' still references a device on the importee.

- erik

Re: [9fans] Do we have a catalog of 9P servers?

[Eris Discordia]

> That isn't happening.  All we have is one TCP connection and one small
> program exporting file service.

I see. But then, is it the "small program exporting file service" that does
the multiplexing? I mean, if two machines import a gateway's /net and both
run HTTP servers binding to and listening on *:80 what takes care of which
packet belongs to which HTTP server?

On a UNIX clone, or on Windows, because there is exactly one TCP/IP
protocol stack in usual setups no two programs can bind to the same port at
the same time. I thought Plan 9's approach eliminated that by keeping a
distinct instance of the stack for each imported /net.

--On Sunday, November 16, 2008 11:46 AM -0800 Micah Stetson
<micah@stetsonnet.org> wrote:

>> Very well said. This posting summarizes what's been going on:
>
> Thank you.
>
>> 2. Generality costs.
>
> Not always, and I think you may be overestimating the costs here.
> Your later posts talk about making a complete copy of the TCP stack.
> That isn't happening.  All we have is one TCP connection and one small
> program exporting file service.
>
> Micah
>

Re: [9fans] Do we have a catalog of 9P servers?

[Micah Stetson]

> Very well said. This posting summarizes what's been going on:

Thank you.

> 2. Generality costs.

Not always, and I think you may be overestimating the costs here.
Your later posts talk about making a complete copy of the TCP stack.
That isn't happening.  All we have is one TCP connection and one small
program exporting file service.

Micah

Re: [9fans] Do we have a catalog of 9P servers?

[Micah Stetson]

>> I think Eris is saying that this makes Plan
>> 9's resource requirements grow with the number of hosts behind the
>> gateway -- not just with the number of connections through it like
>> Linux.
>
> I don't quite follow. If by resources you mean process related resources
> than I would agree. My very first comment didn't have anything to do
> with process related resources.

I did mean the extra processes, and I assumed that was what Eris was
referring to.

> And for the TCP related resources I
> maintain that the amount of overhead in Plan9's case is definitely
> comparable to a Linux's case.

Right.

Micah

Re: [9fans] Do we have a catalog of 9P servers?

[Eris Discordia]

Finally, one very remarkable remark <sighs deeply>.

Ron Minnich clarifies what _is_ indeed the advantage of Plan 9. I hope
those who have followed this thread so far at last see what I was driving
at. The edge of Plan 9 was never in kernel space but in user space.

To put it in the abstract terms I understand: existence of a neutral scheme
of networking is the _one_ and _only_, and _huge_ advantage of Plan 9. It
is not coding practice, clarity of vision, being favored by "hackers of the
old," protocol X of Y repute, ease of implementing a protocol, or any other
obscure, subjective non-technicality that distinguishes your beloved OS,
9fans--it's the complete network neutrality of the OS. UNIX invented pipes
that originally began and ended on one machine (ever wondered why everyone
remembers UNIX with pipes?). That was application neutrality of I/O (what
is a computer's most important task? to transmute I till it's O). Plan 9
invented "pipes" that began and ended on any machine. That was network (and
application) neutrality of I/O. The next step towards free-form computing.

Thank you very much, Ron Minnich. I am edified.

--On Sunday, November 16, 2008 10:01 AM -0800 ron minnich
<rminnich@gmail.com> wrote:

> On Sun, Nov 16, 2008 at 9:17 AM, erik quanstrom <quanstro@quanstro.net>
> wrote:
>
>> i think it is a bit easier.  the plan 9 kernel is simplier.
>> but that's beside the point.  plan 9 network does more
>> with less than bsd.  /net is more expressive than sockets.
>> the dial interface is quite elegant.  plan 9 telnet works
>> just fine with il and most other connection-based protocols.
>>
>
> I don't think the main point is simplicity, although it is nice. The
> big point to me: network object names are not binary objects but
> pathnames.
>
> Which is why a 386 can mount /net from a ppc and dump the routing
> tables. With a shell script.
>
> So, as has been pointed out many times:
> 1. Cost to migrate all unix apps to ipv6: let's just say "high" -- we
> won't know until they've all moved.
> 2. Cost to migrate all unix apps to infiniband addresses with 20-octet
> MAC addresses: "high". SIX YEARS LATER, you still have to manually
> patch all of dhcpd to manage 20-octet MAC addresses.
> And some parts of the Linux kernel still dont' always agree with other
> parts about what an IB mac address looks like.
> 3. Cost to migrate Plan 9 apps to either of these: *zero*. They're
> pathnames.
>
> I still recall how unhappy many of us were when we got BSD sockets
> with binary names. It was just nausea-inducing. It didn't have to be
> that way: "/dev/tcp" was being worked on for Unix at the time, but it
> just didn't quite work out. /proc was in the future at that point ...
>
> Plan 9 restored sanity: names of things are paths, not obscure binary
> structures that  could not be used without htons and their ilk.
>
> But the brokenness of the bsd interface is so ingrained that most
> people take it for granted: "you can't name a socket like you name a
> file" -- who says?
>
> ron
>

Re: [9fans] Do we have a catalog of 9P servers?

[Eris Discordia]

> the trite "not reinventing the wheel" is countered with
> the equally trite "use the right tool for the job".  both
> avoid the point of carefully evaluating the engineering
> problem.

Deprecating IL must have had engineering reasons. Among them, I guess, that
in the course of time and as applications accumulated and became more
complex it dawned on the developers that TCP had always had good reason to
be as complex as it were.

> tcp is the perl of networking.

I happen to like Perl but they say liking Perl here is like being a leper.

> i think it is a bit easier.  the plan 9 kernel is simplier.
> but that's beside the point.  plan 9 network does more
> with less than bsd.  /net is more expressive than sockets.
> the dial interface is quite elegant.  plan 9 telnet works
> just fine with il and most other connection-based protocols.

You seem to forget--or am I gravely mistaken?--that the network layer
occurs below /net not above it--which is why Plan 9 connections can remain
network agnostic--so the expressiveness of /net abstraction (if it exists
outside of subjective judgment) won't ease the pain of implementing a
network layer protocol.

Actually, the marginal (contrast with: the ubiquity of sockets) nature of
the interface you need to present to layers atop the layer you are
implementing will trouble you all along the way because few people know how
to present that sort of interface, there has been little experimentation in
that direction outside of the small community of Plan 9 researchers, and
the people who designed the network layer protocol you are implementing
were more or less enamored of another abstraction (again, sockets).

For the specific case of dial, dial(3) says that transport may be
explicitly specified (TCP, UDP, UNIX domain sockets, and "net") which means
dial sees things from above transport layer, i.e. from the application
layer. In other words if you were to implement IPv6 for Plan 9 you would
have to implement either TCP6 or another IPv6 transport protocol as well.
The diversity of transports available in Plan 9 should not leave the
impression that one can get away with _no_ transports.

So, it becomes unclear again where the advantage of Plan 9 for implementing
a new network protocol is. Plan 9 may have many advantages, this isn't one
of them. My impression is that its edges are mostly in newer areas of
computing (this "cloud" computing thingy) and _almost certainly_ not in
areas already explored and exhausted to the extreme.

--On Sunday, November 16, 2008 12:17 PM -0500 erik quanstrom
<quanstro@quanstro.net> wrote:

>> And what is the "IP world?" Aren't you part of it? Does your network use
>> a  different transport/network layer protocol than TCP/IP? IL is
>> dead--just in  case you were thinking of it--because to re-invent the
>> wheel was eventually  perceived redundant.
>
> yes.  several.  il/ip being one of them.
>
> the trite "not reinventing the wheel" is countered with
> the equally trite "use the right tool for the job".  both
> avoid the point of carefully evaluating the engineering
> problem.
>
> tcp is the perl of networking.
>
>> I see no reason why implementing IPv6 for Plan 9 has to be easier than
>> the  same task on *BSD. What does Plan 9's dubious claim to superior
>> design as  an OS have to do with implementing a network layer protocol?
>
> i think it is a bit easier.  the plan 9 kernel is simplier.
> but that's beside the point.  plan 9 network does more
> with less than bsd.  /net is more expressive than sockets.
> the dial interface is quite elegant.  plan 9 telnet works
> just fine with il and most other connection-based protocols.
>
> - erik
>
>

Re: [9fans] Do we have a catalog of 9P servers?

[ron minnich]

On Sun, Nov 16, 2008 at 9:17 AM, erik quanstrom <quanstro@quanstro.net> wrote:

> i think it is a bit easier.  the plan 9 kernel is simplier.
> but that's beside the point.  plan 9 network does more
> with less than bsd.  /net is more expressive than sockets.
> the dial interface is quite elegant.  plan 9 telnet works
> just fine with il and most other connection-based protocols.
>

I don't think the main point is simplicity, although it is nice. The
big point to me: network object names are not binary objects but
pathnames.

Which is why a 386 can mount /net from a ppc and dump the routing
tables. With a shell script.

So, as has been pointed out many times:
1. Cost to migrate all unix apps to ipv6: let's just say "high" -- we
won't know until they've all moved.
2. Cost to migrate all unix apps to infiniband addresses with 20-octet
MAC addresses: "high". SIX YEARS LATER, you still have to manually
patch all of dhcpd to manage 20-octet MAC addresses.
And some parts of the Linux kernel still dont' always agree with other
parts about what an IB mac address looks like.
3. Cost to migrate Plan 9 apps to either of these: *zero*. They're pathnames.

I still recall how unhappy many of us were when we got BSD sockets
with binary names. It was just nausea-inducing. It didn't have to be
that way: "/dev/tcp" was being worked on for Unix at the time, but it
just didn't quite work out. /proc was in the future at that point ...

Plan 9 restored sanity: names of things are paths, not obscure binary
structures that  could not be used without htons and their ilk.

But the brokenness of the bsd interface is so ingrained that most
people take it for granted: "you can't name a socket like you name a
file" -- who says?

ron

Re: [9fans] Do we have a catalog of 9P servers?

[Charles Forsyth]

> Obviously, a linux server is going to have a hard time importing /net
>(in a useful way, at least until Glendix gets there).

an existing library interceptor allows Linux to "import" networks via peculiar
setups of ssh, so i don't see why that mechanism couldn't more easily
read and write a remote /net via 9P.

Re: [9fans] Do we have a catalog of 9P servers?

[lucio]

> I have no reason to believe Bell Labs' not-so-current
> experimentation is any more "saintly" and free of blemish than the
> previous. In time somebody will come up with the Plan 9 Haters Handbook.

Surely, there has been enough traffic here to emphasise that Plan 9
contains some good, fresh ideas in many cases to address Unix's
original failures of vision?

The "perfect" operating system isn't even a pipe dream, specially when
hardware converges to a lowest-common-denominator variety of CPU
design with legacy going back generations and the common consensus is
to inflate the kernel with as many features as it can possibly
contain, irrespective of their actual merit, nevermind their mutual
incompatibilities.

Plan 9 is not "saintly" and I fail to see how you could have arrived
at the perception that anyone here considers it so.  Our own
frustration (mine, at any rate) is that none of the more popular
alternatives to Plan 9 has geared itself up to discard, as Plan 9 has,
the baggage that makes Unix an inferior operating system and worse,
that by refusing to see the need to do so the Unix-perpetuating
community is condemning users to suffer unnecessarily.  In this
respect Plan 9 shows some of the way, it is annoying that it goes
largely unacknowledged, specially as this becomes an obstacle to any
further research in that direction.

Information Technology has always been very complex and consequently
prone to failures; sometimes spectacular failures, more often at the
level of mere inconveniences.  At the same time, computing power has
increased phenomenally, making it possible for information
technologists to aspire to grandiose products.  The nett effect is an
impossibly huge quantity of "software" of very dubious quality,
partially moderated by the audience that uses it, an audience that is
hardly competent to judge its quality and, worse, is conditioned to
accept mediocre products because it is not aware of any alternatives.
For that matter, there may be no alternatives, but that is a
self-perpetuating situation.

Ii is no more than a delusion that the audience will supply the
quality, a delusion originating from the sheer magnitude of the
audience.  The result: Windows, Linux, FreeBSD and all the other
offerings in diminishing popularity.

Plan 9, initially, bucked this trend, aiming for simplicity and
accuracy rather than quantity.  Sadly, that's not a great survival
trait _in_the_current_context_.  Reminds me of the Great Reptiles.
They ruled the world until conditions demanded different properties
(furry skin?  small size?  warm blood?  viviparous?  whatever) and
then they perished.

My hope is that Plan 9 is more like a small furry mammal than
something destined for estinction.  But that is because I have
considerable investment, technical and emotional, in it, not because
it is a holy grail.  I approve of its "new" properties and, being
somewhat more discriminating than Mother Nature (or Natural
Selection), I believe they are improvements in an abstract, not just,
maybe not even, in a pragmatic, survival-oriented fashion.  Maybe I'm
looking at esthetics when the rest of the world is looking for
performance.  In my philosophy, civilisation is the ability to
transcend the practical and seek something more satisfying;
mathematics is more beneficial than physics, Plan 9 is more beautiful
than Linux.

But not saintly, not perfect, not the product of infallible wisdom.
Not even more useful, any more than, say, Michelangelo's David is
useful.  Plan 9 is the product of artistry, the best I have been
exposed to, which is not to say that there aren't sculptures out there
that may be deemed greater than Michelangelo's.

But, in a subjective fashion, Plan 9 is better than the obvious
contenders, where it is clear that the developers have followed
totally different "esthetic" principles and, sadly, have overlooked
certain fundamentals that are in my opinion totally non-negotiable
simply because they have been revealed and shown to be valuable.

You want something else, you're extremely lucky to exist in a world
with many choices.  Make the most of them.

++L

Re: [9fans] Do we have a catalog of 9P servers?

[Eris Discordia]

>  Obviously, a linux server is going to have a hard time importing /net
> (in a useful way, at least until Glendix gets there).

Of course, which means dependence of network layer operations on an
application layer protocol in a heterogeneous--you aren't plan9ing to take
over the world, are you?--is most meaningless and non-standard.

--On Monday, November 17, 2008 12:09 AM +0900 sqweek <sqweek@gmail.com>
wrote:

> On Sun, Nov 16, 2008 at 8:39 PM, Eris Discordia
> <eris.discordia@gmail.com> wrote:
>>> aux/listen1 -tv tcp!*!22 /bin/aux/trampoline tcp!$linux!22
>>
>> And in this case you
>> don't have an imported /net and the fabled transparency.
>
>  Obviously, a linux server is going to have a hard time importing /net
> (in a useful way, at least until Glendix gets there).
> -sqweek
>

Re: [9fans] Do we have a catalog of 9P servers?

[erik quanstrom]

> And what is the "IP world?" Aren't you part of it? Does your network use a
> different transport/network layer protocol than TCP/IP? IL is dead--just in
> case you were thinking of it--because to re-invent the wheel was eventually
> perceived redundant.

yes.  several.  il/ip being one of them.

the trite "not reinventing the wheel" is countered with
the equally trite "use the right tool for the job".  both
avoid the point of carefully evaluating the engineering
problem.

tcp is the perl of networking.

> I see no reason why implementing IPv6 for Plan 9 has to be easier than the
> same task on *BSD. What does Plan 9's dubious claim to superior design as
> an OS have to do with implementing a network layer protocol?

i think it is a bit easier.  the plan 9 kernel is simplier.
but that's beside the point.  plan 9 network does more
with less than bsd.  /net is more expressive than sockets.
the dial interface is quite elegant.  plan 9 telnet works
just fine with il and most other connection-based protocols.

- erik

Re: [9fans] Do we have a catalog of 9P servers?

[Eris Discordia]

> [...] NAT's raison d'etre is that IP is broken [...]

That's very far from truth. In this case IP's only fault is lack of
exceptional foresight. Who'd think someday every kids' toy would claim a
network address?

As for NAT, you know very well it has uses entirely unrelated to IP's
limitations.

> systems, and much more importantly by being completely network
> protocol agnostic, part of the beauty of importing /net is that you

I believe every application layer protocol ought to be, and most of them
are, network protocol agnostic. Nothing "miraculous" there--it's just
following the basic guidelines of layered network design. Except perhaps
9P's simplicity has allowed it to make fewer assumptions about the
underlying network, no doubt because it has never been deployed in
real-world situations (BG/L and Coraid don't count).

> The IP world has been trying to move to IPv6 for almost a decade, and
> it will be at least that long before the migration is done, plus it
> will be a painful and cumbersome process with lots of wasted resources
> along the way.

What keeps the world from migrating is first and foremost inertia: IPv4
just does the job, creating some adventures every once in while. There's
also the problem of appliances with their proprietary software.

>From the mainstream-OS standpoint by the end of 2002 every major operating
system featured a IPv6 stack. The last one to catch up was Windows whose
production quality stack didn't come out until Vista (actually it was
present in WS2K3, but that's a different story).

And what is the "IP world?" Aren't you part of it? Does your network use a
different transport/network layer protocol than TCP/IP? IL is dead--just in
case you were thinking of it--because to re-invent the wheel was eventually
perceived redundant.

> In the Plan 9 world, migrating to a new network protocol is pretty much a
> non-issue, which as I think somebody pointed out, is not hard to
> accomplish over a weekend.

I see no reason why implementing IPv6 for Plan 9 has to be easier than the
same task on *BSD. What does Plan 9's dubious claim to superior design as
an OS have to do with implementing a network layer protocol?

*BSD's case took some years and many dedicated developers to come to
fruition. Plan 9's case is still in the making. Try this:
<http://www.google.com/search?q=ipv6+site:9fans.net>

> P.S.: I have zero interest in discussing NAT or IPv6, if you are
> interested go watch the talks at Google's IPv6 conference, and you
> will see how much misery NAT is causing.

Okay. That you have cared to write a response is kind enough. Thank you.

--On Sunday, November 16, 2008 2:25 PM +0100 Uriel <uriel99@gmail.com>
wrote:

> NAT's raison d'etre is that IP is broken, NAT doesn't completely solve
> this problem, and creates a whole new set of problems that will
> plague the world until a new version of IP can be deployed (which
> interestingly enough, is made much more complicated by the prevalence
> of NAT itself).
>
> In the meantime Plan 9 and /net make it much easier to work around
> IP's limitations because network stacks can be shared easily across
> systems, and much more importantly by being completely network
> protocol agnostic, part of the beauty of importing /net is that you
> might not even be using IP to reach your gateway, and that
> applications don't care what network protocols either your local host
> or the gateway speak.
>
> The IP world has been trying to move to IPv6 for almost a decade, and
> it will be at least that long before the migration is done, plus it
> will be a painful and cumbersome process with lots of wasted resources
> along the way. In the Plan 9 world, migrating to a new network
> protocol is pretty much a non-issue, which as I think somebody pointed
> out, is not hard to accomplish over a weekend.
>
> Peace
>
> uriel
>
> P.S.: I have zero interest in discussing NAT or IPv6, if you are
> interested go watch the talks at Google's IPv6 conference, and you
> will see how much misery NAT is causing.
>
> On Sun, Nov 16, 2008 at 12:45 PM, Eris Discordia
> <eris.discordia@gmail.com> wrote:
>> If there were no real routers and the world still used bang paths you
>> wouldn't be thinking about overlay networks the way you do. Does your
>> thinking fall under the same category of fallacy?
>>
>> By the way, I think you have missed the meaning of raison d'etre. There
>> is a necessity, a problem, somebody responds, solves the problem. NAT
>> (or TCP/IP, or Plan 9) emerges.
>>
>> --On Saturday, November 15, 2008 11:57 PM -0700 andrey mirtchovski
>> <mirtchovski@gmail.com> wrote:
>>
>>>> 5. If you need NAT weigh the options of doing it. It may turn out that
>>>> importing /net is the best choice for your application. Or it may turn
>>>> out otherwise. /net has a raison d'etre--regular NAT, too.
>>>
>>> If regular NAT hadn't been invented you wouldn't be thinking in terms
>>> of regular NAT, therefore you wouldn't be "needing NAT".
>>>
>>> Post hoc ergo propter hoc. (you'll find it under "logical fallacy" on
>>> wikipedia)
>>>
>>
>>
>>
>>
>>
>>
>

Re: [9fans] Do we have a catalog of 9P servers?

[Eris Discordia]

> Eris, are you telling, that plan9 is not suited to all the problems of
> all badly designed and bloated software? Oh goddess, that's horrible.
> What is this thing you're searching for? Have you tried it with XML?

Yes and no. "The badly designed and bloated software" is in large part a
relic of Bell Labs' previous experimentation with numerous people's
graffiti on it. I have no reason to believe Bell Labs' not-so-current
experimentation is any more "saintly" and free of blemish than the
previous. In time somebody will come up with the Plan 9 Haters Handbook.

Perhaps you can give this book a try on the subject of Bell Labs'
infallibility:

<http://www.privateline.com/Gehani/index.htm>

If someone at Bell Labs reads this I will be very much grateful if they
tell the list and me about what happened to ODE.

--On Sunday, November 16, 2008 1:49 PM +0100 hiro <23hiro@googlemail.com>
wrote:

> Eris, are you telling, that plan9 is not suited to all the problems of
> all badly designed and bloated software? Oh goddess, that's horrible.
> What is this thing you're searching for? Have you tried it with XML?
>

Re: [9fans] Do we have a catalog of 9P servers?

[sqweek]

On Sun, Nov 16, 2008 at 8:39 PM, Eris Discordia
<eris.discordia@gmail.com> wrote:
>> aux/listen1 -tv tcp!*!22 /bin/aux/trampoline tcp!$linux!22
>
> And in this case you
> don't have an imported /net and the fabled transparency.

 Obviously, a linux server is going to have a hard time importing /net
(in a useful way, at least until Glendix gets there).
-sqweek

Re: [9fans] Do we have a catalog of 9P servers?

[Uriel]

NAT's raison d'etre is that IP is broken, NAT doesn't completely solve
this problem, and creates a whole new set of problems that will
plague the world until a new version of IP can be deployed (which
interestingly enough, is made much more complicated by the prevalence
of NAT itself).

In the meantime Plan 9 and /net make it much easier to work around
IP's limitations because network stacks can be shared easily across
systems, and much more importantly by being completely network
protocol agnostic, part of the beauty of importing /net is that you
might not even be using IP to reach your gateway, and that
applications don't care what network protocols either your local host
or the gateway speak.

The IP world has been trying to move to IPv6 for almost a decade, and
it will be at least that long before the migration is done, plus it
will be a painful and cumbersome process with lots of wasted resources
along the way. In the Plan 9 world, migrating to a new network
protocol is pretty much a non-issue, which as I think somebody pointed
out, is not hard to accomplish over a weekend.

Peace

uriel

P.S.: I have zero interest in discussing NAT or IPv6, if you are
interested go watch the talks at Google's IPv6 conference, and you
will see how much misery NAT is causing.

On Sun, Nov 16, 2008 at 12:45 PM, Eris Discordia
<eris.discordia@gmail.com> wrote:
> If there were no real routers and the world still used bang paths you
> wouldn't be thinking about overlay networks the way you do. Does your
> thinking fall under the same category of fallacy?
>
> By the way, I think you have missed the meaning of raison d'etre. There is a
> necessity, a problem, somebody responds, solves the problem. NAT (or TCP/IP,
> or Plan 9) emerges.
>
> --On Saturday, November 15, 2008 11:57 PM -0700 andrey mirtchovski
> <mirtchovski@gmail.com> wrote:
>
>>> 5. If you need NAT weigh the options of doing it. It may turn out that
>>> importing /net is the best choice for your application. Or it may turn
>>> out otherwise. /net has a raison d'etre--regular NAT, too.
>>
>> If regular NAT hadn't been invented you wouldn't be thinking in terms
>> of regular NAT, therefore you wouldn't be "needing NAT".
>>
>> Post hoc ergo propter hoc. (you'll find it under "logical fallacy" on
>> wikipedia)
>>
>
>
>
>
>
>

Re: [9fans] Do we have a catalog of 9P servers?

[hiro]

Eris, are you telling, that plan9 is not suited to all the problems of
all badly designed and bloated software? Oh goddess, that's horrible.
What is this thing you're searching for? Have you tried it with XML?

Re: [9fans] Do we have a catalog of 9P servers?

[Eris Discordia]

If there were no real routers and the world still used bang paths you
wouldn't be thinking about overlay networks the way you do. Does your
thinking fall under the same category of fallacy?

By the way, I think you have missed the meaning of raison d'etre. There is
a necessity, a problem, somebody responds, solves the problem. NAT (or
TCP/IP, or Plan 9) emerges.

--On Saturday, November 15, 2008 11:57 PM -0700 andrey mirtchovski
<mirtchovski@gmail.com> wrote:

>> 5. If you need NAT weigh the options of doing it. It may turn out that
>> importing /net is the best choice for your application. Or it may turn
>> out otherwise. /net has a raison d'etre--regular NAT, too.
>
> If regular NAT hadn't been invented you wouldn't be thinking in terms
> of regular NAT, therefore you wouldn't be "needing NAT".
>
> Post hoc ergo propter hoc. (you'll find it under "logical fallacy" on
> wikipedia)
>

Re: [9fans] Do we have a catalog of 9P servers?

[Eris Discordia]

> aux/listen1 -tv tcp!*!22 /bin/aux/trampoline tcp!$linux!22

This is absolutely interesting. Upon reading trampoline(8) it seemed to me
that port forwarding, or rather the more general case of _traffic_
forwarding, is being implemented outside of any NAT. And in this case you
don't have an imported /net and the fabled transparency. The gateway is
being tinkered with.

I can't right away know whether any address translation is done--I don't
have access to the source of trampoline(8) and the man page doesn't mention
any such thing. Is your serving machine (_not_ gateway) using a
non-routable or a routable IP address?

If you say you're using this I trust it must be working well for SSH
(that's the protocol you're forwarding, right?) Does it also work for
non-passive FTP?

The "ugly" NAT implementations, e.g. on Linux, that have been criticized on
this thread are _mandated_ by RFC 1631 to deal with even non-passive FTP
and other badly designed protocols that exchange network layer awareness at
application layer (NAT does that by extending upwards into application
layer). The criticism has largely been based on misunderstanding the
circumstances and on the air of vainglory that seems to surround some 9fans
(those "funny gnu guys," eh?).

> as usual, plan9 lets you combine simple commands to provide all sorts
> of interesting functionality.

Add to the above that the simple command line you use is mutatis mutandis
available on nearly every UNIX clone:
<http://www.openbsd.org/faq/pf/rdr.html#tcpproxy>

This of course has nothing to do with real NAT and the complex requirements
of hassle-free port forwarding. The "poor man's proxy" can be created with
many combinations of user space tools.

> there you have it, port forwarding without the need to reset all your
> connections (my d-link router does it).

My D-Link router's "virtual servers," i.e. destinations for port
forwarding, entries can be updated without any harm to existing
connections. I presume either your router is irredeemably old or there's a
glitch in the firmware that could be fixed by updating. Mine is a
DSL-2500U, Linux-based.

--On Saturday, November 15, 2008 10:15 PM -0200 Felipe Bichued
<bichued@gmail.com> wrote:

> as usual, plan9 lets you combine simple commands to provide all sorts
> of interesting functionality. on my plan9 gateway i often have to do
> something like:
>
> aux/listen1 -tv tcp!*!22 /bin/aux/trampoline tcp!$linux!22
>
> there you have it, port forwarding without the need to reset all your
> connections (my d-link router does it).
>
> On Sat, Nov 15, 2008 at 8:07 PM, Eris Discordia
> <eris.discordia@gmail.com> wrote:
>>> It would be helpful if you can quote exactly the part on which you are
>>> requesting
>>> my opinion.
>>
>> This part:
>>
>>> It actually does qualify. I believe (though I could be wrong) state
>>> information and communication buffers are the biggest memory spending
>>> for network operations.
>>>
>>> There _could_ be a trade-off between the transient NAT with its
>>> processing power toll and the persistent /net-import with its memory
>>> cost. However, systems like FreeBSD pre-allocate and always keep a
>>> number of network buffers so the processing power toll for transience
>>> almost vanishes if the kernel is fine-tuned for its load. By contrast,
>>> on a large network /net-import strategy could make a "powerful" gateway
>>> unavoidable because every machine on the network will need a session
>>> with the gateway even if it only rarely communicates with the outside
>>> world, unless you implement an uglier-than-NAT client-side
>>> dial-on-demand.
>>
>> And this:
>>
>>> There is a huge difference. Almost as much difference there is between
>>> NAT and RSVP.
>>
>> Where importing /net is compared to RSVP because it uses a persistent
>> application layer overlay to do a job that is usually done with transient
>> connections. In case of RSVP there's a motive to do that, in case of NAT,
>> well, NAT solutions already exist and work pretty well--I've actually
>> been saying that /net-imported may be useful (!= usable) for some
>> applications I don't know about but very probably not for NAT.
>>
>>> What field?
>>
>> Out of the field := clueless, a soccer player who follows the ball
>> outside the field
>>
>>> I am only familiar with Linux implementation.
>>
>> Which is only a small subset of iptables, right?
>>
>>> Yes. And that's the NAT that *I* and a million Linux lemming out there
>>> are familiar with.
>>
>> Not right. As late as SuSE v9.0 people used the much lighter and less
>> sophisticated "masquerading" ipmasq which didn't involve iptables
>> (beginning with v10's iptables became the default). It was the Linux
>> equivalent of the sort of half-assed "NAT" that importing /net will give
>> you. Easy but incomplete.
>>
>> In case of iptables as I pointed out before you have at your disposal a
>> very sophisticated tool--that you put the tool to uses it is too big for
>> is mostly your fault. There are many other Linux NAT solutions that do
>> NAT proper.
>>
>>> data structures to do its job. I'll leave it up to you to see how much
>>> memory gets wasted on each connection.
>>
>> Do you claim you have compared that to doing the same thing on Plan 9?
>> If X bytes of memory get used up for a task you don't call it a "waste
>> of memory" unless the task could be done with (X - x) bytes being used
>> up.
>>
>>> I have no clue what netfilter does, thus I can't answer your question.
>>
>> Netfilter (or NetFilter) is the larger framework iptables is part of. It
>> provides every conceivable capability at network layer--everything,
>> including NAT.
>>
>>> I thought the original discussion was dedicated to comparing an overhead
>>> that the general purpose NAT box has with an overhead of a Plan9 box
>>> from which /net was imported. Since I haven't seen specifics I gave the
>>> example of a typical Linux NAT built using iptables. That's the area I'm
>>> familiar with.
>>
>> It's OK. But you haven't made any comparison of the overhead, yet.
>>
>>> Define port forwarding. And I really mean it: define. Then I can may be
>>> offer a bit of  functionality on Plan9 that would be capable of fitting
>>> your definition.
>>
>> The traditional definition of NAT is (of course) here:
>> <http://asg.andrew.cmu.edu/rfc/rfc1631.html>
>>
>> Here's a definition of port forwarding:
>> <http://hasenstein.com/linux-ip-nat/diplom/node7.html#SECTION00071300000
>> 000000000>
>>
>> However I give an operational definition which involves what is nowadays
>> _expected_ from any NAT solution:
>>
>> A packet arrives at the gateway. Behind the gateway there is a machine
>> dedicated to serving FTP and another to HTTP, or two machines both
>> dedicated to serving HTTP that are meant to balance each other's loads.
>> You want the gateway to decide on how to rewrite the packet so that
>> inbound traffic to port 21 goes to the FTP machine and inbound traffic
>> to port 80 goes to the HTTP machine, or the inbound traffic in one
>> session goes to one HTTP machine and the inbound traffic in another
>> session goes to the other HTTP machine. To add to the hassle you may
>> also want--for security reasons--to run your server software on other
>> ports than 21 and 80, and the gateway needs to rewrite the packet so
>> that it reaches the right endpoint (IP:port, in this case). The process
>> shall be transparent to the internal and external networks.
>>
>> How should the two imported /net's on the two machines on the internal
>> network rewrite packets without becoming NAT re-invented?
>>
>> --On Saturday, November 15, 2008 12:01 PM -0800 Roman Shaposhnik
>> <rvs@sun.com> wrote:
>>
>>> On Nov 15, 2008, at 3:21 AM, Eris Discordia wrote:
>>>>>
>>>>> Exactly! An idle TCP connection costs you nothing except the state
>>>>> that
>>>>
>>>> Would you mind reading my response, too, and then informing me of
>>>> your opinion?
>>>
>>> It would be helpful if you can quote exactly the part on which you are
>>> requesting
>>> my opinion.
>>>
>>>>> Not only that, but if you look at the amount of state something like
>>>>> iptables on Linux needs to keep in order to provide NAT
>>>>> capabilities it
>>>>> becomes a complete toss.
>>>>
>>>> You seem to be extremely out of the field
>>>
>>> What field?
>>>
>>>> with respect to what iptables does and how normal NAT is implemented
>>>> on a *BSD system (which was my example).
>>>
>>> I have no knowledge of how NAT is implemented on a *BSD system and thus
>>> I can not comment. I am only familiar with Linux implementation. Thus if
>>> that's
>>> not what you're interested in discussing -- lets stop right now.
>>>
>>>> Iptables provides very sophisticated routing and filtering
>>>> capabilities. It's used as a back-end for stateful inspection,
>>>> packet rewriting, logging, routing, intrusion detection, and
>>>> firewalling applications. That's NAT... plus one million other
>>>> applications.
>>>
>>> Yes. And that's the NAT that *I* and a million Linux lemming out there
>>> are familiar with.
>>> Arguing that your OS can do that in a simpler way is as useful as trying
>>> to convince
>>> Windows users to migrate to Linux 'en masse.
>>>
>>>> I'm unclear as to what "amount of state" iptables needs to keep
>>>
>>> After you do something like:
>>>     # iptables -t nat -A POSTROUTING  -p TCP -j MASQUERADE
>>> the Linux kernel module called nf_conntrack starts allocating
>>> data structures to do its job. I'll leave it up to you to see how much
>>> memory gets wasted on each connection. Here's a hint,
>>> though: /proc/net/nf_conntrack
>>>
>>>> that makes imported /net a "complete toss" assuming you can
>>>> magically make /net provide the same functionality netfilter does.
>>>
>>> I have no clue what netfilter does, thus I can't answer your question.
>>>
>>> I thought the original discussion was dedicated to comparing an overhead
>>> that the general
>>> purpose NAT box has with an overhead of a Plan9 box from which /net was
>>> imported.
>>> Since I haven't seen specifics I gave the example of a typical Linux NAT
>>> built using
>>> iptables. That's the area I'm familiar with. If you're interested in
>>> something else -- there
>>> are others on the list who might have an opinion.
>>>
>>>> Also, neither you nor anyone else have addressed the question of
>>>> port forwarding using an imported /net.
>>>
>>> Define port forwarding. And I really mean it: define. Then I can may be
>>> offer a bit of functionality
>>> on Plan9 that would be capable of fitting your definition.
>>>
>>> Thanks,
>>> Roman.
>>>
>>
>>
>>
>>
>>
>>
>

Re: [9fans] Do we have a catalog of 9P servers?

[Eris Discordia]

> I don't quite follow. If by resources you mean process related resources
> than I would agree. My very first comment didn't have anything to do
> with process related resources. And for the TCP related resources I
> maintain that the amount of overhead in Plan9's case is definitely
> comparable to a Linux's case.

The key phrase is: transience versus persistence. From the very beginning
NAT could be implemented using persistent connections but it wasn't because
it had a problem at hand that would not yield to that solution. In fact,
there exist methods of "NATting" with exactly that approach--namely VPN,
PPTP, L2TP, and any "tunneling" application like GNU's httptunnel--but for
obvious reasons they haven't supplanted NAT.

According to the RFC that describes it NAT was adopted primarily to address
the "temporary" scarcity of IP addresses (before IPv6 took on, and it
didn't, how many IPv6 connections do you make outside of your organization
in a day). It was expected that large organizations without Class A ranges
would soon want one--GM had one, why not them?--and nearly all Class A's
were already allocated. NAT was invented so that late-coming organizations
could share _one_ class A range (192.x.x.x and any one of the others).

Every sensible NAT solution must be implemented with that in mind--not that
existing ones have been. Even imagining persistent connections from an
entire Class A network makes one shudder. Needless to say, the wreak of
havoc occurs _long_ before over 16 million hosts need persistent
connections.

The costliness of this type of persistence must be understood with regard
to the fact that most hosts on most organizations' internal networks
rarely, but not never, access the outside world and when they do they only
need some traffic routed to and fro not an entire copy of protocol stack
reserved for them in the gateway's memory. The /net-import doesn't scale
(well or at all?) because a side-effect of generality is lack of
granularity.

--On Saturday, November 15, 2008 9:47 PM -0800 Roman Shaposhnik
<rvs@sun.com> wrote:

> On Nov 15, 2008, at 2:13 PM, Micah Stetson wrote:
>>>> I'm unclear as to what "amount of state" iptables needs to keep
>>>
>>> After you do something like:
>>>   # iptables -t nat -A POSTROUTING  -p TCP -j MASQUERADE
>>> the Linux kernel module called nf_conntrack starts allocating
>>> data structures to do its job. I'll leave it up to you to see how
>>> much
>>> memory gets wasted on each connection. Here's a hint,
>>> though: /proc/net/nf_conntrack
>>
>> I don't think Plan 9 is keeping any less state, is it?
>
> Not really, no. My point was that the amount of state  in a typical
> Linux-based NAT box was quite comparable and thus couldn't
> be used to bash Plan9's approach as being visibly less efficient
> as far as TCP overhead goes.
>
>> Plan 9 does need one extra connection per client and a process (or
>> two?) to do the export.
>
> Yes it does need one extra connection for /net to be imported. Depending
> on the setup that extra connection could be reduced to one per host
> importing the /net. I specifically didn't address the point of extra
> processes running on the GW simply because I agree -- there's a price
> there that Linux doesn't pay (although as I've learned from Bruce
> Inferno has reduced the price for running identical processes quite
> significantly by implementing silent page sharing).
>
>> I think Eris is saying that this makes Plan
>> 9's resource requirements grow with the number of hosts behind the
>> gateway -- not just with the number of connections through it like
>> Linux.
>
> I don't quite follow. If by resources you mean process related resources
> than I would agree. My very first comment didn't have anything to do
> with process related resources. And for the TCP related resources I
> maintain that the amount of overhead in Plan9's case is definitely
> comparable to a Linux's case.
>
> Thanks,
> Roman.
>

Re: [9fans] Do we have a catalog of 9P servers?

[andrey mirtchovski]

> 5. If you need NAT weigh the options of doing it. It may turn out that
> importing /net is the best choice for your application. Or it may turn out
> otherwise. /net has a raison d'etre--regular NAT, too.

If regular NAT hadn't been invented you wouldn't be thinking in terms
of regular NAT, therefore you wouldn't be "needing NAT".

Post hoc ergo propter hoc. (you'll find it under "logical fallacy" on wikipedia)

Re: [9fans] Do we have a catalog of 9P servers?

[Eris Discordia]

> Plan 9 does need one extra connection per client and a process (or
> two?) to do the export.  I think Eris is saying that this makes Plan
> 9's resource requirements grow with the number of hosts behind the
> gateway -- not just with the number of connections through it like
> Linux.  You're right, Eris, but I think you're missing the point:
> importing /net gives you all the features you'd want from NAT (and
> some it doesn't give you) without a single line of code specifically
> written to make it happen.  It isn't an example of how you can handle
> the most clients with the least hardware.  It's an example of how a
> good design can give you features without having to code each one
> individually.

Very well said. This posting summarizes what's been going on:

1. Generality is good.

2. Generality costs.

3. Depending upon circumstances the costs of generality may or may not
entirely overshadow its benefits.

4. The application should determine choices of software. No solution fits
all.

5. If you need NAT weigh the options of doing it. It may turn out that
importing /net is the best choice for your application. Or it may turn out
otherwise. /net has a raison d'etre--regular NAT, too.

--On Saturday, November 15, 2008 2:13 PM -0800 Micah Stetson
<micah@stetsonnet.org> wrote:

>>> I'm unclear as to what "amount of state" iptables needs to keep
>>
>> After you do something like:
>>    # iptables -t nat -A POSTROUTING  -p TCP -j MASQUERADE
>> the Linux kernel module called nf_conntrack starts allocating
>> data structures to do its job. I'll leave it up to you to see how much
>> memory gets wasted on each connection. Here's a hint,
>> though: /proc/net/nf_conntrack
>
> I don't think Plan 9 is keeping any less state, is it?  As far as the
> gateway is concerned, all of the connections from machines importing
> its /net are the same as connections from local programs.  The TCP/IP
> stack has to keep track of those, but Plan 9 doesn't need separate
> connection tracking code for that because it's handled like any other
> connection.
>
> Plan 9 does need one extra connection per client and a process (or
> two?) to do the export.  I think Eris is saying that this makes Plan
> 9's resource requirements grow with the number of hosts behind the
> gateway -- not just with the number of connections through it like
> Linux.  You're right, Eris, but I think you're missing the point:
> importing /net gives you all the features you'd want from NAT (and
> some it doesn't give you) without a single line of code specifically
> written to make it happen.  It isn't an example of how you can handle
> the most clients with the least hardware.  It's an example of how a
> good design can give you features without having to code each one
> individually.
>
> Micah
>

Re: [9fans] Do we have a catalog of 9P servers?

[Eris Discordia]

> I believe our conversation stops right here. Should you
> ever consider restarting it -- a simple apology for
> being an asshole would do the trick.

If you look at the context you'll see this wasn't an insult at all: I wrote
"out of the field with respect to [something]." That means you seem to now
know about [something], and that's more or less correct because you've been
using netfilter but not knowing at all about it.

Anyhow, if you feel offended I think an apology would be proper. I am sorry.

--On Saturday, November 15, 2008 9:27 PM -0800 Roman Shaposhnik
<rvs@sun.com> wrote:

> On Nov 15, 2008, at 2:07 PM, Eris Discordia wrote:
>>> What field?
>>
>> Out of the field := clueless
>
> I believe our conversation stops right here. Should you
> ever consider restarting it -- a simple apology for
> being an asshole would do the trick.
>
> Thanks,
> Roman.
>

Re: [9fans] Do we have a catalog of 9P servers?

[Roman Shaposhnik]

On Nov 15, 2008, at 2:13 PM, Micah Stetson wrote:
>>> I'm unclear as to what "amount of state" iptables needs to keep
>>
>> After you do something like:
>>   # iptables -t nat -A POSTROUTING  -p TCP -j MASQUERADE
>> the Linux kernel module called nf_conntrack starts allocating
>> data structures to do its job. I'll leave it up to you to see how
>> much
>> memory gets wasted on each connection. Here's a hint,
>> though: /proc/net/nf_conntrack
>
> I don't think Plan 9 is keeping any less state, is it?

Not really, no. My point was that the amount of state  in a typical
Linux-based NAT box was quite comparable and thus couldn't
be used to bash Plan9's approach as being visibly less efficient
as far as TCP overhead goes.

> Plan 9 does need one extra connection per client and a process (or
> two?) to do the export.

Yes it does need one extra connection for /net to be imported. Depending
on the setup that extra connection could be reduced to one per host
importing the /net. I specifically didn't address the point of extra
processes running on the GW simply because I agree -- there's a price
there that Linux doesn't pay (although as I've learned from Bruce
Inferno has reduced the price for running identical processes quite
significantly by implementing silent page sharing).

> I think Eris is saying that this makes Plan
> 9's resource requirements grow with the number of hosts behind the
> gateway -- not just with the number of connections through it like
> Linux.

I don't quite follow. If by resources you mean process related resources
than I would agree. My very first comment didn't have anything to do
with process related resources. And for the TCP related resources I
maintain that the amount of overhead in Plan9's case is definitely
comparable to a Linux's case.

Thanks,
Roman.

Re: [9fans] Do we have a catalog of 9P servers?

[Roman Shaposhnik]

On Nov 15, 2008, at 2:07 PM, Eris Discordia wrote:
>> What field?
>
> Out of the field := clueless

I believe our conversation stops right here. Should you
ever consider restarting it -- a simple apology for
being an asshole would do the trick.

Thanks,
Roman.

Re: [9fans] Do we have a catalog of 9P servers?

[Iruata Souza]

On Sat, Nov 15, 2008 at 9:21 AM, Eris Discordia
<eris.discordia@gmail.com> wrote:
> Also, neither you nor anyone else have addressed the question of port
> forwarding using an imported /net.

I love science.

iru

Re: [9fans] Do we have a catalog of 9P servers?

[sqweek]

On Sat, Nov 15, 2008 at 2:29 AM, Eris Discordia
<eris.discordia@gmail.com> wrote:
> I don't see how port forwarding is possible at all with an
> imported /net.

 Because your mind is set - as far as you're concerned, NAT is how things work.
 With /net, the concept doesn't exist. The http server just imports
/net and listens on port 80. No need to touch the gateway's
configuration, no need to invent new protocols for dynamic port
allocations (UPNP)...
 And lets not forget, plan 9's approach is not specific to networking.
It's a property of 9p's network transparency combined with the
"resources as files" abstraction. Lets see how well NAT serves when
you want to import the graphics device from your gateway ;)

>>  More to the point, I'm yet to see a richer set of abstractions come
>> out of another system.
>
> As for an example of a richer set of abstractions take Microsoft .NET
> framework. There are so many abstractions and layers of abstraction you
> don't know where to begin.

 Well, there's a reason I used the word "richer". I probably wouldn't
classify a large set of useless/redundant abstractions as richer than
a small set of orthogonal abstractions. This isn't a criticism of .NET
mind, I've never touched the thing.
-sqweek

Re: [9fans] Do we have a catalog of 9P servers?

[Felipe Bichued]

as usual, plan9 lets you combine simple commands to provide all sorts
of interesting functionality. on my plan9 gateway i often have to do
something like:

aux/listen1 -tv tcp!*!22 /bin/aux/trampoline tcp!$linux!22

there you have it, port forwarding without the need to reset all your
connections (my d-link router does it).

On Sat, Nov 15, 2008 at 8:07 PM, Eris Discordia
<eris.discordia@gmail.com> wrote:
>> It would be helpful if you can quote exactly the part on which you are
>> requesting
>> my opinion.
>
> This part:
>
>> It actually does qualify. I believe (though I could be wrong) state
>> information and communication buffers are the biggest memory spending for
>> network operations.
>>
>> There _could_ be a trade-off between the transient NAT with its
>> processing power toll and the persistent /net-import with its memory
>> cost. However, systems like FreeBSD pre-allocate and always keep a number
>> of network buffers so the processing power toll for transience almost
>> vanishes if the kernel is fine-tuned for its load. By contrast, on a
>> large network /net-import strategy could make a "powerful" gateway
>> unavoidable because every machine on the network will need a session with
>> the gateway even if it only rarely communicates with the outside world,
>> unless you implement an uglier-than-NAT client-side dial-on-demand.
>
> And this:
>
>> There is a huge difference. Almost as much difference there is between
>> NAT and RSVP.
>
> Where importing /net is compared to RSVP because it uses a persistent
> application layer overlay to do a job that is usually done with transient
> connections. In case of RSVP there's a motive to do that, in case of NAT,
> well, NAT solutions already exist and work pretty well--I've actually been
> saying that /net-imported may be useful (!= usable) for some applications I
> don't know about but very probably not for NAT.
>
>> What field?
>
> Out of the field := clueless, a soccer player who follows the ball outside
> the field
>
>> I am only familiar with Linux implementation.
>
> Which is only a small subset of iptables, right?
>
>> Yes. And that's the NAT that *I* and a million Linux lemming out there
>> are familiar with.
>
> Not right. As late as SuSE v9.0 people used the much lighter and less
> sophisticated "masquerading" ipmasq which didn't involve iptables (beginning
> with v10's iptables became the default). It was the Linux equivalent of the
> sort of half-assed "NAT" that importing /net will give you. Easy but
> incomplete.
>
> In case of iptables as I pointed out before you have at your disposal a very
> sophisticated tool--that you put the tool to uses it is too big for is
> mostly your fault. There are many other Linux NAT solutions that do NAT
> proper.
>
>> data structures to do its job. I'll leave it up to you to see how much
>> memory gets wasted on each connection.
>
> Do you claim you have compared that to doing the same thing on Plan 9? If X
> bytes of memory get used up for a task you don't call it a "waste of memory"
> unless the task could be done with (X - x) bytes being used up.
>
>> I have no clue what netfilter does, thus I can't answer your question.
>
> Netfilter (or NetFilter) is the larger framework iptables is part of. It
> provides every conceivable capability at network layer--everything,
> including NAT.
>
>> I thought the original discussion was dedicated to comparing an overhead
>> that the general purpose NAT box has with an overhead of a Plan9 box from
>> which /net was imported. Since I haven't seen specifics I gave the
>> example of a typical Linux NAT built using iptables. That's the area I'm
>> familiar with.
>
> It's OK. But you haven't made any comparison of the overhead, yet.
>
>> Define port forwarding. And I really mean it: define. Then I can may be
>> offer a bit of  functionality on Plan9 that would be capable of fitting
>> your definition.
>
> The traditional definition of NAT is (of course) here:
> <http://asg.andrew.cmu.edu/rfc/rfc1631.html>
>
> Here's a definition of port forwarding:
> <http://hasenstein.com/linux-ip-nat/diplom/node7.html#SECTION00071300000000000000>
>
> However I give an operational definition which involves what is nowadays
> _expected_ from any NAT solution:
>
> A packet arrives at the gateway. Behind the gateway there is a machine
> dedicated to serving FTP and another to HTTP, or two machines both dedicated
> to serving HTTP that are meant to balance each other's loads. You want the
> gateway to decide on how to rewrite the packet so that inbound traffic to
> port 21 goes to the FTP machine and inbound traffic to port 80 goes to the
> HTTP machine, or the inbound traffic in one session goes to one HTTP machine
> and the inbound traffic in another session goes to the other HTTP machine.
> To add to the hassle you may also want--for security reasons--to run your
> server software on other ports than 21 and 80, and the gateway needs to
> rewrite the packet so that it reaches the right endpoint (IP:port, in this
> case). The process shall be transparent to the internal and external
> networks.
>
> How should the two imported /net's on the two machines on the internal
> network rewrite packets without becoming NAT re-invented?
>
> --On Saturday, November 15, 2008 12:01 PM -0800 Roman Shaposhnik
> <rvs@sun.com> wrote:
>
>> On Nov 15, 2008, at 3:21 AM, Eris Discordia wrote:
>>>>
>>>> Exactly! An idle TCP connection costs you nothing except the state
>>>> that
>>>
>>> Would you mind reading my response, too, and then informing me of
>>> your opinion?
>>
>> It would be helpful if you can quote exactly the part on which you are
>> requesting
>> my opinion.
>>
>>>> Not only that, but if you look at the amount of state something like
>>>> iptables on Linux needs to keep in order to provide NAT
>>>> capabilities it
>>>> becomes a complete toss.
>>>
>>> You seem to be extremely out of the field
>>
>> What field?
>>
>>> with respect to what iptables does and how normal NAT is implemented
>>> on a *BSD system (which was my example).
>>
>> I have no knowledge of how NAT is implemented on a *BSD system and thus
>> I can not comment. I am only familiar with Linux implementation. Thus if
>> that's
>> not what you're interested in discussing -- lets stop right now.
>>
>>> Iptables provides very sophisticated routing and filtering
>>> capabilities. It's used as a back-end for stateful inspection,
>>> packet rewriting, logging, routing, intrusion detection, and
>>> firewalling applications. That's NAT... plus one million other
>>> applications.
>>
>> Yes. And that's the NAT that *I* and a million Linux lemming out there
>> are familiar with.
>> Arguing that your OS can do that in a simpler way is as useful as trying
>> to convince
>> Windows users to migrate to Linux 'en masse.
>>
>>> I'm unclear as to what "amount of state" iptables needs to keep
>>
>> After you do something like:
>>     # iptables -t nat -A POSTROUTING  -p TCP -j MASQUERADE
>> the Linux kernel module called nf_conntrack starts allocating
>> data structures to do its job. I'll leave it up to you to see how much
>> memory gets wasted on each connection. Here's a hint,
>> though: /proc/net/nf_conntrack
>>
>>> that makes imported /net a "complete toss" assuming you can
>>> magically make /net provide the same functionality netfilter does.
>>
>> I have no clue what netfilter does, thus I can't answer your question.
>>
>> I thought the original discussion was dedicated to comparing an overhead
>> that the general
>> purpose NAT box has with an overhead of a Plan9 box from which /net was
>> imported.
>> Since I haven't seen specifics I gave the example of a typical Linux NAT
>> built using
>> iptables. That's the area I'm familiar with. If you're interested in
>> something else -- there
>> are others on the list who might have an opinion.
>>
>>> Also, neither you nor anyone else have addressed the question of
>>> port forwarding using an imported /net.
>>
>> Define port forwarding. And I really mean it: define. Then I can may be
>> offer a bit of functionality
>> on Plan9 that would be capable of fitting your definition.
>>
>> Thanks,
>> Roman.
>>
>
>
>
>
>
>

Re: [9fans] Do we have a catalog of 9P servers?

[Micah Stetson]

>> I'm unclear as to what "amount of state" iptables needs to keep
>
> After you do something like:
>    # iptables -t nat -A POSTROUTING  -p TCP -j MASQUERADE
> the Linux kernel module called nf_conntrack starts allocating
> data structures to do its job. I'll leave it up to you to see how much
> memory gets wasted on each connection. Here's a hint,
> though: /proc/net/nf_conntrack

I don't think Plan 9 is keeping any less state, is it?  As far as the
gateway is concerned, all of the connections from machines importing
its /net are the same as connections from local programs.  The TCP/IP
stack has to keep track of those, but Plan 9 doesn't need separate
connection tracking code for that because it's handled like any other
connection.

Plan 9 does need one extra connection per client and a process (or
two?) to do the export.  I think Eris is saying that this makes Plan
9's resource requirements grow with the number of hosts behind the
gateway -- not just with the number of connections through it like
Linux.  You're right, Eris, but I think you're missing the point:
importing /net gives you all the features you'd want from NAT (and
some it doesn't give you) without a single line of code specifically
written to make it happen.  It isn't an example of how you can handle
the most clients with the least hardware.  It's an example of how a
good design can give you features without having to code each one
individually.

Micah

Re: [9fans] Do we have a catalog of 9P servers?

[Eris Discordia]

> It would be helpful if you can quote exactly the part on which you are
> requesting
> my opinion.

This part:

> It actually does qualify. I believe (though I could be wrong) state
> information and communication buffers are the biggest memory spending for
> network operations.
>
> There _could_ be a trade-off between the transient NAT with its
> processing power toll and the persistent /net-import with its memory
> cost. However, systems like FreeBSD pre-allocate and always keep a number
> of network buffers so the processing power toll for transience almost
> vanishes if the kernel is fine-tuned for its load. By contrast, on a
> large network /net-import strategy could make a "powerful" gateway
> unavoidable because every machine on the network will need a session with
> the gateway even if it only rarely communicates with the outside world,
> unless you implement an uglier-than-NAT client-side dial-on-demand.

And this:

> There is a huge difference. Almost as much difference there is between
> NAT and RSVP.

Where importing /net is compared to RSVP because it uses a persistent
application layer overlay to do a job that is usually done with transient
connections. In case of RSVP there's a motive to do that, in case of NAT,
well, NAT solutions already exist and work pretty well--I've actually been
saying that /net-imported may be useful (!= usable) for some applications I
don't know about but very probably not for NAT.

> What field?

Out of the field := clueless, a soccer player who follows the ball outside
the field

> I am only familiar with Linux implementation.

Which is only a small subset of iptables, right?

> Yes. And that's the NAT that *I* and a million Linux lemming out there
> are familiar with.

Not right. As late as SuSE v9.0 people used the much lighter and less
sophisticated "masquerading" ipmasq which didn't involve iptables
(beginning with v10's iptables became the default). It was the Linux
equivalent of the sort of half-assed "NAT" that importing /net will give
you. Easy but incomplete.

In case of iptables as I pointed out before you have at your disposal a
very sophisticated tool--that you put the tool to uses it is too big for is
mostly your fault. There are many other Linux NAT solutions that do NAT
proper.

> data structures to do its job. I'll leave it up to you to see how much
> memory gets wasted on each connection.

Do you claim you have compared that to doing the same thing on Plan 9? If X
bytes of memory get used up for a task you don't call it a "waste of
memory" unless the task could be done with (X - x) bytes being used up.

> I have no clue what netfilter does, thus I can't answer your question.

Netfilter (or NetFilter) is the larger framework iptables is part of. It
provides every conceivable capability at network layer--everything,
including NAT.

> I thought the original discussion was dedicated to comparing an overhead
> that the general purpose NAT box has with an overhead of a Plan9 box from
> which /net was imported. Since I haven't seen specifics I gave the
> example of a typical Linux NAT built using iptables. That's the area I'm
> familiar with.

It's OK. But you haven't made any comparison of the overhead, yet.

> Define port forwarding. And I really mean it: define. Then I can may be
> offer a bit of  functionality on Plan9 that would be capable of fitting
> your definition.

The traditional definition of NAT is (of course) here:
<http://asg.andrew.cmu.edu/rfc/rfc1631.html>

Here's a definition of port forwarding:
<http://hasenstein.com/linux-ip-nat/diplom/node7.html#SECTION00071300000000000000>

However I give an operational definition which involves what is nowadays
_expected_ from any NAT solution:

A packet arrives at the gateway. Behind the gateway there is a machine
dedicated to serving FTP and another to HTTP, or two machines both
dedicated to serving HTTP that are meant to balance each other's loads. You
want the gateway to decide on how to rewrite the packet so that inbound
traffic to port 21 goes to the FTP machine and inbound traffic to port 80
goes to the HTTP machine, or the inbound traffic in one session goes to one
HTTP machine and the inbound traffic in another session goes to the other
HTTP machine. To add to the hassle you may also want--for security
reasons--to run your server software on other ports than 21 and 80, and the
gateway needs to rewrite the packet so that it reaches the right endpoint
(IP:port, in this case). The process shall be transparent to the internal
and external networks.

How should the two imported /net's on the two machines on the internal
network rewrite packets without becoming NAT re-invented?

--On Saturday, November 15, 2008 12:01 PM -0800 Roman Shaposhnik
<rvs@sun.com> wrote:

> On Nov 15, 2008, at 3:21 AM, Eris Discordia wrote:
>>> Exactly! An idle TCP connection costs you nothing except the state
>>> that
>>
>> Would you mind reading my response, too, and then informing me of
>> your opinion?
>
> It would be helpful if you can quote exactly the part on which you are
> requesting
> my opinion.
>
>>> Not only that, but if you look at the amount of state something like
>>> iptables on Linux needs to keep in order to provide NAT
>>> capabilities it
>>> becomes a complete toss.
>>
>> You seem to be extremely out of the field
>
> What field?
>
>> with respect to what iptables does and how normal NAT is implemented
>> on a *BSD system (which was my example).
>
> I have no knowledge of how NAT is implemented on a *BSD system and thus
> I can not comment. I am only familiar with Linux implementation. Thus if
> that's
> not what you're interested in discussing -- lets stop right now.
>
>> Iptables provides very sophisticated routing and filtering
>> capabilities. It's used as a back-end for stateful inspection,
>> packet rewriting, logging, routing, intrusion detection, and
>> firewalling applications. That's NAT... plus one million other
>> applications.
>
> Yes. And that's the NAT that *I* and a million Linux lemming out there
> are familiar with.
> Arguing that your OS can do that in a simpler way is as useful as trying
> to convince
> Windows users to migrate to Linux 'en masse.
>
>> I'm unclear as to what "amount of state" iptables needs to keep
>
> After you do something like:
>      # iptables -t nat -A POSTROUTING  -p TCP -j MASQUERADE
> the Linux kernel module called nf_conntrack starts allocating
> data structures to do its job. I'll leave it up to you to see how much
> memory gets wasted on each connection. Here's a hint,
> though: /proc/net/nf_conntrack
>
>> that makes imported /net a "complete toss" assuming you can
>> magically make /net provide the same functionality netfilter does.
>
> I have no clue what netfilter does, thus I can't answer your question.
>
> I thought the original discussion was dedicated to comparing an overhead
> that the general
> purpose NAT box has with an overhead of a Plan9 box from which /net was
> imported.
> Since I haven't seen specifics I gave the example of a typical Linux NAT
> built using
> iptables. That's the area I'm familiar with. If you're interested in
> something else -- there
> are others on the list who might have an opinion.
>
>> Also, neither you nor anyone else have addressed the question of
>> port forwarding using an imported /net.
>
> Define port forwarding. And I really mean it: define. Then I can may be
> offer a bit of functionality
> on Plan9 that would be capable of fitting your definition.
>
> Thanks,
> Roman.
>

Re: [9fans] Do we have a catalog of 9P servers?

[Roman Shaposhnik]

On Nov 15, 2008, at 3:21 AM, Eris Discordia wrote:
>> Exactly! An idle TCP connection costs you nothing except the state
>> that
>
> Would you mind reading my response, too, and then informing me of
> your opinion?

It would be helpful if you can quote exactly the part on which you are
requesting
my opinion.

>> Not only that, but if you look at the amount of state something like
>> iptables on Linux needs to keep in order to provide NAT
>> capabilities it
>> becomes a complete toss.
>
> You seem to be extremely out of the field

What field?

> with respect to what iptables does and how normal NAT is implemented
> on a *BSD system (which was my example).

I have no knowledge of how NAT is implemented on a *BSD system and thus
I can not comment. I am only familiar with Linux implementation. Thus
if that's
not what you're interested in discussing -- lets stop right now.

> Iptables provides very sophisticated routing and filtering
> capabilities. It's used as a back-end for stateful inspection,
> packet rewriting, logging, routing, intrusion detection, and
> firewalling applications. That's NAT... plus one million other
> applications.

Yes. And that's the NAT that *I* and a million Linux lemming out there
are familiar with.
Arguing that your OS can do that in a simpler way is as useful as
trying to convince
Windows users to migrate to Linux 'en masse.

> I'm unclear as to what "amount of state" iptables needs to keep

After you do something like:
     # iptables -t nat -A POSTROUTING  -p TCP -j MASQUERADE
the Linux kernel module called nf_conntrack starts allocating
data structures to do its job. I'll leave it up to you to see how much
memory gets wasted on each connection. Here's a hint,
though: /proc/net/nf_conntrack

> that makes imported /net a "complete toss" assuming you can
> magically make /net provide the same functionality netfilter does.

I have no clue what netfilter does, thus I can't answer your question.

I thought the original discussion was dedicated to comparing an
overhead that the general
purpose NAT box has with an overhead of a Plan9 box from which /net
was imported.
Since I haven't seen specifics I gave the example of a typical Linux
NAT built using
iptables. That's the area I'm familiar with. If you're interested in
something else -- there
are others on the list who might have an opinion.

> Also, neither you nor anyone else have addressed the question of
> port forwarding using an imported /net.

Define port forwarding. And I really mean it: define. Then I can may
be offer a bit of functionality
on Plan9 that would be capable of fitting your definition.

Thanks,
Roman.

Re: [9fans] Do we have a catalog of 9P servers?

[hiro]

I think if plan9 was the real standard /net, ip, dns and of course nat
would not matter at all.

Imagine i.e. bind '#wan' for putting the world in your namespace. The
device would take care of the communication to the next node and you
would not even have to mind which protocol to use.
Your provider would just export a hierarchical file tree which you
could use to access all other devices connected to that network.

Re: [9fans] Do we have a catalog of 9P servers?

[Gabriel Diaz Lopez de la Llave]

hello

if the point of port forward is to access a service behind a firewall
you can do something like:

inside% import outside /net /net
inside% start_service

and the servide will listen on the /net of the outside machine.

that's just a "simple" example.

slds.

gabi


El 15/11/20
>
> Also, neither you nor anyone else have addressed the question of
> port forwarding using an imported /net. Now I'm curious: do any of
> you 9fans have an internal network behind a gateway that runs Plan
> 9? In case you do, I'll be grateful if read about the configuration
> of your network(s).

Re: [9fans] Do we have a catalog of 9P servers?

[Sergey Zhilkin]

[-- Attachment #1: Type: text/plain, Size: 503 bytes --]

> Also, neither you nor anyone else have addressed the question of port
> forwarding using an imported /net. Now I'm curious: do any of you 9fans have
> an internal network behind a gateway that runs Plan 9? In case you do, I'll
> be grateful if read about the configuration of your network(s).
>
>
> May be some of Bell-Labs people can talk about Plan9 :)

I'm using Inferno on my gateway, as proxy to Internet. It simply mount
remote /net (served by listen) to /net.alt

-- 
С Уважением
Жилкин Сергей

[-- Attachment #2: Type: text/html, Size: 783 bytes --]

Re: [9fans] Do we have a catalog of 9P servers?

[Eris Discordia]

> Exactly! An idle TCP connection costs you nothing except the state that

Would you mind reading my response, too, and then informing me of your
opinion?

> Not only that, but if you look at the amount of state something like
> iptables on Linux needs to keep in order to provide NAT capabilities it
> becomes a complete toss.

You seem to be extremely out of the field with respect to what iptables
does and how normal NAT is implemented on a *BSD system (which was my
example). FreeBSD doesn't have iptables at all. Stateful packet filtering
is done by the _optional_ pf loadable kernel module (kld, in *BSD-speak)
specifically created to meet OpenBSD's security requirements and NAT is
done by natd, a tiny daemon. Simpler firewalls are often implemented using
ipfw (now ipfw2).

Iptables provides very sophisticated routing and filtering capabilities.
It's used as a back-end for stateful inspection, packet rewriting, logging,
routing, intrusion detection, and firewalling applications. That's NAT...
plus one million other applications. I'm unclear as to what "amount of
state" iptables needs to keep that makes imported /net a "complete toss"
assuming you can magically make /net provide the same functionality
netfilter does.

Also, neither you nor anyone else have addressed the question of port
forwarding using an imported /net. Now I'm curious: do any of you 9fans
have an internal network behind a gateway that runs Plan 9? In case you do,
I'll be grateful if read about the configuration of your network(s).

--On Friday, November 14, 2008 8:12 PM -0800 Roman Shaposhnik <rvs@sun.com>
wrote:

> On Nov 13, 2008, at 8:55 AM, sqweek wrote:
>>> I understand that if you import a gateway's /net on each computer
>>> in a
>>> rather large internal network you will be consuming a huge amount
>>> of mostly
>>> redundant resources on the gateway. My impression is that each
>>> imported
>>> instance of /net requires a persistent session to be established
>>> between the
>>> gateway and the host on the internal network. NAT in comparison is
>>> naturally
>>> transient.
>>
>> I'm not sure there's as much difference as you make out to be. On the
>> one hand, you have a NAT gateway listening for tcp/ip packets, and on
>> the other hand you have an open tcp/ip connection and a file server
>> waiting for 9p requests. It's not as though 9p is wasting bandwidth
>> chatting away while there's no activity, so the only cost is the
>> tcp/ip connection to each client on the network, which shouldn't
>> qualify as a huge amount of resources.
>
> Exactly! An idle TCP connection costs you nothing except the state that
> is kept by the kernels of the two connected end points. No packets
> ever get generated unless there's an application level payload that
> needs to be transferred. Not only that, but if you look at the amount
> of state something like iptables on Linux needs to keep in order
> to provide NAT capabilities it becomes a complete toss. With Plan9
> as a gateway you're not paying a visible extra premium.
>
> Thanks,
> Roman.
>

Re: [9fans] Do we have a catalog of 9P servers?

[Roman Shaposhnik]

On Nov 13, 2008, at 8:55 AM, sqweek wrote:
>> I understand that if you import a gateway's /net on each computer
>> in a
>> rather large internal network you will be consuming a huge amount
>> of mostly
>> redundant resources on the gateway. My impression is that each
>> imported
>> instance of /net requires a persistent session to be established
>> between the
>> gateway and the host on the internal network. NAT in comparison is
>> naturally
>> transient.
>
> I'm not sure there's as much difference as you make out to be. On the
> one hand, you have a NAT gateway listening for tcp/ip packets, and on
> the other hand you have an open tcp/ip connection and a file server
> waiting for 9p requests. It's not as though 9p is wasting bandwidth
> chatting away while there's no activity, so the only cost is the
> tcp/ip connection to each client on the network, which shouldn't
> qualify as a huge amount of resources.

Exactly! An idle TCP connection costs you nothing except the state that
is kept by the kernels of the two connected end points. No packets
ever get generated unless there's an application level payload that
needs to be transferred. Not only that, but if you look at the amount
of state something like iptables on Linux needs to keep in order
to provide NAT capabilities it becomes a complete toss. With Plan9
as a gateway you're not paying a visible extra premium.

Thanks,
Roman.

Re: [9fans] Do we have a catalog of 9P servers?

[erik quanstrom]

>> That would break the protocol stack. 9P is an application layer protocol (or
>> so I understand). It should _never_ see, or worse rewrite, network layer
>> data units. If by "a fileserver on top of that" you actually mean a file
>> server under that then you simply are re-inventing NAT.
>
> Putting a file server over /net which selectively allows access to the
> underlying /net. There it can monitor data at the application (not
> transport) level.

yes.  it's worth pointing out that networking in plan 9
is all done with 9p to network devices.  (or isomorphic
chan functions)  in fact the ip stack has been in user
space.  also, since dial takes care of connection-making,
one can replace ip with something completely different
without changing any applications.  (i did some experiments
with a non-ip stack earlier this year.  no applications were
harmed.  or even recompiled.)  mounting a proxy server
that fiddles packets does work.

however, none of this will help bring nat to a windows box.
windows boxes are well-known for not being able to import
/net.

- erik

Re: [9fans] Do we have a catalog of 9P servers?

[Tom Lieber]

On Fri, Nov 14, 2008 at 12:29 PM, Eris Discordia
<eris.discordia@gmail.com> wrote:
>>  What makes /net tick depends on what you export on /net. The kernel
>> serves your basic /net, yes, but there's nothing to stop you having a
>> userspace file server on top of that to do whatever filtering you
>> like.
>
> That would break the protocol stack. 9P is an application layer protocol (or
> so I understand). It should _never_ see, or worse rewrite, network layer
> data units. If by "a fileserver on top of that" you actually mean a file
> server under that then you simply are re-inventing NAT.

Putting a file server over /net which selectively allows access to the
underlying /net. There it can monitor data at the application (not
transport) level.

--
Tom Lieber
http://AllTom.com/

Re: [9fans] Do we have a catalog of 9P servers?

[Eris Discordia]

>  Welcome, but don't mistake me for someone having the background and
> experience with plan 9 to comment with any sort of authority.

I won't ;-)

>  I'm not sure there's as much difference as you make out to be.

There is a huge difference. Almost as much difference there is between NAT
and RSVP.

> the other hand you have an open tcp/ip connection and a file server
> waiting for 9p requests. It's not as though 9p is wasting bandwidth
> chatting away while there's no activity, so the only cost is the
> tcp/ip connection to each client on the network, which shouldn't
> qualify as a huge amount of resources.

It actually does qualify. I believe (though I could be wrong) state
information and communication buffers are the biggest memory spending for
network operations.

There _could_ be a trade-off between the transient NAT with its processing
power toll and the persistent /net-import with its memory cost. However,
systems like FreeBSD pre-allocate and always keep a number of network
buffers so the processing power toll for transience almost vanishes if the
kernel is fine-tuned for its load. By contrast, on a large network
/net-import strategy could make a "powerful" gateway unavoidable because
every machine on the network will need a session with the gateway even if
it only rarely communicates with the outside world, unless you implement an
uglier-than-NAT client-side dial-on-demand.

> at a cost (the sort of cost that are hard to recognise as costs
> because we're so used to them. every time i remind myself that /net
> removes the need for port forwarding i get shivers).

I don't know about implementing NAT but configuring most NAT
implementations, e.g. FreeBSD's natd(8) or the Linux-based one in my
router, is very easy. I don't see how port forwarding is possible at all
with an imported /net. Assuming /net represents an underlying IP network,
how is one supposed to tell /net to redirect inbound traffic to either
machine X or machine Y depending on the port the traffic is destined for?

>  What makes /net tick depends on what you export on /net. The kernel
> serves your basic /net, yes, but there's nothing to stop you having a
> userspace file server on top of that to do whatever filtering you
> like.

That would break the protocol stack. 9P is an application layer protocol
(or so I understand). It should _never_ see, or worse rewrite, network
layer data units. If by "a fileserver on top of that" you actually mean a
file server under that then you simply are re-inventing NAT.

>  UNIX seems to have coped with changing constraints by bolting more
> and more junk on the side...

Are there other ways of doing it?

>  *ahem* Plan 9 seems to have more of a tendency to adapt. I'm sure the
> adoption of utf-8 and the switch from 9p to 9p2000 aren't the only
> examples of system-wide changes.

Or is it because Plan 9 has much less inertia because of a smaller user
base?

>  More to the point, I'm yet to see a richer set of abstractions come
> out of another system. Private namespaces, resources as files... they
> might be ancient ideas, but everyone else is still playing catch up.
> They might not be the ultimate ideal, but if we push them far enough
> we might learn something.

Everyone else isn't playing catch up. Most others seem to watch the
development here, pick what is to their liking, and do it their own way.

As for an example of a richer set of abstractions take Microsoft .NET
framework. There are so many abstractions and layers of abstraction you
don't know where to begin. Every thinkable way of representing the same old
thing, i.e. a computer's resources, is in there. That's one reason I don't
like programming in .NET. I doubt any of these abstractions, except the
most rudimentary ones, actually ease development.

>  'scuse me if I'm silent for awhile, I've been spending too much time
> pondering and it's starting to affect my work. *9fans breathes a sigh
> of relief*

Take your time. You never promised to tutor me through and through ;-)

(I don't see why 9fans should be annoyed by a few emails).

--On Friday, November 14, 2008 1:55 AM +0900 sqweek <sqweek@gmail.com>
wrote:

> On Wed, Nov 12, 2008 at 10:23 PM, Eris Discordia
> <eris.discordia@gmail.com> wrote:
>> First off, thank you so much, sqweek. When someone on 9fans tries to put
>> things in terms of basic abstract ideas instead of technical ones I
>> really appreciate it--I actually learn something.
>
>  Welcome, but don't mistake me for someone having the background and
> experience with plan 9 to comment with any sort of authority.
>
>>>  It doesn't stop at 9p:
>>> * plan 9 doesn't need to bother with NAT, since you can just
>>> import /net from your gateway.
>>
>> I understand that if you import a gateway's /net on each computer in a
>> rather large internal network you will be consuming a huge amount of
>> mostly redundant resources on the gateway. My impression is that each
>> imported instance of /net requires a persistent session to be
>> established between the gateway and the host on the internal network.
>> NAT in comparison is naturally transient.
>
>  I'm not sure there's as much difference as you make out to be. On the
> one hand, you have a NAT gateway listening for tcp/ip packets, and on
> the other hand you have an open tcp/ip connection and a file server
> waiting for 9p requests. It's not as though 9p is wasting bandwidth
> chatting away while there's no activity, so the only cost is the
> tcp/ip connection to each client on the network, which shouldn't
> qualify as a huge amount of resources.
>  If it does, you have the same problem with any service you want to
> provide to the whole network, so the techniques you use to solve it
> there can be applied to the gateway. So *maybe* you could get away
> with a weaker machine serving NAT instead of /net, but it would come
> at a cost (the sort of cost that are hard to recognise as costs
> because we're so used to them. every time i remind myself that /net
> removes the need for port forwarding i get shivers).
>
>> With an imported /net since there's no packet rewriting implemented
>> on the network layer (e.g. IP) and because the "redirection" occurs in
>> the application layer there's no chance of capturing spoofed packets
>> except with hacking what makes /net tick (the kernel?).
>
>  What makes /net tick depends on what you export on /net. The kernel
> serves your basic /net, yes, but there's nothing to stop you having a
> userspace file server on top of that to do whatever filtering you
> like.
>
>> Does that mean a new design "from scratch" is
>> always bound to be better suited to current constraints?
>
>  It very often is in my experience. But it's also very easy to leave
> something important out of "current constraints" when designing from
> scratch, or ignore the lessons learned by the previous iteration.
>
>> Also, if you think
>> UNIX and clones are flawed today because of their history and origins
>> what makes you think Plan 9 doesn't suffer from "diseases" it contracted
>> from its original birthplace? I can't forget the Jukebox example.
>
>  UNIX seems to have coped with changing constraints by bolting more
> and more junk on the side...
> * "Whoa, here comes a network, we're going to need some more syscalls!"
> * "Non-english languages? Better rig up some new codepages!"
>
>> As pointed out previously on this same thread,
>> in jest though, the Linux community always finds a way to exhaust a
>> (consistent) model's options, and then come the extensions and "hacks."
>> That, however, is not the Linux community's fault--it's the nature of an
>> advancing science and technology that always welcomes not only new users
>> but also new types of users and entirely novel use cases.
>
>  It's a matter of approach. Linux takes what I like to call the cookie
> monster approach, which is MORE MORE MORE. More syscalls, more ioctls,
> more program flags, more layers of indirection, a constant enumeration
> of every use case. Rarely is there a pause to check whether several
> use cases can be coalesced into a single more general way of doing
> things, or to consider whether the feature could be better implemented
> elsewhere in the system. This has a tendency to disrupt conceptual
> integrity, which hastens the above process.
>
>  These days the dearth of developers make it difficult to distinguish
> any daring developments on plan 9, but during the decades a different
> derivation has been demonstrated.
>  *ahem* Plan 9 seems to have more of a tendency to adapt. I'm sure the
> adoption of utf-8 and the switch from 9p to 9p2000 aren't the only
> examples of system-wide changes. The early labs history is rife with
> stories of folk joining and trying out all sorts of new stuff. The
> system feels like it has a more experimental nature - things that
> don't work get dropped and lessons are learned from mistakes. Which is
> sadly somewhat rare in software.
>
>  More to the point, I'm yet to see a richer set of abstractions come
> out of another system. Private namespaces, resources as files... they
> might be ancient ideas, but everyone else is still playing catch up.
> They might not be the ultimate ideal, but if we push them far enough
> we might learn something.
>
>>> The problem is it forces the server and client to synchronise on every
>>> read/write syscall, which results in terrible bandwidth utilisation.
>>
>> An example of a disease contracted from a system's birthplace.
>
>  You're pretty quick to to describe it as a disease. Plan 9 learned a
> lot from the mistakes of UNIX, but the base syscalls are something
> that stuck. I wouldn't expect that to happen without good reason.
>
>  'scuse me if I'm silent for awhile, I've been spending too much time
> pondering and it's starting to affect my work. *9fans breathes a sigh
> of relief*
> -sqweek
>

Re: [9fans] Do we have a catalog of 9P servers?

[erik quanstrom]

> > Hiding the details of the underlying resources is one of the
> > functions/features of the OS, isn't it?
>
> Bjarne Stroustrup likes to call that "data abstraction and encapsulation;"
> in a different context. But the essence of it is the same. Operational
> details have to be "hidden," functional ones not. You don't want your OS to
> "abstract" your latest and best hardware's capabilities by dumbing it down
> to 80286. You also don't want your OS to generalize at the cost of fitting
> all sorts of resources into one model--it can't be done.

on the other hand, stroustup's ideas tend to make modern computers
compile as slowlyas a 80286.

- erik

Re: [9fans] Do we have a catalog of 9P servers?

[Eris Discordia]

> Hiding the details of the underlying resources is one of the
> functions/features of the OS, isn't it?

Bjarne Stroustrup likes to call that "data abstraction and encapsulation;"
in a different context. But the essence of it is the same. Operational
details have to be "hidden," functional ones not. You don't want your OS to
"abstract" your latest and best hardware's capabilities by dumbing it down
to 80286. You also don't want your OS to generalize at the cost of fitting
all sorts of resources into one model--it can't be done.

--On Thursday, November 13, 2008 3:25 PM +0100 gdiaz@9grid.es wrote:

> Hola,
>
> Hiding the details of the underlying resources is one of the
> functions/features of the OS, isn't it?
>
> slds.
>
> gabi
>
> -- eris.discordia@gmail.com wrote:
>>
>>> you of course know that the big difference in unix and other
>>> systems of the day was that files did not have type. this allowed
>>> a tools-based approach which was popular for many years.
>>
>> Not that type of "types." I gave an example (which Charles Forsyth found
>> to  be a bad one) to set the types of "types" apart. I mean "types" as
>> in named  pipes ("special" files) versus regular files. In my experience
>> which is  limited to "modern" UNIX clones, i.e. Linux and *BSD, you can
>> distinguish  between a number of file "types" and decide what to do
>> accordingly. You can  tell a directory, from a (character or block)
>> device, from a link, from a  regular file. These same "types" could, and
>> have been, be used to represent  some details of the underlying resource.
>>
>> --On Wednesday, November 12, 2008 6:11 PM -0500 erik quanstrom
>> <quanstro@coraid.com> wrote:
>>
>>>> Why shouldn't there be file "types" to
>>>> help better represent the details of an underlying resource?
>>>
>>> you of course know that the big difference in unix and other
>>> systems of the day was that files did not have type. this allowed
>>> a tools-based approach which was popular for many years.
>>>
>>> - erik
>>
>>
>>
>>
>>
>>
>
>

Re: [9fans] Do we have a catalog of 9P servers?

[Eris Discordia]

The information is very much appreciated here, Erik Quanstrom.

> so in plan 9, it's possible to know the device providing the file
> (try ls -l /dev), [...]

>From this I gather the client-side caching problem sqweek pointed out can
be easily addressed. Caching or no caching can be decided by the provider
of the file. And files are "typed"--though not explicitly--because you can
tell them apart.

--On Thursday, November 13, 2008 9:17 AM -0500 erik quanstrom
<quanstro@quanstro.net> wrote:

>> Not that type of "types." I gave an example (which Charles Forsyth found
>> to  be a bad one) to set the types of "types" apart. I mean "types" as
>> in named  pipes ("special" files) versus regular files. In my experience
>> which is  limited to "modern" UNIX clones, i.e. Linux and *BSD, you can
>> distinguish  between a number of file "types" and decide what to do
>> accordingly. You can  tell a directory, from a (character or block)
>> device, from a link, from a  regular file. These same "types" could, and
>> have been, be used to represent  some details of the underlying resource.
>
> actually, unix since early bsd does have file types. (actually,
> they derive from different types of file descriptors).  for example,
> there's a different and disjoint set of operations for sockets.
> there are some files that only respond to ioctls.
>
> so in plan 9, it's possible to know the device providing the file
> (try ls -l /dev), but there are no links, there is a pretty strong
> namespace (namespace(4)) convention and all files respond to
> the same io primatives so what more information do you need?
>
> - erik
>

Re: [9fans] Do we have a catalog of 9P servers?

[Eric Van Hensbergen]

On Thu, Nov 13, 2008 at 11:52 PM, Roman Shaposhnik <rvs@sun.com> wrote:
>
> But along the very same line of thought -- wouldn't it also then be
> much more reasonable to stick with an "alternative aname"
> approach when adopting 9P for symlinks, FIFOs and the
> rest of the POSIX paraphernalia?
>
> You pay with a slightly more complicated server, but you
> reap a huge benefit in a form of:
>
>   term% srvssh unix unix-fs
>   term% mount /srv/unix-fs /n/unix-fs
>   term% mount /srv/unix-fs /n/unix-fs-symlinks posix-symlinks

I wasn't aware of anyone looking for this particular functionality.
We look forward to your server implementation(s).

          -eric

Re: [9fans] Do we have a catalog of 9P servers?

[Steve Simon]

> But along the very same line of thought -- wouldn't it also then be
>much more reasonable to stick with an "alternative aname"
> approach when adopting 9P for symlinks, FIFOs and the
> rest of the POSIX paraphernalia?

I'a not the one who has to implement it so my opinion is
nothing more than that, but this gets my vote.

-Steve

Re: [9fans] Do we have a catalog of 9P servers?

[Roman Shaposhnik]

On Nov 13, 2008, at 8:37 AM, Dan Cross wrote:
> On Wed, Nov 12, 2008 at 2:13 PM,  <geoff@plan9.bell-labs.com> wrote:
>> stat(5) specifies exclusive-access files, which we do use for
>> locking.
>> In what sense is that not `doing locking'?  It's not POSIX byte-range
>> read- or write-locking per fcntl, but it's not clear to me how often
>> that's actually useful.  In quite a few situations, having a single
>> process directly access a resource and forcing all other accesses
>> through that process suffices.
>
> For special purposes, the canonical solution is probably just to have
> a ctl file that accepts commands to manipulate locks.  It's a bit of a
> protocol dance in the sense of the calling program having some smarts
> about what order it does things in, but wouldn't require changes to 9P
> proper.
>
> I recall when we were talking about adding a Tflush message around the
> time of 9P2000 and Rob or Russ or someone saying, "that's really the
> job of a fileserver."  I didn't fully appreciate what they meant at
> that time, thinking solely in terms of disk-based "file servers"
> (instead of the more abstract notion of a fileserver as a collection
> of related resources with well-defined operations on them) like kenfs,
> but it dawned on me (much) later that they were just referring to some
> sort of ctl file and a command along the lines of "sync <fid>".
> Locking is a natural abstraction of that kind of thing; it could
> easily be abstracted into a library function that does the right
> thing, much as dial() does.

But along the very same line of thought -- wouldn't it also then be
much more reasonable to stick with an "alternative aname"
approach when adopting 9P for symlinks, FIFOs and the
rest of the POSIX paraphernalia?

You pay with a slightly more complicated server, but you
reap a huge benefit in a form of:

    term% srvssh unix unix-fs
    term% mount /srv/unix-fs /n/unix-fs
    term% mount /srv/unix-fs /n/unix-fs-symlinks posix-symlinks
    # Look ma, I'm creating a symbolic link from a Plan9 terminal
    # I'll name it after you and it'll point to the root
    term% echo / > /n/unix-fs-symlinks/home/glenda/mama
    # And I can even do readlink()
    term% cat /n/unix-fs-symlinks/home/glenda/mama
    /
    # Best of all -- it all works as expected
    term% cd /n/unix-fs/home/glenda/mama
    term% ls
    bin   cdrom  etc   initrd      initrd.img.old  lib32  lost+found
mnt  proc  sbin  sys  usr  vmlinuz
    boot  dev    home  initrd.img  lib             lib64  media
opt  root  srv   tmp  var  vmlinuz.old

Thanks,
Roman.

Re: [9fans] Do we have a catalog of 9P servers?

[Brian L. Stuart]

>  It's a matter of approach. Linux takes what I like to call the cookie
> monster approach, which is MORE MORE MORE. More syscalls, more ioctls,
> more program flags, more layers of indirection, a constant enumeration
> of every use case. Rarely is there a pause to check whether several
> use cases can be coalesced into a single more general way of doing
> ...
>  More to the point, I'm yet to see a richer set of abstractions come
> out of another system. Private namespaces, resources as files... they

I often try to explain it to people this way.  There's
a big difference between mechanisms and features.  Well
designed software gets a lot of features out of a few
mechanisms.  Poorly designed software creates a new
mechanism for each feature.  You can see the difference
in the code, and you can feel the difference when using
it.

For example, the design decision to use a standard
protocol across all resources and a mechanism to
import name spaces doesn't seem like all that much
if you're judging by the release notes.  But it's
hard to even list all the "features" you get from
it.  The discussion about /net is one.  It makes
dealing with graphical displays across a network
so elegant as to make X look positively gross.
It makes using a remote disk for off-site mirroring
trivial.  And the list goes on.

Your homework assignment is to figure out which of
those two characterizations best fits the software
you use daily.

BLS

Re: [9fans] Do we have a catalog of 9P servers?

[sqweek]

On Wed, Nov 12, 2008 at 10:23 PM, Eris Discordia
<eris.discordia@gmail.com> wrote:
> First off, thank you so much, sqweek. When someone on 9fans tries to put
> things in terms of basic abstract ideas instead of technical ones I really
> appreciate it--I actually learn something.

 Welcome, but don't mistake me for someone having the background and
experience with plan 9 to comment with any sort of authority.

>>  It doesn't stop at 9p:
>> * plan 9 doesn't need to bother with NAT, since you can just
>> import /net from your gateway.
>
> I understand that if you import a gateway's /net on each computer in a
> rather large internal network you will be consuming a huge amount of mostly
> redundant resources on the gateway. My impression is that each imported
> instance of /net requires a persistent session to be established between the
> gateway and the host on the internal network. NAT in comparison is naturally
> transient.

 I'm not sure there's as much difference as you make out to be. On the
one hand, you have a NAT gateway listening for tcp/ip packets, and on
the other hand you have an open tcp/ip connection and a file server
waiting for 9p requests. It's not as though 9p is wasting bandwidth
chatting away while there's no activity, so the only cost is the
tcp/ip connection to each client on the network, which shouldn't
qualify as a huge amount of resources.
 If it does, you have the same problem with any service you want to
provide to the whole network, so the techniques you use to solve it
there can be applied to the gateway. So *maybe* you could get away
with a weaker machine serving NAT instead of /net, but it would come
at a cost (the sort of cost that are hard to recognise as costs
because we're so used to them. every time i remind myself that /net
removes the need for port forwarding i get shivers).

> With an imported /net since there's no packet rewriting implemented
> on the network layer (e.g. IP) and because the "redirection" occurs in the
> application layer there's no chance of capturing spoofed packets except with
> hacking what makes /net tick (the kernel?).

 What makes /net tick depends on what you export on /net. The kernel
serves your basic /net, yes, but there's nothing to stop you having a
userspace file server on top of that to do whatever filtering you
like.

> Does that mean a new design "from scratch" is
> always bound to be better suited to current constraints?

 It very often is in my experience. But it's also very easy to leave
something important out of "current constraints" when designing from
scratch, or ignore the lessons learned by the previous iteration.

> Also, if you think
> UNIX and clones are flawed today because of their history and origins what
> makes you think Plan 9 doesn't suffer from "diseases" it contracted from its
> original birthplace? I can't forget the Jukebox example.

 UNIX seems to have coped with changing constraints by bolting more
and more junk on the side...
* "Whoa, here comes a network, we're going to need some more syscalls!"
* "Non-english languages? Better rig up some new codepages!"

> As pointed out previously on this same thread,
> in jest though, the Linux community always finds a way to exhaust a
> (consistent) model's options, and then come the extensions and "hacks."
> That, however, is not the Linux community's fault--it's the nature of an
> advancing science and technology that always welcomes not only new users but
> also new types of users and entirely novel use cases.

 It's a matter of approach. Linux takes what I like to call the cookie
monster approach, which is MORE MORE MORE. More syscalls, more ioctls,
more program flags, more layers of indirection, a constant enumeration
of every use case. Rarely is there a pause to check whether several
use cases can be coalesced into a single more general way of doing
things, or to consider whether the feature could be better implemented
elsewhere in the system. This has a tendency to disrupt conceptual
integrity, which hastens the above process.

 These days the dearth of developers make it difficult to distinguish
any daring developments on plan 9, but during the decades a different
derivation has been demonstrated.
 *ahem* Plan 9 seems to have more of a tendency to adapt. I'm sure the
adoption of utf-8 and the switch from 9p to 9p2000 aren't the only
examples of system-wide changes. The early labs history is rife with
stories of folk joining and trying out all sorts of new stuff. The
system feels like it has a more experimental nature - things that
don't work get dropped and lessons are learned from mistakes. Which is
sadly somewhat rare in software.

 More to the point, I'm yet to see a richer set of abstractions come
out of another system. Private namespaces, resources as files... they
might be ancient ideas, but everyone else is still playing catch up.
They might not be the ultimate ideal, but if we push them far enough
we might learn something.

>> The problem is it forces the server and client to synchronise on every
>> read/write syscall, which results in terrible bandwidth utilisation.
>
> An example of a disease contracted from a system's birthplace.

 You're pretty quick to to describe it as a disease. Plan 9 learned a
lot from the mistakes of UNIX, but the base syscalls are something
that stuck. I wouldn't expect that to happen without good reason.

 'scuse me if I'm silent for awhile, I've been spending too much time
pondering and it's starting to affect my work. *9fans breathes a sigh
of relief*
-sqweek

Re: [9fans] Do we have a catalog of 9P servers?

[Dan Cross]

On Wed, Nov 12, 2008 at 2:13 PM,  <geoff@plan9.bell-labs.com> wrote:
> stat(5) specifies exclusive-access files, which we do use for locking.
> In what sense is that not `doing locking'?  It's not POSIX byte-range
> read- or write-locking per fcntl, but it's not clear to me how often
> that's actually useful.  In quite a few situations, having a single
> process directly access a resource and forcing all other accesses
> through that process suffices.

For special purposes, the canonical solution is probably just to have
a ctl file that accepts commands to manipulate locks.  It's a bit of a
protocol dance in the sense of the calling program having some smarts
about what order it does things in, but wouldn't require changes to 9P
proper.

I recall when we were talking about adding a Tflush message around the
time of 9P2000 and Rob or Russ or someone saying, "that's really the
job of a fileserver."  I didn't fully appreciate what they meant at
that time, thinking solely in terms of disk-based "file servers"
(instead of the more abstract notion of a fileserver as a collection
of related resources with well-defined operations on them) like kenfs,
but it dawned on me (much) later that they were just referring to some
sort of ctl file and a command along the lines of "sync <fid>".
Locking is a natural abstraction of that kind of thing; it could
easily be abstracted into a library function that does the right
thing, much as dial() does.

The one change I wish we could make to 9P is to extend stat and wstat
with a version field, so I could pass domain specific information over
9P.  As a stupid example, combining that with some sort of translator,
I could define a DECnet service that let me manipulate all the VMS and
TOPS-20 specific fields and extended file attributes from those
worlds, but from Plan 9.  All of a sudden, I have access to a
versioned filesystem living under VMS on Itanium.  Not that anyone
would WANT to do such a thing, but it was a simple example that just
popped into my head.  Perhaps a more realistic idea would be assuming
the functionality of the 9P2000.u protocol (which I don't know much
about; the Marines have been keeping me away from Plan 9 for quite
some time now, but as I understand it, it mainly extends 9P to deal
with symlinks for Unix support).

I can't really think of anything you couldn't do with that change and
an appropriately designed ctl interface.  But then again, I've been
out of the game for a little while.

        - Dan C.

Re: [9fans] Do we have a catalog of 9P servers?

[Iruata Souza]

On Thu, Nov 13, 2008 at 12:17 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>> Not that type of "types." I gave an example (which Charles Forsyth found to
>> be a bad one) to set the types of "types" apart. I mean "types" as in named
>> pipes ("special" files) versus regular files. In my experience which is
>> limited to "modern" UNIX clones, i.e. Linux and *BSD, you can distinguish
>> between a number of file "types" and decide what to do accordingly. You can
>> tell a directory, from a (character or block) device, from a link, from a
>> regular file. These same "types" could, and have been, be used to represent
>> some details of the underlying resource.
>
> actually, unix since early bsd does have file types. (actually,
> they derive from different types of file descriptors).  for example,
> there's a different and disjoint set of operations for sockets.
> there are some files that only respond to ioctls.
>

that disjoint set of operations was a pain to circumvent while writing
the communication/network part for o9fs [1].
I didn't want to have to write separate code for the different types
of files, so I used file entries instead of vnodes (what people tend
to use).
I ended up with something that doesn't know what file types are and
with way simpler code and needed funcionality added (p9p ramfs mounted
nicely with no specific code, for example)

iru

[1] http://src.oitobits.net/o9fs

Re: [9fans] Do we have a catalog of 9P servers?

[gdiaz]

Hola,

Hiding the details of the underlying resources is one of the functions/features of the OS, isn't it?

slds.

gabi

-- eris.discordia@gmail.com wrote:
>
>> you of course know that the big difference in unix and other
>> systems of the day was that files did not have type. this allowed
>> a tools-based approach which was popular for many years.
>
>Not that type of "types." I gave an example (which Charles Forsyth found to
>be a bad one) to set the types of "types" apart. I mean "types" as in named
>pipes ("special" files) versus regular files. In my experience which is
>limited to "modern" UNIX clones, i.e. Linux and *BSD, you can distinguish
>between a number of file "types" and decide what to do accordingly. You can
>tell a directory, from a (character or block) device, from a link, from a
>regular file. These same "types" could, and have been, be used to represent
>some details of the underlying resource.
>
>--On Wednesday, November 12, 2008 6:11 PM -0500 erik quanstrom
><quanstro@coraid.com> wrote:
>
>>> Why shouldn't there be file "types" to
>>> help better represent the details of an underlying resource?
>>
>> you of course know that the big difference in unix and other
>> systems of the day was that files did not have type. this allowed
>> a tools-based approach which was popular for many years.
>>
>> - erik
>
>
>
>
>
>

Re: [9fans] Do we have a catalog of 9P servers?

[erik quanstrom]

> Not that type of "types." I gave an example (which Charles Forsyth found to
> be a bad one) to set the types of "types" apart. I mean "types" as in named
> pipes ("special" files) versus regular files. In my experience which is
> limited to "modern" UNIX clones, i.e. Linux and *BSD, you can distinguish
> between a number of file "types" and decide what to do accordingly. You can
> tell a directory, from a (character or block) device, from a link, from a
> regular file. These same "types" could, and have been, be used to represent
> some details of the underlying resource.

actually, unix since early bsd does have file types. (actually,
they derive from different types of file descriptors).  for example,
there's a different and disjoint set of operations for sockets.
there are some files that only respond to ioctls.

so in plan 9, it's possible to know the device providing the file
(try ls -l /dev), but there are no links, there is a pretty strong
namespace (namespace(4)) convention and all files respond to
the same io primatives so what more information do you need?

- erik

Re: [9fans] Do we have a catalog of 9P servers?

[Eris Discordia]

> you of course know that the big difference in unix and other
> systems of the day was that files did not have type.  this allowed
> a tools-based approach which was popular for many years.

Not that type of "types." I gave an example (which Charles Forsyth found to
be a bad one) to set the types of "types" apart. I mean "types" as in named
pipes ("special" files) versus regular files. In my experience which is
limited to "modern" UNIX clones, i.e. Linux and *BSD, you can distinguish
between a number of file "types" and decide what to do accordingly. You can
tell a directory, from a (character or block) device, from a link, from a
regular file. These same "types" could, and have been, be used to represent
some details of the underlying resource.

--On Wednesday, November 12, 2008 6:11 PM -0500 erik quanstrom
<quanstro@coraid.com> wrote:

>> Why shouldn't there be file "types" to
>> help better represent the details of an underlying resource?
>
> you of course know that the big difference in unix and other
> systems of the day was that files did not have type.  this allowed
> a tools-based approach which was popular for many years.
>
> - erik

Re: [9fans] Do we have a catalog of 9P servers?

[akumar]

[-- Attachment #1: Type: text/plain, Size: 88 bytes --]

You shouldn't need to be starved of electricity in order to get away
from the thread.

[-- Attachment #2: Type: message/rfc822, Size: 2353 bytes --]

From: "Bruce Ellis" <bruce.ellis@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net>
Subject: Re: [9fans] Do we have a catalog of 9P servers?
Date: Thu, 13 Nov 2008 01:51:47 +0200
Message-ID: <775b8d190811121551i69daee72y66666674fe27b729@mail.gmail.com>

yuck, i give up. this thread is nearly longer than the kernel. i'm off
to find an island without electricity. i can do without beer.

brucee

Re: [9fans] Do we have a catalog of 9P servers?

[Bruce Ellis]

yuck, i give up. this thread is nearly longer than the kernel. i'm off
to find an island without electricity. i can do without beer.

brucee

Re: [9fans] Do we have a catalog of 9P servers?

[erik quanstrom]

> Why shouldn't there be file "types" to
> help better represent the details of an underlying resource?

you of course know that the big difference in unix and other
systems of the day was that files did not have type.  this allowed
a tools-based approach which was popular for many years.

- erik

Re: [9fans] Do we have a catalog of 9P servers?

[Roman V. Shaposhnik]

On Wed, 2008-11-12 at 09:47 -0800, ron minnich wrote:
> > The way I see it: if you look past stalessness (taken care of
> > in WebNFS and NFS4) eagerness to do proper caching and
> > on-the-wire messages there are, actually, quite a few similarities
> > between the two:
> >  FH is a moral equivalent of a Qid
> >  ACCESS is a moral equivalent of open
> >  SETATTR/GETATTR is like stat/wstat
> >  LOOKUP is like walk (especially so in WebNFS)
> >  READ/WRITE/CREATE/REMOVE is there in both
> >
>
> yes, from the top they look superficially similar. From where I stand,
> they could not be more different. This difference is the cause of
> major performance issues.
> - sunrpc
> - xdr
> - fhandles are a nightmare (security and otherwise)
>
> The whole layering of nfs/sunrpc is very computer-sciency and 1970s.
> It's antiquated. It's also how everyone does it even now. It's a hog.
> It's also interesting to see differences

Absolutely. No disagreement there. But! You're now talking
implementation. You don't have to do rpc and all that crap in all its
glory to implement NFS. Plan9's very own nfsserver is a prime example of
how things could be way simpler in NFS than they usually are.

> Result: FOUR different protocols to make nfs work (portmap, nfs,
> lockd, mountd); one protocol to make 9p file servers work

Mmmm. Almost agreed. Very painful thing to manage. But! None of that
(well, except nfsd) is needed in WebNFS/NFS4. Thus is is almost
a deployment practices issue, not really something that is inherently
bad in the *core* of the protocol.

> That's just a taste. They're really very very different.

Well, here's one thing that I wanted to point out in this
discussion: if you abstract away from the implementation (rpc &co)
and the horrible deployment practices (portmap, mountd and to
some extent even lockd) what is left still seems close enough
to 9P in the following sense: it shares a number of same problems.
These problems were actively discussed in NFS community (which
is, unfortunately, much large than a 9P community) and it may
be worthwhile to learn from that experience.

Thanks,
Roman.

P.S. I totally feel for you -- dealing with NFS *implementation*
and typical *deployments* is nothing short of a torture.

Re: [9fans] Do we have a catalog of 9P servers?

[Eris Discordia]

> that's a particularly bad example to pick. those shouldn't exist at all.

I don't see why (of course I am rather short-sighted). I guess they exist
because at some point in UNIX history devices existed that could be
usefully characterized as either block or character devices or meaningfully
distinct applications existed for named pipes of either type. But it's very
probable anyway that you know better than I do. The bad example, however,
doesn't invalidate the question. Why shouldn't there be file "types" to
help better represent the details of an underlying resource?

--On Wednesday, November 12, 2008 2:02 PM +0000 Charles Forsyth
<forsyth@terzarima.net> wrote:

>> Why isn't there provision for file "types" at least
>> (mknod types b and c come to mind)?
>
> that's a particularly bad example to pick. those shouldn't exist at all.
>

Re: [9fans] Do we have a catalog of 9P servers?

[Gorka Guardiola]

On Wed, Nov 12, 2008 at 8:55 PM, Brantley Coile <brantley@coraid.com> wrote:
> That explains why IBM's MVS didn't have locking at all.  One would conclude
> from that fact that locking isn't required to do even serious business
> applications.
>

I don't follow your reasoning.
Saying fcntl locking is not useful does not mean you don't need locking,
just that you don't need fcntl.

By the way, can you (forsyth) expand on why you couldn't use it/didn't work
for you?.
--
- curiosity sKilled the cat

Re: [9fans] Do we have a catalog of 9P servers?

[Charles Forsyth]

>It's not POSIX byte-range
>read- or write-locking per fcntl, but it's not clear to me how often
>that's actually useful.

they aren't. i wrote a paper about it many years ago, when helping to implement
a database system. in short, you can't rely on them for either scale or properties,
so in any serious application you'll do it yourself anyway.

Re: [9fans] Do we have a catalog of 9P servers?

[Brantley Coile]

That explains why IBM's MVS didn't have locking at all.  One would
conclude from that fact that locking isn't required to do even serious
business applications.

Brantley


On Nov 12, 2008, at 2:58 PM, Charles Forsyth wrote:

>> It's not POSIX byte-range
>> read- or write-locking per fcntl, but it's not clear to me how often
>> that's actually useful.
>
> they aren't. i wrote a paper about it many years ago, when helping
> to implement
> a database system. in short, you can't rely on them for either scale
> or properties,
> so in any serious application you'll do it yourself anyway.
>
>

Re: [9fans] Do we have a catalog of 9P servers?

[Eric Van Hensbergen]

On Wed, Nov 12, 2008 at 1:00 PM, Uriel <uriel99@gmail.com> wrote:
>
> 9P doesn't do locking; .u/.l change the protocol.
>

yes.  (well mostly yes - Geoff points out there are some locking
semantics in 9P, more correctly 9P doesn't do POSIX locking, .L
changes the protocol (.u doesn't make any provisions for locking).)

> Of course it would be possible to do locking (ext attrs and other
> lunix crud) without changing the protocol, which would have the
> advantage of not requiring changes in the dozens of existing 9P
> implementations, plus would give one access to such 'features' from
> standard cat/echo interface, something which no lunix system can
> currently do...
>

Actually the .L mechanism does it in a way that requires no changes to
applications or servers who don't want to do locking.  In fact, .L
isn't really meant for any existing 9P applications, as I've said
previously -- it is a complimentary set of operations intended to
function as proxies between Linux systems (or between Linux and a .L
remote file server).  Servers which don't support an operation (such
as locking) respond with an error to Locking requests and the clients
are expected to respond gracefully.

Access to such changes would not be directly accessible to unmodified
programs/systems, however simple proxy gateways could provide a
stopgap mapping whatever semantics you want between 9P2010 and 9P2000.
 However, as I said, this isn't really the intended target of the 9P.L
work, its really about establishing a proxy protocol for Linux with a
foundation based on 9P.

My co-workers and internal customers have constantly  attempted to
convince me to clean-slate design the protocol and rename it so it
doesn't contain any stigma of being associated with Plan 9.  But I see
that as counterproductive to both communities.  Zealots never prosper,
or at least they never should prosper.

> If I understood erik correctly, .L will even add auth into the
> protocol... I guess that only leaves us missing sunrpc for 9P to match
> NFS4's beauty.

Actually, what I said was is that I was uncertain of how Auth will
shake out.  It is entirely likely that it can be handled within the
context of the existing setup, but since I haven't worked through the
implementation yet I'm unsure of what it will look like.  The same can
be said for all parts of .L actually, all I've done is setup the Linux
9P client to be easily extended (the same work could be used to make
an Octopus variant) and look at how many opcodes I may need to reserve
to provide proxy functions for Linux VFS calls -- .L will be specified
as the implementation is worked out, I wouldn't make too many
assumptions about it until that process is (at least mostly) complete.

           -eric

Re: [9fans] Do we have a catalog of 9P servers?

[ron minnich]

On Wed, Nov 12, 2008 at 11:00 AM, Uriel <uriel99@gmail.com> wrote:

>> That's just a taste. They're really very very different.
>
> May Glenda bless the IBM-induced standard wisdom.

So the IBM standard wisdom is that NFS and 9p are really very very
different (actually that was my quote)?

But yes, the fact that NFS and 9p are very very different is wisdom.

We all appreciate the blessing.

ron

Re: [9fans] Do we have a catalog of 9P servers?

[geoff]

stat(5) specifies exclusive-access files, which we do use for locking.
In what sense is that not `doing locking'?  It's not POSIX byte-range
read- or write-locking per fcntl, but it's not clear to me how often
that's actually useful.  In quite a few situations, having a single
process directly access a resource and forcing all other accesses
through that process suffices.

Re: [9fans] Do we have a catalog of 9P servers?

[erik quanstrom]

> If I understood erik correctly, .L will even add auth into the
> protocol... I guess that only leaves us missing sunrpc for 9P to match
> NFS4's beauty.

i said nothing about .l.  perhaps eric did.

- erik

Re: [9fans] Do we have a catalog of 9P servers?

[Uriel]

On Wed, Nov 12, 2008 at 6:47 PM, ron minnich <rminnich@gmail.com> wrote:
> On Tue, Nov 11, 2008 at 9:20 PM, Roman Shaposhnik <rvs@sun.com> wrote:
>> On Nov 11, 2008, at 8:58 PM, ron minnich wrote:
>
>>> They're utterly different, at every level. Yes, they give you a
>>> similar service, but ...
>>
>> Whoa! That's a pretty strong claim. Care to substantiate?
>>
>> The way I see it: if you look past stalessness (taken care of
>> in WebNFS and NFS4) eagerness to do proper caching and
>> on-the-wire messages there are, actually, quite a few similarities
>> between the two:
>>  FH is a moral equivalent of a Qid
>>  ACCESS is a moral equivalent of open
>>  SETATTR/GETATTR is like stat/wstat
>>  LOOKUP is like walk (especially so in WebNFS)
>>  READ/WRITE/CREATE/REMOVE is there in both
>>
>
> yes, from the top they look superficially similar. From where I stand,
> they could not be more different. This difference is the cause of
> major performance issues.
> - sunrpc
> - xdr
> - fhandles are a nightmare (security and otherwise)
>
> The whole layering of nfs/sunrpc is very computer-sciency and 1970s.
> It's antiquated. It's also how everyone does it even now. It's a hog.
> It's also interesting to see differences
>
> sunrpc gets service variation via program number/version; 9p gets it
> by what server you talk to.
> Result: FOUR different protocols to make nfs work (portmap, nfs,
> lockd, mountd); one protocol to make 9p file servers work
>
> in essence, sunrpc externalizes service variation by creating lots of
> protocols (program numbers and versons) over sunrpc; 9p gets it the
> right way, by changing the server, but not the protocol.
> In a way, 9p cleanly squashes together nfs and sunrpc, and dispenses
> with the wasteful xdr code completely. In my ancient 10-year-old TR to
> DARPA I point out that we could use 9p for all four nfs services and
> save some work.

9P doesn't do locking; .u/.l change the protocol.

Of course it would be possible to do locking (ext attrs and other
lunix crud) without changing the protocol, which would have the
advantage of not requiring changes in the dozens of existing 9P
implementations, plus would give one access to such 'features' from
standard cat/echo interface, something which no lunix system can
currently do...

If I understood erik correctly, .L will even add auth into the
protocol... I guess that only leaves us missing sunrpc for 9P to match
NFS4's beauty.

> That's just a taste. They're really very very different.

May Glenda bless the IBM-induced standard wisdom.

uriel

> ron
>
>

Re: [9fans] Do we have a catalog of 9P servers?

[ron minnich]

On Tue, Nov 11, 2008 at 9:20 PM, Roman Shaposhnik <rvs@sun.com> wrote:
> On Nov 11, 2008, at 8:58 PM, ron minnich wrote:

>> They're utterly different, at every level. Yes, they give you a
>> similar service, but ...
>
> Whoa! That's a pretty strong claim. Care to substantiate?
>
> The way I see it: if you look past stalessness (taken care of
> in WebNFS and NFS4) eagerness to do proper caching and
> on-the-wire messages there are, actually, quite a few similarities
> between the two:
>  FH is a moral equivalent of a Qid
>  ACCESS is a moral equivalent of open
>  SETATTR/GETATTR is like stat/wstat
>  LOOKUP is like walk (especially so in WebNFS)
>  READ/WRITE/CREATE/REMOVE is there in both
>

yes, from the top they look superficially similar. From where I stand,
they could not be more different. This difference is the cause of
major performance issues.
- sunrpc
- xdr
- fhandles are a nightmare (security and otherwise)

The whole layering of nfs/sunrpc is very computer-sciency and 1970s.
It's antiquated. It's also how everyone does it even now. It's a hog.
It's also interesting to see differences

sunrpc gets service variation via program number/version; 9p gets it
by what server you talk to.
Result: FOUR different protocols to make nfs work (portmap, nfs,
lockd, mountd); one protocol to make 9p file servers work

in essence, sunrpc externalizes service variation by creating lots of
protocols (program numbers and versons) over sunrpc; 9p gets it the
right way, by changing the server, but not the protocol.
In a way, 9p cleanly squashes together nfs and sunrpc, and dispenses
with the wasteful xdr code completely. In my ancient 10-year-old TR to
DARPA I point out that we could use 9p for all four nfs services and
save some work.

That's just a taste. They're really very very different.

ron

Re: [9fans] Do we have a catalog of 9P servers?

[Eric Van Hensbergen]

On Tue, Nov 11, 2008 at 9:51 PM, Roman Shaposhnik <rvs@sun.com> wrote:
> On Nov 11, 2008, at 6:11 PM, sqweek wrote:
>>
>> On Wed, Nov 12, 2008 at 4:54 AM, Eric Van Hensbergen <ericvh@gmail.com>
>> wrote:
>>>
>>> I have two measurements of success:
>>> a) what keeps me working on Plan 9 related technologies in a paid
>>> position
>>> b) what switches people from using NFS, GPFS, or other horribly
>>> complicated solutions to something closer to Plan 9
>>
>> Fair enough. Does .L still qualify as "closer to Plan 9", or is it
>> NFS by any other name?
>
> NFS (especially NFS4) seems to be exactly the POSIX-oriented 9P.
> Except one thing: they worry too much about caching and that
> show in various places in the protocol. NFS3 is also stateless.
>

An important consideration (and quantifiable difference):

9p-rfc.txt -- 47 pages
nfsv4-rfc.txt -- 275 pages

What's particularly interesting there is that the nfsv4.txt is
incomplete -- in order to implement the protocol you have to go
reference the RFC's on dozens of sub-protocols and side protocols.
The 9p-rfc.txt is fundamentally complete, with the only exception
being the requirement of a separate spec for the authentication
mechanisms.  Now, even though 9P.L will grow the specification
somewhat (in that there will be many new op-codes), the definition of
those protocol elements are trivial and I don't believe it'll boost us
to 275+ pages.

Another considering (and quantifiable difference):
9P Client (in Linux kernel including virtio, fd, & RDMA transports)
               Total Physical Source Lines of Code (SLOC)                = 5,233
9P Client (npfs ufs.c)
               Total Physical Source Lines of Code (SLOC)                = 5,454

NFS Client (in Linux kernel only including socket interface)
               Total Physical Source Lines of Code (SLOC)
  = 43,903
NFS Server Code (in Linux kernel)
               Total Physical Source Lines of Code (SLOC)
  = 15,106
NFS Userspace Support Utils (required for server op)
               Total Physical Source Lines of Code (SLOC)
  = 35,468

These aren't apples to apples kinds of comparisons.  NFS has more
features, 9P has more transports (in the above comparison, I didn't
have the time to track down the NFS/RDMA patch and there is no
NFS/virtio patch that I am aware of).

Again, the introduction of 9P.L will grow our line count a bit --
however, nearly all of the added operations are just proxy operations.
 That is, all they do is marshall and unmarshall VFS operands and
responses and map those operations to FIDs versus dentry pointers or
file pointers.  This is extremely straightforward and there is likely
to be more lines taken up by boilerplate than implementation.  As
such, I don't see the overall line count or code complexity increasing
dramatically on the protocol side.  The largest line count increase
will likely be from having alternative "fs" interfaces for 9P versus
9P.L -- but this will largely be boilerplate, not new complex code.

I use 9P versus NFS (or some other remote file system) for three
particular reasons:

* its approachable - I can understand it and understand what's going
on without slogging through layers of crap
* I can trivially implement a fully functioning server in a weekend or
less (this is an area we can do better on as well)
* its default semantics with respect to caching are closer to what I
need for the sorts of distributed systems I work with
* it is fairly straightforward to support new transports, and in the
Linux kernel implementation it's getting easier.  This is important
for me because not everything I deal with is a socket.

These reasons make sense to me no matter what environment I'm in (be
it Linux, Plan 9, or whatever).  Its certainly possible there are
other solutions and protocols, and I have no doubt things can be done
better.  But experience with using these things in actual large scale
deployments is the most valuable indicator of what tools works best
for what applications.

               -eric

Re: [9fans] Do we have a catalog of 9P servers?

[Charles Forsyth]

NFS4 still assumes that a file handle can be used to
find a file; neither the persistent nor the volatile
variants are directly comparable to a Qid and both can
complicate implementation.  (at least a volatile file handle
allows a file system implementation not based on inodes to be
done more easily than previously.) 9P uses fids instead,
which aren't coupled to Qids, with a lifetime limited
to at most a single session (and more usually they are explicitly clunked).

Re: [9fans] Do we have a catalog of 9P servers?

[Charles Forsyth]

>Why isn't there provision for file "types" at least
>(mknod types b and c come to mind)?

that's a particularly bad example to pick. those shouldn't exist at all.

Re: [9fans] Do we have a catalog of 9P servers?

[Eris Discordia]

First off, thank you so much, sqweek. When someone on 9fans tries to put
things in terms of basic abstract ideas instead of technical ones I really
appreciate it--I actually learn something. By the way, it is very
interesting how a technical question can be sublimated into a
Gedankenexperiment that even non-technical people can try to take a stab
at. Believe me, such pursuits can be fruitful for the technical people as
well as non-technicals.

>  It has a simple mapping to basic file operations, which makes it easy
> to transparently use on the client side. Aside from the debugging tool
> aux/9pcon, I'm not sure that any plan 9 programs do explicit 9p client
> calls.

That also means _if_ a resource can't be represented well using the
directory/file metaphor you will have to go through some trouble fitting it
into the model. In other words, 9P shouldn't be considered a "fits-all"
solution for problems. That in turn says why other protocols that try to be
"fits-all" solutions end up being complex--it's not because the designers
were dumb or didn't know better, it's because they had a different problem
to solve; namely, the problem of heterogeneity.

>  Could do. However, part of the simplicity of 9p stems from its
> implementation in Plan 9:
> * 9p doesn't need to worry about the details of auth - that's the
> responsibility of authsrv + factotum.
> * 9p doesn't need to support symlinks; the kernel provides that sort
> of functionality through bind.
> * 9p doesn't care about different user id mappings because plan 9 only
> deals with user names (and those are verified by the auth server).

Doesn't that imply, as Roman Shaposhnik pointed out, that 9P's edge is
limited to the Plan 9 implementation? It may be--though I'm certainly not
the one to consult on the subject--that the combination of 9P-esque
simplicity with the natural diversity of platforms is impossible, or very
hard to achieve. Unless, along with suggesting ubiquitous use of 9P one
suggests that everyone should run Plan 9.

>  It doesn't stop at 9p:
> * rc/bc/dc/hoc don't need to implement line editing or tab completion
> because the "terminal" (win from rio/acme) does the job.
> * rc/awk don't need to explicitly support tcp/ip because we have /net.
> * fossil doesn't need hardlinks, since venti coalesces identical data
> blocks. * plan 9 doesn't need to bother with NAT, since you can just
> import /net from your gateway.

This third case, i.e. NAT, is interesting to me. I remember you informing
me some time ago on how Plan 9 could allow a "network transparent sort of
networking." At the time I saw no flaws with that argument. Now I do.
There's a reason for NAT being the way it is.

I understand that if you import a gateway's /net on each computer in a
rather large internal network you will be consuming a huge amount of mostly
redundant resources on the gateway. My impression is that each imported
instance of /net requires a persistent session to be established between
the gateway and the host on the internal network. NAT in comparison is
naturally transient. If at all points in time like half the network's
population is not using any outside world connections then the gateway can
be set up to handle only that much with a little to spare. Importing /net
is very much like tunneling a network protocol in an application layer
protocol, the drawbacks are the same, the advantages, too.

If I knew something of network security I probably could also point out
some serious security flaws in the imported /net model, one of them being
lack of any access control beyond what auth provides which is insufficient
for networking purposes. A firewalled NAT service should be able to
distinguish between real packets from inside the network and packets with
spoofed source address. With an imported /net since there's no packet
rewriting implemented on the network layer (e.g. IP) and because the
"redirection" occurs in the application layer there's no chance of
capturing spoofed packets except with hacking what makes /net tick (the
kernel?). There's also the problem of setting up a DMZ and/or three-legged
firewall with this approach. The "width" of the DMZ is always zero with an
imported /net--the entire DMZ exists within the gateway's kernel (or
wherever in the gateway's memory structures is that /net resides).

>  Just some examples. But you're right, simplicity of design does
> happen elsewhere, but it's less likely to arise elsewhere simply
> because other systems have a lot more crap to deal with. When you're
> stuck with vt100 emulators, of course every shell implements its own
> line editing.

So the gist of this argument is that existing flawed designs are basically
continuations of measures that were previously required by constraints but
are now obsolete, right? Does that mean a new design "from scratch" is
always bound to be better suited to current constraints? Also, if you think
UNIX and clones are flawed today because of their history and origins what
makes you think Plan 9 doesn't suffer from "diseases" it contracted from
its original birthplace? I can't forget the Jukebox example.

>  Much of plan 9's simplicity comes from its structure and consistency.
> Note that all the simplicity gains I've listed come from *removing*
> features. To be able to do that sort of thing it helps to have a
> system where each component meshes well with the other components.
> Everything in its right place, so to speak.

That's the meaning of Rob Pike's "less is more" then. What do you propose
to be done to existing functional and perfectly operable systems? Should
one scrap them to make the scene more consistent?

Consistency comes at a cost. As pointed out previously on this same thread,
in jest though, the Linux community always finds a way to exhaust a
(consistent) model's options, and then come the extensions and "hacks."
That, however, is not the Linux community's fault--it's the nature of an
advancing science and technology that always welcomes not only new users
but also new types of users and entirely novel use cases. What seemed
ludicrous yesterday is the norm today and I must emphasize that this
_doesn't_ mean yesterday was the last day of a "Golden Age." What is the
Plan 9 community's plan for meeting the demands of new types of users? Do
Plan 9's creators/contributors intend to keep it as their darling secret
running for the purposes of research and education occasionally fitting
into some company's (Coraid?) business model or suiting some "big iron's"
(the new BG thing Ron Minnich wrote about) very special design.

>  Does "improve 9p to the point where no one will even minimally
> criticise it" count? :)

It counts but it won't work. At some point the accumulation of changes will
cause 9P to mutate into a new protocol. I suspect that's why 9P's designers
are loathe to "officially" incorporate changes and some 9fans think every
change to the "original" plan is a disaster. Things could get out of
(their) hand(s) that way.

> The problem is it forces the server and client to synchronise on every
> read/write syscall, which results in terrible bandwidth utilisation.

An example of a disease contracted from a system's birthplace.

> 9p is at a disadvantage because it is so general. Having to support
> arbitrary file semantics makes it difficult to come up with any sort of
> safe lookahead scheme to avoid waiting for a network round trip on every
> read()...

Why is there so much emphasis on the "everything-is-a-file" or
"everything-is-a-stream-of-bytes" model? The world is obviously more
diverse than that. Why isn't there provision for file "types" at least
(mknod types b and c come to mind)? Cache viable ones, pass others through.
If a resource is to be represented as file system what could go wrong with
providing the capability in the protocol of representing its minutiae? What
design principles--besides KISS, of course--require bludgeoning every
aspect (read: "file") of a resource into a regular "file?"

>  I'm sure I've missed something, but readahead is safe for all these
> constructs except event files, where if you readahead (and get data)
> but the client closes the file before actually read()-ing the buffered
> data, you really want to tell the file server to "put back" those
> events.

Mark event files by, say, "e" and don't cache them. Or implement "jitter"
control at the cost of extra bandwidth (that's what is currently done in
9P, I presume). Or require the client to announce a live "transaction sum
total" when closing an "e" type file. Or provide a "callback" mechanism for
events that the client actually processes through a control connection and
make the file server record and heed them. Outside of "one world, one
model" paradigms there's no shortage of nearly optimum solutions.

By the way, I believe most "event" files contain mostly "uneventful" data
and only rarely an "event" (e.g. EOF or EOT). So the callback mechanism
might not be as costly as it seems.

And once again, thanks for enlightening me :-)

--On Wednesday, November 12, 2008 1:40 PM +0900 sqweek <sqweek@gmail.com>
wrote:

> On Wed, Nov 12, 2008 at 9:32 AM, Eris Discordia
> <eris.discordia@gmail.com> wrote:
>> And some stuff for troll-clubbers to club me with:
>>
>> 1. What is 9P's edge over text-based protocol X?
>
>  It has a simple mapping to basic file operations, which makes it easy
> to transparently use on the client side. Aside from the debugging tool
> aux/9pcon, I'm not sure that any plan 9 programs do explicit 9p client
> calls.
>
>> 4. Intelligence is not something peculiar to 9fans and the creators of
>> Plan 9. Simplicity of design is not something peculiar to 9P. It could
>> appear out of the blue any day with the latest protocol X.
>
>  Could do. However, part of the simplicity of 9p stems from its
> implementation in Plan 9:
> * 9p doesn't need to worry about the details of auth - that's the
> responsibility of authsrv + factotum.
> * 9p doesn't need to support symlinks; the kernel provides that sort
> of functionality through bind.
> * 9p doesn't care about different user id mappings because plan 9 only
> deals with user names (and those are verified by the auth server).
>
>  It doesn't stop at 9p:
> * rc/bc/dc/hoc don't need to implement line editing or tab completion
> because the "terminal" (win from rio/acme) does the job.
> * rc/awk don't need to explicitly support tcp/ip because we have /net.
> * fossil doesn't need hardlinks, since venti coalesces identical data
> blocks. * plan 9 doesn't need to bother with NAT, since you can just
> import /net from your gateway.
>
>  Just some examples. But you're right, simplicity of design does
> happen elsewhere, but it's less likely to arise elsewhere simply
> because other systems have a lot more crap to deal with. When you're
> stuck with vt100 emulators, of course every shell implements its own
> line editing. Of course utf8+tcp/ip support creeps into every app one
> by one when you don't have a ubiquitous interface to them.
>  Much of plan 9's simplicity comes from its structure and consistency.
> Note that all the simplicity gains I've listed come from *removing*
> features. To be able to do that sort of thing it helps to have a
> system where each component meshes well with the other components.
> Everything in its right place, so to speak. Not that I'm suggesting
> plan 9 is 100% perfect, I'm sure there are shortcomings but it makes
> so much more effort than any other system I've seen as far as elegance
> goes.
>
>> Since protocol X is
>> supposedly new it will break nothing but if it manages to get a foothold
>> by its designers _not_ acting up the way the average 9fan does when 9P is
>> minimally criticized then 9P will be out the window forever. Do you have
>> a solution to that?
>
>  Does "improve 9p to the point where no one will even minimally
> criticise it" count? :)
>  9p certainly deserves some criticism as it stands - its sensitivity
> to latency means it works great on a local network, but poorly over
> something as wide as the internet. Though as Erik pointed out not so
> long ago, this is a limitation plan 9's 9p client code (and probably
> the client portion of every other 9p implementation), not the 9p
> protocol itself. The problem is it forces the server and client to
> synchronise on every read/write syscall, which results in terrible
> bandwidth utilisation. Unless we see some remarkable improvements in
> network technology in the near future, I'd be surprised to see 9p gain
> any foothold outside local networks before this problem is solved (I
> should really take a close look at Op). NFS or something similar that
> is only concerned with serving "regular" files could do a much better
> job here; 9p is at a disadvantage because it is so general. Having to
> support arbitrary file semantics makes it difficult to come up with
> any sort of safe lookahead scheme to avoid waiting for a network round
> trip on every read()...
>  OTOH, I wonder what semantics are generally used... the common sorts
> of files are:
>
> * "regular files" - a persistent array of bytes, whatever you write()
> to a certain offset will show up again when you read() the same
> offset.
>
> * ctl files - write()s are not preserved, but affect the state of the
> file server in some arbitrary way. read()s tend to give some brief
> information about the state.
>
> * event files - read()s block until something interesting happens.
> write()s might allow bi-directional events.
>
> * clone files - a read() of this file creates a new heirachy.
>
>  I'm sure I've missed something, but readahead is safe for all these
> constructs except event files, where if you readahead (and get data)
> but the client closes the file before actually read()-ing the buffered
> data, you really want to tell the file server to "put back" those
> events. Buggerit, I'm stumped already. :S
> -sqweek
>

Re: [9fans] Do we have a catalog of 9P servers?

[sqweek]

On Wed, Nov 12, 2008 at 2:22 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>> 0: the client calls pread()
>> 0: devmnt sends a Tread to the server
>> 1: server recieves Tread
>> 1: server sends Rread
>> 2: client recieves Rread
>> 2: pread() returns
>>
>>  You can't do any better than this if the server is involved, so what
>
> who says a remote server is involed?  perhaps the remote
> master has had the forethought to beknight a proxy with more
> advantagious connectivity.

 More advantagious connectivity?? The whole point of the scenario is
that it doesn't exist, otherwise I wouldn't be worried about latency,
would I?
 Otherwise sure, you could also have a local file server doing the
caching. But that just adds another level of indirection at time zero,
you still have to solve the same problem. Even if the file server is
speaking Op or some other less latency sensitive protocol on the
remote link, how do you translate the individual 9p requests to the
other protocol without doing potentially dangerous readahead or
similar?
-sqweek

Re: [9fans] Do we have a catalog of 9P servers?

[erik quanstrom]

> 0: the client calls pread()
> 0: devmnt sends a Tread to the server
> 1: server recieves Tread
> 1: server sends Rread
> 2: client recieves Rread
> 2: pread() returns
>
>  You can't do any better than this if the server is involved, so what

who says a remote server is involed?  perhaps the remote
master has had the forethought to beknight a proxy with more
advantagious connectivity.

perhaps there are seven such beknighted, with one worm to
rule them all.

- erik

Re: [9fans] Do we have a catalog of 9P servers?

[Roman Shaposhnik]

On Nov 11, 2008, at 8:58 PM, ron minnich wrote:
> On Tue, Nov 11, 2008 at 6:11 PM, sqweek <sqweek@gmail.com> wrote:
>> On Wed, Nov 12, 2008 at 4:54 AM, Eric Van Hensbergen <ericvh@gmail.com
>> > wrote:
>>> I have two measurements of success:
>>> a) what keeps me working on Plan 9 related technologies in a paid
>>> position
>>> b) what switches people from using NFS, GPFS, or other horribly
>>> complicated solutions to something closer to Plan 9
>>
>> Fair enough. Does .L still qualify as "closer to Plan 9", or is it
>> NFS by any other name?
>
> well it's pretty different from NFS.
>> Please excuse the inflammatory phrasing - that's an honest question.
>> I'm very ignorant about NFS and its differences from 9p, other than
>> the number of message types.
>
>
> They're utterly different, at every level. Yes, they give you a
> similar service, but ...

Whoa! That's a pretty strong claim. Care to substantiate?

The way I see it: if you look past stalessness (taken care of
in WebNFS and NFS4) eagerness to do proper caching and
on-the-wire messages there are, actually, quite a few similarities
between the two:
   FH is a moral equivalent of a Qid
   ACCESS is a moral equivalent of open
   SETATTR/GETATTR is like stat/wstat
   LOOKUP is like walk (especially so in WebNFS)
   READ/WRITE/CREATE/REMOVE is there in both

That leaves READLINK, MKDIR, SYMLINK, MKNOD,
RMDIR, RENAME, READDIR[PLUS] and some FSINFO* stuff.

Now, you can't do POSIX without SYMLINK, READLINK, MKNOD and RENAME
so I expect to see them in .L

That leaves MKDIR/RMDIR and READDIR[PLUS] which doesn't
strike me as that huge of a diff.

Am I missing the point you're trying to make?

Thanks,
Roman.

Re: [9fans] Do we have a catalog of 9P servers?

[sqweek]

On Wed, Nov 12, 2008 at 1:50 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>> protocol itself. The problem is it forces the server and client to
>> synchronise on every read/write syscall, which results in terrible
>> bandwidth utilisation. Unless we see some remarkable improvements in
> [...]
>>
>>  I'm sure I've missed something, but readahead is safe for all these
>> constructs except event files, where if you readahead (and get data)
>> but the client closes the file before actually read()-ing the buffered
>
> unfortunately, client caching is problematic.
>
> the open research question is, how to make latency the
> domain of the file server(s) and not of the application.

 I don't think that is possible without the current set of
syscalls/algorithms... Currently we have this (where time is measured
in one-way trips across the network):

0: the client calls pread()
0: devmnt sends a Tread to the server
1: server recieves Tread
1: server sends Rread
2: client recieves Rread
2: pread() returns

 You can't do any better than this if the server is involved, so what
saving is there to be made aside from:

0: the client calls pread()
0: devmnt notices it has the requested data cached
0: pread() returns

 devmnt doesn't have to be the one to choose what to cache, I suppose.
You could have the file server readahead safely, at the cost of having
to teach devmnt (and clients in general) to deal with unsolicited
messages from file servers, and be careful about rate limiting...

 The only other way around the problem I can see is an alternate set
of syscalls (or library calls, but either way you'd need to rewrite
anything that uses read()).
-sqweek

Re: [9fans] Do we have a catalog of 9P servers?

[ron minnich]

On Tue, Nov 11, 2008 at 6:11 PM, sqweek <sqweek@gmail.com> wrote:
> On Wed, Nov 12, 2008 at 4:54 AM, Eric Van Hensbergen <ericvh@gmail.com> wrote:
>> I have two measurements of success:
>>  a) what keeps me working on Plan 9 related technologies in a paid position
>>  b) what switches people from using NFS, GPFS, or other horribly
>> complicated solutions to something closer to Plan 9
>
>  Fair enough. Does .L still qualify as "closer to Plan 9", or is it
> NFS by any other name?

well it's pretty different from NFS.

>  Please excuse the inflammatory phrasing - that's an honest question.
> I'm very ignorant about NFS and its differences from 9p, other than
> the number of message types.


They're utterly different, at every level. Yes, they give you a
similar service, but ...

ron

Re: [9fans] Do we have a catalog of 9P servers?

[erik quanstrom]

> protocol itself. The problem is it forces the server and client to
> synchronise on every read/write syscall, which results in terrible
> bandwidth utilisation. Unless we see some remarkable improvements in
[...]
>
>  I'm sure I've missed something, but readahead is safe for all these
> constructs except event files, where if you readahead (and get data)
> but the client closes the file before actually read()-ing the buffered

unfortunately, client caching is problematic.

the open research question is, how to make latency the
domain of the file server(s) and not of the application.

- erik

Re: [9fans] Do we have a catalog of 9P servers?

[sqweek]

On Wed, Nov 12, 2008 at 9:32 AM, Eris Discordia
<eris.discordia@gmail.com> wrote:
> And some stuff for troll-clubbers to club me with:
>
> 1. What is 9P's edge over text-based protocol X?

 It has a simple mapping to basic file operations, which makes it easy
to transparently use on the client side. Aside from the debugging tool
aux/9pcon, I'm not sure that any plan 9 programs do explicit 9p client
calls.

> 4. Intelligence is not something peculiar to 9fans and the creators of Plan
> 9. Simplicity of design is not something peculiar to 9P. It could appear out
> of the blue any day with the latest protocol X.

 Could do. However, part of the simplicity of 9p stems from its
implementation in Plan 9:
* 9p doesn't need to worry about the details of auth - that's the
responsibility of authsrv + factotum.
* 9p doesn't need to support symlinks; the kernel provides that sort
of functionality through bind.
* 9p doesn't care about different user id mappings because plan 9 only
deals with user names (and those are verified by the auth server).

 It doesn't stop at 9p:
* rc/bc/dc/hoc don't need to implement line editing or tab completion
because the "terminal" (win from rio/acme) does the job.
* rc/awk don't need to explicitly support tcp/ip because we have /net.
* fossil doesn't need hardlinks, since venti coalesces identical data blocks.
* plan 9 doesn't need to bother with NAT, since you can just import
/net from your gateway.

 Just some examples. But you're right, simplicity of design does
happen elsewhere, but it's less likely to arise elsewhere simply
because other systems have a lot more crap to deal with. When you're
stuck with vt100 emulators, of course every shell implements its own
line editing. Of course utf8+tcp/ip support creeps into every app one
by one when you don't have a ubiquitous interface to them.
 Much of plan 9's simplicity comes from its structure and consistency.
Note that all the simplicity gains I've listed come from *removing*
features. To be able to do that sort of thing it helps to have a
system where each component meshes well with the other components.
Everything in its right place, so to speak. Not that I'm suggesting
plan 9 is 100% perfect, I'm sure there are shortcomings but it makes
so much more effort than any other system I've seen as far as elegance
goes.

> Since protocol X is
> supposedly new it will break nothing but if it manages to get a foothold by
> its designers _not_ acting up the way the average 9fan does when 9P is
> minimally criticized then 9P will be out the window forever. Do you have a
> solution to that?

 Does "improve 9p to the point where no one will even minimally
criticise it" count? :)
 9p certainly deserves some criticism as it stands - its sensitivity
to latency means it works great on a local network, but poorly over
something as wide as the internet. Though as Erik pointed out not so
long ago, this is a limitation plan 9's 9p client code (and probably
the client portion of every other 9p implementation), not the 9p
protocol itself. The problem is it forces the server and client to
synchronise on every read/write syscall, which results in terrible
bandwidth utilisation. Unless we see some remarkable improvements in
network technology in the near future, I'd be surprised to see 9p gain
any foothold outside local networks before this problem is solved (I
should really take a close look at Op). NFS or something similar that
is only concerned with serving "regular" files could do a much better
job here; 9p is at a disadvantage because it is so general. Having to
support arbitrary file semantics makes it difficult to come up with
any sort of safe lookahead scheme to avoid waiting for a network round
trip on every read()...
 OTOH, I wonder what semantics are generally used... the common sorts
of files are:

* "regular files" - a persistent array of bytes, whatever you write()
to a certain offset will show up again when you read() the same
offset.

* ctl files - write()s are not preserved, but affect the state of the
file server in some arbitrary way. read()s tend to give some brief
information about the state.

* event files - read()s block until something interesting happens.
write()s might allow bi-directional events.

* clone files - a read() of this file creates a new heirachy.

 I'm sure I've missed something, but readahead is safe for all these
constructs except event files, where if you readahead (and get data)
but the client closes the file before actually read()-ing the buffered
data, you really want to tell the file server to "put back" those
events. Buggerit, I'm stumped already. :S
-sqweek

Re: [9fans] Do we have a catalog of 9P servers?

[Roman Shaposhnik]

On Nov 11, 2008, at 6:11 PM, sqweek wrote:
> On Wed, Nov 12, 2008 at 4:54 AM, Eric Van Hensbergen
> <ericvh@gmail.com> wrote:
>> I have two measurements of success:
>> a) what keeps me working on Plan 9 related technologies in a paid
>> position
>> b) what switches people from using NFS, GPFS, or other horribly
>> complicated solutions to something closer to Plan 9
>
> Fair enough. Does .L still qualify as "closer to Plan 9", or is it
> NFS by any other name?

NFS (especially NFS4) seems to be exactly the POSIX-oriented 9P.
Except one thing: they worry too much about caching and that
show in various places in the protocol. NFS3 is also stateless.

Now, since it looks like I may be stuck implementing poor-mans-NFS
for Solaris via a user-space NFS daemon I sleuthed around and
discovered (quite to my embarrassment as a Sun employee) that
we had WebNFS once. Which was, if you ask me, as close to
POSIX-oriented 9P (at least the way it is shaping up right now)
as one can get.

Thanks,
Roman.

Re: [9fans] Do we have a catalog of 9P servers?

[Roman Shaposhnik]

[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]

On Nov 11, 2008, at 8:30 AM, Uriel wrote:
> On Tue, Nov 11, 2008 at 4:37 PM, Skip Tavakkolian <9nut@9netics.com>
> wrote:
>>
>> operations like these (symlink, readlink, lock, etc.) that only have
>> significance at the extremities should not worry the transit relays.
>> that was the reason for Text/Rext proposal.
>>
>> regardless, interpretation of the ops in a hetergeneous environment
>> will be a problem.
>
> It is not a problem if the ops are Topen/Tread/Twrite (on an
> alternative attach), as agreed at the first iwp9,

I think this is a very nice idea. In fact that's what I'm trying to
implement
right now as part of my project to get around symlinks.

The only drawback that I can see so far is an unnecessary walk on
the parallel tree in cases where you need to actually *manipulate*
a symlink (reading, etc. is not a problem -- that gets handled on
the server and is fine for my purposes).

I though the mantra around here was "out-of-band == should be
on a separate channel".

Thanks,
Roman.

[-- Attachment #2: Type: text/html, Size: 1747 bytes --]

Re: [9fans] Do we have a catalog of 9P servers?

[Roman Shaposhnik]

On Nov 11, 2008, at 8:36 AM, Skip Tavakkolian wrote:
>> I just want to have
>> separate protocol ops for messages versus a single extension op.  I
>> suppose the difference is largely an implementation decision assuming
>> your protocol operation space is large enough
>
> the thinking is that it's the least polluting -- in regard to 9P
> messages -- while still allowing for many categories of ops.

That's all goodness, but isn't it really an ioctl() that we all love
to hate?

Thanks,
Roman.

Re: [9fans] Do we have a catalog of 9P servers?

[sqweek]

On Wed, Nov 12, 2008 at 10:55 AM, Roman V. Shaposhnik <rvs@sun.com> wrote:
> On Tue, 2008-11-11 at 09:45 +0100, Fco. J. Ballesteros wrote:
>> For this we use local Infernos at machines serving resources,
>> using a dav server to provide the built name space to the native host systems.
>> Not for devices, but works for most other things.
>> Devices can be done by adapting their interfaces via wrapper FSs.
>
> Very interesting. Do you have any papers on this stuff available?

 You should have been at IWP9 :)
 http://iwp9.inf.uth.gr/iwp9_proceedings08.pdf #page 18 (page 9
according to the page numbers)
-sqweek

Re: [9fans] Do we have a catalog of 9P servers?

[Eric Van Hensbergen]

On Tue, Nov 11, 2008 at 8:11 PM, sqweek <sqweek@gmail.com> wrote:
> On Wed, Nov 12, 2008 at 4:54 AM, Eric Van Hensbergen <ericvh@gmail.com> wrote:
>> I have two measurements of success:
>>  a) what keeps me working on Plan 9 related technologies in a paid position
>>  b) what switches people from using NFS, GPFS, or other horribly
>> complicated solutions to something closer to Plan 9
>
>  Fair enough. Does .L still qualify as "closer to Plan 9", or is it
> NFS by any other name?

It'll likely be more tightly bound to Linux than NFS (in much the same
way that 9P is tightly bound to Plan 9).  Some of the new features of
NFSv4 actually bring it closer to 9P in ways, but .L isn't an attempt
to mimic NFSv4, its merely an attempt at defining a protocol to remote
Linux VFS operations.  Since the core of the protocol is base don 9P
(use of fids, walks, tags, etc.) many of the basic principals are
closer to 9P versus NFS -- its just there is a larger potential
operation space with parameters and argument syntax that matches the
underlying Linux interfaces (so no mapping/unmapping gorp is
necessary).

>  I'd hazard a guess that 9p's auth mechanism is more flexible, for starters.

While this may be true, its not clear how Auth will actually play out
in a Linux context.  However, one thing I am trying to do is keep
everything within the protocol instead of defining separate protocols
and ports for auth, locking, id mapping, etc. Although IIRC, NFSv4
actually makes some progress on fixing that as well.

           -eric

Re: [9fans] Do we have a catalog of 9P servers?

[sqweek]

On Wed, Nov 12, 2008 at 1:52 AM, Eric Van Hensbergen <ericvh@gmail.com> wrote:
> On Tue, Nov 11, 2008 at 10:36 AM, Skip Tavakkolian <9nut@9netics.com> wrote:
>>> I just want to have
>>> separate protocol ops for messages versus a single extension op.  I
>>> suppose the difference is largely an implementation decision assuming
>>> your protocol operation space is large enough
>>
>> the thinking is that it's the least polluting -- in regard to 9P
>> messages -- while still allowing for many categories of ops.
>>
>> but almost immediately there has to be a standard for the
>> extension message content. maybe it could be XML/SOAP :)
>
> I guess the difference between
>
> <extended op> <extended args...>
>
> and
>
> Text <extended op> <extended args...>
>
> is lost on me.

 What's the current default behaviour for unknown message types? I'm
guessing existing servers would respond with Rerror. Since you want to
forward unknown ops, I think this makes a case for Text/Rext - it's a
simpler modification to forward Text messages than forward all message
types within a certain range, especially if other protocol changes
happen in the future.
 OTOH, I guess the idea is a minimal change to the plan 9 routines to
forward unknown messages, rather than educating it about the different
types. In that case there isn't so much difference, though I'm not
sure how you tell whether a particular server is an endpoint vs a
transitive mount - seems you'd have to add a flag to lib9p and at that
point you seem to have less to worry about if you just educate it
about Text/Rext...
-sqweek

Re: [9fans] Do we have a catalog of 9P servers?

[sqweek]

On Wed, Nov 12, 2008 at 4:54 AM, Eric Van Hensbergen <ericvh@gmail.com> wrote:
> I have two measurements of success:
>  a) what keeps me working on Plan 9 related technologies in a paid position
>  b) what switches people from using NFS, GPFS, or other horribly
> complicated solutions to something closer to Plan 9

 Fair enough. Does .L still qualify as "closer to Plan 9", or is it
NFS by any other name?
 Please excuse the inflammatory phrasing - that's an honest question.
I'm very ignorant about NFS and its differences from 9p, other than
the number of message types. If you have a moment I'd appreciate a
quick summary, but feel free to tell me to do my own homework ;)
 I'd hazard a guess that 9p's auth mechanism is more flexible, for starters.
-sqweek

Re: [9fans] Do we have a catalog of 9P servers?

[Roman V. Shaposhnik]

On Tue, 2008-11-11 at 09:45 +0100, Fco. J. Ballesteros wrote:
> For this we use local Infernos at machines serving resources,
> using a dav server to provide the built name space to the native host systems.
> Not for devices, but works for most other things.
> Devices can be done by adapting their interfaces via wrapper FSs.

Very interesting. Do you have any papers on this stuff available?

Thanks,
Roman.

Re: [9fans] Do we have a catalog of 9P servers?

[Eris Discordia]

Excuse my interruption, please. I probably understand less than half of
this exchange, certainly none of the in-jokes, and I know Eric Van
Hensbergen might not exactly like compliments from a lowlife but whatever:
you rock Mr. Van Hensbergen!

And some stuff for troll-clubbers to club me with:

1. What is 9P's edge over text-based protocol X?

2. If somebody learnt from 9P, created their own protocol, and called it
FUSE II, what are you going to do? You know, _if_ FUSE has follies today it
doesn't it will have follies tomorrow.

3. If what you deem folly keeps on recurring perhaps it has a cause. If it
has a cause and if it comes out from among rather intelligent people then
the cause may simply be a _rationale_. Have you tried finding out the
rationale behind the current state of protocols/software you label
"horrendously complicated?"

4. Intelligence is not something peculiar to 9fans and the creators of Plan
9. Simplicity of design is not something peculiar to 9P. It could appear
out of the blue any day with the latest protocol X. Since protocol X is
supposedly new it will break nothing but if it manages to get a foothold by
its designers _not_ acting up the way the average 9fan does when 9P is
minimally criticized then 9P will be out the window forever. Do you have a
solution to that?

5. Widespread public and industry acceptance of a protocol is vital. More
vital is the realization that acceptance is often given by people who have
thoughts of their own and are probably not zombies for "enemy" X of 9P.
What a 9fan deems best might not be the best for somebody else and they may
have good reason for their stance. Sitting in here calling Linux Lunix
won't make Plan 9 any better known. At least do that on some LUG so that
they get to know Plan 9 by the fine trolls it nurtures.

--On Tuesday, November 11, 2008 4:33 PM -0600 Eric Van Hensbergen
<ericvh@gmail.com> wrote:

> On Tue, Nov 11, 2008 at 2:51 PM, erik quanstrom <quanstro@quanstro.net>
> wrote:
>>>>  If corporate acceptance is the new measure of success, maybe we
>>>> should be using an XML based protocol extension.
>>>
>>> Corporate acceptance was always the measure of success. it's the old
>>> measure. And it works, unless you don't need to eat.
>>
>> i'm pretty sure that's not how plan 9 got
>> written in the first place.
>>
>> aiming for corporate acceptance doesn't seem
>> to me to be aiming high enough.
>>
>
> Given the number of people writing good code for Plan 9 and/or Inferno
> now versus 15 years ago it seems like aiming for "higher than
> corporate acceptance" doesn't seem to be enough either.
>
>             -eric
>

Re: [9fans] Do we have a catalog of 9P servers?

[Eric Van Hensbergen]

On Tue, Nov 11, 2008 at 2:51 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>>>  If corporate acceptance is the new measure of success, maybe we
>>> should be using an XML based protocol extension.
>>
>> Corporate acceptance was always the measure of success. it's the old
>> measure. And it works, unless you don't need to eat.
>
> i'm pretty sure that's not how plan 9 got
> written in the first place.
>
> aiming for corporate acceptance doesn't seem
> to me to be aiming high enough.
>

Given the number of people writing good code for Plan 9 and/or Inferno
now versus 15 years ago it seems like aiming for "higher than
corporate acceptance" doesn't seem to be enough either.

            -eric

Re: [9fans] Do we have a catalog of 9P servers?

[erik quanstrom]

>>  If corporate acceptance is the new measure of success, maybe we
>> should be using an XML based protocol extension.
>
>
> Corporate acceptance was always the measure of success. it's the old
> measure. And it works, unless you don't need to eat.

i'm pretty sure that's not how plan 9 got
written in the first place.

aiming for corporate acceptance doesn't seem
to me to be aiming high enough.

- erik

Re: [9fans] Do we have a catalog of 9P servers?

[Bruce Ellis]

It was N+1. I'm still in greece, though I spoke to tiger last night -
I played Buudy Boy with him and he said woof woof - which means come
home. I'll send you the code on my return.

The puppy has spoken (he's less patient than my sheila).

brucee

On Tue, Nov 11, 2008 at 9:55 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote:
> On Tue, Nov 11, 2008 at 1:18 PM, Bruce Ellis <bruce.ellis@gmail.com> wrote:
>> Eric Sir,
>>
>> That's what I proposed in Madrid when introducing [TR]ext. It cannot
>> hurt. Forward unknown transactions. The destination will Rerror on
>> crap - it was buggered anyway (as Roy adn HG would say)..
>>
>
> Fair enough, what was the op-code(s) for [TR]ext? I need to add them
> to my strawman list to make sure I don't inadvertently squash them
> with my futzing.  Or add them yourself to the wiki under the 9P2010
> entry.
>
>        -eric
>
>

Re: [9fans] Do we have a catalog of 9P servers?

[Eric Van Hensbergen]

On Tue, Nov 11, 2008 at 1:18 PM, Bruce Ellis <bruce.ellis@gmail.com> wrote:
> Eric Sir,
>
> That's what I proposed in Madrid when introducing [TR]ext. It cannot
> hurt. Forward unknown transactions. The destination will Rerror on
> crap - it was buggered anyway (as Roy adn HG would say)..
>

Fair enough, what was the op-code(s) for [TR]ext? I need to add them
to my strawman list to make sure I don't inadvertently squash them
with my futzing.  Or add them yourself to the wiki under the 9P2010
entry.

        -eric

Re: [9fans] Do we have a catalog of 9P servers?

[Eric Van Hensbergen]

On Tue, Nov 11, 2008 at 11:54 AM, sqweek <sqweek@gmail.com> wrote:
>>
>> Absolute, complete, utter disaster.  Completely hopeless.
>
>  If corporate acceptance is the new measure of success, maybe we
> should be using an XML based protocol extension.
>

I have two measurements of success:
  a) what keeps me working on Plan 9 related technologies in a paid position
  b) what switches people from using NFS, GPFS, or other horribly
complicated solutions to something closer to Plan 9

.u satisfied both these criteria.  I will judge the success of .L on
similar metrics.

Note that I didn't claim that either were optimal solutions, I'm less
clear on how to quantify such a metric.  Uriel's opinion of their
worth certainly not among the candidates.

            -eric

Re: [9fans] Do we have a catalog of 9P servers?

[ron minnich]

On Tue, Nov 11, 2008 at 9:54 AM, sqweek <sqweek@gmail.com> wrote:

>  If corporate acceptance is the new measure of success, maybe we
> should be using an XML based protocol extension.


Corporate acceptance was always the measure of success. it's the old
measure. And it works, unless you don't need to eat.

ron

Re: [9fans] Do we have a catalog of 9P servers?

[Bruce Ellis]

Eric Sir,

That's what I proposed in Madrid when introducing [TR]ext. It cannot
hurt. Forward unknown transactions. The destination will Rerror on
crap - it was buggered anyway (as Roy adn HG would say)..

brucee

(back in volos, i went the wrong way and got stuck on skiathos)

On Tue, Nov 11, 2008 at 6:02 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote:
> On Tue, Nov 11, 2008 at 9:37 AM, Skip Tavakkolian <9nut@9netics.com> wrote:
>>
>> operations like these (symlink, readlink, lock, etc.) that only have
>> significance at the extremities should not worry the transit relays.
>> that was the reason for Text/Rext proposal.
>>
>> regardless, interpretation of the ops in a hetergeneous environment
>> will be a problem.
>>
>
> Transitive mounts aside, why shouldn't intermediates just forward
> unknown messages?  End-points which receive messages they don't know
> how to deal with just return Error and the client adjusts accordingly.
>  Endpoint interpretation of operations should be well documented to
> prevent silliness and invisible hedgehogs named Dimsdale.
>
> I suppose this is the same thing you are saying, I just want to have
> separate protocol ops for messages versus a single extension op.  I
> suppose the difference is largely an implementation decision assuming
> your protocol operation space is large enough....
>
>           -eric
>
>

Re: [9fans] Do we have a catalog of 9P servers?

[sqweek]

On Wed, Nov 12, 2008 at 2:01 AM, Eric Van Hensbergen <ericvh@gmail.com> wrote:
> On Tue, Nov 11, 2008 at 10:30 AM, Uriel <uriel99@gmail.com> wrote:
>> (Wasn't the disaster of adding .u to p9p a clear enough indication of
>> how hopeless that path is?)
>
> Yes, .u was a disaster which is why the most powerful supercomputer in
> the world is using it for workload distribution and boot-time.  It was
> a failure, that's why its not being integrated into commercial cluster
> toolkits.  It was a failure, that's why its not the current defacto
> standard for Linux paravirtualized file systems.  It was a failure,
> that's why there's an RDMA protocol instance developed by
> third-parties, and that's why its not being looked at being integrated
> into mainframes and why IBM is not considering funding a development
> team to support it.
>
> Absolute, complete, utter disaster.  Completely hopeless.

 If corporate acceptance is the new measure of success, maybe we
should be using an XML based protocol extension.
-sqweek

Re: [9fans] Do we have a catalog of 9P servers?

[Eric Van Hensbergen]

On Tue, Nov 11, 2008 at 10:30 AM, Uriel <uriel99@gmail.com> wrote:
>>
>> operations like these (symlink, readlink, lock, etc.) that only have
>> significance at the extremities should not worry the transit relays.
>> that was the reason for Text/Rext proposal.
>>
>> regardless, interpretation of the ops in a hetergeneous environment
>> will be a problem.
>
> It is not a problem if the ops are Topen/Tread/Twrite (on an
> alternative attach), as agreed at the first iwp9, sadly people seems
> to forget quite easily,
>

While pretty on whiteboards, this becomes a bit of bitch in the
implementation (of both the client and the server).  The reason folks
want to use 9P on Linux (and other non-Plan 9 things) is the protocols
implementation for both client and server is simple and
straightforward.  .u failed because implementing the extensions was an
ugly hack, and it is my belief/experience (yes, I tried implementing
extensions this way) would be a similarly ugly hack that wouldn't be
very useful in the end.  It was based on my experiences with
attempting to code extensions in such a way along with discussions
with others that led to the current experiment of architecting the
extensions as part of the protocol.  Like many things, they are being
developed to satisfy requirements of others so its likely that only a
subset of the operations (if any) will be useful to native Plan 9 or
Inferno.  The structure of the extensions is such that they are easily
ignored by the clients or servers which do not implement them (which
wasn't the case with .u).

>
> (Wasn't the disaster of adding .u to p9p a clear enough indication of
> how hopeless that path is?)
>

Yes, .u was a disaster which is why the most powerful supercomputer in
the world is using it for workload distribution and boot-time.  It was
a failure, that's why its not being integrated into commercial cluster
toolkits.  It was a failure, that's why its not the current defacto
standard for Linux paravirtualized file systems.  It was a failure,
that's why there's an RDMA protocol instance developed by
third-parties, and that's why its not being looked at being integrated
into mainframes and why IBM is not considering funding a development
team to support it.

Absolute, complete, utter disaster.  Completely hopeless.

            -eric

Re: [9fans] Do we have a catalog of 9P servers?

[Eric Van Hensbergen]

On Tue, Nov 11, 2008 at 10:36 AM, Skip Tavakkolian <9nut@9netics.com> wrote:
>> I just want to have
>> separate protocol ops for messages versus a single extension op.  I
>> suppose the difference is largely an implementation decision assuming
>> your protocol operation space is large enough
>
> the thinking is that it's the least polluting -- in regard to 9P
> messages -- while still allowing for many categories of ops.
>
> but almost immediately there has to be a standard for the
> extension message content. maybe it could be XML/SOAP :)
>

I guess the difference between

<extended op> <extended args...>

and

Text <extended op> <extended args...>

is lost on me.  We've (currently) got a large enough op-code space to
satisfy all the Plan 9 operations, all the Octopus variant operations,
all the Linux VFS API, and still have a hundred or so op-codes to
spare.  While I have no doubt the Linux community will figure out a
way to exhaust the number of operations, it is not currently a
practical concern.  Using the protocol version specification in
Tversion you can potentially provide alternate sets of operations, but
I think that's worth avoiding.

            -eric

Re: [9fans] Do we have a catalog of 9P servers?

[ron minnich]

On Tue, Nov 11, 2008 at 8:30 AM, Uriel <uriel99@gmail.com> wrote:

> (Wasn't the disaster of adding .u to p9p a clear enough indication of
> how hopeless that path is?)


no. It just showed that the .u path was wrong. Adding extra ops?
Worked well for me for years, it was easy and simple.

If your idea is better, implement it and show it to us. I'd love to see it.

ron

Re: [9fans] Do we have a catalog of 9P servers?

[Skip Tavakkolian]

> I just want to have
> separate protocol ops for messages versus a single extension op.  I
> suppose the difference is largely an implementation decision assuming
> your protocol operation space is large enough

the thinking is that it's the least polluting -- in regard to 9P
messages -- while still allowing for many categories of ops.

but almost immediately there has to be a standard for the
extension message content. maybe it could be XML/SOAP :)

Re: [9fans] Do we have a catalog of 9P servers?

[Uriel]

On Tue, Nov 11, 2008 at 4:37 PM, Skip Tavakkolian <9nut@9netics.com> wrote:
>> This approach seems to be flawed on two accounts:
>>    1. it forces the server to resolve symlinks and special
>>    nodes, without an option for the client to do the same.
>>    That prevents cross-tree symlinks and nodes as the
>>    points of rendezvous *on the client*. IOW, the following
>>    will not work:
>>       $ mknod <imported FS>/test p
>>       $ echo test >> <imported FS>/test &
>>         cat <imported FS>/test
>>    I can buy a point of view that reading on a node that happens
>>    to be a character device should really bring the data from
>>    the remote server's device attached to that node. However,
>>    that point of view is much more difficult to sell for
>>    FIFOs.
>>
>>    2. It doesn't let manipulate these special files. IOW,
>>    readlink(2) fails and so does mknod(2)/symlink(2).
>
> operations like these (symlink, readlink, lock, etc.) that only have
> significance at the extremities should not worry the transit relays.
> that was the reason for Text/Rext proposal.
>
> regardless, interpretation of the ops in a hetergeneous environment
> will be a problem.

It is not a problem if the ops are Topen/Tread/Twrite (on an
alternative attach), as agreed at the first iwp9, sadly people seems
to forget quite easily, and as brucee points out, lack of vision
prevails, that is what doomed .u and will doom .L and other such silly
and pointless hacks, trying to butcher 9P into becoming FUSE, way to
go, and pray for ten thousand monkeys with typewriters because you
will need them to beat the lunix monkeys at their own game.

(Wasn't the disaster of adding .u to p9p a clear enough indication of
how hopeless that path is?)


Peace

uriel

Re: [9fans] Do we have a catalog of 9P servers?

[Gorka Guardiola]

On Tue, Nov 11, 2008 at 4:28 PM, hiro <23hiro@googlemail.com> wrote:
> I must have missed something. what dav server?
>

We have one for inferno in the octopus. We presented/talked about
it in IWP9 at Volos.



--
- curiosity sKilled the cat

Re: [9fans] Do we have a catalog of 9P servers?

[Eric Van Hensbergen]

On Tue, Nov 11, 2008 at 9:37 AM, Skip Tavakkolian <9nut@9netics.com> wrote:
>
> operations like these (symlink, readlink, lock, etc.) that only have
> significance at the extremities should not worry the transit relays.
> that was the reason for Text/Rext proposal.
>
> regardless, interpretation of the ops in a hetergeneous environment
> will be a problem.
>

Transitive mounts aside, why shouldn't intermediates just forward
unknown messages?  End-points which receive messages they don't know
how to deal with just return Error and the client adjusts accordingly.
 Endpoint interpretation of operations should be well documented to
prevent silliness and invisible hedgehogs named Dimsdale.

I suppose this is the same thing you are saying, I just want to have
separate protocol ops for messages versus a single extension op.  I
suppose the difference is largely an implementation decision assuming
your protocol operation space is large enough....

           -eric

Re: [9fans] Do we have a catalog of 9P servers?

[Skip Tavakkolian]

> This approach seems to be flawed on two accounts:
>    1. it forces the server to resolve symlinks and special
>    nodes, without an option for the client to do the same.
>    That prevents cross-tree symlinks and nodes as the
>    points of rendezvous *on the client*. IOW, the following
>    will not work:
>       $ mknod <imported FS>/test p
>       $ echo test >> <imported FS>/test &
>         cat <imported FS>/test
>    I can buy a point of view that reading on a node that happens
>    to be a character device should really bring the data from
>    the remote server's device attached to that node. However,
>    that point of view is much more difficult to sell for
>    FIFOs.
>
>    2. It doesn't let manipulate these special files. IOW,
>    readlink(2) fails and so does mknod(2)/symlink(2).

operations like these (symlink, readlink, lock, etc.) that only have
significance at the extremities should not worry the transit relays.
that was the reason for Text/Rext proposal.

regardless, interpretation of the ops in a hetergeneous environment
will be a problem.

Re: [9fans] Do we have a catalog of 9P servers?

[hiro]

I must have missed something. what dav server?

hiro

On Tue, Nov 11, 2008 at 9:45 AM, Fco. J. Ballesteros <nemo@lsub.org> wrote:
> For this we use local Infernos at machines serving resources,
> using a dav server to provide the built name space to the native host systems.
> Not for devices, but works for most other things.
> Devices can be done by adapting their interfaces via wrapper FSs.
>
>>
>>  Ok, here's a stab at describing my requirement: imagine a situation
>>  where you need to make access to a large variety of existing external
>>  resources (and I really do mean *variety*) be:
>>   1. transparent to the users
>>   2. independent of the user's environment
>>   3. independent of the location of the users
>>   4. independent of the user's ability to *explicitly* do networking
>>
>>  Most of these existing external resources are already shared using
>>  protocols quite different from 9P. Worse yet, the servers serving
>>  them are not under our control. Thus making them speak 9P at the
>>  end point of a server is not an option.
>>
>>  Now, at this point, one might wonder why not use FUSE and import these
>>  resources directly at the client end-point? The answer is quite simple:
>>  because of MS Windows (#2) and because of the potential inability
>>  to dial out (#4) on demand.
>>
>>  Thanks,
>>  Roman.
>>
>>  P.S. On a similar note I'd like to add that the requirement outlined
>>  above seem to be quite typical in today's world. See, on one hand new
>>  kind of resources (take flickr or youtube as an example) are very
>>  unlikely to be shared using 9P, unless WE can argue that 9P is somehow
>>  radically better (saves bandwidth, etc.) for the resource *maintainer*.
>>  Not an impossible thing to articulate (as some of the responses I've
>>  got to my earlier question indicated -- thank you guys!) but a difficult
>>  one. Why? Well, because the next question you get from the maintainers
>>  is: who can import our resources using 9P on the client side?
>>
>>  I wish 9p:// URL worked out of the box in Firefox, but it doesn't. It is
>>  also not supported by JDK & C#. And even we we stick with the "resources
>>  as regular files" approach on the client you're stuck with mostly POSIX
>>  environment + locking (+caching). POSIX means symlink(2) and mknod(2)
>>  (and locking/caching means a lot of pain and mental masturbation).
>>  Last time I checked, we didn't have consensus on how things like these
>>  are supposed to be handled by 9P.
>>
>>  And finally -- it is ok to say: "they are not supposed to". If that's
>>  our collective answer, that also answers my earlier question -- 9P as
>>  it stands is useless in a situation like I'm in.
>>
>
>

Re: [9fans] Do we have a catalog of 9P servers?

[Fco. J. Ballesteros]

For this we use local Infernos at machines serving resources,
using a dav server to provide the built name space to the native host systems.
Not for devices, but works for most other things.
Devices can be done by adapting their interfaces via wrapper FSs.

>
>  Ok, here's a stab at describing my requirement: imagine a situation
>  where you need to make access to a large variety of existing external
>  resources (and I really do mean *variety*) be:
>   1. transparent to the users
>   2. independent of the user's environment
>   3. independent of the location of the users
>   4. independent of the user's ability to *explicitly* do networking
>
>  Most of these existing external resources are already shared using
>  protocols quite different from 9P. Worse yet, the servers serving
>  them are not under our control. Thus making them speak 9P at the
>  end point of a server is not an option.
>
>  Now, at this point, one might wonder why not use FUSE and import these
>  resources directly at the client end-point? The answer is quite simple:
>  because of MS Windows (#2) and because of the potential inability
>  to dial out (#4) on demand.
>
>  Thanks,
>  Roman.
>
>  P.S. On a similar note I'd like to add that the requirement outlined
>  above seem to be quite typical in today's world. See, on one hand new
>  kind of resources (take flickr or youtube as an example) are very
>  unlikely to be shared using 9P, unless WE can argue that 9P is somehow
>  radically better (saves bandwidth, etc.) for the resource *maintainer*.
>  Not an impossible thing to articulate (as some of the responses I've
>  got to my earlier question indicated -- thank you guys!) but a difficult
>  one. Why? Well, because the next question you get from the maintainers
>  is: who can import our resources using 9P on the client side?
>
>  I wish 9p:// URL worked out of the box in Firefox, but it doesn't. It is
>  also not supported by JDK & C#. And even we we stick with the "resources
>  as regular files" approach on the client you're stuck with mostly POSIX
>  environment + locking (+caching). POSIX means symlink(2) and mknod(2)
>  (and locking/caching means a lot of pain and mental masturbation).
>  Last time I checked, we didn't have consensus on how things like these
>  are supposed to be handled by 9P.
>
>  And finally -- it is ok to say: "they are not supposed to". If that's
>  our collective answer, that also answers my earlier question -- 9P as
>  it stands is useless in a situation like I'm in.
>

Re: [9fans] Do we have a catalog of 9P servers?

[Skip Tavakkolian]

> Perhaps someone should sit down and write an win32 driver for it ;-)

there is one.

Re: [9fans] Do we have a catalog of 9P servers?

[Skip Tavakkolian]

> We have at least three different attempts at solving that: 9P2000.u,
> Skip's Text/Rext and a "parallel tree" approach, but no consensus(*)

Text/Rext are Bruce's idea which he prototyped for Styx.  i might have
asked for something more crude to deal with lock requests.

Re: [9fans] Do we have a catalog of 9P servers?

[sqweek]

On Tue, Nov 11, 2008 at 11:40 AM, Enrico Weigelt <weigelt@metux.de> wrote:
> * Robert Raschke <rtrlists@googlemail.com> wrote:
>> On Mon, Nov 10, 2008 at 6:26 AM, Enrico Weigelt <weigelt@metux.de> wrote:
>> > * sqweek <sqweek@gmail.com> wrote:
>> >>  Everyone has write access to the plan 9 wiki.
>> >
>> > hmm, perhaps I didn't look hard enough, but I didn't see anything
>> > like an "edit" button etc ... ;-o
>>
>> Put in Acme Wiki.
>
> Just curious: does this also work w/ p9p (don't have native Plan9
> running) ? What exactly do I have to type in ?

 Nope, it's not included with p9p. Might be in 9vx, but I haven't
checked. You can still mount the wiki of course, but I couldn't tell
you how to edit it without the acme interface.
http://netlib.bell-labs.com/magic/man2html/4/wikifs probably can. See
http://plan9.bell-labs.com/sources/plan9/rc/bin/9fs and
http://plan9.bell-labs.com/sources/plan9/lib/ndb/common for the rest
of the puzzle.
-sqweek

Re: [9fans] Do we have a catalog of 9P servers?

[Enrico Weigelt]

* Robert Raschke <rtrlists@googlemail.com> wrote:
> On Mon, Nov 10, 2008 at 6:26 AM, Enrico Weigelt <weigelt@metux.de> wrote:
> > * sqweek <sqweek@gmail.com> wrote:
> >>  Everyone has write access to the plan 9 wiki.
> >
> > hmm, perhaps I didn't look hard enough, but I didn't see anything
> > like an "edit" button etc ... ;-o
>
> Put in Acme Wiki.

Just curious: does this also work w/ p9p (don't have native Plan9
running) ? What exactly do I have to type in ?


thx
--
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 cellphone: +49 174 7066481   email: info@metux.de   skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: [9fans] Do we have a catalog of 9P servers?

[Lyndon Nerenberg]

> Actually, I've got flickr-9P on my 2do-list [ ... ]

Is there any hope of re-winding the clock back to some time pre-
September?

Re: [9fans] Do we have a catalog of 9P servers?

[Enrico Weigelt]

* Charles Forsyth <forsyth@terzarima.net> wrote:
> >So we IMHO should learn from all the big "community" projects how
> >to attract people and get them involved with minimal effort. It's
> >not for us, it's for them ...
>
> i know, but have you spoken to the auther of the comment below:
>
> >Mozilla folks aren't very open to innovation (no matter how old/mature
> >this innovation already is), but at least I've still got some hope ;)
>
> hey! it was you!

I didn't say we should learn from Mozilla ... ;-o

> that's more my experience with Apache and Perl, so far,
> and not even for `innovation', just getting their stuff going
> on Windows.

Yeah, they're even incapable of writing clean makefiles ;-o


cu
--
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 cellphone: +49 174 7066481   email: info@metux.de   skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: [9fans] Do we have a catalog of 9P servers?

[Enrico Weigelt]

* Roman V. Shaposhnik <rvs@sun.com> wrote:

> P.S. On a similar note I'd like to add that the requirement outlined
> above seem to be quite typical in today's world. See, on one hand new
> kind of resources (take flickr or youtube as an example) are very

Actually, I've got flickr-9P on my 2do-list (but still lacking time
for it yet). And my media hosting platform will also get an 9P interface.

> Not an impossible thing to articulate (as some of the responses I've
> got to my earlier question indicated -- thank you guys!) but a difficult
> one. Why? Well, because the next question you get from the maintainers
> is: who can import our resources using 9P on the client side?

Perhaps someone should sit down and write an win32 driver for it ;-)
Linux has 9P support, BSD too (IMHO). And also some common userland
apps like Midnight Commander (not in mainline yet, but that's coming).

> I wish 9p:// URL worked out of the box in Firefox, but it doesn't.

I've did some pieces for Seamonkey. (but not stable yet).

> It is also not supported by JDK & C#.

That's under way, feel free to jump on the train :)
Maybe, once I've got jmixp up and running, I'll port it to flex ;-o


cu
--
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 cellphone: +49 174 7066481   email: info@metux.de   skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: [9fans] Do we have a catalog of 9P servers?

[Bruce Ellis]

Why does your build fail? Lack of vision to the extreme resulting in a
completely horrible way of building things that has grew and grew to
something that not even its mother could not love.

In some sense it's good that it fails. If you want to build things
that way then don't use plan9. Seriously. The simplest program is now
entangled in the most horrendous config/build mess. Why? Because
that's how you do things. No!!!

"Hideous, horrible!" - as a friend at the Labs would shout (not about
CS, he was a physicist).

As for mknod, I don't think it's worth trying to keep that alive, let
alone breaking plan9 to do it.

brucee

On Tue, Nov 11, 2008 at 3:00 AM, Roman V. Shaposhnik <rvs@sun.com> wrote:
> On Tue, 2008-11-11 at 00:14 +0000, Charles Forsyth wrote:
>> >But wouldn't you agree that files kept on a remote POSIX file system is
>> >an important and common class of remotes resources for which we don't
>> >quite have a consensus on how to use 9P?
>>
>> yes, but both your examples are things of purely local significance.
>
> Sorry I'm confused, which examples are you talking about? Anyway, for
> the sake of this conversation lets focus on: using 9P as the means to
> access files on a remote POSIX filesystem.
>
>> the symbolic links point to something local (or not), and the major/minor
>> numbers are decidedly only local (since they index a kernel's data structures!).
>> sorry, to which they refer.
>
> This approach seems to be flawed on two accounts:
>   1. it forces the server to resolve symlinks and special
>   nodes, without an option for the client to do the same.
>   That prevents cross-tree symlinks and nodes as the
>   points of rendezvous *on the client*. IOW, the following
>   will not work:
>      $ mknod <imported FS>/test p
>      $ echo test >> <imported FS>/test &
>        cat <imported FS>/test
>   I can buy a point of view that reading on a node that happens
>   to be a character device should really bring the data from
>   the remote server's device attached to that node. However,
>   that point of view is much more difficult to sell for
>   FIFOs.
>
>   2. It doesn't let manipulate these special files. IOW,
>   readlink(2) fails and so does mknod(2)/symlink(2).
>
> For the practical application of 9P a failing symlink(2) is a big
> source of problems.
>
> In fact, "why does my build fail" was the first question that people
> asked me once I demonstrated my prototype of drawterm written in
> Java. It fails because it tries to symlink within a tree that
> is exported.
>
> Thanks,
> Roman.
>
>
>

Re: [9fans] Do we have a catalog of 9P servers?

[Roman V. Shaposhnik]

On Tue, 2008-11-11 at 00:14 +0000, Charles Forsyth wrote:
> >But wouldn't you agree that files kept on a remote POSIX file system is
> >an important and common class of remotes resources for which we don't
> >quite have a consensus on how to use 9P?
>
> yes, but both your examples are things of purely local significance.

Sorry I'm confused, which examples are you talking about? Anyway, for
the sake of this conversation lets focus on: using 9P as the means to
access files on a remote POSIX filesystem.

> the symbolic links point to something local (or not), and the major/minor
> numbers are decidedly only local (since they index a kernel's data structures!).
> sorry, to which they refer.

This approach seems to be flawed on two accounts:
   1. it forces the server to resolve symlinks and special
   nodes, without an option for the client to do the same.
   That prevents cross-tree symlinks and nodes as the
   points of rendezvous *on the client*. IOW, the following
   will not work:
      $ mknod <imported FS>/test p
      $ echo test >> <imported FS>/test &
        cat <imported FS>/test
   I can buy a point of view that reading on a node that happens
   to be a character device should really bring the data from
   the remote server's device attached to that node. However,
   that point of view is much more difficult to sell for
   FIFOs.

   2. It doesn't let manipulate these special files. IOW,
   readlink(2) fails and so does mknod(2)/symlink(2).

For the practical application of 9P a failing symlink(2) is a big
source of problems.

In fact, "why does my build fail" was the first question that people
asked me once I demonstrated my prototype of drawterm written in
Java. It fails because it tries to symlink within a tree that
is exported.

Thanks,
Roman.

Re: [9fans] Do we have a catalog of 9P servers?

[Eric Van Hensbergen]

On Mon, Nov 10, 2008 at 6:19 PM, ron minnich <rminnich@gmail.com> wrote:
> On Mon, Nov 10, 2008 at 3:45 PM, Roman V. Shaposhnik <rvs@sun.com> wrote:
>
>> We have at least three different attempts at solving that: 9P2000.u,
>> Skip's Text/Rext and a "parallel tree" approach, but no consensus(*)
>>
>
> four. My original v9fs added 3 ops for supporting symlinks and
> hardlinks. There was no option.
>

Soon to be 5.  9P.L coming soon to the dismay of Uriels everywhere...

                   -eric

Re: [9fans] Do we have a catalog of 9P servers?

[ron minnich]

On Mon, Nov 10, 2008 at 3:45 PM, Roman V. Shaposhnik <rvs@sun.com> wrote:

> We have at least three different attempts at solving that: 9P2000.u,
> Skip's Text/Rext and a "parallel tree" approach, but no consensus(*)
>

four. My original v9fs added 3 ops for supporting symlinks and
hardlinks. There was no option.

ron

Re: [9fans] Do we have a catalog of 9P servers?

[Charles Forsyth]

>But wouldn't you agree that files kept on a remote POSIX file system is
>an important and common class of remotes resources for which we don't
>quite have a consensus on how to use 9P?

yes, but both your examples are things of purely local significance.
the symbolic links point to something local (or not), and the major/minor
numbers are decidedly only local (since they index a kernel's data structures!).
so: access the things they refer to.
sorry, to which they refer.

Re: [9fans] Do we have a catalog of 9P servers?

[Roman V. Shaposhnik]

On Mon, 2008-11-10 at 23:38 +0000, C H Forsyth wrote:
> >And even we we stick with the "resources
> >as regular files" approach on the client you're stuck with mostly POSIX
> >environment + locking (+caching). POSIX means symlink(2) and mknod(2)
>
> no, because (unless i've misunderstood) they are accessing resources
> (as regular files) on a remote server, and symbolic links and
> outdated major/minor are irrelevant and not needed.

Agreed. That's why I didn't include this bit in the main set of
requirements.

But wouldn't you agree that files kept on a remote POSIX file system is
an important and common class of remotes resources for which we don't
quite have a consensus on how to use 9P?

We have at least three different attempts at solving that: 9P2000.u,
Skip's Text/Rext and a "parallel tree" approach, but no consensus(*)

Thanks,
Roman.

Re: [9fans] Do we have a catalog of 9P servers?

[C H Forsyth]

>And even we we stick with the "resources
>as regular files" approach on the client you're stuck with mostly POSIX
>environment + locking (+caching). POSIX means symlink(2) and mknod(2)

no, because (unless i've misunderstood) they are accessing resources
(as regular files) on a remote server, and symbolic links and
outdated major/minor are irrelevant and not needed.

Re: [9fans] Do we have a catalog of 9P servers?

[Roman V. Shaposhnik]

On Sun, 2008-11-09 at 11:26 +0000, Steve Simon wrote:
> How about if you start a page with a list of the 9p
> file servers you know of, say on the plan9 wiki, and
> then email 9fans asking them to add any that you have
> missed?

That's the plan!

> I can see how such a thing might be a useful resource
> to people on the list as well as a promotional tool.
> It could also (perhaps) focus attention of those with
> time and interest towards the best ones to tackle next.

I can do whatever cataloging is necessary, that's not a
problem.

Describing the applications and limitations of 9P on the
other hand, feels like something that would belong to:
   http://en.wikipedia.org/wiki/9P
and I would really feel much more comfortable if some of
the "founding fathers" can take a stab at it first.

Thanks,
Roman.

P.S. Or am I not appreciating the collaborative nature of the
Wikipedia? :-)

Re: [9fans] Do we have a catalog of 9P servers?

[Roman V. Shaposhnik]

On Mon, 2008-11-10 at 15:17 +0900, sqweek wrote:
> On Mon, Nov 10, 2008 at 2:50 PM, Enrico Weigelt <weigelt@metux.de> wrote:
> > * Steve Simon <steve@quintile.net> wrote:
> >
> >> How about if you start a page with a list of the 9p
> >> file servers you know of, say on the plan9 wiki, and
> >> then email 9fans asking them to add any that you have
> >> missed?
> >
> > If I had write access, I'd just did it ;-o
>
>  Everyone has write access to the plan 9 wiki.

plan 9 wiki is a very good suggestion. I would like to start
such a topic there. I do have 2 questions though:
   1. It doesn't seem to allow anonymous edits:
   I tried:
     http://netlib.bell-labs.com/wiki/plan9/sandbox/edit.html
   and all I got was:
     http://netlib.bell-labs.com/magic/wikipost
     Object not found
     The object does not exist on this server.

     errstr: '/bin/ip/httpd/wikipost' does not exist
     uri host:
     header host:
     actual host: plan9.bell-labs.com
   Direct edits from my Acme also don't seem to work.

   2. When/if it works what would be the appropriate place
   to stick that topic into?

> > Meanwhile I've just added my 9P libs (libmixp, libmixpsrv)
> > to the 9P page @ wikipedia - probably a good starting point, too.
> >
> > But if we're talking about 9P/Styx in general (not specifically
> > on Plan9 or Inferno), it might be wise to set up a sepate website.
> > This site should also contain information on topics like what 9P
> > is really good for and why application developers should use it :)
> >
> > Just let me know if you'd like to feed some input to such a site,
> > and I'll set up one.
>
>  http://9p.cat-v.org is halfway there, makes more sense to improve
> that than start a new site.

Agreed. In fact, halfway is a very accurate description ;-) It already
has http://9p.cat-v.org/implementations, but it still lacks what I
would call a "servers" page.

> Get in touch with Uriel if you want something on there that isn't already there,

That would be http://9p.cat-v.org/servers linked from his Left-hand-side
menu. Speaking of getting in touch with Uriel -- is he not subscribed
to this list? ;-) Or well, I'll CC him ;-)

>  or if you want to make
> his life easy you can send a patch to the document source. You can get
> the source by appending .md to the url (eg
> http://9p.cat-v.org/implementations.md or http://9p.cat-v.org/index.md
> ) - they are written in markdown[1] syntax. Also he has something in
> the works to enable editing via http, which I believe is implemented
> but needs testing...

Thanks for the .md suggestion. One thing that I clearly see missing on
the implementations page is the Java implementation done at LSUB.

Thanks,
Roman.

Re: [9fans] Do we have a catalog of 9P servers?

[Anant Narayanan]

On 10-Nov-08, at 10:56 PM, Roman V. Shaposhnik wrote:
> I wish 9p:// URL worked out of the box in Firefox, but it doesn't.

Shameless plug:
It does if you install the Angled extension: http://www.kix.in/projects/web9/
Ok, I lied - ninep:// works, 9p:// doesn't :)

--
Anant

Re: [9fans] Do we have a catalog of 9P servers?

[Roman V. Shaposhnik]

On Sat, 2008-11-08 at 06:47 -0500, erik quanstrom wrote:
> > Sure. But that would an argument in favor of the Plan 9/Inferno
> > kernel architecture, not the protocol itself. Nobody's denying
> > that 9P is a perfect match to that kind of kernel architecture.
> > What I'm trying to find out is whether the protocol could stand
> > its own ground even if Plan9 kernel is not serving nor muxing it.
>
> this depends entirely on your criteria and constraints.

Ok, here's a stab at describing my requirement: imagine a situation
where you need to make access to a large variety of existing external
resources (and I really do mean *variety*) be:
   1. transparent to the users
   2. independent of the user's environment
   3. independent of the location of the users
   4. independent of the user's ability to *explicitly* do networking

Most of these existing external resources are already shared using
protocols quite different from 9P. Worse yet, the servers serving
them are not under our control. Thus making them speak 9P at the
end point of a server is not an option.

Now, at this point, one might wonder why not use FUSE and import these
resources directly at the client end-point? The answer is quite simple:
because of MS Windows (#2) and because of the potential inability
to dial out (#4) on demand.

Thanks,
Roman.

P.S. On a similar note I'd like to add that the requirement outlined
above seem to be quite typical in today's world. See, on one hand new
kind of resources (take flickr or youtube as an example) are very
unlikely to be shared using 9P, unless WE can argue that 9P is somehow
radically better (saves bandwidth, etc.) for the resource *maintainer*.
Not an impossible thing to articulate (as some of the responses I've
got to my earlier question indicated -- thank you guys!) but a difficult
one. Why? Well, because the next question you get from the maintainers
is: who can import our resources using 9P on the client side?

I wish 9p:// URL worked out of the box in Firefox, but it doesn't. It is
also not supported by JDK & C#. And even we we stick with the "resources
as regular files" approach on the client you're stuck with mostly POSIX
environment + locking (+caching). POSIX means symlink(2) and mknod(2)
(and locking/caching means a lot of pain and mental masturbation).
Last time I checked, we didn't have consensus on how things like these
are supposed to be handled by 9P.

And finally -- it is ok to say: "they are not supposed to". If that's
our collective answer, that also answers my earlier question -- 9P as
it stands is useless in a situation like I'm in.

Re: [9fans] Do we have a catalog of 9P servers?

[Charles Forsyth]

>So we IMHO should learn from all the big "community" projects how
>to attract people and get them involved with minimal effort. It's
>not for us, it's for them ...

i know, but have you spoken to the auther of the comment below:

>Mozilla folks aren't very open to innovation (no matter how old/mature
>this innovation already is), but at least I've still got some hope ;)

hey! it was you!

that's more my experience with Apache and Perl, so far,
and not even for `innovation', just getting their stuff going on Windows.

Re: [9fans] Do we have a catalog of 9P servers?

[Robert Raschke]

On Mon, Nov 10, 2008 at 6:26 AM, Enrico Weigelt <weigelt@metux.de> wrote:
> * sqweek <sqweek@gmail.com> wrote:
>>  Everyone has write access to the plan 9 wiki.
>
> hmm, perhaps I didn't look hard enough, but I didn't see anything
> like an "edit" button etc ... ;-o

Put in Acme Wiki.

Re: [9fans] Do we have a catalog of 9P servers?

[Enrico Weigelt]

* sqweek <sqweek@gmail.com> wrote:
> On Mon, Nov 10, 2008 at 2:50 PM, Enrico Weigelt <weigelt@metux.de> wrote:
> > * Steve Simon <steve@quintile.net> wrote:
> >
> >> How about if you start a page with a list of the 9p
> >> file servers you know of, say on the plan9 wiki, and
> >> then email 9fans asking them to add any that you have
> >> missed?
> >
> > If I had write access, I'd just did it ;-o
>
>  Everyone has write access to the plan 9 wiki.

hmm, perhaps I didn't look hard enough, but I didn't see anything
like an "edit" button etc ... ;-o

> http://9p.cat-v.org is halfway there, makes more sense to improve
> that than start a new site. Get in touch with Uriel if you want
> something on there that isn't already there, or if you want to make
> his life easy you can send a patch to the document source. You can get
> the source by appending .md to the url (eg
> http://9p.cat-v.org/implementations.md or http://9p.cat-v.org/index.md
> ) - they are written in markdown[1] syntax. Also he has something in
> the works to enable editing via http, which I believe is implemented
> but needs testing...

Okay, I'll get back to it in a few days. But this site clearly has
a big bottleg when it comes to collaboration, because Uriel has to
maintain that all.

I'd really like to get the whole 9P topic to very broad audience.
My suggested site isn't actually for us, who are on this list, but
those who aren't, those wo probably hear about 9P the first time.
So we IMHO should learn from all the big "community" projects how
to attract people and get them involved with minimal effort. It's
not for us, it's for them ...
(a psychological, not a technical decision).


cu
--
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 cellphone: +49 174 7066481   email: info@metux.de   skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: [9fans] Do we have a catalog of 9P servers?

[Enrico Weigelt]

* Anant Narayanan <anant@kix.in> wrote:

> I must say that it is highly unlikely that Mozilla will adopt the path
> of splitting the "monolithic app into a bunch of fileservers" simply
> because that would involve a lot work, and potentially a lot code to
> be written from scratch.

Well, let's see. I'll try to use the current discussions to push 9P in.
Mozilla folks aren't very open to innovation (no matter how old/mature
this innovation already is), but at least I've still got some hope ;)

Of course this will take a while, but it can be done.
(give me, lets say, 10 good devs for about half a year, and I'll
show you ;-P)

I don't want a completely modularized / splitted Mozilla (not yet),
moving out things like web access (-> webfs), profile handling (so many
separate instances can run simultaniously), plugins (webfs, rio, ...)
would alreay be a HUGE advantage.

Everyone of you can help by just advocating 9P and demonstrating
what it can do :)


cu
--
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 cellphone: +49 174 7066481   email: info@metux.de   skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: [9fans] Do we have a catalog of 9P servers?

[sqweek]

On Mon, Nov 10, 2008 at 2:50 PM, Enrico Weigelt <weigelt@metux.de> wrote:
> * Steve Simon <steve@quintile.net> wrote:
>
>> How about if you start a page with a list of the 9p
>> file servers you know of, say on the plan9 wiki, and
>> then email 9fans asking them to add any that you have
>> missed?
>
> If I had write access, I'd just did it ;-o

 Everyone has write access to the plan 9 wiki.

> Meanwhile I've just added my 9P libs (libmixp, libmixpsrv)
> to the 9P page @ wikipedia - probably a good starting point, too.
>
> But if we're talking about 9P/Styx in general (not specifically
> on Plan9 or Inferno), it might be wise to set up a sepate website.
> This site should also contain information on topics like what 9P
> is really good for and why application developers should use it :)
>
> Just let me know if you'd like to feed some input to such a site,
> and I'll set up one.

 http://9p.cat-v.org is halfway there, makes more sense to improve
that than start a new site. Get in touch with Uriel if you want
something on there that isn't already there, or if you want to make
his life easy you can send a patch to the document source. You can get
the source by appending .md to the url (eg
http://9p.cat-v.org/implementations.md or http://9p.cat-v.org/index.md
) - they are written in markdown[1] syntax. Also he has something in
the works to enable editing via http, which I believe is implemented
but needs testing...

[1] http://daringfireball.net/projects/markdown/syntax

-sqweek

Re: [9fans] Do we have a catalog of 9P servers?

[Skip Tavakkolian]

> Right now, there's an discussion about moving things into their own
> processes (eg. one process per tab) @ dev-platform@lists.mozilla.org,
> and I just digged out my (old but still unrecognized) point of using
> 9P as IPC and splitting off the currently monolithic app into a bunch
> of fileservers.

maybe replace the underlying code for XPCOM and ease them into it.
you'll need an IDL compiler that generates 9p server templates -- most
of which is in 9p(2) -- and the stub functions for the client side.
instead of searching the registry for COM objects, look in /srv, etc.

that said, it seems leaving the complexity of COM in place is
a backward step.

Re: [9fans] Do we have a catalog of 9P servers?

[Anant Narayanan]

On 10-Nov-08, at 6:26 AM, Enrico Weigelt wrote:
> Right now, there's an discussion about moving things into their own
> processes (eg. one process per tab) @ dev-platform@lists.mozilla.org,
> and I just digged out my (old but still unrecognized) point of using
> 9P as IPC and splitting off the currently monolithic app into a bunch
> of fileservers.

I must say that it is highly unlikely that Mozilla will adopt the path
of splitting the "monolithic app into a bunch of fileservers" simply
because that would involve a lot work, and potentially a lot code to
be written from scratch.

There's some history from the old netscape days here; 6.0 bombed
because they decided to rewrite everything: http://www.joelonsoftware.com/articles/fog0000000069.html

Lesson learned. No matter how "messy" the Mozilla code looks, there is
simply no way the developers would agree to a major redesign of the
Mozilla architecture. Solutions that easily "fit into" the existing
codebase would be more than welcomed, and I am sure somebody will come
up with it.

--
Anant

Re: [9fans] Do we have a catalog of 9P servers?

[Enrico Weigelt]

* Steve Simon <steve@quintile.net> wrote:

> How about if you start a page with a list of the 9p
> file servers you know of, say on the plan9 wiki, and
> then email 9fans asking them to add any that you have
> missed?

If I had write access, I'd just did it ;-o
Meanwhile I've just added my 9P libs (libmixp, libmixpsrv)
to the 9P page @ wikipedia - probably a good starting point, too.

But if we're talking about 9P/Styx in general (not specifically
on Plan9 or Inferno), it might be wise to set up a sepate website.
This site should also contain information on topics like what 9P
is really good for and why application developers should use it :)

Strange as it sounds, but today everyone seems to live in dozens
of "community portals" (yeah, that funny overblotat sites with
lots of bad excuses for not doing your real work ;-o), so I tend
to prefer an little Joomla over Wiki ;-)

Just let me know if you'd like to feed some input to such a site,
and I'll set up one.


cu
--
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 cellphone: +49 174 7066481   email: info@metux.de   skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: [9fans] Do we have a catalog of 9P servers?

[Enrico Weigelt]

* Roman Shaposhnik <rvs@sun.com> wrote:

Hi,

> See that's the problem. I was asking for the arguments that might
> help me convince somebody who hasn't ever been exposed
> to Plan9/Inferno OSes (and hasn't ever been on this list) to
> consider 9P (as a protocol) to be added (as a fronted) to a major
> service that Sun wants to roll out. Personally, I ran  out of
> ammo.

Actually, I'm even going some steps further and advocating 9P and
the idea of representing resources just as filesystem hierachy as
a generic and elegant way of IPC in complex applications, eg. Mozilla.

Right now, there's an discussion about moving things into their own
processes (eg. one process per tab) @ dev-platform@lists.mozilla.org,
and I just digged out my (old but still unrecognized) point of using
9P as IPC and splitting off the currently monolithic app into a bunch
of fileservers.

Perhaps some of you like to subscribe there and jump at my side ;)


cu
--
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 cellphone: +49 174 7066481   email: info@metux.de   skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: [9fans] Do we have a catalog of 9P servers?

[Bruce Ellis]

Transitive trust is metastable. "I trust him. Hold on - do I trust who
he trusts" etc.

brucee

On Mon, Nov 10, 2008 at 12:13 AM, Skip Tavakkolian <9nut@9netics.com> wrote:
>>>also, it assumes that the vm/vs
>>>service provider will be able to provide as good or better quality of
>>>service as you would maintaining your own infrastructure.
>>
>> also that they are as sound as a bank and just as unlikely to go bust.
>> wait a minute ...
>
> exactly; that also crossed my mind.  there's the analogous potential
> pitfall of counting on service providers that count on other service
> providers and soon a problem affecting somebody who's tangentially
> involved in your service could bring down your business.
>
>
>

Re: [9fans] Do we have a catalog of 9P servers?

[Skip Tavakkolian]

>>also, it assumes that the vm/vs
>>service provider will be able to provide as good or better quality of
>>service as you would maintaining your own infrastructure.
>
> also that they are as sound as a bank and just as unlikely to go bust.
> wait a minute ...

exactly; that also crossed my mind.  there's the analogous potential
pitfall of counting on service providers that count on other service
providers and soon a problem affecting somebody who's tangentially
involved in your service could bring down your business.

Re: [9fans] Do we have a catalog of 9P servers?

[Bruce Ellis]

cool, i think that was the code they were really looking for.

the transcript is funny huh? "yada yada" is transcribed as something
very funny, like yattata. was there a video?

brucee

On Sun, Nov 9, 2008 at 10:39 PM, C H Forsyth <forsyth@vitanuova.com> wrote:
>>I did some work on it when in the Inferno Business  Unit,
>>based on my journalfs. As far as I can tell it doesn't appear in the
>>Vita distribution.
>
> no, i don't think i ever saw it, and at one stage i had a look round
> the file stores we inherited to see if there were any interesting things
> that the business unit unaccountably hadn't included.
> i have got the kilcullen talk about sessionfs (25 Feb 1998).
>
>

Re: [9fans] Do we have a catalog of 9P servers?

[C H Forsyth]

>also, it assumes that the vm/vs
>service provider will be able to provide as good or better quality of
>service as you would maintaining your own infrastructure.

also that they are as sound as a bank and just as unlikely to go bust.
wait a minute ...

Re: [9fans] Do we have a catalog of 9P servers?

[C H Forsyth]

>I did some work on it when in the Inferno Business  Unit,
>based on my journalfs. As far as I can tell it doesn't appear in the
>Vita distribution.

no, i don't think i ever saw it, and at one stage i had a look round
the file stores we inherited to see if there were any interesting things
that the business unit unaccountably hadn't included.
i have got the kilcullen talk about sessionfs (25 Feb 1998).

Re: [9fans] Do we have a catalog of 9P servers?

[Bruce Ellis]

That's actually not too hard (data retention and confidentiality
policies). I did some work on it when in the Inferno Business  Unit,
based on my journalfs. As far as I can tell it doesn't appear in the
Vita distribution. Maybe it was lost. The design satified bank
regulations.

When I left the Unit(s) and went upstairs I was confused for weeks by
questions about "where is this", "where is that". /home/brucee/src I
would say (IBU used Suns and god knows what else).

It turned out that some pointy headed sys admin had deleted my home
directory. OK then thhe backups. NO! Our home directories were never
backed up! I told the VP that if that disk crashed he would lose over
a $1 million of work. Things may have changed then - but I doubt it.
At least two sysadmins were sacked from that unit, a rare thing at the
Labs.

If someone needs something like this I might be able to find some
code, on a ZIP disk that probably won't work.

brucee

On Sun, Nov 9, 2008 at 8:12 AM, erik quanstrom <quanstro@quanstro.net> wrote:
>> purely virtual infrastructure for rolling out services is a good idea
>> but the pieces aren't there yet.  also, it assumes that the vm/vs
>> service provider will be able to provide as good or better quality of
>> service as you would maintaining your own infrastructure.
>
> one also needs to deal with data retention and confidentiality
> issues more directly.  neither fossil nor ken's fs were designed with
> this in mind.
>
> - erik
>
>

Re: [9fans] Do we have a catalog of 9P servers?

[Steve Simon]

How about if you start a page with a list of the 9p
file servers you know of, say on the plan9 wiki, and
then email 9fans asking them to add any that you have
missed?

I can see how such a thing might be a useful resource
to people on the list as well as a promotional tool.
It could also (perhaps) focus attention of those with
time and interest towards the best ones to tackle next.

"best" in this context is of course a moveable feast.

just my 2cents worth

-Steve

Re: [9fans] Do we have a catalog of 9P servers?

[erik quanstrom]

> purely virtual infrastructure for rolling out services is a good idea
> but the pieces aren't there yet.  also, it assumes that the vm/vs
> service provider will be able to provide as good or better quality of
> service as you would maintaining your own infrastructure.

one also needs to deal with data retention and confidentiality
issues more directly.  neither fossil nor ken's fs were designed with
this in mind.

- erik

Re: [9fans] Do we have a catalog of 9P servers?

[Skip Tavakkolian]

> I wrote a functional 9P S3 client but it just seemed silly in the end.
> Buy a few T of disk and fossil+venti and it's over. Even aging kenfs
> will do.
>
> brucee

and the Coraid boxes are an excellent option.

purely virtual infrastructure for rolling out services is a good idea
but the pieces aren't there yet.  also, it assumes that the vm/vs
service provider will be able to provide as good or better quality of
service as you would maintaining your own infrastructure.

Re: [9fans] Do we have a catalog of 9P servers?

[Bakul Shah]

> It's not just the PHBs. I showed the original 9p (for 2.0.36) in 1998
> to a fair number of linux people, and back then I had private name
> spaces, union mounts, user level servers, in fact just about all you
> get in plan 9 today and STILL don't get in linux.
>
> They were strongly convinced there was no use for userland file
> systems, or union mounts, or private name spaces, or any of this
> stuff. They kept pointing to things that Linux did that were not at
> all what I was showing them, saying "we already do that". At some
> point I gave up. Years later, FUSE comes along, and ... well you know
> the story.

It is always the same story.  People like shiny baubles.
Stuff they can relate to and/or show off to their friends.
You just can't sell them on simplicity or flexibility.  They
don't care.  If they did, they'd already be using plan9!

If you want to sell them on 9P, build some shiny baubles they
might want. Build a 9p client for iphone. Build a wireless 9p
camera.  Build something like openFrameworks.cc but simpler.
People use it for all sorts of things including "spray
painting" graffiti on skyscrapers -- see examples @
GraffitiResearchLab.com.  Look at what Johny Lee has done
with wiimote @ http://www.cs.cmu.edu/~johnny/projects/wii/

People are making lots of new fun, creative uses of computers
& IO devices.  A simple building block framework can be very
useful here and it will be a while before FUSE gets here!

Re: [9fans] Do we have a catalog of 9P servers?

[LiteStar numnums]

[-- Attachment #1: Type: text/plain, Size: 2155 bytes --]

Well they took Cyclone & made Vault C, so they might as well go along with
Inferno/Plan9 too. Interestingly enough, Singularity is written in Sing#,
yet another MS-specific language. ugh. I think F# is the only thing to have
recently escaped MSR (well, besides LINQ, although they killed Comega).


On Sat, Nov 8, 2008 at 1:32 PM, <akumar@sounine.nanosouffle.net> wrote:

> Well, they do have a branch called "MicroSoft Research" that they seem
> fond of putting money into.  And apparently, a portion of that has
> gone into making an Inferno/Plan 9 -equivalent, thus far dubbed, "MS
> Singularity".  Development has been going on for quite some time, it
> seems.  Think it'll outweigh what we have going with Plan 9?
>
>
> ---------- Forwarded message ----------
> From: Brantley Coile <brantley@coraid.com>
> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
> Date: Sat, 8 Nov 2008 13:27:08 -0500
> Subject: Re: [9fans] Do we have a catalog of 9P servers?
> And don't forget MS' programming motto, 'Don't think; Type!'
>
> On Nov 8, 2008, at 12:21 PM, Skip Tavakkolian wrote:
>
>  It seems that MS is pushing webdav hard.
>>>>
>>>
>>> that's what's needed when heavy things run out of fuel.
>>>
>>
>> to paraphrase Edison, MS' genius is 1% development and 99% marketing.
>>
>>
>>
>>
>
>


--
And in the "Only Prolog programmers will find this funny" department:

Q: How many Prolog programmers does it take to change a lightbulb?

A: No.
 -- Ovid

   "By cosmic rule, as day yields night, so winter summer, war peace, plenty
famine. All things change. Air penetrates the lump of myrrh, until the
joining bodies die and rise again in smoke called incense."

   "Men do not know how that which is drawn in different directions
harmonises with itself. The harmonious structure of the world depends upon
opposite tension like that of the bow and the lyre."

   "This universe, which is the same for all, has not been made by any god
or man, but it always has been, is, and will be an ever-living fire,
kindling itself by regular measures and going out by regular measures"
-- Heraclitus

[-- Attachment #2: Type: text/html, Size: 3194 bytes --]

Re: [9fans] Do we have a catalog of 9P servers?

[Roman Shaposhnik]

On Nov 8, 2008, at 3:11 PM, erik quanstrom wrote:
>>> Even as a potential substitute for ftp webdav is a farce.  Speaking
>>> from personal experience, the amount of XML you need to generate
>>> for a
>>> directory listing is at least 20 times the size of the equivalent
>>> ftp
>>> listing, and then you twiddle your thumbs waiting for the webdav
>>> client to parse and render it.
>>
>> But think about this: why would you care if you have this:
>>     http://noedler.de/projekte/wdfs/
>>
>> Why would anyone care about what's getting pushed to the
>> wire?
>
> i think most everyone here inderstands why one would.

See that's the problem. I was asking for the arguments that might
help me convince somebody who hasn't ever been exposed
to Plan9/Inferno OSes (and hasn't ever been on this list) to
consider 9P (as a protocol) to be added (as a fronted) to a major
service that Sun wants to roll out. Personally, I ran  out of
ammo.

You're now telling me that  such a knowledge can only be had via the
process of osmosis. That there are no arguments to be used.
That's fair. This process of osmosis is what makes me read this
list to begin with.

But wouldn't you agree, that in all fairness, if the only people who
want to
see 9P being spoken by any piece of software or hardware are the ones
subscribed to the list -- it is not worth implementing?

> let's let this thread die in peace.


Sure. I'm about to write a reply to the question of requirements
and I would be happy to take the answers off the list.

Sorry to be a bother.

Thanks,
Roman.

Re: [9fans] Do we have a catalog of 9P servers?

[Mechiel Lukkien]

On Sat, Nov 08, 2008 at 02:16:39PM -0800, Roman Shaposhnik wrote:
> On Nov 8, 2008, at 11:15 AM, John Barham wrote:
> >>>It seems that MS is pushing webdav hard.
> >>
> >>that's what's needed when heavy things run out of fuel.
> >
> >Even as a potential substitute for ftp webdav is a farce.  Speaking
> >from personal experience, the amount of XML you need to generate for a
> >directory listing is at least 20 times the size of the equivalent ftp
> >listing, and then you twiddle your thumbs waiting for the webdav
> >client to parse and render it.

it's not that bad!

# readdir in xml...
PROPREQ = array of byte "<?xml version=\"1.0\"
	encoding=\"utf-8\"?><propfind xmlns=\"DAV:\"><prop><getcontentlength
	xmlns=\"DAV:\"/><getlastmodified xmlns=\"DAV:\"/><executable
	xmlns=\"http://apache.org/dav/props/\"/><resourcetype
	xmlns=\"DAV:\"/><checked-in xmlns=\"DAV:\"/><checked-out
	xmlns=\"DAV:\"/></prop></propfind>";


>
> But think about this: why would you care if you have this:
>     http://noedler.de/projekte/wdfs/
>
> Why would anyone care about what's getting pushed to the
> wire?

i guess it's just us who care, since we have to implement the protocols
if we want to use them.  for this case, i'm not sure what didn't stop me:

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

unpolished as always, but i've used it to edit files from my homedir at
my isp.

mechiel

Re: [9fans] Do we have a catalog of 9P servers?

[ron minnich]

On Sat, Nov 8, 2008 at 2:59 PM, Roman Shaposhnik <rvs@sun.com> wrote:

> The most ironic thing of all is that one would expect a company which
> stood behind a technology like ZFS to easily appreciate that. Especially
> since we've always had a userland ZFS. And especially now, that
> we are trying to figure out a cloud storage market story. But no.

you had a userland nfs too :-)

>
> Now, not to date myself as a green youngling, but how are PHBs
> to be convinced? They hear about 9P for the first time in their
> life (unlike bullshit lotto items: WebDAV, XML, SOAP and REST) and
> when they ask about *existing* client-side support there's not much I can
> tell them.


It's not just the PHBs. I showed the original 9p (for 2.0.36) in 1998
to a fair number of linux people, and back then I had private name
spaces, union mounts, user level servers, in fact just about all you
get in plan 9 today and STILL don't get in linux.

They were strongly convinced there was no use for userland file
systems, or union mounts, or private name spaces, or any of this
stuff. They kept pointing to things that Linux did that were not at
all what I was showing them, saying "we already do that". At some
point I gave up. Years later, FUSE comes along, and ... well you know
the story.

So it goes. We can't blame the PHBs for everything. Sometimes its our own guys.

ron

Re: [9fans] Do we have a catalog of 9P servers?

[erik quanstrom]

>> Even as a potential substitute for ftp webdav is a farce.  Speaking
>> from personal experience, the amount of XML you need to generate for a
>> directory listing is at least 20 times the size of the equivalent ftp
>> listing, and then you twiddle your thumbs waiting for the webdav
>> client to parse and render it.
>
> But think about this: why would you care if you have this:
>      http://noedler.de/projekte/wdfs/
>
> Why would anyone care about what's getting pushed to the
> wire?

i think most everyone here inderstands why one would.
let's let this thread die in peace.

- erik

Re: [9fans] Do we have a catalog of 9P servers?

[Bruce Ellis]

[-- Attachment #1: Type: text/plain, Size: 1122 bytes --]

Hmmm, that's politics ... and here is mine - I forgot how much fun
journalism is. I'm two hours late for filing, oh well.

brucee

On Sun, Nov 9, 2008 at 12:59 AM, Roman Shaposhnik <rvs@sun.com> wrote:
> On Nov 8, 2008, at 2:19 PM, Bruce Ellis wrote:
>>
>> I wrote a functional 9P S3 client but it just seemed silly in the end.
>> Buy a few T of disk and fossil+venti and it's over. Even aging kenfs
>> will do.
>
>
> The most ironic thing of all is that one would expect a company which
> stood behind a technology like ZFS to easily appreciate that. Especially
> since we've always had a userland ZFS. And especially now, that
> we are trying to figure out a cloud storage market story. But no.
>
> Now, not to date myself as a green youngling, but how are PHBs
> to be convinced? They hear about 9P for the first time in their
> life (unlike bullshit lotto items: WebDAV, XML, SOAP and REST) and
> when they ask about *existing* client-side support there's not much I can
> tell them.
>
> Network effect (http://en.wikipedia.org/wiki/Network_effect) at its worst?
>
> Thanks,
> Roman.
>
>

[-- Attachment #2: Falotct08.html --]
[-- Type: text/html, Size: 7396 bytes --]

Re: [9fans] Do we have a catalog of 9P servers?

[Roman Shaposhnik]

On Nov 8, 2008, at 2:19 PM, Bruce Ellis wrote:
> I wrote a functional 9P S3 client but it just seemed silly in the end.
> Buy a few T of disk and fossil+venti and it's over. Even aging kenfs
> will do.


The most ironic thing of all is that one would expect a company which
stood behind a technology like ZFS to easily appreciate that. Especially
since we've always had a userland ZFS. And especially now, that
we are trying to figure out a cloud storage market story. But no.

Now, not to date myself as a green youngling, but how are PHBs
to be convinced? They hear about 9P for the first time in their
life (unlike bullshit lotto items: WebDAV, XML, SOAP and REST) and
when they ask about *existing* client-side support there's not much I
can
tell them.

Network effect (http://en.wikipedia.org/wiki/Network_effect) at its
worst?

Thanks,
Roman.

Re: [9fans] Do we have a catalog of 9P servers?

[Bruce Ellis]

I wrote a functional 9P S3 client but it just seemed silly in the end.
Buy a few T of disk and fossil+venti and it's over. Even aging kenfs
will do.

brucee

On Sun, Nov 9, 2008 at 12:13 AM, Roman Shaposhnik <rvs@sun.com> wrote:
> On Nov 8, 2008, at 4:11 AM, Francisco J Ballesteros wrote:
>>
>> It seems that MS is pushing webdav hard.
>
> True. But it is not MS that worries me in this particular case. At least
> they don't have anything to offer yet. This:
>    http://docs.amazonwebservices.com/AmazonS3/2006-03-01/
> on the other hand, seems to be getting a lot of traction. As in
> "people are using it right now" kind of traction.
>
> I wish these guys provided 9P as one of the options to access their
> remote storage resources, but, of course, they don't. And why
> would they -- FUSE can handle whatever they have perfectly well.
>
> Thus, the letter of the "remote resource access via FS semantics"
> law seems to be perfectly fine, while the spirit, of course, is hopelessly
> broken.
>
> Thanks,
> Roman.
>
>

Re: [9fans] Do we have a catalog of 9P servers?

[Roman Shaposhnik]

On Nov 8, 2008, at 11:15 AM, John Barham wrote:
>>> It seems that MS is pushing webdav hard.
>>
>> that's what's needed when heavy things run out of fuel.
>
> Even as a potential substitute for ftp webdav is a farce.  Speaking
> from personal experience, the amount of XML you need to generate for a
> directory listing is at least 20 times the size of the equivalent ftp
> listing, and then you twiddle your thumbs waiting for the webdav
> client to parse and render it.

But think about this: why would you care if you have this:
     http://noedler.de/projekte/wdfs/

Why would anyone care about what's getting pushed to the
wire?

Thanks,
Roman.

Re: [9fans] Do we have a catalog of 9P servers?

[Roman Shaposhnik]

On Nov 8, 2008, at 4:11 AM, Francisco J Ballesteros wrote:
> It seems that MS is pushing webdav hard.

True. But it is not MS that worries me in this particular case. At least
they don't have anything to offer yet. This:
     http://docs.amazonwebservices.com/AmazonS3/2006-03-01/
on the other hand, seems to be getting a lot of traction. As in
"people are using it right now" kind of traction.

I wish these guys provided 9P as one of the options to access their
remote storage resources, but, of course, they don't. And why
would they -- FUSE can handle whatever they have perfectly well.

Thus, the letter of the "remote resource access via FS semantics"
law seems to be perfectly fine, while the spirit, of course, is
hopelessly
broken.

Thanks,
Roman.

Re: [9fans] Do we have a catalog of 9P servers?

[John Barham]

>>It seems that MS is pushing webdav hard.
>
> that's what's needed when heavy things run out of fuel.

Even as a potential substitute for ftp webdav is a farce.  Speaking
from personal experience, the amount of XML you need to generate for a
directory listing is at least 20 times the size of the equivalent ftp
listing, and then you twiddle your thumbs waiting for the webdav
client to parse and render it.

And don't get me started on vista...  My wife's new dell laptop uses
up 800 MB of ram doing who knows what after it boots and two times out
of three fails to go to sleep w/ the fan whirling like a banshee.  At
times I wonder if I shouldn't have paid the $700 premium for the
macbook.  Sorry for the OT rant...

Re: [9fans] Do we have a catalog of 9P servers?

[Russ Cox]

On Sat, Nov 8, 2008 at 10:32 AM,  <akumar@sounine.nanosouffle.net>
wrote:
> Well, they do have a branch called "MicroSoft Research" that they seem
> fond of putting money into.  And apparently, a portion of that has
> gone into making an Inferno/Plan 9 -equivalent, thus far dubbed, "MS
> Singularity".  Development has been going on for quite some time, it
> seems.  Think it'll outweigh what we have going with Plan 9?

This is unfair for two reasons.  First, Microsoft Research does
interesting research.  Second, Singularity is a far cry from being
the same as Inferno or Plan 9.  It's an operating system, but that's
the only real similarity.  I suppose it uses a bytecode execution
engine too, but that doesn't automatically make it like Inferno.
They're very different and enabled very different research.

Read the papers here and here
http://research.microsoft.com/os/Singularity/
http://plan9.bell-labs.com/sys/doc/
and then tell me why they are "equivalent".

Russ

Re: [9fans] Do we have a catalog of 9P servers?

[akumar]

[-- Attachment #1: Type: text/plain, Size: 342 bytes --]

Well, they do have a branch called "MicroSoft Research" that they seem
fond of putting money into.  And apparently, a portion of that has
gone into making an Inferno/Plan 9 -equivalent, thus far dubbed, "MS
Singularity".  Development has been going on for quite some time, it
seems.  Think it'll outweigh what we have going with Plan 9?

[-- Attachment #2: Type: message/rfc822, Size: 2313 bytes --]

From: Brantley Coile <brantley@coraid.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] Do we have a catalog of 9P servers?
Date: Sat, 8 Nov 2008 13:27:08 -0500
Message-ID: <E6C76436-50FB-4B7B-B138-D96E3DCCD9A2@coraid.com>

And don't forget MS' programming motto, 'Don't think; Type!'

On Nov 8, 2008, at 12:21 PM, Skip Tavakkolian wrote:

>>> It seems that MS is pushing webdav hard.
>>
>> that's what's needed when heavy things run out of fuel.
>
> to paraphrase Edison, MS' genius is 1% development and 99% marketing.
>
>
>

Re: [9fans] Do we have a catalog of 9P servers?

[Brantley Coile]

And don't forget MS' programming motto, 'Don't think; Type!'

On Nov 8, 2008, at 12:21 PM, Skip Tavakkolian wrote:

>>> It seems that MS is pushing webdav hard.
>>
>> that's what's needed when heavy things run out of fuel.
>
> to paraphrase Edison, MS' genius is 1% development and 99% marketing.
>
>
>

Re: [9fans] Do we have a catalog of 9P servers?

[Skip Tavakkolian]

>>It seems that MS is pushing webdav hard.
>
> that's what's needed when heavy things run out of fuel.

to paraphrase Edison, MS' genius is 1% development and 99% marketing.

Re: [9fans] Do we have a catalog of 9P servers?

[Charles Forsyth]

>It seems that MS is pushing webdav hard.

that's what's needed when heavy things run out of fuel.

Re: [9fans] Do we have a catalog of 9P servers?

[Francisco J Ballesteros]

It seems that MS is pushing webdav hard.

On Sat, Nov 8, 2008 at 12:47 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>> Sure. But that would an argument in favor of the Plan 9/Inferno
>> kernel architecture, not the protocol itself. Nobody's denying
>> that 9P is a perfect match to that kind of kernel architecture.
>> What I'm trying to find out is whether the protocol could stand
>> its own ground even if Plan9 kernel is not serving nor muxing it.
>
> this depends entirely on your criteria and constraints.
>
> - erik
>
>
>

Re: [9fans] Do we have a catalog of 9P servers?

[erik quanstrom]

> Sure. But that would an argument in favor of the Plan 9/Inferno
> kernel architecture, not the protocol itself. Nobody's denying
> that 9P is a perfect match to that kind of kernel architecture.
> What I'm trying to find out is whether the protocol could stand
> its own ground even if Plan9 kernel is not serving nor muxing it.

this depends entirely on your criteria and constraints.

- erik

Re: [9fans] Do we have a catalog of 9P servers?

[erik quanstrom]

>> 9p is not going to replace fuse now, if ever, on these systems.
>>
>> That's not to say that 9p goes away. But it's not worth worrying about
>> whether FUSE will have more users -- it already has and it probably
>> always will.

if the winner is determined by usage (silly criteria, i think), the
winner is not FUSE.  the winner is email, by whatever protocol's
handy.

- erik

Re: [9fans] Do we have a catalog of 9P servers?

[Lyndon Nerenberg]

> The amount of fuse traffic for simple operations is
> astounding. You stop wondering "why?" and just try and cope. I'm not
> dumping on fuse - it does fill a gap - rather I just don't wish to
> look at its implementation.

This sound so much like the argument about shared libraries ...

Re: [9fans] Do we have a catalog of 9P servers?

[Bruce Ellis]

Indeed. Fortunately Russ' code was very clean, but if you turn on
tracing you get quite a surprise. Here we are concerned about
optimizing 9p. The amount of fuse traffic for simple operations is
astounding. You stop wondering "why?" and just try and cope. I'm not
dumping on fuse - it does fill a gap - rather I just don't wish to
look at its implementation.

brucee

On Sat, Nov 8, 2008 at 1:45 AM, Skip Tavakkolian <9nut@9netics.com> wrote:
>> That said, what's the "resource sharing protocol" for fuse? None of
>> those file systems has a common wire protocol AFAICT. Those servers
>> are hooks from kernel to user to "something". FUSE is not for resource
>> sharing, is it? It's for making it easy to write file systems for
>> Linux users.
>
> the new rangboom agents include 9pfuse (brucee's work based on russ'
> p9p code) and run on linux and mac os x.  i was hoping to release them
> by the end of oct (in time for iwp9).  filesystems imported from plan9 are
> mounted as fuse fs.  fuse has a lot of quirks and doesn't inspire confidence.
>
>
>

Re: [9fans] Do we have a catalog of 9P servers?

[Roman Shaposhnik]

On Nov 7, 2008, at 7:56 PM, ron minnich wrote:
>> And FUSE, as I realize now, seems to fit the bill quite nicely.
>> It is available on quite a few OSes and the list of resource sharing
>> protocols for which adapters are already available seems to be quite
>> large.
>
> And little lacks in 9p like symlnks, xatrr, etc. are a killer.


Not really no. At least not for the kind of things I care about
at the moment. Like enabling mounts to the source code
repositories and such.

Thanks,
Roman.

Re: [9fans] Do we have a catalog of 9P servers?

[ron minnich]

On Fri, Nov 7, 2008 at 7:43 PM, Roman V. Shaposhnik <rvs@sun.com> wrote:

> Are you talking about this:
>   http://fuse.sourceforge.net/wiki/index.php/FuseProtocolSketch

That's just kernel to user on same machine. What goes over the wire?

> And FUSE, as I realize now, seems to fit the bill quite nicely.
> It is available on quite a few OSes and the list of resource sharing
> protocols for which adapters are already available seems to be quite
> large.

And little lacks in 9p like symlnks, xatrr, etc. are a killer.

ron

Re: [9fans] Do we have a catalog of 9P servers?

[Roman V. Shaposhnik]

On Fri, 2008-11-07 at 14:31 -0800, ron minnich wrote:
> FUSE won. It's easy, it works, and it has cross-platform support (macos/linux).

It certainly looks that way. It also certainly looks like I have to
study it. Do you guys have any good pointers and/or wisdom in that
department? I'd be happy to take answers off the list, btw.

> 9p is not going to replace fuse now, if ever, on these systems.
>
> That's not to say that 9p goes away. But it's not worth worrying about
> whether FUSE will have more users -- it already has and it probably
> always will.

Fair enough. But that begs the next question: realistically speaking,
what is the right area for 9P to be used these days? Where would it
be the perfect fit in cases where Plan9/Inferno are not there to
leverage it?

> That said, what's the "resource sharing protocol" for fuse?

Are you talking about this:
   http://fuse.sourceforge.net/wiki/index.php/FuseProtocolSketch
It is riddled with POSIX inspired quirks as far as I can
tell but given enough thrust this particular pig surely can be
made airborne. Or so it appears after an hour or so of cursory
read ;-)

> None of those file systems has a common wire protocol AFAICT. Those servers
> are hooks from kernel to user to "something". FUSE is not for resource
> sharing, is it? It's for making it easy to write file systems for
> Linux users.

That depends on the point of view: very few things talk 9P natively,
most of the resource sharing is done via a hoge-podge of protocols
that, unfortunately, already exist. I wish I had control over the
server *and* the client in which case 9P would be a perfect fit.
But I don't. I have to hook up with what's already there.

And FUSE, as I realize now, seems to fit the bill quite nicely.
It is available on quite a few OSes and the list of resource sharing
protocols for which adapters are already available seems to be quite
large.

Thanks,
Roman.

Re: [9fans] Do we have a catalog of 9P servers?

[Roman V. Shaposhnik]

On Fri, 2008-11-07 at 22:38 +0000, C H Forsyth wrote:
> of course, that's just the protocol, and to show the larger
> idea of the representation of things by name spaces
> (instead of ioctls and special system calls)
> would have to include section 3 (devices).
>
> it's fairly pervasive.

Sure. But that would an argument in favor of the Plan 9/Inferno
kernel architecture, not the protocol itself. Nobody's denying
that 9P is a perfect match to that kind of kernel architecture.
What I'm trying to find out is whether the protocol could stand
its own ground even if Plan9 kernel is not serving nor muxing it.

I have always used an argument of simplicity and ease of implementation.
In fact, from that point of view, 9P is better than FUSE:
   http://fuse.sourceforge.net/wiki/index.php/LanguageBindings
vs
   http://9p.cat-v.org/implementations

That's the good news, the bad news is that the "Network effect"
seems to be really working in favor of FUSE: the amount of
*already* implemented fileservers is nothing short of amazing.

Thanks,
Roman.

Re: [9fans] Do we have a catalog of 9P servers?

[ron minnich]

On Fri, Nov 7, 2008 at 3:45 PM, Skip Tavakkolian <9nut@9netics.com> wrote:
> fuse has a lot of quirks and doesn't inspire confidence.

Which hasn't stopped most of the software I am abused by -- er, use --
from achieving world dominance :-)

ron

Re: [9fans] Do we have a catalog of 9P servers?

[Skip Tavakkolian]

> That said, what's the "resource sharing protocol" for fuse? None of
> those file systems has a common wire protocol AFAICT. Those servers
> are hooks from kernel to user to "something". FUSE is not for resource
> sharing, is it? It's for making it easy to write file systems for
> Linux users.

the new rangboom agents include 9pfuse (brucee's work based on russ'
p9p code) and run on linux and mac os x.  i was hoping to release them
by the end of oct (in time for iwp9).  filesystems imported from plan9 are
mounted as fuse fs.  fuse has a lot of quirks and doesn't inspire confidence.

Re: [9fans] Do we have a catalog of 9P servers?

[Charles Forsyth]

and what's at the end of a fuse?
exactly.  i was reminded of that the other night as
i was lighting the blue touch paper before standing WELL BACK

Re: [9fans] Do we have a catalog of 9P servers?

[C H Forsyth]

[-- Attachment #1: Type: text/plain, Size: 228 bytes --]

of course, that's just the protocol, and to show the larger
idea of the representation of things by name spaces
(instead of ioctls and special system calls)
would have to include section 3 (devices).

it's fairly pervasive.

[-- Attachment #2: Type: message/rfc822, Size: 1771 bytes --]

From: Charles Forsyth <forsyth@terzarima.net>
To: 9fans@9fans.net
Subject: Re: [9fans] Do we have a catalog of 9P servers?
Date: Fri, 7 Nov 2008 22:37:21 +0000
Message-ID: <8ecb4ee8da5aef27e8e56d59218d6dbc@terzarima.net>

mostly section 4 of the manual, i'd have said,
although there are a few in section 8 where the
file service is incidental to the service
(eg, cs and dns)

Re: [9fans] Do we have a catalog of 9P servers?

[Charles Forsyth]

mostly section 4 of the manual, i'd have said,
although there are a few in section 8 where the
file service is incidental to the service
(eg, cs and dns)

Re: [9fans] Do we have a catalog of 9P servers?

[ron minnich]

FUSE won. It's easy, it works, and it has cross-platform support (macos/linux).

9p is not going to replace fuse now, if ever, on these systems.

That's not to say that 9p goes away. But it's not worth worrying about
whether FUSE will have more users -- it already has and it probably
always will.

That said, what's the "resource sharing protocol" for fuse? None of
those file systems has a common wire protocol AFAICT. Those servers
are hooks from kernel to user to "something". FUSE is not for resource
sharing, is it? It's for making it easy to write file systems for
Linux users.

ron

[9fans] Do we have a catalog of 9P servers?

[Roman V. Shaposhnik]

Guys,

do we have something like this:
   http://fuse.sourceforge.net/wiki/index.php/FileSystems
for 9P? At this point I don't even care what OS these
servers run under I just need the most comprehensive
list of every possible kind of a resource that can be
shared/served using 9P.

Thanks,
Roman.

P.S. The list of things that can be accessed using FUSE
is *really* impressive. I have no clue how good any
of them are, but in a management-type of a conversation
I would really like to be in a position to defend 9P
as a protocol of choice for some things that we do.
Although it looks like FUSE has become Linux of resource
sharing/access protocols? :-(