I have finished writing the DIST2 command processor. It took some time
because I had to completely rewrite most of its 1416 lines -- both because of
the new algorithm (which I will explain another day) and because of the new
functions. A very important new feature is DISTRIBUTE RFC822. It takes the
"data" dataset, parses it as RFC822 mail, and extracts the FROM and TO
information from it. The file then gets processed as a FILE distribution job,
is propagated among the appropriate servers, but ends up sent to the local
MAILER as a BSMTP job with (possibly) multiple recipients. That is, it gets
delivered exactly as if it had been passed on to the local MAILER, except that
it has been processed as a DISTRIBUTE job instead of being sent directly to
all the recipients. It also gets parsed by a full RFC822 parser which does not
reject quote-quotation and suchlike :-) To use that feature, all that the
mailing agent has to do is:
1) Insert the following three lines on top of the RFC822 mailfile:
//Mail JOB Echo=No
DISTRIBUTE RFC822
//DATA DD *,EOF,Res=Disk
2) Direct the file to LISTSERV instead of MAILER.
Anyway, I have tested the new stuff on my server, have fixed most of the
bugs and think that it is now eligible for beta-testing. The output jobs
generated by the server look ok, but now I have no way to know whether they
would be processed correctly as input by the server who's going to get them
:-) The inter-server control information input-extraction routines might
generate REXX errors for all that I know... So I would need help to test the
code. Preferrably two or three sites -- I need to test intermediate-server to
intermediate-server control commands too, and this requires at least three
servers. By the way, don't worry if your server gets a few DIST2 commands and
rejects them as unknown command during the test period -- I have told the exec
that all backbone servers had DIST2 operational :-)
Please send me mail if you are interested to benchmark DIST2. Note that I
won't send you all of 1.5j (too many files, really!), just those "that are
needed", which means that I will perhaps forget a few files and you server
might operate strangely for a few hours after you install the beta-shipment,
especially if I'm in school at that time... :-) So be sure to be available for
more than 10 minutes before installing the stuff.
Here's a sample job output showing the paths taken by a sample file (with
the current link weight file). Please feel free to comment if you think
something is wrong. Note that I have temporarily added CEARN to the backbone
during the test to check that it properly receives recipients if I send a file
to 10 people at DEARN and 10 people at IBACSATA -- with the old DISTRIBUTE
there would have been one file sent directly to DEARN and one to IBACSATA, and
nothing to CEARN (the algorithm was a little dumb...)
/../
Date: Sun, 17 May 1987 21:33 SET
From: Revised List Processor (1.5j) <LISTSERV@FRECP11>
Subject: Output of your job "ERIC"
To: Eric Thomas <ERIC@FRECP11>
> DIST2 FROM=DD=FROM ACK=MAIL DEBUG=YES
Debug trace information:
HAROLD@UGA goes to UGA (#2)
PAULIE@UTORONTO goes to UTORONTO (#3)
C0@DDAESA10 goes to DEARN (#25)
ZCCBJBC@EB0UB011 goes to EB0UB011 (#5)
POSTMAST@FINHUTC goes to CEARN (#16)
DURASSE@BNANDP11 goes to BNANDP11 (#8)
$VK0@CLVM goes to BOSTONU (#52)
EARNUCD@IRLEARN goes to CEARN (#16)
DPL1646@IRISHVM goes to IRISHVM (#11)
DENNIS@CANADA01 goes to CANADA01 (#12)
BAV@KSUVM goes to KSUVM (#13)
SYSBJAV@TCSVM goes to TAMVM1 (#19)
MS5U@CMUCCVMA goes to CMUCCVMA (#15)
MARTIN@CEARN goes to CEARN (#16)
A024012@RUTVM1 goes to RUTVM1 (#17)
SPONSELL@AKRONVM goes to CMUCCVMA (#15)
X222DL@TAMVM1 goes to TAMVM1 (#19)
556@OREGON1 goes to OREGON1 (#20)
JMB1989@RITVM goes to RITVM (#21)
MARK@RICE goes to TAMVM1 (#19)
HARRY@MARIST goes to BOSTONU (#52)
REICHETZ@AWIIMC11 goes to AWIIMC11 (#24)
MEYER@DEARN goes to DEARN (#25)
WATKINS@OUACCVMA goes to CMUCCVMA (#15)
GERLAND@UBVM goes to UBVM (#27)
JEFF@UTCVM goes to UTCVM (#28)
JOSHUA@TAMCBA goes to TAMVM1 (#19)
NETMAN@SUVM goes to UBVM (#27)
JIM@UCF1VM goes to UCF1VM (#31)
VMSP@NCSUVM goes to UCF1VM (#31)
RICKY@BITNIC goes to BITNIC (#33)
MIKEB@WATDCS goes to CANADA01 (#12)
LISTMNGR@UIUCVMD goes to TAMVM1 (#19)
U001212@HEARN goes to HEARN (#36)
HABERNOL@DB0TUI11 goes to DB0TUI11 (#37)
SCH@BYUADMIN goes to BYUADMIN (#38)
INFO@NDSUVM1 goes to NDSUVM1 (#42)
SWANV@WSUVM1 goes to OREGON1 (#20)
WGRCU@CUNYVM goes to BITNIC (#33)
Path information:
UGA : CEARN IBACSATA BITNIC PSUVM CMUCCVMA UTCVM UGA
UTORONTO: CEARN IBACSATA BITNIC PSUVM UBVM CANADA01 UTORONTO
DEARN : CEARN DEARN
EB0UB011: Direct send
CEARN : Direct send
BNANDP11: Direct send
BOSTONU : CEARN IBACSATA BITNIC BOSTONU
IRISHVM : CEARN IBACSATA BITNIC PSUVM CMUCCVMA IRISHVM
CANADA01: CEARN IBACSATA BITNIC PSUVM UBVM CANADA01
KSUVM : CEARN IBACSATA BITNIC NDSUVM1 KSUVM
TAMVM1 : CEARN IBACSATA BITNIC PSUVM CMUCCVMA IRISHVM TAMVM1
CMUCCVMA: CEARN IBACSATA BITNIC PSUVM CMUCCVMA
RUTVM1 : CEARN IBACSATA BITNIC RUTVM1
OREGON1 : CEARN IBACSATA BITNIC BYUADMIN OREGON1
RITVM : CEARN IBACSATA BITNIC PSUVM UBVM RITVM
AWIIMC11: CEARN DEARN AWIIMC11
UBVM : CEARN IBACSATA BITNIC PSUVM UBVM
UTCVM : CEARN IBACSATA BITNIC PSUVM CMUCCVMA UTCVM
UCF1VM : CEARN IBACSATA BITNIC PSUVM UCF1VM
BITNIC : CEARN IBACSATA BITNIC
HEARN : CEARN DEARN HEARN
DB0TUI11: CEARN DEARN DB0TUI11
BYUADMIN: CEARN IBACSATA BITNIC BYUADMIN
NDSUVM1 : CEARN IBACSATA BITNIC NDSUVM1
File forwarded to LISTSERV@CEARN for distribution.
File forwarded to LISTSERV@EB0UB011 for distribution.
File forwarded to LISTSERV@BNANDP11 for distribution.
/../
Note: None of the recipients will get the file. I trashed it before it left
FRECP11 (actually there is a "rscs = 'ERIC'" in LSVDIST2 :-) )
And here is a sample of the inter-server job bound for CEARN:
/../
//DUMMY.FILE JOB Echo=No,Reply-to="ERIC@FRECP11"
// DIST2 FROM=DD=From ACK=Mail DEBUG=YES I=Y FORW(VIA) HOST(2 3 25 25 16 16 16 ,
//+ 52 52 11 12 12 13 19 19 19 19 19 15 15 15 17 20 20 21 24 27 27 28 31 31 33 ,
//+ 33 36 37 38 42) PATH(2:16,58,33,57,15,28 3:16,58,33,57,27,12 25:16 52:16,58,
//+ ,33 11:16,58,33,57,15 12:16,58,33,57,27 13:16,58,33,42 19:16,58,33,57,15,11,
//+ 15:16,58,33,57 17:16,58,33 20:16,58,33,38 21:16,58,33,57,27 24:16,25 27:16,
//+ ,58,33,57 28:16,58,33,57,15 31:16,58,33,57 33:16,58 36:16,25 37:16,25 38:16,
//+ ,58,33 42:16,58,33) TO HAROLD UGA PAULIE UTORONTO C0 DDAESA10 MEYER DEARN P,
//+ OSTMAST FINHUTC EARNUCD IRLEARN MARTIN CEARN $VK0 CLVM HARRY MARIST DPL1646,
//+ IRISHVM DENNIS CANADA01 MIKEB WATDCS BAV KSUVM SYSBJAV TCSVM X222DL TAMVM1,
//+ MARK RICE JOSHUA TAMCBA LISTMNGR UIUCVMD MS5U CMUCCVMA SPONSELL AKRONVM WA,
//+ TKINS OUACCVMA A024012 RUTVM1 556 OREGON1 SWANV WSUVM1 JMB1989 RITVM REICHE,
//+ TZ AWIIMC11 GERLAND UBVM NETMAN SUVM JEFF UTCVM JIM UCF1VM VMSP NCSUVM RICK,
//+ Y BITNIC WGRCU CUNYVM U001212 HEARN HABERNOL DB0TUI11 SCH BYUADMIN INFO NDS,
//+ UVM1
//From DD "ERIC@FRECP11 Eric Thomas"
//Via DD "FRECP11"
//Data DD *,EOF,Res=Disk
DUMMY TEST FILE
/../
There are 14 lines of non-fixed-length header information for 40 recipients
of 40 different nodes, which is not as compact as the old DISTRIBUTE.
The file goes to the States via the south, which was a little bit surprising
but I checked the weights and the result is consistent with the present
LINKSWT FILE. Note that the file must go to DEARN *and* IBACSATA *and* BITNIC
anyway, so it will take roughly the same number of hops regardless of whether
it travels via the south or via the north.
Note that this was a FILE distribution and DIST2 therefore decided that the
recipients' names were not needed and should be trashed on the inter-server
command job. If INFORM=MAIL is activated, this will probably cause the names
to be missing from the 'To:' field in the notification mail, but it sures
makes the output job more compact.
Another interesting feature is that the SOURCE node is the one that eats all
the CPU. Intermediate nodes will normally not have to do any (long) path
determination not any call to LSVBITFD. This is "fair" because postmasters
who set all their lists to Mail-Via= DISTRIBUTE will have to pay for it from
their own CPU, not from the neighbours' one :-)
Eric
PS: When I did the PUT LINKSWT FILE, I was running with an old version of the
backbone file, without EB0UB011 and a few other nodes. Don't be alarmed if
you didn't get it and you should have, I'll do another PUT after I get all
the acknowledgements.
|
