Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #19412 > unrolled thread

detecting Socket disconnect

Back to article view | Back to comp.lang.java.programmer

Contents

  detecting Socket disconnect bob smith <bob@coolfone.comze.com> - 2012-10-17 13:12 -0700
    Re: detecting Socket disconnect Arne Vajhoej <arne@vajhoej.dk> - 2012-10-17 16:45 -0400
    Re: detecting Socket disconnect Lew <lewbloch@gmail.com> - 2012-10-17 13:47 -0700
      Re: detecting Socket disconnect Arne Vajhoej <arne@vajhoej.dk> - 2012-10-17 17:19 -0400
    Re: detecting Socket disconnect Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-10-17 13:59 -0700
      Re: detecting Socket disconnect Arne Vajhoej <arne@vajhoej.dk> - 2012-10-17 17:24 -0400
        Re: detecting Socket disconnect Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-10-17 14:42 -0700
      Re: detecting Socket disconnect Steven Simpson <ss@domain.invalid> - 2012-10-18 09:31 +0100
        Re: detecting Socket disconnect Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-10-18 07:09 -0700
    Re: detecting Socket disconnect Martin Gregorie <martin@address-in-sig.invalid> - 2012-10-17 21:14 +0000
    Re: detecting Socket disconnect Roedy Green <see_website@mindprod.com.invalid> - 2012-10-17 15:52 -0700

#19412 — detecting Socket disconnect

I have a java.net.Socket that I only write to, and I can't figure out how to tell if it's disconnected.

I call socket.isConnected(), but it still returns true after I broke the TCP connection.  I had telnetted in thru Windows telnet and closed the window.

Anyone know how to detect the disconnect?

[toc] | [next] | [standalone]

#19415

On 10/17/2012 4:12 PM, bob smith wrote:
> I have a java.net.Socket that I only write to, and I can't figure out how to tell if it's disconnected.
>
> I call socket.isConnected(), but it still returns true after I broke the TCP connection.  I had telnetted in thru Windows telnet and closed the window.
>
> Anyone know how to detect the disconnect?

I believe the most reliable method is to implement a protocol that
contains frequent keep alive messages and use missing such to detect
a network failure. Otherwise you can try send and wait for timeout.

Arne

[toc] | [prev] | [next] | [standalone]

#19416

bob smith wrote:
> I have a java.net.Socket that I only write to, and I can't figure out how to tell if it's disconnected.
> 
> I call socket.isConnected(), but it still returns true after I broke the TCP connection.  I had telnetted in thru Windows telnet and closed the window.

Closed what window?

How do you know that closing "the window" broke the connection?

What reads from the other end of the connection?

> Anyone know how to detect the disconnect?

http://docs.oracle.com/javase/7/docs/api/java/net/Socket.html#isConnected()
"Returns: true if the socket was successfuly connected to a server"

Your socket was connected, so according to the docs you should get 'true'.

What does 
http://docs.oracle.com/javase/7/docs/api/java/net/Socket.html#isClosed()
tell you?

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#19423

On 10/17/2012 4:47 PM, Lew wrote:
> bob smith wrote:
>> I have a java.net.Socket that I only write to, and I can't figure out how to tell if it's disconnected.
>>
>> I call socket.isConnected(), but it still returns true after I broke the TCP connection.  I had telnetted in thru Windows telnet and closed the window.
>
> Closed what window?

The window of the program he mentioned (Windows telnet) seems
a good guess.

The window of his email program would not make much sense.

> How do you know that closing "the window" broke the connection?

Broke is a bit fuzzy term.

But obviously a closed program (Windows telnet terminated when the
window is closed) can not receive from the connection.

> What reads from the other end of the connection?

Whatever uses a java.net.Socket - I would expect a Java program.

>> Anyone know how to detect the disconnect?
>
> http://docs.oracle.com/javase/7/docs/api/java/net/Socket.html#isConnected()
> "Returns: true if the socket was successfuly connected to a server"
>
> Your socket was connected, so according to the docs you should get 'true'.

Unfortunately it will only tell status in the apps own end.

Arne

[toc] | [prev] | [next] | [standalone]

#19419

On Wed, 17 Oct 2012 13:12:13 -0700 (PDT), bob smith wrote:

> I have a java.net.Socket that I only write to, and I can't figure out how to tell if it's disconnected.
> 
> I call socket.isConnected(), but it still returns true after I broke the TCP connection.  I had telnetted in thru Windows telnet and closed the window.
> 
> Anyone know how to detect the disconnect?

Not enough information in your question.  What kind of "disconnected" are
you asking about?  Why do you need to detect it?

The normal way to detect a disconnect is to read from the socket and get a
return value of 0 bytes for the count of bytes.  This tells you that the
remote end is done sending (even if it never sent anything) and is ready to
close the connection.

