[Standards-JIG] The Ack Hack.
richard at dobson-i.net
Wed May 10 18:14:47 UTC 2006
>> Sure but if you read Dave's proposals he seems intent on including a
>> "quick reconnection" mechanism along with the reliable message delivery,
>> I was just commenting on how this is not really needed.
> No, he wasn't. He was introducing a way to know which messages actually
> arrived to the server and were not acked (after reconnect). This seems
> unrelated to the acking mechanism to me.
Urm well he certainly appears to have, I may have misunderstood but I
dont think I have, here are some quotes:
"4) Reconnection: A Receiver MAY store the highest sequence number it
has received when the connection fails, and present it to the Sender
upon reconnection. (Server in a stream feature, and Client in an iq?
That would eliminate a round-trip.)"
"c) When a new connection is made, transmit the last highest sequence
"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.)"
If I have misunderstood can you explain exactly what he means by his
reconnection stuff then?
More information about the Standards