Just have a look at the latest NetMonth issue, there is an article about
GRAND by Judith Molka:
> It (GRAND) will soon be used to shadow several discussion groups on
> [log in to unmask]
Wonder why they're not willing to install a FRECP11-LISTSERV? ;-) I guess we
have to do something about this use of GRAND as a substitute for LISTSERV. As
you may know my first experience with GRAND was a *BIG* deception. They may
have improved it, but three things are sure:
1) The size of the user package CANNOT have decreased (about 3 cyls)
2) The speed of the user package CANNOT have increased (5 secs for just pres-
sing ENTER on my system)
3) The size of the files it ships you across the network, as well as the number
of these files, cannot have bettered. You want to know what a discussion is
about because you don't understand what the topic exactly is? Just press the
ORDER key and wait until the whole 1,500 lines contents of the discussion
reach you :-) I've heard rumours that the main problem of GRAND is that the
servers ship updates to each other faster than the network can transmit
them, resulting in a GRANDiose bottleneck *hee hee*
Anyway, GRAND may perhaps be a good conferencing tool; but it certainly
should not be used to emulate LISTSERV functions, in much the same way that a
war 40 tons tank should not be used as a personal leisure car ;-)
Some (happy) news:
- I'm completing a "links weight" feature for the infernal module. It seems to
be working, except that we have problems with aliases. If you change the
weight of a link, you must change the weights of all the aliases too. Otherwi
se the link gets short-cut by its alias, and... :-( Also it sometimes causes
the program to die because it creates a loop in the network (that would have
to be examined more thoroughly).
- I'm not going to use the "links speed" from BITEARN NODES to create the links
weight file. I heard that NODESGEN takes 1 minute 20 secs on Phil's computer,
but on mine it takes 15 minutes. I just can't afford doubling that, especial-
ly since I would have to test the stuff. I can't spend 6 hours on this just
because every test takes 30 minutes. Anyway I don't think this is very impor-
tant since important links all have the same link speed.
- I'm putting on some stuff to fix the loop problems on ARPA &co. I decided
that parsing the messages was impossible, considering the amount of
"ERGTW-PRTMOUT%NSLINK%MAIL- Poor mailer was not able to access nasty UNIX
node for three days, your nice mail has had to be canned, waaaahahahahh".
I just had an "EUREKA" idea: *anything* sent by LISTSERV has a "Sender: nia
niania <listid@mynode>" line in the header. Now if I find a "Sender: some-
thing <listid@mynode>" line in the mail BODY, it is probably a rejection
notice.
- Loop problems caused by loops in peer links: I'll fix that by adding an inter
peer field indicating the source node. If I get mail originated from *me*,
I just can it. :-) Which does not mean that I'm not going to bitch whomever
initiated the link....
Ah, another issue (excuse the length of this mail :-) ). The BITNIC seemed to
be very concerned with the issue of "LISTSERV coordination". I saw in a note
from BITNIC that they sort of tended to assume that it would be reasonable that
the NIC be designated as the coordination point for all LISTSERVs in the world.
Needless to say, it seems absurd that BITNIC coordinates a network of FRECP11-
LISTSERVs when THEY do not even have one and have no idea of how it works. Even
assuming that they eventually install one, they would have to really indulge in
a minute perusal of all the tomes and librams furnished with the device, not to
mention the arcane formulae found in the magic REXX books inside the apparatus.
:-) Actually I think that the LISTSERVs should be coordinated not by a single
person or center, which would not be available 24h, not to mention the time
zones problem, but by a (limited) number of people who have a good knowledge of
the thing and above all a good understanding of how peer linking works and what
should be done to avoid a loop or stop it. Good knowledge of the network topolo
gy (in the person's area) would also be required. FRECP11-LISTSERV is a distri-
buted server, so it's gonna have a distributed coordination :-) I think that
about 5 people would be needed all over the world, 2 in Europe and 2-3 in the
States (and perhaps 1 in Canada too). Who will volunteer?
We might then suggest to the various LISTSERV owners to give one or more of
these persons the authority to stop their LISTSERV in case a mailing loop
occurs. This would also cause them to receive all severe error messages from
the server and would help troubleshooting a lot. This would of course be optio-
nal, although those people who do not allow anybody except their own account
to stop their LISTSERV might be considered morally responsible of long duration
mailing loops by other people on the network. As I mentioned in the LISTMAST
MEMO, I feel like anybody who has authority to drain the network link to the
LISTSERV should also have authority to stop the server so that he does not have
to resort to draining the link to stop a mailing loop. Also please note that
you can give STOP privileges *without* giving CP or CMS privileges -- this is a
separate class of postmastership and requires a separate password. I understand
that nobody would want people outside the node to have CP privs on a class D
account. :-)
Eric
|
