M-StoreArchitecture
The diagram below illustrates the architecture of the Isode X.400 Message Store and its relationship to P7 client and to its associated X.400 MTA using X.400 P3. An X.400 Message Store is associated with a single X.400 user. M-Store X.400 uses a single process to support multiple X.400 clients, retaining separate databases for each X.400 client (UA).
There are two databases (of the same format) for each Message Store client; an "In Box" that holds messages delivered to the user and an "Out Box" for messages sent by the X.400 client. Each message is held as a single file on disk that contains:
- Message Content.
- Message Envelope Information.
- Message Store Sequence Number and Child Sequence Number information.
- Cached index attribute values
This file is written once on message delivery (or submission), and not changed subsequently. The files are named by the parent sequence number, which is the primary index to the message in the P7 protocol, plus a 'state' character, indicating whether the message is New, Listed or Processed. As a message progresses through these states it is renamed appropriately.
By use of the file store, the indexing and integrity mechanisms of the file store are utilized by M-Store X.400. There is no complex database, and so problems associated with database corruption are avoided. Some operations, such as fetch based on sequence number can operate very efficiently using just this database structure.
In order to support efficient searching and listing of messages, M-Store X.400 maintains an optimized message index.
Note that authoritative message information is held in the message databases. The message index can be completely rebuilt from the message database, and the presence of prebuilt index attribute values stored in message files means that a full decode of messages is not required during this process.
The M-Store X.400 server is a single process, comprising a number of modules. The P7 server module supports P7 connections initiated by multiple P7 clients and will:
- Support Summarize, List, Fetch, Register (auto action) and Delete operations using the In Box or Out Box database.
- Pass Indirect Submission operations to the P3 Submission module.
- Send auto-alerts to the P7 client, as requested by the P3 delivery module.
The P3 submission module will initiate a connection to an MTA for indirect message submission. After the message is submitted, a copy may be stored in the Out Box database.
The P3 delivery module accepts messages being delivered by an MTA. Delivered messages will be stored in the In Box database, and then registered auto actions are processed. Auto-forwarded messages are handled through the P3 Submission module. Auto alerts are passed to the client through the P7 server module.
After a message is delivered into the In Box database for a user, the most recent message for that user is cached in memory. In a typical high performance system, the P7 client will have a registered auto alert and will fetch the message immediately and thus make use of the memory cached copy. Clients will generally cache message copies, and in this case the only further message change will be when it is deleted. Thus the only disk i/o is that needed to write the message, and rename the message file to reflect the change in its status. The message database format is chosen to be efficiently generated from a P3 delivery. This approach provides for very high volume and low latency delivery.
The message index is held in memory within the M-Store X.400 server. It is periodically flushed to disk, and is also written out on a clean shutdown, so that it can be quickly reloaded when M-Store X.400 is restarted. On restart, M-Store X.400 runs an index check routine to ensure that the reloaded index for each mailbox is consistent with the set of message files present in the mailbox (since inconsistency could arise if M-Store X.400 has been shut down uncleanly). This check runs as a background process; while it is running, messages can be submitted and delivered as normal.