3

I've a client and server running on the same server(Linux machine) and TCP connection in between them. I've observed that when I kill client, Kernel/OS sends RST packet after exactly 2 seconds after the client is killed. My question is which kernel parameter os Socket options govern this timer(2 secs)?

rohitsoren
  • 111
  • 5

2 Answers2

2

A RST isn't ordinarily sent between peers in a normal connection termination. A FIN is. When you kill the client, a FIN is sent on the connection to indicate to the server that the client won't be sending any more data.

But the server is apparently not paying attention to the FIN it receives when the client is killed (i.e. it would need to attempt a recv on the socket and react appropriately to the end-of-file indication it will get -- usually that means close its own socket). Subsequently, the server is attempting to send data to the client but the connection is closed. That is what results in a RST packet being sent.

RST means (roughly) "there is no active connection available to receive the data you're sending; it's pointless to send more."

And so the timing of that RST is likely based on when the server next attempts to send to the client, not on any kernel / OS configuration setting. If the server doesn't attempt to send and it doesn't close, the connection should just sit there idle forever, and no RST will be sent.

Gil Hamilton
  • 11,973
  • 28
  • 51
  • Random note. If the killed client was running on Windows, then Windows does not send that FIN. It would still give you the RST if you tried sending onto the socket. Another note. It is perfectly legit for a client to half-close, that is, send its FIN, but still receive what the server might be sending. Therefore, getting a FIN from a client does not necessarily mean all well-behaved servers have to stop sending. Final note, there is TCP timeout, it is long (hours) but certainly not forever. So the connection is gonna go away, eventually, even in the final case. – user7610 May 01 '20 at 16:27
  • Windows will most certainly send a FIN when you kill a client. On process exit, Windows closes all open files and sockets (like most OSes). That will cause a FIN to get sent (FINs are sent by the OS not by the application). – Gil Hamilton May 01 '20 at 21:29
  • You're correct that receiving a FIN doesn't prevent further sends. Half-closed connections have various interesting uses. – Gil Hamilton May 01 '20 at 21:30
  • There is no TCP inactivity timeout AFAIK. You can optionally set up keepalives but by default there is no session timeout. Two peers can hold an idle session open for days or weeks without ever sending data. Various switches, routers, firewalls and NATs may impose an idle session timeout, but that's not in TCP itself. If you think otherwise, I'd appreciate seeing a reference to the RFC. – Gil Hamilton May 01 '20 at 21:33
1

As mentioned in the UNIX Network programming Volume 1 Section Generic socket options, if a client is killed, TCP will send a FIN across the connection.

Bhargav Rao
  • 50,140
  • 28
  • 121
  • 140
Su47flying
  • 11
  • 1