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