Transport Protocol Between Processes

Managers, Workers and clients

Managers, workers and administration clients may communicate via one of two supported transport protocols: either TCP or SSL. By default Flumotion uses SSL, which encrypts the data so it is not easily readable by looking at the network traffic. You should use this default wherever possible.

The transport protocol can be specified in the manager's XML configuration file and must then be specified in each worker's XML configuration file. See the Deployment chapter for more details about this part of the configuration files.

[Note] Note

Technically speaking, TCP is the transport protocol in both cases. SSL is a way of encrypting the actual TCP packets. In the context of Flumotion, however, we refer to both as protocols, where TCP is the standard TCP protocol (with plaintext communication), and SSL uses Secure Socket Layer on top of TCP.

TCP is the least secure because any communication using this transport protocol is readable as plaintext on the network. This means that anyone with access to the traffic on your network can see authentication information, remote method calls, and other information exchanged between the various processes.

[Warning] Warning

Because the TCP communication is visible as plaintext to anyone on the network, you should not use this transport except for testing, or in cases where you secure the communication through some other means (for example, through an SSH channel).

Generating The Certificate

For SSL communication to work, the manager needs a PEM certificate file. On startup, the manager looks for flumotion/default.pem under the system configuration sysconfdir directory. You can specify a different file using the --certificate parameter when starting the manager.

When Flumotion is installed from a standard Linux distribution package, a default certificate file is generated for you, but at some point you may wish to regenerate this file. For instance, the Fedora Linux package currently just creates a dummy default.pem file using fake data, via openssl's make-dummy-cert program.

You may generate a real RSA private key and certificate using openssl. For instance:

openssl req -newkey rsa:1024 -keyout private-key.txt -nodes -x509 -days 365 
-out certificate.txt

You will be asked to provide some details about yourself and your organization when running this command.

Then combine the private key and the certificate into one default.pem file. For instance,

cat private-key.txt >  ${target}
echo ""   >> default.pem
cat certificate.txt >> default.pem
rm -f private-key certificate.txt

Components

Components communicate with each other via unencrypted TCP connections because encryption of audio and video data would have a large processor performance cost. You should consider this when designing your network. See the Firewall Issues section for more information.

Of course, when the components are on the same machine, a localhost network socket is used. See the Optimizing component locations chapter for more information about which components should not communicate across the network because they would require too much network bandwidth.