WHACK (was: Re: [Standards-JIG] Reliable message delivery (the tcp problem))
stpeter at jabber.org
Tue Apr 25 20:58:33 UTC 2006
-----BEGIN PGP SIGNED MESSAGE-----
Chatting with Kevin Smith of the Psi project has, as usual, given me a
There are really two things here:
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
Justin's "stanza acking" proposal  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. :-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards