How can you tell if a socket is closed?

Discussion in 'Java' started by Dave Rathnow, Jun 2, 2004.

  1. Dave Rathnow

    Dave Rathnow Guest

    Normally I would hang a thread on socket.getInputStream().read()
    and wait for a -1 to come back but I've had to use a different
    approach. My thread can't block so it is calling
    socket.getInputStream().available() to see if anything is waiting and
    only then will it read.

    while (true) {
    if (socket.getInputStream().avilable() > 0)
    ...read some chars...
    }

    My problem is I can't tell when the socket is closed by the remote
    end. Socket.isClose() always returns false so it's no help. Same with
    isConnected(). available() always return 0.

    Can anyone tell me the trick?

    Thanks,
    Dave.
    Dave Rathnow, Jun 2, 2004
    #1
    1. Advertising

  2. On Wed, 02 Jun 2004 04:10:03 GMT, Dave Rathnow wrote:
    > My thread can't block so it is calling
    > socket.getInputStream().available() to see if anything is waiting
    > and only then will it read.
    >
    > while (true) {
    > if (socket.getInputStream().avilable() > 0)
    > ...read some chars...
    > }
    >
    > My problem is I can't tell when the socket is closed by the remote
    > end. Socket.isClose() always returns false so it's no help. Same
    > with isConnected(). available() always return 0.


    Unfortunately isClosed() and isConnected() don't tell you the status
    of the underlying connection, they tell you the status of the Socket
    object itself. As such they really only tell you whether close() or
    connect() has been invoked.

    The only way to tell is to (attempt to) read or write something. That
    is the nature of the underlying TCP stream.

    If that's a problem, why can't your thread block, or why can't you
    start an additional thread that *can* block? It could also be argued
    that whether the socket is closed or not is (usually) uninteresting
    until you actually need to read or write.

    Realize too that relying on available() wastes most of your CPU while
    you spin. Additionally it prevents you from detecting EOF since
    available() will return 0 then and you won't read.

    A better solution is Selector.select() in java.nio, which is quite
    similar to using select() in the standard socket API and lets you
    handle IO from several sources in the same thread. The variants
    select(timeout) and selectNow() let you do so without blocking.

    /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, Jun 2, 2004
    #2
    1. Advertising

  3. Dave Rathnow

    Leon Lambert Guest

    I have resorted to a dummy read so that an exception is thrown when the
    connection is broken.

    // dummy read on raw input to force error if connection broke
    // this doesn't actually ready anything but does throw connection broken
    exception
    socket.getInputStream().read(tempBuffer,0,0);
    for (;socket.available() >= bytesToRead;){
    }

    Hope this helps
    Leon Lambert

    Dave Rathnow wrote:
    > Normally I would hang a thread on socket.getInputStream().read()
    > and wait for a -1 to come back but I've had to use a different
    > approach. My thread can't block so it is calling
    > socket.getInputStream().available() to see if anything is waiting and
    > only then will it read.
    >
    > while (true) {
    > if (socket.getInputStream().avilable() > 0)
    > ...read some chars...
    > }
    >
    > My problem is I can't tell when the socket is closed by the remote
    > end. Socket.isClose() always returns false so it's no help. Same with
    > isConnected(). available() always return 0.
    >
    > Can anyone tell me the trick?
    >
    > Thanks,
    > Dave.
    >
    >
    Leon Lambert, Jun 2, 2004
    #3
  4. Dave Rathnow

    Roedy Green Guest

    On Wed, 02 Jun 2004 04:10:03 GMT, "Dave Rathnow" <>
    wrote or quoted :

    >Normally I would hang a thread on socket.getInputStream().read()
    >and wait for a -1 to come back but I've had to use a different
    >approach. My thread can't block so it is calling
    >socket.getInputStream().available() to see if anything is waiting and
    >only then will it read.


    What I have done in two of my big traffic apps is send a dummy
    heartbeat packet every N seconds in both directions if there has been
    no other traffic. This keeps the channel open and avoids reads timing
    out. You find out within N seconds if something has gone awry and
    attempt to open a new socket.

    There may be some lower level way of accomplishing the same thing with
    a dummy heartbeat TCP/IP probe of 0 bytes. In any case, this
    application level packet is something very explicit to deal with and I
    can easily tell if it is working.

    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
    Roedy Green, Jun 2, 2004
    #4
    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. Miguel Dias Moura
    Replies:
    2
    Views:
    333
    Martin
    Jun 22, 2004
  2. yogesh
    Replies:
    1
    Views:
    359
    Victor Bazarov
    Mar 14, 2007
  3. billiejoex
    Replies:
    6
    Views:
    1,968
    Roy Smith
    Jul 27, 2007
  4. Matt Kruse
    Replies:
    5
    Views:
    296
    Richard Cornford
    Sep 9, 2003
  5. harry

    Tell when popup has been closed?

    harry, May 4, 2004, in forum: Javascript
    Replies:
    2
    Views:
    74
    Guest
    Sep 4, 2004
Loading...

Share This Page