Socket errors

[Ethan Blanton]

Billy Crook spake unto us the following wisdom:
> On Nov 27, 2007 1:16 PM, Stu Tomlinson <stu at nosnilmot.com> wrote:
> > On Tue, 2007-11-27 at 13:07 -0600, Billy Crook wrote:
> > > Sounds great, I can't wait.  How about an instant reconnect attempt
> > > though, followed by an exponential backoff to a user definable maximum
> > > retry interval?
> >
> > NO. No instant reconnect, and don't let the *user* define the maximum
> > retry interval. We have to consider the poor servers. Otherwise yes, we
> > have the reconnect & exponential backoff already and have done for quite
> > some time.
>
> 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.

Yes, it does -- most users who have the ability to find the constants
in the code and edit them know enough about computers and networks to
know that it's a bad idea to do so.  Not all, of course, and there are
non-programmers who will know as well, but it *does* serve as an
effective barrier to entry.

> 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 rapid reconnection (instant is almost always a bad idea, with
networks, for _practical_ reasons, network abuse aside) is probably
OK.  The default initial reconnection is between 8 and 60 seconds; I
could se reducing that to 1-5 seconds, and simply making sure that the
exponent on the backoff is larger.  (We do NOT want to try to connect
to the same server more often than every 30 seconds or so when
avoidable.)

> As for watching for route changes, a change in the default gateway
> would be a pretty good sign that your connections have all been
> severed, and will shortly begin to fail as they timeout.  During this
> period between severance, and timeout, however, you will miss incoming
> messages, and depending on protocol, be sending messages into a black
> hole.
> 
> 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?

We use Network Manager for this, on Linux -- which is in the messages
you replied to.  As mentioned, our support for it is disabled by
default due to bugs.  If someone stepped forward to figure that out,
we could enable it by default.

Ethan


-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20071127/eda63fce/attachment.sig>