9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* Re: [9fans] Do we have a catalog of 9P servers?
@ 2008-11-12 19:08 erik quanstrom
  0 siblings, 0 replies; 198+ messages in thread
From: erik quanstrom @ 2008-11-12 19:08 UTC (permalink / raw)
  To: uriel99, 9fans

> 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



^ permalink raw reply	[flat|nested] 198+ messages in thread
* Re: [9fans] Do we have a catalog of 9P servers?
@ 2008-11-21  0:12 Eris Discordia
  2008-11-21  0:42 ` erik quanstrom
  0 siblings, 1 reply; 198+ messages in thread
From: Eris Discordia @ 2008-11-21  0:12 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

>> "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
>
>







^ permalink raw reply	[flat|nested] 198+ messages in thread
* Re: [9fans] Do we have a catalog of 9P servers?
@ 2008-11-20 22:28 Eris Discordia
  2008-11-20 22:42 ` erik quanstrom
  0 siblings, 1 reply; 198+ messages in thread
From: Eris Discordia @ 2008-11-20 22:28 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

> 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
>
>



^ permalink raw reply	[flat|nested] 198+ messages in thread
* Re: [9fans] Do we have a catalog of 9P servers?
@ 2008-11-20 21:35 Eris Discordia
  0 siblings, 0 replies; 198+ messages in thread
From: Eris Discordia @ 2008-11-20 21:35 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

> 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
>
>



^ permalink raw reply	[flat|nested] 198+ messages in thread
* Re: [9fans] Do we have a catalog of 9P servers?
@ 2008-11-19 18:31 Eris Discordia
  2008-11-19 20:08 ` Anant Narayanan
  0 siblings, 1 reply; 198+ messages in thread
From: Eris Discordia @ 2008-11-19 18:31 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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;



^ permalink raw reply	[flat|nested] 198+ messages in thread
* Re: [9fans] Do we have a catalog of 9P servers?
@ 2008-11-17  8:42 Eris Discordia
  0 siblings, 0 replies; 198+ messages in thread
From: Eris Discordia @ 2008-11-17  8:42 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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
>



^ permalink raw reply	[flat|nested] 198+ messages in thread
* Re: [9fans] Do we have a catalog of 9P servers?
@ 2008-11-17  7:57 Eris Discordia
  0 siblings, 0 replies; 198+ messages in thread
From: Eris Discordia @ 2008-11-17  7:57 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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
>
>



^ permalink raw reply	[flat|nested] 198+ messages in thread
* Re: [9fans] Do we have a catalog of 9P servers?
@ 2008-11-16 18:30 Eris Discordia
  0 siblings, 0 replies; 198+ messages in thread
From: Eris Discordia @ 2008-11-16 18:30 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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
>







^ permalink raw reply	[flat|nested] 198+ messages in thread
* Re: [9fans] Do we have a catalog of 9P servers?
@ 2008-11-16 18:08 Eris Discordia
  0 siblings, 0 replies; 198+ messages in thread
From: Eris Discordia @ 2008-11-16 18:08 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

> 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
>
>



^ permalink raw reply	[flat|nested] 198+ messages in thread
* Re: [9fans] Do we have a catalog of 9P servers?
@ 2008-11-16 17:19 Eris Discordia
  0 siblings, 0 replies; 198+ messages in thread
From: Eris Discordia @ 2008-11-16 17:19 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

>  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
>







^ permalink raw reply	[flat|nested] 198+ messages in thread
* Re: [9fans] Do we have a catalog of 9P servers?
@ 2008-11-16 16:58 Eris Discordia
  2008-11-16 17:17 ` erik quanstrom
  0 siblings, 1 reply; 198+ messages in thread
From: Eris Discordia @ 2008-11-16 16:58 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

> [...] 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)
>>>
>>
>>
>>
>>
>>
>>
>







^ permalink raw reply	[flat|nested] 198+ messages in thread
[parent not found: <96BA4878DB039F3DAE38CCF2@192.168.1.2>]
* Re: [9fans] Do we have a catalog of 9P servers?
@ 2008-11-16 11:39 Eris Discordia
  0 siblings, 0 replies; 198+ messages in thread
From: Eris Discordia @ 2008-11-16 11:39 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

> 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.
>>>
>>
>>
>>
>>
>>
>>
>




