[jdev] XMPP on Android, Round #2

[Stephen Pendleton]

-----Original Message-----
From: jdev-bounces at jabber.org [mailto:jdev-bounces at jabber.org] On Behalf Of
Rene Treffer
Sent: Wednesday, November 03, 2010 5:16 AM
To: Jabber/XMPP software development list
Subject: Re: [jdev] XMPP on Android, Round #2
>> -----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
>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?

I'm not sure what you mean by wake lock for GSM/TCP, nothing exists for
that. There is only wake locks that keep the CPU from sleeping, display from
turning off/etc. If you are using a time tick intent then you are implicitly
doing a CPU wake lock every tick. This is done automatically by the system
and isn't released until your onReceive is called. I am guessing you are
doing this every 60s or so along with a whitespace ping. Unless you do this
the TCP connection will get killed when the device CPU sleeps. If you aren't
seeing that on your device then there is some other process doing a partial
wake lock. In particular, certain versions of the Facebook client had a bug
where it never released the wake lock. Several (bad) Twitter clients also
maintain an open wake lock. There is a good app called Spare Parts in the
market that will give you insight into partial wake usage battery
information.

>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

That's true, that is a lot of overhead for just resuming a stream! The other
point I mentioned that you are probably doing this anyway with a long lived
connection scheme as the device moves and loses and restores connectivity.
Plus the whitespace pings.

Anyway, the one great thing about open source is that different schemes can
be built relatively easily and compared.