[Standards] stanza order and MUC

Florian Zeitz florian.zeitz at gmx.de
Wed Sep 29 23:04:36 UTC 2010

On 30.09.2010 00:08, Artur Hefczyc wrote:
> On Sep 29, 2010, at 10:17 PM, Florian Zeitz wrote:
>> On 29.09.2010 21:02, Justin Karneges wrote:
>>> 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).
>> Hi,
>> 3920bis actually doesn't talk about a source/destination JID pair, but says:
>> "An XMPP server MUST ensure in-order processing of XML stanzas between
>> any two entities."
>> I would argue that the two entities in this case are the MUC component
>> and the users server. The server must then process the stanzas in the
>> order it received them from the MUC, where processing means sending them
>> to the client.
>> The interesting question seems to me: Can a server actually make that
>> promise?
>> It'd have to be able to distinguish room at server/nick from
>> user at server/resource.
> Indeed, how is the server supposed to distinguish between the MUC component
> and other entity? In theory the server can query each sender and received for
> service disco to find out. In theory possible, even though highly inefficient still
> does not solve the problem fully.
> Please note, the MUC component is just one of border cases which may cause
> such problems. There are lots of different use cases where we can encounter
> similar problems with packets ordering between entities which are visible behind
> multiple JIDs/resources.
>> Or it'd have to process all stanzas coming over the same XMPP stream
>> in-order, which might actually be the intended behavior.
> What you mean by XMPP stream? Does it include S2S and all external 
> components too? What about built-in components?
First: Note that I'm not suggesting you do that as such.
Yes this would mean any XMPP stream. So C2S, S2S and external components
too. Communication with built-in components is not mandated by XMPP, I
would view them as part of your server for this purpose.

> Artur

More information about the Standards mailing list