Networking configuration

Networking can be done in different ways: UDP multicast and TCP unicast with or without automatic host discovery are supported.

You can decide how to use the networking capabilities in your application. You can realize a conventional master/slave configuration similar to mental ray with satellites where all scene editing and rendering always initiates from the same host. In that scenario you would typically write a small stub application which does the configuration and starts the system and then waits until shutdown is requested. In the background the neuray system would handle reception of data and would accept requests to do work and handle them.

But you are not restricted to this scenario with neuray. The neuray library allows all hosts to edit the database and initiate rendering. You can use this to implement peer-to-peer applications. It is up to your application to avoid conflicting changes in this scenario. To help doing that the Iray API provides means for synchronizing changes to database objects for example by locking objects.

UDP Multicast Networking: Using UDP multicast gives the best performance because data can be sent once on a host but be received by many hosts in parallel. Additionally there is no need to configure a host list so it is very easy to dynamically add and remove hosts. On the downside using UDP multicast for high bandwidth transmissions is not supported by all network switches and might require changes to the network infrastructure. For the UDP multicast case a multicast address, a network interface and a port can be configured. A host list is optional and acts as a filter which restricts the hosts which can join to the given list.

Hosts can be started dynamically and will automatically join without the need for configuration. A callback object can be given to the neuray system which will be called when hosts have been added to the network or when hosts have left the network.

TCP/IP Networking: Because multicasting with high bandwidth is not supported on all networks it is also possible to use a more conventional scheme using TCP/IP networking, which is supported on virtually all networks. In that case an address and port to listen on can be configured. A host list is mandatory if the discovery mechanism is not used. Hosts can still be added to and removed from the host list at any time using the Iray API provided that the necessary redundancy level can be maintained (see below).

TCP/IP networking can be coupled with a host discovery mechanism, in which case an additional address needs to be given. In case of a multicase address, multicast will only be used to discover other hosts dynamically. In case of a unicast address, the host with the given address acts as master during the discovery phase. In both cases, the actual data transmission will be done using TCP/IP. Because this mode requires only low bandwidth multicasting it is supported by most networks and can be used to simplify the configuration even if high bandwidth multicast is not supported. Again a callback object can be given by the application to allow the application to keep track of added and leaving hosts.

Failure Recovery: A redundancy level can be configured up to a certain maximum. The redundancy level configures how many copies of a certain database object will be kept at least on the network. The neuray database guarantees that the system will continue working without data loss even when hosts fail if the following preconditions are met: The number of hosts failing at the same time must be less than the configured redundancy level and at least one host must survive. After host failures or administrative removal of hosts the database will also reestablish the redundancy level if the number of surviving hosts is high enough.

Dynamic Scheduling Configuration changes: A neuray instance in a multi-hosted system can dynamically be configured to stop delegating rendering work to other hosts, to stop accepting rendering work delegation from other hosts, or to exclude the local hosts from rendering completely. This can be used to adapt the load on systems to the current usage scenario.

Administrative HTTP Server: The neuray system has a built-in administrative HTTP server which can be started. This server is not identical to the HTTP server framework which can be used to serve requests from customers. The administrative HTTP server does not allow the execution of C++ code or the rendering of images. It is meant to be used to monitor the system at runtime. You can configure if this server is started (by default it is not started) and on which port and interface it listens. The administrative HTTP server allows one to inspect aspects of the neuray database and thus is useful for debugging integrations. Usually it would not be enabled in customer builds.