[Standards-JIG] In order delivery for xep-0047 ?
mridul at sun.com
Fri Dec 15 13:01:06 UTC 2006
Was not around (still am not actually) for a while - hence late response !
Matthias Wimmer wrote:
> Hi Mridul!
> Mridul schrieb:
>>> If I would not receive stanzas in-order, nobody could check if I am
>>> processing them in-order.
>> I am not sure if you can check this whatever be the model you apply ...
>> client sends stanza's and expects server to process it and route
> If delivery would not be part of the processing, that has to be
> in-order, then think about the following situation:
> Client C of Server S1 sending two stanzas to S2. Server to is required
> to process received stanzas in-order, right? But if you do not require
> delivery of messages to be in-order, how do you know, that it's not S1,
> that just delivered the stanzas to S2 in an in-correct order? You can't,
> and therefore it would make no sence to require S2 to process the
> stanzas in-order.
Actually, this does not happen in a lot of cases : S1 would process C's
stanza in order, but delivery to S2 is not gaurentee'ed in order.
Simple example would be when you have the s2s out connection from S1 to
S2 being established. (this is not very uncommon, s2s connections do break).
Initial stanza's from C would get queue'ed (which connection is in
progress) and it is possible that a later set of stanzas (from C) could
get delivered before as soon as the connection is established (not
really a bug but a design compromise, since fixing this normally would
I do agree that I am describing a slightly contrived (though common
enough) usecase here, but just to illustrate that out of order delivery
should not really be so surprising.
Actually, there are a bunch of corner cases where xmpp leads to race
conditions (rosters and privacy lists comes to mind). Some of which are
handled optimistically by implementations, and some others are mentioned
> You are right, that in-order delivery is an additional burden for server
> implementations, but it is not something that prevents scaleablility, it
> just requires additional work by the implementor.
In the above case for example, you can imagine the amount of critical
sections/locking to enforce in order delivery - and this is going to
affect all stanza's to be sent from S1 to S2 - always : If nothing else,
that would kill any server.
Another simple example where in order delivery would actually be very
detrimental for xmpp-system performance would be IBB itself.
That is, in the above example which you described C -- S1 -- S2
If you allow all traffic from C to S2 on same set of sockets - you will
quickly end up saturating the S1 -- S2 link with C's ibb stanza's : not
just for C, and this affects all clients hosted on S1.
Alternative is to use another ibb specific s2s out from S1 to S2 ... and
use that for ibb stanzas for clients on S1.
Please do note that, in the case above we are totally breaking in order
delivery - though from ibb's channels point of view, we are not.
The burst traffic and stanza size in IBB is typically 'large', order of
magnitude larger than a normal xmpp : and there is absolutely no way to
even specify any form of flow control - other than relying on external
means of traffic shaping. In our server, we special case IBB with a
bunch of code just to ensure in order delivery and make sure that
clients dont break cos of the strict in-order requirement : and this
comes at a non-trivial performance penalty.
> Remember, that we do
> not only have clients running on PCs with lots of memory and computing
> power. We also have clients running on mobile devices with maybe just a
> bit of RAM and no access to other storage.
The problem I describe above is not something which happens commonly :
but happens under load (when you have quiet a bit of data queued up for
a client which starts to cause socket buffer to be full).
A potential solution would be for the client to have a simple
implementation/config dependent window based timeout for ibb stanza's.
Since all stanza's are identified with a seq-id - the window size can
be as large as 64k/2 or as small as 1 (that is not handle it - current
case). But as long as spec has those MUST clauses, clients or
applications cannot support this without being non-compliant, and
servers have to resort to tricks to handle it.
For a normal use case of chat client, the possibility of out of order
delivery is negligible : typically the traffic load is minimal.
If you are having applications which use xmpp as middleware and are
going to pump messages at a high rate , then it is quite simple to have
some sort of stanza id'ing to handle potential out of order delivery.
> Tot kijk
More information about the Standards