To detect this, issue a read on the socket.  How best to do this depends on
your exact implementation, but in Java since allocating new threads for
socket i/o is typical, I would suggest doing just that: create a thread
dedicated to a synchronous read on the socket, and when the read returns
(presumably with a byte count of 0, since you say the remote endpoint never
sends), you know they are ready to disconnect.

If the connection was reset somehow, such as because of a network failure,
then you should get an error (exception) when you attempt to send.  There's
usually really no point in trying to detect the failure _before_ you would
normally send, because the failure could be something in between the end
points that recovers.  Explicitly attempting to detect the failure can and
will create failures that otherwise would not have been a problem.

I would not bother with the "isConnected()" method.  It won't tell you
anything you couldn't already find out through more conventional means.
The socket will remain connected until a failure or graceful closure
occurs, and both of those are readily detectable as I describe above, when
they occur.  So rather than polling the socket with isConnected() just
handle the events on the socket normally.

Pete

[toc] | [prev] | [next] | [standalone]

#19424

On 10/17/2012 4:59 PM, Peter Duniho wrote:
> On Wed, 17 Oct 2012 13:12:13 -0700 (PDT), bob smith wrote:
>
>> I have a java.net.Socket that I only write to, and I can't figure out how to tell if it's disconnected.
>>
>> I call socket.isConnected(), but it still returns true after I broke the TCP connection.  I had telnetted in thru Windows telnet and closed the window.
>>
>> Anyone know how to detect the disconnect?
>
> Not enough information in your question.  What kind of "disconnected" are
> you asking about?

He explicit said that the program in the other end was terminated.

> The normal way to detect a disconnect is to read from the socket and get a
> return value of 0 bytes for the count of bytes.  This tells you that the
> remote end is done sending (even if it never sent anything) and is ready to
> close the connection.

Is that fail fast and reliable?

> If the connection was reset somehow, such as because of a network failure,
> then you should get an error (exception) when you attempt to send.  There's
> usually really no point in trying to detect the failure _before_ you would
> normally send, because the failure could be something in between the end
> points that recovers.  Explicitly attempting to detect the failure can and
> will create failures that otherwise would not have been a problem.

That is typical what is done.

Even though I suspect that it may not always be fast.

Arne

[toc] | [prev] | [next] | [standalone]

#19426

On Wed, 17 Oct 2012 17:24:43 -0400, Arne Vajhoej wrote:

> On 10/17/2012 4:59 PM, Peter Duniho wrote:
>> On Wed, 17 Oct 2012 13:12:13 -0700 (PDT), bob smith wrote:
>>
>>> I have a java.net.Socket that I only write to, and I can't figure out how to tell if it's disconnected.
>>>
>>> I call socket.isConnected(), but it still returns true after I broke the TCP connection.  I had telnetted in thru Windows telnet and closed the window.
>>>
>>> Anyone know how to detect the disconnect?
>>
>> Not enough information in your question.  What kind of "disconnected" are
>> you asking about?
> 
> He explicit said that the program in the other end was terminated.

