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