ACM Multimedia 95 - Electronic Proceedings
November 5-9, 1995
San Francisco, California

Multimedia Application Sharing in a Heterogeneous Environment

Klaus H. Wolf


Department of Distributed Systems
Computer Science Faculty
University of Ulm
89069 Ulm, Germany
+49 731 502 4140
wolf@informatik.uni-ulm.de
http://www-vs.informatik.uni-ulm.de/Mitarbeiter/Wolf.html

Konrad Froitzheim


Department of Distributed Systems
Computer Science Faculty
University of Ulm
89069 Ulm, Germany
+49 731 502 4140
frz@informatik.uni-ulm.de
http://www-vs.informatik.uni-ulm.de/Mitarbeiter/Froitzheim.html

Peter Schulthess


Department of Distributed Systems
Computer Science Faculty
University of Ulm
89069 Ulm, Germany
+49 731 502 4140
schulthe@informatik.uni-ulm.de
http://www-vs.informatik.uni-ulm.de/Mitarbeiter/Schulthess.html

ACM Copyright Notice


Abstract:

Application sharing facilities will become a key component of synchronous CSCW systems and permit the simultaneous use of off-the-shelf applications like word processors and spreadsheets by a group of cooperating users. Special system level software is inserted between application and terminal to distribute output and multiplex input streams. Heterogeneity adds another major task to a sharing system. Application output and user input have to be converted between different graphics and window systems. This paper introduces concepts of application sharing, graphics stream conversion, and their combination. It presents two sharing systems with integrated graphics conversion enabling the use of single user Macintosh applications concurrently on Macintosh and X Window displays. The systems are compared in terms of performance, quality of presentation, and extendibility.

Keywords:

CSCW, collaboration environments, application sharing

Table of Contents


1. Introduction

1.1 The Challenge

Recent advances in personal computers and networking technology will provide the basis for innovative communication and cooperation services. A majority of the new applications and services focus on improving the quality of popular telecommunication services like telephony or fax, providing video conferences and remote printing. New services explore areas such as Computer Supported Cooperative Work (CSCW, groupware), e.g. electronic white-boards, shared document editors, workflow management. These services are typically provided by a set of custom built, cooperation aware application programs.

Acceptance of CSCW applications has been slow so far. An important reason for this seems to be the gap between the sophisticated user interface and functionality of local applications (word processors, spreadsheets, etc.) and the limited power of the tools normally supplied in CSCW packages. Users are spoiled by local functionality and are not willing to cope with the numerous deficiencies in CSCW tools. Similarly people are not willing to change their working environment, many have a highly emotional relation to a particular computer brand or operating system. The significant investments of individuals and corporations in workstations, applications (and professional formation) prevent them from simply switching to telecooperation scenarios.

<-- Introduction
<-- Table of Contents

1.1.2 Screen Sharing as a Solution

The developers of CSCW software will never be able to keep up with the exponential growth of all those useful and useless features of specialized applications on every platform. A different solution to this problem therefore attempts to provide a system level service, which lets us use sophisticated standalone applications such as Microsoft Word and Excel, FrameMaker, Adobe Premiere and Photoshop, etc. in a telecooperation scenario. The basic idea is output sharing, i.e. exporting and distributing application output.

The screen sharing prototypes and products available so far (Timbuktu, Carbon Copy, PlanetX, etc.) typically share a whole screen. They are typically used by network managers to configure and support workstations in a network withoutleaving their desk. Timbuktu can also be used for teleworking, where sharing of a whole screen is desirable.

More often however it is not acceptable to share all of a personal screenspace while working with others. We regard the screen of a workstation as something very personal: there are applications (mail, calendar, maybe even a game) visible, directories with file names and other sensitive items. The information to be shared is typically contained in one or two document windows, e.g. a spreadsheet, a text, or a movie.

<-- The Challenge
<-- Introduction
<-- Table of Contents

1.1.3 Multimedia Window Sharing: the Better Solution

For the purpose of CSCW it is usually sufficient and more desirable to share only the contents of some windows or all windows of a single application. In this case application sharing based on window sharing meets the users' demands better than plain screen sharing. Chapter 2 outlines the concepts of application sharing.

