10

Consider a scenario where exists one server and multiple clients. And each client creates TCP connections to interact with the server. There are three usages of TCP alive:

  1. Server-side keepalive: The server sends TCP keepalive to make sure that the client is alive. If the client is dead, the server closes the TCP connection to the client.
  2. Client-side keepalive: Clients sends TCP keepalive to prevent the server from closing the TCP connection to the client.
  3. Both-side keepalive: Both server and clients send TCP keepalive as described in 1 and 2.

Which of the above usages of TCP keepalive are typical?

Jingguo Yao
  • 7,320
  • 6
  • 50
  • 63

2 Answers2

12

Actually, both server and client peers may use TCP keepalive. It is useful to ensure that the operating system will eventually release any resource associated with dead connections. Note that if a connection between two hosts get lost because of some issue with a router between them, then both hosts have to independently detect that the connection is dead, and cleanup for themselves.

Now, each host will maintain a timer on each connection indicating when it last received a packet associated with that connection. A host will send a keepalive packet when that timer goes over a certain threshold, which is defined locally (that is, hosts do not exchange information about their own keepalive configuration). So either host with the lowest keepalive time will take the initiative of sending a keepalive packet to the other host. If the packet indeed goes through, the other host (that is, the one with the higher keepalive time) will respond to that packet and reset its own timer; therefore, the host with an higher keepalive time will certainly never reach the need to send keepalive packet itself, unless the connection has indeed been lost.

Arguably, it could be said that servers are generally more aggressive on keepalive than client machines (that is, they will more often be configured with lower keepalive time), because hanging connections often have undesirable effects on server software (for example, the software may accept a limited number of concurrent connection, or the server may fork a new process instance associated with each connection).

James
  • 4,211
  • 1
  • 18
  • 34
6

Server-side keepalive: The server sends TCP keepalive to make sure that the client is alive. If the client is dead, the server closes the TCP connection to the client.

If the client is dead, the server gets a 'connection reset' error, after which it should close the connection.

Client-side keepalive: Clients sends TCP keepalive to prevent the server from closing the TCP connection to the client.

No. Client sends keepalive so that if the server is dead, the client will get a 'connection reset' error, after which it should close the connection.

Both-side keepalive

Both sides are capable of getting a 'connection reset' due to keepalive failure, as above.

Whuch of the above usages is typical?

Any of them, or none. If a peer is sending regularly it doesn't really need keepalive as well. It is therefore often of more use to a server than a client.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • @EJB By saying "It is therefore often of more use to a server than a client.", do you mean that the usage where the server sends keepalive is more typical? – Jingguo Yao Aug 11 '17 at 13:35
  • I have no idea how you would measure that, but it seems likely. It was standard for Telnet servers to use it, for example. – user207421 Aug 11 '17 at 21:14
  • 1
    Client-side keepalive: Clients sends TCP keepalive to prevent the server from closing the TCP connection to the client is incorrect but then if there is a firewall with idel timeout connection , keepalive can prevent ageing out of connection if keepalive packets sends by client are sent before firewall ideal timeout . Check the Solution section in link https://www.veritas.com/support/en_US/article.100028680 – Invictus May 10 '18 at 10:28
  • @Invictus Client-side keepalive works exactly the same as server-side keepalive, and specifically it cannot possibly prevent the server application from doing anything, as the server application never even sees it. It therefore cannot possibly prevent idle socket timeouts in servers. Only firewalls . – user207421 Mar 02 '20 at 21:29
  • @Invictus And there is nothing in your link about 'to prevent the server from closing the TCP connection'. It is all about preventing *intermediate devices,* i.e. routers, from dropping it. – user207421 Jun 18 '20 at 12:10