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

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.