[Standards-JIG] In order delivery for xep-0047 ?
Mridul
mridul at sun.com
Thu Dec 7 11:49:40 CST 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
userC.
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).
Regards,
Mridul
> Have a nice day
>
>
More information about the Standards-JIG
mailing list