[Standards-JIG] In order delivery for xep-0047 ?

Mridul mridul at sun.com
Fri Dec 15 07:01:06 CST 2006


Hi Matthias,

  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
>> appropriately.
>>     
>
> If delivery would not be part of the processing, that has to be
> in-order, then think about the following situation:
>
>
> C----S1-----S2
>
> 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 
be expensive).
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 
here :-)

> 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.


Regards,
Mridul

>
> Tot kijk
>     Matthias
>
>   




More information about the Standards-JIG mailing list