[Standards-JIG] Re: WHACK

Mridul Muralidharan mridul at sun.com
Thu Apr 27 23:18:34 UTC 2006


  Please see inline.


Dave Cridland wrote:

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

That would be simple to handle.
The server discards stanza's which have ackid's which have been already 
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.

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

  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.

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

Another point , considering that the xmpp stream always allowed 
whitespace between packets (unless where explictly forbidden by spec) , 
and also considering that we have servers and clients which use just 
this to keep stream alive (through proxies , etc), you will be breaking 
a few implementations.
Like , no stanza transferred for nat_timout seconds - what do we do now...
Lastly , it is quite a strict requirement to send whings such that there 
is no conflict and requires 'bugfree' impl :-)

Thanks and Regards,

More information about the Standards mailing list