Respond to Windows connectivity issues

[watfordjc]

The use of TCP means that the software will only become aware of a websocket connection no longer being usable due to a connectivity issue in the following circumstances:

• An exception is raised in response to an attempt to send a message through a socket or a timeout. IOException being the most likely.
• An assumption being made after so many seconds of not receiving an obs-websocket Heartbeat event (currently configured at 8 seconds).

The NetworkTest window tests the use of NetworkHelper at responding to connectivity change events.

NetworkConnectivityLevel2 contains the same values as Windows.Networking.Connectivity.NetworkConnectivityLevel, and only exists because I had trouble accessing the Enum in XAML. Those values being:

• None (no network connection)
• LocalAccess (network connection, but not Internet connectivity)
• ConstrainedInternetAccess ("limited" network connection, e.g. having an autoconfiguration IP address)
• InternetAccess (Internet should be working)

Unlike the NAudio library, where events propagate to sndvol/control panel at virtually the same time as they reach NAudioWrapperLibrary, the WinRT events for connectivity changes take a second or longer to reach NetworkHelper than the events that change the connectivity status icon/text in network settings and the system tray.

As I plan on making this application a "streaming connectivity hub", it should know the state of network connectivity without relying purely on I/O errors. As obs-websocket is currently the only thing being spoken to over the network (well, 127.0.0.1), there isn't much that could currently utilise connectivity state other than another indicator icon. ClientWebSocket does not expose the Ping websocket OpCode, and its default Options.KeepAliveInterval is 30 seconds (read-only after instantiation).

If there is a connectivity issue, ObsWsClient could send a request that has a small reply to test if obs-websocket is still reachable. When connectivity changes to InternetAccess exponential backoff could be reset to the minimum time between reconnections

As well as connectivity level, other things exposed by the API include connection type and whether it is a metered connection.

[watfordjc]

Windows 10 Bug in Network Location Awareness Service

Upon upgrading to version 2004 of Windows 10, the Windows system tray icon for networking (as well as the Network status page in Settings) said I had no Internet connectivity.

The NetworkTest.xaml window in this application claimed I only had LAN connectivity.

None of the solutions posted online worked, but after a full network settings reset (had to re-add my WPA2-Enterprise EAP-TLS Wi-Fi network after), and Killer Control Center updating itself from the Windows Store, the tray icon (NCSI - Network Connectivity Status Indicator) says I have Internet connectivity, although it is a bit spotty at times despite using Ethernet.

Potential Issues

Using the Windows API alone was not going to be the way I was going to do things anyway. It was more of a "hey, the status of the Internet connection has probably changed" event - something the Windows API annoyingly doesn't provide.

Given the issues have apparently been widespread on the current (and previous) versions of Windows 10, it might make sense to add an NCSI consistency check option to the application.

The settings for some of the checks performed by Network Location Awareness Service are stored in the registry. It shouldn't be too difficult to read those values and perform our own checks (DNS lookups, HTTP GET) using the same settings used by Windows and then compare our results with what the Windows API says our connectivity state is.

Relying solely on the API to determine network connectivity state and preventing functionality based on that state does not sound like a good idea on Windows.