|
Syzygy Documentation: Syzygy ArchitectureIntegrated Systems Lab01/02/2007 Documentation Table of Contents
Syzygy's architecture is divided into five layers. At the base is a portability layer that hides the differences between Win32 and Unix. Built upon this is a communications layer that provides the basic building blocks for network services. Various media protocols, such as for graphics and sound, are built using these services. The media protocols form the third layer. The media protocol components are combined with Syzygy's distributed operating system to form autonomous media objects, like sound players and remote scene graph renderers. This is the fourth layer. Finally, Syzygy has various application frameworks that use the media objects and combine them into a coherent system. Each application framework represents a different style of cluster VR programming and provides an API. These application frameworks are the fifth layer.
Portability Layer(Described in more detail in the Portability Layer chapter). Win32 and Unix have different APIs for threads, locks, sockets, and serial I/O. By wrapping these calls with a common API, the portability layer makes writing portable software easier. The common API is provides lowest common denominator functionality, but this suffices for building the higher levels of the Syzygy system. Communications InfrastructureThe communications infrastructure provides tools for constructing communications protocols that are easy to change, handle data format conversion automatically, and provide robust connect/disconnect/reconnect in an unreliable network environment. The programmer defines a protocol by creating a dictionary of message templates, which defines the semantics of the messages that can be sent over the wire. Data transfer objects then handle connection management chores and moving data between communicating peers and into the applcations. Eventually, this layer will contain an abstract interface to the underlying communications medium, allowing the same code to work over TCP, UDP, or shared memory communications pipes. Media ProtocolsThe communications layer is then used to build protocols for manipulating media information. These include methods for performing synchronization, distributing and rendering a scene graph, manipulating and playing a sound database, and communicating with input devices. Network-based synchronization primitives are necessary for providing swap-lock between multiple graphics pipes. Only a very simple distributed database prototype has been built so far. However, the graphics and sound implementations are built on top of it. In the current implementation, a master database accepts network connections from remote slave databases. At connection, the master database dumps itself in the slave database, creating two synchronized copies. Subsequent changes to the master database are automatically mirrored to the slave, creating consistency without resort to programmer effort. Syzygy supports a general input device framework, where distinct physical devices can be aggregated into larger virtual ones and data transforming filters can be added to any data stream. Distributed Operating System(Described in more detail in the Distributed OS chapter). A program, szgserver, manages basic services of a distributed operating system. One instance of this program runs per Syzygy installation. All Syzygy programs connect to it. Potential bottlenecks are avoided by limiting its function to setting up connections between elements in the distributed system. Another program, szgd, runs on each computer in the distributed system. This provides remote execution services via a uniform interface across Unix and Win32. The distributed operating system provides process management services. Applications can be remotely started or killed on any system from any system using either a command-line interface or a simple java GUI interface. There is also a built-in means for interprocess communication, namely a standard interface by which applications can send messages to one another. There is also a parameter database which is managed by szgserver and functions as a meta-config file accessible and maintable over the network. This replaces the many text configuration files that might otherwise be scattered on machines throughout the distributed system. The distributed operating system also includes support for multiple users. Eventually, it will support a more automatic style of application configuration. Connections are currently made by entering IP/port pairs in the parameter database, but this will soon be automated. Media ObjectsObjects like SoundRender, for the distributed sound database, and szgrender, for the distributed graphics database, provide clients that turn information from the network into sensory events. These objects use the distributed operating system for configuration information and connection management. Application FrameworksThe Syzygy toolkit needs to be flexible. Authors of distributed applications need a variety of tools and approaches with which to accomplish their work. For instance, there are two basic approaches to writing a distributed graphics application: either distribute the application's data, be it geometrical primitives, scene graph changes, or pixel data, or distribute the application itself. Syzygy offers a distributed scene graph that can replicate itself on dumb rendering clients, thus allowing synchronized display across multiple networked pipes. An API for building such applications is encapsulated in arDistSceneGraphFramework. Syzygy also offers tools for distributing the application, namely converting existing applications so that multiple copies can run synchronized across a network. This paradigm is encapsulated in arMasterSlaveFramework. Finally, because of its origin, Syzygy offers a range of functions for dealing with VR-specific problems, like calculating projection matrices for screens, managing trackers, and navigating within a world. The Syzygy application frameworks use a set of common objects to manage shared functionality. Each descends from arFrameworkObject and shares the following methods:
bool configure(arSZGClient&);
Reads in parameters from the Syzygy database and uses them to configure
the object.
Note that this is different from the init/start/stop associated with "active objects".
|
|
[Schedule] [Labs] [Beckman Meeting Rooms] [Equipment] [Projects] [CUBE Projects] [Syzygy] [VSS] [People] [Events] [Publications] |
