Apart from the pnfs server, all of dCache makes use of the cell package. It is a framework for a distributed and scalable server system in Java. The dCache system divided into cells which communicate with each other via messages. Several cells run simultaneously in one domain.

Each domain runs in a separate Java virtual machine and each cell is run as a separate thread therein. The domains communicate with each other via TCP connections which are established at start-up. In the standard setup all domains connect with the dCacheDomain which routes all messages to the appropriate domains. Note, that actual data transfers are not done via these established connections.

At start-up a domain asks the serviceLocatorHost on the serviceLocatorPort (as configured in config/<domainName>Setup) for a domain to connect to. This request is handled by the location manager in the lmDomain In the standard setup it will tell all other domains to connect to the dCacheDomain and will provide the necessary connection information. A TCP connection between the new domain and the dCacheDomain will be established.

Within this framework, cells send messages to other cells addressing them in the form <cellName>@<domainName>. This way, cells can communicate without knowledge about the host they run on. Some cells are well known, i.e. they can be addressed just by their name without @<domainName>. Evidently, this can only work properly if the name of the cell is unique throuout the hole system.

If two well known cells with the same name are present, the system will behave in an undefined way. Therefore it is wise to take care when starting, naming, and renaming the well known cells. Some cell types, like the PoolManager will always be well known, while others may be made well known by the -export option. Some cell types can and should never be well known. The same problem can arise if two dCache instances which are meant to be separate use the same location manager due to a miss-configuration: Messages meant for e.g. the pool manager of one instance get routed to the pool manager of the other instance which generally will not be able to handle the request properly.

A domain is started with a shell script jobs/<domainName> (which in the standard setup is for all domains a link to jobs/wrapper2.sh). This will use the configuration variables in config/<domainName>Setup (which normally is a link to config/dCacheSetup), start the Java virtual machine and execute the cell package commands in config/<domainName>.batch. The main task of these commands is to start up all the cells which should be running in the domain. It follows a typical batch file.

set printout default 2
set printout CellGlue none
onerror shutdown

check -strong setupFile
copy file:${setupFile} context:setupContext
import context -c setupContext
check -strong serviceLocatorPort serviceLocatorHost
check -strong sshPort ftpPort

create dmg.cells.services.RoutingManager  RoutingMgr
create dmg.cells.services.LocationManager lm \
       "${serviceLocatorHost} ${serviceLocatorPort}"

create dmg.cells.services.login.LoginManager GFTP \
            "2811 \
             -export \
             diskCacheV111.doors.GsiFtpDoorV1 \
             -prot=raw \
             -clientDataPortRange=${clientDataPortRange} \
             -root=${ftpBase} \
             -kpwd-file=${kpwdFile} \
             -tlog=/tmp/dcache-ftp-tlog \
             -maxLogin=100 \
             -brokerUpdateTime=5 \
             -protocolFamily=gsiftp \
             -loginBroker=LoginBroker \
             -poolManagerTimeout=5400 \
             -pnfsTimeout=120 \
             -maxRetries=80 \
             -maxStreamsPerClient=10 \
             -ftp-adapter-internal-interface=10.0.1.1 \
"

It is not necessary to understand every detail of the syntax of the batch files even for the most advanced dCache administration tasks. The following explanations should be sufficient: The first tree lines set some logging behaviour.

The next 5 lines import the variables from the config/<domainName>Setup file into the context of the domain. The values of the variables defined in the setup file are placed whereever ${<variableName>} appears.

The create commands at the end start three cells. It takes up to three parameters: The Java class to start, the name of the cell and the argument string which is passed to the class. In the standard setup, most parameters to the cells are either set to reasonable values or are filled from variables defined in the setup file. This way, the batch files only need to be changed for more advanced configuration tasks.

The routing manager and location manager cells are started in each domain are part of the underlying cell package structure. Each domain will contain at least one cell in addition to them.