Tcp Socket Closed

Question

I always thought that if you didn't implement a heartbeat, there was no way to know if one side of a TCP connection died unexpectedly. If the process was just killed on one side and didn't exit gracefully, there was no way for the socket to send FIN or let the other side know that it was closed.

(See some of the comments here for example http://www.perlmonks.org/?node_id=566568 )

But there is a stock order server that I connect to that has a new "cancel all orders on disconnect feature" that cancels live orders if the client dis-connects. It works even when I kill the process on my end, and there is definitely no heartbeat from my app to it.

So how is it able to detect when I've killed the process? My app is running on Windows Server 2003 and the order server is on Suse Linux Enterprise Server 10. Does Windows detect that the process associated with the socket is no longer alive and send the FIN?

Answer 1

It could be using a TCP Keep Alive to check for dead peers:

http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/overview.html

Answer 2

As far as I know, the OS detects the process termination and closes all the file descriptors/sockets/handles the process was using. So, there isn't difference between "killing" application and "gracefully terminating". Of course, the kernel itself must be running (=pc turned on, wire connected...). But it's on the OS the job of sending the FIN and so on... Also, if a host becomes unreachable /turned off, disconnected...) an intermediate gateway (or the client itself) may detect the event (e.g. loss of carrier, DHCP lease not renewed...) and reply to the packets sent to the died host with a ICMP error (host/network unreachable). This causes the peer's TCP connection to die, but it happens only if the client has some packet to send to the host.

Answer 3

When a process exits - for whatever reason - the OS will close the TCP connections it had open.

There's numerous other ways a TCP connection can go dead undetected

• someone yanks out a network cable inbetween.
• the computer at the other end gets nuked.
• a nat gateway inbetween silently drops the connection
• the OS at the other end crashes hard.
• the FIN packets gets lost.

Though enabling tcp keepalive, you'll detect it eventually - atleast during a couple of hours.