145
edits
Line 29: | Line 29: | ||
= Am I still there? = | = Am I still there? = | ||
Current MUC / server implementations do not send offline-presence packets to participants on service restart. Therefore, a client will think it is still joined to a MUC indefinitely. | Current MUC / server implementations do not send offline-presence packets to participants on service restart. Therefore, a client will think it is still joined to a MUC indefinitely, only seeing silence. | ||
There is no portable/reliable mechanism to check if the client is still joined, and no clean way to re-sync the state if it is not joined. | There is no portable/reliable mechanism to check if the client is still joined, and no clean way to re-sync the state if it is not joined. | ||
Sending a "silent" message or presence update to the MUC will lead to O(N²) complexity (if every client does so), killing all our batteries. | |||
The "most viable" workaround is: | |||
Periodically do: | |||
* send a XEP-0199 ping IQ to your participant JID (it might get reflected to your client or to another one) | |||
* set a timer | |||
* if you receive a ping, respond to it | |||
* once you receive the ping response, you know you are still joined - stop the timer | |||
* if the timer fires, you are probably not joined any more | |||
** send presence unavailable | |||
** send join presence | |||
= MUC double join = | = MUC double join = |