[Standards-JIG] Re: WHACK

Dave Cridland dave at cridland.net
Wed Apr 26 15:30:19 UTC 2006

On Wed Apr 26 16:12:25 2006, Michal vorner Vaner wrote:
> On Wed, Apr 26, 2006 at 03:29:10PM +0100, Dave Cridland wrote:
> > No, because data can cross on the wire - TCP is full duplex, so 
> if > you receive data over a connection that has a 100ms latency, 
> the best > you know is that the remote end was not aware of an 
> error at some > point up to 100ms ago. It doesn't say much about 
> whether the data you > sent a few ms back is safe or not, whether 
> that was 10ms or 1000ms.
> Well, that is why I wrote almost. I know there is this few ms time,
> where the message could still get lost, but it is quite difference 
> to
> the TCP timeout of 15 minutes on many servers. And, in the time you
> receive the data, the line is probably useable and the data can 
> flow in
> both directions. This was ment as a compromise between complicity 
> and
> the problem.
"complexity" I think, not "complicity". Although that's not a bad fit 
either, to be fair. :-)

Sure this is a compromise, but in effect, there's no need to 
compromise, as long as servers can manage to hold a single integer 
for each dead session for about 20 minutes or so after the session's 
connection was severed. That's not asking much, is it?

> > Secondly, if you never get an ACK, you don't know if the stanza 
> you > sent was lost, or the ACK was lost.
> Well, but this is problem of quite any acking, thet if you do not 
> get
> ack, you do not know what of these two got lost. But, as said, it
> happens only when the connection dies and I guess receiving a 
> message
> twice is generally better than not receiving it at all. And the more
> probable thing on TCP (or whatever) is that the messages got lost, 
> since
> the acking would be in short sequence after the message.
Yes, of course it only happens when the connection dies. But if the 
connection doesn't die, the data is never lost, and yet that's when 
all these ACKs happen.

Now you say it's more probable that the message gets lost than the 
ACK, and I'd agree, but if we can avoid using probabilities to 
detirmine a reaction to a dead connection, I'll be much happier. If 
you want to go the ACK route, just call it "slightly less unreliable 
messaging extension" or something.

And it's possible to get actual reliability, and - I think - quite 
easy. You just add an optional sequence number to each stanza, 
specific to a session, and the server keeps a note of what sequence 
number was last dealt with from which session, and when a client 
connects and explicitly requests that session identifier again, the 
server tells the client what it last dealt with.

You can add an iq to get an explicit ack if you like, but it's not 
terribly important unless a series of large stanzas have just been 
transmitted by the client, in which case it might want to know when 
it can forget them. (It's also important if you need some assurance 
that the stanzas are being dealt with in a timely fashion). If you 
use these, you're actually getting ACKs, but if you don't, you're 
getting no extra packets, but yet you still get better reliability 
than a dumb ACK.

Feel free to tell me I'm stupid, as long as you also tell me why I'm 
being stupid.

As an amusement, in ESMTP terms, hop-by-hop ACKs are ESMTP's 
post-DATA response, end-to-end ACKs are DSN/MDN, and finally my 
suggestion is more akin to CHECKPOINT (RFC1845), but closer to Tony 
Finch's suggested replacement.

           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