cosFileTransfer

User's Guide

Version 1.2.2

• User's Guide
• Reference Manual
• Release Notes
• PDF
• Top

• Expand All
• Contract All

Chapters

• The cosFileTransfer Application
  • Top of chapter
  • Content Overview
  • Brief description of the User's Guide
• Introduction to cosFileTransfer
  • Top of chapter
  • Overview
• Installing cosFileTransfer
  • Top of chapter
  • Installation Process
• Using the File Transfer Service
  • Top of chapter
  • Overview
• cosFileTransfer Examples
  • Top of chapter
  • A tutorial on how to create a simple service

4 Using the File Transfer Service

4.1  Overview

This chapter describes how two File Transfer Service applications interact.

Components

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

Figure 4.1:   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.

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 incoming and outgoing calls).

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

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