Socket errors

Billy Crook billycrook at gmail.com
Tue Nov 27 15:25:57 EST 2007


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.

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.

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?

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.
>
> > I would also like some sort of smarts to pidgin so that when I change
> > networks in NetworkManager, it would sever all IM network connections,
> > and reconnect.  I guess that might be unnecessarily destructive in
> > some cases so how about I restate it.
>
> --enable-nm will do something like this, but it has some issues so is
> disabled by default.
>
> > When the route table changes in such a way that the route to an
> > account's server changes, -OR- when pidgin is randomly disconnected
> > without reason, that account should automatically disconnect and
> > reconnect (one time) as quickly as possible, then exponentially
> > backoff to a user definable maximum retry interval.
>
> I'm not sure we want to try to detect routing changes.
>
> Regards,
>
>
> Stu.
>
>
> _______________________________________________
> Devel mailing list
> Devel at pidgin.im
> http://pidgin.im/cgi-bin/mailman/listinfo/devel
>




More information about the Devel mailing list