> In order for swarming to be efficient, clients also need to keep files > around long after they have finished using them, and clients need to stay > connected long after they have completed their downloads. > > So, BT-yum can no longer delete rpms after installing them, and BT-yum > needs to hang around connected to the tracker for some time (hours? days?) > after completing updates. Having to keep a copy of the RPMs is a good point. However, if there are thousands of peers, you might get away with only keeping a few files. One extension to BT I played with that worked quite well was a repeater mode. It allows you to help others download without using any disk space. It's currently part of my code base, and I could apply it here. In the best case, I would like users to run their clients as an update deamon, or as a mounted remote drive. It would make sure never to have too high an upload/download ratio (like > 3-to-1), so you wouldn't be sucking up bandwidth all the time. There are also other bandwidth restrictions, such as max upload rate. It's all actually a bit complex, which is why I was going to try keeping the technical discussion on the bittorrent list. It's also a good reason not to build it directly into YUM. > In theory one could have an "always-on" swarming updater running 24/7 in > the background (this would have other benefits such as instant updates) > but lots of people might not like the idea of their machine eating up > bandwidth 24/7. > > To me a BT-yum looks less and less attractive, and a yum with parallelized > downloads looks much better. > > -Dan If you build a parallel YUM, I will happily use it! If you do go that route, I'd recommend building a separate download tool, one that you can tell "Here are the servers, and here are the files I want". It would be a useful utility by itself. Bill
