- Fact:
- The server has an
"on-going" TCP connection
(with the
same
TCP connection identifiers)
- The server does
not have
sufficient information
to conclude
for sure:
- Whether the "on-going" TCP connection is still valid or not
- The server has an
"on-going" TCP connection
(with the
same
TCP connection identifiers)
- We assume that:
- The server currently does not have any data to transmit to the client
In other words:
- The server
cannot send a
TCP data message to
the client
(Such a message can be used to verify if the send seq. no and ACK no are still valid !!!)
- Solution:
- The server must:
- Save the
new connection request
- Verify the status of the current TCP connection
- Save the
new connection request
- To verify the
status of the
current TCP connection:
- The server sends an ACK message (= empty message) to the client !!!
Graphically:
NOTE:
- We will see that the ACK message will result in 2 different responses from the client !!!
- The server must:
- Legimate request scenario:
- The client has
crashed:
- Later, the
client has
recovered and
send a
TCP connection request:
-
Solution:
the server
saves the
connection request and
sends
an ACK message (= empty)
to the client:
When the client receives the server's ACK message, the client will detect that:
- the
ACK number
(for its SYN request)
is wrong !!!!!
(The receiver has only sent 1 byte (SYN).
So the reply must contain ACK no = 7626 !!!)
- the
ACK number
(for its SYN request)
is wrong !!!!!
- The client
must
reject
the Seq No
by sending a
RESET message:
Notice that the RESET message contains a send sequence number !!!!
- When the server
receives the
RESET(7656) message:
- The server will delete the deprecated TCP state record !!!
Graphically:
The server can now proceed to process the saved SYN request:
- Pick a random send seq. no. (= 5678)
- Send an SYN + ACK message to the receiver
Graphically:
-
When the client
receives the
server's reply,
the client will
respond with an ACK:
because the ACK no is correct !!!
Result:
- After the client recovers from a crash, the client has established a new TCP connection with the server !!!
- The client has
crashed:
- Bogus request scenario:
- The client and
server has
a valid TCP connection:
- The server
receives a
bogus connection request:
-
Solution:
the server
saves the
connection request and
sends
an ACK message (= empty)
to the client:
When the client receives the ACK message:
- The client does nothing !!!
Because:
- The seq. no is
correct, so
no error message is
transmitted
- The ACK message need not to be acknowledged !!!
- Result:
the server
receives
no response:
The server will time out:
- To make sure that the
pending connection request is
bogus:
- The server will retransmit the ACK message a few more times.....
- To make sure that the
pending connection request is
bogus:
-
After a maximum number
of retransmissions,
the server will
purge
the bogus
connection request:
The valid TCP connection will proceed uninterrupted....
- The client and
server has
a valid TCP connection: