I have eventually come  up with a seemingly sound links  weight file, which I
am sending  to the list for  your review. I am  not going to start  a year-long
discussion about whether this or that link should be  given a 4 or a 3 ( :-) ),
but I am open to suggestions before I make the thing official.
 
  The distributed  file transmission command  is now  ready and 50%  tested. It
works both  for mail  and files  (in the  former cases  it generates  the "To:"
line itself),  and can  even handle domain  names (and routes  the file  to the
peer server  which is nearest  to the gateway --  this assumes that  the DOMAIN
NAMES file  is available,  of course). In  the case of  a file  transmission, I
assume no responsibility  as to the ARPA  guy being able or not  to process the
thing in  a sensible  way ;-)  A mail enveloppe  is generated  and the  data is
shipped 'as is'  to the poor guy, pour  le moment. Yet this brought  back to my
mind this  endless discussion  we had  in Atlanta  about the  implementation of
domain naming  convention on  BITNET; a  lot of things  were said  during RAF's
BOF  which ended  up to  the  conclusion that  we  probably need  a "FILER"  to
transmit files  to other  domains (in  much the same  way as  we have  a MAILER
for mail).  I'm not  sure I  fully understood  the problem  and what  the FILER
would have to  do, but if his job  is just to deliver the file  in an efficient
way  (in network-load  terms),  then  the network  of  LISTSERVs  could do  it.
 
  I  took my  local LSTSRV-L  list (couldn't  use the  complete list  since the
network was  down all the  weekend) and computed the  number of links  that are
crossed everytime I  send a file to  LSTSRV-L in the normal way.  The result is
70 links (plus  whatever load the UIUCVMD  and UGA servers may  create). I then
computed the number of links that would be crossed if I could send the file via
the DISTRIBUTE  command, using all  the listservs as  relays. If I  assume that
there is  a LISTSERV in all  the central nodes of  all the countries, I  end up
with a result of 30, ie about 57%  less load. With the current setup (where not
all central nodes have  a server), the load would be 33  links, ie 53% savings.
(there is  little difference  because there  is a  server at  BNANDP10 although
there is none at BEARN, and the CEARN  server is only one link away from EARNET
where there is no server; also there are only two recipients in Belgium, two in
Italy).
 
  I am not going to open this thing  to the public until it has been fully tes-
ted. The command is at present available to any user, but please don't make its
existence public. I  would need 2-3 sites for beta-testing  -- this function is
quite complex and can  lead to all sorts of unexpected  troubles with 3 servers
that you would never have spotted with only two ;-) I will also need someone to
test the  improvement of  the "Peers=" keyword  and MOVE/EXPLODE/etc  which now
accept different list userids at the various peer sites (Marc?)
 
  A final note: the  LISTJOB memo is now available and can  be obtained from my
server by sending an "INFO JOB" command.  I will write a memo on this distribu-
tion thing when I  have time; the command to get it will  be "INFO DIST" but it
will not appear on  the "INFO ?" menu until I  officially announce the feature,
which will bring the  release number to 1.5. I guess  the file server functions
will be postponed to 1.6...
 
  Eric