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