Is TCP Keepalive the only mechanism to determine a broken link?

Question

I recently ran into a issue where intermediate link betweeen a TCP server and client was down. The client has the requirement of connecting to a secondary server if the primary server is down. When the primary server is bought down (Ex ..by doing ^C on the terminal), there is TCP shutdown sequence that gets through and client sucessfully detects the broken link and tries the secondary. However if the intermediate link goes down ,the client and server would be unaware of it. The only way the client can detect is when its TCP bufferes gets filled up with failed 'send' operations.

As a solution to this the 'TCP Keepalive' mechanism has been used. This works satisfacatorily.

My question is 'TCP Keepalive' the only solution?

-Prabhu

Answer 1

Keepalive was designed to deal with so-called half-opened connections, when one of the sides (typically the server that receives the requests) is unaware that connection was broken. Client usually knows about it because the attempt to send request to the server will return you error.

Another option is to keep listener running - when client detects comms problems it just tries to connect to the server again. Server gets the incoming connection, check whether it from the same IP address, and if it is the case, closes opened connection and establishes a new one.

But if client is unaware that connection went down and server needs to send something, there is no way for server to re-establish connection but TCP keepalive.

If you don't want to use keepalive, you can use application-level keepalive, e.g. sending something like application-specific echo messages.