[Standards-JIG] Re: WHACK

Mridul Muralidharan mridul at sun.com
Fri Apr 28 04:30:22 UTC 2006


Hi Dave,

  Thanks for your responses.
I just have some more comments/queries inline :-)

Thanks and Regards,
Mridul


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 
that case.

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 
described.

> Dave.





More information about the Standards mailing list