I would like to get someone to look into this idea again. Using bittorrent instead of multicast has many advantages. First and formost, it is easy to move the traffic away from the server connection.
If you have some of the same challenges as I have, multicast traffic from the server to a set of clients will affect networking in a bad way, on all swicthes between the server and the clients. Using bittorrent, you can easily limit traffic from the server to a single tcp connection, and let the traffic between the clients go crazy instead. The clients I am working with are usually limited to a few switches at a time, with no other traffic while I am imaging, but the connection to the server in a different building might go through a number of switches that facilitate normal traffic as well.
The challenge will be to get sequentual downloading of the image files, which is not the standard bittorrent way. We have seen this done in quite a few applications related to videos, applications that play videos while downloading. En example to look into might be btcat from p2ptube, script [URL=‘http://p2ptube.sourceforge.net/btcat.py’]here[/URL]. I have not looked into how btcat can seed from it’s download, since the download is not going to a file, but perhaps some kind of buffer in memory?
I suggest using bittorrent only for deployment, not for uploading. It could just be an addition to current deployment methods, having the fog server running a tracker and a seeder. The seeder should have the option to limit the number of connections. An optional seeding delay on the clients after finishing download could also improve the result.
I have actually done bittorrent downloading for imaging for a few years. However, I have been downloading the image file the normal bittorrent way. to a temporary partition, without piping it, and then running the actual imaging process and cleaning up the partitions afterwards. This is a delay in the process I would like to get rid of.