BEEM - Android XMPP

Hi Eugene,
It seems your crash is due to another bug. Could you disable the Auto-away options and try again ?

Frédéric Barthéléry wrote:

Hi Eugene,
It seems your crash is due to another bug. Could you disable the Auto-away options and try again ?

It still crashes with auto-away turned off; I will produce new log and trace when I am near the right workstation.

For some reason, the .apk from comment #9 starts installing, and then says "Application not installed".

My self-build version from a week ago crashed only once or twice. But it never reconnects, and I end up with application that is running and "thinks" that it is connected but in fact it is not.

I will try to collect and upload more debug information these days.

Eugene, I think you have to uninstall your version before (using adb uninstall for example) and then install the new package because of signature mismatch..

Installed .apk from comment #9.

Turn off wifi so the phone switches to mobile data: beem shows that it is online, and the peer sees the user online, but no messages pass in either direction. Stays this way 20 minutes.

Turn Wifi back on. Bunch of messages that where typed on the phone before arrive at the peer, no messages typed by the peer arrive at the phone.

In 10-20 seconds, a couple I/O error messages on the phone, and then the app crashes with "stopped unexpectedly" message.

Hi,
I am working on a better implementation of the reconnection.
I will probably give you a patch and apk later today.

jer mar wrote:

For the record, I trigger the deconnexion by switching 3G to 2g.

Just got an idea. It may be that my and your symptoms are different because when you switch from 3g to 2g, the network gives you the same IP address. In my case, address of the device changes. When the IP address stays the same, the same TCP session stays functional after reconnection.

BTW I tried to reproduce the problem under emulator but found that (1) it does not provide emulated WiFi, and (2) even when I turn off "mobile network" it does not break IP connectivity to the virtual environment, and beem stays connected and functional.

Maybe the latter is the root of the problem. Maybe beem should shutdown the TCP connection when it receives android disconnection notification, no matter what?

I don't think so, I had it working correctly when switching for wifi to mobile network. I also ran into beem crashes comming from unhandled exceptions in the reconnection manager.
I had a look into the CM code and I think that relying on it is not the good solution as it is not aware of the cause of the disconnection and of the availability of a connectivity mean (switching to airplane mode results to perpetual reconnection attempts) ; the reconnection process should be handled by beem service itself.
Frédéric is refactoring the implementation so it should result to a stronger reconnection process.
Wait and see :)

Jerome M. wrote:

I don't think so, I had it working correctly when switching for wifi to mobile network. I also ran into beem crashes comming from unhandled exceptions in the reconnection manager.
I had a look into the CM code and I think that relying on it is not the good solution as it is not aware of the cause of the disconnection and of the availability of a connectivity mean (switching to airplane mode results to perpetual reconnection attempts) ; the reconnection process should be handled by beem service itself.
Frédéric is refactoring the implementation so it should result to a stronger reconnection process.
Wait and see :)

It is exactly my conclusion :)

Frédéric Barthéléry wrote:

This should be much better.

It is indeed. It does reconnect me now. I will be running it full-time and report if I see troubles.

BTW,
HW: HTC Desire
SW: 1.21.405.2 rooted by modaco (because I need WPA/LEAP and custom CA certs)

After a few days' run of the apk from comment #18:

- It successfully reconnects more often than not.
- It still don't keep me connected even for one whole day.

I've seen "terminated unexpectedly" message, I've found the app not running after a while, I've found it presumably active but with contact list empty and seen "offline" from outside.

I think that at least once I saw "terminated unexpectedly" when I was in the part of the building where both wifi and mobile connectivity are intermittent.

I have no logs because it always happened when I was out of the workstation; I will try to reproduce it when connected to adb, and if I succeed I'll post the logs.

Eugene Crosser wrote:

I had two scenarios with the package from comment #18:

