Network disconnects on SkyDolly exit

[PaulH123455]

Every time I exit SkyDolly my network disconnects for about a minute or more. I happens every time. It even happened when I ran it without MSFS running. Any ideas why this is.

[till213]

Hello Paul,

Thank you for raising this issue.

In short: I have no idea. The only network-related operation that Sky Dolly initiates is when you open the online documentation - and even then Sky Dolly is simply asking the operating system to open the given URL (https://till213.github.io/SkyDolly/) with your default browser (so Sky Dolly is not even creating the network connection itself).

The only other (far-fetched) idea that I have is that you can configure the underlying SimConnect protocol to be networked: the default SimConnect settings (that if, if none are present - see later) assume that the SimConnect server (= MSFS) is running on the same machine like the SimConnect client (= Sky Dolly in this case), and the connection is made via some local "pipe" (a Named Pipe, to be specific: think of a "pipe" as some "special kind of file").

But one can configure SimConnect to run over some TCP (or UDP) network connection as well: the client (Sky Dolly) on one machine, the server (MSFS) on another machine (on a side note: this is "Windows to Windows" only - no Linux/Mac and specifically no Xbox support).

Client-side this is configured with some SimConnect.cfg configuration file. The server (MSFS) must also be configured to accept such network requests, with some SimConnect.xml configuration file (why is one some CFG and the other some XML format? Yeah, whatever... ;)).

To be clear: Sky Dolly does not setup (create) or change any such configuration files: it will use the default settings, the named pipe approach, that is.

But it is theoretically possible that some other addons (possibly some that you had installed years ago, in th times of FS X, for example - assuming you have your Windows installation running for all this time, that is ;)). Such settings can even be made "system-wide", specifically for the client part.

This would be bad practise, of coursee. But one Sky Dolly user reported that he couldn't launch Sky Dolly - turned out some other addon had indeed installed some SimConnect.cfg in his system-wide c:\Windows folder (!), or some sub-folder thereof. In fact, not a single SimConnect client (not even the example SimVar Watcher example application that comes with the MSFS SDK) would launch on his system.

But as you say that your network connection gets "disconnected" (what does that even mean? Do you loose your WiFi connection to your router? You cannot access the internet anymore? Or some network share is unreachable?) even when you do not launch MSFS I assume you also do not load any flight in Sky Dolly. That would mean that Sky Dolly is not even making any attempt to connect to MSFS (via SimConnect - "networked" or via the default named pipe) - so we can probably also rule out this "some random SimConnect.cfg inexplicably messes around with your network" scenario...

But even if you had this scenario: "disconnecting" your network would either mean that one would actually acess some specific operating system settings such as your WiFi settings (neither Sky Dolly nor any related SimConnect funtionality does that) - or generate such "I/O traffic" that your operating system goes berserk (specifically your network TCP/IP stack, or whatever).

The only file I/O that Sky Dolly does when launched is to open a single file, the logbook: it opens this file in read/write mode (actually: the underlying SQLite database is opening (and closing) that file: SQLite is a file-based database used by litteraly ten-thousands of apps, even on iOS and Android etc. - so you bet it is well-tested).

But even if we would assume that you had your logbook on some network share (which by the way I do not recommend: SQLite assumes that file operations are more or less "instant" and properly "flushed" - however some network file protocols could interfere here and you could - theoretically - loose some "database transactions") I would still consider this some kind of weird "network stack/wifi card driver" glitch.

As you see my theories become more and more far-fetched. I have absolutely no idea how an ordinary desktop-application like Sky Dolly could cause your network connection to drop for one minute, after closing the application. Even when closing the database (again, some ordinary file on your file system) could theoretically bring your I/O system "into a stressful situation" this would indicate some very bad setup of your operating system (perhaps caused by some other processes that are running on your system - some virus scanner perhaps?).

Unless you provide some other evidence that could help us linking Sky Dolly with your network issue and track the root cause I will close this issue within a few days.

You could, for example, use some network sniffer application like WireShark and try to detect the last network packets that leave / enter your network interface, and try to associate them with the application that is sending / receiving them). Or you could observe other processes that perhaps try to access the Sky Dolly logbook file (after Sky Dolly has closed) and cause mayhem on your Windows I/O system (sometimes some process can indeed lower the performance of your I/O, including network I/O - but typically only when "swamping" your system with millions of I/O requests). Or anything else that might bring your system (specifically: your network interface) onto its knees).

