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

["Brian L. Stuart" <blstuart@bellsouth.net>]

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