Keep-alive connections

[geileszeuch]

First of all I don't have Google Services on my phone.

Since the new version is not keeping the app awake in the background, which is how it really should be, there are times when messages do not arrive/arrive delayed when Kontalk is in the background. When such a case happens all messages can be retrieved by manually opening the app. How to reproduce (seems not to work all the time):

1. Have a good connection to WiFi with Bobs phone.
2. Open Kontalk.
3. Open recent apps and swipe Kontalk away.
4. Put Bobs phone in standby.
5. Send message from another device to Bobs phone.

The battery life now is terrific and this shouldn't change. I assume Kontalk is not connecting anymore or something like that. Maybe ChatSecure is a good reference to solve this. Messages in Chatsecure always get delivered immediately and the app has zero battery impact.

[daniele-athome]

I don't know how ChatSecure works, but it keeps an always active connection to the server (by the way OTR needs just that), which does indeed drain your battery, I doubt it's zero impact.
An active TCP connection keeps the antenna powered, draining precious energy every second. It's a huge waste of energy, believe me.
Servers have a connection timeout detection mechanism, checked every minute or so using XMPP Ping (XEP-0199), to which the client has to reply, otherwise the server will kick it out. But that also drains energy. However, without a ping mechanism, the server would wait a long time before realizing the client has disconnected, leading to false user presence.
So Kontalk disconnects after the idle timeout configured in preferences, and reconnects after some time (also configurable). I need to investigate on power consumption when sending/receiving ping packets (which could be replaced by something else I guess, but it will always drain energy and require some data exchange).
I'm going to disable the ping mechanism on the beta server for the next few weeks. Let's see what happens. However, Kontalk will continue to disconnect after some time. In the meantime you could shorten the reconnection delay to the lower time possible (5 minutes) and raise the idle connection timeout to the longest time possible (5 minutes). Besides, I don't know if it's really a good move because the login process takes a lot of data transfer and settings those parameters like that could bring to more battery draining (it would be like turning off your car engine at every red traffic light, pretending to save fuel).

[geileszeuch]

I am aware of all of that.

Besides, I don't know if it's really a good move because the login process takes a lot of data transfer and settings those parameters like that could bring to more battery draining (it would be like turning off your car engine at every red traffic light, pretending to save fuel).

That is exactly the point which should be tested! Maybe keeping an active connection is less energy wasting than reconnecting that often, since reconnecting takes much more data to be transferred than simple ping mechanism.

However, Kontalk will continue to disconnect after some time. In the meantime you could shorten the reconnection delay to the lower time possible (5 minutes) and raise the idle connection timeout to the longest time possible (5 minutes).

I do already have configured those timeouts so that Kontalk is connected the maximal amount of time and those things I described in the first post still happen, which shouldn't be the case.

[daniele-athome]

Always-on connection was the policy we adopted in the first place, and many complained about extreme battery draining. It's very hard to not drain energy while a connection is alive.
That said, XMPP compression will save some bytes for the ping packets (it's not implemented server-side yet), but besides that I don't really know what else to do to save battery and guarantee instant message delivery at the same time.
I've restored the ping mechanism on beta - it was causing more problems than it prevented: ghost presences all over.

I will add an option "None" to the idle connection timeout (so Kontalk will never disconnect if the user decides so).