Another important feature of an application sharing service is heterogeneity with respect to supported graphics systems and windowing environment. A number of sharing services have been presented for homogenous sharing of X Window applications between several X Window servers [3] or sharing of Microsoft Windows applications between Windows machines (e.g. ProShare). Few application sharing services connect different graphics and window systems however. Chapter 3 describes the requirements for such a system and implementation issues.

Sharing services and application output converters may be combined into a heterogeneous sharing service in different ways. The chosen model has substantial consequences on the system's modularity and extendibility, as well as performance and possible application scenarios. The 4th Chapter discusses this topic and compares two of our implementations.

<-- The Challenge
<-- Introduction
<-- Table of Contents

2. Multimedia Application Sharing

The basic concept of application sharing is multiplexing of output streams from applications to terminals and multiplexing (filtering) of user input (figure 1). The term terminal refers to any high resolution graphics display and its driver or display server software. Sharing is supported on the application level or on window level: either single windows are shared or all windows of an application. There is no global sharing of the entire screen. Each terminal maintains its own instances of shared windows. The positions of shared window instances may differ on different stations. Even the stacking order of shared windows might vary, permitting an individual arrangement of shared window instances on each terminal.


Figure 1:
Multimedia Application Sharing Service as mediator between single user applications and terminals.

A Multimedia Application Sharing Service (MASS) is a mediator between applications and terminals. Multimedia output from an application to a terminal (user interface output) is redirected by the sharing service in order to be distributed to all connected terminals. Single user applications are not aware of being used within a sharing system. Since they do not expect multiple input streams, input from participating users has to be multiplexed (filtered) to the applications. So called floor control mechanisms are used to control the multiplexing. See [5] for a description of these mechanisms.

<-- Table of Contents

2.1 Redirection

Typical personal computer architectures and applications are intended for use by one person at a time. Even multi-user operating systems such as UNIX assume one-to-one relations between the user and This single user scenario ignores potential telecooperation and thus results in software structures where applications, operating system, and devices are interlocked to a high degree (figure 2). A notable exception is the X Window System, where the graphical output is transferred over a network connection, using the X protocol.

Audio and video are typically mediated through multimedia toolboxes and protocols like QuickTime, Video for Windows and X protocol extensions. These interfaces are significantly more complex than traditional graphics toolboxes. For performance reasons multimedia toolboxes frequently use special channels bypassing the graphics system or other standard I/O mechanisms for video and audio. This results in a tight interlocking of application and terminal.

The usual redirection method is to replace one component of the graphics system or toolbox between application and terminal by a redirecting component. A redirecting component mimics the functionality of the original (replaced) component and additionally extracts information about application output. Most architectures offer several points of redirection at different levels. The level has to be chosen very carefully in order to balance between two competing parameters: Abstraction level and volume of the gathered data.

2a: 2b: 2c:
Figure 2: Input/Output Service Access Points in different computer architectures. The jagged lines denote highly interlocked interfaces.

Figure 2a: Network unaware graphics systems of Personal Computers: MS Windows/Macintosh
Figure 2b: Network aware graphics systems such as the X Window System
Figure 2c: Optimal: A single narrow interface

<-- Multimedia Application Sharing
<-- Table of Contents

2.1.1 High Level Redirection

High level toolboxes like Xlib and QuickDraw present a highly complex interfaces. Toolbox interfaces to applications are designed to fulfil as many application programmers needs for comfortable output operations as possible. They offer a large number of procedures, typically with overlapping functionality. Redirection at this point offers the highest level of semantic information about application output. However, extent and complexity of these interfaces make them unsuitable as redirection interface and point of interception.
<-- Redirection
<-- Multimedia Application Sharing
<-- Table of Contents

2.1.2 Device Driver Interface

