[Standards-JIG] The Ack Hack.

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


> 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.)

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