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

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

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

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

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

Packet analysis == Network layer operations ~= NAT

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

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

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

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

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