No. An entire IP packet (after defragmentation) is given to to the TCP
stack. The stack then looks at the header to find out which 'socket' to
put the payload into, and then pushes the payload onto the end of the
socket buffer.
Doesn't the IP stack peel off it's own IP header before giving
the IP packet payload to the TCP stack? Otherwise, TCP stack
would have to know about IP details which violates encapsulation right?
In short, every layer of network stack peel off *it's own* header as
packet travels up to application layer IIRC.
You're right, I meant to say ... an entire IP packet payload is given to
the TCP stack...
Once this data gets to the
TCP stack, the TCP stack only cares about everything after the header in
the buffer. It doesn't care how big it is.
I'm still not clear how come TCP stack doesn't need to care how big each
TCP segment is. Sure it ultimately only cares about joining all
segments in correct order but how can it do *that* without knowing where
each segment begins and ends!?!?!
the TCP stack just does a sizeof(buf) to find out how much data it has
to play with with this one packet (or the fucntion call to enter the
stack is tcp(buf,count), I don't know without looking)
it still appears that the UDP length field is redundant and unnecessary.
No, that would assume that UDP has to run over IP, which it doesn't
What about TCP and UDP's usage of a "pseudo IP header" when calculating
their checksums? Those "pseudo IP headers" contain the sender and
receiver's IP addresses!? The TCP and UDP checksum fields
therefore seems to lock-in TCP and UDP to use only IP!?!? (Very
Microsoftish :)
--
Michael O'Keefe | [EMAIL PROTECTED]
Live on and Ride a 03 BMW F650GSDakar| [EMAIL PROTECTED] / |
I like less more or less less than |Work:+1 858 845 3514 / |
more. UNIX-live it,love it,fork() it |Fax :+1 858 845 2652 /_p_|
My views are MINE ALONE, blah, blah, |Home:+1 760 788 1296 \`O'|
blah, yackety yack - don't come back |Fax :+1 858 _/_\|_,
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
