[Standards] mobile strengths and weaknesses

Peter Saint-Andre stpeter at stpeter.im
Sat Mar 22 00:37:20 UTC 2008

Here is another data point regarding strengths and weaknesses of XMPP in
the mobile space. I received this offlist from someone who has
experience building mobile application with IMPS, SIP/SIMPLE, and XMPP
(but not recent XMPP experience I think -- this person may not be aware
of things like BOSH and stream compression)...



1. Speed - servers are superb and latency is minimal

2. Simplicity - easy to implement

3. Extensibility - easy to add custom protocol extensions

4. Low data usage - especially compared to SIP - a binary encoding of
XML would help even more (like OMA IMPS has) - but OMA IMPS loses the
race due to large HTTP headers

5. Large developer community (gateways to many other protocols, other
cool features)


1. Reliable message delivery

- Since XMPP is using TCP as transport method, it assumes that if the
TCP connection is active, then all the data transferred is reliably
delivered. However this is not true in mobile environments. GPRS
networks try to keep TCP connection active during brief out-of-coverage
situations, and sometimes the data sent during that period is lost when
the GRPS is unable to re-establish the radio-link between the user agent
and the base station.

- OMA IMPS protocol uses HTTP as the transport mechanism and provides
information about whether a transaction has been successfully delivered.

- SIP/SIMPLE uses TCP/UDP and also has a transaction based model with
clear rules for when a transaction should be re-sent.

* Basically the biggest problems come from the fact that on mobile
devices the network access is not that reliable and the interface can go
down at any time. Also the device might end up switching between
different radio interfaces (e.g., Wifi <-> GPRS). Taking that into
consideration when designing the protocol would have solved many of the
problems we faced with XMPP.

_Solution_: add transaction model to content that is considered vital
(or content that might cost the end-user). Create rules for how to
handle re-sending of the content.

(PSA NOTE: it seems that BOSH could help us here, though at the cost of
HTTP headers...)

2. XMPP requires a persistent TCP connection, which leads to battery
drain - as the network connection is required always when client is
online, the WiFi / GPRS / 3G connection is required as well. The "always
active" radio transceiver will consume a lot of power and drain the battery.

- OMA IMPS has a solution for this: the client can turn off the
signalling channel when the client is not in active use (chatting/etc),
and tell the server to fall back to SMS-based signalling. When the
server receives new messages that are destined for the client, it will
inform the client (using a special SMS message) that content is
available. The client will then resume the network + normal signalling.

(PSA NOTE: this is the "session pause" or "session hush" idea...)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080321/fe0a2d8d/attachment.bin>

More information about the Standards mailing list