[Standards-JIG] Re: WHACK
mridul at sun.com
Fri Apr 28 04:30:22 UTC 2006
Thanks for your responses.
I just have some more comments/queries inline :-)
Thanks and Regards,
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.
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).
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.
The only thing that would not get handled is stream terminates while ack
is not yet recieved.
This is something we will live with I guess ... there could be ways of
solving this , but the requirements would be significantly stringer in
I have not had the chance to read your proposal, where can I pick it up
from ? Thanks.
>> The stanza transmission and delivery would be in-order , the
>> processing need not be.
>> Counting the number of whitespace and popping them from client (or
>> server) side queue is a bit unreliable : esp if you could have out of
>> order stanza processing at the server.
> Ah, you're mistaking out of order processing (which can and probably
> has to happen) with out of order acceptance of responsibility, which
> really needn't happen at all.
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.
Not sure if I am explaining what I want to convey properly enough , or
whether I am understanding the problem you are addressing well enough ...
>> In a strict implementation as below , it could work :
>> a) client sends stanza to server , adds to local history queue.
>> b) server receives stanza from client , while stream is still locked
>> , sends whing ping to client.
> Locked? I'm not sure I follow.
Hope the note above makes it clearer.
The ack's for two stanza's should not cross : whacks are dumb in
themselves , useful only when sent in an order.
If server could potentially resond back with whacks out of order ,
client will have an incorrect list of undelivered stanza's (same for
server in opp direction).
>> b.1) NOT if this was a whing from client - pop from server queue.
>> c) for every whitespace that client receives , pop from client
>> history queue.
>> Mirror for communication in other direction.
>> I am not sure what an explicit ack stanza would not achieve which
>> this would ... the actual number/size of tcp packets would typically
>> be the same for both (assuming small enough ack packets) , while
>> giving better idea of the ack.
> 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
More information about the Standards