2 Overview of the Smap Architecture

The Smap server consists of the following conceptual parts: smapd daemon, map modules and databases.

smapd daemon

The smapd daemon is the principal part of the system. It is responsible for handling incoming connections and dispatching socket map requests to appropriate modules.

Map 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.

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.