>
> 3) A  fight between  the CANADA01  and UOGUELPH  servers which  seen not  to b
>    running  the same  version  of BITEARN  NODES/LINKSUM.  CANADA01 thinks  th
>    recipients  are nearer  to  UOGUELPH  and sends  them  out  there, but  the
>    UOGUELPH  screams in  mad terror  that  no, not  at all,  they're nearer  t
>    CANADA01 and stops  the loop that might  have occured if I  had not include
>    a few  tests in the  code :-) A  few experiments seemed  to show that  it i
>    more probable that the culprit be UOGUELPH,  but I have no certitude at all
>    Kent,  Paulie, please  check that  out.  I'll send  you a  CANADA DATA  fil
>    containing the list of recipients that caused the problem. Thanks.
>
It will never be the case that BITEARN NODES is identical at all hosts.
Therefore it is a mistake of LISTSERV to assume a consistent view
of the net via this data base. Redistribution via peers should be
done in another way: The first LISTSERV that accepts the message
should determine its view of the network and send a copy to each
peer to redistribute the stuff. The message should contain *ALL*
recipients that are considered to be handled by this LISTSERV.
 
Another approach is the following: If one server determines that
some address should be handled by another server it should send
a message to that server that tells: "Hi collegue, based on the
latest update to our common data base (date,time) I have the
feeling that you should serve the following list of subscribers.
 
The general idea behind that is that either the directory lookup,
the directory syncronization, or the mail explosion must be done
in a hierarchical way at some stage. The hierarchy is dynamic of course
 
BTW: BITEARN NODES and GENROUTS have a similar problem especially
when we have some "loops" in the network routing: There are
two known line loops as we know.
 
Peter