WHACK (was: Re: [Standards-JIG] Reliable message delivery (the tcp problem))

Tijl Houtbeckers thoutbeckers at splendo.com
Tue Apr 25 21:57:14 UTC 2006

On Tue, 25 Apr 2006 22:58:33 +0200, Peter Saint-Andre <stpeter at jabber.org>  

> Kevin mentioned to me an alternative approach, which he swears is also
> Justin's idea -- whitespace acks (since I like fun names for things, I
> dub these "whacks"). Whenever an entity receives a stanza, it sends one
> whitespace character ("whack") to the immediate sender. So my previous
> flow would be as follows:
> ...

At the time that justin suggested his orginal ACK proposal, we had a  
discussion where I suggested using "a"/"A", and "p"/"P" instead of XML  
stanzas for ack and ping.
However, two things came up there (I can't remember who said them, but  
they are worth repeating).

The first one is the one also mentioned in the JEP, using namespaces you  
can reduce the size of the acknowledgements to <ack:a/>.

Secondly, the overhead of <ack:a/> vs. " " or "a", and even acking vs. no  
acking is often small in network terms, because (due to the small size)  
the extra data will often "piggyback" on other packets (the TCP ACK, or  
other data that happens to be going that way). Only if you have a  
unidirectional socket (such as with S2S) it could create many extra  
packets if there's no data going the other way. But then the difference  
between <ack:a/> and "a" is still small.

I'm bringing that up because if I remember correctly that was the reason  
to go with xml based acking and not my proposal at the time, it might  
still make sense. It did to me at the time :) Using whitespaces seemed  
like a bad idea because they're already in use, but back then use of  
<stream:features> wasn't as wide spread as it is now (seems fine to  
require it now). I admit I don't know if there's any different from an XML  
standards point of view between white space data or character data such as  
"a", instinctivly I'd say only when canonicalizing XML but maybe there's a  
real XML expert around? :) Or is it that XMPP CORE explicitly allows this  
because of the whitespace pinging many clients already did?

> Another nice thing is that it's easy to implement.

Welcome to "our" side ;)

> For this to reliably add reliability to the network, everything would
> need to support it. But that's true of stanza acking in general. You
> could disco your conversation partners and the in-between servers to
> know if they support it. And it's got to be something that you can't
> turn off, it's just there.

Exactly, as strongly argued at the time, the biggest advantage is you can  
add it where you want, without having to rely on another enity (the one  
you're addressing) supporting end to end tracking. Eg. your connection  
could be pretty good and maybe you wouldn't care at all about your client  
supporting this. But if I'm behind a Stupid(tm) router, on dailup, using  
GPRS, or forced to use an API that has the "black hole" socket effect, I  
can go look for a client and server that will let me ack.

That will improve reliabilty for me knowing whether my messages got to  
you, and your messages returning an error if they don't reach you. Even if  
you hate acking, and refuse to spend bandwith on either your client or  
your server to support this (or end to end), it'll still make my life  
easier. And yours too even :)

It's no replacement for "enterprise-style" end-to-end tracking (not even  
if you disco all nodes in your path and they support it), and it doesn't  
solve things like double delivery.. and there's still some edge cases, but  
IMHO *those* are the things casual IM users don't care about. Not having  
to (obsessivly at times ;) worry where you message went however, would  
give Jabber a nice edge over some other networks out there. Let's hope we  
can make it happen this time :) Whether XML or whacky or whatever based :)

More information about the Standards mailing list