Re: Mirror Negotiation

Brian,

> From www-talk-request@w3.org Mon Dec  9 14:01 PST 1996
> From: Brian Morin <bmorin@WPI.EDU>
> 
> An emerging trend on the web is to offer the same information at multiple
> locations to increase performance, ie mirroring.  This has been done with
> FTP for years.
> 
> The way this is often done is by offering users a list of mirror sites and
> having them select one from the list.  However, I do not feel this is a
> decision that is best made by the user.  How does a user know what mirror
> is best?  If the sites I frequent are all mirrored, why should I go
> through the inconvenience of selecting a mirror each visit?
> 
> Mirror selection can be done by the server within the constraints of
> HTTP/1.0, however I do not feel that this is not a decision the server
> should be making.  The server does not know where the client is nor is
> the server in a position to test one or more mirrors to see which is
> best.
> 
> Therefore I see potential in having the client involved in the decision
> of where to get information.
> 
> In all of the flavors of HTTP I've seen, the only grammar for negotiating
> where information is retrieved from is the simple redirect from the server.
> Would it be a good idea to send a list of alternative locations a resource
> or a group of resources can be acquired so the client can select the fastest
> location without user involvement?

I think a general framework based on a combination of the following
mechanisms to extend the basic request/response metaphor to provide for
(mirror) location selection will provide a clean and uniform architecture for
location resolution specification. Note that such a scheme would provide the
required separation of mechanism and policy with a default policy
specification which can be information specific.

1) standard encoding for mirrored information

	This would provide a uniform URL structure to indicate that the
	information may be mirrored and further negotiations and policy
	resolution can be used to select the location best suited to get
	the information. The uniform URL structure can be patterned as
	gr<type>.<resource/information-identifier>.<master-location>,
	wherein, the gr<type> indicates that the information may be mirrored
	(replicated). For example, grftp may mean that the file is possibly
	replicated. grhttp would mean that the hypertext information is
	replicated and so on. The <resource/information-identifier> would
	provide a unique resource/information identifier and <master-location>
	would provide a means to specify atleast one known master server.

2) client based mirrored information server resolution

	This could be used to specify the client specific information
	location server resolution policy. Typically this can be split
	between location resolution related negotiations to get server
	charactertistics and the use of the specified location resolution
	policy to identify a target server.

3) server based mirrored information server resolution

	This could be used to specify a default information location server
	resolution policy. This would include the location resolution related
	negotiation to get clients' characteristics and use of the specified
	server resolution policy to identify a target server.

Govind

Received on Monday, 9 December 1996 18:14:47 UTC