summaryrefslogtreecommitdiffstats
path: root/wiki/src/blueprint/HTTP_mirror_pool.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'wiki/src/blueprint/HTTP_mirror_pool.mdwn')
-rw-r--r--wiki/src/blueprint/HTTP_mirror_pool.mdwn18
1 files changed, 9 insertions, 9 deletions
diff --git a/wiki/src/blueprint/HTTP_mirror_pool.mdwn b/wiki/src/blueprint/HTTP_mirror_pool.mdwn
index 36d2516..6a5fafd 100644
--- a/wiki/src/blueprint/HTTP_mirror_pool.mdwn
+++ b/wiki/src/blueprint/HTTP_mirror_pool.mdwn
@@ -1,14 +1,5 @@
**Ticket**: [[!tails_ticket 7161]]
-The idea I had was to let the server(s) send a reduced list of hosts. Not
-only it would allow to work-around Tor DNS limitations, but also to have
-some weighted round robin, in order to prioritize some high bandwidth
-mirrors, if we choose to.
-
-If I had to mention the ideal design goals for such changes, I would say
-that the more straightforward would be the better for implementation and
-also for maintainability.
-
[[!toc levels=3]]
# The plan
@@ -42,6 +33,15 @@ We decided to implement a two-way strategy for this feature:
# Initial research
+The idea I had was to let the server(s) send a reduced list of hosts. Not
+only it would allow to work-around Tor DNS limitations, but also to have
+some weighted round robin, in order to prioritize some high bandwidth
+mirrors, if we choose to.
+
+If I had to mention the ideal design goals for such changes, I would say
+that the more straightforward would be the better for implementation and
+also for maintainability.
+
## Using DNS
Using DNS seems to be an easy way to do some round robin in low level. It