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? Artur -- Artur Hefczyc http://www.tigase.org/ http://artur.hefczyc.net/
