Connection lost problem

[GoogleCodeExporter]

Sometimes when network is temporary down client looses connection.

Client should reconnect if connection is lost instead of quitting.

Possible difficulty here is that server does not cache the messages, so
messages received during connection lost will be lost.
This should be properly handled.

Original issue reported on code.google.com by Matvey.K...@gmail.com on 19 Oct 2009 at 10:42

[GoogleCodeExporter]

This might be easy to fix (except the fact that it affects reloading important
messages from server mechanism, but I've got some constructive ideas about 
that...)

Original comment by iskander...@gmail.com on 19 Oct 2009 at 11:03

[GoogleCodeExporter]

Original comment by Mandri...@gmail.com on 19 Oct 2009 at 11:26

[GoogleCodeExporter]

Some random ideas regarding this:

1. Just silently trying to reconnect is not enough, user should immediately 
know if
there IS a problem.
I like the way how it's implemented in TopCoder arena: there is a small 
"connection
status" panel on the top near the timer, showing either green or red light, 
depending
on connection status.

2. Even better is to detect and show the cause of the problem, most common 
causes:
- server not running (tcp connection fails)
- server host machine is unavailable (icmp ping fails)
- network not available (local physical link is down)

This will eliminate the need to launch far/cmd and typing ping/ipconfig/telnet 
commands.

3. Due to the nature of tcp, dead connections are not detected until the next 
packet
is sent. This is what happened to us yesterday, we thought everything worked, 
but
actually network went down some minutes ago.
Sending periodic application-level keepalives (ping-pong dummy packets) every 
5-10
seconds might help.

Original comment by zib...@gmail.com on 19 Oct 2009 at 3:59

[GoogleCodeExporter]

Pings are actually sent periodically...

Original comment by Matvey.K...@gmail.com on 19 Oct 2009 at 4:11

[GoogleCodeExporter]

Well, it didn't work quickly enough then, at least 2 times.
Current ping implementation relies on OS tcp stack timeouts, maybe it's better 
to
handle at application level. Since ping messages are already sent from both 
sides,
just add a check - if we haven't received any messages from other side for
(ping_interval + 1) seconds, consider connection dead and drop client (on 
server) or
force reconnect (on client).

Original comment by zib...@gmail.com on 19 Oct 2009 at 8:26

[GoogleCodeExporter]

Please think again about XMPP.

We can:
# create XEP (XMPP Extension);
# take some server (eg [http://www.igniterealtime.org/projects/openfire/ 
openfire] 
and create plugin for task management;
# take some client library (eg [www.igniterealtime.org/projects/smack/ smack]) 
and 
use it on client-side.

It should solve problems with network, also it can be useful for other features 
(eg 
rooms, described by zibada). Also XEP may be reused by someone else, not only 
for 
NEERC. But this requires time.

Original comment by Mandri...@gmail.com on 19 Oct 2009 at 8:47

[GoogleCodeExporter]

I agree that XMPP is the way to go in the long term (v2.0?=)), but it is not a 
silver
bullet anyway.

I've played a bit with ejabberd (have one running on my server now =)), and it 
has
same problems with unreliable connections for same reasons...
For example, if you send a message to user whose connection died recently (and 
his
server haven't discovered this yet), your message will be lost without you even
knowing about it (!). This could be solved with message receipts (XEP-0184), 
yet it
has to be supported by both clients to work.

There is another XEP (XEP-0199), which implements app-level ping mechanism 
similar to
what I described above to detect network problems quicker.
ejabberd has only recently added support for it, don't know about openfire 
though.

I doubt that correctly implementing all that stuff is easier than patching 
existing
code...

Original comment by zib...@gmail.com on 19 Oct 2009 at 9:24

[GoogleCodeExporter]

Actually we don't need to create new XEP for task management, because it's 
already 
exists :) (See http://xmpp.org/extensions/xep-0004.html)

Also please take a look at class XmppChatClient. To test it locally you can 
install 
openfire server (see http://code.google.com/p/neerc-soft/wiki/XMPP).

Original comment by Mandri...@gmail.com on 20 Oct 2009 at 3:33

[GoogleCodeExporter]

Original comment by Mandri...@gmail.com on 21 Oct 2009 at 10:04

• Changed state: Fixed