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

Dave Cridland 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 
> 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.

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 mailing list