According to careful inspection of XEP-0286, relevant section 4.2 .... It would be beneficial if there was *some* standardized way to send a keepalive packet in less than 70 bytes (including the entire stanza -- <message ....></message>) .... This causes a 3G radio in a mobile phone to use a low-power low-bitrate mode.
In fact, the last sentence of section 5 of XEP-0286 says "Finally, protocol designers should aim to minimize any responses required from the handset, and ensure keepalive traffic, if any, fits inside FACH wherever possible." So, does anyone recommend a standardized method of a sub-70-byte keep alive <message> ? NOPE! The whitespace technique is the only reliable way to do this -- say, sending a single space character between <messages>, is only 1 byte. That makes the low-power 3G radio state possible, instead of the high-power 3G radio state. So, I say, whitespace technique has merit -- it can approximately double the battery life of a cellphone running an idling XMPP client 24/7 that runs keepalive pings. (Ideally, keepalives shouldn't be necessary, but, unfortunately, it is in many situations) However, http://xmpp.org/extensions/inbox/keepalive.html neglects to reference XEP-0286 section 4.2 as a STRONG rationale for using the whitespace method. I do suggest that a reference to XEP-0286 be added, to strenghten the justification of an XEP for whitespace keepalive best-practices. Thanks, Mark Rejhon On Tue, Jul 19, 2011 at 11:08 PM, Mark Rejhon <[email protected]> wrote: > Hello, > > I'm a software developer for mobile devices too, and it also varies by > method of TCP. > > For BlackBerry, there are actually several ways to connect, including > over BIS (carrier based proxy), BES (corporate BlackBerry Enterprise > Server, letting it be the firewall for your BlackBerry), and regular > mobile TCP/IP. Many mobile software XMPP clients, such as Beejive, > allows these various different methods to be selected. > > My experience is that some of these methods time out pretty quickly > (especially BIS) without keepalives, while some services such as BES > have a configurable timeout. > > Now, a properly optimized TCP/IP connection without a timeout can stay > alive for a long time with a mostly dormant mobile radio. The pings > can actually wake up a radio, causing the radio to begin consuming > more power, unless special design considerations are done to use a > lower idle-state bitrate. BOSH, while it solves other things, makes > this WAY worse because of the chattiness of BOSH. > > On the other hand, timeouts exist in many mobile implementations, and > thus, some form of keepalive is needed. From a battery perspective on > a properly designed mobile device, an open idle TCP connection uses no > more battery power than having no TCP connections. There is less > chattiness with a once-a-minute ping (sent only if no XMPP > transmissions done), than with doing BOSH on a mobile device. > > Take a look at XEP-0286 "XMPP on Mobile Devices". This is accurate > battery consumption advice, and my mobile experience agrees with this > spec. > > It's quite annoying detail, really, but this has to be considered. > > Mark Rejhon > (Author of XEP-0301, which also happens to being considered for > assistive needs by multiple companies in a multimedia NG911 system on > mobile phones.) > > On 7/19/11, Peter Saint-Andre <[email protected]> wrote: > > On 7/19/11 7:42 PM, Glenn Maynard wrote: > > > >> (Of course, mobile clients should really be using xbosh anyway, which > >> avoids these and other issues, > > > > Opinions vary on that score. We had some discussions about this years > > ago at one of the XMPP Summit meetings in Brussels and the guys from > > Nokia reported that TCP was actually much better for mobile apps because > > there are magical ways to manage long-lived TCP connections without > > waking up the device, which is not true for the more chatty BOSH > > protocol. Naturally, YMMV. > > > >> but it seems like the bosh/xbosh specs > >> have stalled...) > > > > How so? The specs are stable so there's probably no need to change them > > frequently. However, there has been discussion on the [email protected] list > > over the last few months and that might lead to some small changes and > > clarifications. Let's wrap up those threads and see if we need to > > publish a revised version of XEP-0124 (and perhaps XEP-0206). > > > > Peter > > > > -- > > Peter Saint-Andre > > https://stpeter.im/ > > > > > > > > -- > Sent from my mobile device >
