>Granted  we  probably  signed  on   at  different  times  and  the  peer
>configuration has  likely changed  along the way,  but I  always thought
>that  LISTSERV moved  people  to  the best  server  as  new ones  become
>available.
 
Let's say  that you  have a list  with 2 peers  at nodes  A and B,  and 2
users, U1 and U2 at node C. At  some point in time where A was closest to
C,  U1 signs  up and  ends up,  correctly,  at A.  A few  months pass  by
unnoticed. Then  comes a new shiny  BITEARN NODES which introduces  a new
link, and now C  is closer to B. User U2 sends his  request to A, in much
the same way as user U1, and A correctly forwards the request to node B.
 
Now your question is, why doesn't  LISTSERV@A move U1 to LISTSERV@B since
it knows B is  closer now? Well, it's very simple.  LISTSERV@A is a lucky
server, it has  a serious manager who updates BITEARN  NODES on a regular
basis. It knows  B is closer, but  it also knows, not from  any data file
but from the code  it is executing, that all the  LISTSERV's in the world
are not  that lucky. Maybe  B has a  lazy postmaster who  updates BITEARN
NODES only when someone complains to his boss. Given that A and B run the
same software, if  A were to forward U1  to B on the basis that  B is now
closer, B would, for the same reason,  forward it (and U2) back to A. I'm
not sure  the users would  be very happy about  that. The code  could, of
course, limit  this kind of  activity to once  a month; then  we wouldn't
have a  loop, but we'd still  have poor users who  have to write to  A on
odd-numbered months and to B on  even-numbered months. If they don't know
how to write to B's manager, it's not going to be funny for them.
 
The code could also say that A is  to ask B what version of BITEARN NODES
it has, and make the move only in  that case. But you see June, you wrote
the note I'm replying  to on the 8th of january. It  reached my reader on
the 15th of january, because BITNET is desperately trying to compete with
snail-mail these days.  Maybe you won't read these lines  until the 22nd,
for the  same reason, and  then what I just  said about my  BITEARN NODES
version might no longer be true.
 
There  are indeed  solutions, but  all of  them are  complicated and  can
create unnecessary traffic whose exact volume is difficult to estimate.
 
  Eric