[Standards-JIG] Re: WHACK
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
>> 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
> 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
> 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,
> 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
> 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.
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