Current mirroring support in Eclipse Install/Update was added on the request of Eclipse foundation just before Eclipse 3.1 went live in order to help with the traffic spikes during the release times. However, its current implementation leaves a lot to be desired. It requires too much of the annoying user interaction and currently there is no way around this (bug 97806). In addition, there is no standard way for the user to select the correct mirror.
At the moment we support mirrors using optional mirrorsURL
attribute in the site tag of site.xml which points to an xml file that contains the
update site mirror definitions. This file has mirrors
defined by the mirror tag with attributes that define mirror's name and URL. Once
Update detects mirrorsURL attribute in the site tag of site.xml it downloads
the file and pops up a dialog with a list of
mirrors for the user to select.
We would like to improve the mirroring support in Eclipse Install/Update and have the following goals:
There are several possible options to improve the mirror handling. They can be first classified based on the place where mirror determination takes place (client or server). Client-side choices can be further classified based on the algorithm used to determine the best mirror.
As its name says this algorithm works based on geographic proximity of the mirror to client and usually countries are used for determining proximity.
Issues:
This algorithm works by measuring cost (number of hops) of connecting to different mirrors. It is a better algorithm since it calculates the real cost, not the estimated cost.
Issues:
Mirroring support is usually put on the server. There are several reasons for this. It is much easier to change mirror selecting logic. It is also much easier to update data that mirroring logic uses to select correct mirrors. Finally, servers usually know more about networks and other servers then clients. Work in update to support server side mirror selection is very limited, since update has only to understand one of the two standard ways that 'redirect' instructions from the server are issued. These two standard ways are:
If we decide to go with client side solution we will have to define extension point to support plugging of algorithms from other sources, and extend definitions of the site tag in site.xml and mirror tag in the mirrors definition file to support this. It would be done as follows:
A new extension point will be added to the Install/Update Core plug-in:
<extension point="org.eclipse.update.core.mirrorSorter">
<sorter
id="com.example.xyz.MirrorSorter"
class="com.example.xyz.update.XYZMirrorSorter"
/>
</extension>
The extension point provides for registering a mirror sorter with a unique
identifier referenced from within the site.xml using the newly added
sorter-id attribute.
All of the extender classes must implement following interface:
public interface IMirrorSorter {
/**
* Accepts a list of mirrors as defined in the definition file and sorts them based on
* preferred use, with the best mirrors at the head of the list.
* @param candidates mirrors to sort
* @return the ordered list of mirrors (the best mirrors first)
*/
public IMirror[] sort(IMirror[] candidates);
}
public interface IMirror {
/**
* Returns the URL as a string (as defined in the mirror definition file)
* @return mirror URL as a string
*/
public String getAddress();
/**
* Returns the mirror label (as defined in the mirror definition file)
* @return mirror label
*/
public String getLabel();
/**
* Returns mirror property value given the property name
* @return value of the named mirror property or <code>null</code> if not defined
*/
public String getProperty(String name);
}
<!ATTLIST site
type CDATA #IMPLIED
url CDATA #IMPLIED
mirrorsURL CDATA #IMPLIED
sorter-id CDATA #IMPLIED
>
where sorter-id represents the identifier of the mirror sorting class that is
registered user of extension point mirrorSorter. If sorter-id is not present,
the default sorter provided by Install/Update will be used (the exact identifier
to be defined).
<!ELEMENT mirror (property*)>
<!ELEMENT properties><!ATTLIST property
name CDATA #REQUIRED
value CDATA #REQUIRED
>
wherepropertyelement carries sorter-specific information that can be used to determine suitable mirror.
An issue with both of the client-side options above is that they are based on the assumption that all mirrors are created equal i.e. they have same performance. In our case, this is not true. We can try to alleviate this issue by assigning mirror ratings and use them in our calculations as follows:
Region, Country, State/Province, Time Zone
Region, Region, Weight
Install/Update will use the list of mirrors obtained from the sorter by looping through it until we get the response from one of them. This would allow us to skip the unresponsive mirrors.
This solution does not address the problem where the user and his/hers gateway is not in the physical proximity of each other.
As previously mentioned, the beauty of the server side solution is
that we do not have to define mirror selection algorithm in advance. It
can be changed on the fly and on each site independently. However we
should decide in advance which method of redirecting we will use
(although both can be supported at the same time). There are several
ways to do this that in use on the web:
Since the second solution is HTML specific and the third requires a
JavaScript interpreter we suggest using the HTTP 300 status code with a
sorted list of provided mirrors. Sorting can be done using either the
client's IP address and an IP to Geographical location database,
using a client provided location (using a GET request issued by the
client with 'country' and either 'time zone' or 'state/province' as
parameters), or some other way that can be devised by the site
implementing mirroring support. In any case using client provided
location information, a server-side algorithm similar to the one
presented for the client side solution can be used. Our proposal is for
the update to pass the location information at all times and let the
server decide if it wants to use it. This way we will not dictate the
choice of algorithms in advance.
Provided here is a php script with configuration files that will sort mirrors based on the client's country and time zone. Country and time zone are expected to be provided by as GET parameters. We have adopted the above mentioned default mirror sorter for the client side solution (one difference is that mirrors are in the CSV file and we did not do mirror rating). As an added bonus, this script can be used to generate sorted mirrors lists for current implementations of mirror support. We also provide patches for the org.eclipse.update.core and org.eclipse.update.ui plug-ins of the Update component that enables the script to be used in this manner. These patches add the "Automatically select mirror" checkbox on the Update preferences page. When checked, Update will automatically select the mirror from the mirror list. Also, the timeZone and countryCode parameters are added to every mirror request.
Server side solutions can also resolve issues of a user's location differing from their gateway location. For example, it is well known what IP address ranges are used by certain large organizations and where their internet gateways are located and this can be included in the decision making process.
We recommend that the server-side solution is selected for handling mirrors in the Update component.
Note: All files contained herein are provided as is. If they are to be used in production environments, error checking and other miscellaneous improvements should be added.