Path: utzoo!attcan!uunet!husc6!ukma!david
From: david@ms.uky.edu (David Herron -- One of the vertebrae)
Newsgroups: news.admin
Subject: Re: IDEA: reader-initiated sendme protocol
Message-ID: <9823@g.ms.uky.edu>
Date: 4 Jul 88 02:31:31 GMT
References: <270@octopus.UUCP>
Reply-To: david@ms.uky.edu (David Herron -- One of the vertebrae)
Organization: U of Kentucky, Mathematical Sciences
Lines: 86

In article <270@octopus.UUCP> pete@octopus.UUCP (Pete Holzmann) writes:

[ ... deleted text about reading a posting describing some archived object]

>The reader could respond simply by hitting the 'sendme' key. A control
>message would then be forwarded towards the nearest archive site (csu-archives
>being an alias for the comp.sources.unix archive sites), until it reaches
>a site that either already has the message in question, or [an efficiency
>improvement that might be optional at first] until the message reaches a
>site that has already requested the message. In the latter case, requests
>would pile up until the requested message arrives, then be filled.

This is oh so very similar to something which has been bubbling
away in my mind for a long time.  As I see it though, that phrase
about "would then be forwarded towards the nearest archive site"
is the sticking point that nobody short of peter honeyman could
solve.  The problem I see is that this network doesn't live just
within the UUCP network, but also lives within BITNET and ArpaNet.
If it just lived within the UUCP world, then finding the nearest
archive site is simply a matter of running pathalias.  But if there's
an archive site in BITNET land or Arpa land then it's not so trivial
to find the nearest one.  Or a user in BITland or Arpaland also
has a difficult time of finding the nearest archive.

The problem here is that nobody (short of peter honeyman) has a
good map of ALL of the networks which includes weights to different
parts of ALL of the networks.  Within each network there are maps
from which weights can be derived (er.. maybe not for the Arpanet,
I'm not sure).  But since there is no joint map, the "nearest archive"
cannot be found in the general case.

Assuming that this can be solved then the rest of it will fall into
place in any number of ways.  Given current software it would be
easiest to use something like Brian Reids archive server and build
into it the knowledge of which is the closest archive site for any 
particular site.  When a request comes into the server from a distant
site, it looks up the closest known server in its database and
forwards the request to that one.

Just because two sites are on the Arpanet doesn't mean that they're
close to each other, or that you can get good throughput to that site,
or that it makes sense to fill archive requests from that site.
The same holds true for BITNET but more comes down to which side
of the ohstvma<->psuvm<->cunyvm<->ucbjade links that you live on.

But while I've been sitting here two methods have come to mind.  One
is a control message type of thing which floats out into the network.
It's marked in some special way to cause it to go into an archive
server whenever it reaches a site running one.  The idea is to have
the first one which it reaches handle the request, but how to stop
secondary filling of requests?  hmmm.. The server could send out a
cancel message for the request as soon as it receives the request.
In addition, instead of immediately sending out the requested file
it could generate a mail message which, when replied to, will
cause the request to be filled.  We'd have to trust the user to
not reply to redundant responses from servers...

Another idea is to handle the "find closest archive" problem by
hand.  That is, instead of allowing requests from arbitrary sites
to require a site to register itself with a particular archive.
The director of the archive would probably be fleunt enough with
the network to know a better server to use if the site is far away.
Maybe part of this would be to strongly urge sites to make
direct connections with their archive servers, if possible.

Maybe part of this is a file which the local news maintainer
maintains like the moderators file.  Or maybe it *is* the moderators
file.  So a user making a request posts to a moderated group
and the entry in the moderators file knows where the closest
archiver is because it's in the file.




>This method would limit distribution of big stuff to just those sites
>that request it. To make everything wonderful, we'd probably want to
>add information to the sys file (and maybe the maps) regarding which paths
>may be used for such distributions.


YES EXACTLY!
-- 
<---- David Herron -- The E-Mail guy                         
<---- ska: David le casse\*'      {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<----
<---- I'm not bad, I'm just coded that way!