Table of Contents
The Reliable Transfer Service (RFT) Service implementation in GT 4.2.0 uses standard SOAP messages over HTTP to submit and manage a set of 3rd party GridFTP transfers and deletion of files and directories using GridFTP. The service also provides an interface to control various transfer parameters of the GridFTP control channel like TCP buffer size, parallel streams, DCAU etc. The user creates a RFT resource by submitting a Transfer Request (consisting of a set of third-party gridftp transfers) to the RFT Factory service. The resource is created after the user is properly authorized and authenticated. RFT service implementation exposes operations to control and manage the transfers (the resource). The resource the user created exposes the state of the transfer as a resource property to which the user can either subscribe for changes or poll for the changes in state periodically using standard WS-RF command line clients and other resource properties.
Features new in GT 4.2.0
Supported Features
- Delete files: Delete a set of files/directories on a GridFTP server.
- Exponential Backoff: Configurable exponential back off before a failed transfer is retried.
- Transfer All or None: If this option is set and one of the transfers in the request fails, RFT will stop transferring the remainder of the request and delete the files that were already transferred successfully.
- Transfer Permissions: File permissions are restored at the destination once the file is transfered successfully. This can be configured to throw a fatal error or a transient error depending on whether the GridFTP server supports the MLST command.
- Configurable number of concurrent transfers per container and per request.
- Better error reporting and faults.
- Database purge of the request and transfers after life time expiration.
- Cumulative (aggregate ) Resource Properties on the factory provide some statistical information.
- One status Resource Property for the entire transfer.
- Recursive directory transfers and deletes.
- Parallel streams.
- TCP Buffer Size.
- Third-party directory transfers, file transfers and deletes.
- Data channel authentication (DCAU).
- NoTPT option.
- Different subject names for source and destination GridFTP servers for the authorization mechanism.
- Support for binary/ASCII type of transfers.
- Configurable number of retries for failed transfers per request.
- Block Size in bytes.
Deprecated Features
- None
- New in RFT 4.2 is a connection caching feature. This allows internal GridFTP connections to be internally cached globally across all service requests. This has shown to be a vast performance increase in the case where a single user wishes to transfer many URLs, but instead of transferring them in a single request, they put each URL in a separate request. Caching helps this case specifically, and is a general optimization for other cases.
- The backoff algorithm has been modified. To start with, all errors in communicating with GridFTP servers are considered transient. In the past we considered authorization failures and DNS lookup failures, as well as other similar things, as fatal. We have since recognized that even those shall pass, and in some environments those should be expected as a means of controlling load.
- Additionally, how we back off is different. If a failure is detected, we do not try to communicate with the given GridFTP server for a specified amount of time, or until some other transfer completes successfully with that server. This allows for optimal use of GridFTP servers that only allow a fixed number of connections at once, and it helps make optimal use of our connection cache.
- Bug 3864
- Bug 4847
- Bug 4849
- Bug 4850
- Bug 5494
- Bug 5660
- Bug 5783
- Bug 5910
- Bug 5915
- Bug 6038
- Bug 6039
- Bug 6040
- Bug 6044
- Bug 6056
- Bug 6063
- Bug 5942
- Bug 5943
- Bug 2749
- Bug 2724
- Bug 2683
- Bug 2662
- Bug 2703
- Bug 2847
- Bug 2826
- Bug 2312
- Bug 2879
- Bug 2930
- Bug 2935
- Bug 2852
- Bug 2986
- Bug 3017
- Bug 2984
- Bug 2965
- Bug 2666
- Bug 2927
- Bug 3072
- Bug 2916
- Bug 2721
- Bug 2999
- Bug 3110
- Bug 3091
- Bug 3130
- Bug 2914
- Bug 3115
- Bug 2956
The following problems and limitations are known to exist for RFT at the time of the 4.2.0 release:
- 3121 - The configured maximum allowed active transfers constraint is not enforced.
RFT depends on the following GT components:
- Java WS Core
- WS Authentication and Authorization
- Delegation Service
- Service Groups
- MDS useful RP
RFT depends on the following 3rd party software:
- Optional : PostgreSQL 7.1 or later. Not tested with 8.0 yet.
- Optional : MySQL
Tested platforms for RFT:
Linux
- Fedora Core 1 i686
- Fedora Core 3 i686
- RedHat 7.3 i686
- RedHat 9 x86
- Debian Sarge x86
- Debian 3.1 i686
Mac OS X
- Mac OS X 10.3, 10.4
Tested containers for RFT:
- Java WS Core container
- Tomcat 5.0.30
Protocol changes since GT 4.0.x
- Added All or None option, maximum attempts, and finishBy to the transfer request
- Not backwards compatible with the OGSI version
API changes since GT 4.0.x
- None
Exception changes since GT 4.0.x
- None
Schema changes since GT 4.0.x
- WSDL changes to work with the new Java WS Core
See Reliable File Transfer (RFT) Service for more information about this component.