On Wednesday 29 September 2010 11:06:39 Matthew A. Miller wrote: > On Sep 29, 2010, at 11:42 , Justin Karneges wrote: > > The rule is that stanzas must be delivered in order for a given > > source/destination JID pair. However, a MUC service sends stanzas from > > many different JIDs if you consider the varying resources, and therefore > > it cannot have any expectation that its sent stanzas will maintain > > order. This means that when a client joins a room, the room history > > might be received before the presence ack of the join attempt, and > > individual messages within the room history itself might get reordered. > > I believe sections 7.1.3 and 7.1.15 of XEP-0045 account for the order of > presence and room history correctly.
Yes, the XEP specifies the order that the MUC service should send out stanzas when it matters. The problem is that the stanzas are formulated in such a way that we can't expect XMPP-Core delivery order rules to hold. > from Section 7.1.3: > > Note: The order of the presence stanzas sent to the new occupant is > important. The service MUST first send the complete list of the existing > occupants to the new occupant and only then send the new occupant's own > presence to the new occupant. This helps the client know when it has > received the complete "room roster". In other words, the XEP is saying to send like this: <presence to="user" from="room/existing_occupant1"/> <presence to="user" from="room/existing_occupant2"/> <presence to="user" from="room/new_occupant"/> However, any XMPP server (whether the one the MUC component is connected to, or the user's, which may be over s2s) may route these stanzas in any order, because the from JIDs are all different. It would be perfectly legal for the user's server to relay the stanzas to the user in this order: <presence to="user" from="room/existing_occupant2"/> <presence to="user" from="room/new_occupant"/> <presence to="user" from="room/existing_occupant1"/> I see this issue becoming greater as XMPP servers become more optimized, threaded, clustered, etc. Maintaining delivery order comes at a cost, and you can be sure implementors will avoid that cost where allowed (indeed, this thread was prompted after discussions I had with Artur of Tigase and his desire to bend delivery rules for speed sake). -Justin
