The Smap server consists of the following conceptual parts:
smapd
daemon, map modules and databases.
smapd
daemonThe smapd
daemon is the principal part of the system. It
is responsible for handling incoming connections and dispatching socket
map requests to appropriate modules.
These are external loadable libraries which contain backend-specific lookup drivers. For example, one module may provide a driver for lookups in plaintext files, another one may handle DBM lookups and yet another – searches in MySQL databases. Notice, that modules provide abstract drivers, in the sense that they are not bound for look ups in particular disk files or databases. This specific information is supplied by Smap databases.
A database is an intermediate logical entity associated with a particular module. The database provides actual configuration for the module. Several different databases may be associated with the same module, thereby creating several instances of the same lookup driver.
If the underlying module allows for such use, a database may also be used to modify input map name and/or key value, before passing them on to another database.
The relationships between these parts are shown in the figure below:
Figure 2.1: Smap Control Flow
Here, the smapd
daemon is configured with six databases
(shown as Db a through Db f), interfacing to three
different modules (boxes Mod A through Mod C). The
databases ‘a’ and ‘b’ interface to module ‘A’,
databases ‘c’, ‘d’ and ‘e’ interface to module ‘B’,
and database ‘f’ interfaces to module ‘B’. All three
modules are linked with the libsmap library.
The box labeled ‘CLIENT’ represents a client program. When
smapd
receives a request from client (its path is shown
as a dashed line), it uses a set of dispatch rules (see
the ‘DISP’ box on the figure above) to dispatch it to the appropriate
database. This database (‘Db b’, on the figure) is used to
pass the request to the underlying module (‘Mod A’). The module,
after performing a look-up, sends the response back to the client (the
dot-dashed line on the figure), using interface functions
from libsmap. The latter is responsible for formatting the
answer in accordance with the socket map protocol.
If the request matches no database, the server sends a default ‘NOTFOUND’ reply back to the client.
Dispatch rules mentioned above are supplied by the user in the
smapd
configuration file. They resemble access control
lists: each rule consists of a condition and destination.
The condition may use various data from the connection and request
itself, such as client IP address or map name from the request, and
compare them with some static data. If the condition yields true, the
destination part of the rule points to the database which will handle
this request.