[Date Index]
[Thread Index]

[Date Prev] bullet [Date Next] bullet [Thread Prev] bullet [Thread Next]
bullet
Re: http hack
bullet bullet bullet bullet


>I've been trying to solve a problem for a while and somebody said
>you might be working on the same thing. I want to have users who
>enter in a URL (http://park.org/) be moved over to the appropriate
>machine in Central Park (our 12 servers around the world) to get
>their information.
>
>I talked to Vixie about hacking BIND by putting in a table of
>CIDR Mask (IP, Subnet), ip of correct answer. That turned ugly. :)
>
>Current hack is to go into our httpd. We're willing to configure
>this manually by specifying border as's (e.g, the ones on the
>"edge" of Japan ... if your IP address is inside of that boundary,
>you get the address back of the host we have in Japan).
>
>Any ideas on this? Note that plain old load balancing doesn't
>cut it on this one ... the worst thing we can do is send a bunch
>of traffic from across the ocean into Korea.

Hi Carl. Your message was forwarded to me by Kim. I'd love to help out with the http hacking. I have a scheme which will work (a couple actually). The only part I don't know how to do is map IP addresses to AS's. Is it just a (large) table lookup?

Both ideas depend on your HTTP document tree using relative URL addressing wherever possible. I also assume you'll be able to live with naming each server differently (eg jp.park.org, us.park.org, au.park.org).

One idea is to have the server checking the requsting IP address. If the client and server are in the same AS then return the requested document. Otherwise return an HTTP redirect to the proper server.

Another idea is to include a "BASE" HTML element in each HTML document. The contents of the BASE element will be generated dynamically for each request. If the client is in Japan and they request document "/Info" from the US server, they get back that page with this stuck in:

<BASE HREF="http://jp.park.org/Info">

Then future requests would be made to the jp.park.org server.

The first idea is probably simpler to implement. The second is nice because it avoids the HTTP redirect (and associated delay). If your server is going to be very busy then the first idea probably imposes less load. And, if you don't want to modify the HTTP server, the first idea could be implemented totally separately as well.

Duane W.

bullet
[Date Prev] bullet [Date Next] bullet [Thread Prev] bullet [Thread Next]
bullet