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) a lot more frequently than, since the 
# former is listed as primary for the domain  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
things below.

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.

# 	Brian
# --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
#  http://www.[hyperreal,organic].com/

Andy Kumeda -- Consultant              Voice:  714.449.8327
InteleNet Communications, Inc.         E-mail:
30 Executive Park, Suite 265           P-mail:
Irvine, CA  92714-6741                 URL:

Received on Friday, 30 June 1995 17:15:20 UTC