powered by Jive Software

MUC.leaveSync() causes significant delay when re-joining a desync MUC

#1

The change introduced in SMACK-848 only works if the MUC still considers the user as joined. If the MUC service was restarted, and our user isn’t an occupant any more, the MUC is not required to respond to presence/unavailable (the default is to drop it).

That means a join will be delayed by a packet timeout, which some mobile clients set to 30 seconds, because mobile networks are slow sometimes.

As we are checking for the stanza ID of the join response now in MUC.enter(), is this forced leaveSync() still required?

#2

I am not sure what the former has to do with the later. Basically leave() just mimics the (current state of) the protocol. If leave() returns without throwing then you know that the MUC service acknowledged that you left the room.

That said, I am all in favor of an MultiUserChat.instantLeave(). That is absolutely sensible to have a method where you do not wait for the ack from the MUC service. That’s a pattern you already have in Smack: it would be the analog of XMPPTCPConnection.instandShutdown().

I also note that this probably means that XEP-0045 should specify a response for the case where a client tries to leave a room he isn’t joined (from the MUC service’s POV). And that future groupchat protocols do not make the same mistake by not specifying that case clearly.