«

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".

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.

On Sat, 17 Mar 2012 03:36:16 -0700, Roedy Green
<> 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.

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

On Sat, 17 Mar 2012 09:08:39 -0500, Joshua Cranmer
<> 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.

On 3/18/2012 9:46 PM, Roedy Green wrote:
> On Sat, 17 Mar 2012 09:08:39 -0500, Joshua Cranmer
> <> 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

On 19/03/2012 02:46, Roedy Green wrote:
> On Sat, 17 Mar 2012 09:08:39 -0500, Joshua Cranmer
> <> 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_...very_to_a_user

--
RGB

On 3/17/2012 8:45 AM, Roedy Green wrote:
> On Sat, 17 Mar 2012 03:36:16 -0700, Roedy Green
> <> 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

You are mixing up two problems:
1) delivering localized content
2) route traffic to server that is close network wise

Problem #1 has standard solutions in most web technologies.

Problem #2 was solved in 1998 by Akamai (they do not use a
special domain just the company's main domain).

Arne