address contained in each packet's header? If so, where?
Take a CAREFUL look at the items shown above [and the part you snipped]
when looking at the items below:
> > 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
>
> You didn't say what these five numbers are. What are they?
Yes I did -- in the text you snipped. I indicated that each FRAME
contains a SOURCE and DESTINATION MAC address and each PACKET contained a
SOURCE and DESTINATION NETWORK address. given that bit of information
and the example data I listed, you should be able to correlate addresses
in the example [note, however, I'm not 100% certain I have the order
correct, but then, this is "for example only" -- suffice it to say that
each FRAME/PACKET contains the information given, even if not in the
order presented]
> > > 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.
> >
> > the packets DO have different addresses for the target
>
> Which number is the target value? And which layer contains the table
> that has the matching target value so the packet can be properly
steered
> to the target?
The answer to that is the bonus question. You're part way to the reason
why, even though each FRAME contains a guaranteed-to-be-unique MAC
address, you still need a PACKET with a seemingly redundant
guaranteed-to-be-unique NETWORK address. (BIG hint: it's a synonym for
"steering")
(BIGGER hint: look up the defnintion of the letters DNS)
> Thanks.
>
> - Peter Skye
I know you probably think I'm being obtuse by not coming straight out on
these final answers, but "if I told you everything, you wouldn't learn
it..." ;)
Now, not to get anyone's ire up or anything, I'll direct "interested
parties" to a company called SHOMITI -- on their website they have a
windows95 "packet sniffer" / protocol analyzer. In order to use it,
however, you need to have an actual network in place (I don't think it
will capture dial-up traffic). The "detail" screen has a sub-screen that
shows each packet captured and "DECODES" the packet into individual
components -- you can then highlight different parts of each component
and see EXACTLY where in the packet the "data" resides. this, by the
way, is the way I found out who my "neighbors" were and WHAT they were
doing since some of "their" traffic was bleeding into "my" end of the
aDSL line I had installed. Pacbell has since cleaned up the
gateway/router, so now "unneccessary" protocols are not being forwarded.
=====================================================
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 <<
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.
