Go to the previous, next section.
@everyfooting Author: ensley // Editor: ensley // Texinfo: ensley @| @| 3 December 1994
The queuer receives it's information from the interfaces via a named
pipe (FIFO). This pipe allows for multiple interfaces to send
information to the queuer at the "same time". What is meant here by
"same time" is there can be multiple interface processes of different types
(email, telnet, etc) running at the same time and when they are ready to
submit a search, they can do so as long as the write to the named pipe
is done in one write() call. This is necessary because we don't want to
mix the data packets. Multiple search requests will remain in the pipe
until the queuer removes them and stores them in it's queue. The queue
data structure is necessary to handle niceness of search requests.
A detailed explanation of the interface-queuer communications can be
found in the Chapter titled: Interface-Queuer Communications.
The queuer communicates with the Searcher module via a normal pipe
set-up by the popen() command that initially spawned the Searcher. This
is described in detail in the Chapter titled: Queuer-Searcher
Communications.
The main data structure for this module is the Queue. The next item
ready to be submitted to the searcher will always be the item on top,
but because there is a niceness level for searches, entries must be
positioned in the queue relative to other search items and their
niceness values. Each item in the
Queue must contain the following:
-
Unique ID - This is a string received from an interface. It is used to
give each search made its own identity. From this ID the queuer can
signal the interface process that requested the search that the search
is complete and to take it.
-
Search Type - This is an integer which has been defined from
INSTALLDIR/src/include/search-types.h. A more thorough description can
be found in the Free Archie Users Manual in section "Detailed Search
Information". Always use the defines and never an integer value.
These defines will change as the searcher evolves. The following
searches are currently allowed:
-
EXACT - Exact String Search
-
SUBCASE - Case Sensitive Substring Search
-
SUBSTRING - Case Insensitive Substring Search
-
REGEXP - Regular Expression Search
-
Number of Hits - Maximum number of successful hits before ending search
-
niceness - Niceness level
-
search string - String to search for
The general algorithm can be outlined as follows:
The queuer loops forever while trying to read from the FIFO. If nothing
is in the FIFO it blocks until there is something. When there is
something, it queues the request and starts the loop over again, thus
building the queue for every request from any interface. When the
searcher is ready for another search request, it sends the queuer a
SIGUSR1 signal. The queuer catches this and if the queue is not empty,
it dequeues an item and gives it to the searcher. If the queuer is
empty it keeps track of the request and next time it receives something
it will be sure and send this request to the Searcher.
In debug mode, the all actions done by queuer are logged and/or written
to standard out and the current queue is printed if the Queuer receives a
SIGUSR2 signal.
Go to the previous, next section.