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