anotherim-desktop/libdino/src/service/connection_manager.vala

314 lines
11 KiB
Vala
Raw Normal View History

2017-03-02 14:37:32 +00:00
using Gee;
using Xmpp;
using Dino.Entities;
namespace Dino {
public class ConnectionManager {
public signal void stream_opened(Account account, XmppStream stream);
2017-03-02 14:37:32 +00:00
public signal void connection_state_changed(Account account, ConnectionState state);
public signal void connection_error(Account account, ConnectionError error);
2017-03-02 14:37:32 +00:00
public enum ConnectionState {
CONNECTED,
CONNECTING,
DISCONNECTED
}
private ArrayList<Account> connection_todo = new ArrayList<Account>(Account.equals_func);
private HashMap<Account, Connection> connections = new HashMap<Account, Connection>(Account.hash_func, Account.equals_func);
private HashMap<Account, ConnectionError> connection_errors = new HashMap<Account, ConnectionError>(Account.hash_func, Account.equals_func);
Move to GNetworkMonitor (#236) * Move to GNetworkMonitor Dino currently talks to NetworkManager over DBus to know the state of the network. That doesn't work in a Flatpak sandbox by default though, because Flatpak filters DBus communications and only allows a very small set of things to pass (which are known to be safe). Gio provides an API to know the state of the network (and be notified of changes via a signal): GNetworkMonitor. And GNetworkMonitor works both inside a Flatpak sandbox, and in traditional builds. (in Flatpak it uses what we call a "portal", which are the clean, safe way to let apps exit their sandbox) Fixes #235 * Don't check for network connectivity for now The connectivity check really is the correct thing to do: * network_available means that the computer has network routes to "somewhere". That is, it is connected to a router. * connectivity.FULL means that the computer can access "the Internet". That is, if it is behind a router, that router is connected. As a result, only checking for network_available is not correct. Unfortunately, NetworkManager tends to wait a long time before checking for connectivity. As a result, it is possible that a transient network error leaves NetworkManager thinking that network_available is true but connectivity!=FULL, and it will wait several minutes before realizing that the Internet connexion did come back. During that time, apps checking for connectivity (e.g the whole GNOME desktop) will think they don't have access to the Internet, while apps that don't (e.g Firefox) will access the Internet just fine. Users are understandably confused when that happens. Removing the check for connectivity is an acceptable trade-off in the short-term, until this situation is improved on the NetworkManager side. https://bugzilla.gnome.org/show_bug.cgi?id=792240
2018-01-09 19:39:45 +00:00
private NetworkMonitor? network_monitor;
2017-03-02 14:37:32 +00:00
private Login1Manager? login1;
private ModuleManager module_manager;
2017-04-03 13:09:30 +00:00
public string? log_options;
2017-03-02 14:37:32 +00:00
public class ConnectionError {
public enum Source {
CONNECTION,
SASL,
2018-01-04 20:13:44 +00:00
TLS,
STREAM_ERROR
}
2018-01-04 20:13:44 +00:00
public enum Reconnect {
NOW,
LATER,
NEVER
}
public Source source;
public string? identifier;
2018-01-04 20:13:44 +00:00
public Reconnect reconnect_recomendation { get; set; default=Reconnect.NOW; }
public bool resource_rejected = false;
public ConnectionError(Source source, string? identifier) {
this.source = source;
this.identifier = identifier;
}
}
2017-03-02 14:37:32 +00:00
private class Connection {
public XmppStream stream { get; set; }
2017-03-02 14:37:32 +00:00
public ConnectionState connection_state { get; set; default = ConnectionState.DISCONNECTED; }
public DateTime established { get; set; }
public DateTime last_activity { get; set; }
public class Connection(XmppStream stream, DateTime established) {
2017-03-02 14:37:32 +00:00
this.stream = stream;
this.established = established;
}
}
public ConnectionManager(ModuleManager module_manager) {
this.module_manager = module_manager;
Move to GNetworkMonitor (#236) * Move to GNetworkMonitor Dino currently talks to NetworkManager over DBus to know the state of the network. That doesn't work in a Flatpak sandbox by default though, because Flatpak filters DBus communications and only allows a very small set of things to pass (which are known to be safe). Gio provides an API to know the state of the network (and be notified of changes via a signal): GNetworkMonitor. And GNetworkMonitor works both inside a Flatpak sandbox, and in traditional builds. (in Flatpak it uses what we call a "portal", which are the clean, safe way to let apps exit their sandbox) Fixes #235 * Don't check for network connectivity for now The connectivity check really is the correct thing to do: * network_available means that the computer has network routes to "somewhere". That is, it is connected to a router. * connectivity.FULL means that the computer can access "the Internet". That is, if it is behind a router, that router is connected. As a result, only checking for network_available is not correct. Unfortunately, NetworkManager tends to wait a long time before checking for connectivity. As a result, it is possible that a transient network error leaves NetworkManager thinking that network_available is true but connectivity!=FULL, and it will wait several minutes before realizing that the Internet connexion did come back. During that time, apps checking for connectivity (e.g the whole GNOME desktop) will think they don't have access to the Internet, while apps that don't (e.g Firefox) will access the Internet just fine. Users are understandably confused when that happens. Removing the check for connectivity is an acceptable trade-off in the short-term, until this situation is improved on the NetworkManager side. https://bugzilla.gnome.org/show_bug.cgi?id=792240
2018-01-09 19:39:45 +00:00
network_monitor = GLib.NetworkMonitor.get_default();
if (network_monitor != null) {
network_monitor.network_changed.connect(on_network_changed);
network_monitor.notify["connectivity"].connect(on_network_changed);
2017-03-02 14:37:32 +00:00
}
login1 = get_login1();
if (login1 != null) {
login1.PrepareForSleep.connect(on_prepare_for_sleep);
}
Timeout.add_seconds(60, () => {
foreach (Account account in connection_todo) {
2018-01-04 20:13:44 +00:00
if (connections[account].last_activity != null &&
connections[account].last_activity.compare(new DateTime.now_utc().add_minutes(-1)) < 0) {
check_reconnect(account);
}
}
return true;
});
2017-03-02 14:37:32 +00:00
}
public XmppStream? get_stream(Account account) {
if (get_state(account) == ConnectionState.CONNECTED) {
return connections[account].stream;
2017-03-02 14:37:32 +00:00
}
return null;
}
public ConnectionState get_state(Account account) {
if (connections.has_key(account)){
return connections[account].connection_state;
2017-03-02 14:37:32 +00:00
}
return ConnectionState.DISCONNECTED;
}
public ConnectionError? get_error(Account account) {
if (connection_errors.has_key(account)) {
return connection_errors[account];
}
return null;
}
2017-03-02 14:37:32 +00:00
public ArrayList<Account> get_managed_accounts() {
return connection_todo;
}
public XmppStream? connect(Account account) {
2017-03-02 14:37:32 +00:00
if (!connection_todo.contains(account)) connection_todo.add(account);
if (!connections.has_key(account)) {
2017-03-02 14:37:32 +00:00
return connect_(account);
} else {
check_reconnect(account);
}
return null;
}
public void make_offline_all() {
foreach (Account account in connection_todo) {
make_offline(account);
}
}
private void make_offline(Account account) {
Xmpp.Presence.Stanza presence = new Xmpp.Presence.Stanza();
presence.type_ = Xmpp.Presence.Stanza.TYPE_UNAVAILABLE;
2017-03-02 14:37:32 +00:00
change_connection_state(account, ConnectionState.DISCONNECTED);
2017-11-06 00:02:13 +00:00
connections[account].stream.get_module(Presence.Module.IDENTITY).send_presence(connections[account].stream, presence);
}
public void disconnect(Account account) {
make_offline(account);
try {
connections[account].stream.disconnect();
} catch (Error e) { print(@"on_prepare_for_sleep error $(e.message)\n"); }
connection_todo.remove(account);
if (connections.has_key(account)) {
connections.unset(account);
2017-03-02 14:37:32 +00:00
}
}
private XmppStream? connect_(Account account, string? resource = null) {
2017-09-26 15:01:06 +00:00
if (connections.has_key(account)) connections[account].stream.detach_modules();
connection_errors.unset(account);
2017-03-02 14:37:32 +00:00
if (resource == null) resource = account.resourcepart;
XmppStream stream = new XmppStream();
foreach (XmppStreamModule module in module_manager.get_modules(account, resource)) {
2017-03-02 14:37:32 +00:00
stream.add_module(module);
}
stream.log = new XmppLog(account.bare_jid.to_string(), log_options);
2017-03-02 14:37:32 +00:00
2017-08-31 16:40:58 +00:00
Connection connection = new Connection(stream, new DateTime.now_utc());
connections[account] = connection;
2017-03-02 14:37:32 +00:00
change_connection_state(account, ConnectionState.CONNECTING);
2017-08-12 21:14:50 +00:00
stream.attached_modules.connect((stream) => {
2017-03-02 14:37:32 +00:00
change_connection_state(account, ConnectionState.CONNECTED);
});
stream.get_module(PlainSasl.Module.IDENTITY).received_auth_failure.connect((stream, node) => {
2018-01-04 20:13:44 +00:00
set_connection_error(account, new ConnectionError(ConnectionError.Source.SASL, null));
change_connection_state(account, ConnectionState.DISCONNECTED);
});
stream.received_node.connect(() => {
connections[account].last_activity = new DateTime.now_utc();
});
2017-11-11 20:29:13 +00:00
connect_async.begin(account, stream);
2017-03-02 14:37:32 +00:00
stream_opened(account, stream);
return stream;
}
private async void connect_async(Account account, XmppStream stream) {
2017-11-11 20:29:13 +00:00
try {
yield stream.connect(account.domainpart);
} catch (Error e) {
stderr.printf("Stream Error: %s\n", e.message);
change_connection_state(account, ConnectionState.DISCONNECTED);
if (!connection_todo.contains(account)) {
connections.unset(account);
return;
}
if (e is IOStreamError.TLS) {
2018-01-04 20:13:44 +00:00
set_connection_error(account, new ConnectionError(ConnectionError.Source.TLS, e.message) { reconnect_recomendation=ConnectionError.Reconnect.NEVER});
return;
}
2017-11-11 20:29:13 +00:00
StreamError.Flag? flag = stream.get_flag(StreamError.Flag.IDENTITY);
if (flag != null) {
2018-01-04 20:13:44 +00:00
set_connection_error(account, new ConnectionError(ConnectionError.Source.STREAM_ERROR, flag.error_type) { resource_rejected=flag.resource_rejected });
2017-11-11 20:29:13 +00:00
}
interpret_connection_error(account);
}
}
private void interpret_connection_error(Account account) {
ConnectionError? error = connection_errors[account];
int wait_sec = 5;
if (error == null) {
wait_sec = 3;
2018-01-04 20:13:44 +00:00
} else if (error.source == ConnectionError.Source.STREAM_ERROR) {
if (error.resource_rejected) {
connect_(account, account.resourcepart + "-" + random_uuid());
return;
}
2018-01-04 20:13:44 +00:00
switch (error.reconnect_recomendation) {
case ConnectionError.Reconnect.NOW:
wait_sec = 5; break;
2018-01-04 20:13:44 +00:00
case ConnectionError.Reconnect.LATER:
wait_sec = 60; break;
2018-01-04 20:13:44 +00:00
case ConnectionError.Reconnect.NEVER:
return;
}
} else if (error.source == ConnectionError.Source.SASL) {
return;
}
Move to GNetworkMonitor (#236) * Move to GNetworkMonitor Dino currently talks to NetworkManager over DBus to know the state of the network. That doesn't work in a Flatpak sandbox by default though, because Flatpak filters DBus communications and only allows a very small set of things to pass (which are known to be safe). Gio provides an API to know the state of the network (and be notified of changes via a signal): GNetworkMonitor. And GNetworkMonitor works both inside a Flatpak sandbox, and in traditional builds. (in Flatpak it uses what we call a "portal", which are the clean, safe way to let apps exit their sandbox) Fixes #235 * Don't check for network connectivity for now The connectivity check really is the correct thing to do: * network_available means that the computer has network routes to "somewhere". That is, it is connected to a router. * connectivity.FULL means that the computer can access "the Internet". That is, if it is behind a router, that router is connected. As a result, only checking for network_available is not correct. Unfortunately, NetworkManager tends to wait a long time before checking for connectivity. As a result, it is possible that a transient network error leaves NetworkManager thinking that network_available is true but connectivity!=FULL, and it will wait several minutes before realizing that the Internet connexion did come back. During that time, apps checking for connectivity (e.g the whole GNOME desktop) will think they don't have access to the Internet, while apps that don't (e.g Firefox) will access the Internet just fine. Users are understandably confused when that happens. Removing the check for connectivity is an acceptable trade-off in the short-term, until this situation is improved on the NetworkManager side. https://bugzilla.gnome.org/show_bug.cgi?id=792240
2018-01-09 19:39:45 +00:00
if (network_is_online()) {
wait_sec = 30;
2017-03-02 14:37:32 +00:00
}
print(@"recovering in $wait_sec\n");
Timeout.add_seconds(wait_sec, () => {
check_reconnect(account);
2017-03-02 14:37:32 +00:00
return false;
});
}
private void check_reconnects() {
foreach (Account account in connection_todo) {
check_reconnect(account);
}
}
private void check_reconnect(Account account) {
bool acked = false;
XmppStream stream = connections[account].stream;
stream.get_module(Xep.Ping.Module.IDENTITY).send_ping(stream, account.bare_jid.domain_jid, (stream) => {
acked = true;
change_connection_state(account, ConnectionState.CONNECTED);
});
2017-03-02 14:37:32 +00:00
Timeout.add_seconds(5, () => {
if (connections[account].stream != stream) return false;
if (acked) return false;
2017-03-02 14:37:32 +00:00
change_connection_state(account, ConnectionState.DISCONNECTED);
try {
connections[account].stream.disconnect();
2017-03-02 14:37:32 +00:00
} catch (Error e) { }
connect_(account);
2017-03-02 14:37:32 +00:00
return false;
});
}
Move to GNetworkMonitor (#236) * Move to GNetworkMonitor Dino currently talks to NetworkManager over DBus to know the state of the network. That doesn't work in a Flatpak sandbox by default though, because Flatpak filters DBus communications and only allows a very small set of things to pass (which are known to be safe). Gio provides an API to know the state of the network (and be notified of changes via a signal): GNetworkMonitor. And GNetworkMonitor works both inside a Flatpak sandbox, and in traditional builds. (in Flatpak it uses what we call a "portal", which are the clean, safe way to let apps exit their sandbox) Fixes #235 * Don't check for network connectivity for now The connectivity check really is the correct thing to do: * network_available means that the computer has network routes to "somewhere". That is, it is connected to a router. * connectivity.FULL means that the computer can access "the Internet". That is, if it is behind a router, that router is connected. As a result, only checking for network_available is not correct. Unfortunately, NetworkManager tends to wait a long time before checking for connectivity. As a result, it is possible that a transient network error leaves NetworkManager thinking that network_available is true but connectivity!=FULL, and it will wait several minutes before realizing that the Internet connexion did come back. During that time, apps checking for connectivity (e.g the whole GNOME desktop) will think they don't have access to the Internet, while apps that don't (e.g Firefox) will access the Internet just fine. Users are understandably confused when that happens. Removing the check for connectivity is an acceptable trade-off in the short-term, until this situation is improved on the NetworkManager side. https://bugzilla.gnome.org/show_bug.cgi?id=792240
2018-01-09 19:39:45 +00:00
private bool network_is_online() {
/* FIXME: We should also check for connectivity eventually. For more
* details on why we don't do it for now, see:
*
* - https://github.com/dino/dino/pull/236#pullrequestreview-86851793
* - https://bugzilla.gnome.org/show_bug.cgi?id=792240
*/
return network_monitor != null && network_monitor.network_available;
}
private void on_network_changed() {
if (network_is_online()) {
print("network online\n");
2017-03-02 14:37:32 +00:00
check_reconnects();
} else {
Move to GNetworkMonitor (#236) * Move to GNetworkMonitor Dino currently talks to NetworkManager over DBus to know the state of the network. That doesn't work in a Flatpak sandbox by default though, because Flatpak filters DBus communications and only allows a very small set of things to pass (which are known to be safe). Gio provides an API to know the state of the network (and be notified of changes via a signal): GNetworkMonitor. And GNetworkMonitor works both inside a Flatpak sandbox, and in traditional builds. (in Flatpak it uses what we call a "portal", which are the clean, safe way to let apps exit their sandbox) Fixes #235 * Don't check for network connectivity for now The connectivity check really is the correct thing to do: * network_available means that the computer has network routes to "somewhere". That is, it is connected to a router. * connectivity.FULL means that the computer can access "the Internet". That is, if it is behind a router, that router is connected. As a result, only checking for network_available is not correct. Unfortunately, NetworkManager tends to wait a long time before checking for connectivity. As a result, it is possible that a transient network error leaves NetworkManager thinking that network_available is true but connectivity!=FULL, and it will wait several minutes before realizing that the Internet connexion did come back. During that time, apps checking for connectivity (e.g the whole GNOME desktop) will think they don't have access to the Internet, while apps that don't (e.g Firefox) will access the Internet just fine. Users are understandably confused when that happens. Removing the check for connectivity is an acceptable trade-off in the short-term, until this situation is improved on the NetworkManager side. https://bugzilla.gnome.org/show_bug.cgi?id=792240
2018-01-09 19:39:45 +00:00
print("network offline\n");
2017-03-02 14:37:32 +00:00
foreach (Account account in connection_todo) {
change_connection_state(account, ConnectionState.DISCONNECTED);
}
}
}
private void on_prepare_for_sleep(bool suspend) {
foreach (Account account in connection_todo) {
change_connection_state(account, ConnectionState.DISCONNECTED);
}
if (suspend) {
print("suspend\n");
foreach (Account account in connection_todo) {
Xmpp.Presence.Stanza presence = new Xmpp.Presence.Stanza();
presence.type_ = Xmpp.Presence.Stanza.TYPE_UNAVAILABLE;
try {
connections[account].stream.get_module(Presence.Module.IDENTITY).send_presence(connections[account].stream, presence);
connections[account].stream.disconnect();
2017-03-02 14:37:32 +00:00
} catch (Error e) { print(@"on_prepare_for_sleep error $(e.message)\n"); }
}
} else {
print("un-suspend\n");
check_reconnects();
}
}
private void change_connection_state(Account account, ConnectionState state) {
if (connections.has_key(account)) {
connections[account].connection_state = state;
connection_state_changed(account, state);
}
}
2018-01-04 20:13:44 +00:00
private void set_connection_error(Account account, ConnectionError error) {
connection_errors[account] = error;
connection_error(account, error);
2017-03-02 14:37:32 +00:00
}
}
}