Silicon Graphics, Inc.
OpenVault (tm)
MLM Core
Design Document

$Id: server.html,v 1.11 1997/07/01 21:38:36 curtis Exp $

Overview and High Level Goals

The MLM Core is central to all processing performed by MLM. Virtually all transactions either originate with or flow through the MLM Core. The MLM Core will be logically broken down into a number of pieces including the following: A root process that negotiates client types and language versions, client interface processes (including MLM client processes, LCP/DCP processes, and admin processes), and a catalog process that contains the persistent store and the mechanisms for accesing it. Each of the interface processes may be further subdivided into pieces: An IPC layer for managing communications with the client, a command interpreter (CAPI, ADI, ALI, and AAPI), a set of action routines, and a database interface.

From the point of view of client processes (application, admin, DCP or LCP processes), the actual implementation details of the MLM Core, kernel data structures, and algorithms will be opaque. This will greatly simplify changes to the kernel in the future.

Externally, the MLM Core will behave like a transaction processing system and have ACID properties (Atomicity, Consistency, Isolation, and Durability).

The MLM Core will attempt to process all transactions concurrently. In general, it is not acceptable for MLM to block processing on one session because it is waiting for activity from another.

The MLM Core will scale from a small, single-user installation with only a few dozen cartridges to large data centers with hundreds of thousands of cartridges with many users. The MLM Core will also scale from small (desktop) machines to large servers. Obviously, larger installations will require larger machines.

Licensing will be included to limit various resources (concurrent sessions, supported devices, etc.) to allow various configurations to be sold at different price points.

The MLM Core will be designed with high availability in mind. It will be capable of quickly recovering from failures and will keep all persistent data in a consistent state at all times.

There will be a logging/audit mechanism to allow for system accounting, debugging, and security reviews.

Decisions / Assumptions / Limitations

Core Structure

In order to achieve some level of concurrent processing of transactions, the kernel will be multiprocessing. Every new connection to the MLM Core will cause a process to be forked by the root process to handle the needs of that specific connection.

GRIO, reservations, and revocation will not be supported the initial release.

No user-level authentication or access control will be performed by the MLM Core. It will be the responsibility of MLM application level clients to perform whatever user-level authentication is desired.

Communication and Authentication

Interprocess communications between the MLM Core and its clients will be handled by TCP socket connections. All connections must originate with MLM clients. Clients will contact the MLM Core by connecting to a well-known port number on a particular host. Once a connection has been established, the root process in the MLM Core will fork a process to manage that specific connection. That process will do client type and language version negotiation, and will then overlay itself with (exec) the appropriate type of child given the type of client. If authentication is enabled, it will be initialized at this time. The process will remain in place for the duration of the connection it is managing.

CAPI, AAPI, ALI and ADI Back Ends

Please refer to the appropriate design document.

Implementation


                              MLM CORE
                        ========================
                       /                        \         +-------+
    +--------+        /  +----+       +----+     \        | Admin |
    | Client |       /   |root|-------|C.4|-------\-------|  App  |
    |   #1   |-----_/    +----+\      +----+       \      |       |
    |        |     /\   /     \\\                   \     +-------+
    +--------+    /  +---+     ||\  +-------+        \    /--------------\
                 /   |C.1|     || --|catalog|---------\---| DB log files |
                |    +---+     ||   +-------+          |  \--------------/
    +--------+  |             / |                      |
    | Client |  |        +---+  |                      |
    |   #2   |--|--------|C.2|  |                      |
    |        |  |        +---+ /                       |
    +--------+  |             /                        |
                |        +---+                         |
                 \       |C.3|                        /
    +--------+    \      +---+                       /
    | Client |     \    /                           /
    |   #3   |---------/                           /
    |        |       \                            /
    +--------+        \                          /
                       ==========================
                        

              
               Figure 1 -- High level diagram of MLM Core

Overview

The MLM Core is responsible for accepting requests from one or more clients and processing them in an efficient manner. It is also responsible for generating requests to one or more specialized clients (LCP and DCP processes) responsible for controlling removable media libraries and drives.

Communications Layer

This portion of the MLM Core is represented by lines connecting MLM clients (outside the MLM Core) with processes spawned to manage these connections inside the MLM Core in Figure 1. In addition to transferring requests to and from the MLM Core, this layer also handles mutual client/server authentication. For a detailed discussion of MLM interprocess communication, see the IPC document.

Root Process

In Figure 1, the box labeled "root" inside the MLM Core represents the root process. The root process is responsible for initializing the MLM Core at startup, listening on a well-defined port for incoming connection requests from clients, and spawning client interface processes to set up each connection (negotiate language and version, then overlay itself with the correct child).

Client Interface Processes

The boxes labeled "C.1", "C.2", "C.3", and "C.4" in Figure 1 represent client interface processes. There is a one-to-one correspondence between a client interface process and an external client. A client interface process is spawned by the root process in response to an incoming connection request by an MLM client. An MLM client is defined to be one of the following:

An MLM application, such as Networker, which directly uses the services of OpenVault.
An administrative application, typically run by the MLM Administrator, and responsible for administering MLM.
A DCP client, responsible for controlling a particular drive.
An LCP client, responsible for controlling a particular library.

Each type of client speaks a different language to the client interface process associated with it, and each language has a different set of semantics associated with it. This enables MLM to separate the actions capable of being performed by the various types of client processes from one another while at the same time managing their interprocess communications in a consistent manner.

In addition to handling communications in a consistent manner, client interface processes also share some other duties. These include:

authentication,
interfacing with the catalog
generation and processing of events through a message passing mechanism,
memory management.

The message passing interface is implemented using the database. When one client interface process wishes to communicate with another client interface process, it adds that message to the end of a table (managed as a queue) maintained for that other process in the database. If the queue was empty before it added its entry, the first process will signal the second process that it has a new message in its queue. Client interface processes will revert to a sleeping state when there are no entries for them to process in their associated message queues and no traffic for them to handle from their associated external clients.

Catalog Process

This process is spawned by the root process during startup. It is responsible for implementing the MATCH/ORDER/NUMBER/REPORT clause semantics, and managing the integrity of the catalog. It is labeled in Figure 1 as "catalog". It also handles catalog chores such as periodic checkpointing of the contents of the catalog to an external file. Note that this process does not have any external processes associated with, or communicating with it.

Interfaces

External Interfaces

The only external interface to the kernel is the socket-based interface between MLM client processes and interface processes within the MLM Core. See the MLM IPC document for a detailed specification of this interface.

Internal Interfaces

There are two significant internal interfaces within the MLM Core. The first is the mechanism used to communicate between different server processes. It is a message passing interface, but in the first release it will be implemented using a memory mapped file that all processes have access to. When a process wishes to send a request to another process, it will insert the request into the other processes message queue in the shared mapped file space. If the other process' message queue was initially empty, the requesting process will then ping the other process with a socket connection request in order to wake it up and begin processing of incoming requests.

The second major internal interface is a special case of the message passing interface and is the interface to the catalog process. The caller generates a message as a structure in the shared mapped file and puts it on the message queue for the catalog. The catalog responds by putting a different structure on the incoming message queue for this process.

Silicon Graphics, Inc. OpenVault (tm) MLM Core Design Document