Please help a newbie understand the benefit of this program

Hi… Current user of BTSync here,

I was planning on moving over to this promising FOSS project until I read this discouraging post linked below (notice the first response by Calmh after OP). Please quickly read the first 2 posts at least before continuing here.


Ok so my question is this. Given the known behavior in that linked post, how is this program beneficial (for large file transfers) over any other plain old sync program, like FreeFileSync? Under realistic network loads and behaviours, if computer A introduces a large file to the “mesh”, all clients will have just about 80-90% of the file before the fastest reciever will be able to advertise that it ALSO has that file and can finally start sharing the upload load with the original sender. Doesn’t this completely negate the point of a p2p mesh and all the added complexity that making a program and protocol for it brings? No offence but we might as well be making a plain jane syning program here instead of a BitTorrent like program/protocol that allows swarm uploading/downloading for much faster syncing.

I understand about arranging the mesh into more of a tree instead, or perhaps just using zip to span the large file into many smaller ones but this misses the point. TBH, those remedies sound like the user having to unnecessarily add complexity themselves just to fix the shortcomings of the current design in the first place no?

Please let me know if I an missing something big here. Also, while constructive criticism is welcome, please don’t attack me. I’m not trying to tear down this program/project as it seems to have a great start. I just want to know if I am on the right track here in the questions I am asking.

Also can anything be done with the design to make it more like the BitTorrent protocol where, when a large file is added, peers can immediately start uploading pieces they have recieved as soon as those pieces are complete, not just the entire contents of the file? I might even consider trying to help develop it a tweak like that if it isn’t too hard and or completely changes the way the program/protocol works.

Here’s to hoping for a truly robust and superior FOSS product in the years down the road.

Upload of partially downloaded files is already being discussed on github and currently marked with V 1.0 (maybe) by the developers.

FreeFileSync is for on-demand sync, so not really comparable with syncthing/btsync. It also seems, that it does not de delta transfer, so a small change in a big file would case the complete file to be send again.

Once the initial sync is complete and you change 1MB in a 10GB file, syncthing will only send 1MB over the network.

Thanks for the quick reply. Fair enough on FFS, however I was just using FFS as an example not THE example.

Rsync then… another example but one that does delta as well, just not true P2P mesh load balancing. And of course I also am aware that all of this is a moot point if either BTsync or Syncthing are just syncing between 2 clients. Can’t take advantage of a mesh if there is no mesh in the first place.

Anyway… it’s good to know that this is already under discussion in the developers forum. I’ll go check that out.

It is not, if all you want to do is transfer a large file from A to B. The benefit comes from automatic bidirectional syncing between multiple peers, and synchronizing changes made to large files when the devices already have a copy that is similar to the right thing.