I don't think so. I believe Gordon is wrong.
My experience is writing programs that receive connections from C
programs. The C programs call close on a file descriptor. The thing
that happens in the Java program is a java.net.SocketException gets
thrown, with something like "connection reset" or "connection reset by
peer" as the message.
opalpa@gmail.com
http://www.geocities.com/opalpaweb/
> I don't think so. I believe Gordon is wrong.
>
[quoted text clipped - 3 lines]
> thrown, with something like "connection reset" or "connection reset by
> peer" as the message.
When the descriptor is closed, a correctly behaving TCP stack sends
FIN (not RST) causing the remote reader to get EOF after reaching the
end of any remaining data. BufferedReader.readLine() returns NULL at
that point, both according to Sun's API documentation and in practice.
"Connection reset by peer" does not indicate a normal close, it
indicates an aborted connection, or that you've sent data to a port
for which there is no corresponding socket. I've also heard that some
TCP stacks (notably some versions of windows) abort connections rather
than closing them properly.
/gordon

Signature
[ do not email me copies of your followups ]
g o r d o n + n e w s @ b a l d e r 1 3 . s e
opalpa@gmail.com - 10 Jan 2006 19:09 GMT
I received SocketExceptions when Solaris C clients closed connections.
This problem bugged me before and I've posted here and on various
message boards about it. It's not just windows. Searching this
newsgroup shows a variety of suggestions which inteslf suggests that
these things do not behave consistantly.
http://www.geocities.com/opalpaweb/
Oliver Wong - 10 Jan 2006 21:17 GMT
>I received SocketExceptions when Solaris C clients closed connections.
> This problem bugged me before and I've posted here and on various
[quoted text clipped - 3 lines]
>
> http://www.geocities.com/opalpaweb/
There's two concepts here:
(1) Does receiving a NULL give a 100% guaranteed indication that the
connection was closed?
(2) When the connection is closed, am I 100% guaranteed to receive NULL?
I believe Gordon is saying "yes" to (1), and Opalpa is saying "no" to
(2), and I agree with both of them.
- Oliver
Chris Uppal - 11 Jan 2006 11:17 GMT
> "Connection reset by peer" does not indicate a normal close, it
> indicates an aborted connection, or that you've sent data to a port
> for which there is no corresponding socket. I've also heard that some
> TCP stacks (notably some versions of windows) abort connections rather
> than closing them properly.
Do you mean that it is a common practise for Windows programmers to
closesocket() rather than use shutdown() as documented (unusually well for MS)
at:
http://msdn.microsoft.com/library/en-us/winsock/winsock/graceful_shutdown_linger
_options_and_socket_closure_2.asp
-- chris
Gordon Beaton - 11 Jan 2006 12:14 GMT
> Do you mean that it is a common practise for Windows programmers to
> closesocket() rather than use shutdown() as documented (unusually well for MS)
> at:
> http://msdn.microsoft.com/library/en-us/winsock/winsock/graceful_shutdown_linger
_options_and_socket_closure_2.asp
I have no idea what any windows programmers commonly do. What I've
heard is that the TCP stack on (some versions of?) windows sends RST
instead of FIN when a normal close is done, giving the appearance of
an aborted connection. Perhaps it is due to using closesocket()
instead of shutdown() as you suggest, or expecting closesocket() to do
the same thing as close(), which apparently it doesn't.
/gordon

Signature
[ do not email me copies of your followups ]
g o r d o n + n e w s @ b a l d e r 1 3 . s e
EJP - 14 Jan 2006 09:32 GMT
>>Do you mean that it is a common practise for Windows programmers to
>>closesocket() rather than use shutdown() as documented (unusually well for MS)
[quoted text clipped - 7 lines]
> instead of shutdown() as you suggest, or expecting closesocket() to do
> the same thing as close(), which apparently it doesn't.
Yes. In Unix TCP stacks close() implies shutdown(fd,SHUT_WR) so a FIN is
sent. In WINSOCK closesocket() does *not* imply shutdown(fd,SHUT_WR) so
it behaves like an abortive close and an RST is sent, unless the
programmer has also called shutdown(fd,SHUT_WR).
Chris Uppal - 14 Jan 2006 11:54 GMT
> Yes. In Unix TCP stacks close() implies shutdown(fd,SHUT_WR) so a FIN is
> sent. In WINSOCK closesocket() does *not* imply shutdown(fd,SHUT_WR) so
> it behaves like an abortive close and an RST is sent, unless the
> programmer has also called shutdown(fd,SHUT_WR).
The above does not seem consistent with the behaviour documented in MSDN (the
link I posted a couple of messaged back). FWIW, a quick test (on a WinXP Pro
box) shows closesocket(), on a socket with default options, to initiate a
normal FIN/ACK sequence.
-- chris