[Standards-JIG] The Ack Hack.

Dave Cridland dave at cridland.net
Wed May 10 08:05:47 UTC 2006

On Wed May 10 07:15:54 2006, Justin Karneges wrote:
> The lazy acking is neat, but I personally would rather opt for 
> immediate acking all the time.  This isn't because I'm sitting on a 
> nice broadband connection.  I'd want it on my GPRS connection, too. 
>  I'd want it there even more, actually.
Interesting - I have to deal with GPRS behaviour quite a bit, and I'd 
want to eliminate as much data, and as many packets, as possible, as 
long as I get the same result.

As things stand, you'd probably detect a failed connection slightly 
faster, but equally, with stronger reconnection support, I'd deal 
with it better.

Now as I said before, counting, in principle, should yield the same 
result, but after a couple of hundred stanzas, tracking down that 
off-by-one bug will be a nightmare.

> Maybe that's a sad irony of sorts.  On a reliable, high-bandwidth 
> connection, infrequent acking could be acceptable, and on a 
> unreliable, low-bandwidth connection immediate acking is desired.  
> Where are the unreliable, high-bandwidth connections when you need 
> them? :)
Right over there, in the box marked "NAT".

But you're correct in an important detail you've implied - we need to 
put the cost where it's most required, so we can have reasonably 
strong reliability without much additional cost, and the highest cost 
deals with the case where we really need that reliability - ie, when 
the connection has actually died.

> Fortunately, Dave's proposal provides a mechanism for explicitly 
> synchronizing the session, which can act as a substitute for 
> immediate acking.  However, if you were to do this after every 
> stanza then it would end up being more costly than JEP-Ack.
That's true, the intent was to provide a mechanism to use to probe 
the connection - it's a sort of ping or NOOP, which happens to be 
required to ack as well. It's not intended for use after every 
pipeline. Depending on the XML stanza size, though, it might not be 
significantly larger than JEP-ACK.

> If people want sequencing and lazy acks, then I propose folding 
> these changes into JEP-Ack (or redrafting a new JEP, either way), 
> so that everything is possible, including immediate acks, without 
> drawbacks (aside from added complexity...).

That works, I'm not proposing a competition between proposals, I'd 
rather everyone got a solid, quality protocol out of it. My proposal 
is absolutely not copyrighted, patented, etc. Most of it isn't even 
my idea. (Okay, it's not patented by me, and not patented to my 
knowledge by anyone else, but I haven't done a patent search of any 

I see two options for always-immediate-ack as an option:

1) Add yet another attribute to the stanza element, requesting an 
immediate ACK up to this stanza.

2) Have a switch to make the above the default.

You might as well have both.

           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