- From: Brad Block <bradb@s1.ganet.net>
- Date: Sun, 14 Jul 1996 10:10:12 -0400 (EDT)
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Hello, First of all, I would like to take this time to express the great relief I have found after reading through this list. I have been struggling with the task of automated server replication and designing a mission-critical implementation of a web server for quite some time. During the period in which I have considered options, I have concluded at least two important points which I have not yet seen in this thread: (BTW, I like the multiple "Link:" response solution and I am basing my suggestions on it or a similair convention) 1. Server replication must include link-state information - take it from the IP working groups who develop OSPF and other link-state aware protocols - no need to reinvent the wheel - this could be implemented at both the server and browser level much like MX preference records are preassigned at the DNS level - accordingly, at the browser level or at some other authority, a table of information about candidate servers should be maintained for fast lookup with preferences accounting for everything from country codes to avg. response time 2. Some authority other than http servers may be used - in order for the browser to retrieve the initial multiple "Link:" responses, it has to contact the only server it knows about - the primary original server indicated by the URL. if that server is down or otherwise unable to communicate information about other "Link:"'ed replicated servers, then all efforts are lost - some kind of analogy can be drawn by understanding why multiple name servers should be placed on different physical networks so that loosing a single network will not render hosts actually located on different networks unresolvable I look forward to replies and comments! - Thank you! Brad Block
Received on Sunday, 14 July 1996 07:30:06 UTC