On 2 November 2010 21:24, Stephen Pendleton <[email protected]> wrote: > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Rene Treffer > Sent: Tuesday, November 02, 2010 4:09 PM > To: [email protected] > Subject: Re: [jdev] XMPP on Android, Round #2 > > On 11/01/2010 10:14 PM, Stephen Pendleton wrote: >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf > Of Yann Leboulanger >> Sent: Monday, November 01, 2010 4:27 PM >> To: [email protected] >> 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 _______________________________________________ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [email protected] _______________________________________________
