CAVERNsoft is the common collaborative software architecture for CAVERN. CAVERNsoft uses light-weight distributed data-stores as the mechanism for managing a wide range of data volumes (from a few bytes to several terrabytes) that are typically needed for sustaining persistence in virtual environments. Multiple networking interfaces support customizable- latency, data consistency, and scalability that is needed to support a broad spectrum of networking requirements.
This paper begins by describing a number of collaborative virtual reality scenarios developed by our laboratory as well as our collaborators, with the goal of identifying the key issues of networking and database management that are unique to collaborative virtual reality. From these the CAVERNsoft architecture is presented including a report on the current status of CAVERNsoft's development.
Keywords: Scalable Persistence Collaborative Virtual Reality
Naturally CVR poses new challenges to traditional areas of networking and databases as well. A Collaborative Virtual Environment (CVE) requires an unconventionally broad range of networking, database and graphics capabilities. This vast range makes the rapid construction of complex CVEs difficult. Current attempts at building networking and database architectures for CVEs have resulted in ad-hoc solutions that are specifically designed to solve a small range of problems. These ad-hoc solutions typically use only a single protocol for data transmission- either reliable or unreliable but rarely both. There is no uniform means (network and database) for interoperability between virtual environments and non-virtual environments (e.g. Java-based desktop workstations.) There is little middleware to provide higher-level services for collaborative VR (avatars, audio/video teleconferencing, database) that can allow developers to ``jump-start'' the construction of a collaborative environment.
CAVERNsoft is a software architecture for supporting CVR that attempts to be cognizant of these diverse human-factors, networking and database issues. Its main goal is to explore the problem of supporting persistent CVEs for collaborative, education, and scientific and engineering visualizations that involve supercomputers as well as massive data stores.
In this paper we will describe a number of scenarios that have helped motivate the design of CAVERNsoft by identifying a number of key issues that a software architecture for CVR must support. We will then propose an architecture for CAVERNsoft and conclude by describing its progress at the present time.
One constraint this paper attempts to impose on the set of scenarios, is that they involve tasks that would benefit from a solution in CVR over simply non-collaborative VR or 3D workstation computer graphics. For example, simple audio/video teleconferencing alone is not considered a scenario that can significantly benefit from the use of CVR. However collaborative work that depends on the spatial qualities of VR (such as collaborative architectural design) in addition to teleconferencing as part of its solution (teleimmersion) is considered a good candidate for a CVR solution.
The National Computational Science Alliance (NCSA) has been working with Caterpillar Belgium S.A., to develop a system to allow remotely located engineers to work together on vehicle design review and redesign[Lehner and DeFanti, 1997]. Remote collaboration is necessary here because the eventual system will be used by Caterpillar engineers in the U.S. and Europe who must jointly design Caterpillar vehicles so that they meet customer demands and safety requirements for both markets. For example, European safety standards require a roading fender to be added to the basic vehicle design. The collaborative VR system allows engineers to evaluate rearward visibility from a viewpoint in the virtual cab of the vehicle. Virtual co-presence allows one designer to manipulate the fender while another designer watches for its effect on visibility.
To support user-to-user communication, publicly available audio and video teleconferencing tools (vat and nv respectively) were modified to work with the CAVE virtual environment[Cruz-Neira et al., 1993]. Video images from each participant were texture-mapped onto the surface of a rectangular box to establish their presence in the environment. The 3D models of the Caterpillar vehicles that are used in the collaboration are first duplicated at every site. Then an unreliable multicast data stream is used to distribute information about the participants and changes in the models to all the other participants.
As SIMNET was designed primarily for military simulation, its underlying unit of data transmission (called a Protocol Data Unit- PDU for short) specifically contains encodings for military entities (such as tanks and airplanes.) DIS (Distributed Interactive Simulation) is a newer and more ambitious simulation standard (IEEE 1278) that is based on SIMNET but allows for greater complexity and realism. For example: SIMNET uses a flat terrain whereas DIS accounts for the curvature of the Earth. SIMNET is oriented towards terrain and the sky above it whereas DIS encompasses all areas of potential military activity including below the ocean and in space.
Argonne National Laboratory (ANL) in collaboration with Nalco Fuel Tech have built an immersive interactive engineering tool for designing pollution control systems for commercial boilers and incinerators[Freitag et al., 1995]. Using ANL's CAVEcomm library multiple CAVEs could synchronously connect with an IBM SP supercomputer to steer the interactive simulation of flue gas flow in the boiler. Control of the simulation was strictly via turn-taking. One participant could initiate the flow from one viewing location while another participant could simultaneously view the flow in a different chamber of the boiler. Participants could communicate with one another via a conference telephone call.
As with most CVR applications, this system is only in a prototypical phase. Additional capabilities that may be useful in enhancing work in the environment include:
CALVIN [Leigh et al., 1996a, Leigh et al., 1996b, Leigh and Johnson, 1996] is a CVE that allows multiple users to synchronously and asynchronously experiment with architectural room layout designs in the CAVE (Figure 1.)
Participants are able to move, rotate, and scale architectural design pieces such as walls and furniture. Participants may work as either ``mortals'' who see the world life-sized (classically known as an ``inside-out'' view), or as ``deities'' (``outside-in'' view) who see the world as if it were a miniature model. Deities by virtue of their enlarged size relative to the environment, tend to tower above the scene and are better at performing gross manipulations on objects. Mortals on the otherhand are at the same scale as the environment, and are hence better able to perform fine manipulations.
Asynchronous access allows designers to enter the space whenever inspiration strikes them, rather than requiring them to wait to schedule formal meetings, which can be particularly difficult if the participants are located at opposite parts of the world with significant timezone differences. In fact CALVIN already provides interfaces for bilingual (Japanese and English) interaction.
Participants are able to save versions of the design as the collaboration progresses. When participants re-enter the environment at a later time, the most recently saved version is automatically loaded. If on the otherhand the participant re-loads a different version of the design, CALVIN will record successive designs as a new branch in the version tree.
CALVIN employees a shared variable model of a distributed shared memory (DSM) system to eliminate the need of the programmers to develop specific protocols for network communication. The DSM itself uses a reliable protocol and a centralized sequencer to guarantee consistency in all clients. C++ classes representing networked versions of floats, integers and character arrays are provided so that assignment to variable instantiations of these classes automatically shares the information with all the remote clients.
These networked variables are used to send data such as the state of objects in the world and user-tracker information. Tracker information is sent so that avatars can be drawn in the place of participants in the virtual scenes. Position as well as orientation data from the user's hand and head are transmitted so that fundamental gestures such as nodding, pointing, and waving can be communicated through the avatars.
Although the task of world synchronization is greatly simplified by the centralized sequencer, the transmission of tracker information over such a reliable channel can introduce latencies- especially when synchronizing between the participant's real location and their avatar's location. This is acceptable for small relatively closely located working groups where the network traffic and latency is relatively low but is unsuitable for larger and more distant groups of participants dispersed over the internet. In fact, to transmit audio/video signals between sites, the shared memory system is bypassed with point-to-point raw ATM streams which are able to support teleconferencing at NTSC resolution and at 30 frames per second.
Finally, in CALVIN when two or more participants simultaneously modify an object, a ``tug-of-war'' occurs where the object appears to jump back and forth between two positions, eventually remaining at the position given to it by the last person holding onto it. This problem can be alleviated by using a locking scheme, but this was intentionally not done. In VR, where emphasis is placed on natural interaction, it would be unnatural if the user had to lock an object before picking it up. The presence of avatars in combination with audio communication (the most important of the communication channels to provide) compensated for the lack of strict floor control and database locking. For example, the declaration: ``I'm going to move this chair'' combined with the visual cue of an avatar standing next to a chair and pointing at it, alerts other users that this user is about to grab that chair.
CALVIN's centralized topology and distributed shared memory implementation informed us on the potential and usefulness of this architecture for supporting CVR. Our next goal was to investigate the issues involved in developing CVEs that use highly distributed techniques. These investigations are embodied in the architecture developed for the NICE project.
The NICE group is building a collaborative environment in the form of a virtual island for young children (approximately 6-8 years of age)[Roussos et al., 1996, Roussos et al., 1997]. In the center of this island the children can tend a virtual garden. The children, represented by avatars, collaboratively plant, grow, and pick vegetables and flowers. They ensure that the plants have sufficient water, sunlight, and space to grow, and need to keep a look out for hungry animals which may sneak in and eat the plants. The children can shrink down to the size of a mouse and crawl under the garden to see the root system, and can talk with the other remotely located children or other characters in the scene. The children are able to modify the parameters of this small ecosystem to see how it affects the health of the garden (Figure 2.)
NICE's architecture is based on the techniques derived from CALVIN in that a central server is used to maintain consistency across all the participating virtual environments. Whereas CALVIN solely used a reliable connection to synchronize state information, NICE used an unreliable protocol (either multicasting or UDP) to share avatar information from magnetic trackers, and a reliable socket connection to share world state information and to dynamically download models from WWW servers using the HTTP 1.0 protocol.
Both multicasting and UDP were provided to deliver tracker data, as it was not always possible to acquire the administrative privileges to conveniently erect multicast tunnels between distant remote sites. Hence a number of interconnected NICE ``smart-repeaters'' were deployed at various remote sites that allowed the use of multicasting amongst clients at localized sites but UDP for repeating packets between remote locations. In addition, to prevent faster clients from overwhelming slower clients with data, the smart-repeaters performed dynamic filtering of data based on the throughput capabilities of the clients. Using this scheme we have participants running on high speed networks have been able to collaborate with participants running on slower 33Kbps modem lines.
NICE's virtual environment is persistent. That is, even when all the participants have left the environment and the virtual display devices have been switched off, the environment continues to evolve; the plants in the garden keep growing and the autonomous creatures that inhabit the island remain active.
Interactions with the NICE garden are not limited to users with VR hardware. The garden in NICE can be experienced either by entering VR, a basic WWW browser (http://www.ice.eecs.uic.edu/~nice), a VRML2 browser, or in a Java applet. Participants using a mouse can interact with participants using VR hardware where the desktop user's mouse position is used to position an avatar in the 3D virtual world, and the bodies of the VR users are used to position 2D icons on the desktop screen. This kind of scalability will be important for increasing the breadth of possible collaborations.
The elaborateness of the avatar should vary with the task being performed. Hence it is important to identify the minimum elements of representation needed to afford recognizability and to convey non-verbal information such as body language and gesture. In our experience we have found a minimum of head position and orientation, body direction, and hand position and orientation to be adequate for many CVR tasks. To afford recognizability, we have found it easier to distinguish avatars based on geometry rather than color. Hence the commonly used, homogeneously shaped avatars with varying colors and overlayed name tags, do not make good avatars.
To support the minimal avatar, a bandwidth of approximately 12Kbits/sec (at 30 frames per second) is needed. Theoretically this implies that 10 avatars can be supported over a 128Kbits/sec ISDN connection. In practice however, our experiments have shown that it is able to support a maximum of four avatars with an average latency of 60ms using UDP as the transmission protocol. Although this is not a scalable solution, it is a cost effective means of transmitting VR avatar data with the quality of service of a dedicated connection.
Unreliable protocols are suitable for the transmission of tracker data because: 1. the loss of a packet of tracker data is usually followed shortly afterwards by newer ones, and 2. unreliable protocols have a lower latency and utilize lower bandwidth than reliable protocols.
Multicasting has the additional benefit that clients that subscribe to a multicast group need only send one message to the group, rather than having to send the same message individually to each participant in the collaboration. The multicast protocol will automatically propagate the single message to all the other subscribers. The main disadvantage however is that multicast is based on unreliable UDP. Work however, is currently underway in developing reliable multicast protocols [Lin and Paul, 1996]. Reliable transmission is important in CVR for the delivery of accurate state information as well as models and scientific data sets. Here the loss of a packet could produce an unwanted artifact in the visualization that is not representative of the original data set.
A flexible solution to networking for CVR should include both reliable and unreliable forms of transmission. However it is interesting to note that only a few provide both capabilities simultaneously[Mandeville et al., 1995, Roussos et al., 1996]. This is perhaps due to the following reasons three reasons: First, the main concentration of VR libraries in the past has been in providing tools to allow programmers to quickly build interactive non-collaborative VR environments (e.g MRToolkit[Shaw and Green, 1993]). Support for collaboration was generally an after-thought and hence reliable TCP is used as the default, safe and generic solution. Secondly, most CVR implementations are still experimental technologies undergoing significant change. For example DIVE[Carlsson and Hagsand, 1993] initially used a transaction-oriented, object-oriented database called ISIS and a reliable TCP connection to synchronize all state information in the CVE. They are now using a peer-to-peer connection with a replicated database that synchronizes data via a reliable multicast connection. Finally, the implementations may be highly customized for specific problem domains. For example NPSNET[Macedonia and Zyda, 1995] uses multicasting to deliver information for military simulations. Other researchers have attempted to extend the underlying DIS protocol to allow the delivery of ``non-ballistic'' information. But because it uses an unreliable protocol additional mechanisms for retransmitting packets had to be devised. In addition, since the notion of military weapons are directly embedded in the specification of the protocol it does not serve as a generic protocol for non-military simulations such as collaborative engineering or scientific visualization.
Transient data are data that are not stored in a database. An example of this kind of data are command messages that might be sent between clients to effect events or audio/video data streams. An exception to this definition is when transient data is stored in a database to allow re-play of events at a later time. In this case the data is more accurately characterized as persistent rather than transient.
It is our belief that data scalability is of greater importance to the development of engineering and scientific applications than connection scalability. Data sets in these problem domains are typically enormous in size however the number of people simultaneously collaborating is unlikely to exceed 6 or 7.
The three main classes of distributed topologies used in CVR include: replicated homogeneous, shared centralized, and shared distributed[Macedonia and Zyda, 1995]. These are described below.
In a scientific visualization environment that involves simulations that are running on supercomputers a recording should include either the entire state of the virtual environment as well as the state and output of the simulation, or the state of the virtual environment and only the geometric representation of the simulation. The advantage of the latter is that it simplifies the mechanism for re-play. Re-play will only require a rendering of the geometry which can easily be encapsulated to work even in external viewers such as VRML2 browsers. However the disadvantage is that the geometry data itself cannot be re-used to further query the output of the simulation.
On the otherhand the advantage of saving the state of the environment and the simulation is that during re-play the participant can choose to dynamically re-involve the supercomputer. This is motivated by the following:
To ensure accuracy in computational science simulations, the simulation steps are kept relatively small. However the computed results are collected at every n time steps due to, surprisingly, disk space limitations (the output can occupy between several hundred megabytes to many gigabytes)[Roy and Cruz-Neira, 1995]. If by viewing the results a feature of interest is found, the scientist would normally re-execute the simulation from the beginning but only begin recording the output in the region of the feature and at each time step rather than at every n time steps. In this scenario persistence may be used to offer some assistance in reducing the amount of re-computation time. State Persistence may be invoked during the initial course-grained recording where, instead of simply recording the output, the states of the computation are also recorded. When the region of interest has been isolated, rather than returning computation to the beginning as is typical, the state of the computation can be retrieved from the persistent database and computation can be resumed from that point. Recording can then resume at a finer granularity.
In general, as part of the recording of persistent experiences it may be useful to also record the actions of the avatars so that on re-play they may be re-positioned in the scene to serve as reminders of which particular area of the visualization was being observed or manipulated at the time of the recording. In fact it may actually seem rather unnatural to watch an event transpire without being able to see the effector of the event. One could also imagine that the re-play procedure may also be recursively recorded so that a participant could observe him/herself observing him/herself. It is not entirely clear if this capability is of any value but the idea is at least somewhat intriguing.
Although this may seem to be an extravagant use of computing power, it is anticipated that in future generations of CVR environments the notion of persistence is merely an extension of the existing idea of the operating system or the WWW server. These are essentially, already continuously persistent environments.
CAVERNsoft is the collaborative VR middleware to facilitate the construction of persistent CVEs within CAVERN. CAVERNsoft uses light-weight distributed data-stores as the mechanism for managing a wide range of data volumes (from a few bytes to several terrabytes) that are typically needed for sustaining persistence in virtual environments. Multiple networking interfaces support customizable- latency, data consistency, and scalability that is needed to support a broad spectrum of networking requirements. Although CAVERNsoft is being developed to support the CAVERN partnership, it is not a CAVE/ImmersaDesk-specific library. Only the higher level template layers (described below) of CAVERNsoft are VR-platform specific. The underlying capabilities of CAVERNsoft are designed to work on heterogeneous computing facilities (such as workstations, supercomputers, desktop PCs) that are not VR specific. It was conceived to create a common software middleware with which heterogeneous applications may communicate with VR applications.
A client application is built by using an IRB interface (IRBi) which, on invocation, will spawn the client's ``personal'' IRB. This IRB is used to cache data retrieved from other IRBs during the operation of the client. An application-specific server is similarly built using the IRBi. Hence there is little differentiation between a client and a server (Figure 3.) Using the IRBi a client can arbitrarily form a connection, after having acquired the proper permissions, with any other client or server to access its resources. The IRBi will communicate the request to the client's personal IRB which will then communicate with the remote client's or server's IRB. It is the IRBs' responsibility to negotiate the networking and database services requested by the client/server applications. This form of flexibility and symmetry will allow all of the main CVR topologies to be quickly constructed (Figures 4.) Figure 4a. shows IRB-based clients with possibly fully replicated databases (as in NPSNET) sharing updates via a multicast group. Figure 4b. shows the use of IRBs in a shared, centralized database. Figure 4c. shows IRB-based clients in a fully connected configuration to support a shared, distributed database with peer-to-peer updates. Finally Figure 4d. shows IRB-based clients and servers that are connected to form a shared, distributed client-server database. The clients may arbitrarily connect to any of the servers using any desired communications protocol to retrieve information. Since there is no distinction between a client or a server, an IRB-based program may be a client running on a supercomputer, or a server interfacing with a large database of scientific data.
The mechanisms for facilitating the IRB's capabilities will be described in greater detail in the following sections.
A client's handle to their personal IRB is used to activate dynamic connections with remote IRBs. A client wishing to share information between its personal IRB and a remote IRB begins by first creating a communication channel and declaring its communication properties. Then any number of local and remote keys may be linked over the channel. A key is a handle to a storage location in an IRB's database. The database is used to cache data received from remote keys. Keys are uniquely identified across all IRBs and can be hierarchically organized much like a UNIX directory structure. Each local key may be linked to only one remote key. This is the link explicitly invoked by the user to share information with a remote IRB. However each local key can accept multiple linkages from other remote subscribing keys. The user is generally made unaware of these additional linkages as the personal IRB transparently manages data sharing with the remote subscribers. Any modifications that are made to one key will automatically be propagated to all the other linked keys.
In addition to connection reliability clients may specify Quality of Service (QoS) requirements. Hence they are able to declare the desired bandwidth, latency, and jitter of the data stream. The personal IRB will attempt to obtain the desired level of QoS from the remote IRB, but if it fails, the client may at any time negotiate for a lower QoS. As in RSVP[Zhang et al., 1993] client-initiated QoS is used so that the client can specify the amount of data it can handle from the remote IRB.
In most CVR applications, world state information consisting of a few tens of bytes are actively distributed. That is, the moment a new value is generated it is automatically propagated to all the subscribers of the data. Passive updates occur only on subscriber request and usually involves a comparison of local and remote timestamps before transmission. For example, passive updates are typically used to download large volumes of 3D model data. Caching data and comparing their timestamps helps to reduce the need to redundantly download the same data set.
The initial synchronization behavior determines how the local and remote keys should be synchronized when the links are first formed. That is, clients are able to choose to synchronize automatically based on the keys' timestamps. That is the older key will be updated with information from the newer key. However the client may also choose to force synchronization from the local key to the remote key, and vice versa, regardless of timestamp. Of course clients may choose to perform no initial synchronization at all.
Subsequent synchronization behavior specifies the manner in which data is synchronized when local or remote updates to keys occur. The same options as for initial synchronization hold.
The default link property is to use active updates with automatic initial and subsequent synchronization.
Some examples of events include:
This event occurs when a key receives a new piece of data. For example a key could be subscribing to avatar state information (position and orientation of the avatar's head). When this information changes, a callback can be invoked to make the corresponding changes to the graphical representations of the avatars in the virtual world.
When a connection to an IRB has been broken (possibly due to a crash) clients will continue to function by accessing local versions of the subscribed data. The personal IRB may then periodically attempt to re-establish connection with the remote IRB or choose another client or server to take the place of the ``broken'' IRB. It is the responsibility of the application-specific IRBs to determine the policies for such situations.
This event occurs when the negotiated QoS falls below contracted levels. For example, if the latency negotiated for a stream of tracker data falls below acceptable limits, the VR client can be warned so that perhaps interpolative techniques such as dead-reckoning[Macedonia and Zyda, 1995] can be activated to reduce the impact of the increased latency. Alternatively the client can re-negotiate a different QoS, perhaps one involving a lowering of the bandwidth (by compression of data) in order to maintain the desired latency.
In these recordings close synchronization of remote system clocks is not absolutely necessary as recording is always made from one point of view and hence it is the point of view's time reference that all relevant information is recorded.
Recordings may consist of time stamping and storing every change in value that occurs at a key and recording the state of all the keys at wide intervals. The former is needed to track the gradual changes in the virtual environment over time. The latter is needed to establish checkpoints so that the recordings may be fast-forwarded or rewound without having to compute every successive state that led to the fast-forwarded/rewound location.
On playback the recordings will populate the appropriate keys and, if desired, trigger client callbacks. In some instances it is useful to be able to playback only a subset of the recorded keys. This will allow the user to observe smaller subsets of events that occur in the VR environment. For example the Virtual Director[Thiebaux, 1997] (a VR application that allows users to record the path of a virtual camera through a virtual environment) allows playback of recordings of camera positions in each of the three X,Y,Z axes so that each of the paths in the axes can be edited independently.
Finally to synchronize the playback of experiences across multiple virtual environments each environment must constantly broadcast their frame-rate. This ensures that faster VR systems do not overtake slower systems while rendering the virtual imagery.
Templates are divided into two categories: support templates and environmental templates.
Support templates provide a collection of libraries to support various basic CVR component services such as: encoding and decoding of audio and video streams for teleconferencing and management of avatars.
Environmental templates provide a suite of complete but extensible CVEs. For example an environmental template could be designed specifically to help domain scientists ``jumpstart'' the process of building collaborative scientific visualization applications. Such a template would automatically provide networking, visualization and recording components as well as basic collaboration components such as audio/video conferencing, and avatars.
The template layers of CAVERNsoft are the only layers that simultaneously interface with the IRB interface and the graphics interface (Figure 5.) For example, in order to support avatars, the IRB interface must be used to declare keys to hold avatar information. The graphics portion of the avatar template will be implemented with the CAVE library in conjunction with either OpenGL, OpenInventor, or Performer. This separation of the basic IRB interface and the graphics interface with the template layer allows the IRB system to be used in non-graphic computing systems such as supercomputers or workstation farms.
The database manager will be built using PTool[Grossman et al., 1995], a persistent object store developed by the Laboratory for Advanced Computing at the University of Illinois at Chicago. PTool's main use is in the efficient storage and retrieval of enormous persistent objects (typically occupying giga- to terra-bytes in size). A custom interface will be built on top of PTool to provide the abstraction of persistent keys. Strictly speaking the database that CAVERNsoft uses is a datastore. PTool achieves significant performance improvements over other object-oriented databases by stripping away the transaction management capabilities found in traditional databases.
Nexus and PTool are tightly coupled to minimize the latency involved in propagating incoming data from the network to the client application. Incoming data from the network is deposited directly into the datastore's cache. The client, on accessing the data, may either make a single copy of the data, or choose to temporarily lock the key (and hence the affected region of the cache) to directly access the data via a pointer. By traditional database standards, this is potentially ``dangerous,'' as a client may forget to unlock a key after using it and hence prevent its subsequent update; but when dealing with time-critical data as in CVR, this is acceptable. Essentially this means that incoming data from the network is at most copied once by the time the data is stored in the datastore and the client uses it. This is typically not the case with traditional distributed-object implementations such as Orbix 1.3 and ORBeline 1.2[Schmidt et al., 1995].
As there are potentially multiple streams of incoming data destined for a key, each key holds a number of temporary ``buffers'' (one per link) which all contain pointers to independent regions of the datastore's cache. When data arrives, it is deposited directly in the appropriate temporary buffer, and a pointer switch occurs which makes the buffered data, the current data in the key. Again, this guarantees that at most one memory copy occurs from the time the data arrives at the IRB to the time the data is used by the client.
The main distributed components of NICE consist of the garden simulation server, the WWW servers from which models are downloaded, and the NICE ``smart-repeater.'' In the CAVERNsoft model all these components are replaced by IRB-based clients and servers.
The garden server can be built out of an IRB with two main keys- an incoming message key and an outgoing message key (Figure 6.) NICE clients, which are also built from IRBs, can start up by first linking to the garden message key to ask for information on the state of the garden. This is done by sending a message to the garden server's incoming key and receiving state information on the outgoing key. The state of the garden can actually be distributed amongst multiple keys, but for simplicity garden message keys will be treated as message-passing conduits. Based on the messages from the garden server the NICE client can decide which 3D models it needs to download from the model repository server. The model repository server behaves like the WWW server in the original NICE implementation. The repository is of course implemented with an IRB. Since keys in all IRBs are timestamped, the client's download of the 3D models only occurs if the repository has a newer version of the model.
While the models are being downloaded, the NICE client may send a message to the avatar hailing key on the IRB repeater server (Figure 7.) This will inform any other NICE client that may already be participating in the environment, that a new participant has arrived. This information can consist of the address of the remote NICE client's IRB and the key under which the avatar models are stored (e.g. avatar1/models). Hence one client can directly access the models from a remote client. Alternatively all the avatar models can be stored in the model repository, in which case the clients simply give each other the key identifiers of the avatar models they are assuming. The clients can then consult the repository for the models.
Each client that connects to an IRB repeater can create a key on the repeater to hold its avatar state information (e.g. avatar1/state; Figure 8.) Hence any changes to client avatar1 will be first sent by the client to the repeater which will hold the data under that key. Another avatar (e.g. avatar2) will learn about the key through messages sent along the avatar hailing key by avatar1. Avatar2 can then discover the state of client avatar1 by subscribing to the avatar1/state key on the repeater. To reduce the latency involved in first sending avatar information to a repeater and then to the individual subscribing clients, avatars can choose to directly subscribe to each other's avatar/state keys. Yet another approach would be to link the avatar/state keys to one or more multicast addresses (Figure 9.) Again the hailing message key would be used to inform all participating clients of the proper subscription addresses.
In doing so one of our primary and largely practical goals is the production of CAVERNsoft to facilitate the rapid construction of complex CVR applications. To achieve this, we believe that at the present time, given the realtime performance demands of virtual reality, the most flexible approach is to adopt a symmetric architecture that uses light-weight, fast, distributed data-stores interlinked by customizable networking connections.
As CAVERNsoft is a long term solution to CAVERN's CVR needs it will continue to develop and evolve in the next few years as it is used by the CAVERN partnership. It is expected that by the end of 1997 the first applications built using CAVERNsoft will emerge. After the development of the underlying CAVERNsoft infrastructure, it is anticipated that future work will focus on the construction of multiple reusable CAVERNsoft environmental templates to further facilitate the rapid construction of collaborative virtual environments in numerous problem domains.
We would also like to thank the Nexus group for their networking support. The Nexus (http://www.nexus.org) group consists of Steve Tueke and Ian Foster at Argonne National Laboratory.
Major funding is provided by the National Science Foundation (CDA-9303433.)
This document was generated using the LaTeX2HTML translator Version 96.1 (Feb 5, 1996) Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
The command line arguments were:
latex2html -split 0 -no_navigation -show_section_numbers
index.tex.
The translation was initiated by Jason Leigh on Thu Jul 3 13:10:25 CDT 1997