> > 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