Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #13028 > unrolled thread

Toward faster international server selection using clever DNS.

Back to article view | Back to comp.lang.java.programmer

Contents

  Toward faster international server selection using clever DNS. Roedy Green <see_website@mindprod.com.invalid> - 2012-03-17 03:36 -0700
    Re: Toward faster international server selection using clever DNS. Jeff Higgins <jeff@invalid.invalid> - 2012-03-17 08:17 -0400
    Re: Toward faster international server selection using clever DNS. Roedy Green <see_website@mindprod.com.invalid> - 2012-03-17 05:45 -0700
    Re: Toward faster international server selection using clever DNS. Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-03-17 09:08 -0500
      Re: Toward faster international server selection using clever DNS. Roedy Green <see_website@mindprod.com.invalid> - 2012-03-18 19:46 -0700
        Re: Toward faster international server selection using clever DNS. Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-03-19 22:23 -0500
        Re: Toward faster international server selection using clever DNS. RedGrittyBrick <RedGrittyBrick@spamweary.invalid> - 2012-03-27 14:51 +0100

#13028 — Toward faster international server selection using clever DNS.

When you type google.com you get sent to google.ca if you live in
Canada.  I presume this works by your request going to google.com in
the USA, where it then figures out you are from Canada and sends back
a redirect,  then you resend your request to google.ca a server in
Canada.  Is that correct?

blogger.com (owned by google) has just started doing this variable
suffix thing too.  All kinds of large companies use this sort of
logic.  Sometimes you must manually select your region.  It strikes me
as inefficient. If the head office is in Taiwan, it is quite slow
(e.g. motherboard manufacturers).

What should happen is the DNS routers in Canada should direct
google.global requests to google.ca. and in the USA to google.com.
You should be able to bypass the country server selector with a
specific google.ca request.

Does it actually work roughly this way already? if not, why? It is
just the inertia holding back extending DNS software in all the
world's servers?

If it does not work this way, or when the server uses the redirect
method,  it suggests I can be kind to my clients in my JSP (the Java
topic tie) by localising links to global enterprises in the generated
HTML so they go directly.  

For example, on every page in the Java glossary is a link to google
that lets you find more information about the topic of the page. This
link could be localised if I were using JSP to dynamically generate
the page.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
One of the most useful comments you can put in a program is 
"If you change this, remember to change ?XXX? too".
 

[toc] | [next] | [standalone]

#13029

On 03/17/2012 06:36 AM, Roedy Green wrote:
> When you type google.com you get sent to google.ca if you live in
> Canada.  I presume this works by your request going to google.com in
> the USA, where it then figures out you are from Canada and sends back
> a redirect,  then you resend your request to google.ca a server in
> Canada.  Is that correct?
>
> blogger.com (owned by google) has just started doing this variable
> suffix thing too.  All kinds of large companies use this sort of
> logic.  Sometimes you must manually select your region.  It strikes me
> as inefficient. If the head office is in Taiwan, it is quite slow
> (e.g. motherboard manufacturers).
>
> What should happen is the DNS routers in Canada should direct
> google.global requests to google.ca. and in the USA to google.com.
> You should be able to bypass the country server selector with a
> specific google.ca request.
>
> Does it actually work roughly this way already? if not, why? It is
> just the inertia holding back extending DNS software in all the
> world's servers?

<http://www.zytrax.com/books/dns/>
<http://tools.ietf.org/html/rfc3439>

>
> If it does not work this way, or when the server uses the redirect
> method,  it suggests I can be kind to my clients in my JSP (the Java
> topic tie) by localising links to global enterprises in the generated
> HTML so they go directly.
>
> For example, on every page in the Java glossary is a link to google
> that lets you find more information about the topic of the page. This
> link could be localised if I were using JSP to dynamically generate
> the page.

[toc] | [prev] | [next] | [standalone]

#13030

On Sat, 17 Mar 2012 03:36:16 -0700, Roedy Green
<see_website@mindprod.com.invalid> wrote, quoted or indirectly quoted
someone who said :

>For example, on every page in the Java glossary is a link to google
>that lets you find more information about the topic of the page. This
>link could be localised if I were using JSP to dynamically generate
>the page.

I have developed this idea further at
http://mindprod.com/project/routing.html
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
It is almost impossible to keep things in synch manually. Instead: 
-Keep each fact in only one central database (not necessarily SQL),
and access it as needed. Since there is only one copy of each fact, 
there is nothing to get out of synch.
-Use some automated tool so that if you change a fact is one place,
it automatically updates the others.
-Write a sanity checker you run periodically to ensure all is consistent. 
This is the strategy compilers use.
-Document the procedures needed to keep all in synch if you change 
something and rigidly and mechanically follow them.

