[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian ISOs

Hash: SHA1

Bruce Sass wrote:
> You seem to be ignoring that metalinker will use multiple protocols, 
> servers, and connections in an effort to get the fastest download. 
> http://www.metalinker.org/Metalink_3.0_Spec.pdf also indicates it will 
> switch servers if the download rate falls, and perhaps even perpetuate 
> old torrents --- which is all great for the client, but will pretty 
> much guarantee worse than possible performance from the servers.
> It is also not clear what will happen when a release is made and 
> hundreds (thousands?) of clients hit the fastest mirror, whose download 
> rate then drops, prompting all the clients to try switching to the new 
> fastest mirror, whose rate then drops, ...  At the very least there 
> will be more overhead traffic for the servers, worst case could be some 
> kind of nasty cyclic oscillations with the server loads which 
> undermines transfer efficiency for everyone.  Ya, that's kinda FUDish, 
> but given the newness and limited deployment of the technology, 
> speculation is about all we have to work with.

 When a new release is made, all servers (and mirrors) are getting hit.
First, the tier 1 (ftp.<country>.debian.org), and then the other
mirrors. So, if you only consider http and ftp, metalink is the logical
choice, since it switches automatically to a new server, when the rate
drops (at least, it should, but this depends on the client).
 The only situation in which you can save the servers bandwidth is when
you use download protocols that involves the users bandwidth, like
bittorrent, edonkey and other specifica file sharing protocols.
 So, there are 2 situations here:
  *) make .torrent files
  *) make .metalinks files only with bittorrent, e2k protocols and
magnet urls

You can see that metalink has advantage over bittorrent simply by having
bittorrent _and e2k_ :)

> The objective is to ease and spread out the load on the servers; 
> bittorrent and socially engineered access to the less efficient 
> protocols is more likely to do that than bittorrent + ftp + http + 
> multiple servers/client. IMO

 ok. then use metalink only with bittorrent and e2k links :)
I only try to convince you that using this technology is just a very big
advantage for the average joe.

> I think Metalinks are an interesting idea which deserve investigation, 
> but it seems clear they would result in more server overhead and 
> unclear whether the load spreading would offset that or even happen[1].

 Sure. I'm not saying that it should be adopted as once, without further
investigation and tests. But is not something that should be ignored
just because is new. I'm only saying that metalink deserves a change.

Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


Reply to: