wb8foz@ncoast.UUCP (02/25/87)
I have a thought to broach with the wizards. There has been
much concern recently over the increased volume on news. I
regularly see posting of the following ilk:
I would have mailed but my mailer choked.....
Now the same thing often happens to me, so I can appreciate
the state of mind of the poster. But it is very wasteful of
net.money to go through this. My question is: would it not
be worthwhile to devote some fraction of net.genuis/net.GOD
(s) resources to inventing better, more dependable, mailers?
I well realise, even though I am a hardware engineer and
therefor not qualified to speak on any subject (8-}), that
this is a highly complex problem, with no simple, easy
answers. After all, news is run on hundreds of different
types of machines with the only common command command
beings cp and rm, if that.
But does that make it a goal not worth looking at?
Just a thought
--
decvax!cwruecmp!ncoast!wb8foz
ncoast!wb8foz@case.csnet
(ncoast!wb8foz%case.csnet@csnet-relay.ARPA)
"SERIOUS?
Bones, it could upset the entire percentage!"
NRO Mossad intercept igniters plutonium Ollie North Tehran woods@hao.UUCP (02/28/87)
In article <2131@ncoast.UUCP> wb8foz@ncoast.UUCP (David Lesher) writes: > > I would have mailed but my mailer choked..... > > Now the same thing often happens to me, so I can appreciate > the state of mind of the poster. But it is very wasteful of > net.money to go through this. My question is: would it not > be worthwhile to devote some fraction of net.genuis/net.GOD > (s) resources to inventing better, more dependable, mailers? Yes, it certainly would, which is why it is being done. It's called domains. I have heard people say that the very idea of domains is the reason why we're seeing so many failures. I do not happen to agree with this point of view. I think the reason we're seeing so many failures is because we are in the middle of a period of rapid change in the way uucp mail gets delivered. Some sites implement domain-based addressing, and others don't. As more and more sites move to domain-based routing, mail will become more reliable. Dave Taylor pointed out some problems with routing based on static information. He is correct in noting that the routing breaks down when that information is not correct. Of course, that's no problem; you site admins out there ARE updating your pathalias database promptly when the mod.map postings come out, right? :-) This is as close to dynamic routing information as we are going to get with uucp technology. If you don't want to maintain routing tables, I see nothing wrong with Dave's suggestion to simply send messages you can't route directly to a site which DOES maintain routing tables. This can be done with sendmail (by defining a major relay host, and sending any unresolved addresses to that host at the end of ruleset 0). With a little work, you could probably get it to work with the major relay host actually being a uucp path. If you don't have sendmail, you could use smail(8) (and presumably the "uumail" I've heard about on the net but never seen) to do this. Just create a very simple phony paths file that routes all top-level domains to some "smart" host (e.g., a bunch of lines like .COM pathtoseismo!%s would do it). (For smail, make sure the file is run through sort -f first). For netnews software, this capability is already implemented in 2.11 with the "mailpaths" file. Define "internet" to be a path to a "smart" host, and that takes care of that. Mail replies to the From: line in domain form get sent to that host for delivery. We're getting there, but all the bugs are not out, and all the old software out there has not yet been replaced with newer software that is designed for domains (insert plug for 2.11 here). --Greg -- UUCP: {hplabs, seismo, nbires, noao}!hao!woods CSNET: woods@ncar.csnet ARPA: woods%ncar@CSNET-RELAY.ARPA INTERNET: woods@hao.ucar.edu
page@ulowell.UUCP (02/28/87)
woods@hao.UUCP (Greg Woods) wrote: >you site admins out there ARE updating your pathalias database promptly >when the mod.map postings come out, right? :-) I'm glad to see the smiley face, but... >This is as close to dynamic routing information as we are going to get >with uucp technology. If you are referring to mod.map, I disagree with this. It does not make sense to publish this massive database every 6 weeks that's out of date when it's published. Wouldn't it make more sense to publish the full text every six months, and publish the connectivity data each month? Every two weeks? All we need is something like: ulowell:ci-dandelion=180,masscomp=190,wanginst=200,apollo=200,\ vaxine=200,datacube=500,wang=300000 (etc) Where the "=n" denotes pathalias connect cost. Easy to build, easy to parse. It would not solve the problem completely, but would go a long way to keeping the routing tables up to date, and would decrease the network traffic as a bonus. Finally, it makes little sense to have the UUCP Project handle the map alone; it is too big and too dynamic. Regional coordinators could maintain and post the data as appropriate. If Maine doesn't get any new connections, the Maine coordinator doesn't send out new connectivity data! If something does change, and the diff file is smaller than the original file, post the diff file! How about it, Mel? What needs to happen for this to become reality? ..Bob -- Bob Page, U of Lowell CS Dept. ulowell!page, page@ulowell.CSNET
davids@iscuva.UUCP (03/04/87)
In article <1113@ulowell.cs.ulowell.edu> page@ulowell.cs.ulowell.edu (Bob Page) writes: >If you are referring to mod.map, I disagree with this. It does not >make sense to publish this massive database every 6 weeks that's out >of date when it's published. Agreed. >Wouldn't it make more sense to publish the full text every six months, >and publish the connectivity data each month? Every two weeks? All >we need is something like: > >ulowell:ci-dandelion=180,masscomp=190,wanginst=200,apollo=200,\ > vaxine=200,datacube=500,wang=300000 (etc) > >Where the "=n" denotes pathalias connect cost. Easy to build, >easy to parse. Or even in the current format. Just distribute the maps without the comment lines. Better yet, distribute the same info, but as patch files (see below). >It would not solve the problem completely, but would go a long way >to keeping the routing tables up to date, and would decrease the >network traffic as a bonus. > It would be nice if the map data could be distributed as patch files between full distributions. These could be send out as they came in, and thus keep the paths file as up to date as possible. This does mean more work for the moderators (or at least the same work spread throughout the distribution period), but it would keep the maps a lot cleaner overall, especially near the end of the distribution period. -- David Schmidt UUCP: ihnp4!tektronix!reed!iscuva!davids ISC Systems Corp. Phone: (509)927-5479 Box TAF-C8 Spokane, WA 99220
john@xanth.UUCP (03/07/87)
In article <470@iscuva.UUCP>, davids@iscuva.UUCP (David Schmidt) writes: > It would be nice if the map data could be distributed as patch files > between full distributions. These could be send out as they came in, > and thus keep the paths file as up to date as possible. Sounds nice, but posting it as patch files would require that everyone always got all the parts. I enclose part of an article I saw just after yours as an example of how reliable this would be. (The subject is strangely ironic.) At least with the current scheme, if I've missed lots of map entries due to news feed problems, at least the ones I get will be ok, and I'll be back in sync eventually. - Newsgroups: net.sources.bugs - Subject: Request for reposting of patch patches - Date: 12 Feb 87 16:22:23 GMT - There seems to be a need for the reposting of - I too am one who missed the patch patch postings, - I noticed that someone reposted patch patches 5,6,7. - Could someone please repost patch patches 1,2,3 and 4. -- John Owens Old Dominion University - Norfolk, Virginia, USA john@ODU.EDU old arpa: john%odu.edu@RELAY.CS.NET +1 804 440 3915 old uucp: {seismo,harvard,sun,hoptoad}!xanth!john
greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) (03/09/87)
In article <683@xanth.UUCP> john@xanth.UUCP (John Owens) writes: >In article <470@iscuva.UUCP>, davids@iscuva.UUCP (David Schmidt) writes: >> It would be nice if the map data could be distributed as patch files >> between full distributions. ..... >Sounds nice, but posting it as patch files would require that everyone >always got all the parts. ..... I have suggested to Peter Honeyman and the UUCP map folks that the next version of pathalias allow an entry that forces a cost along a particular link; i.e., instead of chosing the cheapest cost provided, a value is assigned to the path. This would allow the publishing of a "patch file" that contained only the changed values, and there would be no need to physically splice them into the current data maps. For example, suppose site foo used to talk to site bar, but no longer does. The update file would contain: foo bar(=DEAD) to indicate that the link from foo to bar is now DEAD, no matter what is said elsewhere. In this way, it wouldn't matter if you missed some of the updates; as long as you had the latest one, you would be OK. This same mechanism could be used to distribute newly-created links, even before the official entry for a site was distributed. Then the full data base would be distributed on a much longer cycle (quarterly? or perhaps ten percent of the data base every week to spread out the volume?) with the update file being posted on a much more frequent basis (weekly? even daily is possible since the file wouldn't be that large). -- -- Greg Noel, NCR Rancho Bernardo Greg.Noel@SanDiego.NCR.COM
davids@iscuva.UUCP (03/09/87)
In article <1424@ncr-sd.SanDiego.NCR.COM> greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) writes: >I have suggested to Peter Honeyman and the UUCP map folks that the next >version of pathalias allow an entry that forces a cost along a particular >link; i.e., instead of chosing the cheapest cost provided, a value is >assigned to the path. >... >In this way, it wouldn't matter if you missed some of the updates; as long >as you had the latest one, you would be OK. This same mechanism could be >used to distribute newly-created links, even before the official entry for >a site was distributed. Then the full data base would be distributed on >a much longer cycle (quarterly? or perhaps ten percent of the data base >every week to spread out the volume?) with the update file being posted on >a much more frequent basis (weekly? even daily is possible since the file >wouldn't be that large). This seems like a good solution. We would have to make changes to pathalias to either indicate that an entry is the ONLY entry to be used or place the changes in a files that would be read last and modify pathalias to only use the data from the LAST entry found (as I understand it, pathalias allows multiple entries for a site and uses all of them). We could then have an additional newsgroup called "mod.map.updates" or something similar that would contain the updates and corrections to the maps. This should give us a much more current map and correct at least some of the mail problems that are current occuring. -- David Schmidt UUCP: ihnp4!tektronix!reed!iscuva!davids ISC Systems Corp. Phone: (509)927-5479 Box TAF-C8 Spokane, WA 99220
roger@celtics.UUCP (Roger Klorese) (03/17/87)
In article <683@xanth.UUCP> john@xanth.UUCP (John Owens) writes: >In article <470@iscuva.UUCP>, davids@iscuva.UUCP (David Schmidt) writes: >> It would be nice if the map data could be distributed as patch files >> between full distributions. > >Sounds nice, but posting it as patch files would require that everyone >always got all the parts. Actually, this need not be true... we really need to maintain two patch paths: -- one to be applied to the last patched version -- one, permanently numbered #1, to be applied to ORIGINAL maps A new base level could be established and distributed every 3 to 6 months. -- ///==\\ (No disclaimer - nobody's listening anyway.) /// Roger B.A. Klorese, CELERITY (Northeast Area) \\\ 40 Speen St., Framingham, MA 01701 +1 617 872-1552 \\\==// celtics!roger@seismo.CSS.GOV - seismo!celtics!roger
john@xanth.UUCP (03/20/87)
I like that idea! There could be 3-to-6 month full map distributions with
diffs on the base level distributed biweekly, say, and other diffs daily or
so. I'm still not convinced that there's a real problem with the way they're
done now, as we can see from the "emergency" posting of the ca.[246] maps;
whether or not this plan would be better than monthly full distributions
really depends on the size of the full maps vs. the sizes of the diffs.
Would all the diffs for a month fit in one posting?
All it would take to allow automatic updating from the diffs is adding a copy
of patch to the bin directory used by uuhosts' mapsh, and posting the diffs as
a shell script that ran patch (and having the right names in the diffs so
patch could figure out the right file).
Are there any real UNIX sites that can't (as opposed to don't) use patch?
Are there any non-UNIX sites that would have a use for the UUCP maps? Eunice
should be able to handle patch; has anyone ported it to native VMS?
Also, to take care of the problems of missed base maps, one of the sites that
has constantly up-to-date maps could set up a mail-based server so that sites
that missed some maps could pick those up between the 3-6 month distributions.
(For example, we still don't have new d. files; we came in in the middle of
the u. files after establishing a good news feed). This might need a limit of
10 files/site/month or some such, meaning that someone starting from scratch
would need to find the maps from someone closer.
How do the instantaneously-updated sites stay that way? Mailed diff files?
uucp'd entire map files (with all having direct connections to someone and the
maps in a directory writable by that site)?
Comments?
--
John Owens Old Dominion University - Norfolk, Virginia, USA
john@ODU.EDU old arpa: john%odu.edu@RELAY.CS.NET
+1 804 440 3915 old uucp: {seismo,harvard,sun,hoptoad}!xanth!johnroy@phri.UUCP (03/22/87)
Various people have suggested distributing map updates in diff
format to reduce the amount of data that has to be shipped around. The
most common objection I've seen so far is that if you only ship diffs, it's
too easy to get out of sync (i.e. patching the wrong base version of a
file). Obviously, the thing to do (as many have suggested) is to ship the
full map every so often, say 4 times a year. My addition to this
discussion is to suggest that you maintain redundant news feeds for mod.map
so you increase the chances of always having up-to-date base files.
--
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016
"you can't spell deoxyribonucleic without unix!"