[Standards-JIG] In order delivery for xep-0047 ?
mridul at sun.com
Thu Dec 7 22:51:10 CST 2006
Ian Paterson wrote:
> I agree with the quotes below from Remko, Matthias and Kevin.
> Since the intention has always been for in-order delivery, either we
> need to tighten up the wording of the RFC a little to remove any
> possible doubt, or we need to agree a radical change to XMPP to allow
> client implementations to reorder the instant messages they receive.
I am not sure if the intention was in-order delivery - if yes, then it
will very severely affect the scalability of xmpp servers.
Currently, most of the processing is already pushed to the server side
keeping clients simple (there are already ramification's of this on
pubsub and muc).
But if trivial things which can be handled easily at the clients are
also going to be pushed to the server side, it will make things a bit
When it comes to 'humans' chatting, the load is minimal and chances of
reordering are very rare (except for ibb) - but when you start using
xmpp as a presence enabled realtime messaging bus, a bunch of issues are
Message ordering is very simple to handle at clients if required :
timestamps, seq numbers, etc - not sure why this should even be pushed
to the server.
In this specific case - there is a sequence number already assigned, the
max data size if already negotiated - so it is trivial to handle out of
You can always have a window size for 'lost' seq id's after which some
'action' (request for retransmission/close/etc) can be taken.
Another thing which will help this xep in particular (and this has been
a long standing issue for us) is some way to negotiate atleast advisory
> Such a major change is unlikely to be agreed at this late stage, and
> IMO it would not be desirable anyway since it is incompatible with our
> Simple Clients mantra.
Simple clients wont hit the problem typically.
> - Ian
> Remko Tronçon wrote:
>> The possibility of delivering messages out of
>> order puts a huge burden on the client, and I don't think any client
>> copes with this (for example, when sending MUC history). Even worse,
>> if a server can reorder messages, then the client will sometimes show
>> messages in the wrong order, which is untolerable in an IM context.
> Matthias Wimmer wrote:
>> If in-order delivery would not be necessary, why should then in-order
>> processing be required? If I would not receive stanzas in-order,
>> nobody could check if I am processing them in-order. Therefore the
>> requirement in section 10 does not make sence to me, if it would not
>> include in-order delivery.
> Kevin Smith wrote:
>> On 7 Dec 2006, at 16:19, Mridul wrote:
>>> Anyway, the point is - since xmpp does not mandate in order delivery
>> I'm not at all sure that this is true, but if it's possible to
>> interpret it this way, I think the wording should be tightened up in
>> the RFCs, as it's always been my belief that in-order delivery was
>> the intention.
More information about the Standards-JIG