This document explains how to enable collaboration between multiple Flame Family workstations on a single local network. It also explains the roles the different components of the Flame ecosystem play and how to configure them for a smooth deployment.

The Flame Ecosystem

When you install Flame (or any Flame Family software) on a Linux or macOS station, several satellite components are also installed. These components can be categorized as Applications, Background Tasks, or Collaboration Services.

Application

This category includes the Flame Family software and all the different tools and scripts that are used by the standalone application.

Background Tasks

This category consists of the background job manager (BackburnerManager), its servers (BackburnerServer), and the job-specific adapters (BackgroundReactor, Wire, MediaConverter, Burn, etc.). The main application uses these services to offload tasks that do not require user interaction like rendering, caching, or transcoding.

Collaboration Services

This category consists of the services that make it possible for a remote Flame to work on a local project or enable your Flame to work on a remote project. Most of these services are part of the Flame distribution, but other services essential to collaboration are provided by the operating system.

Services installed as part of the Flame Family distribution:

• The Stone+Wire suite of daemons and tools provides managed distributed storage and high-performance parallel I/O from disk or network.
• The wiretapgateway daemon provides specialized media browsing, decoding, and encoding.
• The DLmpd is the multi-purpose daemon that provides remote system call optimizations and some more specialized services like remote archives and integrity checking.
• The ifffsWireTapServer provides Flame project access to standalone tools and a means of interoperability with other applications (mainly Lustre).

Services provided by the operating system:

• The NFS server provides local file system access to remote hosts and is used for NFS export.
• The automount daemon automates the mounting of remote NFS filesystems and is used for NFS import.
• Your choice of identity management: collaboration works best if you set up a central authority for user identification and authorization such as FreeIPA or Active Directory. How you set this up is specific to your facility and goes beyond the scope of this document.

Setting Up Collaboration

The Flame installer program configures the system so that basic collaborative workflows can work between multiple Flame Family applications on the same network. Every facility has its own particularities and you may have to tweak it to better suit your needs. Moreover, on the macOS platform, the installer may fail to appropriately configure the operating system depending on your security settings. This section will explain the steps taken by the installer so that you can validate or tweak your configuration. Each subsection provides a list of the network ports used. This may come in handy if you want to configure a firewall.

Workstation Identification

/opt/Autodesk/cfg/network.cfg contains a unique workstation identifier and the multicast configuration that enables automatic discovery of the services using the WireTap protocol (wiretapgateway, ifffsWireTapServer, BackburnerManager). If your workstation uses a single network interface, you should only have to worry about the following settings in this file:

[ Local ] → UUID: This token uniquely identifies your host - no two workstations on your network can have the same UUID. You can generate a UUID with this command to be executed in a shell terminal (same for macOS and Linux):

/usr/bin/uuidgen | /usr/bin/tr '[:upper:]' '[:lower:]'

[ Self Discovery ] → Port (7555): The network port over which all wiretap services notify each other of their presence on the network. The default is 7555 and unless it conflicts with another service, you should not have to change it.

[ Self Discovery ] → Scope (224.0.0.1): The multicast address used to broadcast information on the network. The default is 224.0.0.1 and identifies the local subnet. This is appropriate for a small network. If you have systems on multiple subnets, you must change the multicast scope. For example, on AWS, multicast across the AWS Transit Gateway doesn't work using 224.0.0.1, and you have to change the scope for 239.0.0.1.

[ Self Discovery ] → TTL (1): If the multicast traffic remains on the local network (single VLAN), the default Time-To-Live (TTL) value of 1 is adequate. If multicast packets must transit on different networks, the value should be increased. The TTL should be set as small as possible.

[ Dynamic Ports ] → LowerBound & UpperBound (49152-65535): Defines the range used for dynamically allocated network ports. It is sometimes necessary for a program to allocate an arbitrary port rather than a predetermined port. The wiretap services will pick such ports in the range defined here. Reducing the range increases the risk of port conflicts since no two programs can accept connections on the same port. A bigger range increases the attack surface of your system and, if you are configuring a firewall, forces you to open these ports if they must be accessible to remote hosts. The default range is the one defined by the operating systems. If your systems are running in an isolated local network, the default values are usually safe to use.

