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.
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".
Section 7.1.15:
After sending initial presence as shown above, a room MAY send
discussion
history to the new occupant. (The room MUST NOT send any discussion
history
before it finishes sending room presence as specified in the Presence
Broadcast section of this document.) Whether such history is sent, and
how
many messages comprise the history, shall be determined by the chat
service
implementation or specific deployment.
I don't see any specific note on order or received messages for broadcast, but
this is a big XEP and I could be missing it (-: It might not be explicitly
defined because most of the initial implementations were components linked to
the server via the component protocol, and therefore have a single
point-of-entry (a single network socket); this would guarantee an order that
the MUC service receives stanzas.
I'm not sure what we could say about other MUC implementation forms (e.g.
in-process plugin directly into an XMPP server). We'd welcome suggestions on
this point.
- m&m
