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

[Eris Discordia <eris.discordia@gmail.com>]

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