Re: TCP packets : end of thre-way handshake and start of data-transmission - how to detect ?
- From: dempson@xxxxxxxxxxxxx (David Empson)
- Date: Mon, 4 May 2009 23:49:09 +1200
R.Wieser <address@xxxxxxxxxxxxx> wrote:
I'm (still) busy trying to write TCP/IP for an rtl8019as NIC connected to
an ATMega32 controller, and seem to have hit a snag : I cannot seem to find
any information that tells me *with authority* when the three-way handshake
ends and the first data-packet starts.
Most info that I found describe the handshake, and than follow that up with
tearing-down the connection (sending the FIN flag).
And yes, I have seen the I've looked at the RFC 793 for it. It seems to
indicate that data-less packets being received by the server after it has
send its SYN/ACK should (pretty-much) be ignored, but nothing is actually
said about it.
RFC 793 Section 3.4 (Establishing a connection) says in part:
" Several examples of connection initiation follow. Although these
examples do not show connection synchronization using data-carrying
segments, this is perfectly legitimate, so long as the receiving TCP
doesn't deliver the data to the user until it is clear the data is
valid (i.e., the data must be buffered at the receiver until the
connection reaches the ESTABLISHED state)."
This says that it is possible to transport data in the SYN packets, but
any such data can't be delivered to higher levels until the three-way
handshake is complete.
I'd expect it would be difficult to send any data in the initial SYN
packet because it would be necessary to assume a window size. The second
packet (SYN/ACK) could include data because the first SYN could report a
window size, but the connection initiator might start with an empty
window in the initial SYN and then indicate a non-empty window in the
subsequent ACK.
If the connection responder indicates an empty window in its SYN, it
would need to send another packet after the three-way handshake to
report the window size (but that packet could contain data, if the
client has already indicated a non-empty window).
It allso makes me wonder about services that send back data when a
connection is made, *without* the client having to do anything else than
connect (it does not need to send any data. Like with , for instance,
"daytime" at port 15, "quote of the day" at port 19 and "chargen" on port
20).
Two possibile "minimum" dialogues might be:
Client sends SYN (with window nonempty)
Server sends SYN/ACK (with window nonempty if useful) and data
Client sends ACK (of SYN and possibly data)
Server sends FIN
Client sends FIN,ACK (of data and FIN)
Server sends ACK (of FIN)
Client sends SYN (with window 0)
Server sends SYN/ACK (with window 0)
Client sends ACK (with window nonempty)
Server sends data (with window nonempty if useful)
Client sends FIN,ACK (of data)
Server sends FIN,ACK (of FIN)
Client sends ACK (of FIN)
Combinations of empty/non-empty windows might also be possible.
Allso, I can't seem to find any information/description about when a server
is supposed to tell the client that further communication should be directed
at another port (what the high-level "accept" function does/seems to
handle). When I tried to change the port number in the SYN/ACK packet I
get a RST back.
That is a feature of the sockets API, and doesn't quite work the way you
might think it does. (I was also confused by this when I first started
using TCP/IP.)
The server listens on a well-known port, but the listening socket is not
used for communication, just to detect incoming connections. accept()
returns a newly created socket which deals with one specific connection.
The listening socket and all those returned by accept() have the same
port number at the server side, but all the sockets returned by accept()
have unique (client_IP, client_port) pairs.
The client has picked its own typically high-numbered port for the
outgoing connection, and addresses the server at its well-known port.
The resulting connection is identified by the quadruplet:
(client_IP, client_port, server_IP, server_port)
All packets for that connection (from initial SYN to last FIN/ACK and
following ACK) have the same values in the source and destination IP and
port fields (with the source and destination fields swapped for packets
in the opposite direction).
Multiple clients will have different (client_IP, client_port) pairs, so
their packets can be distinguished and sent to the appropriate socket at
the server, even though the (server_IP, server_port) pairs are the same.
--
David Empson
dempson@xxxxxxxxxxxxx
.
- Follow-Ups:
- References:
- Prev by Date: Re: 0x07 or 0xE0 CRC
- Next by Date: Fastest Processor Under 1W?
- Previous by thread: TCP packets : end of thre-way handshake and start of data-transmission - how to detect ?
- Next by thread: Re: TCP packets : end of thre-way handshake and start of data-transmission - how to detect ?
- Index(es):
Relevant Pages
|
