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

Chris Mullins chris.mullins at coversant.net
Thu Dec 7 19:47:23 UTC 2006


Don't forget multiple resources bound to a single stream... 

(Coming Soon to an IM Server Near You!)

--
Chris Mullins

-----Original Message-----
From: standards-jig-bounces at jabber.org [mailto:standards-jig-bounces at jabber.org] On Behalf Of Justin Karneges
Sent: Thursday, December 07, 2006 11:45 AM
To: XMPP Extension Discussion List
Subject: Re: [Standards-JIG] In order delivery for xep-0047 ?

On Thursday 07 December 2006 8:19 am, Mridul wrote:
> Matthias Wimmer wrote:
> > If you are binding a XMPP stream on a transport protocol, that does
> > not guarantee in-order delivery by itself, your binding would have to
> > ensure the reordering.
>
> I think the assumption here is that in order processing will immediately
> result in in order delivery - which is a simplistic scenario.
> Anyway, the point is - since xmpp does not mandate in order delivery : I
> am not sure why 47 is trying to mandate it - especially since seq number
> can be used for message re-ordering in case of out of sync delivery.

Except that XMPP *does* mandate in-order delivery.  If it is unclear in the 
RFC, then it needs to be fixed, since I believe this was always the intent of 
the protocol.  I think the only reason the document doesn't explicitly 
say "in-order delivery" is because this would be redundant in the context of 
a single TCP stream.  Now that we realize we might have non-TCP bindings, or 
multiple TCP streams (s2s), some additional clarification is needed.  
However, I don't see in-order delivery between each jid pair to be a threat 
to parallelism.

Regarding IBB: XMPP guarantees stanza order, but it does not guarantee stanza 
delivery to occur.  Therefore, a sequence number is needed to detect a hole 
in the transfer (missing packet).  The sequence number is not used for any 
kind of reordering.

-Justin


More information about the Standards mailing list