BitTorrent support for smart
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Smart Package Manager |
New
|
Undecided
|
Unassigned |
Bug Description
[04:33] <Rudd-O> the point of smart where I see bt useful
[04:33] <Rudd-O> is in update downloading
[04:34] <Jonathan_R> give me an example
[04:34] <Rudd-O> so when an update is released, sure it's downloaded from the official mirror, but then seeded using some sort of torrent
[04:34] <Rudd-O> ok so you have a mirror
[04:34] <Rudd-O> and the mirror usually generates the metadata and stuff
[04:35] <Rudd-O> it could conceivably generate a trackerless torrent that is seeded over the web, and smart would download only selected files from that torrent (or, in case of failure, well, it's web-seeded so...)
[04:35] <Rudd-O> that way a channel ("repo" in yum parlance) can be bittorrent-enabled and reduce the bandwidth across the web
[04:35] <Rudd-O> fewer mirrors would be needed
The way I see this could be implemented is:
Enable the deb repo generator and the yum createrepo to create a Web-seeded, trackerless torrent. That is step 1. So when the repos are regenerated in the mirrors, they are auto-creating the new .torrent file that will be placed in the appropriate directory of the repo.
Step 2 would be to make smart interface with the high-quality python libraries for bittorrent, so it can download only select files (the ones that it needs to perform the system update) from the Web-seeded trackerless torrent.
Step 3 would be to be a good citizen. Seed until a predefined percentage or some time has passed, then quit and remove the files from disk.
This idea would, of course, need to be an opt-in option and naturally also would need the user to specify a maximum upload bandwidth (or perhaps auto-envelope the upload bandwidth based on the latency to the download server, if pings are too high, cut the upload bandwidth in half, until the bandwidth sits at a level where it doesn't impact network performance, or maybe in the other direction, start at 1 KB and multiply it by 2 until network performance decreases, then slash by 2 and remember the value.).
And, of course, this would not need any modification to smart's repo code, except for detecting whether a .torrent exists on the repo directory (and if that's the case, enable bittorrent).
If this is implemented correctly, this would lead to major bandwidth savings on Internet links in companies, and blindingly fast updates across machines in the local network, because LAN speeds are much, much faster than Internet speeds.
Wouldn't you need one such .torrent file for each .rpm or .deb ?
I mean it's useful for .iso files, but not so very for smaller ones.
But yeah, there are some variants on this BT theme floating around. apt-torrent, or http:// brainstorm. ubuntu. com/idea/ 7792/
Like debtorrent/