[Bug 41148] NM: better handling of connectivity changes

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41148

--- Comment #3 from Will Thompson <will.thompson at collabora.co.uk> ---
I've been thinking about this, and I think the right way to do this is within
the CM. The CM knows which interface it's using to connect to the network,
whereas MC would have to guess or ask.

GNetworkMonitor currently only monitors which routes are available (using
netlink's RTM_NEWROUTE, RTM_DELROUTE, RTM_GETROUTE messages—see man 7
rtnetlink). This isn't enough to determine that your wired network, and hence
your XMPP connection, is dead when your wireless is still up.

You can determine the source (local) IP address used by a socket with
g_socket_get_local_address(), and you can monitor which IP addresses the system
currently has with netlink's RTM_NEWADDR, RTM_DELADDR, RTM_GETADDR messages.
So, combining the two, the CM could forcibly close its socket after the
socket's source IP is lost.

I believe this should cope with the case where two interfaces have the same IP
address (Rob has, since his Empathy bug report, hacked the office DHCP server
to assign him the same IP address on wired and wireless, which I /think/ makes
his connections not break when he docks and undocks). I'm not sure how VPNs
look.

Rather than forcibly closing the socket immediately, it could send a ping with
a relatively short timeout. This would avoid killing connections unnecessarily
if you unplug your wire for just a moment, and might make bugs in this code
less disastrous. However, it would mean that the following scenario would still
not work:

• Undock your laptop;
• Send an IM to say “I'll be there in 5 minutes”;
• And then the ping times out, your connection dies, and your message has been
lost.

On XMPP, XEP-0198 is one answer to that—and a big advantage of having the CM do
this kind of connectivity monitoring is that it would be possible for
Gabble/Wocky to resume the stream and resend stanzas as necessary, without
having to signal to MC and the user that the connection bounced.

(A half-way house would be to have the CM send a ping in response to
GNetworkMonitor::network-changed, and blow up if it doesn't get a reply.)

This is /way/ simpler than having MC watch which interfaces are active, guess
which one the CM is using (or have API for the CM to tell MC), etc etc.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.