I've been trying to understand how LISTSERV chooses to distribute files
using the DIST2 algorithm.  We have a situation where many distributions
are being broken up into individual files on the RICEVM1<->UHOU link that
would be better distributed if sent to a LISTSERV on the other side
of that link.
 
Eric, this is not a complaint about the algorithm.  The problem is
that the RICEVM1<->UHOU link is currently overloaded, so that the
normal choosing of the "best" path is invalid, even though the
nearest LISTSERV on the other side of that link is in fact "farther"
away in terms of the number of sites between it and us.  For various
reasons not worth going into here, the RICEVM1<->UHOU link is a real
bottleneck.
 
I've tried modifying the LINKSWT FILE to make the RICEVM1 UHOU link
have a large weight, and assigning 0 weights along the path to a
LISTSERV on the other side of the UHOU link.  However, I still see
lots of files coming in via DIST2 distributions that get split up into
multiple files.  (Yes, I did a NODESGEN WTONLY, and even restarted LISTSERV.)
 
1. Does changing my local copy of LINKSWT affect only distributions
   that start at RICEVM1?
 
   I know that the DIST2 files coming in from other sites have
   HOST(nn nn nn...) arguments on the DIST2 command line.  I can't find
   documentation on what that argument means.  Does it perchance force
   distributions to those hosts, which means that my changing the local
   LINKSWT file is worthless?
 
2. If changing my local LINKSWT file is not worthless, am I following
   the right method to try to encourage LISTSERV to delay breaking the
   file into individual files?  I.e., make the overloaded link have a
   weight of 99, and put 0 weights on links on the path to the LISTSERV
   on the other side of the overloaded link?
 
   Or is just putting a high weight on the RICEVM1<->UHOU link sufficient?
 
3. Is it possible to get a global LINKSWT change made to help me out on
   this?
 
Thanks,
Richard