ata-link
hysical
I'll direct the class to any book on Netware or TCP/IP networking for
detailed explanations of these levels. For our purposes, here is what we
need to know:
The Physical and Data-link layers deal with the hardware proper --
Physical being the wire (or other transmission media, such as fiber
optics) proper; the data-link layer is an organizational view of discrete
bits sent over the physical layer combined into what is known as FRAMES.
A FRAME consists of a SOURCE and DESTINATION address -- these are the
actual MAC addresses [MAC = Media Access Channel, I believe, and is the
"unique" number on the actual interface card]. Note that while we HAVE a
unique address at this point, the bits/bytes that follow don't have any
"meaning" yet
The Network layer is where things start to get interesting. This and the
Transport layer is where the TCP/IP address is defined. Technically,
this layer is either IPX [netware's Internet Packet eXchange protocol] or
IP [Internet Protocol]. From the Netware TCP/IP & NFS book I have in
front of me:
"The transport layer also may be responsible for creating several
logical connections of ther the same network connection, a process called
_multiplexing_. Multiplexing (or time sharing) occurs when a number of
transport connections share the same network connection."
[and a little later on]
"... To identify each software element within the transport layer, a
more general form of addressing is neccessary. these addresses, called
_transport addresses_, usually are a combination of the network layer
address and a Transport Service Access Point (SAP) number. Sometimes the
names _sockets_ or _port numbers_ are used to identify transport
addresses"
> > If fred@def.com then connects on port 20,
> > the server spawns another child process "B". It is up to the tcp
stack
> > to keep track of who gets which data. When a packet comes in for
port
> > 20 from joe@abc.net, the OS gives it to child process "A". A packet
> > for port 20 from fred@def.net goes to process "B".
>
SO... from here "down" the seven-layer OSI model [the "purple snake"...],
a single SOCKET (or PORT) is the combination of THREE actual addresses:
The ransport address: 20
The etwork address: 204.125.16.99 [which defines an arbitrary
computer on, say, abc.net]
The ata-link address: 00-40-80-12-34-56 [the hard-coded actual
address of the NIC in joe's computer]
(technically, the hysical and the ata-link layers are combined
for the purposes of defining an address)
To clarify, we can see how it is "easy" for the computer to keep traffic
for these two people "apart" since _packets_ for joe@abc.net and
fred@def.com will have significantly different addresses. To continue
with our example:
Let's say that fred has a NIC from the same company joe bought his, but
you bought a NIC from some entirely different company. NIC/MAC addresses
could be:
joe: 00-40-80-12-34-56
Fred: 00-40-80-99-88-77
You: 98-00-12-45-78-45
Likewise, Fred is doing his FTP'ing from work, while joe is on a dial-in.
Your server is co-located at a good sized ISP:
joe: 204.125.16.99
fred: 18.0.1.200 [fred works at a BIG company!]
you: 129.129.0.15
So, packets from joe to you would look like:
98-00-12-45-78-45 / 00-40-80-12-34-56 / 129.129.0.15 / 204.125.16.99 /
20
while packets from fred to you look like:
98-00-12-45-78-45 / 00-40-80-99-88-77 / 129.129.0.15 / 18.0.1.200 / 20
[note that while I've listed these in "conventional" formats, each number
would be a single byte value] ALSO note that the "packet" addresses
contain both a SOURCE and a DESTINATION address, both for the MEDIA
address and the NETWORK address.
> I'm really confused now. I thought the FTP server (the parent process)
> was listening on port 20. How does the TCP stack know to give the
> packet that comes in on port 20 to the child process? In the header,
> the IP address is the same and both carry the same port number, 20.
> There's no other identification in the header that the TCP stack can
use
> to properly steer the packet.
right and wrong to a degree. YES, both packets contain "20" as the port,
but as shown above, the packets DO have different addresses for the
target, so NO, your last statement isn't entirely true...
However: The next three layers "up" the OSI model (session, presentation,
and application) extend the above a little farther. consider, for
instance, what happens when fred starts a second file transfer [after
all, he's using a popular multi-tasking OS and CAN start a second FTP
session from the same computer...] The packet headers for each would
look the same (I think that's effectively the question you're asking
here) -- this is where the concept of the _session_ comes into play --
this "session" is the _truly unique random number_ that differenciates
conversations between computers. Since this is a two-byte value, the
theoretical maximum number of FTP sessions one can have with the SAME
host is 65536. [actually, that's the maximum number of file transfers
with the same SERVER on the same host -- if we run two simultaneous
servers on ports 20 and 2020, for instance, we can have twice as many
sessions going...]
note that while there is a limit of 65536 SESSION between to computers on
the same port, there is NO "theoretical" limit to the number of CLIENT
COMPUTERS that can connect to the host [ok, there is an actual
theoretical maximum -- 2^32, or one for each and every IP address in the
current IP numbering scheme]
The
resentation layer is an abstract concept for how the data is
represented: is the data ASCII or EBCDIC? are numbers "big"-endian or
"little"-endian? etc.
The pplication layer, finally, is FTP itself (or POP or SMTP or NNTP
or anything else you see in etc/services)
> I thought that the child process was given a new, unique port number by
> the TCP stack, and a socket (a handle) was passed to the child process
> so that it could use that port number. I thought the child process
> never really knew what port number it was using and only used the
socket
> for its communications. I thought the TCP stack kept a table so it
> could look up a port if given a socket (for transmitted data), and look
> up a socket if given a port (for received packets). I thought that
only
> one process at a time could use a port, and that a parent and a child
> could not use the same port.
>
> I thought this was all really simple and now I'm going to get an F
(sob)
> in FTP Servers 101.
>
> Where am I getting mixed up?
review:
a FRAME contains physical NIC addresses
a PACKET re-inforces the FRAME with a NETWORK address AND a
PORT(SOCKET) address
a SESSION between two computers is the combination of a PORT and a
"random number"; every PACKET needed to complete the operation will
contain this SESSION information.
and ALL of this takes place at a level FAR BELOW ftp proper -- FTP itself
has no knowledge that ANY of this is occuring -- all your FTP
client/server "knows" is that there is a file-handle-looking entity which
can be read from and written to -- this "file handle" is passed to the
program FROM the underlying networking/operating system.
(bonus) Homework question:
Since the packet/frame contains a UNIQUE address for the NIC, why do we
even NEED a "network" address?
[hint: there are two parts to the answer]
Tom Emerson
=====================================================
To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".
For problems, contact the list owner at
"rollin@scoug.com".
=====================================================
<< Previous Message <<
>> Next Message >>
Return to [ 02 |
October |
1998 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group.
OS/2, Workplace Shell, and IBM are registered trademarks of International
Business Machines Corporation.
All other trademarks remain the property of their respective owners.
