Date: Tue, 29 Jan 2002 19:11:05 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: "Jeremy C. Reed" <reed@reedmedia.net> Cc: freebsd-chat@freebsd.org Subject: Re: serving content from the closest server Message-ID: <3C576449.68A33477@mindspring.com> References: <Pine.LNX.4.43.0201291249530.14819-100000@pilchuck.reedmedia.net>
next in thread | previous in thread | raw e-mail | index | archive | help
"Jeremy C. Reed" wrote: > > What are some methods that content delivery services use for serving from > an access point closest to the end user? Ah, content delivery networks! A cool way to distribute your trojan horse cyber warfare attacks, by compromising a single server that is a customer of the content delivery network, and then letting the network replicate your attack everywhere... > Are there DNS servers that count the number of hops between the end user > and the possible webservers, and then reply back with an address that is > closest? This is the Akamai approach. The Akamai approach is inherently technically flawed, since the DNS servers assigned by dialup negotiation ar going to be in West Virginai, as EarthLink buys all ISPs and points the dialup users at their DNS servers, so everyone looks like they are located at their DNS proxy, rather than where their client is really located. Basically, the Akamai approach to content delivery networks incorrectly assumes that the DNS server will be local to the dialup POP that soemone is dialing into, which is not a correct assumption. So a DNS approach can't work. > Or maybe figure out the fastest? This is the FireClick approach, based on the Jeff Mogul paper on templates and incremental content update. The way this works is by running code on the client (a Java or JavaScript application) that provides the real network locality -- unlike the Akami approach, where all clients tend to use DNS servers at the ISP, and appear to be located at the NOC for the ISP. This has the disadvantage of running code on the client, which assumes a lot of things that aren't really true for many devices today, and probably won't be for any, in the long run (but the incremental update approach is still a good idea). > Or are there web servers (or a CGI or Apache module) that count the number > of hops (or the amount of time) between it and the client -- and then > either send a HTTP redirect or modify the HTML image or href links to > point to a closer server? Apache has a number of modules that could be abused for this, but since the lookup is direct each time, you would also have to do URL rewriting. Do a Yahoo search for apache module load balancing And you will find many of them. Really, you are better off with a reverse proxy cache for static content (or even cacheable dynamic content), than trying to set up a content distribution network this way. There are new protocols being designed (Cisco routers even support some of them) that support connection to service instead of connection to a particular server, and HTTP is the first target protocol for most of these. This hearkens back to the very early 1990's, when I first suggested that I don't care where the next 512 frames of "Indiana Jones" come from, so long as they are there to be displayed by the time they are needed. For a new protocol, though, we are pretty much going to have to wait until there is a WinSock interface for it, and then until it's supported in IE and Netscape, for any hope of wide deployment. Just like IPv6 and IPSEC, we see that Microsoft is (as usual) the bottleneck preventing deployment of useful technology, until they can figure out a way to pee on it and make it theirs so that no one can compete with their implementation. 8-(. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C576449.68A33477>