The beta-1.5n global list registration protocol (ie the commands that the
servers send to each other to keep their list of lists up to date) did not
provide any kind of recovery and did not detect inconsistencies between the
information stored by the various backbone servers. If, for example, a X-LUPD
file was lost in a spool crash, the corresponding information would be lost
forever in case of a DEL request, until the list was updated again for REP
requests. Furthermore, whenever requests arrived out of chronological order,
any 'obsolete' request would be discarded, which works fine for REP requests
but may or may not be correct for DEL and ADDs. This latter problem could have
been solved by keeping the last update date/time information along with EACH
entry in the (large) list of lists, but this still wouldn't solve the lost
files problem, and it wouldn't help new backbone sites any (they would start
with an empty list of lists and only receive updates from the day they were
added to the backbone).
This has been solved in the following way:
- Whenever updates to the list of (local) lists are being generated, the
sending server (which, by definition, has the latest version of the list of
its own local lists) will send a checksum along with the DEL/REP commands.
- The checksum is checked by the target servers. If it doesn't match, an
informational message is sent to the postmaster, and a 'LSVLDELT REFRESHME'
command is sent to the LISTSERV at the node where the error was detected.
- A new command, LSVLDELT, has been implemented. It should normally not be
used by postmasters, so I chose a nasty name. There are four options to this
command:
* 'LSVLDELT REFRESHME' causes a "refresh" X-LUPD job to be sent to the
originator. This job contains a 'DEL *' statement and 'REP' instructions
for each list, and NO checksum (to avoid a loop if there somehow happens
to be a bug in the checksum routine). This should normally be used only by
another LISTSERV.
* 'LSVLDELT REFRESH userid@node' causes a "refresh" job to be sent to the
specified address. It should normally never be used.
* 'LSVLDELT REFRESH' causes a "refresh" job to be distributed to ALL the
backbone servers. It may be used when an inconsistency has been (manually)
detected.
* 'LSVLDELT INIT userid@node' causes a complete copy of GLOBLIST FILE to be
sent to the specified address. This should be used by the LMC when a new
server has been added to the backbone, to speed up its refresh process and
to avoid seeing it sending useless 'LSVLDELT REFRESHME' requests
everywhere in the world.
The LSVLDELT command is restricted to the postmaster, LMC and LCOORD.
Additionally, any LISTSERV may use the REFRESHME option (only).
- Each server will make sure to send at least one X-LUPD job per month. If
there has been no change broadcasted in the last 30 days, it will send a
dummy job with just a 'CKS' statement. Thus if some previous X-LUPD job was
lost in a COLD start, a checksum error will be detected within 1 month and
the problem will correct itself automatically.
This is a bit complicated because of the distributed approach and asynchronous
nature of the network, but it should work without generating too much traffic.
I couldn't think of anything simpler that would detect lost files.
Eric
|