^ permalink raw reply	[flat|nested] 198+ messages in thread
* Re: [9fans] Do we have a catalog of 9P servers?
@ 2008-11-16  7:24 Eris Discordia
  2008-11-17 10:20 ` Dave Eckhardt
  0 siblings, 1 reply; 198+ messages in thread
From: Eris Discordia @ 2008-11-16  7:24 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

> 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.
>



^ permalink raw reply	[flat|nested] 198+ messages in thread
[parent not found: <DBCC6BB0C82C348357A14A53@192.168.1.2>]
[parent not found: <906EC091083FF0C3C35F51A9@192.168.1.2>]
* Re: [9fans] Do we have a catalog of 9P servers?
@ 2008-11-15 22:07 Eris Discordia
  2008-11-16  5:27 ` Roman Shaposhnik
  0 siblings, 1 reply; 198+ messages in thread
From: Eris Discordia @ 2008-11-15 22:07 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

> 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.
>







^ permalink raw reply	[flat|nested] 198+ messages in thread
* Re: [9fans] Do we have a catalog of 9P servers?
@ 2008-11-15 11:21 Eris Discordia
  2008-11-15 13:38 ` Gabriel Diaz Lopez de la Llave
  2008-11-15 20:01 ` Roman Shaposhnik
  0 siblings, 2 replies; 198+ messages in thread
From: Eris Discordia @ 2008-11-15 11:21 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

> 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.
>







^ permalink raw reply	[flat|nested] 198+ messages in thread
[parent not found: <FB6D5E99B294E50B901E8872@192.168.1.2>]
* Re: [9fans] Do we have a catalog of 9P servers?
@ 2008-11-14 17:29 Eris Discordia
  0 siblings, 0 replies; 198+ messages in thread
From: Eris Discordia @ 2008-11-14 17:29 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

>  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
>



^ permalink raw reply	[flat|nested] 198+ messages in thread
* Re: [9fans] Do we have a catalog of 9P servers?
@ 2008-11-14 16:39 Eris Discordia
  0 siblings, 0 replies; 198+ messages in thread
From: Eris Discordia @ 2008-11-14 16:39 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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
>



^ permalink raw reply	[flat|nested] 198+ messages in thread
[parent not found: <7D122EF9133395AC4DEA0396@192.168.1.2>]
* Re: [9fans] Do we have a catalog of 9P servers?
@ 2008-11-13 14:25 gdiaz
  2008-11-14 16:43 ` Eris Discordia
  0 siblings, 1 reply; 198+ messages in thread
From: gdiaz @ 2008-11-13 14:25 UTC (permalink / raw)
  To: 9fans

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
>
>
>
>
>
>




^ permalink raw reply	[flat|nested] 198+ messages in thread
* Re: [9fans] Do we have a catalog of 9P servers?
@ 2008-11-12 21:19 Eris Discordia
  2008-11-12 23:11 ` erik quanstrom
  0 siblings, 1 reply; 198+ messages in thread
From: Eris Discordia @ 2008-11-12 21:19 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

> 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.
>







^ permalink raw reply	[flat|nested] 198+ messages in thread
* Re: [9fans] Do we have a catalog of 9P servers?
@ 2008-11-12 13:23 Eris Discordia
  2008-11-12 14:02 ` Charles Forsyth
  0 siblings, 1 reply; 198+ messages in thread
From: Eris Discordia @ 2008-11-12 13:23 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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
>



^ permalink raw reply	[flat|nested] 198+ messages in thread
[parent not found: <ba5c9f8b914dc6c6d0b4f533d681cda2@quanstro.net>]
* Re: [9fans] Do we have a catalog of 9P servers?
@ 2008-11-12  5:22 erik quanstrom
  0 siblings, 0 replies; 198+ messages in thread
From: erik quanstrom @ 2008-11-12  5:22 UTC (permalink / raw)
  To: sqweek, quanstro, 9fans

> 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



^ permalink raw reply	[flat|nested] 198+ messages in thread
[parent not found: <150a5464b8f389f1eb92ff001f7d391f@quanstro.net>]
* Re: [9fans] Do we have a catalog of 9P servers?
@ 2008-11-12  4:50 erik quanstrom
  0 siblings, 0 replies; 198+ messages in thread
From: erik quanstrom @ 2008-11-12  4:50 UTC (permalink / raw)
  To: sqweek, 9fans

> 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



^ permalink raw reply	[flat|nested] 198+ messages in thread
* Re: [9fans] Do we have a catalog of 9P servers?
@ 2008-11-09  6:12 erik quanstrom
  2008-11-09 13:52 ` Bruce Ellis
  0 siblings, 1 reply; 198+ messages in thread
