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 r...@server/nick from >> u...@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 Florian
