Re: Indirect references -Reply

> 
> I agree--what you suggest is very much needed. The "URN" proposals are an
> attempt to accomplish this. By way of analogy, we refer to a book via an
> ISBN, which identifies the book, rather than the store and shelf which hosts it.
> 
> For example, if I want to get a copy of RFC 1866, I don't care were it comes
> from, only that it arrives efficiently and is a legitimate copy. The
> InterNIC in this case has quite a few mirrors around the world, and lots of
> others have copies as well.
> 
> I've attempted to follow this development, but am not as knowledgable as I
> might like. My notes at http://www.ccs.org/validate/wwwspec5.html may be
> helpful to you.
> 
> Good luck.  /Harold
> 
> At 13:54 3/3/96 +0800, Teoh Teik Huat wrote:
> >> 
> >> Don't redirects solve that?  I mean, if you're running
> >> a spider (I run MOMspider) you'll see the redirects
> >> and update the links.
> >> 
> >> I thought everyone was doing this.   What I do 
> >> is run MOMspider once a week, and update
> >> redirected links to their new location.  If I change
> >> the location of my pages, I usually re-direct for a while,
> >> then stop (since everyone else who was running a
> >> spider has noticed that the location has changed).
> >> 
> >> Also, a lot of servers have virtual paths, so you 
> >> could be doing the same thing with that.
> >> 
> >> >>> Bryan A. Bentz <bentz@martigny.ai.mit.edu> - 3/2/96 10:26 AM >>>
> >> It often seems that URL's point to (moved) locations... it kind of 
> >> reminds me of the garbage collection problem in Lisp, in which data 
> >> can be moved around in memory and all active pointers must be 
> >> updated.
> >> 
> >>  One solution (not a good one) would be to treat it the same way, and
> >> have a
> >>  GC web walker which re-points moved URL's; obviously this is fraught
> >> with  problems.
> >> 
> >> However, an indirect referencing scheme might go a long way towards 
> >> solving this problem.  Rather than:
> >> 
> >>         <A HREF="http://www.blah/foo.html"> which is an "absolute"
> >> pointer, perhaps a syntax change allowing  dynamic lookup would solve
> >> the problem:
> >>        <A HREF="www.blah.foo.html@index-server.com" ...>
> >> 
> >> The idea is that to resolve the HREF, (in this case) index-server.com
> >>  is asked for the *current* location of www.blah.foo.html (syntax here
> >>  needs some thought).  This way, one could move pages around, update 
> >> pointers on whatever index server one uses, and all existing pointers
> >>  would still work.
> >> 
> >
> >My idea may be a stupid idea, but I would like to learn that
> >it is stupid.
> >
> >To increase reliability and balance the load of WWW servers, in 
> >addition to having indirect links (dynamic query of servers for
> >links), we can have multiple links - where web pages are duplicated
> >and distributed in a few sites.   The resolution of which path
> >(or servers) to go to for WEB pages therefore depends on the
> >path's availability and load condition.   If a few simultaneous calls
> >comes in, they can be redirected to different sites for WEB pages.
> >

May be I should include an aritlce from  the Internic site - 96mar directory,
which emphasize the importance of performance in protocol 
specification:

>Group Name: Applications/Transport Joint Session (apptsv)
>Chairs:	    Harald Alvestrand <harald.t.alvestrand@uninett.no>
>	    Allison Mankin <mankin@isi.edu>
>===================================================
>TRANSPORT/APPS JOINT BOF ON WEB-RELATED TRANSPORT ISSUES
>--------------------------------------------------------
>
>This session will attempt to address the problems that the phenomenal
>growth of the Web has caused, both related to the strains it puts on
>the Web servers and the strain it puts on the infrastructure.
>
>The session will start with some short introductions to illuminate
>various parts of the problem and some examples of proposed solutions,
>and thereafter, there will be the usual open discussion.
>
>Examples of the problems we want to address:
>
>- - Web problems for the Web client
>  - "always" goes far away
>  - Takes too long
>- - Web problems for the Web servers
>  - Thousands of connections in CLOSE_WAIT and similar states
>  - Hundreds of addresses per interface
>  - Nasty behaviour by clients (they crash)
>- - Web problems for the network
>  - Congestion because TCP backoff doesn't have time to establish
>  - Routing cache miss because of too many destinations at once
>  - Loss of "locality of reference" model
>
>Examples of solutions we might want to pursue:
>
>- - An extensive caching network might solve the problem.
>- - Deploying T/TCP might solve the problem.
>- - Deploying LBL reliable multicast in unicast mode rather than TCP
>    might solve the problem.
>- - Switching to HTTP/NG with multiple-stream persistent connections
>    might solve the problem.
>- - Deploying flow policing in the routers rather than the end nodes
>     might solve the problem.
>
>Some of these will be presented in short introductions.
>
>After the presentations, there will be a general discussion,
>terminating in an attempt to decide on what further work, if any, we
>need to do related to this problem area.


Peter Teoh 					Information Technology Institute
Internet : peter@iti.gov.sg			Science Park II
Tel : 65-7705585				11 Science Park Road
Fax : 65-7791827				Singapore 117685

Received on Monday, 4 March 1996 01:09:55 UTC