Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / January 2006

Tip: Looking for answers? Try searching our database.

Socket & Disconnect

Thread view: 
bunka.munka@email.si - 10 Jan 2006 14:09 GMT
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 - 10 Jan 2006 14:26 GMT
> Is the NULL from readLine() 100% sign that socket was closed by remote
> peer

Yes.

/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 17:10 GMT
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/
Gordon Beaton - 10 Jan 2006 17:47 GMT
> 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
Paul Bilnoski - 10 Jan 2006 14:53 GMT
> Hi !
>
[quoted text clipped - 34 lines]
>
> 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


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.