[Standards-JIG] Re: WHACK
mridul at sun.com
Fri Apr 28 19:26:36 UTC 2006
Some responses , some comments and somethings I was envisioning :
1) Not every stanza would require ack : depends on the QoS requirement
of a particular stanza.
Like SOAP/XMPP might require end to end ack or just hop to hop ack , or
no ack at all.
Similarly, if I am chatting with my boss , I might want to know if he
does not recieve any packets ;-)
Anyway , the basic intention is that , there might be different
requirements for different stanzas : not a flat out hop by hop for all
2) Retransmission would happen when you do not get ack within some
negotiated timeout (or maybe static timeout).
So extra n/w usage is acceptable imo ... since alternative is
potentially losing packets.
3) I was not paying much attention to 'monotonically increasing' ;-).
Let me put it this way, each subsequent is one more than the previous -
with initial value selected randomly :-)
4) Sending server's current_ack instead of ack for each stanza would be
a nice optimisation - did not think of it :-) Thanks !
5) If you club with point 1 and 4 above , the actual cost of ack is not
very high and stanza traffic would be pretty low IMO.
Whether you optimise away and send current_ack of server periodically or
for every stanza could be an impl detail - we just need to specify what
... how could be handled by impl's I guess.
Like, if number of packet's requiring ack's is high - makes sense to
send back ack's at higher rate to prevent too much packet queuing at client.
Similarly , we would need to send ack such that we prevent
retransmission if possible.
Thanks and Regards,
Dave Cridland wrote:
> 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.
More information about the Standards