In this section we give more technical details about the implementation of the PROOF system.
To use PROOF a user (the client) needs to start a PROOF session. Practically this means creating an instance of a the TProof class, which represents (maps) the PROOF session.
The first argument of TProof is an URL representing the network address of the PROOF master node: this is a machine where a xproofd daemon runs and accepts connections on a given port (default 1093). The same, as we will see below, isrequired on the worker nodes. A prerequisite to start PROOF sessions is therefore the availability of a set of machines with xproofd running on it (or xrootd with the XrdProofdProtocol enabled on it). This situation is depicted in Figure 1.
Figure 1. PROOF cluster in idle state; the daemons are ready to accept connections on the specified ports.
To start the session the user issues the command
root[] TProof *p = TProof::Open("master")
This opens a TCP socket to the master and logins the client to the master xproofd (by running the authentication handshake, if required). This is depicted in the top part of Figure 2. Once logged in, the master process (proofserv in master mode) is forked by xproofd (step 2 in the middle of Figure 2). Finally, when proofserv is up it calls back xproofd to establish the second component of the connection (a UNIX socket) used to communicate with the client.
Figure 2. Setting up the master: 1) login; 2) proofserv fork; 3) UNIX connection.
Once the connection with the client is up, the master proofserv proceeds to setup the rest of the session, namely the workers. The list of the workers is obtained from xproofd, where it is determined by the scheduler instance on the base of the configuration file or the dedicated worker configuration file (proof.conf). Then a TProof instance, in master mode, is created; this instance, which, during construction, opens the connections to the worker machines to setup the worker processes. This is done serially and each step is the exact replica of the master process creation (TCP socket, login, fork and UNIX connection setup; see Figure 3).
Figure 3. Setting up the workers: the steps described in Figure 2 are repeated serially for each worker.
Once the whole process is finished the situation looks like the one depicted in Figure 4, with the client connected with the master process and the master process connected to the worker processes.
Figure 4. PROOF session up and ready to process the client commands.
