Distribution between nodes / Order and heirachy.

OK RTFM here, sorry in advance. I have searched and found items regarding sync order etc. Just to clarify in a dumbed down version.

If I have

A - A Master Server

B,C,D - Slaves to Master

If I add a file to master it will propagate to the Slave machines.

My million dollar question is can/how/is it possible to have the master AND slaves all sync to each other. Meaning if file x shared from A master has reached node B and A master goes off line can B push to C/D slaves?. Just trying to get a fundamental lay of the land in how this distribution works.

Hopefully above is understood. The above would cut down on bandwidth from the Master as well as all nodes would distribute between themselves.

Regards

VC

1 Like

There are is no concept of “master” and “slave” regarding devices in Syncthing. Every device is equal. I’d say you only need to connect all devices with each other, then share the same folder between all of them, and you will be all set.

1 Like

Ok thanks tomasz.

So just for clarity

A shares a folder X with B,

B receives the files.

A shares a X folder with C

C receives files sync from both A and C whichever syncs first.

So now when A shares another file within the folder X both C and D gets the files. Does B then send to C if A is offline?

Apologies for being a bit of a lemming here but I need it iron clad to understand.

Regards

VC

Yes, as long as you have connected the devices with each other and shared the folder between them.

Ok we are getting down to the nuts and bolts now.

So by

  • A sharing with B
  • A sharing with C.

B cannot share the same files with C in terms of syncing?

I’m trying to establish if a distributed network can be made. As in once A has shared with B and C. B and C can sync even if A goes offline (Providing of course A has already put the data on B ore C).

I’m sure there is a term in syncthing world for this. But at the moment this escapes me.

Whatever topology you select, it will work.

  • Mesh like in your picture.
  • Hub and spokes.
  • Any combination.

It will work as long as there is one or more paths between any two participating nodes, regardless if there is zero or more intermediate nodes in between.

It will work as long as there is one or more paths between any two participating >>nodes, regardless if there is zero or more intermediate nodes in between.

For my fried brain.

So B can communicate with C even if A has only granted access to B and C Martin?.

Not Martin, but obviously the synchronisation will not work if the two cannot communicate with one another.

In one word, as long as you do

A <--> B
A <--> C
B <--> C

both B and C will be able to sync if A is offline.

On the other hand, if you do only

A <--> B
A <--> C

then B and C will not be able to sync when A is offline.

I’d suggest to simply connect the devices and share a test folder between them, so that you can see with your own eyes how Syncthing works. If you’ve still got questions then, please post screenshots showing the Syncthing Web GUI on all devices in order to verify the actual configuration.

2 Likes

Thanks Tomasz much appreciated.

Yes I did test it yesterday on lan but to be honest even watching task manager / performance manager on network it was so fast the changes were hard to spot.

A <–> B A <–> C

So with the case above providing all nodes are online then B can communicate with C.

A shares a file to B. B can then send the file depending on location and speed to C should A not be as fast.

Every node is independent from all others. You may have configured A to share a folder with B and C, and on B and C someone (maybe you) may have accepted the sharing from A. When that is done you have a small hub A with two spokes B and C. In this situation A must be up for changes on B to propagate to C.

However, B and C may share that same folder between them, unbeknownst to A which is never informed about that. If they do so, changes in B will propagate to C regardless if A is up or not.

You wrote: “A has only granted access to B and C”, thereby implying that A controls B and C. That is not true. Every node is independent.

Right get it now.

My next question sorry its running on a bit.

A adds B as a node.

B accepts and adds A (And also ticks the introducer tab)

What is the consequence of B ticking the introducer tab? Does that mean when A joins to another node say C then A is aware of C?. From what you say all nodes are independent unless joined between each other.

The introducer feature is a grey area at the moment. What is the is the use case?

Your time is valued its nice to have someone reply with tangible answers so thanks.

I assume you’ve checked the documentation already, but basically, you can use introducer to spare yourself of manually sharing the same folder between multiple devices.

For example, let’s say you’ve got the same folder shared between A and B, and between A and C. A is set to introducer on both B and C. Then, you connect B and C with each other (without sharing the folder). With A being set to introducer, the folder will then be automatically shared between B and C. Without A being set to introducer, you’d have to share it manually between the two.

Yes did read the docs but your wording makes more sense to me so thanks tomasz86

Sorry to resurrect this so quickly.

If indeed all the nodes are shared between each other and A is the introducer does A try to push a newly introduced file/s to both B and C at the same time or does it pick to push to one first say B. Or if multiple files one file to B one to file C in a random order, then B an C sync the missing files between them. I’m trying to get an idea of the sequence of a mesh and order of precedence.

I suggest you go read the protocol on the docs site, if you are interested in such details.

I think it should clear up some of your questions.

Introducer etc, has no control on data flow, and all data is pulled, not pushed.

2 Likes

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