Cluster Synchronization

	Cluster Task	Waits for all Cluster Machines to trigger the Input Method and only then fires its Event.
	Cluster Data	Sends values or events from the Cluster's master machine to all clients. These will be applied/fired in the same frame.

General

If working with Ventuz Designer the Cluster nodes will operate in a 'stand-alone' mode if the RenderSetup mode is set to Cluster or Design Preview. In these modes the nodes will always function to simulate a correctly working multi-machine Cluster. If switched to Production Preview the nodes operate like in Ventuz Runtime and are dependent on the communication with the other machines in the Cluster.

The communication between the Cluster nodes works only if all machines in a Cluster have loaded the same scene! Sender and receiver nodes find each other via an internal node ID. This means that replacing a Cluster node in a scene only on one machine by a new node would break the communication because the new node has a different ID.

Cluster Task

The Cluster Task node is meant to synchronize events within a multi-machine Cluster. This is especially useful if you work with tasks that need different time to finish per machine. The synchronization of events can be parametrized by two properties: the Timeout property specifies the time-frame (in seconds) in which the LocalFinished method on all associated Cluster Task nodes in the Cluster has to be triggered. If the timeout is not exceeded the ClusterFinished event is fired synchronously on all machines. Accordingly the ClusterTimeout event is fired if one or more machines did not trigger the LocalFinished method within the timeout duration. The Delay specifies the number of frame that are available to fire the ClusterFinished or ClusterTimeout event after the determination of success or fail.

On the basis of the following diagram the internal mechanisms of the Cluster Task node will be explained:

The diagram represents a Ventuz Cluster of 4 machines. The Timing and Input master (specified in the Ventuz Config) is represented by Master. All machines have loaded the same scene with at least one Cluster Task node in it. The properties of the nodes are set to 0.25 seconds for Timeout (represents 15 frames in a 60 Hz rendering) and 5 frames for Delay. Let's assume that a certain node logic triggers the LocalFinished method on each machine in a different frame. The first method is triggered on Client1 in frame 1001 and a request message to fire ClusterFinished is send to the master machine. The same happens on the Master and Client3 machines in frame 1002 and on Client2 in frame 1004. The first request message starts the master timeout countdown. This means that all request messages must arrive at the master machine until frame 1016. If we assume that a message takes up to two frames to arrive at a target machine, the last request message arrives in frame 1006 at master machine. Hence all messages arrived within the timeout time-frame. In this case the master will send a positive response to all machines in the Cluster in frame 1007. As the Delay is set to 5 frames the response message defines that the ClusterFinished event has to be fired in frame 1012 on all machines. If at least one machine does not send any request message or the message arrives too late, the master sends a timeout response to all machines; the delay mechanism applies here, too!

A good example for the necessity of the Cluster Task is the asynchronous loading and presenting of images on a video-wall driven by a Ventuz Cluster. To load images without stalling the rendering you have to use the Texture Loader in Async mode. But the load duration for the same image on different machines will always be slightly different and the image would be most likely presented in different frames per machines. To prevent this asynchronous image presentation one can use the Cluster Task node to synchronize the Loaded event of the Texture Loader node: only when all machines have successfully loaded the image it should be presented in a specific frame.

The scene logic could look like follows:

The Mover (which is synchronized via Cluster Clock) triggers the load of a new image and starts the fade out of the image currently displayed. The Loaded event of the async. Texture Loader is bound to the LocalFinished method of the Cluster Task node. If all Texture Loader have fired the Loaded event within the Timeout duration specified on the Cluster Task node, the node fires the ClusterFinished event on all machines in the same frame. If not all LocalFinished methods have been triggered within the timeout, the ClusterTimeout event is fired.

Cluster Data

The Cluster Data node was build to send values of type float, double, integer, boolean and string to all machines in a Ventuz Cluster and provide them in the same specific frame on all machines. Additionally an arbitrary number of events can by fired synchronously in the Cluster. Via the Custom Model Dialog (at the bottom of the Property Editor) pairs of Input and Output properties and pairs of Methods and Events can be added to the node. These pairs define which values and events should be send from the master to the client machines. Basically the node provides the SendOnChange property which specifies whether values should be automatically send when they have changed or manually on triggering the Send method. The Delay property specifies how many frames in the future the values should be applied after sending them. Note that triggering Send will only transfer the custom property values but not the events; these have to be triggered separately. If a Cluster Data node has received and applied values the Received event is fired.

In contrast to the Cluster Task node the Cluster Data only requires a unidirectional communication:

The Master just commands values and events and the clients have to apply them in the specified frame. In the example above the master sends values in frame 1001. Due to the Delay of 5 frames the values have to be applied in frame 1006.

An use case for the Cluster Data node would be the propagation of values from a Script node which can only run on a single machine (e.g. due hardware limitation). In a single machine setup the Script node would be directly bound to the Axis node. But in a multi-machine Cluster these values must be available on all machines in the same frame. On a master machine (machine with the lowest ID) the Cluster Date node acts as sender and receiver. On all client machines the node only acts as receiver.