From: erik quanstrom @ 2008-11-09  6:12 UTC (permalink / raw)
  To: 9nut, 9fans

> 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



^ permalink raw reply	[flat|nested] 198+ messages in thread
* [9fans] Do we have a catalog of 9P servers?
@ 2008-11-07 21:51 Roman V. Shaposhnik
  2008-11-07 22:31 ` ron minnich
  2008-11-07 22:37 ` Charles Forsyth
  0 siblings, 2 replies; 198+ messages in thread
From: Roman V. Shaposhnik @ 2008-11-07 21:51 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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? :-(




^ permalink raw reply	[flat|nested] 198+ messages in thread
end of thread, other threads:[~2008-11-21  7:57 UTC | newest]

Thread overview: 198+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-11-12 19:08 [9fans] Do we have a catalog of 9P servers? erik quanstrom
  -- strict thread matches above, loose matches on Subject: below --
2008-11-21  0:12 Eris Discordia
2008-11-21  0:42 ` erik quanstrom
2008-11-21  7:57   ` Eris Discordia
2008-11-20 22:28 Eris Discordia
2008-11-20 22:42 ` erik quanstrom
2008-11-20 21:35 Eris Discordia
2008-11-19 18:31 Eris Discordia
2008-11-19 20:08 ` Anant Narayanan
2008-11-20  0:00   ` Eris Discordia
2008-11-20  4:55     ` blstuart
2008-11-20  7:44       ` Eris Discordia
2008-11-20 17:34         ` Brian L. Stuart
2008-11-20 18:30           ` akumar
2008-11-20 18:36             ` erik quanstrom
2008-11-20 19:20               ` Brian L. Stuart
2008-11-17  8:42 Eris Discordia
2008-11-17  7:57 Eris Discordia
2008-11-16 18:30 Eris Discordia
2008-11-16 18:08 Eris Discordia
2008-11-16 17:19 Eris Discordia
2008-11-16 16:58 Eris Discordia
2008-11-16 17:17 ` erik quanstrom
2008-11-16 18:01   ` ron minnich
     [not found] <96BA4878DB039F3DAE38CCF2@192.168.1.2>
2008-11-16 15:09 ` sqweek
2008-11-16 17:41   ` Charles Forsyth
2008-11-16 11:39 Eris Discordia
2008-11-16  7:24 Eris Discordia
2008-11-17 10:20 ` Dave Eckhardt
2008-11-17 14:01   ` Eris Discordia
2008-11-17 16:50     ` Dave Eckhardt
2008-11-17 19:45       ` Eris Discordia
     [not found] <DBCC6BB0C82C348357A14A53@192.168.1.2>
2008-11-15 11:49 ` Sergey Zhilkin
2008-11-16  4:31 ` Iruata Souza
     [not found] <906EC091083FF0C3C35F51A9@192.168.1.2>
2008-11-16  0:15 ` Felipe Bichued
2008-11-15 22:07 Eris Discordia
2008-11-16  5:27 ` Roman Shaposhnik
2008-11-16  6:19   ` Eris Discordia
2008-11-15 11:21 Eris Discordia
2008-11-15 13:38 ` Gabriel Diaz Lopez de la Llave
2008-11-15 15:30   ` hiro
2008-11-15 20:01 ` Roman Shaposhnik
2008-11-15 22:13   ` Micah Stetson
2008-11-16  5:47     ` Roman Shaposhnik
2008-11-16 19:36       ` Micah Stetson
2008-11-16  6:27     ` Eris Discordia
     [not found]     ` <1282469A8843837F996E64E1@192.168.1.2>
2008-11-16  6:57       ` andrey mirtchovski
2008-11-16 11:45         ` Eris Discordia
     [not found]         ` <D6FDC9E2D78F88C07963DBE5@192.168.1.2>
2008-11-16 12:49           ` hiro
2008-11-16 16:15             ` Eris Discordia
2008-11-16 17:38               ` lucio
2008-11-16 13:25           ` Uriel
2008-11-16 19:46       ` Micah Stetson
2008-11-16 21:24         ` Eris Discordia
2008-11-16 21:52           ` erik quanstrom
2008-11-19  1:59           ` Nathaniel W Filardo
2008-11-20  2:35             ` erik quanstrom
     [not found]         ` <D0E4FEAEC0D3FD307DE41383@192.168.1.2>
2008-11-17  5:12           ` Micah Stetson
     [not found] <FB6D5E99B294E50B901E8872@192.168.1.2>
2008-11-14 18:21 ` Tom Lieber
2008-11-14 18:59   ` erik quanstrom
2008-11-16  2:45 ` sqweek
2008-11-14 17:29 Eris Discordia
2008-11-14 16:39 Eris Discordia
     [not found] <7D122EF9133395AC4DEA0396@192.168.1.2>
2008-11-13 16:55 ` sqweek
2008-11-13 17:28   ` Brian L. Stuart
2008-11-15  4:12   ` Roman Shaposhnik
2008-11-13 14:25 gdiaz
2008-11-14 16:43 ` Eris Discordia
2008-11-14 17:00   ` erik quanstrom
2008-11-12 21:19 Eris Discordia
2008-11-12 23:11 ` erik quanstrom
2008-11-12 23:51   ` Bruce Ellis
2008-11-13  0:35     ` akumar
2008-11-13 11:58   ` Eris Discordia
2008-11-13 14:17     ` erik quanstrom
2008-11-13 16:22       ` Iruata Souza
2008-11-12 13:23 Eris Discordia
2008-11-12 14:02 ` Charles Forsyth
     [not found] <ba5c9f8b914dc6c6d0b4f533d681cda2@quanstro.net>
2008-11-12  5:52 ` sqweek
2008-11-12  5:22 erik quanstrom
     [not found] <150a5464b8f389f1eb92ff001f7d391f@quanstro.net>
2008-11-12  5:17 ` sqweek
2008-11-12  4:50 erik quanstrom
2008-11-09  6:12 erik quanstrom
2008-11-09 13:52 ` Bruce Ellis
2008-11-09 20:39   ` C H Forsyth
2008-11-09 21:57     ` Bruce Ellis
2008-11-07 21:51 Roman V. Shaposhnik
2008-11-07 22:31 ` ron minnich
2008-11-07 23:19   ` Charles Forsyth
2008-11-07 23:45   ` Skip Tavakkolian
2008-11-07 23:51     ` ron minnich
2008-11-08  6:16     ` Bruce Ellis
2008-11-08  7:22       ` Lyndon Nerenberg
2008-11-08  3:43   ` Roman V. Shaposhnik
2008-11-08  3:56     ` ron minnich
2008-11-08  4:29       ` Roman Shaposhnik
2008-11-08 11:39     ` erik quanstrom
2008-11-07 22:37 ` Charles Forsyth
2008-11-07 22:38   ` C H Forsyth
2008-11-08  1:45     ` Roman V. Shaposhnik
2008-11-08 11:47       ` erik quanstrom
2008-11-08 12:11         ` Francisco J Ballesteros
2008-11-08 15:58           ` Charles Forsyth
2008-11-08 17:21             ` Skip Tavakkolian
2008-11-08 18:27               ` Brantley Coile
2008-11-08 18:32                 ` akumar
2008-11-08 18:44                   ` Russ Cox
2008-11-08 23:56                   ` LiteStar numnums
2008-11-08 19:15             ` John Barham
2008-11-08 22:16               ` Roman Shaposhnik
2008-11-08 23:11                 ` erik quanstrom
2008-11-08 23:37                   ` Roman Shaposhnik
2008-11-09 11:26                     ` Steve Simon
2008-11-10  5:50                       ` Enrico Weigelt
2008-11-10  6:17                         ` sqweek
2008-11-10  6:26                           ` Enrico Weigelt
2008-11-10 10:00                             ` Robert Raschke
2008-11-11  2:40                               ` Enrico Weigelt
2008-11-11  2:53                                 ` sqweek
2008-11-10 22:46                           ` Roman V. Shaposhnik
2008-11-10 22:54                       ` Roman V. Shaposhnik
2008-11-10  5:26                     ` Enrico Weigelt
2008-11-10  5:56                       ` Anant Narayanan
2008-11-10  6:18                         ` Enrico Weigelt
2008-11-10 12:11                           ` Charles Forsyth
     [not found]                           ` <4a3bd2fc8118cd88c5bd56605ba6d4e9@terzarima.net>
2008-11-11  2:23                             ` Enrico Weigelt
2008-11-10  6:01                       ` Skip Tavakkolian
2008-11-08 23:36                 ` Mechiel Lukkien
2008-11-08 22:13           ` Roman Shaposhnik
2008-11-08 22:19             ` Bruce Ellis
2008-11-08 22:59               ` Roman Shaposhnik
2008-11-08 23:11                 ` Bruce Ellis
2008-11-08 23:26                 ` ron minnich
2008-11-09  1:12                   ` Bakul Shah
2008-11-09  5:50               ` Skip Tavakkolian
2008-11-09 20:43                 ` C H Forsyth
2008-11-09 22:13                   ` Skip Tavakkolian
2008-11-09 22:21                     ` Bruce Ellis
2008-11-10 21:56         ` Roman V. Shaposhnik
2008-11-10 22:28           ` Anant Narayanan
2008-11-10 23:38           ` C H Forsyth
2008-11-10 23:45             ` Roman V. Shaposhnik
2008-11-11  0:14               ` Charles Forsyth
2008-11-11  1:00                 ` Roman V. Shaposhnik
2008-11-11  1:50                   ` Bruce Ellis
2008-11-11 15:37                   ` Skip Tavakkolian
2008-11-11 16:02                     ` Eric Van Hensbergen
2008-11-11 16:36                       ` Skip Tavakkolian
2008-11-11 16:52                         ` Eric Van Hensbergen
2008-11-12  2:42                           ` sqweek
2008-11-12  3:26                         ` Roman Shaposhnik
2008-11-11 19:18                       ` Bruce Ellis
2008-11-11 19:55                         ` Eric Van Hensbergen
2008-11-11 20:08                           ` Bruce Ellis
2008-11-11 16:30                     ` Uriel
2008-11-11 16:51                       ` ron minnich
2008-11-11 17:01                       ` Eric Van Hensbergen
2008-11-11 17:54                         ` sqweek
2008-11-11 19:46                           ` ron minnich
2008-11-11 20:51                             ` erik quanstrom
2008-11-11 22:33                               ` Eric Van Hensbergen
2008-11-12  0:32                                 ` Eris Discordia
     [not found]                                 ` <D06FA45F8C3E658AA29EAAFD@192.168.1.2>
2008-11-12  4:40                                   ` sqweek
2008-11-11 19:54                           ` Eric Van Hensbergen
2008-11-12  2:11                             ` sqweek
2008-11-12  2:44                               ` Eric Van Hensbergen
2008-11-12  3:51                               ` Roman Shaposhnik
2008-11-12 14:29                                 ` Charles Forsyth
2008-11-12 14:48                                 ` Eric Van Hensbergen
2008-11-12  4:58                               ` ron minnich
2008-11-12  5:20                                 ` Roman Shaposhnik
2008-11-12 17:47                                   ` ron minnich
2008-11-12 19:00                                     ` Uriel
2008-11-12 19:13                                       ` geoff
2008-11-12 19:58                                         ` Charles Forsyth
2008-11-12 19:55                                           ` Brantley Coile
2008-11-12 21:08                                             ` Gorka Guardiola
2008-11-13 16:37                                         ` Dan Cross
2008-11-14  5:52                                           ` Roman Shaposhnik
2008-11-14  8:18                                             ` Steve Simon
2008-11-14 16:35                                             ` Eric Van Hensbergen
2008-11-20 12:08                                             ` Dan Cross
2008-11-20 22:57                                               ` Roman V. Shaposhnik
2008-11-12 19:16                                       ` ron minnich
2008-11-12 19:31                                       ` Eric Van Hensbergen
2008-11-12 21:20                                     ` Roman V. Shaposhnik
2008-11-12  3:40                       ` Roman Shaposhnik
2008-11-11  0:19               ` ron minnich
2008-11-11  0:48                 ` Eric Van Hensbergen
2008-11-11  6:35                 ` Skip Tavakkolian
2008-11-11  2:19           ` Enrico Weigelt
2008-11-11  2:32             ` Lyndon Nerenberg
2008-11-11  6:54             ` Skip Tavakkolian
2008-11-11  8:45           ` Fco. J. Ballesteros
2008-11-11 15:28             ` hiro
2008-11-11 16:25               ` Gorka Guardiola
2008-11-12  1:55             ` Roman V. Shaposhnik
2008-11-12  2:48               ` sqweek

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).