[Standards-JIG] Re: WHACK
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:
>>>> 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.
>> 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.)
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