[Yum] More on BitTorrent and YUM

[Bill Cox]

> 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