Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > How can you tell if a socket is closed?

Reply
Thread Tools

How can you tell if a socket is closed?

 
 
Dave Rathnow
Guest
Posts: n/a
 
      06-02-2004
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.


 
Reply With Quote
 
 
 
 
Gordon Beaton
Guest
Posts: n/a
 
      06-02-2004
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
 
Reply With Quote
 
 
 
 
Leon Lambert
Guest
Posts: n/a
 
      06-02-2004
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.
>
>

 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      06-02-2004
On Wed, 02 Jun 2004 04:10:03 GMT, "Dave Rathnow" <(E-Mail Removed)>
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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: socket.unbind or socket.unlisten? - socket.error: (48, 'Addressalready in use') Steve Holden Python 1 02-03-2009 06:20 AM
Re: socket.unbind or socket.unlisten? - socket.error: (48, 'Addressalready in use') Steve Holden Python 0 02-01-2009 12:45 PM
Re: socket.unbind or socket.unlisten? - socket.error: (48, 'Addressalready in use') Laszlo Nagy Python 0 02-01-2009 07:37 AM
socket.unbind or socket.unlisten? - socket.error: (48, 'Addressalready in use') Laszlo Nagy Python 1 01-27-2009 05:05 PM
Re: socket.unbind or socket.unlisten? - socket.error: (48,'Address already in use') Jean-Paul Calderone Python 0 01-27-2009 01:41 PM



Advertisments