Or simply try to update your network interface driver ;)

[till213]

As for the SimConnect network part, have a look here:

For the server (MSFS): https://docs.flightsimulator.com/html/Programming_Tools/SimConnect/SimConnect_XML_Definition.htm

For the client (e.g. Sky Dolly): https://docs.flightsimulator.com/html/Programming_Tools/SimConnect/SimConnect_CFG_Definition.htm

Again, this is standard functionality of SimConnect and not Sky Dolly-specific. And Sky Dolly does not create / change such configuration files itself. But it may help you find any "network-related" functionality in that official documentation that might explain your network outage. And to repeat as well, I expect this (SimConnect.cfg causing network issues) to be extremely unlikely: no ordinary "desktop application" (not interacting with any system-specific settings API, that is, or be otherwise embedded "deep into the system", like some hardware driver) should be able to bring down your network when doing "normal file / network I/O", let alone cause some "disconnect".

[PaulH123455]

Hello Paul,

Thank you for raising this issue.

In short: I have no idea. The only network-related operation that Sky Dolly initiates is when you open the online documentation - and even then Sky Dolly is simply asking the operating system to open the given URL (https://till213.github.io/SkyDolly/) with your default browser (so Sky Dolly is not even creating the network connection itself).

The only other (far-fetched) idea that I have is that you can configure the underlying SimConnect protocol to be networked: the default SimConnect settings (that if, if none are present - see later) assume that the SimConnect server (= MSFS) is running on the same machine like the SimConnect client (= Sky Dolly in this case), and the connection is made via some local "pipe" (a Named Pipe, to be specific: think of a "pipe" as some "special kind of file").

But one can configure SimConnect to run over some TCP (or UDP) network connection as well: the client (Sky Dolly) on one machine, the server (MSFS) on another machine (on a side note: this is "Windows to Windows" only - no Linux/Mac and specifically no Xbox support).

Client-side this is configured with some SimConnect.cfg configuration file. The server (MSFS) must also be configured to accept such network requests, with some SimConnect.xml configuration file (why is one some CFG and the other some XML format? Yeah, whatever... ;)).

To be clear: Sky Dolly does not setup (create) or change any such configuration files: it will use the default settings, the named pipe approach, that is.

But it is theoretically possible that some other addons (possibly some that you had installed years ago, in th times of FS X, for example - assuming you have your Windows installation running for all this time, that is ;)). Such settings can even be made "system-wide", specifically for the client part.

This would be bad practise, of coursee. But one Sky Dolly user reported that he couldn't launch Sky Dolly - turned out some other addon had indeed installed some SimConnect.cfg in his system-wide c:\Windows folder (!), or some sub-folder thereof. In fact, not a single SimConnect client (not even the example SimVar Watcher example application that comes with the MSFS SDK) would launch on his system.

But as you say that your network connection gets "disconnected" (what does that even mean? Do you loose your WiFi connection to your router? You cannot access the internet anymore? Or some network share is unreachable?) even when you do not launch MSFS I assume you also do not load any flight in Sky Dolly. That would mean that Sky Dolly is not even making any attempt to connect to MSFS (via SimConnect - "networked" or via the default named pipe) - so we can probably also rule out this "some random SimConnect.cfg inexplicably messes around with your network" scenario...

But even if you had this scenario: "disconnecting" your network would either mean that one would actually acess some specific operating system settings such as your WiFi settings (neither Sky Dolly nor any related SimConnect funtionality does that) - or generate such "I/O traffic" that your operating system goes berserk (specifically your network TCP/IP stack, or whatever).

The only file I/O that Sky Dolly does when launched is to open a single file, the logbook: it opens this file in read/write mode (actually: the underlying SQLite database is opening (and closing) that file: SQLite is a file-based database used by litteraly ten-thousands of apps, even on iOS and Android etc. - so you bet it is well-tested).

But even if we would assume that you had your logbook on some network share (which by the way I do not recommend: SQLite assumes that file operations are more or less "instant" and properly "flushed" - however some network file protocols could interfere here and you could - theoretically - loose some "database transactions") I would still consider this some kind of weird "network stack/wifi card driver" glitch.