Most operating systems offer means to attach new physical components such as high resolution displays, graphics accelerators, or printer drivers to the graphics toolbox in a standardized way. They typically use a driver interface or the concept of bottleneck procedures for this purpose. In the case of the Macintosh graphics system this interface is called 'low level QuickDraw routines'. The Macintosh QuickTime architecture for multimedia uses the notion of 'Components' to allow for different modules to compress, decompress, digitize, or play synchronous media.
<-- Redirection
<-- Multimedia Application Sharing
<-- Table of Contents

2.1.3 Transport System Connection

The X Window system offers an obvious choice for redirection: the transport system connection which links an X Window application (X client) to a terminal (X server). X protocol primitives are transmitted over this connection (see figure 2) carrying all the information required for the presentation of application output. This does not imply that the information obtained at the transport system connection is optimal for sharing however. Graphics protocols can be very complex at this level. But network transparent window systems are most easily redirected at the transport system connection.

Video and audio in the X environment are more difficult to obtain. Many manufacturers chose to implement their own X protocol extensions and audio device interfaces. Multimedia toolboxes like QuickTime provide structured access methods to multimedia data. From the redirection's point of view the mechanisms of multimedia presentation are very similar to the presentation of graphics protocol data streams.

<-- Redirection
<-- Multimedia Application Sharing
<-- Table of Contents

2.1.4 Low Level Redirection

The framebuffer access path offers a very low level interface, which guarantees interception of all output. At this level application output is completely rendered by graphics engines. The data obtained consists of a sequence of pixel maps without context information. The data volume is drastically higher than that at the levels above. Relation to windows and application contexts are not present at this bottom level. Its simplicity makes it the natural choice to implement plain screen sharing, although more sophisticated models for screen sharing are possible (Timbuktu).
<-- Redirection
<-- Multimedia Application Sharing
<-- Table of Contents

2.2 Multiplexing

2.2.1 Centralized Model

A centralized sharing system is a single component which multiplexes application output to several connected terminals. User input events from the terminals are multiplexed by the sharing component into the application input stream. The sharing system is usually located in the same machine as the shared application or at least close to it in terms of communication cost [2]. This model uses two types of connections: Both connection types are bound to existing protocols, because each connects to an unmodified off-the-shelf component: the application or the terminals (figure 3).


Figure 3: Sharing system with centralized architecture. The shared application and the sharing service are located near to each other, e.g. on the same host.

In a homogeneous CSCW scenarios, i.e. all participants have the same equipment, the centralized model results in one standalone sharing component for each host. The separate sharing systems may collapse into one so-called sharing server which is unique within one CSCW context, e.g. a conference. In the latter case all applications connect to this server in order to be shared. This model obviously does not scale with the number of connected terminals and shared applications. Furthermore it is not useful in a heterogeneous environment which supports network unaware window systems.

<-- Multiplexing
<-- Multimedia Application Sharing
<-- Table of Contents

2.2.2 Distributed Sharing System

In order to distribute the functionality of an application sharing system, we divide it into four major tasks [8]: Two of these tasks, filtering and archiving, have to be located near the shared application, while the other two perform better if located near the terminals. The term near means a connection with high throughput and low delay and cost. Such a connection may be a local area network (LAN) or interprocess communication via shared memory.

Partitioning of the sharing system according to the tasks defined above leads to a distributed model. The distributed system implies a third type of interface between the two separated components of the sharing system which is entirely under the control of the sharing system. It may carry a protocol extended from or even independent of the mediated graphics protocols. Specific features such as compression or encryption can be added (figure 4).


Figure 4: Distributed Architecture. Several individual connections between the application related and terminal related components may be substituted (in one direction) by a multicast connection (light arrows) if the protocol carried by this connection is appropriately designed.

<-- Multiplexing
<-- Multimedia Application Sharing
<-- Table of Contents

3. Conversions Between Graphics Systems

The major graphics systems (X-windows, QuickDraw, MS-Windows, ...) offer comparable functionality to application programs. The interface between an application and the highest layer of a graphics system is the toolbox API (Application Programmers Interface). The primitives of a typical toolbox API can be divided in two major groups: A graphical context contains a set of parameters which control rendition of output operations. The highest layer of a graphics system manipulates the graphics context and converts parameters and commands, convenient for the human programmer, into a representation better suited for the lower layers, e.g. converting RGB colors into color index values or manipulating the clipping area, utilized by the graphics engine in lower layers. Resource management refers to operations like identification and allocation of fonts, patterns and color maps.

