> ## 1 Overview

> This chapter describes how two File Transfer Service applications interact.

> ### 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.

> ### 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).

> #### 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

> #### 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-2003 Ericsson Utvecklings AB