In theory, I think something like this  would be nice, but in practice, no go.
For example,  if BITNIC were  down, CUNYVM would  have the files  queued. Now,
you  can't route  BITNIC files  to CUNYVM  via weights,  because CUNYVM  isn't
backbone. Fall  back one  level. Equal  are QUEENS and  ORION. You  also have,
for arguments  sake, PUCC,  YALEVM, and PSUVM  1 hop away,  but we  don't want
to  overload those  links.  Which would  you choose?  QUEENS  or ORION?  (Note
that this  assumes that neither  has a local user  specified in the  DIST job,
since, if that were  the case, there would already be a  DIST file headed that
way.)
 
This seems  to me  to be an  unresolvable case. And  anyway, who  assumes that
either QUEENS  or ORION  want's the extra  traffic? :-) I  do have  a standing
offer to  both Bill  Rubin (CUNYVM)  and Ken Ng  (ORION) to  help out  if they
need  it, but  that is  a special  case scenario,  not just  due to  a glitch.
 
Of course,  this wouldn't  help LIST  DISTs with peers,  because they  MUST go
to the peer, which will be the down node.
 
It would  be nice  to be  able to do  something like  this for  general DISTs:
 
   1) Dynamically  alter other  peers  (via  an update  Job?)  for a  specific
        period (renewable).
 
   2) Send  non LIST  DISTs to  the  specified alternate,  perhaps giving  two
        alternates to be used evenly.
 
   3) Split LIST  DISTs so that all  non-local (to the affected  LISTSERV) are
        sent  to  the   alternate(s),  and  all  local  sent   as  per  usual.
 
Comments?  (Eric?)
 
/Geert