I\'m currently maintaining some web server software and I need to perform a lot of I/O operations. The read()
, write()
, close()
and
If you are sure that nothing on your side of the TCP connection is closing the connection, then it sounds to me like the remote side is closing the connection.
ENOTCONN
, as others have pointed out, simply means that the socket is not connected. This doesn't necessarily mean that connect
failed. The socket may well have been connected previously, it just wasn't at the time of the call that resulted in ENOTCONN
.
This differs from:
ECONNRESET
: the other end of the connection sent a TCP reset packet. This can happen if the other end is refusing a connection, or doesn't acknowledge that it is already connected, among other things.ETIMEDOUT
: this generally applies only to connect
. This can happen if the connection attempt is not successful within a system-dependent amount of time.EPIPE
can sometimes be returned by some socket-related system calls under conditions that are more or less the same as ENOTCONN
. For example, on some systems, EPIPE
and ENOTCONN
are synonymous when returned by send
.
While it's not unusual for shutdown
to return ENOTCONN
, since this function is supposed to tear down the TCP connection, I would be surprised to see close
return ENOTCONN
. It really should never do that.
Finally, as dwc mentioned, EBADF
shouldn't apply in your scenario unless you are attempting some operation on a file descriptor that has already been close
d. Having a socket get disconnected (i.e. the TCP connection has broken) is not the same as closing the file descriptor associated with that socket.