* The range is this table differs from the defaults in the network.cfg file because it accounts for other services using dynamic ports that do not yet obey these settings. The upper bound is also constrained by the Linux setting, 60999, which is lower than the config file upper bound.

To be usable for multicasting, the network interface must have the MULTICAST flag enabled at the OS level. This can be validated and changed using the ifconfig or ip link commands. Enabling the 'MULTICAST' flag on the 'loopback' interface is recommended to help ensure discoverability of local services.

Wiretap services without multicast

Wiretap relies on mutlicast to discover Flame Family-related services running on the local and remote hosts. Some network or host configurations can prevent Wiretap from using multicast to discover them. When this happens, use/opt/Autodesk/cfg/services.cfg to manually expose these services.

The /opt/Autodesk/cfg/services_snapshot.sh script can be used to create a services.cfg that contains information from local services. To update the local /optAutodesk/cfg/services.cfg, you can run the command /opt/Autodesk/cfg/services_snapshot.sh without any arguments. This will scan the local services on their default ports and create the file.

To update this file with remote services, add to the command the IP or hostname from the hosts to scan for services. For example: /opt/Autodesk/cfg/services_snapshot.sh localhost vxfhost 192.168.0.1

The script scans for ports known as the default for Autodesk network services. If ports other than the default ones are used, specify to ports to scan with the -p argument. For example: /opt/Autodesk/cfg/services_snapshot.sh localhost vxfhost 192.168.0.1 -p 42444

Stone+Wire Configuration

/opt/Autodesk/sw/cfg/sw_probed.cfg holds the parameters used by the sw_probed daemon that essentially provides the discovery service of the Stone+Wire network. The Stone+Wire daemon, sw_serverd, uses its own protocol and much like the WireTap protocol has a discovery mechanism with similar parameters. The main difference between the two is that Wire requires a dedicated daemon whereas, with WireTap, clients will also act as the daemon, receiving and sending presence data. The latter is more flexible but generates more traffic. While you may find a Scope and ttl setting in sw_probed.cfg, they are deprecated, and sw_probed now uses the Scope and TTL settings set in network.cfg.

[ Probe ] → Port (7001): This is the port over which sw_probed accepts connections for discovery queries. It defaults to 7001 and must be set to the same value on every host participating in a Stone+Wire network. This port is subject to conflicts as several vendors have elected this port for their services. NoMachine, the remote display software, and Apple's Airplay service are two such conflicting services. If you must use these services on the same system as Stone+Wire, you can either change the port number of the conflicting service, or sw_probed's. If you chose the second option, you must change the port number on all Stone+Wire systems to the same value.

[ Probe ] → SelfDiscovery(true): This parameter controls whether the sw_probed daemon will broadcast its presence and collect messages from other sw_probed daemons on your network. When true, automatic host discovery and explicit host identification through /opt/Autodesk/sw/cfg/sw_framestore_map are enabled. By setting it to false, you choose to rely solely on the /opt/Autodesk/sw/cfg/sw_framestore_map file to identify the other participating S+W hosts.

/opt/Autodesk/sw/cfg/sw_framestore_map is the predecessor of sw_probed. It is still useful when your network does not allow multicast messages beyond the local subnet. It lets you add arbitrary hosts to your Stone+Wire network. The caveat is that the sw_framestore_map file on every host must be updated every time the IP address, name, framestore ID, or network UUID of a host changes, or when a host must be added or removed. Should you choose to use this approach, consider centralizing this file on a shared filesystem and use a symlink to point to it.

