TCP connection and corrupted data

I know about the three-way handshake to establish a TCP connection. If there are two hosts, "A" requesting information and "B" providing it, "A" sets the window size. Let's say that the window size will allow 3 packets to be transferred before "A" issues an ACK.

Assume that the connection has been establised and transfer of data occurs:

"B" sends frames 1, 2 and 3 to "A"
"A" sends an ACK, indicating that the next expected frame is 4
"B" sends frames 4, 5 and 6 to "A" but frame 5 is damaged
"A" sends an ACK, indicating that the next expected frame is 5 (rather than 7)

The question that I have is what happens next?

Does "B" send frames 5, 6 and 7 (even though 6 and 7 have been received by "A" correctly) and are the original frames 6 and 7 discarded?

---OR---

When "A" sends the ACK, does it indicate that it only requires frame 5 and reduce the window size so that a further ACK will be issued after the single frame has been received correctly? If this happens, "A" will have to reassemble the data into the correct order and return the window size to what it was previously.

I hope that I've explained the question. I've done some googling but haven't come up with any solution. I guess that I could run a packet sniffer and look for retransmitted frames but that might be a long process going through the traffic to identify them.

Thanks for your time.

Steve

Do any of the experts here have any comment about this topic for me?

I would suggest getting a fantastic book on Protocols called "The TCP/IP Guide" which i beleive is also available free online here

Anyhow, the detection of an error within a packet will usually cause the packet to simple get dropped. Once this is done, the normal reliability mechanism's from TCP will take over and be treated as though the packet wasn't received.

A simplistic way that acknowledgements work is that segments are sent and then acknowledged. If for example segments 1,2 are sent and acknowledged. Segments 3 & 4 are then sent, if you acknowledge segment 4, segment 3 is assumed to be received also. Therefore if you are missing segment 3, you are unable to acknowledge segment 4 because this will imply three has been received.

Something called a Retransmit timer is used to timeout segments that have been lost. In this example, segment 3's timer will timeout indicating that it hasn't been received. This will then be resent and then the client can acknowledge Segment 4.

Some implementations vary and if segment 3 isn't acknowledged and the timer runs out, both segments may get retransmitted or only segment 3.

In the Above guide, the section "TCP Reliability and Flow Control Features" explain it much better then me

Cheers

Wayne

That's great - many thanks. It looks like I'll have some reading for over Christmas!