[Standards-JIG] Re: WHACK

Dave Cridland dave at cridland.net
Thu Apr 27 22:57:31 UTC 2006

On Thu Apr 27 23:40:33 2006, Mridul Muralidharan wrote:
> Tijl Houtbeckers wrote:
>> On Wed, 26 Apr 2006 19:26:35 +0200, Mridul Muralidharan 
>> <mridul at sun.com>  wrote:
>>> Hi,
>>>   Just to get my thoughts in order about this discussion :
>>> Sending of whack's is just to get around tcp implementation 
>>> issues right  ?
>>> What I mean is , there is no way to correlate which stanza's were 
>>>  received at the server (or the client) end given that sender 
>>> received a  whack.
>> "Whack" or something else based on JEP-ACK, uses acks, or "whacks" 
>> if you  like, for individual stanzas. That allows you to know 
>> exactly what stanzas  were at least received by the other end 
>> (wether it's a server or the  client), which solves the bulk the 
>> problems that people keep bringing up  here.
> Hi,
>  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.

> I dont see how whitespace ack will tell us upto which stanza the 
> server recieved/processed - there would be stanza pipelining at 
> both server and client side , and you could have unreliable 
> intermediaries.
It tells you the same whether it says the id or not, because stanzas 
have to be accepted in the same order as they're transmitted - 
whether or not they're processed. The ack signifies transfer of 
responsibility, not just data. So in this design, one whitespace 
character causes the receiver to delete the first stanza in its 
history queue of unacknowledged stanzas.

If you don't have that - if stanzas can be accepted from the stream 
out of order - then reliability becomes very much harder to aim for.

As it happens, the ack here is designed to both act as a connection 
failure detection mechanism and to prevent retransmission, and I 
agree with your comments that it's a poor connection failure 
detection. A whitespace character sent arbitarily works much better, 
prevents NAT timeouts, etc. (You don't need to make them pings, you 
just need to ensure that both ends see some network traffic every 
five minutes or so.)

           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