[Standards-JIG] In order delivery for xep-0047 ?
mridul at sun.com
Thu Dec 7 23:14:34 CST 2006
Chris Mullins wrote:
> Don't forget multiple resources bound to a single stream...
Yet to scope this one :-)
> (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.
More information about the Standards-JIG