Socket & Disconnect

[Guest]

Hi !

I would like to know, how to trap an event, that the remote peer has
closed the connection.

Here is a simple script which sends a line, and receives one.
Socket socket ;
OutputStream outputStream = null ;
BufferedReader inputStream = null;
try {
socket = new Socket("mypeer", 5555) ;
socket.setKeepAlive(true) ;
socket.setSoTimeout(5000) ;
outputStream = new PrintStream(socket.getOutputStream());
inputStream = new BufferedReader(new InputStreamReader
(socket.getInputStream()));
String s = new String("This is to be sent\n") ;
outputStream.write(s.getBytes()) ;
outputStream.flush() ;
String r ;
if ((r = inputStream.readLine()) == null) {
System.out.println("NOTHING READ") ;
} else {
System.out.println("This was read: " + r) ;
}
outputStream.flush() ;
outputStream.close() ;
inputStream.close() ;
socket.close() ;
} catch (Exception e) {
e.printStackTrace() ;
}

Is the NULL from readLine() 100% sign that socket was closed by remote
peer, or may be just lack of data remote did not send ?
Should I wait for stream write() and catch exception ?

Any help would be appreciated.

 

[Gordon Beaton]

Is the NULL from readLine() 100% sign that socket was closed by remote
peer

Yes.

/gordon

 

[Paul Bilnoski]

Hi !

I would like to know, how to trap an event, that the remote peer has
closed the connection.

Here is a simple script which sends a line, and receives one.
Socket socket ;
OutputStream outputStream = null ;
BufferedReader inputStream = null;
try {
socket = new Socket("mypeer", 5555) ;
socket.setKeepAlive(true) ;
socket.setSoTimeout(5000) ;
outputStream = new PrintStream(socket.getOutputStream());
inputStream = new BufferedReader(new InputStreamReader
(socket.getInputStream()));
String s = new String("This is to be sent\n") ;
outputStream.write(s.getBytes()) ;
outputStream.flush() ;
String r ;
if ((r = inputStream.readLine()) == null) {
System.out.println("NOTHING READ") ;
} else {
System.out.println("This was read: " + r) ;
}
outputStream.flush() ;
outputStream.close() ;
inputStream.close() ;
socket.close() ;
} catch (Exception e) {
e.printStackTrace() ;
}

Is the NULL from readLine() 100% sign that socket was closed by remote
peer, or may be just lack of data remote did not send ?
Should I wait for stream write() and catch exception ?

Any help would be appreciated.

I believe stream's read operations block until data is available, and
you'll know the client end of the socket was dropped through some kind
of SocketException.
--Paul

 

[opalpa]

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.

(e-mail address removed)
http://www.geocities.com/opalpaweb/

 

[Gordon Beaton]

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.

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

 

[opalpa]

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]

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/

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]

"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/e...tdown_linger_options_and_socket_closure_2.asp

-- chris

 

[Gordon Beaton]

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/e...tdown_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

 

[EJP]

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.

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]

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