Barrier: Data Transport Mechanisms

Visualization can generally be characterized as a data processing pipeline. In the 
context of an RDV framework, each of the individual components accepts data as 
input, performs some processing, and then sends its results to the next component 
in the processing chain. When all components exist on the same machine, data transport 
between components is straightforward to address through use of shared memory 
segments, and so forth. When the components exist on different machines separated 
by WANs, then efficient transport of data between components becomes a task that has 
significant impact upon the overall performance and usability of the system.

Familiar methods for data transfer between machines are completely inadequate for use 
in the context of RDV frameworks. Ftp, and its cousins such as GridFTP, pftp, and so 
forth, are oriented towards movement of files. In contrast, components in an RDV 
pipeline will need to move a diverse range of data objects, including combinations 
of structured and unstructured data, as well as geometry primitives.

Beyond the serialization, or "wire-encoding" of visualization objects for transmission 
between sender and receiver, two additional issues merit attention. The first is the 
efficient use of network bandwidth. The other is the potential need for communication 
patterns beyond peer-to-peer.

The Transmission Control Protocol (TCP) has formed the backbone of IP-based communication 
for many years. Unfortunately, it is well-accepted that TCP is entirely inadequate for 
use on high-bandwidth networks. RDV should leverage emerging efforts for data transmission 
that use alternate custom protocols in order to realize efficient use of bandwidth. 
LBNL's Visapult is a good example of a custom implementation that uses rate-regulated 
flows with custom UDP protocols. More general-purpose implementations that merit study 
for general purpose use include RIPP (an emerging protocol from LBL), and SABUL 
(http://www.dataspaceweb.net/sabul.htm).

Multicast protocols have often been viewed as the solution for the many-to-many 
communication transport method. Unfortunately, multicast firmware in backbone routers 
is not uniform in its reliability. Anyone who has used the Access Grid can attest to 
problems that stem from multicast. A logical approach to pursue in the collaborative 
visualization arena would include a communiction layer that supports multiple 
sender/multiple consumer data encoding. In one instance, such a layer would use a 
non-multicast protocol. Later, when multicast implementations are uniform and 
reliable, it can be used in native fashion. An additional benefit of the brokerage 
layer is to support dynamic setup and teardown of multiparticipant sessions, as well 
as to provide direct support that meets the needs of remote and distributed visualization.