But that doesn't describe the form of disconnect he wants to detect.  It's
entirely possible that the "program in the other end" attempted a graceful
closure, and failing that (because his own code doesn't handle it), just
timed out and exited.

In that scenario, sure...he could just stick to detecting the forced reset.
But that'd be dumb.  He'd be getting a normal graceful closure that he
_could_ handle gracefully.  Ignoring that would make no sense.

Granted, his code still needs to be able to deal with exceptions.  But the
network operates more efficiently if he complies with the protocol's
conventions.

>> The normal way to detect a disconnect is to read from the socket and get a
>> return value of 0 bytes for the count of bytes.  This tells you that the
>> remote end is done sending (even if it never sent anything) and is ready to
>> close the connection.
> 
> Is that fail fast and reliable?

I don't understand the question.  It's not a failure at all.  It's fast and
reliable, but works only when both ends are cooperating and following the
normal TCP conventions.

>> If the connection was reset somehow, such as because of a network failure,
>> then you should get an error (exception) when you attempt to send.  There's
>> usually really no point in trying to detect the failure _before_ you would
>> normally send, because the failure could be something in between the end
>> points that recovers.  Explicitly attempting to detect the failure can and
>> will create failures that otherwise would not have been a problem.
> 
> That is typical what is done.

What is typical?  Just handling failures on a normal send?  Or adding extra
sends in your application protocol to force failures when they otherwise
would not happen?

> Even though I suspect that it may not always be fast.

Detecting a failure on send should IMHO be "fast enough".  At worst you'd
have the delay associated with the Nagel algorithm, then the latency for
the servers through which the message is routed to detect the connection
failure and report that back.  This is all in the ballpark of the normal
latencies one deals with in handling network i/o.

In any case, I don't see how anyone's going to get the error handling to
happen faster.  Using "keep-alive" (whether the TCP option or building it
into the application protocol) will detect the failure _sooner_ (though as
noted, will create failures when otherwise none would have happened).  But
the delay between attempting to send and detecting the failure is the same
in any case.  And said delay is short enough to not be a user-interaction
issue.

Closing the connection gracefully provides the best performance though.  No
timeouts are needed, and of course the network stacks at both ends get to
close the socket immediately, rather than leaving it dangling to expire
some time later.  This is all better from an efficiency standpoint than
dealing with forced resets.

Pete

[toc] | [prev] | [next] | [standalone]

#19430

On 17/10/12 21:59, Peter Duniho wrote:
> On Wed, 17 Oct 2012 13:12:13 -0700 (PDT), bob smith wrote:
>> I have a java.net.Socket that I only write to, and I can't figure out how to tell if it's disconnected.
> The normal way to detect a disconnect is to read from the socket and get a
> return value of 0 bytes for the count of bytes.

This is the case in C, where functions like recv() use -1 to signal an 
error and 0 for EOF.  However, in Java, InputStream (such as you get 
from a Socket) returns -1 to signal EOF.

<http://docs.oracle.com/javase/7/docs/api/java/io/InputStream.html>


-- 
ss at comp dot lancs dot ac dot uk

[toc] | [prev] | [next] | [standalone]

#19431

On Thu, 18 Oct 2012 09:31:27 +0100, Steven Simpson wrote:

> On 17/10/12 21:59, Peter Duniho wrote:
>> On Wed, 17 Oct 2012 13:12:13 -0700 (PDT), bob smith wrote:
>>> I have a java.net.Socket that I only write to, and I can't figure out how to tell if it's disconnected.
>> The normal way to detect a disconnect is to read from the socket and get a
>> return value of 0 bytes for the count of bytes.
> 
> This is the case in C, where functions like recv() use -1 to signal an 
> error and 0 for EOF.  However, in Java, InputStream (such as you get 
> from a Socket) returns -1 to signal EOF.
> 
> <http://docs.oracle.com/javase/7/docs/api/java/io/InputStream.html>

Right. It's hard to keep track of all the different socket variations. :)

Anyway, the point is...the socket has a defined way to detect the end of
the stream, which occurs when the remote endpoint does a "send" shutdown.
It's better to rely on this than to just wait for the connection to be
forcefully reset.

[toc] | [prev] | [next] | [standalone]

#19422

On Wed, 17 Oct 2012 13:12:13 -0700, bob smith wrote:

> I have a java.net.Socket that I only write to, and I can't figure out
> how to tell if it's disconnected.
> 
> I call socket.isConnected(), but it still returns true after I broke the
> TCP connection.  I had telnetted in thru Windows telnet and closed the
> window.
> 
> Anyone know how to detect the disconnect?
>
The most you can do is enable S_KEEPALIVE by calling Socket.setKeepAlive
(). This causes the TCP/IP stack to send a periodic system message to 
check whether the connection is still there. However, this is fairly 
useless because the default keepalive frequency can be as slow as once 
every two hours (it says) and there's no Java method that can change that 
frequency. As a result TCP/IP doesn't notice a broken connection until 
you try to send a message over it. About the best you can do is arrange 
for the client to exchange an 'are you still there/yes I am' message pair 
with the server at intervals when the connection is idle.

This makes TCP/IP somewhat deficient for some tasks, e.g. running an ATM 
network since, unless each ATM polls the server fairly frequently its 
likely to say its in service until the punter sticks his card in and 
enters his PIN - that's when the first message is sent to the bank's 
server and so, without a fairly frequent 'Im alive, are you' poll, thats 
when the ATM discovers the line or server is dead and pisses off the 
punter by putting up its OUT OF ORDER display and giving his card back.

It explains why X.25, which instantly notices disconnects of endpoint 
failures and notified both endpoints of the failure, is/was so popular 
for ATM networks. Even the much older proprietary polled network 
protocols such as SNA and 3270 Bisync, will notice a network failure 
pretty much instantly: as soon as a poll goes unanswered the system knows 
something has broken, and these protocols polled their terminals several 
times a second.

HTH


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#19427

On Wed, 17 Oct 2012 13:12:13 -0700 (PDT), bob smith
<bob@coolfone.comze.com> wrote, quoted or indirectly quoted someone
who said :

>Anyone know how to detect the disconnect?

I wrestled with the problem and solved it with a custom protocol
sending packets back and forth.  

If there is no traffic, it sends a "heartbeat" packet every X seconds,
just to let the other end know it is alive. The receiver just ignores
them.  If a read times out, it presumes the worst and restarts the
socket.

TCP/IP is quite happy with no traffic for long periods of time, so it
is up to you if you want early notification.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
There are four possible ways to poke a card into a slot.
Nearly always, only one way works. To me that betrays a 
Fascist mentality, demanding customers conform to some 
arbitrary rule, and hassling them to discover the magic 
orientation. The polite way to do it is to design the reader 
slot so that all four ways work, or so that all the customer 
has to do is put the card in the vicinity of the reader. 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web