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

Hello David,

Nope, it was not Zero. Initially it was about 8 KByte and the redefinition made it 32 KByte. The packet I did send (after the first ACK) had a payload of 10 bytes.

That is what I'm trying to evade, but as of now I have no clue to when I'm allowed to send, as a Server, my first data-packet. :-(

As mentioned, the first ACK shows a window-size of over 8 KByte, more than enough to receive my data.

Thanks for the hint. But I'm afraid that a Google-search on a generic phrase like that will not turn up much (if anything). Do you have an URL ?

Regards, Rudy Wieser

-- Origional message David Empson schreef in berichtnieuws

1iz8mix.1g51y2x1mke568N% snipped-for-privacy@actrix.gen.nz...

what I

will

skip

is on

it

not

send a

Hello Paul,

I'm an hobbyist. They do normally not need something like a reason to try to do something, do they ? :-)

But if you want to know, I've seen several projects implementing the same, and thought it would be a nice project to try for myself.

Examples:

ARP, ICMP (together PING), IP and UDP are allready there. TCP is just the next to be implemented.

Regards, Rudy Wieser

-- Origional message Paul Keinanen schreef in berichtnieuws snipped-for-privacy@4ax.com...

socket.

*Bytes*

the

connection

window.

Hello Andrew,

Thanks for the hint. I'll have a look at it.

Regards, Rudy Wieser

-- Origional message Andrew Jackson schreef in berichtnieuws snipped-for-privacy@eclipse.net.uk...

socket.

*Bytes*

the

connection

together

window.

In that case, I'm pretty sure you are misinterpreting what is happening, or making a false assumption about how TCP handles acknowledgements.

The first ACK from the client confirms the connection is fully established and both ends have agreed on options such as MSS, and established the initial sequence numbers. It is perfectly valid for the server to send data as soon as it gets that ACK (possibly earlier - in the SYN/ACK, depending on what window size the client indicated in its SYN).

Each station is supposed to hold "early" data and deliver it to the application after the connection enters the ESTABLISHED state (as per RFC 793).

Using Wireshark to look at the packets and the timing would be a big help.

I suspect what is happening is something like this:

1. Client sends SYN with initial sequence number and possibly an MSS option. Window size could be zero or 8KB at this point.

1. Server sends SYN/ACK with its initial sequence number and possibly an MSS option. Probably also includes a nonzero window size at this point.

2. Client sends ACK, completing the three-way handshake. Per your comments, the client has indicated a window size of 8KB in this packet.

4.1. Server transmits a packet with 10 bytes of data.

4.2. At the same time (or slightly earlier, at least before the server packet arrives), the client sends another ACK to report a larger window (32KB).

4.3. The server's packet with data arrives at the client. The 10 bytes are delivered to the application.

4.4. The client's ACK with a larger window arrives at the server, not acknowledging any of the data you just sent, because the client hadn't received that packet when it sent its second ack.

The second ACK from the client and your data packet crossed in transit. This is perfectly normal. A correctly implemented TCP/IP stack will keep waiting for an acknowledgement which confirms the 10 bytes were received.

It is also possible that the client did receive your packet before sending its second ACK, but the client didn't enter the ESTABLISHED state until after your packet arrived. It therefore couldn't deliver the data to the application yet and held onto it briefly. The ACK it sent (upon entering ESTABLISHED and increasing the window size) didn't acknowledge your data, because it hadn't been delivered to the application at that point.

1. A short time later, the client sends another ACK, confirming it has received the 10 bytes you sent. This will probably be after a delay in the order of 200 ms if you haven't sent another packet with further data and the client has no data to send.

You would need to hold onto your data for a while and eventually retransmit if that ACK doesn't turn up.

Don't forget that TCP is a byte stream protocol. TCP cares little about packets - they are just a means of transporting a sequence of bytes of data, along with piggyback acknowledgements. It is the data bytes which are counted and eventually acknowledged. Apart from special flags like SYN and FIN, you should not be reacting to packets, only to the sequenced data they contain, the updated receive window and the acknowledgement sequence number.

You can't expect an instant acknowledgement when you send data. The client's TCP stack will acknowledge your data when it gets around to it, and you may receive one or more packets which don't acknowledge your data, due to delays in the network or other reasons.

There are three basic cases, if you are observing the packets on the network:

(a) If the client gave a nonzero window in its SYN, then you are allowed to send data in the SYN/ACK.

(b) If the client gave a zero window in its SYN but a nonzero window in its first ACK, then you are allowed to send data immediately after receiving that ACK.

(c) If the client gave a zero window in it SYN and its first ACK but then sends another ACK with a nonzero window, then you are allowed to send data immediately after receiving the second ACK.

In all cases, it is the window size reported by the client which determines whether you (as the server) are allowed to send data. You don't need to worry about which packet you have received. You just look at the window size.

If you send data "early", it will not be acknowledged by the client until at least the third packet it sends (SYN, ACK and another ACK) and probably not until a later packet, depending on how many packets it sends immediately after the first ACK.

Even after you are well into an established connection, any data you send will be acknowledged some time later, and you could receive multiple packets which don't acknowledge the data you sent.

You must hold onto your transmit data (or be able to regenerate the same data) until it is acknowledged, and may eventually need to retransmit it after a timeout due to a missing acknowledgement.

You didn't try very hard. :-)

Google for "uIP" (without the quotes) and it is the second hit.

Google for "uIP TCP/IP" (without the quotes) and it is the first hit.

--
David Empson
dempson@actrix.gen.nz

An OS won't normally delay an ACK until the data is passed up to user-space. Programs won't necessarily read a socket as soon as data is available, and you don't want the peer to keep re-transmitting (and increasing its timeout) just because the client hasn't read the data.

That seems reasonable.

I've also had a closer look at the TCP state diagram and it appears the client should be in the ESTABLISHED state as soon as it sends its first ACK, thus data sent by the server in response to that packet won't need to be held by the client's TCP stack.

This means my first theory is more likely: the client's second ACK and the initial data from the server crossed in transit.

--
David Empson
dempson@actrix.gen.nz

Get yourself Richard Stevens' TCP/IP Illustrated series. Reading it will likely save you a lot of trial and much error.

Hello Jan,

I did find and read a few PDFs that show what should be happening. But as they allso did not show the actual data-sending I just assumed it was some info that was just not included. It turned out I was wrong.

But I'll see if I can find that book(/books?). Thanks.

Regards, Rudy Wieser

-- Origi> >

I

connection