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

Nigel Edwards (nje@ansa.co.uk)
Fri, 30 Sep 94 16:08:38 BST

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Dirk Herr-Hoyman: "Re: Lisp Syntax for external representation [Was: URC usage scenarios ]"
- Previous message: Daniel LaLiberte: "Multicasting vs Anycasting (was: No "TOP" of the docuverse)"
- In reply to: Jon P. Knight: "Re: No "TOP" of the docuverse [Was: URC usage scenarios ]"
- Next in thread: Alexander Dupuy: "Re: No "TOP" of the docuverse [Was: URC usage scenarios ]"

    From: Nigel Edwards <nje@ansa.co.uk>

    Message-Id: <9409301508.AA26062@socrates.ansa.co.uk>

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

    To: J.P.Knight@lut.ac.uk (Jon P. Knight)

    Date: Fri, 30 Sep 94 16:08:38 BST

    In-Reply-To: <Pine.3.05.9409301252.C2081-c100000@suna>; from "Jon P. Knight" at Sep 30, 94 12:31 (noon)

Jon P. Knight wrote:
>
> Hmm, but in a multicast environment such as the MBONE, the servers will be
> in so many different parts of the Internet that the m messages will
> probably never exist all at the same time (machines that are ``nearer'' to
> the source topologically speaking will be processing the request before
> more distant ever see it). You can also use increasing TTLs with
> retransmissions to let your URC/N server search spread out gradually over
> the network. That's a big plus of having something like the MBONE
> carefully constructed to follow the physical topology where possible.
>

I believe that the usage models of URC/N servers and MBONE will be
different. In MBONE most of the packets go in one direction (from
source to sink) and there are only relatively few sources. These
assumptions won't necessarily be valid for URC/N servers: they are
likely to have many clients sending them requests.

[stuff deleted]
> > 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.)
>
> The trouble with this is that if the list is k entries long (where k is
> fairly large; say several hundred ``top-level'' servers) and the first k-1
> fail to respond (they're down, the links are congested, the hosts are
> overloaded, etc, etc) but the kth one works, you will have sent k request
> packets.
This all depends on how many servers fail to respond. I suspect that
most of the time the first one will respond, and it will be extremely
rare to have to try more than one alternative server. We should try to
optimise the most common case, not unusual failure cases.
.
.
> Also, I'm of the view that bandwidth is getting cheaper and we can afford
> to waste a little here and there if it helps us to get the response times
> for the user application to scale better.

I agree with you point about bandwidth, but we need to be careful
about overloading servers. A server will need to do some processing
to decide whether to ignore a request even if TTL is used. Sending
multiple concurrent requests to different servers will mean the
average server load will much higher than if an alternative scheme is
used. There are aready plenty of examples of overloaded servers on the
net.
Nigel.

    --
    Nigel Edwards (nje@ansa.co.uk)
    Information about ANSA: <http://www.ansa.co.uk/>

- Next message: Dirk Herr-Hoyman: "Re: Lisp Syntax for external representation [Was: URC usage scenarios ]"
- Previous message: Daniel LaLiberte: "Multicasting vs Anycasting (was: No "TOP" of the docuverse)"
- In reply to: Jon P. Knight: "Re: No "TOP" of the docuverse [Was: URC usage scenarios ]"
- Next in thread: Alexander Dupuy: "Re: No "TOP" of the docuverse [Was: URC usage scenarios ]"