
The figure below summarizes the different components of the DPM and their basic interactions.
As described above, there are two node types on the server side, both interacting with the client.
Head Node
The entry point for clients, hosting the nameserver and the protocol frontend that has to redirect clients towards disk nodes. The components of the head node contain the logic that drive the decisions about authorizing clients, where to write new files, presenting the content, and many others. It may also host the database backend that gives persistency to metadata.
These daemons can be deployed on a single machine or on multiple machines, depending on the expected load.
APACHE
The well-known HTTP server, using our LCGDM-DAV plugin to speak to the rest of the DMLite framework
DPNS
The DPM nameserver daemon: handles all file and directory related metadata operations for the legacy protocols (SRM, RFIO)
DPM
The DPM daemon: handles file access requests (asynchronous queue management and interaction with the data access daemons)
SRM
XROOTD
A daemon exposing POSIX like high performance file access primitives, according to the xrootd protocol.
Disk Node
Nodes hosting actual data, providing remote access. Each of these nodes will run all data access daemons (rfio, xrootd, gridftp, httpd).
GRIDFTP
A daemon exposing secure FTP file access
RFIO
A daemon exposing POSIX like file access according to the rfio protocol. RFIO is used by the DPM daemon to locate files on the disk servers.
HTTP
Based on apache, provides file access on the disk node via the HTTP protocol. In the disk node it will only accept requests that have been signed by the head node (unless plain http access is desired)
XROOTD
A daemon exposing POSIX like high performance file access primitives, according to the xrootd protocol. In the disk node it will only accept requests that have been signed by the head node.