Re: Summary - Will browsers support multiple proxy servers
Brian Behlendorf wrote:
# On Fri, 30 Jun 1995, Andy Kumeda wrote:
# > The key here is that each server needs to be it's own primary server.
# > Therefore, if the server is down, no DNS info can be given out, thus
# > queries will be sent to the server that is up.
# I respectfully suggest this is very network-unfriendly. The amount of
# "downtime" is directly related to the length of the DNS cache timeouts,
# which means they will probably be set incredibly low - 2 minutes? 10
# minutes? It means the servers will be doing much more DNS work than
# usual. I also find it hard to see how this could handle load-balancing
# adequately, since it looks like DNS lookups are going to return (in your
# case) 188.8.131.52 a lot more frequently than 184.108.40.206, since the
# former is listed as primary for the domain wdc.com. Could you compare the
# WDC-based traffic loads between the two?
# I would say this is the best try yet at trying to make redundancy
# transparant in DNS... but I still think simply having the client test
# latencies of each server would be the most elegant solution.
Brian, I appreciate your comments, and I will attempt to clarify a few
Yes, the cache timeouts are set extremely low -- I don't recall what it
is set at exactly off the top of my head.
Also, you are right in that it does not do 'load-balancing' in the
traditional sense, in fact, as you stated, it goes to the 129.253 system
more frequently, and was intended to do just that. We wanted to
distinguish a 'primary' and a 'secondary' (mirror) server mainly for
administrative purposes, such as updating HTML files. (FWIW, the
'secondary' server currently gets appx 20% of the total hits, and I
suspect that this is mainly due to DNS timeouts to the 'primary' server
who happens to be on a more congested network than the 'secondary'.)
I also like the idea that it should be a client feature, but until ALL
clients support this, the only way it can be done is on the server end.
Thus, this is the reason why I had implemented the solution above.
Believe me, I'll be the first one to get rid of this implementation if
there were an alternative solution, but at this time, I see no other.
# firstname.lastname@example.org email@example.com http://www.[hyperreal,organic].com/
Andy Kumeda -- Consultant Voice: 714.449.8327
InteleNet Communications, Inc. E-mail: firstname.lastname@example.org
30 Executive Park, Suite 265 P-mail: email@example.com
Irvine, CA 92714-6741 URL: http://www.intelenet.net