Connection reset by peer, broken pipe...

Question

This part of sockets is just needlessly confusing. Perhaps someone can shed some light on this?
Sometimes I get an IOException with as message "Connection reset by peer". Other times, it's "broken pipe". What is the difference? Why isn't there a way other than parsing the exception message text to figure out if it's a client 'hanging up on you' unexpectedly or something else?
Secondly, in my NIO server, all webbrowsers, but for some reason firefox especially, really likes to make a full request, than grab 0 to 99 bytes (the full return HTTP message size is much larger than that), and then silently hang up and immediately re-request the same resource again. Sometimes 10 to 15 times in a row. Firefox shows no errors of any kind when it does this. the read() operation on the socket returns -1 which is what ends up causing the close.
Is this because '-1' doesn't really mean: The socket is closed, it actually just means: the socket INPUT is closed but you can still send?
And if it is the latter, how the heck do I detect a connection in lockdown state in a non-blocking environment?

Answer 1

Sometimes I get an IOException with as message
"Connection reset by peer". Other times, it's "broken
pipe". What is the difference? Why isn't there a way
other than parsing the exception message text to
figure out if it's a client 'hanging up on you'
unexpectedly or something else?I agree: I would love there to be a ConnectionResetException. Anyway, practically any IOException on a socket operation means you should close it (and forget about it if you're a server).
Secondly, in my NIO server, all webbrowsers, but for
some reason firefox especially, really likes to make
a full request, than grab 0 to 99 bytes (the full
return HTTP message size is much larger than that),
and then silently hang up and immediately re-request
the same resource again.Maybe it is doing a HEAD request?
Is this because '-1' doesn't really mean: The socket
is closed, it actually just means: the socket INPUT
is closed but you can still send?It actually means a one-way close originating from the other end, which could be the result of either a close or a shutdownOutput() by the peer. If it was a shutdownOutput() you can indeed still send.
And if it is the latter, how the heck do I detect a
connection in lockdown state in a non-blocking
environment?What do you mean by 'lockdown state'? If you mean how do you detect when the peer finally closes after a shutdown, the answer is that you eventually get a connection reset when writing, which is where we came in. If you have a socket channel which has detected EOS as above and you don't have any more data to send to it, close it.