Question

How should I check a (TCP) socket to find out whether it is connected?

I have read about the Socket.Connected property in MSDN, but it says it only shows the state according to the last I/O. This isn’t useful for me, since I want to do this before trying to read from the socket. The remarks section also notes that:

If you need to determine the current state of the connection, make a nonblocking, zero-byte Send call. If the call returns successfully or throws a WAEWOULDBLOCK error code (10035), then the socket is still connected; otherwise, the socket is no longer connected.

The example on the same page shows how to do it.⁽¹⁾ But a post by Ian Griffiths says that I should read from the socket, not send through it.

Another post by Pete Duniho says:

… after you’ve called Shutdown(), call Receive() until it returns 0 (assuming the remote endpoint isn’t actually going to send you anything, that will happen as soon as the remote endpoint has received all of your data). Unless you do that, you have no assurance that the remote endpoint has actually received all of the data you sent, even using a lingering socket.

I don’t really understand his statement about calling Receive() to make sure that the remote endpoint has actually received all the data I sent. (Do sockets block receiving until the sending buffer is empty?)

I am confused by the different methods proposed. Could you please explain them?

---

(1) I wonder why the example for the Socket.Connected property allocates a 1-byte array, even though it calls Send with 0 length?

Answer 1

Death of a socket changes its behavior in several ways, so these methods are both valid 🙂

With both methods you actually check those parts of the socket’s behavior that change after disconnection.

I don’t really understand his statement about calling Receive() to make sure that the remote endpoint has actually received all the data I sent. (Do sockets block receiving until the sending buffer is empty?)

TCP is reliable protocol, that means that every packet you send must be acknowledged. Acknowledgement implies sending the packets with ACK bit set. These packets may or may not contain additional (payload) data.

When the socket is connected, Receive() will block until the socket receives a packet with non-empty payload. But when the socket is disconnected, Receive() will return as soon as the last ACK packet arrives.

Calling Receive() ensures that you either receive that last ACK packet from your remote endpoint or a disconnect timeout occurs and you will be able to receive nothing more on this socket.

The example on the same page shows how to do it. (I wonder why does it allocate a 1-byte array, even though it calls Send with 0 length?) But a post by Ian Griffiths says that I should read from the socket, not send through it.

When send()ing to a socket, you actually try to append some data to the end of the socket queue. Is there is some place left in the buffer, then your Send() returns instantly, if not, the Send() blocks until there is some place.

When the socket is in disconnected state, TCP/IP stack prevents all further operations with the buffer, that’s why Send() returns an error.

Send() implements a basic pointer check, this means it fails when a NULL pointer is passed to it. You may probably pass any non-null constant as a pointer, but you better allocate 1 byte instead of making the constant up — just in case.

---

You may use any method you like, as none of them is resource consuming. As long as they are used for socket connection checking, they are identical.

As for me, I would prefer Receive(), as this is what you normally run in a cycle and wait for. You get a non-zero from Receive(), you process data; you get a zero, you process disconnection.