Theoretically, a Torrent swarm could be a replacement, but only theoretically. In practice, for most downloads there is no Torrent swarm. For some larger, popular files it is feasible for them to exist but it is unrealistic for them to ever exist for a myriad of smaller files that we are also serving.

Metalinks can play all their advantages with the existing infrastructure of 10-150 mirrors that serve files. In those cases where Torrents exists (iso images) it is a welcome addition that can be also employed by metalinks.

Whether Akamai servers take part of not doesn’t make a functional difference; it is just one server (farm) more that contributes to handling the user requests.

When downloading package metadata or packages, it’s all still plain old HTTP, not torrent involved. Just with added metalink goodies.

Torrents are only relevant for downloading iso images.

And yes: allowing for tuning with -C and similar things, in the context of aria2c used from libzypp, is one of the requirements in my view as well.

I am in the same troubles as Sam.

Downloaded openSuse 11.1 DVD (via Torrent link on official site), burned the image and now I am getting the same SHA1 sum error as Sam.
The checksum seem to be o.k., but the installer keeps complaining.

Do I need to get the image otherwise (without Torrent = painfully slow) or is there an other way.

Thank you,
Otto

Regards,
Sam

Metalink doesn’t download from “the most opportune source”, it downloads from 5 most opportune sources at the same time.

It’s true that it has no advantage over a torrent swarm, but it doesn’t claim that. It’s supposed to be better than giving a huge list of mirrors and a md5 hash to check manually. Torrents are a different beast.

Ok, i believe aria2 downloads the metalink file at the beginning and does not update it at any point so it does not know because it downloades all the data needed at the beginning of the download and does not update it’s knownledge. I was using aria2 as well for opensuse11.1 and i needed 5hours,20minutes at around 200Kb/s average speed;-)

I’m currently downloading 11.1 at 50-70 kB/s in Thailand, even though the Thai mirrors haven’t got the new distribution yet.

Just a note about aria2 – for those interested, there are three gui’s available, albeit in early stages of development. Here’s a link:

http://aria2.sourceforge.net/#guifrontends

As part response to TSU2, you may well be correct that a “robust and virulent Torrent swarm” is ideal, but that is only the case for a highly popular torrent at it’s peak. After I’ve got my shiny new openSuse 11.1 up and running, I’ll want to download a whole raft of niche packages that I seriously doubt would have such swarms.

Moreover, since metalinks include torrents anyway (if they exist), using metalink clients should help swarms get nice and virulent that much more quickly. It certainly looks to me as if aria2 is uploading. Here’s a snippet of aria2’s output:

[#3 SIZE:702.7MiB/4,442.5MiB(15%) CN:45 SPD:65.59KiB/s UP:32.45KiB/s(474.5MiB) ETA:16h13m09s]
FILE: ./openSUSE-11.1-DVD-x86_64.iso

One thing I’m curious about though, does the metalink update during the download process? For example, if the Thai mirrors come online before my download is complete, will aria2 “know” about that?

But, I wonder about the potential for other scenarios where the Servers aren’t widely deployed geographically, mostly HTTP/FTP (non-segmented downloads and don’t upload) instead of Torrent and don’t benefit from Akamai technology.

Metalink seems to only attempt to download from the most opportune source but the truth of the matter is that only yields a benefit in either distributing Server load or where there is ample excess Server capacity. In fact it looks particularly limited if the Servers don’t support “segmented downloads” where large files are broken down into individual small chunks which can be downloaded in any order and can be retrieved by anyone else purely because that little bit is available.

I can’t see any kind of advantage over a robust and virulent Torrent swarm at all… Although initially it might look great that a Client has so many options to download but the fact of the matter is that if the client is not uploading (like Torrent clients) or too many people are connecting to HTTP/FTP downloads then the benefit could be marginal if at all.

If you see a hole in my thinking, pls comment… 🙂

All this is fine, as long as it doesn’t bypass all the lovely squid caching we do for our network users – get the iso / updates once and every other machine gets them from the cache. If it does prevent caching, it would be ideal if the ‘aria2’ method can be made optional (and / or a reversion to previous behaviour is available as an option). The ‘-C’ option will also need to be available as an external option for the above tools as well.