Socket errors

[Sean Egan]

On Nov 27, 2007 12:25 PM, Billy Crook <billycrook at gmail.com> wrote:
> The user can always, and has always been able recompile to adjust such
> timings, so it serves no purpose to retrain the user from adjusting
> them in a simple fashion.

I think the described "Reconnect" button is functionally equivalent to
user-specified reconnect timeouts. If the user wants to re-connect
more frequently, he can hit the button.

> One instant reconnect would be useful, say, when your wifi drops out
> and comes back, or say, your switch or router within your organization
> resets, and interrupts your connection.  You might still have a path
> to the server, just not the same path, so you'd need to re-establish
> the connection.

One instant reconnect would be harmful, say, when your corporate XMPP
server goes down, and can't get back up because all 5 thousand clients
are trying to re-connect simultaneously, essentially DOSing it. Right
now we have an 8 second to 1 minute hysteresis before reconnecting,
which may not be the finest tuned numbers, but is the right thing to
do. If you're actively using the client, you can manually reconnect
immediately, while all the people who are away and don't care about
re-connecting don't DDOS the server.

> Monitoring the route table /does/ seem a little beyond the scope of an
> IM client, I admit.  Perhaps there is a higher level API to detect
> changes, or something on dbus?

I think supporting Network Manager properly is the best way to go
about this. If Network Mangaer tracks this, we'll get it for free.