Output functions fall into several classes. There is for instance the Rectangle class which contains a set of Rectangle functions like Fill-Rectangle and Frame-Rectangle. The higher layers of the graphics system map complex functions to single graphics primitives. Primitives like lines, text, arcs, pixel maps are similar in all graphics systems. However the actual definition may differ.

The concept of multimedia data presentation using a multimedia toolbox is similar to graphics output. The following discussion therefore applies equally well to graphics, audio and video streams, although it is more difficult to intercept these media streams between applications and terminals (see Chapter 2.1).

<-- Table of Contents

3.1 The Purpose of Graphics Conversion

Application output represented by a protocol can only be interpreted by a rendering graphics engine, if the graphics protocol is understood. In a heterogeneous environment the rendering information carried on the connection is adapted to the terminal's needs. A general purpose sharing system might need n*(n-1) converters to support n graphics systems. Even a conversion between the three most commonly used systems (X, Macintosh Quickdraw, and MS Windows) would require a very large scale effort. A real implementation is better off selecting one common network representation. This may be either one of the existing network-transparent window system protocols or a completely new design (see Chapter 4).

A second, equally important reason for conversion is the move from network unaware graphics (e.g. MS Windows) to a network-transparent system. When application programs written for standalone graphics systems are shared, the rendering requests flowing across the graphics system software interfaces must be converted into a networkable graphics protocol. This is done through translation of graphics system functions, their parameters, and context information into PDUs (protocol data units) of a graphics protocol. In a heterogeneous environment this translation may become very involved and reaches beyond simple coding and assembly of messages. The next chapters will focus on this type of conversion.

<-- Conversions Between Graphics Systems
<-- Table of Contents

3.2 Translation of Application Output

3.2.1 A General Form of Translation

Application output to a terminal consists of a stream of graphics operations P(g), g being defined by two sets of parameters: Number and cardinality of the parameters of each set differs between graphics systems. An example is the 'transfer-mode' context parameter used in many graphics systems. It specifies the result of the combination of two pixel values during a pixel map transfer. Most graphics systems allow several (4 to 16) boolean operations on pixel values. However transfer modes in one system do not always have direct counterparts in other systems.

An output operation using graphics system A is described by the combination P of the two parameter sets:

.

Translation of output operations between graphics systems means transformation of the parameter set of system A into the representation of system B: . Only between related or similar graphics systems direct mappings of output operations exist in the form:

The general case is mapping of single output operation in the representation of the source system into a (finite) sequence of output operations in the representation of the target system. This is particularly so for graphics primitives of a source system which do not have counterparts in the target system (e.g. the X-Window system's PolyLine or Quickdraw's rounded rectangle). The symbol o denotes the sequential operation:

Not all parameters of P are sent to the graphics system for each output. Typically an output command G(P) (procedure call or protocol data unit) contains only a small subset of P, mainly command type and coordinates. The context information is often changed earlier by a separate context manipulation command M depending on the current context state and the state needed for the processing of the output command ( ).

Each graphics system has its own set of output commands and context manipulation commands {G, M}. Output operations are mediated by sequences of such commands. An output operation g, obtained by redirection in the source system as the set of parameters , is implemented by the output command of this system:

In order to achieve the same result with the target system's capabilities, a translator has to perform some context manipulation on the target context and the actual output command. The operation is implemented in the target system as:

Hence follows the general form of a transformed graphics output operation:

This symbolic notation proved helpful in keeping a clear perception of the issues in graphics conversion. We are using this symbolism to straighten the structure of our software on several platforms. It also provides a framework to separate between conceptual views and mechanisms specific to some hardware platform or graphics system implementation.

<-- Translation of Application Output
<-- Conversions Between Graphics Systems
<-- Table of Contents

3.2.2 Bridging Functional and Semantical Differences

