[Standards-JIG] The Ack Hack.
dave at cridland.net
Tue May 9 18:44:04 UTC 2006
On Tue May 9 17:56:20 2006, Pavel Šimerda wrote:
> Alright, so...
> As far as I know.... peple like Justin's jep-ack more. it's
> simpler... it's just as reliable.
It's certainly simpler, and correspondingly both less reliable and
> Dave's proposal have some very nice ideas - like reducing packet
> count (piggy-backing acks). And it handles reconnection without
> duplicate messages. (Though it could be handled even with jep-ack.)
No, there's no reconnection support in JEP-ACK.
To put that in, you'd need to maintain a count of all stanzas
transmitted and received - that in itself isn't a problem, but it's
increasingly tending toward a strictly increasing sequence number
that's implicitly carried in sent stanzas and explicitly carried in
acks. It's slightly harder to deal with (you need to carry the count
strictly over various stream restarts, for instance), and perhaps
most importantly, it's harder to debug if there's an error counting.
But assuming that such changes were made, the two proposals would be
almost functionally identical, and the differences between my
proposal and JEP-ACK would then be:
1) JEP-ACK doesn't modify stanzas between hops.
My proposal requires that at least the top-level element is rewritten
before forwarding - I didn't think this was a problem at all. If it
really is, I can redesign it to use additional stanzas pipelined with
existing sends, but it'll look a lot messier.
2) JEP-ACK uses more packets, as acking a stanzas needs to be done as
soon as possible.
My proposal allows for acks to piggy-back onto stanzas, and is more
"lazy", relying on solicited acks and reconnection handling for
connection failure detection and handling, which should yield not
only fewer packets and less data, but also better throughput.
As it happens, this laziness decreases reliability in the case where
the connection is lost and no reconnection is possible before the
receiver discards the reconnection data. Quite a few of the use-cases
for this - such as battery exhaustion - don't seem to have any valid
remedy, though. Any others appear to be limited by time, and I
believe that keeping the reconnection data for an hour won't be
difficult. (If a connection is closed cleanly, there's nothing to
keep at all, of course.)
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