# Re: No "TOP" of the docuverse [Was: URC usage scenarios ]

Daniel LaLiberte (liberte@ncsa.uiuc.edu)
Mon, 3 Oct 94 12:10:17 CDT

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Owen Rees: "Naming concepts, terminology and examples"
- Previous message: Daniel W. Connolly: "Re: No "TOP" of the docuverse [Was: URC usage scenarios ]"
- Maybe in reply to: Daniel W. Connolly: "No "TOP" of the docuverse [Was: URC usage scenarios ]"
- Next in thread: Andrew Pam: "Re: No "TOP" of the docuverse [Was: URC usage scenarios ]"
- Reply: Andrew Pam: "Re: No "TOP" of the docuverse [Was: URC usage scenarios ]"
- Reply: Daniel W. Connolly: "Re: No "TOP" of the docuverse [Was: URC usage scenarios ]"

    Date: Mon, 3 Oct 94 12:10:17 CDT

    From: liberte@ncsa.uiuc.edu (Daniel LaLiberte)

    Message-Id: <9410031710.AA21142@void.ncsa.uiuc.edu>

    To: uri@bunyip.com, weibel@oclc.org

    Subject: Re: No "TOP" of the docuverse [Was: URC usage scenarios ]

From: weibel@oclc.org

A "root" or "top" server can be a single *logical* server
without being constrained to a single physical machine, and
without being constrained by the single point of failure
phenomenon. Technology to support such services is well
understood and deployed widely.

Yes, but each replicated root must not be required to do any more work
than any other top-of-the-line server can do. This includes all work
to maintain consistency between the replicas. Even if root servers
are not overloaded by this process, keeping them consistent might
increase network traffic. Actually, for n replicas, an additional
replica would only increase update traffic by 1/(n-1), on average, if
a flooding algorithm is used. Thus with more replicas, the increase
in update traffic is less. The reduction in total network traffic due
to the existence of an additional replica could easily compensate this
increase, but this only applies if the replica server is closer to
some clients that can take advantage of it. Replicating servers at a
single site does not help reduce network traffic, but nor does it
increase network traffic for updates.

Like any good CEO, the roots should delegate almost all of their
responsibility to intermediate level servers. Clients must be able to
go directly to the intermediate level servers so the root servers are
not bothered unless needed. The same applies to intermediate levels
in the hierarchy, on down to the lowest level where the grunt work is
done. Perhaps clients should only talk to the lowest levels who then
request services of higher levels. Have I recreated DNS yet?

A hierarchical naming system, such as the URN scheme, seems to require
a logical hierarchy for resolving the names. A hierarchy has a root.
How do we live with that fact?

BTW, I'm told that basically everyone agrees that URNs should be
hierarchical. If so, exactly what hierarchical scheme are we
considering? If not, what are the alternatives?

Daniel LaLiberte (liberte@ncsa.uiuc.edu)
National Center for Supercomputing Applications

- Next message: Owen Rees: "Naming concepts, terminology and examples"
- Previous message: Daniel W. Connolly: "Re: No "TOP" of the docuverse [Was: URC usage scenarios ]"
- Maybe in reply to: Daniel W. Connolly: "No "TOP" of the docuverse [Was: URC usage scenarios ]"
- Next in thread: Andrew Pam: "Re: No "TOP" of the docuverse [Was: URC usage scenarios ]"
- Reply: Andrew Pam: "Re: No "TOP" of the docuverse [Was: URC usage scenarios ]"
- Reply: Daniel W. Connolly: "Re: No "TOP" of the docuverse [Was: URC usage scenarios ]"