CODEWITHSUNDEEP
tcptimer
Sandeep
Sandeep

Reputation: 1247

tcp timer value for fin/ack termination sequence

I have a tcp client sending a HTTP POST request to a TCP server. Once the connection is established, data is being transmitted from server to client. Finally the server sends a [FIN, ACK] to the client. And the client sends an ACK. After 37 seconds the client sends a [FIN, ACK], but the client does not get ACK from the server, hence the client keeps re-transmitting the [FIN, ACK] on an exponential timer. Question: is the client allowed to send [FIN, ACK] with a delay of 37 seconds? Is there any standard timer value in this case? What is the expected behavior of the client and what is the expected behavior of the server in this case?

Upvotes: 0

Views: 724

Answers (1)

Barmar
Barmar

Reputation: 782166

There's no limit to the time between the server sending FIN and the client sending FIN. In TCP, the two directions of a connection are essentially independent, and a connection can remain in this "half-open" state for an arbitrary length of time.

There's no good reason why the server shouldn't send an ACK for the client's FIN/ACK. If it has destroyed the TCB for some reason (perhaps the server process has closed the socket and/or exited, so there's nothing to receive further data from the client) it should send a RST rather than an ACK, but something should be returned as a result of receiving the FIN/ACK. If nothing is being returned, it's a bug in the server's TCP implementation.

Upvotes: 0

Related Questions