[Standards-JIG] Re: The Ack Hack.
richard at dobson-i.net
Wed May 10 18:32:08 UTC 2006
> When a connection is lost uncleanly, the stanza can be delivered OK but
> the ack can be lost. You can't bounce the stanza if you haven't got the
> ack when the connection is lost, because you may bounce a stanza that was
> delivered OK. You need to re-connect and work out which stanzas were
> handled and which were not.
If you dont bounce the potensially unsent messages then its pretty
pointless even having the acks if you ask me as to the third party that
is sending this unreliable user a message they will still as now not
know if their messages where delivered or not, the whole point of acks
should be to allow everyone to know if their traffic was definately
delivered and if not then it should be bounced, its far better to end up
sending a second message (because the first appeared to bounce, even if
it was delivered) than to not re-send at all.
> This re-connection does not have to be "quick" - that's orthogonal to
> transactional consistency. I don't think it matters if the user appears to
> go offline during the reconnect interval: what we are interested in
> finding out is if they need to re-send their last few messages when they
> manage to get conected again, and we want to do this automatically instead
> of by people saying to each other "did you get my message before i went
Doing as you suggest at the top does not allow that to happen as you are
not bouncing the stanzas when they are not definately delivered, IMO if
a connection drops all un-acked stanza's should be bounced, it doesnt
matter if one of those was successfully sent before the receiver got a
chance to ack it.
More information about the Standards