ROBINSON@BITNIC.BITNET (Andrew T. Robinson) (02/12/90)
My primary gripe with the current LISTSERV concept is that it requires "smart" file distribution--routing over routing. You have a topology of LISTSERVs which is constrained by the topology of the real network. If the LISTSERV "network" could better approximate the real topology of the network (meaning it would have to run on other than IBM VM systems), the "smart routing" could be eliminated and each node's routing tables could be used instead. Unfortunately, the only way to a non-VM implementation of LISTSERV is by a line-by-line analysis of the code. Andy
VALDIS@VTVM1.CC.VT.EDU (Valdis Kletnieks) (02/12/90)
On Sun, 11 Feb 90 18:13:30 EST Andrew T. Robinson said: >My primary gripe with the current LISTSERV concept is that it requires >"smart" file distribution--routing over routing. You have a topology >of LISTSERVs which is constrained by the topology of the real network. Andy: *all* network services are constrained by the topology of the real network. You can't send bits over a non-existent link. Valdis Kletnieks
RUBIN@YKTVMX.BITNET (Bill Rubin) (02/12/90)
If enough people were running RSCS V2.2+ or 2.3, you could use the built in list processor feature. Then, all LISTSERV-like software would have to do is send out a single copy of the file with a distribution list, and RSCS, the guy who already KNOWS the topology of the network, would send the minimum number of files. Voila, no more duplication of topology information. This is how things work in VNET, and we do quite a bit of mailing list traffic here, too. Does JNET support this feature? All you really need is the ability to handle multiple dataset headers, which is how MVS manages to be compatible, even though it cannot process the initial distribution list. Note also, that the initial list processor doesn't even have to be on the same machine as the mailing list generator, it can send it to a different node for list processing. Bill Rubin IBM TJ Watson Research