On Thu Sep 30 14:59:02 2010, Ben Schumacher wrote:
My basic point is that if you're using some sort of threading,
queuing, sockets, quantum delivery in your server to make it
"optimized, threaded, clustered, etc." and you choose which thread,
queue, socket, particle based on whichever JID the stanza is
address to, rather than a "sensible" approach that uses a bare JID
(ignores the "resourcepart", if it exists), stanzas will get
delivered in a different order than they were introduced into the
system. It may not happen all the time, but it will eventually
happen.
If a user has two clients connected, there is no way you can make any
assumptions on when two sequential stanzas sent to the users bare
jid, but to different full jids, will be delivered.
So yes, it will eventually happen - quite a lot.
And I don't think we need to care.
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.
Seems okay to me with the caveat that a stream, when a user is
involves, obviously requires a "resourcepart" and tying the wording
too closely to the concept of a stream leaves cases open where I'm
sending messages to another user which resource-locked and the
users goes offline as I'm sending message (thus breaking the lock).
Assuming that my messages are delivered within the context of my
stream in-order and then handed off to some construct that
represents the other user's stream, but the socket is close before
they're delivered, what the expectation for the message with
regards to offline storage?
As the sender I'd expect the messages to end up in offline in the
same order they were originally sent by me, but when the other
stream disappears mid-conversation, what's our in-order semantics?
I'm maybe a little too close to an implementation here, but I think
it's less ambiguous to simply tie in-orderness to a (destination)
bare JID rather than a stream.
I think once you've "attempted delivery", you assume you've done your
bit.
If you don't, then I can concoct any number of cases where the
in-order delivery rules will either break, or cause massive
serialization.
To pick on off the top of my head:
u...@example.org has two 198-enabled clients, on resources 1 and 2.
We send a stanza from u...@example.net to u...@example.org/1, and
subsequently another one from u...@example.net to u...@example.org/2.
After a period, u...@example.org/1 drops offline without acking the
stanza.
When we perform recovery on unacked stanzas - either because we don't
support resume or because the resume timer expired - we'll redeliver
the stanza to /2.
The only way I see to avoid this is to - if 198 is supported - delay
the delivery to /2 until /1 no longer has any unacked stanzas. I
don't think this is a practical suggestion.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
