[Standards-JIG] The Ack Hack.
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