incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject Re: [DL LOGIC] How to choose a mirror when more than 1 is available?
Date Sat, 07 Apr 2012 16:21:49 GMT

> From: Rob Weir <>
>Sent: Saturday, April 7, 2012 12:14 PM
>Subject: Re: [DL LOGIC] How to choose a mirror when more than 1 is available?
>On Sat, Apr 7, 2012 at 11:45 AM, Joe Schaefer <> wrote:
>> Not true re Apache mirror system scripting.  While
>> some people avoid the ezt templating involved in a typical
>> download page by just using closer.cgi, the fact is
>> that most projects use it successfully.  For example
>> see httpd's download page with links generated by the download
>> script pointing directly at a mirror url.
>Joe -- your top-posting makes it a little unclear what you are
>referring to.  But if you are talking about a way to get a link
>directly to a confirmed Apache mirror download rather than showing the
>user an intermediate page, I'd love to hear more, a pointer to some
>doc, etc.

I don't know where this is documented off the top of my head,
but the best CMS-based example is
There is a standard dowload cgi script in cgi-bin/download.cgi and
a corresponding ezt template in content/download.mdtext.

Just look it over and ask if you have any questions about how it works.

(FTR the 'cd' in the script is no longer necessary).

>>> From: Rob Weir <>
>>>Sent: Saturday, April 7, 2012 11:34 AM
>>>Subject: Re: [DL LOGIC] How to choose a mirror when more than 1 is available?
>>>On Sat, Apr 7, 2012 at 10:13 AM, Marcus (OOo) <> wrote:
>>>> For our new release we will have a changed set of conditions:
>>>> - new central mirror hosts for redirecting download requests
>>>> - therefore also a new set of mirror server that host our builds
>>>> - new set of supported platforms and languages
>>>> - slighty changed file name schema
>>>> To get this all under one hat, we have to improve the download logic that
>>>> currently done by JavaScript.
>>>> To fulfill the first condition the download requests have to be split-up
>>>> more than 1 central mirror redirector.
>>>> Here is a suggestion for choosing when (by random number) to redirect to
>>>> which mirror:
>>>> Test results:
>>>> - to make debugging easier I've included some screen output and comments
>>>> - I've tested it locally with different combinations of active/inactive
>>>>  hosts and it works well
>>>> - the fallback method works well, too
>>>> - I've tested different percent values as ratio, but not yet for the
>>>>  2nd case
>>>> What do you think?
>>>The logic on the test pages works for me.
>>>But two additional complexities:
>>>1)  MirrorBrain let's us link directly to a download file.  We then
>>>send the user to
>>>while the file is downloading.  But SourceForge and Apache mirror
>>>systems take the user to a different page (not controlled by us). So
>>>in those cases the user does not see the contribute.html page.
>>>Since the contribute.html page has very useful information for the
>>>user, like links to the install instructions, information on support,
>>>contributing to the project, etc., I think it is important that the
>>>user sees this information in all paths.
>>>What could we do? Pop-up (or pop-under) a new HTML page?  But that is
>>>annoying to some users.
>>>The Apache and SF approaches both direct a user off of the
>>> website, which is risky.
>>>2) What if we have more than three mirror systems?  It sounds like you
>>>prefer to keep MirrorBrain.  That is fine with me. So maybe we have
>>>Apache, SF and MirrorBrain?
>>>Imagine an array of mirror networks, each with weights, in sorted
>>>order from smallest to largest.  (or sort the array in code)
>>>TotalWeight =  MirrorBrain + Apache + SourceForge == 6
>>>x = rand()
>>>if (x < Apache/TotalWeight)
>>>    doApache()
>>>else if (x < MirrorBrain/TotalWeight)
>>>    doMirrorBrain()
>>>    doSourceForge()
>>>Something like that.
>>>> Marcus

View raw message