For first, I have no log. It looked like this: at some moment, I got this message: "Sorry! Activity Beem-Chat (in application Beem) is not responding" with selection "Force Close" or "Wait". I selected "Force Close", after that the window with contact list had not entries, but there was "Disconnect" button in the menu.

I think it is an unrelated issue. Anyway, we have to find a good way to deal with ANR issues like this one.

Eugene Crosser wrote:

Second scenario was very simple, and I have log for it. I freshly installed the package from comment #18, created account ("test@average.org"), and got online with wifi and mobile available. Things where all right, I exchanged messages with the contact on a desktop ("crosser@average.org"). Then I turned off wifi in the settings. From the point of view from the desktop, test@average.org did not go offline even for a second, and Beem on android did not show signs of reconnecting. The messages typed on any side did not reach the peer. This continued for no less then 10 minutes. I have log attached for this case.

I don't know why but asmack did not detect the disconnection. There is no "connectionClosedOnError" which trigger the reconnection process.

From several days of running the app and looking at what is going on, it seems that the most often problem is that the app does not notice that the current connection is no longer active. The app still shows "Active" status but of course nothing is transferred, and the server eventually (after long time - hours maybe) realizes that the user is not connected.

I thought that maybe it would make sense to implement some sort of heartbeat check, and if the app cannot get response from the server for e.g. 10 minutes initiate reconnection? Just a thought...

No logs because it was all on the go. Incidentally, do you know if it is possible to write the log onto the SD card for later retrieval? That would help debug such cases as this one.

Eugene Crosser wrote:

From several days of running the app and looking at what is going on, it seems that the most often problem is that the app does not notice that the current connection is no longer active. The app still shows "Active" status but of course nothing is transferred, and the server eventually (after long time - hours maybe) realizes that the user is not connected.

Maybe a solution could be forcing the wifi policy to "AlwaysOn" when the phone went to idle state ? Maybe as an option in settings ?

I thought that maybe it would make sense to implement some sort of heartbeat check, and if the app cannot get response from the server for e.g. 10 minutes initiate reconnection? Just a thought...

I think for TCP connections the best method is to use the standard TCP keep alive.

No logs because it was all on the go. Incidentally, do you know if it is possible to write the log onto the SD card for later retrieval? That would help debug such cases as this one.

If on your phone you have a terminal emulator, you can use : logcat > /sdcard/logfile.txt

cf : http://wiki.cyanogenmod.com/index.php?title=Logcat

Nikita Kozlov wrote:

From several days of running the app and looking at what is going on, it seems that the most often problem is that the app does not notice that the current connection is no longer active.

Maybe a solution could be forcing the wifi policy to "AlwaysOn" when the phone went to idle state ? Maybe as an option in settings ?

I have WiFi "always on" because I also run a SIP client, but it is obviously not a "solution" because it does not help when you move between areas with WiFi coverage, mobile coverage and no coverage. Which is exactly when the problems arises.

I thought that maybe it would make sense to implement some sort of heartbeat check, and if the app cannot get response from the server for e.g. 10 minutes initiate reconnection? Just a thought...

I think for TCP connections the best method is to use the standard TCP keep alive.

It does not sound like a good option to me (from RFC1122):

         4.2.3.6  TCP Keep-Alives

            Implementors MAY include "keep-alives" in their TCP
            implementations, although this practice is not universally
            accepted.  If keep-alives are included, the application MUST
            be able to turn them on or off for each TCP connection, and
            they MUST default to off.

            Keep-alive packets MUST only be sent when no data or
            acknowledgement packets have been received for the
            connection within an interval.  This interval MUST be
            configurable and MUST default to _no less than two hours_.

If on your phone you have a terminal emulator, you can use : logcat > /sdcard/logfile.txt

Thanks, I'll try that and see if I can collect any useful information. (Although I suspect that it may be killed by the system when run in the background.)

While I am here, I have another typical failure scenario: there is a service icon in the top bar but when I launch the app it starts "Connecting". And never gets authenticated. But if I force stop the running app and then start it, it connects all right.

