I have copied some of icon's comments from http://www.redhat.com/archives/fedora-devel-list/2004-February/msg01146.html +++++++++++++ 1. Bittorrent is highly inefficient for a large collection of small files. You will have to start a separate tracker item for each rpm, and for some of them the amount of traffic generated just tracking the p2p clients will outweigh the savings of using bittorrent. I would imagine that several thousands of tracker items would also be quite processor-intensive. 2. You have to specifically punch holes in the firewall for bittorrent -- not one, but a range of ports, actually. Something most people will not do, so they will be constantly leeching. 3. Yum runs as root, so you suddenly have a very large amount of code (yum+bittorrent libs) listening as root for incoming connections. Yikes. Alternatively, you'd have to fork a downloader process and communicate with it using some methods. Either way is painful. +++++++++++++++++ For question 1, it sounds like Jarret's implementation is a fairly additive and modular one. It sounds like Bittorrent is just another way to get the file and not a total replacement for ftp/http/file based retrieval. This way, the owner of the reference server can decide if a file warrants using bittorrent or not. For example: new version of something big like OpenOfficeorg should be distributed via torrent. New version of "cat", distribute as an RPM direct download. I've also joined the bittorrent list so that I can broach this subject there and hopefully ask about the "overly popular file' problem. 2 is clearly a problem. However, it seems like a known drawback rather than a showstopper. First, even with some leechers we would be better off than ftp/http only, right? Second, many people actively work as seeds for files that they don't need simply to help other users. I am one such person ;) The Linux Mirroring Project is full of lots more such people and we could certainly get their help as well. 3 Doesn't seem like a terrible issue to me. AFAICT Bittorrent has yet to have a security problem identified in three years of the project running - not a bad record. I'm not as sure of Yum's history, but I imagine it is good as well. Clearly an audit of the two trees is a good idea - fortunately this is a rather active group! How encouraging for me to return from dinner and read that smart people have already put good thoughts and effort into this idea! Greg On Wed, 20 Oct 2004 19:49:48 -0400, seth vidal <skvidal@xxxxxxxxxxxx> wrote: > > > We are using the current version of yum that comes with Fedora Core 2 > > (2.0.7). However, our changes to the actual yum code are very minor > > (less than 30 or so lines I would say) so all changes should be forward > > and backward compatible. We also included one extra file to handle the > > BitTorrent connections. There are some extra files that implement the > > background uploading and an intelligent server manager that helps to get > > the swarms started. > > > Our implementation basically just hooks into urlgrabber. The > > headers.info file is modified on the server to point to a .torrent file > > instead of a .rpm file. When url grabber detects that it is downloading > > a .torrent, it trips our code. Our code downloads the .torrent normally > > then starts the BitTorrent process which continues with the download. > > When the download is complete, yum contacts our client upload manager > > and tells it that there is another file to seed. Yum then continues > > normally and, with the exception of some extra debug output, the user > > and yum can't tell and don't care if the file was downloaded via HTTP or > > BT. Yum completes its work normally, but the client manager runs in the > > background continuing to upload on the swarms that can use it. > > So you setup a separate seed for each file? > Do you keep the seed around after the download completes? > > Aren't you taking a fairly serious performance hit? > > -sv > > > > > _______________________________________________ > Yum mailing list > Yum@xxxxxxxxxxxxxxxxxxxx > https://lists.dulug.duke.edu/mailman/listinfo/yum >
