NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/mail/uucp/2652

Text File | 1993-01-28 | 3.5 KB | 72 lines

Newsgroups: comp.mail.uucp
Path: sparky!uunet!charon.amdahl.com!amdahl!rtech!pacbell.com!ames!elroy.jpl.nasa.gov!usc!news.service.uci.edu!gordius!til!maui!erik
From: [e-mail] (Erik Horstkotte)
Subject: Re: problems with the UUCP maps--duplicate n
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: maui
Reply-To: [e-mail]
Organization: Togai InfraLogic, Inc.
References: <[e-mail]>
Date: Wed, 27 Jan 1993 17:35:19 GMT
Lines: 58

In article [e-mail], [e-mail] (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!)
[e-mail], gordius!til!erik - [phone]
[e-mail] for info, [e-mail] for fuzzy mail-server