Ubuntu Wiki

Debtorrent does most of what this spec set out to do. It is in hardy. Please give it a try (http://debtorrent.alioth.debian.org/)

Allowing the package manager to use torrent technology or other P2P technology to download package files and updates. The torrents could be used for just large individual packages and the update lists.

Home User Scenario

Home User installs Ubuntu. User is asked on first boot up if he/she would like to contribute bandwidth back to the community. Ubuntu sets up a bittorrent client that automatically seeds updates and extra packages to the rest of the Ubuntu community.

As we talked about after the last CHLUG meeting, this is probably crucial for getting new free games into the repos. I'm currently packaging World of Padman, for example: the data package is 530MB. If a lot of games get into the Ubuntu repos, and those games become popular downloads, it will put major strain on the official repositories. -- JoeTerranova

Multiple Computer Deployment Scenario

Administrator sets up a bittorrent tracker that holds several different torrents. Each torrent corresponds to a different lab, in the torrent are all the files that are needed for each computer of that lab (aka all packages, but not limited to just packages). When updates are required Administrator just updates the torrent, and they are efficiently transferred around the network.

*Extra possibility, let Synaptic chroot into the torrent files and change packages in a GUI way.

I'm not sure of the usability of this. The general usefulness of torrents is the ability to have numerous people uploading, which overcomes internet bandwidth limitations; in a computer lab, the computers have 100mbit connections. This would be a useful idea if it depended on rsyncing from a central location instead, but torrenting wouldn't make much sense here. A case where it would be useful to have a separate torrent would be for a University network; students would be on the internet torrent and a university torrent, and share parts they'd gotten from the internet within the university network. -- JoeTerranova

Possible Solutions

APT-TORRENT

I think dijjer is a MUCH cleaner solution. It reduces disk fragmentation. We only would need to provide a few seed nodes, as the default one is dead, package it with a script, ask how long we want to seed, what speed we want to upload, etc.

DIJJER

Dijjer definitely seems like a more practical solution. It's seamless, doesn't require firewall rules or port forwarding, and would work perfectly fine as a middle man for the package download. We'd have to look in how well this would work with apt, since that isn't a browser window (it should work fine), and how easily the backend mechanism could be pulled away from Dijjer's script and onto Ubuntu's servers, which doesn't seem very difficult.

However, since you want to allow the user to opt-in or opt-out of the service, it becomes a bit tricky: the packages.gz, which gives the path to all packages on the server, is a flat file (I don't even know if apt supports having urls as paths in packages); this means that, if we're giving a dijjan url for a package, it's either in or it's out -- there's no way to dynamically choose whether or not we're sending the package through dijjan. That would require the redirect script on Ubuntu's side to figure out whether or not the user opted in for dijjan. -- JoeTerranova

Well, this doesn't seem as an issue to me, the user can be prompted for an answer, and two different mirrors could be used for dijjer and non-dijjer users. He would only need to edit /etc/apt/sources.list and instead of

deb http://archive.ubuntu.com/ubuntu main restricted

he could put

deb http://archive.ubuntu.com/ubuntu/dijjer main restricted

--edit You are right, the Package.gz file is the one that should contain the dijjer URL, also, dijjer is very eexperimental as of yet, maybe apt-torrent is the short term solution? Maybe for medibuntu it would be the perfect way to do it? --J18

Unfortunately, it's not that easy. Here's a breakdown on how it works:

Apt downloads the packages.gz for every repository in your sources.list. A packages.gz is specific to your distro, area, and architecture, and has information about every package in that repo (for example, here's the Packages.gz for Feisty main i386). That file is then used by apt to make a database of all the debs in all your repos -- the important part for us being the filename. For example:

Package: abiword-common
...
Filename: pool/main/a/abiword/abiword-common_2.4.6-1.1ubuntu2_all.deb
Size: 1846164
MD5sum: cd1485eb37b1db4bf2b6d7bd44ede433
...

In other words, the only thing that change to sources.list would accomplish would be causing the packages.gz to be sent through dijjer, which is probably the last part of the process we'd ever want sent over p2p (it's small, and it changes a lot). The issue still becomes the 'Filename' field in the packages.gz. I don't know if there's any way to make it be a different url, but either way, it's a flat file, so it either sends everyone to dijjer or it doesn't. As far as that issue goes, options include:

• Making the link be to a Ubuntu script, which checks whether you have dijjer enabled, and either redirects you to dijjer or not.
• Modifying dijjer to have a "download only" option. This means that all dijjer-enabled downloads would come through dijjer, but they're not uploading all the time. We could make it only upload while downloading, or throttle download speed from the dijjer network because they're not uploading, or whatever.

-- JoeTerranova

Perhaps a new repository is in order, perhaps "Games"? Enabling the repository enables digger/apt-torrent/whatever. I suppose if we want to go with the whole universe thing.. metaverse? I think apt-torrent takes a very digger like approach, except they designed it for apt. Correct me if I am wrong, but does dijjer require java? -- BryanQuigley

Another project with similar goals, already usable (and available from Hardy): Debtorrent... http://wiki.debian.org/DebTorrent