Re: Directory Services Work coordination proposal
Simon Spero <ses@hillary.oit.unc.edu> Sat, 13 November 1993 04:55 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25137;
12 Nov 93 23:55 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25133;
12 Nov 93 23:55 EST
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa03452;
12 Nov 93 23:55 EST
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP
id <g.00705-0@haig.cs.ucl.ac.uk>; Sat, 13 Nov 1993 04:43:12 +0000
Received: from tipper.oit.unc.edu by bells.cs.ucl.ac.uk with Internet SMTP
id <g.17249-0@bells.cs.ucl.ac.uk>; Sat, 13 Nov 1993 04:42:54 +0000
Received: from hillary.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02)
id AA11380; Fri, 12 Nov 93 23:42:18 EST
Date: Sat, 13 Novermber 1993 23:40:56 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Simon Spero <ses@hillary.oit.unc.edu>
To: John Curran <jcurran@nic.near.net>
Subject: Re: Directory Services Work coordination proposal
Cc: Simon E Spero <ses@tipper.oit.unc.edu>,
"Barry M. Leiner" <leiner@nsipo.nasa.gov>,
Erik Huizer <Erik.Huizer@surfnet.nl>,
RARE & IETF OSI-DS wg <osi-ds@cs.ucl.ac.uk>, ietf-wnils@ucdavis.edu,
apples@surfnet.nl
Message-Id: <Mailstrom.B53.8456.1101.ses@hillary.oit.unc.edu>
In-Reply-To: Your message <9311130355.AA11331@tipper.oit.unc.edu> of Fri,
12 Nov 1993 22:51:53 -0500
Content-Type: TEXT/plain; charset=US-ASCII
> Long term, it would be preferable if the network could actually answer >some questions regarding the path to a given destination. This would allow >the client to make a decision based on it's priorities. For example, you may >have different criteria for the "site to retrieve RFC big.ps from right now" >and the "site which my archive mirrors from". > Does this make any sense? It didn't for a bit then I read it carefully, and then it did :-) If and when it becomes possible to get live, useful, congestion information out of the network then the paradigm changes slightly. The search technique described in my previous message doesn't guarantee optimal results; it merely predicts good results. The obvious mechanism for extending the algorithm would be to get the first result, and check to see if it is "good enough" for some definition of "good enough". If the check fails, then the search should be continued where it left off. Mirroring is a totally separate issue; there the prime concern is making sure what you're mirroring is actually the right version. Secondary sites can very easily get out of sync, especially when it comes to removing invalid files. Studying the aftermath of the great X11/contrib/JIS whoops of 93 showed the latencies that could be involved. It also showed some of the real limitations of polling based systems like archie. Simon p.s. (For people who don't run archive sites, or who don't mirror X11; the incident I'm referring to was the time when some enterprising individuals discovered a writable directory on expo.lcs.mit.edu, and uploaded 600Mb of pornographic jpegs just before the weekend. When it came time for everybodies nightly mirror, all these files got transferred to all mirroring sites. Then along came archie, which found saw all these nice new files and added them to its listings, where they would stay for the next N weeks until it was polling time again. For weeks afterwards we were getting requests for people to be allowed access to the "secret files" which archie said were there.)
- Directory Services Work coordination proposal Erik Huizer (SURFnet BV)
- Re: Directory Services Work coordination proposal Barry M. Leiner
- Re: Directory Services Work coordination proposal Masataka Ohta
- Re: Directory Services Work coordination proposal Simon E Spero
- Re: Directory Services Work coordination proposal John Curran
- Re: Directory Services Work coordination proposal Simon Spero
- Re: Directory Services Work coordination proposal John Curran
- Re: Directory Services Work coordination proposal pays
- Re: Directory Services Work coordination proposal Masataka Ohta
- Re: Directory Services Work coordination proposal John Curran
- Re: Directory Services Work coordination proposal John Curran
- Re: Directory Services Work coordination proposal sri
- Re: Directory Services Work coordination proposal sri
- Re: Directory Services Work coordination proposal Erik Huizer (SURFnet BV)
- Re: Directory Services Work coordination proposal Barry M. Leiner