FTS User Guide

This document describes the user interface to FTS, in other words how to submit and manage transfers. Longer, detailed guide can be found in gLite User Manual.

Channel management and service configuration are described in the admin guide.


FTS transfers are managed via glite-transfer-* commands.

The main commands are:

Submits a transfer job
Displays the status of an ongoing transfer job
Lists all submitted transfer jobs owned by the user
Cancels a transfer job


You will need a valid proxy in order to use these commands.

On first use, the glite-transfer-submit command will automatically delegate your proxy to the FTS server (default lifetime is 12 hours).

When the remaining lifetime of the stored proxy passes under 4 hours, glite-transfer-submit will automatically delegate a new one.

Currently the _only_ way a Myproxy server can be used is via the legacy "-p" option. Proxies delegated to the FTS have to be renewed by the _user_, because the FTS renewal code does not work for VOMS attributes.

Submitting a transfer

The user can submit a transfer either by specifying the source-destination pair in the command line:

$ glite-transfer-submit -s \
srm:// \


or by specifying all source-destination pairs in an input file (bulk submission).

The -s option specifies the FTS service endpoint to be contacted. If the service starts with http://, https:// or httpg:// it is taken as a direct service endpoint URL; otherwise is taken as a service instance name and Service Discovery is invoked to look up the endpoints. If not specified the first available transfer service from the Service Discovery will be used. This is true for all subsequent examples.

 $ glite-transfer-submit -s \ -p $passwd

where the input file looks like:

$ cat
srm:// \
srm:// \
srm:// \

Attention! The transfers handled by FTS within a single job bulk submission must be all assigned to the same channel, otherwise FTS will not process such transfers and will return the message: Inconsistent channel.

Querying a transfer

The following example shows a query to FTS to infer information about the state of a transfer job:

$ glite-transfer-status \
-s \
-l c2e2cdb1-a145-11da-954d-944f2354a08b

Attention! The verbosity level of the status of a given job is set with the -v option; the status of individual files is however available through the option -l.

The following example allows to query all ongoing data transfers in the specified (intermediate) state in a defined FTS service. In order to list only the transfer jobs relative to a channel, this must be specified with the -c option.

$ glite-transfer-list \
-s Pending
c2e2cdb1-a145-11da-954d-944f2354a08b Pending

Cancelling a transfer

An example of cancellation of a previously submitted data transfer job is shown here:

$ glite-transfer-cancel -s c2e2cdb1-a145-11da-954d-944f2354a08b


The FTS service comprises an FTS server used for configuration and user-level transfer management, and two types of agent which execute the transfers.

FTS Web service ("FTS")

This component allows users to submit FTS jobs and query their status. It is the only component that users interact with. It runs as a Tomcat web-application (Java based). The node also has a local BDII with a GIP publishing the necessary information about this FTS server (the site BDII should configured to pull this information).

Referred to throughout a node type FTS.

FTS agents ("FTA")

These are the back-end agents that do the work of the service. Each agent runs as a distinct daemon, and you may have as many agents daemons running on a node as it can support. There are two main type (channel and VO agent) which may be mixed across nodes as necessary.

Referred to throughout a node type FTA.

FTS agents: channel agent

Each network channel, (e.g. "transfers from CERN to RAL") has a distinct daemon running transfers for it. The daemon is responsible for starting and controlling transfers on the associated network link. When a transfer is started, a controlling process for that transfer is (double) forked from the controlling agent.

There should be one agent daemon for every channel that the FTS has defined, each managing a different channel.

Since they produce a large number of forked processes, the channel agent daemons are generally spread over a number of agent nodes ~equally.

FTS agents: VO agents

Each VO served by the FTS service has a distinct VO agent daemon running for it. This performs house-keeping tasks for that VO. There should be one VO agent daemon for every VO that will use the FTS service.

The VO agents consume very little resources and can be put freely on any agent node in the cluster.


This document is based on the gLite User Guide.

Last modified 3 years ago Last modified on Sep 7, 2012 12:15:37 PM

Attachments (2)

Download all attachments as: .zip