Yep, I reckon it's far from ideal. :-) Thanks for your insights!
Sent from my iPhone On 14 Oct 2010, at 06:19, Christopher Popp <[email protected]> wrote: > To determine disconnects within the second timeframe, that means you'd have > to > configure TCP keep-alives to be occurring nearly once a second. Since the > keep-alives may be bi-directional, assuming one per second, you'd be sending > about 2 * 54 bytes * 60 * 60 * 24 * 30 = 267 MB of data a month per > connection. > I hope you don't have too many clients, and that the clients ("mobile > device") > don't have bandwidth limited data plans. ;-) > > I've also read a bit that cellular carriers can sometimes decide to drop TCP > level keepalives. So, with a TCP timeout window in the second range, > connections may end up being more flakey than they really are. The cellular > carriers dropping TCP keepalives is one of the reasons we use application > level > keepalives (in addition to being able to configure keepalives on a per > connection basis). > > Chris > > > > ________________________________ > From: Zigor Salvador <[email protected]> > To: "[email protected]" <[email protected]> > Sent: Wed, October 13, 2010 1:49:18 AM > Subject: Re: almost immediate detection of disconnected client > > Let me resurrect this old thread to point to this URL: > http://www.gnugk.org/keepalive.html > > I managed to change the keepalive timer of my system so that I can detect > (IOException) the disconnection of, say, a mobile device within seconds of > its > disconnection. > > It's far from ideal, since this configuration affects all of the system, but > this way you don't have to implement a heartbeat protocol to detect "almost > immediate" disconnection. > > Zigor. > > On 7 Jul 2010, at 16:55, Alexander Christian wrote: > >> >> Hi, >> >> >> On Wed, 07 Jul 2010 14:16:25 +0200, Emmanuel Lecharny >> <[email protected]> >> wrote: >>> There is no way to detect a connection failure. The connection is opened >> >>> or closed, but you will know only after having successfully sent >>> something to the client. >> >> What about TCP KeepAlive? That IS checking the connection automatically. >> The only problem with this is: >> You don't know WHEN the OS will send a keep-alive-message to check the >> connection. It can be within seconds (unlikely), several minutes (more >> likely) or even hours ... (or maybe never?) >> It is possible to change the keep-alive interval, but this then counts for >> all socket connections the OS manages ... :-( >> >> A maybe useful hint: >> >> http://mindprod.com/jgloss/socket.html#DISCONNECT >> >> I don't use transactions. But I also wanted to know asap when the >> connection dies. >> >> So I created my own keepl-alive check: >> >> * As long as client and server and sending data to each other, the check >> happens when sending this data. If sending fails, the connection is broken >> * If client and server fall into IDLE (mina's session idle thing), then my >> communicationlayer on top of MINA sends ping-pong packages: If a pong has >> not been received xx sec after a ping is sent, the connection is broken. >> >> For me this has the positive sideeffect, that a "blocking" remote >> (dealocked?!) is detected as well. >> >> br, >> Alex > >
