From: Nigel Edwards <nje@ansa.co.uk>
Message-Id: <9409300831.AA24452@socrates.ansa.co.uk>
Subject: Re: No "TOP" of the docuverse [Was: URC usage scenarios ]
To: Michael.Mealling@oit.gatech.edu
Date: Fri, 30 Sep 94 9:31:56 BST
In-Reply-To: <199409292052.QAA10993@oit.gatech.edu>; from "Michael Mealling" at Sep 29, 94 4:52 pm
Michael Mealling wrote:
>
> Jon P. Knight said this:
[Stuff deleted]
> > What about if the ``top'' or ``root'' was a multicast group with lots of
> > authoritive servers listening in for queries for URN/URC mappings that
> > can't be handled by more localised heirarchies.
>
> I've always been interested in the applications of multicasting to the
> informatiion retrieval problem. Several purposes make a hell of a lot of
> sense:
>
> 1. 1 multicast address for all large whois++ servers for centroid
> advertisement
>
> 2. using multicast to 'advertise' a resource or the need for a given
> resource.
>
> 3. efficient pre-emptive cache replication across large backbone caches.
>
> etc..
> etc...
>
I think the only practical solution is to have a group of URN/URC
servers otherwise scaling will be a problem. In such a group I believe
it will be difficult to avoid the question of which one is the
authorative server for a particular URN. (Unless the group is locked
to propagate updates, but that will hurt performance.) This is why I
favor designating a single server to be the authorative server for
a particular URN. (This could be the publisher's server, or some server
which the publisher nominates.)
Client/server multicasting can cause scaling problems in wide-area
networks. It is possible to build protocols in which a client can
send a multicast as single message to m servers on the same LAN
segment. However, if the servers are in different parts of the network
(URN/URC servers will be), m separate messages will be needed to send
a multicast to them (even routers are used to fan-out the
multicast). So if there are n clients you have n*m messages.
The question of which server replies can cause further scaling
problems unless the server which should reply is already known. In
which case why not have the client choose the server and send a
uni-cast message?
A possible solution to this is to have the client pick ONE member from
the group of servers and send its request to that. If that fails it
tries to talk to the next one until it succeeds or exhausts the list.
(Ron Daniel's "URC Service Usage Scenarios" proposes the same idea for
browsers when they receive a list of URLs from the servers.)
Nigel.
-- Nigel Edwards (nje@ansa.co.uk) Information about ANSA: <http://www.ansa.co.uk/>