[Standards-JIG] Re: WHACK

Dave Cridland dave at cridland.net
Thu Apr 27 23:42:59 UTC 2006


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.

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


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


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

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