Scorp1us

If we're talking about beat practices, you shouldn't be using sync to manage a web server. What you should be doing is having a development code base, in a version control system (assume git) you have release and testing branches, and your production server just pulls the release branch. The fact that you can check in any tweaks (usually config mgt) from the production webserver and inegrate them into the dev branch is a very valuable back-flow.

Can you elaborate on what Sync is capable of detecting and how it responds?

The problem I have with labeling this thing as a good thing for the "cloud" is cloud files are not the same as general torrents. Torrented files are copies of an original that never changes. With cloud files,, there is a higher expectation that this is a working file.

That's not a fair comparison. If someone wrote Sync with all the features it has, which uses BT, then a fair comparison is if someone wrote a comparable Sync for RSync. BT and RSync are the protocols, Sync is a app using the protocols.

Well then that's cool!

Very much so. But I suggest you take it further. Use the appropriate protocol for the task at hand. If BT would be inferior, switch to Rsync. Then you have one tool that can work better in more situations. But the important distinction is that the computer knows, so the computer picks. The choice can be hidden from the user and they just see lots of win.

This is an interesting claim. No matter what protocol, you have to send 2gb to have the same file on all computers.But I am interested in what happens next. If you modify the file, what has to be transmitted? Perhaps it is just publish/download. But once distro I used only provided Rsync of ISOs so you'd only get the 20mb or so of changes. How does bittorrent respond? To me one of the advantages of Bittorrent is when you have lots of seeders. But if you have a microcloud of 3, I don't see BT doing nearly as well.

It depends on how you define "server" RSync can operate on it's own by comparing two files. If one of the files is remote, it is heavily benefited by being able to calculate the checksums locally, then comparing them. So yes, there may be a "server" on the remote system that reads the file and transfers the checksums. Then once that is done, the server accepts and applies the incoming deltas.

As an aside, I just find it amusing that it is 2013, 50 years after the first filesystems and 20 years since the took off web we're still inventing ways to move files between computers.

False. There are no algorithms that can't be done on Windows if they are done on Unix https://www.itefix.no/i2/cwrsync (Python: http://blog.liw.fi/posts/rsync-in-python/ ) it would me interesting to see if you could replace your torrent based solution with rsync and see which one comes out ahead.

True, but it would be interesting to see in some tests who performs better. Given that most changes are small incremental ones, rsycn should be competitive for a large number of test cases. I thing you'd need an organization to generate enough load that rsync starts to falter. Which is fine, but when I hear "dropbox" I think individual.

So RSync is good at transferring files, and the differences between them. Meaning added, deleted or changed blocks. And given that you create/modify at one location at a time. Rsync seems a better fit. Bittorent is engineered for getting 1 file from many sources. You're not going to have many sources in your private cloud. So why should we use bit torrent. I can't think of any reasons to, but many not to: - ISP throttling/blocking. - RSync is more efficient.