Rayfront User Manual

Host Configuration

(not supported with demo version)

Background

In order to enable processing of simulations on remote hosts, all systems involved need some information about how they see the data they want to work on. The assumption here is that the project data are located on a file server, and each client (or processing server) may have mounted that networked volume with a different name.

To overcome this confusion, a Rayfront installation allows to define internal names for any number of "locations" on the network. An editor process will then check if the current project has one of those named locations as among it's parent directories. If this is the case, then it will enable networking, and check if the configuration contains any systems that are declared as servers. If this is the case, then the simulation setup dialog will offer those systems as target hosts for remote simulations.

If a Rayserer receives a request to run a simulation, then it will check if it can translate the location name given into a physical path name on it's system. If so, then it has all the information it needs to find the project directory from its viewpoint, and will start the simulation. If not, then it will automatically reload the host configuration file and try again. If it still can't find the name after this, then it will refuse to serve the request.

The host configuration file is located in the installation directory as rayfront/config/hosts.

If an editor process doesn't find a host configuration file, if there is no record for it's hostname in there, or no name that covers the location of the current project, then it will disable networking and operate in local mode only. If a server finds not host configuration file or no record for it's hostname, then it will refuse to run.

File Format

The syntax of the file consists of any number of records. A record can have one of the following forms:

  <hostname> <#_of_cpus> [<pathname>="<localpath>" ...]

  __include__ <path_of_other_hostfile>

  __library__ <relative_path_of_library_file> <pathname>

  __library__ <absolute_path_of_library_file>

where the whitespace seperated items have the follwing meaning:

<hostname>

is the name the application gets from the local system with the gethostname(2) system call. This should be just the plain hostname, without any domain. If gethostname returns the fully qualified domain name, then your system is misconfigured. Still just use the simple hostname here. This makes it impossible to render on hosts outside your current domain. Is this a good idea?

<#_of_cpus>

is the number of CPUs that we can use on that system. This is currently ignored, but will limit the maximum number of concurrent processes on that host eventually.

<pathname>

is a name you specify for a network location. This must be unique and should only contain printable characters. For simpler configuration, use the upmost position of each file system subtree that can be reached by all hosts involved. However, you should try to avoid a situation where a project can be reached by more than one of the paths, eg. where one specifies a subtree of the another one.

<localpath>

is the path under which the host <hostname> sees this network location. It should be in the syntax that is returned by the "getcwd(3)" system call. If the path contains whitespace characters, then it must be enclosed in double quotes, such as "<localpath>".

__include__

This literal entry starts a special record, which gets replaced by the contents of another host file as referenced. It is recommended to use a fully qualified path for the spefification of that file. Relative path names will be interpreted as being relative to either the directory where Rayfront was started, or the current project directory, either of which may give unexpected results.

The purpose of this record is to make configuration of larger networks more convenient. Typically, there will be one central hosts file in a network (most likely with the rayserver installation), that is visible to and included by all local Rayfront installations. This helps to make sure that each installation always sees configuration changes immediately, whithout the need to load Rayfront over the network, as working with a local installation is much faster.

__library__

This literal entry starts a special record, which specifies the location of the system library. If there is no such entry, then the standard location within the current installation is assumed. If there is one argument with a absolute path to an existing directory, then Rayfront will assume that the system library is located there. If the first argument is a relative path, then a second argument is required with a pathname. The pathname must be defined elsewhere in the file (or an included/parent file), and defines the root for the relative path of the first argument.

Specifying a relative path is especially useful if the entry is located in an included file that can be seen by several hosts on the local network, each of which may access the library directory through a different physical path. The pathname used will then resolve those differences for each system. If the relative or the absolute path contains any whitespace characters, then it must be enclosed in double quotes.

There may be several <pathname>="<path>" pairs, or none, which disables remote simulation. If a record doesn't fit well on a single line, it may be wrapped to following lines, and the continuation line must start with one ore several tabs. Comments start with a "#" and go to the end of the line. Lines containing only whitespace are ignored.

Examples

In the directory rayfront/config, there is a file named hosts.dst, wich can be used as an example and copied to hosts in the same place. The following is an excerpt from that example file:

  # This will be the standard case.
  #
  somehost 1 path1=/home path2=/export/home2 example="/export/some place"


  # This is a high end multi cpu server (wish I had one ;).
  # The filesystem is organized differently here.
  #
  otherhost 4
      path1=/home
      path2=/nfs/somehost/home2
      example="/nfs/somehost/some place"


  # An example of a host running WindowsNT.
  # Both drive based and UNC paths are valid.
  #
  nt-host 1
      path1=h:\
      path2=\\somehost\home2 
      example="\\somehost\some place"

Notice:
On Windows, you can use both drive letter based paths like "F:\some\directory" and UNC paths like "\\<host>\some\directory". However, changing an existing configuration later from one path format to the other may cause confusion under certain circumstances.

Navigation: