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" <[EMAIL PROTECTED]>
To: <[email protected]>
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 <[EMAIL PROTECTED]> 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
