>An advantage to this over peering was to not have to worry about peer linking
>to the wrong  list and possibly creating  a loop. For one  list reducing this
>chance of error is nice, for 40 lists this is worthwhile.
 
EB0UB011 has 67 lists,  44 of them public. Of the 44 public  lists, 29 of them
have one or more peers -- there are lists with 2 peers and lists with up to 15
peers, 3  peers beeing  the average. I  have *never* had  a loop,  expect when
installing a list. Beeing an owner for other peers has helped me to stop loops
when other node's postmasters  were not at work -- note  that, from that point
of view, the  probability of loops *decreases* when there  are more peers: the
time difference is an advantage here.
 
>...            The  security  aspect  of  peering is  not  favorable,  it  is
>possible to create loops.
 
Monday night Tony Dahbura, Harri Salminen  and me were testing the new I-GRAPH
and VLSICAD lists.  Some misunderstandings lead us to create  a peer structure
which formed a neat loop: SUVM ---> FINHUTC ---> EB0UB011 ---> SUVM. Tony sent
a test  mail, and I  received two copies: one  directly from SUVM  and another
from FINHUTC.  No more copies.  I tried then from  my side (my  list mentioned
both SUVM and  FINHUTC as peers) and a  while later I received a  note from my
LISTSERV saying : "Possible loop in  the peer structure for list I-GRAPH"; the
offending mail was transferred to my reader.
 
I looked  at it, and it  had some inter-server  tags. One of them  (X-LSVVia I
think) listed ALL THE PEERS in the path: since my note was sent from EB0UB011,
then forwarded  to SUVM,  then FINHUTC  and then back  to EB0UB011,  it looked
something like
 
  X-LSVVia: VLSICAD@EB0UB011 VLSICAD@SUVM VLSICAD@FINHUTC
 
EB0UB011   was  immediately   able  to   detect   the  loop   with  a   single
Find(lsvvia,myself) instruction.
 
Conclusion:  when Eric  says that  LISTSERV has  very powerful  loop-detection
strctures, he's not lying :-)
 
> With DISTRIBUTE only the contribution  end is centralized, meaning, once the
>job is  relayed to the  next node  it doesn't matter  if the central  node is
>down.
 
Yes, but  this does  not address  the point I  mentioned: mailing  activity is
totally suspended if the central node is down.
 
>--Judith Molka
 
Jose Maria