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

David Waite dwaite at gmail.com
Wed Apr 26 07:19:23 UTC 2006

I don't understand what whacks do. Say for the sake of making examples
real-world that my network latency is around 60 seconds. Which message
am I confirming by sending a whitespace acknowledgement? Is the
assumption that I lose all ability to have keepalive messages, I must
acknowledge every message, and the number of 'whacks' sent is counted
to correlate?

And moreso, what type of accountability would end-to-end message
acknowledgement provide that isn't there by client-directed iq
get/response, or the existing "guarantees" of message delivery? Making
up an excuse "oh I didn't see your message, my Jabber server must have
been broken again" vs. "I didn't see your message, my jabber client
must be buggy/crashed while I was away from my desk"?

-David Waite

On 4/25/06, Peter Saint-Andre <stpeter at jabber.org> wrote:
> Hash: SHA1
> Chatting with Kevin Smith of the Psi project has, as usual, given me a
> new perspective.
> There are really two things here:
> 1. Reliability
> 2. Accountability
> Everyone wants reliability: they want to know that their messages (and
> other stanzas) will be delivered all the time. But not everyone wants
> accountability: they don't necessarily want another party to know when
> they received a message.
> JEP-0184 addresses the accountability issue, but if it is used for
> reliability then it automatically includes accountability, which normal
> users don't like.
> So what we need is a way to do acknowledgements without necessarily
> including accountability.
> Justin's "stanza acking" proposal [1] does this, but in a rather heavy
> fashion -- all those extra <a/> elements (seemingly top-level!), pings
> and pongs, etc.
> 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:
> 1. My client sends a stanza (intended for you) to my server.
> 2. My server sends a whack to my client.
> 3. My server routes the stanza to your server.
> 4. Your server sends a whack to my server.
> 5. Your server routes the stanza to your client.
> 6. Your client sends a whack to your server.
> One nice thing about this is that it doesn't require any changes to the
> core protocol, since entities are allowed to send whitespace between
> stanzas (in fact whitespace pings -- whings? -- are a subset of whacks).
> Another nice thing is that it's easy to implement.
> 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.
> In fact, this has a real Jer feeling to it. It's the kind of hack he
> would have built in at the very beginning. :-)
> Thoughts?
> /psa
> [1] http://www.jabber.org/jeps/inbox/ack.html
> Version: GnuPG v1.4.1 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> iD8DBQFETo15NF1RSzyt3NURAiXZAJwP4r95EXUwLfTxcmvveIk4Hs99iQCgvX17
> =mYPv

More information about the Standards mailing list