NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/sys/3b1/4386

Text File | 1993-01-24 | 6.0 KB | 128 lines

Newsgroups: comp.sys.3b1
Path: sparky!uunet!cs.utexas.edu!uwm.edu!linac!unixhub!ditka!hico2!sonyd1.broadcast.sony.com!blilly.uucp!bruce
From: [e-mail] (Bruce Lilly)
Subject: Re: Taylor uucp 1.4 gamma on 3B1 with TCP
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Bruce Lilly
Date: Sat, 23 Jan 93 14:37:41 GMT
Message-ID: <[e-mail]>
Reply-To: [e-mail] (Bruce Lilly)
Lines: 116

In article <[e-mail]>,
 posted to comp.sys.3b1,
 [e-mail] (Karl Swartz) wrote:
>In article <[e-mail]> [e-mail] (DoN. Nichols) writes:
>
>unambiguous about why I chose the path I did -- getting NNTP going
>would seem to be a lot more work than getting Taylor uucp up, and

Not from the sound of things. Getting nntp 1.5.11 and successors
running on the 3b1 is fairly simple.

>still doesn't even address the issue of mail.
[...]
>And then there's still Smail and SMTP to deal with when I'm done with
>news.

With WIN/3B you already have mail connectivity via SMTP using
sendmail. Wollongong's version is quite old, but workable, and
it can be simply replaced by the IDA version in the osu-cis
archives, or you can compile UIUC/IDA sendmail from
sources--there is specific support for the 3B1. And if you have
Smail already running on a 3B1, what's the problem? Surely
you're not saying that you *prefer* uux/rmail semantics over
SMTP?

>By going to NNTP, I have to build NNTP (client and server), then
>rebuild C news with it, then rebuild trn with it, and worry about
>breaking my newsfeed.

C news need not change at all. As long as you're using NNTP for
news reading (and optionally posting) rather than news transfer
(and Taylor UUCP by itself still won't let you transfer news
using NNTP anyway), there is no reason to touch C news.

nntp *is* a server program. trn, when compiled with NNTP
support, is the client program that uses NNTP.

>Basically, I'm changing the transport so it seems to make a lot more
>sense to change the transport software (one piece) than to change a
>number of high-level pieces of software.  NNTP isn't the right tool
>to solve the problem.

IMO, it's silly to run UUCP protocol on top of TCP/IP protocol.
The UUCP suite of programs handles file transfer and remote
execution of programs, period. There are programs that do that
using TCP/IP (rcp, remsh, ftp, etc.).

>>One advantage of nntp over what you appear to be describing is that
>>nntp needs a news spool directory only on *one* machine.
>
>Did I say the two had identical feeds?  I don't believe I did.  One
>machine carries a full feed, distributing all or parts of it along to
>other machines (including my second machine) and then getting rid of
>it to make room for the next wave as quickly as possible.  The other
>gets a small feed of stuff I really want, and keeps it around as long
>as I need.  If I read news on the primary machine it'd miss most of
>the discussions I might be interested in, not to mention the problem
>of falling asleep because the thing is so damned slow.

Though you didn't say so, it sounds like your "second machine"
gets a subset of the groups carried by "One machine". If that's
the case, I'd definitely have to agree with Don. If you're
transferring articles or batches between the two machines,
you're contributing to the slowness problem, and using a lot of
disk space as well.  Transferring the articles in batches
between the two machines involves extra processing of a sys file
entry on the first machine for the second machine, collecting a
list of articles to be transferred, assembling a batch from the
list, compressing the batch, spooling the batches under your
news spool directory, invoking uux which spools the batches
again under the uucp spool directory, running uudemon.hour, plus
all of the uucico overhead on top of the TCP/IP overhead. You're
also using a lot of resources on the second machine, which must
also deal with uucico overhead on top of TCP/IP, it must
disassemble the batches, create histiry file entries, update an
active file, store the articles on disk, handle expiry, control
messages, etc., etc., etc..

I think you'd be far better off increasing the article retention
time (in explist) for the newsgroups you're interested in on your
first machine, and using NNTP to read those articles from the
second machine. There are many advantages, here are a few:
1)    The articles are transferred as required, using TCP/IP
    with no additional protocol suite overhead.
2)    No disk storage for the articles, history entries, etc.
    is required on the second machine (or on *any* client
    machine if you have more than two machines).
3)    You don't have to have the C news executables, spool
    directories, or crontab entries on any client machine.
    There is a mini-inews (part of the nntp package) that
    handles posting.
4)    Overhead of batching, compression, spooling (twice)
    storage of spooled batches, and batch transfer is
    eliminated from the server machine.
5)    Overhead of unbatching, uncompression, spooling,
    expiry, etc. is eliminated from the client machines.
6)    If/when you acquire additional client machines, you'll
    be all set to read news on (and post articles from)
    those additional machines, without having to make any
    changes to your C news configuration.
7)    In the event that a client machine crashes, you can
    still read and post from another client or the server.

Please think about this; you may save yourself a lot of
trouble.

You've changed the nature of your network from a point-to-point,
store-and-forward connection using UUCP to a packet-switched,
bus-oriented connection using Ethernet(TM) and TCP/IP. That's a
substantial change, and it is possible to achieve several
efficiencies.  Some thought is warranted.  Certainly you can
impose the point-to-pont, store-and-forward limitations of UUCP
on your new network, but why would you want to cause so much
trouble for yourself?
--
    Bruce Lilly        ...uupsi!monymsys!sonyd1!blilly!bruce