Syncthing is tremendously useful for a single user, or for multi-user network where each user has equal rights. However I am hoping to use it for the remaining case: Multiple users, only one user is adding new files.
So, user A adds new files, which get pushed to users B and C. Now, suppose user B adds some files of his own (to the same shared folder). I wonder, if there is a way for user C to ignore B’s files, while still receiving updates from A.
Well, a trivial solution is to connect only to A, but then the bandwidth between B and C is not utilized. So this is not really a solution (it’s more like FTP). The question is how to achieve the same, while having all nodes exchanging data (originally A’s data).
This is a critical function for a whole range of applications. So, I am curious if it is possible now, or planned in the future?
Yes, BTSync works, and is what I’m using currently. However I consider using BSync risky due to its commercial nature. E.g., just recently they introduced 10 folders limitation, who knows what they’ll think of next to improve the revenue.
So, I’ll switch to Syncthing as soon as it will support this scenario.
I wonder what would be the best course of action to make it happen. Campaigning in comunity / booting a bounty / having a go at coding it myself, etc…
No, I mean Bittorrent, not Bittorrent Sync. If I understand your question correctly, Bitorrent is the perfect fit for you. It is for efficient transfer of data from one to many.
And if you are concerned about being screwed by proprietary software, there are many copyleft and permissively licensed Bittorrent clients.
Sorry, I was not completely clear. Full synchronization functionality is still a requirement for me. Instead of “distributing files” I should have written “synchronizing from one to many”.
I.e., the recipient nodes should notice when files are added or deleted on master node, automatically, and mirror all changes.
This could be done with Syncthing in its current form assuming all the nodes are directly under your control.
If you added a single node to, say, 30 machines, didn’t set that single node as an introducer on any of them, and set the single node as repo master, you’d essentially have Single-to-many syncronisation.
Or am I misunderstanding your usecase here?
If you had huge files that absolutely had to utilise all available bandwidth, you could always PGP sign them so that the receiving applications know they are the real deal.
The problem with that topology (the “star”), is that you lose the possibility of the slaves sharing blocks with each other.
So, the master would have to transmit the data 30 times (once to each slave), rather than once (1/30 to each slave and let the slaves share with each other).
I honestly don’t see the problem here using syncthing. It might not be the most fool-proof approach, but having one masternode and many “other” nodes that share the load is definitely possible. Though, once your master node gets disconnected, and some user changes something in the repo, it changes all other nodes as well. But hitting the “override changes” button on the master node from time to time shouldn’t be that difficult.
But thean again, I am sure there are better ways to do this…
Btsync implements this by allowing you to distribute a read-only key.
I am thinking of moving from btsync to syncthing and am really surprised if syncthing does not have such a feature. It has been a part of btsync almost from the beginning.
Please tell me if I am missing something?
Why does that matter when BTSync had such a feature?
Syncthing is not trying to be a clone of BTSync, hence no surprise that it currently doesn’t have the feature.
That’s an excellent question. You are right that a bad answer would be that syncthing is simply trying to match btsync’s features, which it is obviously not.
I think a better answer would be that there is a strong use case for such a feature.
I am not challenging that, there is, and it already has a issue on github.
It’s just missing someone who actually implements it, as well as irons out all the implementation details
It is GPL and designed for synchronizing large clusters.[/quote]
Thanks for this link. As far as I can see, csync2 implements one-to-many synchronization, which is suitable for its intended purpose: synchronizing configuration files on a cluster (e.g., tiny amount of data). I.e., slave nodes don’t connect to each other. Also, it looks extremely non-user-friendly (e.g., good luck telling your Windows users they need to run “./configure; make; make install”).
I’ll think about it…
They’re not, which is the exact point of this thread.
Single-to-many synchroinzation already exists for years in form of FTP, rsync, etc. p2p synchronization is why we are here.
Now, this is an excellent point. Actually it’s a good idea regardless of synchronization tech. In my case I simply distribute SHA-512 hashes, separately from the actual data being synchronized (via http).
The problem is outlined in the first post: Someone, accidentally, or intentionally, adds a bunch of data to the shared folder. Now, the network is busy exchanging bogus data, wasting precious time and bandwidth.
Well, no. This feature (issue #1439) does not help. You can’t trust the users to set this flag any more than you can trust them to not pollute the shared folder with junk data.
In a multi-user file distrubution scenario, a typical user can’t be expected to know how to set flags, or even to care about it. On the other hand we can expect some users to try setting the flags to the opposite, by mistake, or to try to see what happens, etc…
Issue #62 “Non-source (slave) devices” does not seem to help either (unless I am missing something). All these attempt to solve the problem at the node originating the junk data. Instead the problem needs solution on the node receiving such data.
