On 9/30/10 12:26 PM, Justin Karneges wrote: > 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.
Interesting. Unfortunately we're on the wrong list here. I'll start a thread on [email protected] so we can bang this out. Peter -- Peter Saint-Andre https://stpeter.im/
