[Standards] mobile strengths and weaknesses

pavlix pavlix at pavlix.net
Sun Apr 6 15:00:09 UTC 2008


I'm definitely for solving issues in XMPP on top of TCP. BOSH may be
nice but if we get it actually solved, it may help many more people
than just mobile/BOSH users.

There are many other users that suffer from XMPP's unreliability or
slowness in re-connections (it depends wheter XEP-ACK is implemented
and other stuff).

On Fri, 21 Mar 2008 18:37:20 -0600
Peter Saint-Andre <stpeter at stpeter.im> wrote:

> 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)...
> 
> ******
> 
> Strengths:
> 
> 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)
> 
> Weaknesses:
> 
> 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...)
> 
> ******


-- 

Web: http://www.pavlix.net/
Jabber & Mail: pavlix(at)pavlix.net
OpenID: pavlix.net



More information about the Standards mailing list