[Standards-JIG] In order delivery for xep-0047 ?
mridul at sun.com
Fri Dec 8 05:12:11 UTC 2006
Michal 'vorner' Vaner wrote:
> 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.
Trivial to handle IMO - have a window for 'lost' seq id's, etc : just
The restriction that after 64k, the seq id should go back to 0 already
requires something of this sort.
>>> • 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
It wont need to wait for a stanza indefinitely ... like everything else,
you will just timeout a transfer with a close as per client
implementation and configuration.
Ofcourse, you can always write something which messes up : but for that
you dont need ibb :-)
>>> 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
That was just to illustrate the problem.
For this specific case too : sAB could be to userB/res1 and sAC could be
to userB (bare jid) with res1 being the most available resource.
> 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 there are requirements for strict order to be mandated - you can
always use time stamps or seq id or something else.
At the client, compare timestamps/seq id for messages from a user (his
timestamp) and just reorder in case you recieve an older message later:
this is simple for bots to handle, might require UI magic for chat clients.
Note, this sort of reordering does not normally happen - happens under
heavy load with a large number of stanza's being transferred between two
As I mentioned elsewhere, for two 'humans' chatting, this almost never
happens until you do ibb : for two bots 'chatting', the possibility is
>> 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.
You cannot fragment stanza's being written, so need to write it 'whole'
: so sent out is same as delivery assuming tcp (if I understood what you
While the actual acting of sending out could get deferred for later
based on socket state, etc and this IO management is typically not a
very simple layer (atleast not for us) and other considerations come
>> We can ofcourse think up alternatives on how to solve this particular
>> problem - but just to illustrate the issue, thats all.
>>> 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?
I am not sure I understand this ... I did not talk about crossing of data.
I think the assumption here might be that, userA sends data, thread in
server reads data from socket, processes it, writes it to recepient
socket (s2s or userB) for delivery : then goes back to reading from
userA again. (or variations of this replacing socket with queue or
This is a bit simplified view of a server.
> 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
> using UDP.
Clients wishing to 'ignore' it can ofcourse chose to do so as an impl
detail : but the protocol should be able to handle cases like this.
More information about the Standards