[Standards-JIG] Re: The Ack Hack.

Richard Dobson richard at dobson-i.net
Wed May 10 18:04:04 UTC 2006


>> personally I think that as soon as a connection is detected by the
>> server as being dead (using the acks) that the particular user in
>> question should immediately go offline rather than buffering the traffic
>> and giving the user a couple of minutes to reconnect.
> 
> It sounds like you don't want reliable delivery at all, but would be happy
> with fast disconnection detection, which can (and is) already be done with
> whitespace pings.

Huh? Im confused, how does what I said indicate I do not want reliable 
delivery? The reliable delivery that we are talking about here is 
knowing whether your stanzas are delivered or not which at the moment we 
dont, as they can just end up dropping into a blackhole, whats wrong 
with making the client session immediately go offline (just as if they 
had gracefully disconnected)? when the connection is detected as dead, 
and when this happens any non-acked stanzas would be bounced back to the 
sender, rather than being just lost in the ether as they are now.

David wants to add in a mechanism of quick reconnection without needing 
to send/receive all the traffic you normally would do when connecting 
(i.e. roster list, presences, messages etc), but to accomplish this the 
user would have to appear to remain online to the outside world (even 
though the server has detected already that they arnt) during the period 
in which you will allow them to quickly reconnect (after which time they 
would need to perform a normal full login), which would probably be in 
the magnitude of a couple of minutes, but this is a potensial problem 
because it exaserbates the problem we already have with zombie/ghost 
sessions left open for a period of time.

I would suggest rather than introducing the problems and complexity that 
having a quick reconnect mechanism of this sort creates that we aim to 
reduce the overall traffic required at login instead. By having things 
like a roster retreival protocol where you can get just the changes that 
have happened to the roster since you last retreived it (as has been 
discussed recently already), im sure for the people with large rosters 
that it would be a great help. This also benefits a wider range of users 
as it will be applicable whenever they connect, not just when their 
connection has failed and they have to re-connect.

Richard




More information about the Standards mailing list