An asynchronous  inter-LISTSERV request protocol has  been implemented to
solve a problem with the DELETE/SIGNOFF command.
 
When you  issue a SIGNOFF command  with the (default) UPCASE  option to a
list, and cannot be found on it,  the list owners will receive a piece of
mail telling you about this attempt, so that they can search the list for
possible (synonym) addresses  (see my append re: "Changes  to the SIGNOFF
processing" for more details).
 
This works perfectly  for non-peered lists. However, with  peered ones we
have a serious problem: we don't want the owners to receive this piece of
mail unless the  person trying to sign  off could not be found  on ANY of
the  peers. This  means  that the  "last" peer  must  send the  mailform.
Unfortunately there is no such thing  as a "last" peer: the various peers
form a linked graph where there is  no end nor tail, and, considering the
asynchronous nature of the NJE network, there  is no way to know which is
the "last" peer. The  only sure thing is that the "first"  one is the one
which  receives the  original request  from the  user. Besides,  whenever
there is a fork in the graph, there  is a chance that one of the branches
will succeed in finding the user while the other won't.
 
To solve this problem, I  had to introduce a request-and-answer protocol.
Each  server will,  when its  turn comes,  generate a  unique request  id
associated with  the SIGNOFF  (or DELETE) request.  For each  request id,
there are sub-ids assigned to the  various peers linked to the local one.
Each such peer will  receive a (reqid,subid) pair and use  it to reply to
the issuing  server when  appropriate. A  success generates  an immediate
reply,  whereas a  failure doesn't  generate a  reply unless  the request
could  not be  forwarded  to another  peer (dead  branch).  If it  could,
another request id is generated, which will eventually get replied to and
will cause this reply to be forwarded to the original issuer. All of this
is  under  the supervision  of  a  "request  monitor" that  will  timeout
anything older than 7 days (for obvious reasons).
 
This protocol  is general enough to  be usable for other  things than the
DELETE/SIGNOFF command  processors. For  example, it  would make  it very
easy  to implement  an "authority  checking" mechanism  whereby a  server
could ask  another server whether  some user  has some authority  or not,
without having to wait for the reply.
 
If you send a SIGNOFF request to a peered list without the GLOBAL option,
and couldn't be found on it, you'll get the following message:
 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
You have not  subscribed to list TEST-L. You might  wish to re-issue your
command with the GLOBAL option, ie "SIGNOFF TEST-L (GLOBAL", to have your
name searched on all the peers instead of just the FRECP11 one.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
 
If you  then issue a  SIGNOFF (GLOBAL command  and you couldn't  be found
anywhere, you'll get the usual message  sent to the list owners. You may,
alternatively, get this:
 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Date:         Thu, 10 Mar 1988 22:57 SET
From:         Revised List Processor (1.5n) <LISTSERV@FRECP11>
Subject:      Message
To:           Local VM Wizard <WIZARD@FRECP11>
 
Inter-server asynchronous  requests timed out for  your command: "SIGNOFF
TEST-L". You might wish to re-issue  the command if you have not received
any personal notification of its completion.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
 
For a  DELETE command,  you'll get  this message if  the person  you were
attempting to delete couldn't be found on any of the peers:
 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Date:         Sat, 12 Mar 1988 15:48 SET
From:         Revised List Processor (1.5n) <LISTSERV@FRECP11>
Subject:      Message
To:           Eric Thomas <ERIC@FRECP11>
 
User NETINFO@FRECP11 could not be found on any peer for list TEST-L.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
 
Note that  none of this  will work properly unless  all the peers  in the
chain are 1.5n.  For a hybrid peer  chain, you will get  the 1.5m replies
plus a "timeout" message from the server you issued the request to, if it
was 1.5n; if you issue your command  to a 1.5m server, no request will be
generated and you will get pure 1.5m behaviour.
 
If  this works  correctly, I  plan to  remove the  "Request forwarded  to
listid@node" messages  in the next  release, or set them  to "interactive
message or nothing". They are quite painful on a mail-only node...
 
  Eric