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

[Mridul]

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 
impl details.
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
> timeout.
>   

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 
>> userC.
>>     
>
> 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
> independently.
>
>   

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 
users.
As I mentioned elsewhere, for two 'humans' chatting, this almost never 
happens until you do ibb : for two bots 'chatting', the possibility is 
higher.

>   
>> 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 
mean correctly).
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 
into play.

>   
>> 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?
>   

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 
whatever).
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.


Mridul