Socket & Disconnect

Discussion in 'Java' started by Guest, Jan 10, 2006.

  1. Guest

    Guest 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.
     
    Guest, Jan 10, 2006
    #1
    1. Advertising

  2. On Tue, 10 Jan 2006 15:09:05 +0100, <> wrote:
    > Is the NULL from readLine() 100% sign that socket was closed by remote
    > peer


    Yes.

    /gordon

    --
    [ 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
     
    Gordon Beaton, Jan 10, 2006
    #2
    1. Advertising

  3. wrote:
    > 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
     
    Paul Bilnoski, Jan 10, 2006
    #3
  4. Guest

    Guest

    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.


    http://www.geocities.com/opalpaweb/
     
    , Jan 10, 2006
    #4
  5. On 10 Jan 2006 09:10:59 -0800, wrote:
    > 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

    --
    [ 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
     
    Gordon Beaton, Jan 10, 2006
    #5
  6. Guest

    Guest

    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/
     
    , Jan 10, 2006
    #6
  7. Guest

    Oliver Wong Guest

    <> wrote in message
    news:...
    >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
     
    Oliver Wong, Jan 10, 2006
    #7
  8. Guest

    Chris Uppal Guest

    Gordon Beaton wrote:

    > "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
     
    Chris Uppal, Jan 11, 2006
    #8
  9. On Wed, 11 Jan 2006 11:17:42 -0000, Chris Uppal wrote:
    > 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

    --
    [ 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
     
    Gordon Beaton, Jan 11, 2006
    #9
  10. Guest

    EJP Guest

    Gordon Beaton wrote:
    > On Wed, 11 Jan 2006 11:17:42 -0000, Chris Uppal wrote:
    >
    >>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.


    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).
     
    EJP, Jan 14, 2006
    #10
  11. Guest

    Chris Uppal Guest

    EJP wrote:

    > 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
     
    Chris Uppal, Jan 14, 2006
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Bryan
    Replies:
    6
    Views:
    917
    Bryan
    Dec 20, 2006
  2. Laszlo Nagy
    Replies:
    1
    Views:
    5,112
    Mark Wooding
    Jan 27, 2009
  3. Jean-Paul Calderone
    Replies:
    0
    Views:
    1,031
    Jean-Paul Calderone
    Jan 27, 2009
  4. Jon Fi
    Replies:
    1
    Views:
    169
    hemant
    Oct 3, 2006
  5. bob smith

    detecting Socket disconnect

    bob smith, Oct 17, 2012, in forum: Java
    Replies:
    6
    Views:
    629
    Steven Simpson
    Oct 18, 2012
Loading...

Share This Page