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 <[EMAIL PROTECTED]> 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
