[Standards] About Fast Reconnect
azlist1 at gmail.com
Mon May 5 14:53:49 UTC 2008
I am new to XMPP development and please excuse me in advance if this is not
the good place to post my question.
I am developing a custom mobile (j2me) application that is going to use XMPP
as it's "data" and "commands" transport mechanism.
My implementation authenticates to the xmpp server and then retrives the
user roster on each connection to the xmpp server before sending a new
The roster is stored / cached in the client after successful retrieval.
Everything was fine until recently when I realised that a mobile device was
constantly dropping its Internet connection for various reasons mostly loss
of GPRS signal, incoming call etc ...
With the actual state of the xmpp specs there is no other way for me than to
re-authenticate and re-request the user's roster each time a connection is
My main problem here is linked to the fact that data transfers over GPRS are
still quite expensive if you're not on a flat rate data plan with your
mobile provider, and I really want to avoid useless data transfers to limit
the communication costs .
I've been googling a litle and it seems that this issue has been discussed
during one of the xmpp guru's meeting in Brussels earlier this year. A
proposed solution was to implement a fast reconnect mechanism.
I wanted to know what was the evolution on this side of the standards
More generally speaking, is there a way for me to bypass the entire
post-authentication mechanism that is usually implemented i.e. roster
retrieval. As far as I know roster retrieval is mandatory for a resource if
it wants to be notified of new presence messages "If an available resource
does not request the roster during a session, the server MUST NOT send it
presence subscriptions and associated roster updates." The problem here is
that I need the client to receive roster and presence updates even if the
roster wasn't requested after re-authenticating to the xmpp server.
Thank you in advance for your help and feedback on this.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards