On Thursday 30 September 2010 02:13:22 Dave Cridland wrote: > On Thu Sep 30 00:12:59 2010, bschumac wrote: > > Users a...@s/C and b...@s/C are both online and both users begin a > > conversation with each other at the same time. The server > > > > receives > > > > messages in this order: > > 1. a...@s/C sends "Yo" to b...@s (Bare JID) > > 2. b...@s/C sends "How's it going?" to a...@s > > 3. a...@s/C sends second "Terrible." to b...@s/C (Full JID -- > > > > resource > > > > locked) > > > > However server provides incorrect guarantee that only ensures > > in-order between "fullest-possible" JID, the messages end up > > > > delivered out-of-order: > > * b...@s/C receives "Terrible." > > * b...@s/C receives "Yo." > > * a...@s/C receives "How's it going?" > > I'm in awe of your programming skills. The majority of clients have > to wait until they get the response before they resource-lock, and > moreover, quite a few users tend to wait until they see a question > before they answer it, too. Not me, of course - I wrote this message > three weeks ago, and just didn't get around to sending it until now...
At first I thought this example was sort of contrived (not that it matters to me, contrived examples are the most fun when discussing protocol), but with s2s negotiation lag you could replicate the above issue in real life. Suppose the outbound s2s channel of A's server takes longer (on the order of seconds) to complete than the inbound channel from B's server. It is possible that A is able to read B's message and reply to it, while A's initial message is still queued waiting for the outbound s2s to be ready. This means there will be two of A's messages queued to be sent (one to B's bare JID and the other to B's full JID), and the delivery order of these messages will be at the mercy of A's server implementation. > I'll throw out an alternate ordering rule, and see how people react: > > Servers MUST ensure in-order processing of the stanzas received on a > stream. Servers MUST resolve any ambiguity caused by processing > requests (for example, those sent to the bare jid of a connected > client); in the case where the result of a request could have an > effect on subsequent stanzas, servers MUST suspend processing of > stanzas until the request is completed. Servers MUST ensure that any > stanzas forwarded from a stream to a particular remote domain are > forwarded in order - in particular, this implies that for any given > inbound stanza that is addressed to a remote domain, there SHOULD be > at most one outbound stream, used consistently. Beautiful. :) I like this because it goes beyond merely delivery and also addresses pipelining, to provide a complete "in-order processing" picture. In the context of the existing section 10.1, your suggestion is, interestingly, neither Full JIDs pairs nor Bare JID pairs. It is basically Bare JID destination (where it makes sense) and Stream source. -Justin
