After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 659872 - deals terribly with changes in connectivity
deals terribly with changes in connectivity
Status: RESOLVED NOTGNOME
Product: empathy
Classification: Core
Component: General
3.1.x
Other Linux
: Normal major
: ---
Assigned To: empathy-maint
empathy-maint
Depends on:
Blocks:
 
 
Reported: 2011-09-22 20:19 UTC by robert
Modified: 2011-09-23 11:24 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description robert 2011-09-22 20:19:19 UTC
I'm not sure whether the best place to solve this is in Empathy or Telepathy, but I'm getting seriously frustrated with Empathy not noticing when we've changed network IPs. This means you can be offline, suspend, resume, come online with a different connection, or just choose a different network connection from the menu, and it can takes minutes for Empathy to deal with this and time out and retry and get your contacts back.

This seriously exacerbates bugs inherent like silently throwing messages away and not knowing if they've been delivered or not, etc etc. This is utterly infuriating. Any application on the system can tell if the system's IP has changed or the default gateway has changed, and Network Manager even gives us this through a nice D-Bus interface.

If our IP address and/or the default route has changed, we know for a fact that our TCP connections to our IM servers will all have been dropped so we should bounce them off and on from our end. We should of course do this when a connection comes /up/ so that if a connection temporarily goes away and comes back with the same IP, we don't cut connections un-necessarily - but similarly it might be nice to have the CMs send an explicit/more aggressive ping when connections go down so we actually time out within 30s or so, and don't provide the illusion of IM connectivity/presence if the uplink has actually gone away.

The only exception to this I can think of is if you have multiple interfaces, one to a local LAN with some local SIP/XMPP server, and one to the Internet where you have the rest of your IM servers. Handling this case correctly would either need each CM to monitor the system's connectivity to the servers it cares about (ie monitor the routing table with syslink?!) - this seems like a massive pain in the ass - or perhaps more easily to establish some account<->connection mapping so that you could lock some accounts to specific connections (would also make corporate VPN users happy) - or just keep that as a plan if anyone cares enough. The latter might argue in favour of moving connectivity tracking into Mission Control so that this equivalence can be tracked directly.

But wherever we do this, we should fix it. Maybe fix the obvious cases in Empathy first and file a wishlist bug on MC to do the fancier stuff.
Comment 1 Guillaume Desmottes 2011-09-23 07:48:57 UTC
We are moving connectivity checking to mission-control ( https://bugs.freedesktop.org/show_bug.cgi?id=38978 ), so this should be done there. We also have some plans to properly disconnect when we are about to get disconnected because of sleep ( https://bugs.freedesktop.org/show_bug.cgi?id=28370 ) and network changes (https://bugs.freedesktop.org/show_bug.cgi?id=40131 ).

But I'll do some tests and check if we can improve the network switching case for 3.2.
Comment 2 Guillaume Desmottes 2011-09-23 10:45:59 UTC
Ok, so the main issue here is that we are relying exclusively on NM_STATE changes to detect connectivity changes. This used to work fine when NM was keeping only one connection at a time as a drop of this connection resulted in a state change. But that's not the case since NM can now be connected to different connections at the same time (typically a wired and a wifi connection).

I'm working on a finer approach tracking the current active default connection. As Will is working on the same time on moving NM bits to MC, I suggest that I do this in Empathy (easier to test, etc) and then we'll move this logic to MC later once we are happy about it.
Comment 3 Guillaume Desmottes 2011-09-23 11:24:28 UTC
After dicussing this with Will, we agreed that it was easier to do this directly in MC has it already supports associating a connection/transport with an Account.

So I opened the following MC bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=41148
https://bugs.freedesktop.org/show_bug.cgi?id=41150