You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Fernando C. de Castro" <fe...@altriz.com.br> on 2006/09/16 03:54:27 UTC
detection of lost connection when it doesn't close "cleanly"
Hello,
I looked in the archive before posting this and couldn't find an answer, so please excuse me if it has already been commented.
I was wondering if there is a way to detect a lost connection when the other side doesn't close the connection "cleanly".
Actually the server I wrote with MINA takes connections from GPRS modules and eventually sends messages to some of them. The matter is that sometimes the GPRS modules face some network problem and lose their IP session. When that happens, MINA (or the Operating System, for that matter) takes a long time (many minutes) to realize the connection is gone.
I am aware that there are means to adjust this delay within the OS, but I was expecting MINA to check that for me. If MINA sends a string of bytes for which the TCP/IP stack never got an ACK, I think MINA was supposed to know it.
Of course I could implement some kind of protocol to check for active connections: the GPRS modules could periodically send some data, and sessionIdle() would point out the 'mute' peers and then those sessions could be closed. But that isn't very much efficient, and also the GPRS is charged by traffic and this approach would result in a high fixed cost for the system.
I was hoping MINA could confirm that all bytes scheduled to be sent for a certain session were actually received by the other party; if some bytes remain there after a Timeout, then some event should be triggered.
Is there any easy way to achieve this, and I'm still not able to see?
Thanks in advance,
Fernando
Re: detection of lost connection when it doesn't close "cleanly"
Posted by Vinod Panicker <vi...@gmail.com>.
On 9/16/06, Fernando C. de Castro <fe...@altriz.com.br> wrote:
> Hello,
>
> I looked in the archive before posting this and couldn't find an answer, so please excuse me if it has already been commented.
>
> I was wondering if there is a way to detect a lost connection when the other side doesn't close the connection "cleanly".
<snip/>
Unfortunately, if you want to know of this asap, then you will have to
implement your own solution for checking if the session is alive. I've
also had notorious experiences with GPRS gateways (they don't seem to
bother with TCP/IP semantics) and have ended up with application
level pinging.
AFA MINA is concerned, it should not deal itself with checking for
such things, since it might possibly lead to breaking the application
protocol.
Regards,
Vinod.
Re: detection of lost connection when it doesn't close "cleanly"
Posted by Mike Grundvig <mi...@electrotank.com>.
Another option (one that I've had to use before) is to simply set an idle
timeout on inbound data. This is very simple and works great. MINA supports
it with:
ioSession.setIdleTime(IdleStatus.READER_IDLE, timeInSeconds);
This way, the client can simply send a ping and you detect it on the server
(but do nothing with it). That's enough for the client connection to stay
alive.
Michael Grundvig
Electrotank, Inc
http://www.electrotank.com
----- Original Message -----
From: "Trustin Lee" <tr...@gmail.com>
To: <mi...@directory.apache.org>
Sent: Friday, September 15, 2006 11:50 PM
Subject: Re: detection of lost connection when it doesn't close "cleanly"
> Hi Fernando,
>
> On 9/16/06, Fernando C. de Castro <fe...@altriz.com.br> wrote:
>>
>> Hello,
>>
>> I looked in the archive before posting this and couldn't find an
>> answer, so please excuse me if it has already been commented.
>>
>> I was wondering if there is a way to detect a lost connection when the
>> other side doesn't close the connection "cleanly".
>>
>> Actually the server I wrote with MINA takes connections from GPRS
>> modules and eventually sends messages to some of them. The matter is that
>> sometimes the GPRS modules face some network problem and lose their IP
>> session. When that happens, MINA (or the Operating System, for that
>> matter)
>> takes a long time (many minutes) to realize the connection is gone.
>>
>> I am aware that there are means to adjust this delay within the OS,
>> but
>> I was expecting MINA to check that for me. If MINA sends a string of
>> bytes
>> for which the TCP/IP stack never got an ACK, I think MINA was supposed to
>> know it.
>
>
> You can set SO_KEEPALIVE flag to true to enable the internal TCP/IP
> keepalive packet exchange between peers, but it highly depends on the O/S
> implementation. Some says the keepalive exchange interval is 2 hrs. So I
> think it is not that efficient. The best way is to implement the high
> level
> keep alive mechanism as you mentioned.
>
> Of course I could implement some kind of protocol to check for active
>> connections: the GPRS modules could periodically send some data, and
>> sessionIdle() would point out the 'mute' peers and then those sessions
>> could
>> be closed. But that isn't very much efficient, and also the GPRS is
>> charged
>> by traffic and this approach would result in a high fixed cost for the
>> system.
>
>
> If you cannot use the high level keep alive mechanism, then I cannot think
> of any better way to detect unclean disconnections excepto for
> SO_KEEPALIVE. But this keep alive will also take some cost.
>
> I was hoping MINA could confirm that all bytes scheduled to be sent for
> a
>> certain session were actually received by the other party; if some bytes
>> remain there after a Timeout, then some event should be triggered.
>
>
> That's what TCP/IP is for, so MINA doesn't need to guarentee anything like
> that. We can implement such mechanism on top of TCP/IP, but I think this
> is
> of dubious value.
>
> My suggestion for now is to use SO_KEEPALIVE, then at least the connection
> will be cleaned up somehow someday. (probably in 2 hours? You can modify
> this setting if the O/S provides the setting or the source code.
>
> HTH,
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP key fingerprints:
> * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
> * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
>
Re: detection of lost connection when it doesn't close "cleanly"
Posted by Trustin Lee <tr...@gmail.com>.
Hi Fernando,
On 9/16/06, Fernando C. de Castro <fe...@altriz.com.br> wrote:
>
> Hello,
>
> I looked in the archive before posting this and couldn't find an
> answer, so please excuse me if it has already been commented.
>
> I was wondering if there is a way to detect a lost connection when the
> other side doesn't close the connection "cleanly".
>
> Actually the server I wrote with MINA takes connections from GPRS
> modules and eventually sends messages to some of them. The matter is that
> sometimes the GPRS modules face some network problem and lose their IP
> session. When that happens, MINA (or the Operating System, for that matter)
> takes a long time (many minutes) to realize the connection is gone.
>
> I am aware that there are means to adjust this delay within the OS, but
> I was expecting MINA to check that for me. If MINA sends a string of bytes
> for which the TCP/IP stack never got an ACK, I think MINA was supposed to
> know it.
You can set SO_KEEPALIVE flag to true to enable the internal TCP/IP
keepalive packet exchange between peers, but it highly depends on the O/S
implementation. Some says the keepalive exchange interval is 2 hrs. So I
think it is not that efficient. The best way is to implement the high level
keep alive mechanism as you mentioned.
Of course I could implement some kind of protocol to check for active
> connections: the GPRS modules could periodically send some data, and
> sessionIdle() would point out the 'mute' peers and then those sessions could
> be closed. But that isn't very much efficient, and also the GPRS is charged
> by traffic and this approach would result in a high fixed cost for the
> system.
If you cannot use the high level keep alive mechanism, then I cannot think
of any better way to detect unclean disconnections excepto for
SO_KEEPALIVE. But this keep alive will also take some cost.
I was hoping MINA could confirm that all bytes scheduled to be sent for a
> certain session were actually received by the other party; if some bytes
> remain there after a Timeout, then some event should be triggered.
That's what TCP/IP is for, so MINA doesn't need to guarentee anything like
that. We can implement such mechanism on top of TCP/IP, but I think this is
of dubious value.
My suggestion for now is to use SO_KEEPALIVE, then at least the connection
will be cleaned up somehow someday. (probably in 2 hours? You can modify
this setting if the O/S provides the setting or the source code.
HTH,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6