Great question.  I find the most reliable way to detect disconnects is by
paying careful attention to the return value / error code from recv( ) and
send( ).  There's no clean rule of what's fatal and what's not, but here's
my breakdown of recv( ) errors for a blocking TCP socket:

 

            case WSANOTINITIALISED:

            case WSAENETDOWN:

            case WSAEFAULT:

            case WSAENOTCONN:

            case WSAENETRESET:

            case WSAENOTSOCK:

            case WSAEOPNOTSUPP:

            case WSAESHUTDOWN:

            case WSAEMSGSIZE:

            case WSAEINVAL:

            case WSAECONNABORTED:

            case WSAETIMEDOUT:

            case WSAECONNRESET:

            default:

                // Interesting -- fatal socket error

                return SOCKET_ERROR;

 

            case WSAEINTR:

            case WSAEINPROGRESS:

            case WSAEWOULDBLOCK:

                // Not interesting, and not fatal.

                return 0;

 

If the socket is non-blocking then it gets a little tricky because you might
get (for example) An ENOTCONN when trying to send on a socket that hasn't
yet connected.  However, if you know that you've already connected but later
get an ENOTCONN, then it can mean you've lost the connection.

 

You can also get some weird non-fatal things such as EINTR when receiving a
HUP signal on the process when in a select( ).

 

Also, if using select( ), poll( ), or epoll( ), be sure to pay attention to
"except" events - depending on the situation it can describe error
conditions.

 

Finally, if you're calling recvfrom( ) on a UDP socket, be sure to pay
attention to ECONNRESET - it means that a packet you sent previously went to
a non-existent host; the address returned from recvfrom( ) is the one that
doesn't exist (or, at least, returned an ICMP response).

 

Anyway, error detection is a bit of a mess, but this might give you a place
to start.  Good luck!

 

-david

 

  _____  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Vikram Dham
Sent: Friday, June 15, 2007 2:40 PM
To: [email protected]
Subject: [p2p-hackers] How to reliably detect TCP connection close

 

What is best practice / approach to detect that read side / or both end of
TCP connection have closed? Does poll / select set any error/read/write
descriptors to communicate connection close information to the application?

Thanks

Vikram 

_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers

Reply via email to