[Standards-JIG] The Ack Hack.

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Wed May 10 06:15:54 UTC 2006


On Tuesday 09 May 2006 11:44, Dave Cridland wrote:
> 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.

Sorry to not have replied about this topic yet, I've been really swamped with 
stuff.

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.

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? :)

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.

I'm not opposed to the sequencing stuff, although I'm not convinced it is 
necessary in the casual case.

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

-Justin



More information about the Standards mailing list