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

Mridul mridul at sun.com
Thu Dec 7 17:49:40 UTC 2006

Michal 'vorner' Vaner wrote:
> On Thu, Dec 07, 2006 at 09:49:31PM +0530, Mridul wrote:
>> 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.
> You can not use them for reordering, you would have to store them, which
> is IMO:
> • More work, so clients should not be forced to de so
> • Could make a memory DOS attack

I am not sure if these are too tough to handle - temp files based on the 
seq id, etc are potential solutions : but that would be client dependent.

> • Could lead to blocked session that would not be dropped

I am not sure I understand this ... how do you end up with a blocked 
session ?

> And anyway, the question is - is sending out part of the processing?

Processing and delivery need not to be coupled: actually, if you are 
going to couple reading, processing and dispatch - you typically cant scale.
Consider simple example : sAB , sAC from userA to be sent to userB and 
If you couple them, sAC can be processed only after sAB has been delivered.
We can ofcourse think up alternatives on how to solve this particular 
problem - but just to illustrate the issue, thats all.

>  If
> yes, then you have guaranteed in-order delivery (since TCP can not swap
> them, nor could the server)

The problem with ibb is that there is absolutely no flow control or 
sequencing once the transfer starts (other than close that is).
For small payloads, this might be reasonable ... but if the data goes 
beyond some limit, you could end up with out of order delivery in the 
face of very heavy stanza transfer unless you start using blocking IO 
for ibb : esp multiple ibb transfers over s2s (which is where we 
normally see this issue).


> Have a nice day

More information about the Standards mailing list