[Standards-JIG] In order delivery for xep-0047 ?
Michal 'vorner' Vaner
michal.vaner at kdemail.net
Thu Dec 7 22:34:00 UTC 2006
On Thu, Dec 07, 2006 at 11:19:40PM +0530, Mridul wrote:
> 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.
Hm, temp files is even easier to DOS attack, they are slow.
> >• 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 ?
Well, one message got mysteriously lost and it is waiting for it
indefinitely? However, data still flow, so the connection does not
> >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
You can reorder these, since they are to other users and they have
different time. If there is different from or to, the time flows somehow
However, if you had a thread for every user, it still could make the
processing in-order and be parallel on the different users (and it is
where the load comes, from many users, no?)
> If you couple them, sAC can be processed only after sAB has been delivered.
No, after it was _sent out_, not delivered. If you send them in order
and you know there is nowhere for them to cross (or they go to different
location), you are OK.
> 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).
One user is connected to one machine, it goes to someone connected to
one machine and two machines can have only one connection between them,
no? So where it would cross?
Even if I might not have enough enough experience to see the problem, I
still thing even if there was such problem, it is not enough to make the
protocol crazy and need to implement flow controls, reordering and so on
on top of TCP once again. It seems to me we could just as well start
This is a terroristic email. It will explode in 10 minutes,
if you do not close it in the meantime.
Michal "vorner" Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the Standards