Remote ROOT

We describe here a few ideas to implement remote control, and running for a ROOT session. The main purpose is to use a remote machine to produce graphic objects which are then displayed locally, avoiding the heaviness of doing X over the network. In future we may extend all this to any object, though limitations may arise from the fact that the analysis may need to access information (files, dirs), available locally but not remotely.

Architecture

The idea is to have a standar 2-tier client-server architecture, a simplified version of the client-master system in PROOF. The server runs a implementation of TApplication accepting input from a TCP connection to the client; after execution the graphic objects and a log file are sent back to the client. The client runs an instance of an interface class that allows to send commands over and to collect the results. After collection the received canvases are displayed locally.

Setting up

The first step is to setup the session, i.e. to start the remote application and to connect it to the client. The idea is that the client first opens a server socket accepting connections on a given port; the client then executes an appropriate ssh command starting remotely the session and indicating the host:port on which it will be listening. The client then waits for a callback of the remote application. In case of firewalls the callback can be tunneled via an ssh-channel. This technique has been successfully prototyped. The command to be executed is the following:

ssh -f ganis@lxplus217.cern.ch -R 3000:pcepsft43.cern.ch:3001 "/tmp/ganis/root/bin/remsrv.sh 1 pcepsft43.cern.ch:3000"

Server application

In the prototype the server application is called TRemSrv . It implements a derivation of TApplication and follows the lines of TProofServ.

Client interface

The client interface has yet to be designed. Its tasks are:

• forward the typed commands encapsulating them into a TMessage; some parsing is needed to see, for example, if a file needs to be send over before processing
• collect the log files and the results
• display the results
• handle interrupts, errors, ...

For the prototype, the relevant client commands (socket accept, send messages, ...) were played from the ROOT command line.

-- GerardoGanis - 04 May 2007