Some graphics primitives have very similar semantics in different graphics systems. The definition of a rectangle is an example. It is the area defined by two points in the coordinate plane. Conversion of rectangles is thus simple and essentially reduced to coordinate transformations.

Conversion of other primitives is more demanding. Line representation is a good example for different semantics. The algorithm selected for the rendition of a line has a major influence on the result of the operation. One system may regard a line as the set of pixels whose center is inside the rectangle defined by the endpoints and the line width [9]. In other systems a line is defined as the set of pixels touched or covered by a virtual pen moving between the endpoints. Figure 5 shows the different concepts. The difference becomes apparent when drawing wider lines, specified by a 'line width' parameter or by a 'pen size' larger than one pixel. As an example: A converter between Quickdraw and the X protocol is forced to emulate a line drawn in the Quickdraw system with a nontrivial pen shape by a filled polygon operation of the X protocol.

Quickdraw:

X Window System:

Figure 5: Concepts of line representation. The Quickdraw pen of rectangular shape (here 5x2 pixel) hangs below and to the right of the specified coordinate and colors pixels while moving. In the X Window System a basic line is symmetric to the specified endpoints.

The concept of a Region used in some graphics systems for clipping and as a drawing primitive is another example where functional gaps between the capabilities of different systems have to be bridged by the translator. The Quickdraw system allows complex shaped and even disjoined sets of pixels as a region. A region within the X Window system however is represented by a bitmap or by a list of rectangles. The mapping between these different representations requires efficient algorithms for conversion of regions in the translator.

<-- Translation of Application Output
<-- Conversions Between Graphics Systems
<-- Table of Contents

3.2.3 Exploiting the Source System's Capabilities

A substantial part of the application graphics output consists of pixel maps or bitmaps. Often the manipulation of images and user interface elements of applications makes use of pixel maps. Operations which translate pixel maps may cover a small area of the screen only but they are expensive compared to other primitives. The translation of pixel maps between graphics systems often needs calculations for every pixel.

In most graphics systems pixel operations are highly optimized. In order to utilize these capabilities the converter creates a pseudo screen device in its program data space as offscreen framebuffer. The converter then calls functions of the source graphics system to perform pixel map operations in the offscreen buffer. This method is particularly effective if the offscreen buffer is mapped on the memory where protocol data units of the target system are assembled (figure 6).


Figure 6: Usage of functions of the source graphics system for the transformation results in better performance and less code for the graphics converter.

<-- Translation of Application Output
<-- Conversions Between Graphics Systems
<-- Table of Contents

3.3 Translation of User Input

In single user scenarios, input events (mouse and keyboard) is processed by the window system or by some other system component. The events are filtered and directed to the application holding the input focus. Some user input is directed towards the system, e.g. to change the input focus or to trigger window or system management operations. Other user input events are queued by operating systems and window managers for later collection by the application program. These events reach an application together with other messages originating from the system (e.g. redraw messages for exposed window parts).

In an application sharing scenario the input from all connected terminals is collected and fed to the shared application. Input filtering and floor control mechanisms may be applied by the sharing system before the events are handed over to a converter. User input is translated to the event format known by the shared application and put into appropriate application or system event queues. Most operating systems offer functions to insert synthetic events into these queues.

<-- Conversions Between Graphics Systems
<-- Table of Contents

3.4 Translation of Window Management

Not all user input at the terminal reaches applications directly. A part of user interaction is restricted to window or system management operations. These operations do not directly affect the content of shared windows. They rather affect visibility and relative position of shared windows. In many cases applications are only notified of such operations through side effects like exposition of windows or size changes and related operations (e.g. hide/show window, iconify). Some applications even require control over window management. The accumulation of all such events from several terminals is very carefully filtered to avoid overloading the shared application.

Even more exacting is the translation of window management operations between window systems with different policies and capabilities. A window system may process window management operations entirely on its own (sometimes according to guidelines from the application) and inform the application about the result. Other window systems operate only on request from an application. They may inform an application about the start of user interaction, let the application control the processing and merely support it with toolbox functions. A converter of window management operations has to mediate between these different policies. The amount of window management functionality offered is independently limited both by the target system and the source system capabilities.

