powered by Jive Software

Reset all Presences to unavailable

After a disconnection all Presences are set to *unavailable *(done by Roster internal fuction setOfflinePresencesAndResetLoaded). This is fine, but not enough.

Because when I am connected and send a Presence unavailable, I do not get Presences of buddies which go unavailable. When I go *available *again I only get all available presences. The presence of the buddies which went *unavailable *in the meantime are not updated in the Roster. The result is that some buddies stay available, which in fact are not.

Other XMPP client libraries (e.g. XMPPFramework for iOS) handle this use case and reset all presences.

How can I solve this problem? The Roster provides no public functions to reset the presences.

you can send unavailable preance type packet to all roster connected with that user the same thing is done by openfire server when you are connected to server openfire send available packet to all user roster connected with you.

so the same process you can do when user is going to log out you can send presence type(unavailable) packet to all available user.

Thanks for reporting. I’ve created https://issues.igniterealtime.org/browse/SMACK-733

Your description reads like that Smack’s Roster API should act on outgoing ‘unavailable’ Presences and set the Roster contacts to ‘unavailable’. Side note: I believe that is due an optimization performed by some servers as mentioned in RFC 6121 § 4.4.2.

I do believe that the Roster’s state should stay at ‘loaded’.

However I’m not sure if this is enough. There is usually a counterpart in such situations, eg. action on a subsequent outgoing ‘available’ Presence. Which is, according to RFC 6121 § 4.5.3 considered a “second” initial presence. But since the Roster stays loaded, I can’t think of anything right now which should be done in this case.

Thank you for your answer and creating an issue. Due to lack of clarity I raised this question. It seems to need some investigations and clarifications…

However, the roster presences get out of sync and either Smack can handle this (preferred solution) or Smack at least provides an option or a function like setOfflinePresencesAndResetLoaded() and the client can handle the problem on its own.

After talking with some members from the XMPP community, I came to the conclusion that this is also an server bug. The XMPP server should sent also the unavailable presences after the client send an initial presence again. The server’s behavior you described - only sending the available presences of the contacts upon receiving the initial presence - makes only sense for the very first initial presence. Not for following ones.

Nevertheless, Smack will set the presences of contacts to unavailable when it sends itself an unavailable presence. While XMPP clients should only consider presence information from contacts as not up-to-date when the client went unavailable, this behavior makes this situation obvious to the Smack user.