DESCRIPTION


If there is no activity on a given connection for two hours,the server (the end which enables the keepalive option) sends a probe segment to the client.


The client host must be in one of four states:

  1. The client host is still up and running and reachable from the server. The client's TCP responds normally and the server knows that the other end is still up. The server's TCP will reset the keepalive timer for 2 hours in the future. If there is application traffic across the connection before the next 2_hour timer expires, the timer is reset for 2 hours in the future, following the exchange of data.
  2. The client's host has crashed and is either down or in the process of rebooting. In either case, its TCP is not responding. The server will not receive a response to its probe and it times out after 75 seconds. The server sends a total of 10 of these probes, 75 seconds apart, and if it doesn't receive a response, the server considers the client's host as down and terminates the connection.
  3. The client's host has crashed and rebooted. Here the server will recieve a response to its keepalive probe, but the response will be a reset, causing the server to terminate the connection.
  4. The client's host is up and running, but unreachable from the server. This is the same as senario 2, because TCP can't distinguish between the two. All it can tell is that no replies are received to its probes.



THE APPLICATIN POINT OF VIEW

In the first scenario the server application has no idea that the keepalive probes are taking place. Everything is handled at the TCP layer. It's transparent to the application until one of the scenarios 2, 3 or 4 occurs.
In these three scenarios an error is returned to the server application by it's TCP.
Normally the server has issued a read from the network, waiting for data from the client. If the keepalive feature returns an error, it is returned to the server as the return value from the read.
In scenario 2 the error is something like:"connection timeout".
In scenario 3 the error is something like:"connection reset by peer".
The fourth scenario may look like the connection timed out, or may cause another error to be returned, depending on whether an ICMP error related to the connection is received.




To Top of page





TO THE OTHER PAGES:

BACK TO FIRST PAGE

ADVANTAGES & DISADVANTAGES

INTRODUCTION