[Standards-JIG] Re: WHACK

Dave Cridland dave at cridland.net
Fri Apr 28 12:04:58 UTC 2006


On Fri Apr 28 05:30:22 2006, Mridul Muralidharan wrote:
> Dave Cridland wrote:
> 
>> On Fri Apr 28 00:18:34 2006, Mridul Muralidharan wrote:
>> 
>>> Dave Cridland wrote:
>>> 
>>>> On Thu Apr 27 23:40:33 2006, Mridul Muralidharan wrote:
>>>> 
>>>>>  If you have some form of id'ing each stanza which requires ack 
>>>>> and use that in the ack , then yes we can find out which have 
>>>>> been delivered and which have not.
>>>> 
>>>> 
>>>> 
>>>> Nope, you still can't. You can find out ones which have 
>>>> definitely been delivered, but you don't know that the 
>>>> unacknowledged stanzas have not been delivered.
>>> 
>>> 
>>> 
>>> That would be simple to handle.
>>> The server discards stanza's which have ackid's which have been 
>>> already processed.
>>> Client retransmits unack'ed stanza's after timeout.
>>> This way stanza retransmission would not have a functionality 
>>> loss : except for a minor load increase.
>>> 
>>> Just one possibility, I am sure there could be better 
>>> alternatives.
>>> 
>>> 
>> Yes, I've suggested one already.
>> 
>> Your suggestion suffers from the problem that since the server 
>> cannot know if its acks have been received, it has to assume they 
>> aren't, meaning it has to remember every id ever received.
> 
> 
> I was thinking of the 'rid' in JEP 124 when I was suggesting this.
> Over there you have :
> 1) Monotonically increasing rid values from initial rid.

That's "strictly monotonically increasing". I've never actually seen 
a purpose to the word "monotonically", but apparently mathematicians 
love it.


> 2) If connection manager recieves a request with an rid it has 
> already processed ,it will just return the same response. (an 
> intermediary could have lost the stanza).
> 
> 
Uh-oh. That's fine, but not good over links that charge by transfer, 
like GPRS, for instance.


> So , trying to apply the same to our case , if ackid's are 
> monotonically increasing - we will not have the problem you 
> describe.
> If client retransmit a stanza 'cos of late arrival of ack , server 
> would ignore the stanza if stanza_ack_id < current_ack_id.

Right... But if the server says what current_ack_id *is*, then you 
don't have that issue either, because that client doesn't retransmit, 
even if...


> The only thing that would not get handled is stream terminates 
> while ack is not yet recieved.

Which rather suggests that the ACK itself is a waste of time, except 
that an occasional, periodic stanza indicating the current_ack_id is 
useful to reduce the sender's history.


> This is something we will live with I guess ... there could be ways 
> of solving this , but the requirements would be significantly 
> stringer in that case.
> 
> I have not had the chance to read your proposal, where can I pick 
> it up from ? Thanks.
> 
> 
It's on the list, but the essentials are in this message. There's 
nothing formal.

> Simple way to illustrate this :
> stazna1 , stanza2 sent from client , server recieves them in order 
> as stanza1 and stanza2 : so in order delivery is achieved.
> Sending ack would now need to be part of stanza acceptance , else 
> ack for stanza2 could make it back while not the one for stanza1 - 
> and if whacks , no way of differentiating this at client side.

Exactly. But it has to be anyway - so for an <iq type='get'/> stanza, 
for instance, you have two stanzas in return, one with the ACK, one 
with the result/error.

>> Agreed, whitespace acks don't provide anything more than acks do 
>> themselves. That's why I'm arguing against them both.
>> 
>> 
> Great ! I think there is a need to have hop to hop acks ... whacks 
> are interesting and simple idea but I feel not enough as they have 
> been described.

Hopefully, I'm explaining that hop-by-hop ACKs, at least for every 
stanza, aren't needed either. Just the sequence numbering.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw



More information about the Standards mailing list