WHACK (was: Re: [Standards-JIG] Reliable message delivery (the tcp problem))
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