Can I set up syncthing nodes as hub/spoke network?

Support
1

I have a syncthing setup on devices in two geographical locations. Devices A,1,2,3,4 are in one location and B,5,6,7,8 are in another. Devices A and B are dedicated to syncthing and are always on. Devices 1-8 are regular personal use pc’s and android devices. As such they can only connect whenever they’re in use, and the androids whenever they’re connected to wifi. Online status is thus unpredictable.

The reason for two dedicated syncthing devices is that the network between the two geographical locations is unstable and slow so having two devices always on lets syncing work properly. For example, devices 1,2,3,4 might be able to complete a sync with device A and each other instantly. They’re not online long enough to sync across the location gap. A then syncs with B slowly overnight, then the changes propagate from B to 5,6,7,8 instantly.

Right now, for each device, device A and B are both set as introducers. So using one sync partnership as an example, each and every device with this folder is connected to every other device. I’m worried that so many devices might eventually develop sync conflicts or if I decommission a device then I have to remove the unused device from every 9 other devices.

So I want to simplify it by having each device only connected to a “main” device. I’m not knowledgeable about syncthing or networking but I was wondering if I could use a hub/spoke layout to setup a folder partnership like this picture.

Device A is one hub. Connected to it are spoke devices 1,2,3,4. All these are in one geographical location. In another geographical location is Device B which is another hub, connected to it are spoke devices 5,6,7,8.

Device A is connected to device B. 1,2,3,4 are not connected to each other. Neither are devices 5,6,7,8. This way the devices list for each spoke node would only have either hub A or B. Only the hubs themselves would have multiple devices in the device list. Each hub is not aware of the other hub’s devices. There are no introducers.

I have two questions

  1. Does it make sense to separate my partnerships into a hub/spoke layout, based on my circumstances? (Geographical seperation, slow network across location span, intermittently online nature of devices 1-8)

  2. Will this work from a syncthing standpoint? Can one folder be synced amongst devices, some of which do not know about each other? Again this picture is what I am talking about. Circles represent devices, lines represent partnerships. All this is for one syncthing folder/partnership.

2

Sure, this makes sense and would work. There is no need for all devices to know about each other, as long as there is a “path” from one device to another via any number of intermediate devices. What you’re describing is some sort of tree structure which is a perfectly valid deployment model.

3

I just wanted to make sure my thoughts were expressed clearly as I posted this before I could transfer the pictures I meant over. The before picture is my current setup, and after is the aforementioned hub/spoke network.

Before:

IMG_20200306_150448
IMG_20200306_1504484000×3000 3.05 MB

After:

IMG_20200306_150453
IMG_20200306_1504534000×3000 2.86 MB

2 Likes
4

I would greatly prefer the “after” setup. It’ll work fine.

2 Likes
5

That’s great, I will work on simplifying my setup. Thank you for your time and clarification.

2 Likes
6

Me too slow :slight_smile:

  1. Based your reasons given, I would say no: More connections do not create more conflicts, quite the contrary in general. Even the slow connection wont do much harm, peers will just pull must of the files from the local peers (as they can deliver quickly). However:

  2. This totally works and is the usually recommended setup for lots of devices. Since very recently, the database scales better with the amount of remote devices, but there still is quite some overhead based on the number of connected devices. Therefore limiting the amount of remotes is a good thing in terms of resource usage of a Syncthing client.
    In your case with a smallish number of devices, there might be a small benefit for going with a “hub-mesh” network, i.e. all devices connect to each other within a single location and, but only A and B connect to each other across locations. For large transfers this might facilitate quicker transfers as not all the transfer need to go over the single, central device. However if all devices are on a fast network and the central node isn’t resource-starved, the effect might be tiny.

1 Like
7

This is true in principle. In theory I can imagine an exception where a device creates a conflict and wins it, making all connected peers the losers, each of which will create a conflict copy. With fewer connections this will get resolved earlier before getting propagated. In practice I’m not sure what happens. :slight_smile:

1 Like
8

My two cents are that a strictly hub and spoke model is a pain in the butt when something happens to device B due to a power cut (which may be the result of a child choosing to plug their phone into a socket and thus unplugging your “always on server”…).

Point being, having each user device connected to only one hub means you don’t have much redundancy. I prefer to have more than one hub connected to each spoke. In reality I only have one always on device in my environment, but the other devices that are most frequently running often have two or three other devices connected to them to provide an alternative route for files if something happens to the hub.

9

This is one of those it depends issues.

The OP’s 2nd design where 2 star clusters are connected by a single connection between hubs A and B is nice and tidy. But, a break between A to B means that 50% of the nodes lose contact with the other 50%.

A full mesh network, where every node connects to every other node is far more reliable. But in the syncthing world, it means a rather large config file to create and maintain on each device.

In a full mesh, the number of paths [P] is a function of the number of nodes [N], and can be calculated as follows:

P = (N*(N-1))/2

10

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.