Article View: comp.mail.uucp
Article #2869Re: problems with the UUCP maps--duplicate n
From: Erik Horstkotte
Date: Wed, 27 Jan 1993 17:35
Date: Wed, 27 Jan 1993 17:35
57 lines
3697 bytes
3697 bytes
In article 29069@netcom.com, tweek@netcom.com (Michael D. Maxfield) writes: >The standard I suggest... a simple mail account on every uucp system. >Instead of limiting system accounts to root, postmaster, newsadmin, etc., >add one more called something like mapper/mapping/uumaper (or whatever.) >That account could be set up to send out the current map for the site to >any person/daemon that mails the account. All it should take would be a >few simple lines on most UN*X systems. It should be able to work on >Waffle systems as well with the alias file. I would assume that UUPC, >FSUUCP, and the other DOS packages can handle this too. > >If a sysadmin then wanted to have cron automate the map creation process, >there is at least a hook there for a new sysadmin to be able to grab onto >and see what is happening. > >So? Do I make sense, or do I speak crazy like? It sure makes sense to me. So, to summarize, you propose having each system that defines a uucp map entry have a mailbox that could be queried for the map entry. This is simple enough to do, but I'm not sure how it improves the situation over having the system routinely send its map entry to rutgers via email. In the cron-based approach, each system defining a uucp map entry would be responsible for sending in a new map entry before the old one expired. The Coordinators (sound like a bad 60's Sci Fi movie to you?) could choose this expiration period arbitrarily. If a new map entry doesn't arrive in time, the old map entry is declared dead and discarded. In the mailbox-based approach, The Coordinators would have to send an email query to each machine in the previous issue of the maps, and then process the response sent back by that machine. If no response occurs within a specified timeout period, the map entry is declared dead and discarded. The problem I see with this is that it actually appears to *increase*, not *decrease* the network traffic, in that for each map update there is an email query *and* an emailed map entry. I don't see how having a cron job sending in the map entry leads to confusion when the sysadmin changes over, nor do I see how having the mailbox improves that situation. The cron job is as much of a data trail as the mailbox, as far as I can see. Your comment about the mailbox approach being easier to handle on non-Unix systems is well taken, however. As regards the entire bandwidth argument: 1. If an additional 21,000 short messages a month brings the net to its knees, then it's only a few months away from getting there anyway, considering the growth in sites on the net. 2. Rutgers is connected to the Internet, right? Why would "the sites near the coordinating site" have additional load placed on them? Whoever forwards the email to the Internet would get the additional load, and this load would be distributed across the forwarders. --- Erik Horstkotte, Togai InfraLogic, Inc. The World's Source for Fuzzy Logic Solutions (The company, not me!) erik@til.com, gordius!til!erik - (714) 975-8522 info@til.com for info, fuzzy-server@til.com for fuzzy mail-server
Technical Details
Message-ID:
<1993Jan27.173519.5079@til.til.com>Path:
arc1-ca.pugleaf.net!sparky!uunet!charon.amdahl.com!amdahl!rtech!pacbell.com!ames!elroy.jpl.nasa.gov!usc!news.service.uci.edu!gordius!til!maui!erikReferences:
<1993Jan27.033211.29069@netcom.com>Show Full Headers
Complete Article Headers
Newsgroups: comp.mail.uucp Path: arc1-ca.pugleaf.net!sparky!uunet!charon.amdahl.com!amdahl!rtech!pacbell.com!ames!elroy.jpl.nasa.gov!usc!news.service.uci.edu!gordius!til!maui!erik From: erik@til.com (Erik Horstkotte) Subject: Re: problems with the UUCP maps--duplicate n Message-ID: <1993Jan27.173519.5079@til.til.com> Sender: usenet@til.til.com Nntp-Posting-Host: maui Reply-To: erik@til.com Organization: Togai InfraLogic, Inc. References: <1993Jan27.033211.29069@netcom.com> Date: Wed, 27 Jan 1993 17:35:19 GMT Lines: 58