Re: TCP packets : end of thre-way handshake and start of data-transmission - how to detect ?

Hello David,

Thanks for your reply, but somehow I can't seem to extract from it what I
need :

RFC 793 Section 3.4 (Establishing a connection) says in part:
<snip quote>

Its not the client actually sending data before it should I'm concerned
about (as the controller does not have enough RAM to store the data I will
probably just drop the connection), but how figure out which packets to skip
before I'm allowed to send some data myself : Currently I receive two
different ACK responses to my SYN/ACK (the second packet re-defines the
window-size). When I send some data after receiving the first ACK the
client behaves as if I did not send that packet at all (mind you, this is on
a LAN).

I can ofcourse "fix" this by checking the Acknowledgement-number and as it
did not change re-send the data, but a) would like to know why it does not
respond to my data b) have not enough resources in the controller to send a
packet again anyway. :-\

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.)

Thank you for that info, but can you tell me how I should, after the initial
contact, re-direct the client to another port ?

Regards,
Rudy Wieser


-- Origional message
David Empson <dempson@xxxxxxxxxxxxx> schreef in berichtnieuws
1iz7rka.1twixqu1seqp20N%dempson@xxxxxxxxxxxxxxxx
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



.

Relevant Pages