|
|
The Collaborative Virtual Workspace utilizes a client/server architecture to implement the shared virtual space. The core components of CVW are the:
The CVW client and Server maintain persistent connections and communicate via TCP/IP and MOO Client Protocol (MCP). MCP supports textual communication, navigating and interacting with objects in the virtual space, and receipt of state information. The CVW client and Document Server communicate via an HTTP-based protocol, using transactional connections whenever the client performs an interaction with a document.
Integration of applications into the CVW is accomplished either via an application's API, the command line, or by modifications to its source code. Integration of data into the Unix CVW client is most often implemented by first defining a MIME type within the CVW and then accessing the data as it is normally accessed by other applications.
Multipoint audio and video conferencing are implemented peer to peer using vic (Video Conferencing Tool from Lawrence Berkeley Labs) and vat (Visual Audio Tool from Lawrence Berkeley Labs) via IP Multicast. The CVW server supplies multicast address information for the room-based conference to the clients transparently.
The CVW server has at its core a multi-user dimension (MUD), specifically a MOO (MUD, Object-Oriented) developed by Xerox PARC. MOO is freely redistributable software which provides a highly programmable shared virtual space. The benefits of using a MOO for the CVW server side are: object oriented virtual spaces providing rooms, people and objects, relative ease of extensibility, specialized language support and existing code base. The disadvantages are limitations in performance and scalability.
The CVW Server process is a single threaded process. Server performance is not impacted by multiple CPUs, but a faster CPU and sufficient memory to hold the entire database in RAM does greatly improve performance. The MOO server can scale up to about 300 maximum concurrent users.
A MOO has two primary components: the database (represented by and implemented in MOO-code), within which all objects and code exist to implement and populate the virtual space, and the server base, which manages incoming TCP/IP connections and executes the MOO code in the database (written in C). As new objects and features are required from the server, MOO-code is written to implement them; performance hot-spots can be recoded in C as MOO-code primitives.
The installation footprint for the CVW server is described below.
| Directory | /opt/CVWserver/ |
| Database file | CVW.db |
| Database checkpoint files | CVW.db.new, CVW.db.old.Z |
| Runtime engine (process) | moo |
| Startup script | start-mooserver |
| Log file | CVW.log |
| CVW startup script | /etc/init.d/cvw |
The MOO Client Protocol, MCP, is a standard used in the Internet MOO research community; it is a protocol for transmitting structured messages between client and server. It provides multiplexed structured streams over a single TCP connection. It traffics in "requests", which have types, properties, and optional multi-line extensions. The CVW client sends the MCP cookie to the CVW Server upon login, causing the server to send MCP commands to the client. The CVW Server does not send MCP commands to other clients such as telnet because the MCP cookie is never presented to the server.
Requests are intended to be high-level; for example, some of the current requests used in the CVW client include room and folder contents, object overview information and multicast session establishment. By concentrating on a more semantic level, the CVW client provides interactivity and reduced bandwidth usage. Because many small sessions can be wrapped into a single TCP connection, there exists a single access point for authentication and encryption, as well as providing reduced per-connection overhead.
The CVW Document Server is responsible for storing, managing, and serving CVW documents of varying MIME types for use within the CVW environment. It provides a universally available file space, allowing continual shared access and use in which CVW participants can asynchronously view and edit CVW documents through local applications.
The Document Server is implemented in Java as an application. It creates and maintains an index to the flat file document store, maintains meta-data for each document in the document store (consisting of document ownership, modification history, editor comments, and document status), and enforces single-user editing through check-out and check-in procedures. The CVW Document Server uses MIME for file type specification, and relies upon a customizable translation file (transtable.db) to provide the mapping between the MIME type (used by the Unix CVW client) and the file extension (used by Windows). It interfaces with CVW clients and whiteboards via HTTP, thus all CVW documents are accessed as web references. For optimal performance, the CVW Document Server should have sufficient memory to hold the index file in memory.
The installation footprint for the CVW Document Server is described below.
| Directory | /opt/CVWserver/ |
| Document store | doc-store/ |
| Doc store index file | doc-store/index.db |
| MIME to file extension translation table | doc-store/transtable.db |
| Doc server log file | docserver.log |
| Java runtime environment | jre1.1.6/ |
| Document server startup script | /etc/init.d/cvwds |
The CVW client provides users with a graphical user interface to interact with other users, data, and the virtual space, and also provides the fundamental integration point for applications. CVW has two client code base variants: Tcl/Tk and Java. The Tcl/Tk client is available on SunOS 4, Solaris 2, IRIX 5&6, HP-UX 10, and LINUX 2. The Tcl/Tk client was the first CVW client developed and uses the older MCP protocol specification. The Java client is available on Win32, Solaris 2, and LINUX 2 and can be built on other platforms where Java is supported. The Java client communicates with the server via that latest MCP protocol specification.
The CVW client's connection to the CVW server is a persistent connection. The CVW client's connection to the CVW document server is a transactional connection, and is only invoked when the user is performing document interactions. The CVW client maintains a client-side cache for document server interactions, where a local copy of documents the current user has open or checked out for editing resides. When users complete document interactions, the local document is purged from the cache.
The Unix CVW client (Tcl/Tk and Java Unix implementations) uses a MIME specification in a client-side (mime-db) file to generate the list of file types that users can import into CVW. Any MIME file, such as text, image, audio, video, etc., can be imported into CVW. Both Unix clients also use this file to determine which application to use when opening a CVW document for view and edit. The CVW Tcl/Tk client MIME specification file supports passing additional arguments which facilitate a tighter integration of applications into CVW. The arguments can pass state information (e.g., audio/video conferencing multicast information, user's name, room name, client hostname) to the helper application.
The Windows CVW client observes the Windows registry and file extension mapping to identify file types and helper applications used to open files and no special client-side specification files are required. Since the CVW Document Server is based on MIME for file type specification, a customizable translation file (transtable.db) resides on the document server to provide the mapping between the MIME type (used by the Unix CVW client) and the file extension (used by Windows).
The installation footprint for the Unix CVW Client is described below.
| Directory | /opt/CVW/ |
| Client startup script | bin/xcvw |
| OS specific binaries (CVW, Vic, Vat, etc.) | bin/os_type/ |
| Client resource file | etc/cvw.res |
| Client default preferences | etc/cvwprefs |
| User images | lib/images/user/ |
| Client icons | lib/images/Core/ |
| OS specific libraries | lib/os_type/ |
| Document Mime types | lib/os_type/mime-db |
| Man pages | man/ |
| Directory | User’s home directory (~) |
| User preferences | ~/.cvwprefs |
| Client document cache | ~/.cvwcheckout/ |
| Client document index file | ~/.dsrvrdb |
The installation footprint for the Windows CVW Client is described below.
| Directory | C:\Program Files\MITRE\CVW\ |
| Client application | CVW.exe |
| Client resource file | Server.cvw |
| Client icons and sounds | images\ and sounds\ |
| Conferencing tool binaries and libraries | modules\vic\, modules\vat\, modules\mwb\bin and modules\mwb\library |
| User preferences | Users\<username>\.cvwprefs
(for Win95) or $HOMEPATH\CVWUsers\<username>\.cvwprefs (for NT) |
| Client document cache | Users\<username>\cache\
(for Win95) or $HOMEPATH\CVWUsers\<username>\cache (for NT) |
| Client document index file | Users\<username>\cache\dsrvdb
(for Win95) or $HOMEPATH\CVWUsers\<username>\cache\dsrvdb (for NT) |
The CVW audio conferencing capability is vat, Visual Audio Tool, developed Lawrence Berkeley Labs. Vat source is available at LBL's web site, and binaries are available for SunOS, Solaris, Win32, IRIX, HP-UX, and LINUX. Vat supports point to point or multipoint audio conferences over an IP network. Multipoint conferences require client operating system support for IP Multicast (currently supported by Windows 95, NT 4.0, Solaris, IRIX, LINUX, etc.) and multicast routing support between the participating client's networks. The CVW server supplies multicast address information for the room-based conference to the clients, which transparently pass this information to the audio tool upon invocation and when users move from room to room. The CVW client provides a preference interface for specifying default audio conferencing encoder, microphone volume, and speaker volume.
Vat supports a number of audio encoding schemes, varying in quality and bandwidth requirements:
| Format | Bandwidth | CODEC |
| pcm | 78 Kbps | mu-law 8KHz PCM |
| pcm2 | 71 Kbps | mu-law 8KHz PCM |
| pcm4 | 68 Kbps | mu-law 8KHz PCM |
| dvi | 46 Kbps | Intel DVI ADPCM |
| dvi2 | 39 Kbps | Intel DVI ADPCM |
| dvi4 | 36 Kbps | Intel DVI ADPCM |
| gsm | 17 Kbps | GSM |
| lpc4 | 9 Kbps | LPC |
The CVW video conferencing capability is provided by vic, Video Conferencing Tool, developed at Lawrence Berkeley Labs. Vic source is available at LBL's web site, and binaries are available for SunOS, Solaris, Win32, IRIX, HP-UX, and LINUX. Vat supports point to point or multipoint audio conferences over an IP network. Multipoint conferences require client operating system support for IP Multicast (currently supported by Windows 95, NT 4.0, Solaris, IRIX, LINUX, etc.) and multicast routing support between the participating client's networks. The CVW server supplies multicast address information for the room-based conference to the clients, which transparently pass this information to the video tool upon invocation and when users move from room to room.
No special hardware is required to receive video, but a video capture card and camera are required for transmitting video. Vic supports bandwidth and frame rate limiting, and provides support for H.261, Sun CellB, and Xerox NV codecs. The CVW client provides a preference interface for specifying default video conferencing encoder, frame rate, and bandwidth values.
The CVW shared whiteboard capability is provided by mwb (MITRE whiteboard), developed at MITRE. Mwb provides persistent whiteboards as objects inside of the CVW. These whiteboards support drawing and image annotation by one or more parties in real time and utilizes the MCP channel between CVW clients and the CVW server to pass drawing objects between participants onto the whiteboard. Whiteboard image backdrops can be stored on the CVW Document Server, or referenced as an image location (URL) on a web server.
Mwb is implemented in Tcl/Tk and is available on SunOS 4, Solaris 2, IRIX 5&6, HP-UX 10, LINUX 2, and Win32. The same code base is used by the Tcl/Tk and Java CVW clients.
Multicasting itself is unrelated to CVW, except that it provides the underlying network infrastructure to support multipoint video and audio conferencing.
The IP multicast protocol (which is an extension to the standard IP network-level protocol) provides more efficient distribution of data over the network. IP multicast is a bandwidth reduction strategy that is in widespread but experimental stage on the Internet and on DoD networks. It provides the ability to send packets in a one-to-many fashion (e.g. streaming UDP audio/video data) through the use of IP class D address extensions (224.0.0.0 to 239.255.255.255). The address range of 224.2.*.* is the range used by the MBone (Internet Multicast Backbone) users for audio and video conferencing sessions. Sessions are assigned multicast addresses, and users join the session by subscribing to the multicast address with their client software. Session participants may join and leave the session at any time if they know the multicast address for the session.
Network routers that can route multicast traffic are required. If multicast-capable routers are unavailable, a multicast tunneling scheme can be employed to forward multicast packets among participating subnets by encapsulating the multicast packets inside regular IP packets. Multicast tunnels are made up of one tunnel endpoint (workstation running the mrouted software) on each subnet that needs to be interconnected.
The audio and video conferencing tools integrated with CVW, LBL vic and vat, use IP multicast as supporting network infrastructure for mulitpoint audio and video conferencing. The CVW Server does not participate in the multicast network. The role of the CVW Server is to provide a unique multicast address for each CVW room to the CVW client, so that the client can pass the address to the conferencing tools.
A complete multicast address is made up of 4 octets. In the CVW, the first two octets (i.e., 226.10) make up the base address for the CVW Server. This base address is provided by the CVW administrator in the CVW System Settings. The second 2 octets make up the room address in which the audio and video conference is being held. These are automatically sent by the CVW Server to the CVW client when a user walks into a room. Each room in the CVW has a unique predefined room address which is used by the CVW Server in managing the multicast conferences for that room.
What makes the full multicast address unique for each room across all CVW Servers is the base address provided by the CVW Server administrator. It is important that the base address for each new CVW Server on the same network be unique so that the multicast traffic is kept separated from server to server. For example, if two CVW Servers on the same network shared the same base address, users in the rooms corresponding to the location of room 101 on each server would appear in each other's audio and video conferences because they would be sharing the same multicast address.
Last update: 13 October 2000
This work, including the source code, documentation and
related data, is placed into the public domain.
The original author is
The MITRE Corporation.
THIS SOFTWARE IS PROVIDED "AS IS" AND WITHOUT ANY
WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, AS TO THIS
SOFTWARE, OR TO THE ACCURACY, CAPABILITY, EFFICIENCY,
OR FUNCTIONING OF THIS SOFTWARE OR ANY DERIVATIVE WORK
OR OTHER ITEM MADE, USED, OR SOLD THAT INCORPORATES
THIS SOFTWARE. THE AUTHOR OF THIS SOFTWARE ASSUMES NO
RESPONSIBILITY FOR ANY CONSEQUENCE RESULTING FROM THE
USE, MODIFICATION, OR REDISTRIBUTION OF THIS SOFTWARE.
Information in this document is subject to change without notice.
Other products and companies referred to herein are trademarks or registered
trademarks of their respective companies or mark holders.