We have a test environment of 2 Syncthing instances: D1, D2, and 2 shared folders on D1, folder_A and folder_B, and one shared folder on D2, folder_C.
Folder_A on D1 is not shared with any other instances, and Folder_B and Folder_C are shared between D1 and D2.
When the servers are on version 1.6.1, we pause Folder A, and the downloads between Folder_B and Folder_C are going uninterrupted. However, when we upgrade to 1.7.0 or 1.8.0, D1 terminates the connection to D2 the moment Folder A (which has nothing to do with existing downloads) is paused. Is this the expected behavior?
Yes, that’s normal behaviour since always. So I’d be very surprised if you could indeed pause a folder in 1.6.1 without the connection being dropped. Folder information is exchanged when a connection is established, so when any changes the entire connection needs to be re-established. That should however happen pretty quickly.
Thank you! Yes, I confirm that in 1.6.1 downloads of unrelated folders does not seem to stop, which is good. But what I would like to achieve somehow is to update the config via API in a more granular way rather than sending in the entire XML file. Assume having 100 folders and 10k devices, and the file becomes so large it cannot be parsed. Also, for this use-case, it would be essential that connections remain uninterrupted when an existing folder is shared with a new device. Without this capability, we have a scalability issue that we cannot update the config file, say, every minute because if currently syncing folders need to be restarted, when syncing large files, one minute might not give enough time for the other side to complete even a single chunk, and then the syncing gets stuck, and the file will never reach the other end. What would be the best practice to overcome this?
We are aware the api isn’t optimal to put it mildly. There’s something brewing right now that hopefully leads to a new (and better) api: Technology for new API
The issue with dropping connections is unrelated to that. Applying changes incrementally/more granular without dropping connections is in principal possible, but not the way it is done now. Changing that touches a lot (all?) of sensitive areas internally. And it’s not on the table at the moment.
Right now if you are dealing with such huge deployments, the solution is at the cluster level. There have already been a few discussions on this on the forum. The exact solution depends on your requirements/network topology, but the basics are not to connect every device with every other device, but use e.g. a “hub-and-spoke” topology or something tree-like.