A minor change will  be introduced in the DIST2 algorithm  in the next version
of LISTSERV, to further improve the path taken by the DISTRIBUTEd files.
 
When the algorithm  was first designed, the "density" of  backbone servers was
relatively low. There  was almost never any ambiguity as  to what LISTSERV was
the closest to a  given network user. However, as the  amount of backbone site
grows,  there are  more  and more  cases  where a  user  has several  possible
"closest" LISTSERVs, all located at the  same distance from his node. In these
cases, the original DIST2 algorithm merely  picked one of the closest backbone
servers, in a  semi-random fashion (which in fact resulted  in the server with
the  highest license  number  being chosen  in  most of  the  cases). The  one
exception to this rule  was that the local node, ie  the server processing the
DIST2 job, always preferred itself over any other server.
 
With  the  recent  problems  associated   with  the  volume  of  the  INFO-VAX
distribution (just  as a  reminder, I was  able to measure  its effect  on the
CEARN spool when the  FRMOP22 line was down and found  out that INFO-VAX files
represented  36% of  the spoolids  and 42%  of the  spool space,  which in  my
opinion is  clearly above the  "intolerable" threshold), this behaviour  is no
longer acceptable  as very large amount  of data may be  shipped to (slightly)
inadequate  places.  For  example,  PSUORVM   is  handling  all  the  INFO-VAX
distribution for OREGON when UWAVM could have handled it:
 
   (INFO-VAX source) --> (...) --> UWAVM --> OREGON(1) --> PSUORVM
 
PSUORVM and UWAVM are equidistant to OREGON(1), and the former happens to have
the highest license number.
 
I have therefore modified the algorithm to select the node which is closest to
the  local (source)  node, whenever  there is  an ambiguity.  This required  a
modification to both LSVDIST2 and LSVBITFD,  so that the latter may return the
list of  all 'eligible' nodes  to the  former for additional  processing. This
should not increase  the CPU time requirements, as this  information is cached
on a disk file and is therefore calculated only about once a month. This might
introduce bugs/problems in  two heavily called pieces of  LISTSERV code, which
is why  I am writing  this long letter  at all :-) I  would like to  hear from
whomever would be  willing to beta-test the  new code - I will  not release it
unless  it has  been seriously  tested. If  you'd also  like to  test the  new
version of  LSVXMAIL which I have  described on LSTSRV-L some  time ago, don't
hesitate to ask for a copy.
 
Thanks, Eric