I’m not trying to tear down this program/project as it seems to have a great start. Also, while constructive criticism is welcome, please don’t attack me. Please let me know if I an missing something big here. 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? 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. 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. 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. I have a 600mb file being sent to 6 nodes, would it send different 100 m… When syncthing is transmitting data, would it be sending sequential pieces to all 10 nodes simultaneously, or would it be sending different pieces to each node and they would all work together to fill in the gaps, thus sharing the load. The SeedBox is the Repository Master and of course, all of content is coming from there. Scenario, I have SeedBox and would like to sync the contents to 10 different syncthing nodes.
Syncthing over Clusters - Data Transmission Question Feature
0 kommentar(er)
