Using the File Transfer Service

## 4 Using the File Transfer Service

### 4.1 Overview

This chapter describes how two File Transfer Service applications interact.

#### 4.1.1 Components

There are several ways the OMG File Transfer Service can be used. Below one scenario is visualized:

Figure 1: The File Transfer Service Components.

- Source ORB: this is the ORB we want to transfer a file from/via and it holds an object reference to a Virtual File System (VFS) which, in this example, represents an FTP server.
- Target ORB: the goal may be, for example, to transfer a new file or append to an existing file placed at the location that this ORB's `VFS` represents. In this scenario it is the local disk or the NFS.
- Transport Protocol: initially the ORB's, i.e., target and source, communicate via normal `CORBA` requests to determine whether or not they can communicate. If the File Transfer Service's have one, or more, `Transport Protocol` in common the data will be streamed using this protocol. The cosFileTransfer application currently supports `TCP/IP` and `SSL`.

Which type of file system the `VFS` is supposed to represent is determined by the options given when creating it, which is also how one determine which `Transport Protocol` to use. Hence, the source and target `VFS` described above can be started by invoking, respectively, the following operations:

    1> SVFS = cosFileTransferApp:create_VFS('FTP', [], Host, 21, [{protocol, tcp}]),
    2> TVFS = cosFileTransferApp:create_VFS({'NATIVE', 'cosFileTransferNATIVE_file'},
                                            [], OtherHost, 0, [{protocol, tcp}]),

Naturally can any combination of `VFS`-types be used and it is also possible to use own drivers, i.e., `{'NATIVE', 'MyDriver'}`.

After creating necessary `VFS's` we can login in and perform operations on files and directories residing on each file system.

#### 4.1.2 How To Use SSL

To be able to use `SSL` as transport protocol a few configuration parameters must be set. The required parameters depend on if Orber is the target or/and the source ORB. However, the SSL_CERT_FILE variable must be defined in both cases.

Setting of a CA certificate file with an option does not work due to weaknesses in the SSLeay package. A work-around in the ssl application is to set the OS environment variable SSL_CERT_FILE before SSL is started. However, then the CA certificate file will be global for all connections (both incomming and outgoing calls).

##### 4.1.2.1 Configurations when cosFileTransfer is Used as Target

The following three configuration variables can be used to configure cosFileTransfer's SSL target behavior.

- ssl_server_certfile which is a path to a file containing a chain of PEM encoded certificates for cosFileTransfer as target.
- ssl_server_verify which specifies type of verification: 0 = do not verify peer; 1 = verify peer, verify client once, 2 = verify peer, verify client once, fail if no peer certificate. The default value is 0.
- ssl_server_depth which specifies verification depth, i.e. how far in a chain of certificates the verification process shall proceed before the verification is considered successful. The default value is 1.

There also exist a number of API functions for accessing the values of these variables:

- cosFileTransferApp:ssl_server_certfile/0
- cosFileTransferApp:ssl_server_verify/0
- cosFileTransferApp:ssl_server_depth/0

##### 4.1.2.2 Configurations when cosFileTransfer is used as Source

Below is the list of configuration variables used when cosFileTransfer act as the source application.

- ssl_client_certfile which is a path to a file containing a chain of PEM encoded certificates used in outgoing calls.
- ssl_client_verify which specifies type of verification: 0 = do not verify peer; 1 = verify peer, verify client once, 2 = verify peer, verify client once, fail if no peer certificate. The default value is 0.
- ssl_client_depth which specifies verification depth, i.e. how far in a chain of certificates the verification process shall proceed before the verification is considered successful. The default value is 1.

There also exist a number of API functions for accessing the values of these variables in the client processes:

- cosFileTransferApp:ssl_client_certfile/0
- cosFileTransferApp:ssl_client_verify/0
- cosFileTransferApp:ssl_client_depth/0

Copyright © 1991-2007 Ericsson AB