Euronode: Difference between revisions

From Genecats
Jump to navigationJump to search
(Created page with "Category:Browser Development == This pages describes the way the euronode mirror works == We are moving to a system where we have geographically specific servers (nodes); ...")
 
Line 8: Line 8:
The node for a given server is specified in the hg.conf file; e.g. the machines in california will have the following in their hg.conf file:
The node for a given server is specified in the hg.conf file; e.g. the machines in california will have the following in their hg.conf file:


<nowiki>
browser.node=1
browser.node=1
</nowiki>


The euronode will have:
The euronode will have:


<nowiki>
browser.node=2
browser.node=2
</nowiki>


We may add other nodes in the future (e.g. in asia).
We may add other nodes in the future (e.g. in asia).


The table hgFixed.gbNodeReal contains the metadata for each node (e.g. domain, country and description).
The table <tt>hgFixed.gbNodeReal</tt> contains the metadata for each node (e.g. domain, country and description).


The table hgcentral.geoIpNode is used to map a user's IP to the appropriate node. If an IP is not found in geoIpNode, the system assumes the user belongs in node 1 (UCSC).
The table <tt>hgcentral.geoIpNode</tt> is used to map a user's IP to the appropriate node. If an IP is not found in geoIpNode, the system assumes the user belongs in node 1 (UCSC).


hgcentral.geoIpNode is based on hgFixed.geoIpNode, which built by Galt using a publicly available IP => country mapping database. The copy in hgcentral may be modified (e.g. to add the IP used by QA team for testing).
hgcentral.geoIpNode is based on <tt>hgFixed.geoIpNode</tt>, which built by Galt using a publicly available IP => country mapping database. The copy in hgcentral may be modified (e.g. to add the IP used by QA team for testing).


Note that the IP's are stored in the tables using a numeric representation (for speed). mysql has a built in function, INET_ATON, which can be used to convert the dotted notation to the numeric form; e.g. to add a new entry to geoIpNode:
Note that the IP's are stored in the tables using a numeric representation (for speed). mysql has a built in function, <tt>INET_ATON</tt>, which can be used to convert the dotted notation to the numeric form; e.g. to add a new entry to geoIpNode:


<nowiki>
hgsql hgcentral -s -e "insert into geoIpNode VALUES (INET_ATON('128.114.49.36'), INET_ATON('128.114.49.36'), 2)"
hgsql hgcentral -s -e "insert into geoIpNode VALUES (INET_ATON('128.114.49.36'), INET_ATON('128.114.49.36'), 2)"
 
</nowiki>
== Where Does Redirection Happen? ==
 
An important limitation of these mirrors is that sessions are NOT shared between the different nodes.
 
Users are only redirected via hgGateway; e.g. if a european goes directly to <tt>http://genome.ucsc.edu/cgi-bin/hgTracks</tt>, they will not be redirected back to europe. The rationale for this is that such links may include sessions that are specific to the California mirror.
 
The first time a user is redirected, they will see a little dialog box at the top of hgGateway that let's them override the redirect; e.g. if user X is redirected to euronode, they may click on the link in the box to get back to the Californian hgGateway. This action is remembered with a cookie stored in the user's web browser (in this example, the cookie would be <tt>redirect=genome.ucsc.edu</tt>). This cookie is not cleared by a cartReset (this is intentional). The user will always be able to switch which mirror they are using via a to-be-designed UI.

Revision as of 01:10, 19 April 2012


This pages describes the way the euronode mirror works

We are moving to a system where we have geographically specific servers (nodes); we will try to direct users to the node which is appropriate for them.

The node for a given server is specified in the hg.conf file; e.g. the machines in california will have the following in their hg.conf file:

browser.node=1

The euronode will have:

browser.node=2

We may add other nodes in the future (e.g. in asia).

The table hgFixed.gbNodeReal contains the metadata for each node (e.g. domain, country and description).

The table hgcentral.geoIpNode is used to map a user's IP to the appropriate node. If an IP is not found in geoIpNode, the system assumes the user belongs in node 1 (UCSC).

hgcentral.geoIpNode is based on hgFixed.geoIpNode, which built by Galt using a publicly available IP => country mapping database. The copy in hgcentral may be modified (e.g. to add the IP used by QA team for testing).

Note that the IP's are stored in the tables using a numeric representation (for speed). mysql has a built in function, INET_ATON, which can be used to convert the dotted notation to the numeric form; e.g. to add a new entry to geoIpNode:

hgsql hgcentral -s -e "insert into geoIpNode VALUES (INET_ATON('128.114.49.36'), INET_ATON('128.114.49.36'), 2)"

Where Does Redirection Happen?

An important limitation of these mirrors is that sessions are NOT shared between the different nodes.

Users are only redirected via hgGateway; e.g. if a european goes directly to http://genome.ucsc.edu/cgi-bin/hgTracks, they will not be redirected back to europe. The rationale for this is that such links may include sessions that are specific to the California mirror.

The first time a user is redirected, they will see a little dialog box at the top of hgGateway that let's them override the redirect; e.g. if user X is redirected to euronode, they may click on the link in the box to get back to the Californian hgGateway. This action is remembered with a cookie stored in the user's web browser (in this example, the cookie would be redirect=genome.ucsc.edu). This cookie is not cleared by a cartReset (this is intentional). The user will always be able to switch which mirror they are using via a to-be-designed UI.