[Yum] More on BitTorrent and YUM
Bill Cox
bill at viasic.com
Wed Jun 29 20:59:24 UTC 2005
> 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
More information about the Yum
mailing list