If you think about this, there isn't any way you could do this. Let's say you had an established connection, you've written some, you've read some back, and you arrive at the point in your code where you want to make your determination.

If, at exactly that point, the machine at the other end of the connection dies; or the process holding the socket at that end is killed; or if a power failure takes out a critical router somewhere between your machine and that other machine; there is no way for you to know until you attempt some communication with the other end.

If the process at the other end takes some deliberate action to sever the connection, close the socket or shutting it down, then the transport layer can send notice of that to your machine, but until you read that notice, whether by attempting to read data, or by querying the status from the transport layer, your code will not know about it.

You could check for eof each time before you read or write, but as that will only detect deliberate disconnects, your read and write code will still need to check return codes for all the other possible causes of failure anyway, so you might as well skip the attempt and handle the deliberate case in that same code.

I think you will know if a socket crashed only when writing to it, and checking this operation results.

Is the program using some specific protocol, or you are developing your own? IRC, for example, has a PING command for checking connection status.

If you are responsible for both sides, you can implement something like that.

eof might work. Whether your socket is non-blocking and whether select works on your system is likely to be important.

The other situation is that your peer has disappeared, for example crashed, had a network failure, etc. In this case, there's no way to know that without sending some data. That's why many protocols have a NOOP operation or PING and PONG packets, as izut suggests. TCP keepalives are one option; on many systems you can set a system-wide timeout for TCP connections. If the connections are idle for that long, the kernel will send an empty packet to test the connection, and the connection will be shut down if it receives no response. Unfortunately I don't know of a way to send a 0-size probe packet from userspace.

system 'netstat -na'
[download]

lsof -Pni :80
[download]

will also do the trick. Of course substituting your port number for 80.


Ted
--
"That which we persist in doing becomes easier, not that the task itself has become easier, but that our ability to perform it has improved."
  --Ralph Waldo Emerson

In the general case, there's no way of checking whether a socket is connected without actually writing to or reading from it.

         int ierr;
         bool optval = true;
         ierr = setsockopt( Socket->SocketHandle,
                                 SOL_SOCKET,
                                 SO_KEEPALIVE,
                                 (const char FAR * ) &optval,
                                 sizeof(bool));
         if( ierr == 0 )
         {
             linger struct_linger;
             struct_linger.l_onoff  = 1;
             struct_linger.l_linger = 0;
             ierr = setsockopt( Socket->SocketHandle,
                                     SOL_SOCKET,
                                     SO_LINGER,
                                     (const char FAR * ) &struct_linger,
                                     sizeof(linger));

I confirm getpeername will do the trick. if the remote end has closed connection then getpeername will fail. RS.

I understand this is an outdated post, but I need confirmation that getpeername is a reliable test that socket is still connected. Is there a best practice please?