Introduction to the Collaboration Modules

Any user data read into an AVS 5 network, regardless of type, is converted to one of seven internal AVS data types. These seven types include: single integer and floating point values, character string, colormap (color tables), field (multi-vector, multi-dimensional arrays), geometry (polygon objects and transformations), and unstructured cell data (UCD). A Share module has been developed to allow collaborative sharing of each data type, and associated parameter values.

This figure shows the control panel common to all Share modules. The server host and server port widgets specify the location of the collaboration server. Prior to starting a collaborative session, all participants must agree on which of their hosts will run Share server(s). A separate server is created for each Share module in a given AVS network, and the respective Share modules in the AVS networks of the other participants attach to the same server as shown.

A participant who's computer will be hosting a server is assumed to be responsible for that server. The server will automatically be run after they enter their hostname into the server host widget, and a port number into the server port widget. Note that the individual responsible for a given server must initiate that server before other participants will be able to use it. A server will automatically terminate after all participants have quit.

The remaining widgets control the type of information that the Share module will send (and expect to receive). With send data selected, the data moving through the AVS network at the point at which the Share module is inserted, will be rebroadcast to all participants. Note that in this configuration, not all participants must send data. As Example 2 shows, some participants may choose to receive data only.

With send parms selected, the values of the parameters in the control panel belonging to the module immediately upstream of the Share module, will be rebroadcast to all participants. Note that in this configuration, all participants MUST have the same module directly upstream of the respective Share module in their AVS networks. The figure below shows two participants sharing control over the isolevel widget in an Isosurface module. Note that the server isn't shown for the sake of clarity.

The Sharing Visualization Data vs. Parameter Values section details which type of information is best sent in which environments.

Constructing a Collaborative Session

The process involved in constructing a collaborative AVS session can be thought of as inserting one or more Share modules into a pre-existing AVS network, setting the server host and port values, and selecting the type of information to share. Consult the Sharing Visualization Data vs. Parameter Values section below concerning where to insert Share modules in a given AVS network. Here we detail two examples of how the Share modules might be used to accomplish two types of shared visualization tasks.

Example 1

In this example two collaborators have loaded identical copies of an AVS network. The collaborators don't want to share the actual isosurface geometry (since both networks are capable of generating the isosurface it doesn't make sense to transfer this potentially large entity across the network) rather they want to share control over the isolevel parameter in the Isosurface module. In this configuration, the send data button is deselected and the send parms button is selected in the Share Geometry module. Thus the Share Geometry module shares the values of the parameters in the module directly upstream (the Isosurface module in this case) with the other Share Geometry modules across the network using the same server host and port number. The AVS connection between the Isosurface module and the Share Geometry module in each network is used only for signaling the Share Geometry module that the value of an isosurface parameter has changed.

Example 2

In this example two collaborators are visualizing identical copies of a dataset using similar AVS networks. The two collaborators however have agreed to put A in charge of coloring the mesh (perhaps A is an expert at highlighting some desirable feature of this dataset). In the Share Colormap module for A in the above network the send data button is selected and the send parms button is deselected (collaborator A isn't sharing the values of the generate colormap parameters but rather the actual colormap data). Note that the AVS network for collaborator B does not contain a Generate Colormap module. Coloring information is introduced into this network from the Share Colormap module only.

Sharing Visualization Data vs. Parameter Values

As shown previously, the send data and send parms buttons allows you to select the type of visualization information you wish to share with colleagues. The decision to share visualization data versus visualization parameter values should be made based on the available network bandwidth, data locality, and access considerations.

In the case of network bandwidth, consider that sending the values of the parameters which control how a dataset will be visualized often requires less bandwidth than sending the data itself. This is particularly true in the case of AVS, in which a dataset may need to be sent each time it is modified by an upstream module. Thus as a general rule, set the send parms button. Note that in a very few cases, control over a particular parameter cannot be shared. This is because certain parameter settings (primarily those in the Geometry Viewer module menu) are not accessible to the Share modules, due to the design of AVS itself.

In the case of data locality, consider that environments may exist in which not all participants have local copies of a particular dataset, or a dataset may be generated "on-the-fly" during an intermediate step in the visualization process. In such situations, set the send data button.

In the case of access, consider that the Share modules allow you to share only the data and parameter values you want to share. You control which items will be shared by inserting Share modules at appropriate locations within your AVS network. Such privacy considerations may dictate an appropriate setting for the send data and send parms buttons.

Synchronization

A key issue in conducting an effective collaborative session involves the notion of the current state (current value) of the shared data or parameter values. In a nutshell, it is important that all participants see the same values of the shared items at all times.

The server maintains the current state of the shared item by keeping track of the most recent message broadcast to a given set of participating Share modules (clients). Each time a new client attaches to a server, the server initializes the client to the current state thereby maintaining the coherency of the shared data or parameter values at initialization time. To maintain coherency at run time, a server rebroadcasts every message to all clients including the sender, and clients do not process locally derived changes in data or parameters until they are echoed back from the server.

Platform Independent Data Representation

Every effort has been made to make the Share modules operate successfully on and between any platform for which AVS 5 is available. Users should be able to share data and parameters across two or more potentially different platforms. Data representation dependencies such as byte ordering and type size are avoided through the use of Sun's eXternal Data Representation (XDR) library. This is the same library used by AVS itself to avoid dependencies when transferring data between remote modules. Prior to sending data to a collaboration server, a Share module encodes the data elements either as ASCII strings (in the case of the simple AVS data types) or as XDR byte streams (in the case of the complex AVS data types). All participating Share modules then decode the byte stream immediately on receipt from the server.