Tcp Connector Closed

I always thought that if you did not perform a heartbeat, there was no way to find out if one side of the TCP connection unexpectedly died. If the process was simply killed on one side and did not exit gracefully, there was no way for the socket to send FIN or to let the other know that it was closed.

(see some comments here, for example http://www.perlmonks.org/?node_id=566568 )

But there is a purchase order server to which I connect, it has a new “cancel all orders for the disconnect function”, which cancels direct orders if the client disconnects. It works even when I kill a process at my end, and certainly there is no beating from my application to it.

So how can he detect when I killed the process? My application runs on Windows Server 2003, and the order server runs on Suse Linux Enterprise Server 10. Does Windows mean that the socket process is no longer alive and sends FIN?

+4
source share
3 answers

When the process exits - for some reason - the OS will close open TCP connections.

There are many other ways in which a TCP connection can go undetected dead.

  • someone removes the network cable between them.
  • the computer from the other end gets nuked.
  • the nat gateway between them silently disconnects the connection.
  • The OS on the other end will work a lot.
  • FIN packets are lost.

Although enabling tcp is keepalive, you will find it in the end - at least for a few hours.

+7
source

It can use TCP Keep Alive to check for dead nodes:

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

+2
source

As far as I know, the OS detects process termination and closes all file descriptors / sockets / descriptors used by this process. Thus, there is no difference between "killing" the application and "graceful completion." Of course, the kernel itself should work (= pc on, wire connected ...). But this is on the OS the work of sending FIN and so on ... In addition, if the host becomes unavailable / disconnected, disconnected ...) the intermediate gateway (or the client itself) can detect an event (for example, carrier loss, DHCP lease is not renewed ...) and respond to packets sent to the deceased host with an ICMP error (host / network is unavailable). This causes the peer-to-peer TCP connection to die, but this only happens if the client has a packet to send to the host.

+2
source

Source: https://habr.com/ru/post/1303855/


All Articles