Reputation: 4949
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
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
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