LSTSRV-L Archives

LISTSERV Site Administrators' Forum

LSTSRV-L

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
"Geert K. Marien" <GKMCU@CUNYVM>
Fri, 3 Mar 89 09:12:19 EST
text/plain (76 lines)
Hello all:      (* Please DO NOT include all this text when replying *)
 
I  would like  to propose  that the  limits on  data requested  be amended  as
follows, (and some other enhancements that go along with this):
 
   (1) The default  limit be raised  to at least  5 times the  current (256kb)
       limit  (.. a  single  copy  of NODES  INFO1  will  exhaust the  current
       default  limit!!). In  addition, a  whole package  should be  sent when
       requested, not just half the  files and half 'limit exceeded' messages!
 
   (2) The  limits  should not  be  time  wise, but  should  be  based on  the
       number  of  links   crossed,  and  the  relative   importance  of  such
       links,  plus  perhaps the  type  and  speed  of  such links,  and  some
       sort of load factor (see number 4, below);
 
   (3) Some  sort of  mechanism should  be  put into  place so  that you  must
       confirm  that you  want  a specific  file  a second  time  during a  24
       hour period  (24 hours  since last request,  not midnight  to midnight)
       and this  confirm mechanism will  allow that  you can not  just specify
       'override'  on every  command, but  that it  must be  in response  to a
       Listserv  advisory that  "You have  ordered this  file within  the last
       24 hours  and it  has not  been updated  since then.  Send the  command
       again with a  parm of (confirm send  and it will be sent  to you again"
       so as  to avoid/discourage  people from sending  all commands  with the
       "override send" type of parm as a habit;
 
   (4) If  some  sort of  regional  association  of  backbone sites  could  be
       formed to  peer more  important files.  It can  be spread  amongst more
       than one  server in  a particular  region if space  is a  problem. This
       may mean  that a GLOBAL  filelist (limited)  may be created,  much like
       the GLOBAL  list functions  now being  used. A server  will be  able to
       request  that a  file  be  sent from  another  server  that is  either:
 
       (a) The  sub-server that has  the file because of  space considerations
           at the main (regional) server site, or;
 
       (b) A  server that is  closer to the site  that is requesting  the file
           than the  regional server,  and the files  have been  sub-stored on
           that  server, or  the site  is in  fact a  closer regional  server.
 
 
This regional concept may work as follows:
 
   1. Inter-Regional:
 
      All  files have  an origin  point and  are sent  to this  origin by  the
      person  making  the  updates.  This   Listserv  then  sends  the  update
      job  to  all  other  regional  servers housing  the  file  in  question.
 
   2. Intra-Regional:
 
      The Regional server then updates all its local sub-servers.
 
   3. An  "Update completed  successfully job  returns from  the last  server,
      plus  at  every update  point  there  is  a  checksum. Also,  the  point
      of  origin will  receive  an  ack from  each  Listserv  that is  updated
      and a  report is  run at  some given  time frame  (say 48  hours?) which
      will  advise the  person putting  the file  on that  server(s) XXX  have
      still  not received  the file  and loaded  it properly.  It may  also be
      run  at a  further 48  hours since  if  a link  is down  a weekend,  for
      example,  a file  could take  more than  the initial  48 hours  to reach
      its destination.
 
 
This  would, in  my opinion,  cut down  on the  problems of  people requesting
the same  file many  times, of  people not  being able  to get  decent amounts
of  data, and  of huge  file queues  (at least  it may  make a  dent :-)))  ).
 
These are just basics.  Discussion welcome :-).
 
 
/Geert
 
** Disclaimer: The  above are my  views and may not  be those of  my employer,
               or  any other  person, and  are not  to be  taken as  such.  **

ATOM RSS1 RSS2