/opt/Autodesk/sw/cfg/sw_storage.cfg assigns a framestore ID to your host. The framestore ID is a 10-bit integer; it has a range of 1 to 1023. It is used to locate media anywhere on your Stone+Wire network. All the media on your local Stone+Wire volumes is tagged with this identifier, likewise for the media on the volumes of remote hosts - they are tagged with their respective framestore ID. When Flame reads a frame from a local or remote project, its framestore ID is used to locate it. The framestore ID is queried with the sw_probed daemon telling Flame which host it corresponds to; Flame can then read the frame directly from storage if it is local or ask sw_serverd on that host to transfer it if it is remote. By default the framestore ID is assigned the 10 least significant bits of the IP address at the time of installation. For example, if the host IP is 192.168.7.114, the framestore ID is (7 % 4) * 256 + 114 = 882. The important thing is that each host has a unique framestore ID on your Stone+Wire network.

/opt/Autodesk/sw/cfg/stone+wire.cfg defines the storage volumes managed by your host. Each volume has a folder path, a partition ID, an optional name, and a Shared flag. Partition IDs are 3-bit integers and range from 0 to 7. Partition IDs can be thought of as extensions to the framestore ID. All media is also tagged with a partition ID that helps locate the volume on which it resides. Each volume stores media in its folder and maintains a database of this media. Some of the media may be "soft-imported" and only a descriptor file of the media is stored in the volume's folder. This descriptor holds the path to an external media file. The volume database manages these descriptor files as well but it will not manage the media files they reference.

[ PartitionN ] → Shared(false): The default, false, means that the host handles all I/O requests to the volume's storage. Setting it to true allows a remote host with access to the same folder under the same path to perform the I/O itself without going through the host's Stone+Wire daemon. The remote host must still obtain the location of the file from the Stone+Wire daemon, who will query the volume's database, but it can read or write media itself. This greatly reduces traffic on the project host when you have a shared storage solution available such as a SAN or NAS.

/opt/Autodesk/sw/cfg/sw_serverd.cfg defines the network port used to communicate with sw_serverd, the Stone+Wire daemon enabling distributed storage. The port defined here is used both by the clients running on the host to communicate with remote daemons and by the local daemon to listen for incoming connections. It must therefore have the same value on all hosts participating in a Stone+Wire network.

[ Server ] → Port(7000): The default, 7000, sometimes conflicts with the port used by Airplay on macOS systems. You can either disable Airplay or change the port number here and on all other S+W systems to solve the problem.

ifffsWiretapServer Configuration

/opt/Autodesk/wiretap/cfg/wiretapd.cfg defines the two ports used to communicate with the ifffsWiretapServer.

[ Server ] → NodePort(7549): This port gives external tools (non-Flame) access to the projects on the host. Lustre and the MediaConverter Backburner adapter are two heavy users.

[ Server ] → FramePort(7550): This port is used to establish a media transfer connection with the daemon. Requests on the NodePort are small and frequent and must be responsive. The FramePort prevents large media requests from impacting the response time on the NodePort.

DLmpd Configuration

This daemon does not have a configuration file of its own but it will honor the environment variables set in /opt/Autodesk/cfg/env.cfg. One could, for instance, override the default port (7700) of this daemon by defining the CSF_TEST_PORT environment variable and assigning it the desired port number. Clients expect to connect to the daemon on the default port, so CSF_TEST_PORT must be defined with the same value as the server for all clients. This is rarely necessary, no popular service has been known to conflict with DLmpd.

NFS Configuration

/etc/exports declares shared folders and NFS export options for each of them. The syntax is similar for macOS and Linux but the available options differ. Each folder can be exported to a restricted set of hosts with appropriate options. Refer to the exports(5) manpage for restriction details applicable to your environment. For collaboration to work, it should contain at a minimum the entries from the following table. Multiple entries can be grouped by exporting only a common parent:

After modifying /etc/exports, make sure to apply your changes by running

NFS requires the following ports to be opened in the firewall:

Automount Configuration

/etc/auto.master (Linux) and /etc/auto_master (macOS) define the mount points and mappings to physical directories that automount will manage. Flame relies on the -hosts mapping applied to /hosts to access /opt/Autodesk/clip, and /opt/Autodesk/project on remote hosts. The following entries must thus be present:

After modifying /etc/auto.master or /etc/auto_master, make sure to apply your changes by running