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...
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.
What this means in practical terms:
1) If you get a vCard request for a bare jid, and a message to that
same bare jid, you needn't block the entire stream while you pootle
off to your database (or, if you're as hip as us, your ACP-142
compliant X.500 directory) to fetch the info. Just kick of the vCard
fetching, and forward the stanza to a suitable resource. If a sender
cares about what the result of the vCard is prior to delivery of the
message, they'd wait. And you certainly don't care - whatever their
family name is, you're going to pick the same resource, and even if
you waited, there's no certainty you'd manage to delivery the result
before the message anyway.
2) If you get a XEP-0191 change request from a client, and, in the
same TCP packet, a presence broadcast - hence both to the same bare
jid - then absolutely you need to fully process the XEP-0191 request
before the presence broadcast, because the order clearly matters.
3) Once you've forwarded a message, that counts as processing. So if
two sequential messages require forwarding to two different streams,
then you don't need to care about the order they're delivered. If two
sequential messages require forwarding to the same stream, you
forward them in turn (such that they'll arrive in-order).
3) If a MUC service is - sensibly - using a single stream to
communicate with you, it all Just Works™. If it doesn't use a
single stream, it becomes their fault and not yours. (But note that a
MUC service could use a single stream per-participant
4) If you use multiple streams to communicate with an entity (ie, two
S2S streams which you randomly use either of to send to a remote full
jid), then everything will break, and this is entirely your fault.
You can, however, consistently use one of any number of streams to a
remote domain for stanzas from a particular stream.
5) Quantum clients capable of resource locking prior to locating a
resource to lock will now work - this is an important demographic in
some dimensions.
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
