Re: Debian ISOs
On Thu August 31 2006 00:27, Subredu Manuel wrote:
> Bruce Sass wrote:
> > 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.
Would each mirror or region need a unique metalink file to ensure that
happens?
I'm thinking that if all clients see the same metalink file they will
all hit the same servers, and someone wanting to support the local
mirrors could start fetching from 1/2-way around the world (I suppose
there would still need to be non-metalink access just for this reason.)
Hmmm, that brings up another question. Each downloadable file would need
its own metalink file. How much space will that take and at what point
would it become significant.
> 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).
Transfers in progress could change servers, or new clients would get a
different server?
The former is what I would be concerned about (additional overhead,
exacerbated by poorly coded or configured clients); the latter would be
a good thing but could also be done with a smart round-robin setup
(maybe already is via http.us.debian.org.)
> 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_ :)
Ya, assuming both are eventually made available from Debian.
> > 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.
Nothing wrong with that. I did much the same thing back in '95(?) with
http when Debian only provided ftp access to the archives (got told
that http was too inefficient. :-)
- Bruce
Reply to: