Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!usenet.ukfsn.org!not-for-mail From: Martin Gregorie Newsgroups: comp.lang.java.programmer Subject: Re: detecting Socket disconnect Date: Wed, 17 Oct 2012 21:14:30 +0000 (UTC) Organization: UK Free Software Network Lines: 44 Message-ID: References: NNTP-Posting-Host: 84.45.235.129 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: localhost.localdomain 1350508470 28291 84.45.235.129 (17 Oct 2012 21:14:30 GMT) X-Complaints-To: usenet@localhost.localdomain NNTP-Posting-Date: Wed, 17 Oct 2012 21:14:30 +0000 (UTC) User-Agent: Pan/0.139 (Sexual Chocolate; GIT bf56508 git://git.gnome.org/pan2) Xref: csiph.com comp.lang.java.programmer: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 |