As you see my theories become more and more far-fetched. I have absolutely no idea how an ordinary desktop-application like Sky Dolly could cause your network connection to drop for one minute, after closing the application. Even when closing the database (again, some ordinary file on your file system) could theoretically bring your I/O system "into a stressful situation" this would indicate some very bad setup of your operating system (perhaps caused by some other processes that are running on your system - some virus scanner perhaps?).

Unless you provide some other evidence that could help us linking Sky Dolly with your network issue and track the root cause I will close this issue within a few days.

You could, for example, use some network sniffer application like WireShark and try to detect the last network packets that leave / enter your network interface, and try to associate them with the application that is sending / receiving them). Or you could observe other processes that perhaps try to access the Sky Dolly logbook file (after Sky Dolly has closed) and cause mayhem on your Windows I/O system (sometimes some process can indeed lower the performance of your I/O, including network I/O - but typically only when "swamping" your system with millions of I/O requests). Or anything else that might bring your system (specifically: your network interface) onto its knees).

Or simply try to update your network interface driver ;)

Thanks till213 for comprehensive response. Even though I've done lots of unix dev and used Wireshark loads I don't really want to delve in too deep. I was really pointing it out TBH and wondered if I'd configured it wrong. Basically it seems to knock out my WIFI as both my PC and MAC just hang (eg streamed content freezes). But it's guaranteed to happen when I exit SkyDolly. I don't know if the WIFI disconnects or something saturates or hogs it for a minute. Like I say, I'm not too worried about it but just sharing what I've seen. It's a great product BTW. I know it doesn't work 100% with aircraft like Fenix A320 which I fly i.e I get the sticking spoilers and reverse thrust but still good to review my landings.

[till213]

Hi Paul,

thank you for your reply.

Well, I wasn‘t seriously suggesting to investigate your network traffic with something like Wireshark - I simply expressed my absolute ignorance about what could possibly cause „heavy I/O for one minute“ that would bring down your network traffic, or even cause an entire disconnect from your network.

The only I/O traffic that Sky Dolly does when starting and immediately closing it is:

• Accessing the „logbook“ (by default in your „Documents“ folder) file, via SQLite
• The Windows registry (search for „till213“ or „SkyDolly“ - that should reveal all registry entries (*)

(*) Yes, I know that storing „excessive app settings“ in the registry is not state of the art - I might deal with that later, e.g. some INI file or another separate SQLite „settings“ database

Sky Dolly is only trying to initiate a connection with MSFS „as needed“, e.g. when loading a flight (Sky Dolly tries to set the initial aircraft position and possibly spawn „AI aircaft“) or when pushing any „replay / record“ related buttons.

But as summarised above this happens via SimConnect and - by default - over a „named pipe“ (no TCP or UDP traffic that could later „block“ - somehow, inexplicably - your network).

To be clear: I absolutely believe what you say: it‘s just that I am absolutely clueless what could cause this. And needless to say that none of my devices (all via WiFi) ever showed such behaviour, neither on macOS, Linux nor (latest) Windows 10 (my iMac doesn‘t officially support Windows 11 ;)).

I tell you what: currently Sky Dolly uses the Qt framework 6.4. The upcoming Sky Dolly will use the latest Qt 6.5. I have little hope that this would change anything - but I am long enough in software engineering to confidently say „who knows“ ;)

I‘ll leave this issue open until then.

[PaulH123455]

Hi till213,

I updated SkyDolly to 0.16.2 yesterday and the freeze is no longer happening. Unfortunately I cannot remember the freeze version. The only bit of behaviour that's different is that on the freezing version, when I used to exit it would always prompt me about doing a backup of something, which I always dismissed (then the freeze would occur). However, for some reason this newer version doesn't prompt me. I don't know why or whether is has anything to do with the freeze. It is keeping all my flights though.

[till213]

So I guess we can close this issue then :)

Pay special attention to the earlier release notes (also made public on flightsim.to): the older v0.14 had introduced a regression that would cause logbook backups whenever Sky Dolly would launch.

So you may want to check your Sky Dolly logbook folder (c/Users/YourUser/Documents/Sky Dolly/) for excessive backuos (in the Backups subfolder).

Again, that‘s absolutely no explanation for your network disconnect - but glad it now seems to work for you!

[till213]

https://github.com/till213/SkyDolly/blob/main/CHANGELOG.md

The logbook backup bug was fixed in 0.15.1.

Btw you can control the backup periodicity in the logbook setting, in the File menu.