Testing for a closed socket

Question

I\'m trying to test for a closed socket that has been gracefully closed by the peer without incurring the latency hit of a double send to induce a SIGPIPE.

Answer 1

Do you control the other end? The most reliable way to perform a "clean" shut down of a socket is for the other end to send a "goodbye" message of some sort.

Answer 2

OK, so I ran some more tests and this is what I found.

I set my client up to send HTTP/1.1 Connection: close messages to the server causing the server to call close after it's last write of data. When my client finished reading data from a GET transaction it would test the socket to see if it was still open using the above method and then attempt to issue another GET.

What I found is that approximately 30% of the time my test would occur before the server's FIN arrived leading to false-positives and failed operations.

Probably the only way to make this reasonably reliable, say close to 99% would be to introduce artificial delays related to the connection latency between the last read and the attempted socket reuse - however, that would pretty much murder performance.

So, I have to conclude that while this tool is useful, it's only marginally so.

Answer 3

(Slightly "off topic", sorry). Perhaps this discussion may be helpful four you. It still doesn't answer to you "FIN" question, but may help you to react in a more easy way to the peer shutdown while your program is sending.

Bye