I have two Android devices connected with Syncthing. If I stop the app in one of them it almost immediately reports as Disconnected in the other one. But if I enter airplane mode instead, so that Syncthing stops itself because of a standard running condition, it keeps being reported as Up to date by the other device, until I restart the app in it, then it correctly reports Disconnected. Is this expected?
Edit: it eventually is reported as Disconnected but this may take a long time (15-20 minutes).
When you put your phone into flight mode, then no further network transmissions are possible. Thus the notification of Syncthing being shut down on the device won’t get through to the other one anymore. It will take some time until the other device notices that the connection is broken. Sorry this is just how networking works, if you “pull the plug” it needs to rely on a timeout.
There might be an advanced configuration option to shorten the interval between connection checks, I haven’t looked for it.
In this particular situation, it’s not the distance of the network path…
Especially on mobile devices, since it’s not unusual to frequently lose network connectivity or have low bandwidth due to poor wireless connections, the OS uses a process where network requests from apps are queued up instead of being outright rejected.
If the OS rejects a connection immediately, a typical smartphone going into airplane mode would light up with a flood of notifications from potentially dozens of apps that want to reach the network.
So in a sense, Syncthing isn’t aware that the phone has been put into airplane mode. It’s simply waiting for an acknowledgement for the network requests made. Until enough time has gone by without hearing from the other linked device, it doesn’t know the other device’s true status.
Here A has gone into airplane mobile. Suppose it was broadcasting an announcement every 30 seconds to the LAN where B is also connected (and already aware of the presence of A). B may infer that A isn’t there anymore in an average of 15 seconds. But this has nothing to do with the way A’s OS internally deal with airplane mode, other than disconnecting it from the network.
Now, I’m aware that I just made up those announcements every 30 seconds, I may have read something like that regarding the local discovery protocol and it doesn’t sound too crazy to me. But maybe it’s the other way around and it’s B that polls A after 15 minutes to find out that it isn’t there anymore. I guess that’s what I’m asking about.
Ok, I tried this twice and every time it was very close to 15 minutes, but who knows, 15 minutes are as good as 5 minutes in terms of the uncertainty that they introduce in every other scenario because the Up to date status is not reliable anymore unless one wants to keep watching for 5-15 minutes (while 30 seconds is something that I may be willing to wait). But that’s ok, I just wanted to check and understand. Thanks!
You’ve got packages to ship to a friend, so you use a courier.
Whenever the courier has picked up one of your packages, although there might be an estimate on the delivery time, you don’t know how long it’ll really take until it actually gets there.
After the courier takes your package, it eventually gets loaded onto a delivery truck that’s also carrying a bunch of packages from other customers. The courier drives around delivering customers packages.
But let’s suppose that it’s Saturday when you drop off a package for shipping and the courier is either on a slower delivery schedule, or suspending deliveries until the next business day, Monday.
You won’t necessarily know that deliveries are on hold, only that your package has been accepted for shipping. You also won’t necessarily know that your friend isn’t available at the time that the courier tries to deliver your package. Because it requires a signature, the courier tries again at some random amount of time later on.
In the analogy above, you and your friend are Syncthing; the courier is Android; and the delivery truck and roads are the network connection.
When the phone is in airplane mode, Android (courier) is suspending delivery of network packets. Although Syncthing has submitted a heartbeat check (package), it doesn’t know exactly how long it’ll be until Android passes that network request along (courier delivers package).
At some point, Syncthing decides that it’s waited long enough, and it must be something more serious since it hasn’t heard back from the other Syncthing instance.
This isn’t unique to Syncthing. It’s a normal part of network-capable applications, especially for network file transfer apps.
Ok, I now see where you are going, and I do understand that you can overreact to missing heartbeats and arrive to wrong inferences, but that was why I was expecting something around 30 seconds, say 1 minute, not 15 minutes which seems waaaaay into the conservative side.
Another reason mobile devices bunch up network requests and more sophisticated network management compared to desktops is in order to conserve battery power by idling network interfaces for as long as possible. It’s a tricky balance.