Installation Instructions

System Requirements:

JDK 1.3.1 or above
Postgresql 7.1.3 or above

1.Download the latest tar ball from here
2.Untar it and it will create a directory structure in the current directory.
3.In the present implementation we used PostgreSQL as database to store the state of various transfers and to build the state in the event of a crash of RFT Service.
You can create the database with the required schema by running the script createDatabase.sh which is present in bin directory
Make sure that you have postgresql installed and configured properly (postmaster should be running with -i option for postgresql to accept connections using TCP.Contact your system admin for more info).
4.Set your Globus Environment.
5. The Service reads all the configurable parameters like Database name, Database URL,host on which the database is present,username,password for the database from a properties file which should be updated with appropriate values.It can be found in bin directory.A sample Properties file which is a simple text file is as follows (The meaning of various values is explained below) :

url=jdbc\:postgresql\:madduri # Database URL Required for JDBC
maxthreads=100			# This is maximum number of transfers
that can be active at a given point
port=14159					# Port number where
the service listens for the requests
dbname=madduri			# Name of the Database
dbhost=wiggum.mcs.anl.gov # Name of host where database is located
user=madduri				# Username  for the Database
maxtrials=10				# Maximum number of retrials that can be made
password=madduri			# Password for the database
netloggerURL=x-netlog\://terra.mcs.anl.gov\:14835/ 	#Netlogger URL for sending Performance Markers
driver=org.postgresql.Driver	# JDBC Driver for PostgreSQL database.
DCAU=off # DCAU option off( required for old ftp servers)

6.If you want to do transfers using gridftp make sure that your grid-proxy is valid until the end of all the transfers and you are in the gridmap file of both source and destination machines.
7.Update the transfer.host netlogger.port transfer.port netlogger.host entries in control.properties file (found in bin directory) to point to appropriate locations or the other way to do it is using the Control Client GUI.Go to Settings menu and click on Edit Service Locations option and fill in the details for locations of TransferService and Netlogger service.Then save the settings.This will bind the Client to the server.You can do this even if you want to bind the Client to a service running in a different location/port.
8.Two convenient scripts are porvided with the distribution that can be used to start the transfer service and the control client that takes care of most of enviornment issues.However you may have to edit them so that they may reflect your enviornment correctly (like location of java install)

Database Schema:

You can create the database with the required schema by running the script createDatabase.sh

The database schema is as follows :
1.Request Table: This table is used to store the Transfer requests
(
    id                  int primary key, --unique id for each transfer
automatically generated
    u_time              int     not null, -- use UNIX timestamp to allow
for
exponential backoff on retries
    concurrency         int     default 1,-- Concurrency constraint
submitted as part of request
    friendly_name       text    not null, --Name given to a set of transfers
)

2. Transfer Table:This table is used to store individual transfers
(
    id                  int     primary key,
    request_id          int     default 0,
    process_id          int     default 0,
    source_url          text    not null,
    dest_url            text    not null,
    publish_id          text,   -- maybe we should just use 'id', its
unique
    control_url         text    default '',
   status              int     default 0,
    attempts            int     default 0
)

3. Restart Table: This Table is used by the transfer client to store
the
restart markers.
(
     	transfer_id 	int,
	marker 		text

)

Usage Instructions

1. The Service can be started from the bin directory using the script ./transferService and the service listens at the port number specified in the Properties file.
2. When started for the first time the Service tries to load any pending transfers from the database then starts the pending transfers if any. 3. Transfer Requests can be submitted to the Service using the Client GUI which can be started using the script transferRequestGUI.

4. Transfer Requests can be submitted in two ways.
	a. Create a file that lists all the transfers in the following
format:
		RequestName
		Concurrency --------------- Number of Active Transfers
at any given time.
		Source File URL1
		Destination File URL1
		Source File URL2
		Destination File URL2
		Source File URL3
		Destination File URL3 and so on..

		Open the file from Client GUI using Menu File -- Open
Transfer Request.

	b. Enter a name that uniquely identifies the transfer in the
text box adjacent to Request Name.Enter the Concurrency and then press the Add Transfer button.Add
the Source and Destination URLS in the GUI that pops up.
	    Enter as many transfers as needed and Submit the request.You
can also
save your request using menu File--- Save.

5. After you submit the transfer you can see the status of your transfers in a tabular format which lists all the submitted transfers by default.
6. You can filter the transfers you want to see using the drop down which lists names of all the Transfer Requests.
7. The Status of the transfers are dynamically updated and the valid Status

Strings are as follows:
	a. Active ----------------- The Transfer is currently in progress
	b.Finished---------------- The Transfer has been successfully
completed.
	c.Retrying--------------- A recoverable error ( non fatal )
error has been encountered while trying to transfer so the service would retry
to transfer until the allowed number  	   of retries.
	d.Pending-----------------The Transfer has been queued which
may occur by one of two conditions or both. The Transfer may be queued when the Service
reaches the	   maximum number of active transfers or the transfer
has been queued to satisfy the Concurrency constraint associated with the request.
	e.Failed--------------------- The Transfer is considered failed
when the service encounters a fatal error while doing the transfer or it exceeded
the maximum number of retries 	   and the transfer is not succeeded.
	f. Cancelled--------------- The User can cancel the Transfer
at any point,this status denotes that the transfer has been cancelled on user's request.

8. The Performance and Progress of the transfer can be actively monitored using Netlogger service. When you double click on any active transfer you can see a graph which is plotted with time against throughput.
9. The number of parallel streams in which the transfer is done can be changed dynamically. Click on the ShowControls button in the performance GUI and enter the number of parallel streams for the transfer (valid values are multiples of two). This kills the transfer and opens the entered number of sockets on both source and destination and continues the transfer from the point where it stopped it using the entered number of parallel streams.
10. The performance data is archived and can be obtained for any transfer by double clicking on the appropriate request.
11. The locations of RFT Service and Netlogger service can be dynamically configured in the ClientGUI using the Menu option Settings----Edit Service Locations-----Enter the hostnames of both the services along with the port numbers.