[toc] | [prev] | [next] | [standalone]

#13032

On 3/17/2012 5:36 AM, Roedy Green wrote:
> When you type google.com you get sent to google.ca if you live in
> Canada.  I presume this works by your request going to google.com in
> the USA, where it then figures out you are from Canada and sends back
> a redirect,  then you resend your request to google.ca a server in
> Canada.  Is that correct?

No. Most servers probably do the global domain name switching via a 
vhost-based similar on their webservers; they otherwise go to the same 
computer(s). The point of server selection is to do appropriate 
regionalization based on the user's preferences, which often has nothing 
to do with the physical location of a user.


> What should happen is the DNS routers in Canada should direct
> google.global requests to google.ca. and in the USA to google.com.
> You should be able to bypass the country server selector with a
> specific google.ca request.

Note that people already use DNS to point you to the closest physical 
servers you have access to, along with load balancing tricks. Basically, 
the problem you are trying to solve is already more or less solved.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#13042

On Sat, 17 Mar 2012 09:08:39 -0500, Joshua Cranmer
<Pidgeot18@verizon.invalid> wrote, quoted or indirectly quoted someone
who said :

>Note that people already use DNS to point you to the closest physical 
>servers you have access to, along with load balancing tricks. Basically, 
>the problem you are trying to solve is already more or less solved.

Oddly though, Google does not do this.  I watched it with Wireshark.
So there still might be value is localising Google links in your JSP.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
It is almost impossible to keep things in synch manually. Instead: 
-Keep each fact in only one central database (not necessarily SQL),
and access it as needed. Since there is only one copy of each fact, 
there is nothing to get out of synch.
-Use some automated tool so that if you change a fact is one place,
it automatically updates the others.
-Write a sanity checker you run periodically to ensure all is consistent. 
This is the strategy compilers use.
-Document the procedures needed to keep all in synch if you change 
something and rigidly and mechanically follow them.

[toc] | [prev] | [next] | [standalone]

#13069

On 3/18/2012 9:46 PM, Roedy Green wrote:
> On Sat, 17 Mar 2012 09:08:39 -0500, Joshua Cranmer
> <Pidgeot18@verizon.invalid>  wrote, quoted or indirectly quoted someone
> who said :
>
>> Note that people already use DNS to point you to the closest physical
>> servers you have access to, along with load balancing tricks. Basically,
>> the problem you are trying to solve is already more or less solved.
>
> Oddly though, Google does not do this.  I watched it with Wireshark.
> So there still might be value is localising Google links in your JSP.

What do you mean by this? If, for example, I do a traceroute to 
google.co.at and another to google.com, the route is exactly the same 
except for the final server. Judging from whois data, the servers for 
both domains are located in Wisconsin, whereas the host computer I 
queried from is in Illinois. Given the politics of how ISPs connect to 
each other, this is not an unreasonable result (the traffic is forwarded 
via what appear to be primarily academic transit links, so I presume 
that the amount of money that changes hands for the bandwidth in 
question is exactly $0).

Repeating a traceroute from a computer located in another state for the 
same domain name produced a different IP address, accessed via a 
different set of intermediate hops. I can't map these to physical server 
locations, but knowing a little about ISP infrastructures, I suspect 
that the server is likely within 20 miles of my location (I happen to be 
geographically close to a cluster of major internet exchanges--over half 
of the DNS root nameservers have a home in the area).
-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#13223

On 19/03/2012 02:46, Roedy Green wrote:
> On Sat, 17 Mar 2012 09:08:39 -0500, Joshua Cranmer
> <Pidgeot18@verizon.invalid>  wrote, quoted or indirectly quoted someone
> who said :
>
>> Note that people already use DNS to point you to the closest physical
>> servers you have access to, along with load balancing tricks. Basically,
>> the problem you are trying to solve is already more or less solved.
>
> Oddly though, Google does not do this.  I watched it with Wireshark.
> So there still might be value is localising Google links in your JSP.

I'm not sure how Roedy's idea is an improvement over what firms like 
Akamai have been doing for nearly fifteen years?

http://en.wikipedia.org/wiki/Akamai_Technologies#Content_delivery_to_a_user

-- 
RGB

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web