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!