The global list registration code is available for beta-testing (I will
distribute the beta-test shipments on monday evening my time - then I'll be
off until friday). Here is a description of the way it operates:
---------------------- End-user's viewpoint ----------------------------------
1. A "request" for something (presently, only SUBSCRIBE and REVIEW) is sent to
just any LISTSERV that has the feature installed. If the list exists on
that server, either as a 'real' listname or as a List-ID, the request is
satisfied.
2. If the server the command was sent to is not on the backbone, it will
immediately forward the request to the nearest backbone server with a
message sent to the user. Go execute step 3 on the attached processor.
3. If the server is on the backbone, it will search its GLOBLIST FILE for a
match. It may reply that "No such list is known to exist on the LISTSERV
network", game over insert coin. It may also inform you that there are
several lists bearing the same name (note that peers count as a single list
and are represented by their nearest member), give you a list of them, and
ask you to choose for yourself. It will, hopefully, find a single match and
forward the request to the appropriate server.
---------------------- LISTSERV's viewpoint ----------------------------------
1. Every so often (by default, every night), LSVLDELT is called to compare the
current status of the LIST files with last time's. If a difference is
found, a delta file is built and a distribution job (X-LUPD command) is
submitted to the nearest backbone server, possibly the server itself. This
process is responsible for the creation of LOCLIST FILE, which defines the
List-IDs for all the local lists (and ONLY the local lists). The main
advantage of this 'asynchronous' approach is that there is no problem with
lists that have been modified by hand, using XEDIT from the LISTSERV userid
(what, you mean you've never done that?? :-) )
2. The backbone server receiving the X-LUPD job will apply the update to its
own GLOBLIST FILE, and cause a copy to be forwarded to all the other
backbone servers by means of a DIST2 job. There is a mechanism to ensure
that older updates are not applied over recent ones, even if they are
received in the wrong order. Note that the use of DIST2 vs DIST1 reduces
CPU consumption in a factor of 10 on the second and following runs.
3. Some commands request that the LOCLIST FILE be checked for a synonym. Some
don't. In the long run, they will all support synonyms.
4. Some commands will cause the request to be forwarded to the appropriate
server if it couldn't be satisfied locally. Some don't, and never will (eg
GET - you don't want to GET a network-wide name, you want to GET a
particular peer from a particular server). The new X-FOR command is used in
that case, and the new "FWDED=" command keyword is used to prevent
accidental loops.
In any case, the new code does not "know" whether a particular backbone site
has it installed or not, and sends to all backbone servers. You will probably
get copies of X-LUPD and maybe X-FOR jobs if you run a backbone server. Just
ignore them unless they create problems (they shouldn't!)
Eric
|
