Roam
Roam

Reputation: 4949

TCP 3-way handshake - multiple SYNs

Suppose host H1 is looking to make a TCP connection with H2 and sending a SYN for the 1st step of 3-way handshake. H1 then isn't hearing back in timeout and is sending a second SYN to H2.

Then, H1 is hearing back on both of these SYNs. What does H1 do in this case-- which one of these two does it ACK as the 3rd step of handshake, the first SYN+ACK from H2 or the second? The two SYN+ACK have 2 different Initial Sequence Numbers (ISNs) of H2. They also have different ACKs-- H1 sent 2 different ISNs in its two SYNs.

From another point - in such a case, what does H2 do? So - H2 received an SYN and sent SYN+ACK in response to it. After a while, H2 received another SYN+ACK from H1. What does H2 do in this case:

or

How is this handled in TCP?

TIA

Note: I've seen What if a TCP handshake segment is lost?, TCP: SYN request receives SYN response instead of SYN-ACK, tcpip 3-way handshake and TCP handshake reliability along with some other useful discussions.

//------------------------------------------------

EDIT:

The answer seems to lie in the RST flag-- resetting whenever in doubt of the sequence#s. See Figure 9 of RFC793.

However, the Q still stands in the light of the comment below: when does H1 ("TCP A" in Figure 9) retry the connection with a new ISN of its-- how long after and under which circumstances?

Upvotes: 2

Views: 2279

Answers (2)

Joni
Joni

Reputation: 111369

The situation in figure 9 happens when the SYN from a previous connection attempt arrives after the sender has already given up on that connection. Host B sends an ACK for this extra SYN, and Host A sees that the sequence number of the ACK is wrong. Then Host A aborts the connection by sending an RST.

Upvotes: 2

user207421
user207421

Reputation: 311039

Your question is meaningless. Both SYNs are the same, from the point of view of sequence number, and both get acknowledged in the same way.

Upvotes: 2

Related Questions