[jdev] XMPP on Android, Round #2

[Rene Treffer]

On 11/03/2010 01:06 AM, Stephen Pendleton wrote:
>
> -----Original Message-----
> From: jdev-bounces at jabber.org [mailto:jdev-bounces at jabber.org] On Behalf Of
> Rene Treffer
> Sent: Tuesday, November 02, 2010 6:33 PM
> To: Jabber/XMPP software development list
> Subject: Re: [jdev] XMPP on Android, Round #2
>
> On 11/02/2010 10:24 PM, Stephen Pendleton wrote:
>> -----Original Message-----
>> From: jdev-bounces at jabber.org [mailto:jdev-bounces at jabber.org] On Behalf
> Of
>> Rene Treffer
>> Sent: Tuesday, November 02, 2010 4:09 PM
>> To: jdev at jabber.org
>> Subject: Re: [jdev] XMPP on Android, Round #2
>>
>> On 11/01/2010 10:14 PM, Stephen Pendleton wrote:
>>> -----Original Message-----
>>> From: jdev-bounces at jabber.org [mailto:jdev-bounces at jabber.org] On Behalf
>> Of Yann Leboulanger
>>> Sent: Monday, November 01, 2010 4:27 PM
>>> To: jdev at jabber.org
>>> Subject: Re: [jdev] XMPP on Android, Round #2
>>>
>>>> Couldn't Stream managment help for that?
>>>> http://xmpp.org/extensions/xep-0198.html
>> 2. How do you get *less* pushes/pulls if stanzas cause push notifies. I
>> don't get that one, either.
>> 3. Semi-frequently is still better than for-nearly-every-stanza. You are
>> asking to keep the connection short lived? I don't expect the
>> stanza/reconnect ratio to improve due to that. And there is no stanza
>> reduction due to the system. I don't get how your suggestion is going to
>> improve the situation as you still wake the network and cpu at the same
>> rate.
> I think I am not being clear.
>
> Here is an example, you have your XMPP service running on your phone. It is
> in the background, in your pocket, etc. You aren't interested in all the
> <presence>, pubsub, PEP, etc stanzas. You are only interested in <message>
> stanzas so you can be notified when a message is waiting to be read. If you
> maintain a constant XMPP TCP connection you are getting tons of stanzas you
> aren't interested in. In addition you are going to have to partially wake
> lock the device in order to keep the TCP connection from getting torn down
> when the device CPU sleeps. This is going to kill your device and is frowned
> upon in the android world.

There is no wake lock for GSM/TCP. It simply doesn't exist. And you
*have* a TCP connection in your pocket, in the background, it's called
Cloud to Device. Wake Lock keeps your system in an awake state as if the
user would actually use it. Usefull e.g. for in-game animations. Useless
for network or general IO wait. It's usually held because you can't rely
e.g. on Thread.sleep, but you CAN reply on read() to terminate as soon
as there is data available. I've build everything to not rely on timing
but on events / wakeups caused by external sources.

TCP gets killed after weeks on old kernels and after days for new
kernels. Where did you get the assumption that TCP would get killed all
the time?

The second part, filtering, is SIFT, and the power saving is *unrelated*
to keeping a second connection open.

BTW, I am using the time tick intent, thus doing keepalive when every
other app does networking, too. This is why I never show up in the
battery list.

> In an alternate scenario you could use the Google push service to be
> notified when a <message> stanza is available to be read on the server. Only
> then would you reconnect to the XMPP server and retrieve the <message>
> stanza. Actually I misread the XEP-0198 though, it seems that it will
> retransmit all the "missed" stanzas. What we would need is for it to only
> retransmit the stanzas of interest, like SIFT. So maybe a combination of the
> stream resume feature + SIFT would work here.
>
> I'm not sure about you, but 95% of the time my phone is on I am not
> receiving any XMPP messages that require my attention. I don't want to
> maintain an active TCP connection 100% of the time just to get the 5%.

Oh well, but even 5% would wake your xmpp all the time, thus causing
massive battery drains as you keep your system in a quite-active state
for several seconds.

You are assuming a 19:1 ratio. Thus you are doing feature negotation
with tls, zlib initialization and sasl.
- 3 stream header roundtrips / 6 xml openings,
- 4 Sasl stanzas
- 4 negotiation elements
- 1 resume
So at least 12 packages that are going over the wire, in exchange for
hopefully 19 saved ones.... But we have multiple TCP roundtrips and
alike. I'd guess that this doesn't save any battery.

Regards,
    Rene Treffer

>
>
>
>
>
>
> _______________________________________________
> JDev mailing list
> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________
>