Eric Thomas <ERIC@FRECP11>
Wed, 8 Apr 1987 23:19 SET
|
Oh my... the loop phantom again. Seriously, folks... LSTSRV-L has 8 peers or
so, and has been having them for a very long period of time. To the best of my
knowledge it has never looped, even when the UIUCVMD server went crazy and
started sending copies to all the peers instead of only to the neighbour
peers.
I have however noticed several mailing loops on other sub-distribution
lists, especially when using the Send= Editor feature. Peer-linking inserts a
set of control fields in the mail header, which include a complete list of all
the servers that processed the mailfile. If "I" processed it already, it goes
to the postmaster ASAP. You don't have this facility with non-peer lists.
And how does DISTRIBUTE do? First, as long as there will be servers < 1.5g
the DISTRIBUTE backbone will be in danger. The older releases do not accept
jobs from LISTSERVs not officially registered in PEERS NAMES, and I can't
register new servers on them because of the 60 entries limit. If they detect a
problem with a DISTRIBUTE job, it gets trashed. And they trash the anti-loop
information generated by 1.5g and above if they find it in the job stream.
With peers you don't have to worry about going through your dreaded
neighbour's 1.5b server (unless of course you want to peer with him :-) ).
DISTRIBUTE does have an anti-loop protocol, but it is defeated in one of the
following two cases:
1) A server < 1.5g trashes the "went through" control record. In 1.5j, I'll
consider all servers < 1.5g as NOT supporting DISTRIBUTE. Jobs will no
longer be sent to them, even if it means 10 extra nodes. I'm fed up with
1.5d/1.5f DISTRIBUTE rejections.
2) If there are more than 255 bytes of "went through" info. Yes, when I wrote
the code I had forgotten about this *stupid* GLOBALV restriction.
Fortunately it can easily be removed while keeping upward compatibility,
but here again 'old' servers will trash part of the info (ie if 2 lines of
info are generated, they will transmit only 1).
I'll try to design a 'pass-through' protocol to allow 'old' servers to
propagate fields generated by more recent versions, even if they don't use
them -- they'll just pass on whatever they're asked to. The problem is that it
is much more difficult to implement that on CJLI where you have no "list of
DDnames" and you have the "!%$!$+% 255 chars limit, than on RFC822 where the
header is straightforward and you have no size limit. But it will be done. The
problem is that it will take 2 more months for everybody to install it ;-(
Eric
|
|
|