[jdev] XMPP on Android, Round #2

[Matthew Wild]

On 2 November 2010 21:24, Stephen Pendleton <pendleto at movsoftware.com> 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
>> Yes, that would also be used in the cloud push scheme to resume the
> stream. The cloud push scheme allows it to work without having to establish
> a secondary XMPP polling connection. My feeling is that the approaches are
> practically the same but using Google's push would use the existing Android
> connection to the cloud service. Either way support for the asmack service
> to be notified of a wake-up-and-resume-session event would be needed.
>
>>But this would mean I'm doing a feature negotiation run to fetch the
>>queued stanzas, as XEP-0198 reserves throttling for servers:
>>So, if I get you right, I should kill the XMPP TCP connection to wait
>>for events on another idle TCP connection and then restart the XMPP
> connection. Basically exchanging an idle secondary connection for a full
> negotiation every now and then?
>>Could you please explain how this could save battery? Am I missing
>>something?
>
>
> There are a few issues here. The first is that the idle XMPP connection is
> not idle if you have XMPP contacts. You are typically receiving many events
> that you don't (or may not) care about while the XMPP client is in the
> background such as presence, pubsub events, etc.

This is why we have extensions like PEP and SIFT:
http://xmpp.org/extensions/xep-0273.html

> Another issue is on mobile
> devices you may lose connection to the XMPP server semi-frequently as the
> devices moves about which will require full XMPP stream reconnection. Most
> importantly I am assuming you are implementing a partial "wake lock" on the
> Android device which prevents the device from sleeping and killing your
> active TCP connection.
>

I wasn't aware that sleeping devices would kill TCP connections.
Anyway, I would be very surprised to learn that Google's push service
didn't use TCP - and I wouldn't be surprised to learn it used XMPP or
similar :)

> So the approach would be to remove the wake lock and allow the device to
> sleep until the next poll/push time which would be used to determine if an
> interesting stanza (message, etc) is available on the server. If the
> poll/push results indicate that a XMPP connection is required you would use
> stream management features to reconnect the stream.
>

Polling gives you latency, unnecessary bandwidth use, and everything
you don't want. That's the whole point in these push-based mobile
services. In addition new connection establishment requires half a
dozen network round trips, even with stream management. Sending a
stanza to an open waiting connection just one.

Matthew