However I feel that
4) It is reasonable for downloaders to use multiple connexions per
mirror, as long as they don't bypass the controls put in place by the
mirror. Not only reasonable, but actually desirable in terms of using
otherwise unused download capacity that occurs from time to time, and
thus enhancing general download access.
This method only works in the following situations:
- The mirror limits the speed of each individual connection
- You use multiple mirrors to download
- If applying to a single file across multiple mirrors, the mirrors
support transfer of selective portions of the requested file
In the first situation, the mirror maintainer usually has a good reason
for limiting connection speed. If their limit is very low, you should
contact the project they are mirroring and suggest they be dropped as an
official mirror. Going around admin-imposed limitations is bad manners
at the very least and will either get you banned or cause further
restrictions that will harm everyone.
In the second situation, you are now taking the bandwidth of multiple
mirrors, increasing the overall load on the mirror network. Use of four
mirrors means you just took up resources that three other people could
have been using. Effectively, you're being greedy to the detriment of
the community.
The third situation presumes a certain configuration that isn't
necessarily true. It also has the same problems as the second situation.
There is another factor that may not have been considered. Many
downloaders will be slowed by their internet access or other
non-mirror factors, which will very much increase the likelihood that
mirrors have unused bandwidth at various times. Increasing the
utility -- from both sides -- of multiple connexions.
That is an argument against multi-mirror downloads. Most mirror servers
will have good bandwidth for their region. In general, the user's
connection will be a bottleneck. The overhead of maintaining multiple
connections can actually _slow down_ the downloads.
As for torrents, there exists a large problem in that there are several
ways to handle such things (torrent per file, torrent per directory,
etc) and on every change you would need the torrent to be regenerated
and seeds to be established. If you are doing this on something with a
lot of file churn such as a development trunk, you run into a ton of
management overhead for handling the torrents. Even if you start with
web seeds, you now strain your mirrors by requesting that they be active
in seeding a bunch of torrents.
Bittorrent makes good sense in one big situation: you have a single
large or multiple files that will be widely downloaded and distributed,
and the downloaders are likely to leave their download tool (torrent
application) running after download. This is especially useful when it's
going to be a large, but temporary, demand such as ISO files at release
time. While some mirrors might be able to handle a 200-300% increase in
traffic, others may not. It's expensive to provision at that capacity
when such a thing only happens twice a year for a week or maybe two. In
such cases, torrents make very good sense as they help reduce the peak
demand on your mirrors.
- Michael