<-- Conversions Between Graphics Systems
<-- Table of Contents

4. The Distribution of Conversion and Multiplexing

There are several options to distribute the components of the sharing system between application host and terminal workstations. For the purpose of functional distribution three major software components within a heterogeneous sharing system are identified: The redirector is obviously the component closest to the shared application. The entire sharing system is based on the data stream obtained by the redirector. Other components must complement the redirector in such a way that the entire system meets the requirements of the application scenario.
<-- Table of Contents

4.1 Reference Models

4.1.1 Transmission Optimized Arrangement

The components of the transmission optimized system are arranged in order to make best use of the transport system, i.e. by reducing the network load of inter host connections. There are essentially two complementary approaches for a graphics sharing system to reduce network load on connections between multiple hosts:

The first is data compression. A distributed sharing system should choose a representation of the mediated graphics streams which has a lower data volume. It might use well known compression algorithms like runlength or entropy coding, or utilize lightweight graphics protocols (LBX [10]). Obviously either method of bandwidth reduction requires a sharing system which encodes and decodes at both sides of the connections and the inter host connections must be entirely under control of a distributed sharing system discussed in chapter 2.2.2.

The second approach is the exploitation of multicast connections if available from the transport system. However most graphics protocols are not suitable for multicast. They are designed with a one to one relation between application and terminal in mind, leading to resource identifiers (e.g. for colors, fonts, pixel maps) and sequence numbers different from one terminal to the other. Therefore multicast requires some mapping on each side of the connection. In other words multicast is only feasible in a distributed sharing system.


Figure 7: Transmission optimized arrangement: Encapsulation of shared applications. Intermediate redirection and conversion components hide the target application's graphics system from the multiplexing component.

Distributed sharing systems typically focus on optimal transport of a single, common graphics protocol. Graphic systems conversions are located between redirector and multiplexor. They encapsulate the shared applications to make them appear to the multiplexing system as if they were running the proper graphics protocol (figure 7).

<-- Reference Models
<-- The Distribution of Conversion and Multiplexing
<-- Table of Contents

4.1.2 Conversion Optimized Component Localisation

Conversion between graphics protocols requires complete decoding and analysis of the data stream. The subsequent reencoding into a different representation offers the opportunity to support the capabilities of the target terminal as efficiently as possible. Terminal specific capabilities include parameters like pixel depth, available fonts and memory of the terminal software. A conversion oriented distribution strategy will optimize for the capabilities of the individual terminals. It will present graphics output in different qualities depending on the individual capabilities of each terminal. This is done by separately reencoding the individual data streams for the different terminals. Clearly such a graphics stream converter needs information about each connected terminal. An arrangement with direct connections between graphics stream converter and terminals is best suited for this purpose. In this case the multiplexing component of the sharing system is located between redirector and converter (figure 8).


Figure 8: Local multiplexing of graphics data streams to several translator instances, which directly connect to remote terminals.

Sharing of network unaware graphics systems in this sequence (redirection, multiplexing, conversion) requires a centralized sharing system in the sense of chapter 2.2.1. Otherwise the system would have to perform two conversions, first from the network unaware representation to a network aware, common format and second from the common representation to the protocols understood by the terminals.

<-- Reference Models
<-- The Distribution of Conversion and Multiplexing
<-- Table of Contents

4.2 Two Implementations

We implemented two different concepts of a heterogeneous sharing system. A distributed system which focuses on cost effective transmission (chapters 2.2.1 and 4.1.1) and a centralized system. The centralized system is designed for individual treatment of all terminals and best presentation results (chapters 2.2.2 and 4.1.2). The components described in chapter 4 have been implemented: redirectors for the graphics systems Quickdraw and X and a converter between Quickdraw (a network unaware graphics system) and the X protocol (called QuiX). Redirector and converter are used in both scenarios while the multiplexor is different. It has been implemented in two versions. One is a distributed X sharing system [7], the other is a one-to-many multiplexor of Quickdraw graphics device driver primitives.

