[Standards] mobile strengths and weaknesses

Fabio Forno fabio.forno at gmail.com
Tue Mar 25 20:11:32 UTC 2008


Thanks for the update. Some notes below

On Sat, Mar 22, 2008 at 1:37 AM, 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:
[...]

Nice to know all this is recognized ;)

>
>  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.

That's the first point where its seems that our friend isn't aware of
BOSH. We regularly keep the session open when our mobile client
disconnects and we can do interesting things like modifying the
presence when the client si disconnected (e.g. put the client xa with
a proper status message, and autoreply to messages telling the sender:
hey the recipient is temporary disconnect though you see it online,
don't worry the message will be delivered asap)
The feature is not yet in the released version of the client (which
uses tcp sockets) just because we are not ready yet for going public
with this connection manager, but it works without troubles. It's even
possible to reconnect after rebooting the client and, therically, it
should be possible to migrate the session to a different device.

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

See again BOSH for this

>  - 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...)

Yep, again BOSH is the solution. BOSH headers however aren't so large,
the <body/> bag is sometimes heavier. If this is a problem it's not a
big deal designing HTTP like binary headers, thus adding few bytes of
overhead each message. Of course there is a price for this: you lose
the capability of passing through real HTTP servers and proxies, but I
don't think it could be a big issue, since this would be just an
optional optimization for mobiles.

>  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...)

We were talking last week about the same idea with the people at Sapo.
The SMS option is possible also with XMPP since any mobile application
(J2ME, Symbian or the coming Android) can listen for incoming SMSes on
a given port and be automatically scheduled. Besides the session pause
feature, with BOSH again it's possible to stop the connection and
re-establish it when we receive an SMS. However this is feature for
carriers, since I don't think that free server operators or users will
pay the cost of an SMS for almost any incoming message.
Unfortunately this is design flaw  of GPRS/ 3G networks, and we have
to live with it unless there won't be install battery refills with
fuel cells ;)

-- 
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: ff at jabber.bluendo.com



More information about the Standards mailing list