open Introduction
The project, references, etc...

open Glossary
Glossary of our product.

close Background
how DICOM works
archive server / simple storage

open GUI
Your first MIND session.

open Commands
Index of MIND commands

open Project Page
MIND team Project page

open Related Links
Outside pages relating to DICOM, CTN and other related pages.

Background: Archive Server and Simple Storage

Before I begin to explain how our DICOM server functions, please remember that this is a CTN implementation of the DICOM standard. Other implementations may do things differently, particularly when it comes to the individual applications that make up the server and how they relate, despite the fact that they accomplish the same task.

There are several parts to our image server, orchestrated by individual applications that work together. The applications that provide the framework are archive_server, archive_agent, ris_gateway, and archive_cleaner. These are separate programs, and archive_server and ris_gateway actually monitor TCP/IP ports for connections. Together, these programs make up an image server.

In addition, unrelated to the DICOM image server role, a SQL server also exists, and is used for storing databases used by the image archives, as explained below. Although not part of the image server itself, it is crutial to its functionality, as all data and configuration information is stored within a SQL database. For our purposes, we use mSQL, a free SQL server. Each image archive is configured by a control database (SQL). An image archive consists of an image database and its servers. It is important to note that there can be many image archives on a single DICOM server. The image archive contains two SQL databases, the image database (where DICOM images are stored), and a FIS database. The term FIS actually means Fake Information System, which means that our database is not actually a full blown real world database. Actually DICOM servers would have HIS/RIS (Hospital Information Systems and Radiology Inforamtion Systems) databases.

Now back to the individual applications. The user actually will interact with archive_server. It allows one to store and query complex objects such as images and RT objects. The archive_agent runs alongside archive_server, taking some of its work queue and performing the required tasks. The difference between the two comes in when one runs more than one image archive. Remember, it is possible to run multiple archives on a single server, meaning that archive_server itself need only run as a single process, but for each image archive there must be a separate copy of archive_agent running. Each archive_agent process monitors a single image archive work queue. This allows for individual processes to control independant image archives.

The third application, archive_cleaner, does not run full time. It is invoked by the user periodically to remove images that extend beyond a specified time interval.

The fourth and final application, ris_gateway, performs a very similar role to archive_server, however allows for different association requests. It is a separate server, with its own port and AE title (used by DICOM to label applications) and thus appears to be a completely different server, even though it may actually use the same databases as archive_server, it allows for different actions to be done on the database. As we are only using a FIS database, we do not need the added functionality provided by ris_gateway (storage of reports using DICOM HIS/RIS services), and thus we do not typically run this server.