Linux reset detection with Linux sockets

Question

When one end of a TCP channel goes down, it sends a reset (RST) message to the other end. I want to get this at the application level.

In my code, I use the select() call to get input from potentially multiple sources, including a TCP connection. I saw that when select() shows that there is data ready to be read in the connection, then read() call returns 0 bytes that were read after the RST was sent over TCP. (I understand recv() works similarly to read() .)

Does read() return 0 bytes (after select() ) in a TCP connection only if the connection was reset? Does it ever return 0 bytes in any other cases?

I remember that some time ago I used a specific Ethernet device on the other end of the connection, and this end of Linux received 0 bytes after select() , but not for the reset connection, but rather through the middle some data streams. I confirmed in Wireshark that the received packet has 0 bytes of data. Is this a mistake or, as the question above, does it really have this behavior? I do not remember what device it was, as it was several years ago, but he used the Windows driver.

Answer 1

When one end of a TCP channel goes down, it sends a reset (RST) message to the other end.

Not okay.

I want to get this at the application level.

You will.

I saw that when select () shows that there is data ready to be read in the connection, and then the read () call returns 0 bytes that were read after the RST was sent over TCP.

Not.

Can read () return 0 bytes (after select ()) in a TCP connection only if the connection was reset?

Never if the connection was reset. In this case, it returns -1 with errno == ECONNRESET .

Does it ever return 0 bytes in any other cases?

It returns zero if and only if FIN was received, i.e. peer closed the connection or turned off its socket for output.

Answer 2

You also get RST if you try to connect to a port on a server for which there is no listener.

Suppose you have a connection to the server and send data regularly, but then rebooting the server, your pair of sockets no longer exists, and then you also get RST.

The server can send RST using socket options, which I suppose, but this is not a good idea, servers / clients should use normal socket closure in normal situations, when they want to close the connection, and let the TCP 4 handshake do the job .