[Standards-JIG] Re: The Ack Hack.
standards-jig at vicious.dropbear.id.au
Wed May 10 13:56:51 UTC 2006
On Wed, 10 May 2006, Richard Dobson wrote:
> Nope I was just commenting on Dave's proposal to include a "quick reconnect"
> mechanism along with the acks, and how it is not really required (and
> personally not really desired either), having quick reconnect as he suggests
> could result in even more instances of what are effectively ghost connections
> on the server, 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.
On re-reading Dave's proposal, nothing is mentioned about what the server
should do about the online/offline state of the JID between detecting a
disconnection and the presentation of a 'now where were we?' token from a
new connection. However, since offlining the JID will break various
things (eg, client thinking still part of chat room, chat room thinking
client has disconnected), the connection should not be continued if the
JID has been offlined in the interim.
Until someone implements a jabber version of screen(1), I like the idea of
my server being somewhat lazy about considering my connection to be truly
dead and reconnections (for instance, dropouts at poorly-configured
hotspots) being very quick.
> If connections are over
> connections that are this unreliable (that they keep getting disconnected
> every couple of minutes) maybe those clients should be connecting using
> JEP-0124 which wouldn't have this problem.
Theres also a subtle attack vector there depending on the size of the
buffer that the server keeps track of; all the eviluser has to do is to
ack at a much slower rate than the packets being sent. Eventually the
server will have an excessive number of buffered, un-acked packets,
particularly if multiple connections are doing this.
More information about the Standards