Both systems have advantages and disadvantages. Either of them performs better in the areas it is designed for. The distributed system uses a modified X protocol which allows multicast connections to carry the main data stream from application to terminal. This eliminates a large part of network traffic if multicast is supported by the network hardware. It also reduces processing load on the source system. The currently used protocol has been adapted to multicast but not further enhanced. More performance gains can be achieved by additional compression within the X protocol sharing system as described in chapter 4.1.1.

In some cases the conversion optimized strategy (multipoint QuiX) presents application output with better fidelity than the transmission optimized system. The presentation will be better on a true color terminal than on terminals with lower bit depths and it will use the best matching font for each terminal. Regarding to colors it may even be better than the local presentation. The tradeoff is a larger system and network load because application output has to be converted and transferred for each terminal individually. Clever use of the techniques described in 3.2.3 reduces the processing load considerably.

The centralized variant of the conversion optimized system is easier to develop and to maintain in comparison to the distributed system. This is mainly due to additional complexity of the systems' multiplexing components. The distributed version is more complex because the X protocol is not really suited for application sharing [1].

<-- The Distribution of Conversion and Multiplexing
<-- Table of Contents

5. Summary and Further Work

We presented concepts and implementations for application sharing in heterogeneous environments. Implementations have proven the validity of the concepts. The systems are currently in use in the frame of two CSCW projects (Berkom MMC [2] and CIO JVTOS [6]). They enable collaborative work with standard, single-user multimedia applications over heterogeneous networks.

Compatibility with existing applications is a moving target. Redirection of application output to terminals requires constant testing and maintenance in order to support a wide range of sometimes not so well behaved applications. Furthermore we are currently working on redirector and converter modules for the MS Windows graphics system.

Another interesting item is encryption. Application sharing using standard graphics protocols is very easily intercepted and observed. Encryption of graphics protocol data flow between hosts is one possibility to protect business secrets in commercial application scenarios. The distributed version of the sharing system is well suited for this task.

<-- Table of Contents

References

[1]
H. Abdel-Wahab, K. Jeffay: Issues, Problems and Solutions in Sharing X Clients on Multiple Displays, Technical Report TR92-043, University of North Carolina, Chapel Hill, 1992.
[2]
M. Altenhofen, J. Dittrich, R. Hammerschmidt, T. Käppner, C. Kruschel, A. Kückes, T. Steinig: The BERKOM Multimedia Collaboration Service. Proceedings First ACM International Conference on Multimedia, Anaheim, 1993.
[3]
J. Baldeschwieler, T. Gutekunst, B. Plattner: A Survey of X Protocol Multiplexors; in: Computer Communication Review, Vol. 23, Nr. 2, ACM Press, 1993.
[4]
G. Chung: Accommodating Latecomers in a System for Synchronous Collaboration, Master Thesis, University of North Carolina, Chapel Hill, 1992.
[5]
T. Crowley, P. Milazzo, E. Baker, H. Forsdick, R. Tomlinson: MMConf: An Infrastructure for Building Shared Multimedia Applications; Proceedings CSCW'90, Los Angeles, 1990.
[6]
G. Dermler, K. Froitzheim: JVTOS - A Reference Model for a New Multimedia Service; 4th IFIP Conference on High Performance Networking (hpn 92). Liège, 1992.
[7]
T. Gutekunst, D. Bauer, G.Caronni, Hasan, B. Plattner, "A distributed and Policy-Free General Purpose Shared Window System", IEEE/ACM Transactions on Networking, Hannes P. Lubich (Ed.), Februar 1995.
[8]
T. Gutekunst, B. Plattner: Sharing Multimedia Applications Among Heterogeneous Workstations; Proceedings, Second International Conference on Broadband Islands. Edited by O. Spaniol, F. Williams. Athens, 1993.
[9]
A. Nye: X Protocol Reference Manual; O'Reilly & Associates, Sebastpol, 1992.
[10]
K. Packard: Designing LBX; 8th Annual X Technical Conference, Boston, MA, 1994.
<-- Table of Contents