The ClusterManager(Figure 2.1, “Class Diagram: ClusterManager”) is one of the only two static components of ClusterJuggler. It acts as a facade for the entire ClusterJuggler sub-system. It is responsible for maintaining a list of all current plugins, configuring all sub layers, calling the plugins to perform their specific tasks, and syncronizing the kernel loop between machines.

Dynamic Plugin Registration. When a plugin is dynamically loading it automatically registers itself with the ClusterManger where it is thrown into a list of plugins for later use. This list is the only way that ClusterJuggler knows about the plugins. This means that that there is absolutely no way to access these plugins unless you go through the ClusterManager's API and this list.

Run Time Re-Configuration. VR Juggler's architeture has the amazing ability to reconfigure itself while it is running. This is a complex task of run time reconfiguration is difficult when running on one machine let alone across a cluster. The ClusterManager is resoponsible for making this all happen behind the sceens.

Figure 2.1. Class Diagram: ClusterManager

Note

VR Juggler is continually running through a loop of method calls that receive information from external devices, calculates application data, and draws the users perspective called the kernel loop.

Figure 2.2. VR Juggler Kernel Loop

Plugin Method Calls. Within the VR Juggler kernel loop (Figure 2.2, “VR Juggler Kernel Loop”)there are many different locations that we might need to send information across the network in order to fully synchronize the cluster. For example, application data needs to be shared directly before the draw function because this data needs to be identical across the cluster right before we draw the scene. But, on the other hand input data needs to be shared at the beginning of the loop so that preFrame() can use this data to calculate the state of the scene such as the navigation matrix. In order to accommodate all possible needs of a plug in, there are calls into the ClusterManager at numerous locations during the kernel loop. The Cluster Manager is then responsible for calling any plugin that needs to use the network to transfer data.

Frame Synchronization. In order to guarantee that one node does not progress further through the kernel loop than the other nodes the ClusterManager must provide a level of synchronization on every method call from the kernel loop. This is accomplished by requiring the ClusterManager to receive all data packets. Each plugin is only responsible for sending packets to other cluster nodes. Once all plugins have sent their data, the ClusterManager sends an END_BLOCK packet telling the remote nodes that it is done sending information and then reads data from the network until it receives an END_BLOCK from all other nodes. The syncronization occurs because each node must indicate to all other nodes that it has completed the current frame(Figure 2.3, “Frame Syncronization”).

Figure 2.3. Frame Syncronization