Eugene Crosser wrote:

Nikita Kozlov wrote:

From several days of running the app and looking at what is going on, it seems that the most often problem is that the app does not notice that the current connection is no longer active.

Maybe a solution could be forcing the wifi policy to "AlwaysOn" when the phone went to idle state ? Maybe as an option in settings ?

I have WiFi "always on" because I also run a SIP client, but it is obviously not a "solution" because it does not help when you move between areas with WiFi coverage, mobile coverage and no coverage. Which is exactly when the problems arises.

Yep, you are right, it won't help in that case. I was thinking about the case when the phone go in idle state and shutdown the wifi connection, which is happening to me more often.

I thought that maybe it would make sense to implement some sort of heartbeat check, and if the app cannot get response from the server for e.g. 10 minutes initiate reconnection? Just a thought...

I think for TCP connections the best method is to use the standard TCP keep alive.

It does not sound like a good option to me (from RFC1122):

[...]
(my emphasis)

I agree that implementing http://xmpp.org/extensions/xep-0199.html could be a better idea.
But just a comment about rfc1122, there was something like 100,000 computer in 1989 (no nat, no private network, classful ips ...). Let's agree that there are some better sources for today's protocols behavior ;-).

If on your phone you have a terminal emulator, you can use : logcat > /sdcard/logfile.txt

Thanks, I'll try that and see if I can collect any useful information. (Although I suspect that it may be killed by the system when run in the background.)

While I am here, I have another typical failure scenario: there is a service icon in the top bar but when I launch the app it starts "Connecting". And never gets authenticated. But if I force stop the running app and then start it, it connects all right.

In that case, you have switched from a wifi connection to a 3g connection (or vice versa) ? It's maybe because Smack is trying to use a wrong network interface or socket for it reconnection ?

Silly question perhaps, but can anything be learned from what yaxim does? When I ran it, it generally seemed to stay connected reliably. I thought that it too uses asmack, but I'm not sure.

Then again, yaxim has its own bugs that beem doesn't seem to--namely, it produces half a dozen notifications for each message. So maybe there are some differences of which I'm not aware.

Nolan Darilek wrote:

Silly question perhaps, but can anything be learned from what yaxim does? When I ran it, it generally seemed to stay connected reliably. I thought that it too uses asmack, but I'm not sure.

Not for me. I tried yaxim, and in a while (after a few changes of connectivity) I find myself with "Connection closed" displayed in the app and no attempts to reconnect.

I'm not sure how far you've gotten on this problem, but keeping Beem connected and having it automatically reconnect is actually not that difficult at all. I think the real problem is not losing messages when you're disconnected. Android was built with the mobile network model in mind. This being said it expects to have times where the connection is gone. When the connection is gone any messages sent are disregarded.

If smack has a connection on error event AFTER you've already successfully connected once than just reconnect after. When reconnecting make sure the phone has network connectivity and if it doesn't when connectivity is reinstated just reconnect. Keeping connection is as simple as XEP-0199 Ping. Monitor incoming data from the server, after X time send a ping, if the ping went through the incoming data monitor will be updated, if it doesn't ping again, after X time realize the connection is dead. There is more but you get the overall idea.

Anyone have any idea how we can handle not losing messages in the time where you lose service? Even if its just for 30 seconds and the connection comes back and you never get disconnected, that message is lost. You can't really verify that the message went to the server either as XMPP doesn't have any kind of transactions unlike IMPS.

-Tony

Detecting lost messages should be possible if both parties support XEP-0198 (Stream Management) which includes stanza acknowledgements.

I am using the up-to-date version from the android market (Google Play Store) [0.1.7] and am having the "beem goes offline after switching from wifi to 3g" problems. Since this feature request hasn't been updated since a long time I wanted to ask if the version I am using is already having the reconnection features but is somehow buggy or if I need to get another version from somewhere to be able to stay online while moving? Thanks.