Sat, 11 Feb 1995 01:36:52 +0100
|
On Fri, 10 Feb 1995 12:12:00 EST Bill Verity <[log in to unmask]> said:
>I've been trying to follow these discussions but I'm still not clear.
>Would our running the TCP/IP product help our load? Most of our BITNET
>traffic goes out over BITNET-II which is in fact the Internet lines.
>RSCS is rarely saturated. The SMTP machines are the ones that can't keep
>up.
To answer these questions it helps to separate the "core node" function
of PSUVM with its "traffic producer" function. That is, on the same
machine you are running a LISTSERV that is used both as a core router and
to deliver mail for PSU's own mailing lists.
The core function only makes sense if you are running your server in NJE
mode. That is, you cannot act as a switchboard for NJE jobs unless you
run your server in NJE mode. One could probably work out a setup based on
a specially configured LTCP where you would receive jobs from your region
via NJE, and use SMTP to deliver them to the other core nodes involved.
This however would not be a good use of your or the receiving core site's
resources. If as a central NJE switchboard site you need to cut 7 copies
of a job and send them to other core sites, it is more cost effective (on
VM) to do that using NJE. The idea of LTCP is to (1) decrease the use of
this switching function by reducing the number of such switching "hops"
from the current LISTSERV-NJE setup, which is based purely on BITNET
topology, and (2) move the switching functions to cheap workstation or PC
systems.
As a producer of traffic for PSU's own lists, it would however help if
you switched to the version LTCP that is about to be released, the one
with the change to stop using BITNET altogether. It would not help PSUVM
itself, since on VM a NJE delivery is less expensive than an SMTP
delivery, but it would help the other core sites because you would no
longer be sending them jobs via NJE for the traffic that PSU lists
generate. In general, as traffic producers migrate to LTCP, the load on
the core will be reduced.
Finally, as a delivery engine it would help if you ran a copy of the unix
(or VMS) LISTSERV on a cheap workstation-class system and configured your
VM LISTSERV to direct all Internet messages to that machine. This trades
the current set of SMTP messages, with all the queuing and delivery done
on VM, with "leaner" SMTP messages that have just one recipient on a
local, well connected machine. Your SMTPs would be able to deliver these
messages immediately and would not accumulate a queue on their 191.
Having only one RCPT TO: to process would also speed up the delivery
compared to the current setup, so the spool queues would probably go
away.
Eric
|
|
|