WHACK (was: Re: [Standards-JIG] Reliable message delivery (the tcp problem))
dave at cridland.net
Tue Apr 25 21:38:41 UTC 2006
On Tue Apr 25 21:58:33 2006, Peter Saint-Andre wrote:
> Kevin mentioned to me an alternative approach, which he swears is
> Justin's idea -- whitespace acks (since I like fun names for
> things, I
> dub these "whacks"). Whenever an entity receives a stanza, it sends
> whitespace character ("whack") to the immediate sender.
I think you're duplicating TCP level ACKs there needlessly, and
you're instantly making a mobile-based XMPP client more expensive to
operate, in terms of power and cost. Moreover, for non-mobile
systems, the difference between sending <ack/> and a whitespace
character is virtually nothing due to the TCP overhead. So in my
opinion, it's more w-hack than wh-ack.
In general, hop-by-hop reliability is only a problem in as much as it
can be difficult to know whether the connection is still alive.
Essentially, you don't know whether the next hop has taken
responsibility for the message's delivery or not. An explicit ack
solves this for the case where the connection stays alive
sufficiently long to receive it, but not for the case where the
connection dies between receiving the stanza and sending the ack -
this is a well known ESMTP problem.
An alternative would be to introduce synchronization points, such
that the server would inform the connecting client what the
previously know synchronization point was on connect. (I'm assuming
that whitespace pings or some other NOOP will handle detecting
whether a suspiciously silent connection is actually dead).
The simplest thing would be to add in an integer attribute on
potentially every top-level element, such that a client simply grabs
a new one (strictly increasing allocation), and can then know easily
what was and wasn't received by the server.
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