diff options
Diffstat (limited to 'zarb-ml/mageia-dev/20110118/002219.html')
| -rw-r--r-- | zarb-ml/mageia-dev/20110118/002219.html | 171 |
1 files changed, 171 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/20110118/002219.html b/zarb-ml/mageia-dev/20110118/002219.html new file mode 100644 index 000000000..41ca71d19 --- /dev/null +++ b/zarb-ml/mageia-dev/20110118/002219.html @@ -0,0 +1,171 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Proposal%20for%20Mageia%3A%20implement%20bitorrent%09protocol%0A%20to%20allow%20updates%20download&In-Reply-To=%3C4D355138.9020107%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="002216.html"> + <LINK REL="Next" HREF="002218.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download</H1> + <B>andre999</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Proposal%20for%20Mageia%3A%20implement%20bitorrent%09protocol%0A%20to%20allow%20updates%20download&In-Reply-To=%3C4D355138.9020107%40laposte.net%3E" + TITLE="[Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download">andr55 at laposte.net + </A><BR> + <I>Tue Jan 18 09:37:12 CET 2011</I> + <P><UL> + <LI>Previous message: <A HREF="002216.html">[Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download +</A></li> + <LI>Next message: <A HREF="002218.html">[Mageia-dev] mailing list for new RPMs +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#2219">[ date ]</a> + <a href="thread.html#2219">[ thread ]</a> + <a href="subject.html#2219">[ subject ]</a> + <a href="author.html#2219">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Motoko-chan a écrit : +><i> +</I>><i> +</I>>><i> However I feel that +</I>>><i> 4) It is reasonable for downloaders to use multiple connexions per +</I>>><i> mirror, as long as they don't bypass the controls put in place by the +</I>>><i> mirror. Not only reasonable, but actually desirable in terms of using +</I>>><i> otherwise unused download capacity that occurs from time to time, and +</I>>><i> thus enhancing general download access. +</I>><i> +</I>><i> This method only works in the following situations: +</I>><i> +</I>><i> - The mirror limits the speed of each individual connection +</I>><i> - You use multiple mirrors to download +</I>><i> - If applying to a single file across multiple mirrors, the mirrors +</I>><i> support transfer of selective portions of the requested file +</I>><i> +</I>><i> In the first situation, the mirror maintainer usually has a good reason +</I>><i> for limiting connection speed. If their limit is very low, you should +</I>><i> contact the project they are mirroring and suggest they be dropped as an +</I>><i> official mirror. Going around admin-imposed limitations is bad manners +</I>><i> at the very least and will either get you banned or cause further +</I>><i> restrictions that will harm everyone. +</I> +Many mirror sites do restrict multiple connexions (per user), so +evidently it is readily done. If a mirror chooses not to make such +restrictions, that is their choice. It is not good form (to put it +mildly) for some mirrors to try to dictate mirror policy for other +mirrors, which could have different interests. +Limiting the connexion speed could be an easy way to ensure that usually +everyone who wishes to connect can do so in busy times. In less busy +times, multiple connexions to such mirrors causes no problem. +Software such as aria2c monitors the download speed of connexions, and +will avoid slower connexions, thus balancing use of available download +ressources between mirrors. + +><i> In the second situation, you are now taking the bandwidth of multiple +</I>><i> mirrors, increasing the overall load on the mirror network. Use of four +</I>><i> mirrors means you just took up resources that three other people could +</I>><i> have been using. Effectively, you're being greedy to the detriment of +</I>><i> the community. +</I> +So for 2 hours one uses 4x download ressources instead of 8 hours of x +download ressources. In both cases using 8x ressources. +A simple elementary school calculation. +For large files, such as ISOs, it makes a big different to the user. +Globally, it makes no difference collectively to the mirrors. Except +that downloading will tend to be balanced between mirrors if software +such as aria2c is used. And mirrors with free download ressources are +more likely to be more fully used. +(One could always quibble about the overhead per connexion, but that is +relatively minor compared to the download itself.) + +><i> The third situation presumes a certain configuration that isn't +</I>><i> necessarily true. It also has the same problems as the second situation. +</I> +The third case is generally true for ftp mirrors, as well as many http +mirrors. Where it is not, aria2c and similar software will not use the +mirror. + +Don't forget that the major target of multiple connexions will be the +larger/faster mirrors, thus taking load off smaller mirrors. (Since +applications like aria2c favour faster connexions.) + +>><i> There is another factor that may not have been considered. Many +</I>>><i> downloaders will be slowed by their internet access or other +</I>>><i> non-mirror factors, which will very much increase the likelihood that +</I>>><i> mirrors have unused bandwidth at various times. Increasing the utility +</I>>><i> -- from both sides -- of multiple connexions. +</I>><i> +</I>><i> That is an argument against multi-mirror downloads. Most mirror servers +</I>><i> will have good bandwidth for their region. In general, the user's +</I>><i> connection will be a bottleneck. The overhead of maintaining multiple +</I>><i> connections can actually _slow down_ the downloads. +</I> +So you believe that unused download bandwith should not be used ? +Sounds like that would _really_ help downloaders -- and other mirrors. + +Among the potential non-mirror factors which could limit the download +speed is the capacity of the download path. Multiple connexions spread +the download over multiple paths, minimising this potential bottleneck. + +><i> As for torrents, there exists a large problem in that there are several +</I>><i> ways to handle such things (torrent per file, torrent per directory, +</I>><i> etc) and on every change you would need the torrent to be regenerated +</I>><i> and seeds to be established. If you are doing this on something with a +</I>><i> lot of file churn such as a development trunk, you run into a ton of +</I>><i> management overhead for handling the torrents. Even if you start with +</I>><i> web seeds, you now strain your mirrors by requesting that they be active +</I>><i> in seeding a bunch of torrents. +</I>><i> +</I>><i> Bittorrent makes good sense in one big situation: you have a single +</I>><i> large or multiple files that will be widely downloaded and distributed, +</I>><i> and the downloaders are likely to leave their download tool (torrent +</I>><i> application) running after download. This is especially useful when it's +</I>><i> going to be a large, but temporary, demand such as ISO files at release +</I>><i> time. While some mirrors might be able to handle a 200-300% increase in +</I>><i> traffic, others may not. It's expensive to provision at that capacity +</I>><i> when such a thing only happens twice a year for a week or maybe two. In +</I>><i> such cases, torrents make very good sense as they help reduce the peak +</I>><i> demand on your mirrors. +</I> +Evidently you understand the bittorent issue. +Note that it is essentially those with faster download/upload speeds +that act as secondary mirrors that provide the benefit. Many users +can't offer that. +Interesting that you acknowlege the variation in demand in discussing +bittorent. Which implies that some capacity is not always used. Which +applies to the multiple connexion issue. + +><i> - Michael +</I> +Regards :) + +-- +André +</PRE> + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="002216.html">[Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download +</A></li> + <LI>Next message: <A HREF="002218.html">[Mageia-dev] mailing list for new RPMs +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#2219">[ date ]</a> + <a href="thread.html#2219">[ thread ]</a> + <a href="subject.html#2219">[ subject ]</a> + <a href="author.html#2219">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev +mailing list</a><br> +</body></html> |