Middleware support for distributed multimedia and collaborative computing

Abstract

Maestro is a middleware support tool for distributed multimedia and collaborative computing applications. These applications share a common need for managing multiple subgroups while providing possibly different quality-of-service guarantees for each of these groups. Maestro's functionality maps well into these requirements, and can significantly shorten the development time of such applications. In this paper, we report on Maestro, and demonstrate its utility in implementing several multimedia and collaborative computing applications. In particular, we provide a detailed description of the implementation of IMUX, a pseudo X-server (proxy) for collaborative computing applications that is based on Maestro.tools. In a video conference session, there can be a situation in which participants are connected by a WAN, but subsets of the participants may share the same LAN. Different subsets of the participants in a video conference may require different quality video streams, depending on their locale and equipment. We would probably want to use a video coding scheme similar to that used in earlier work [2][3][4]. Here, one stack is used for low quality frames, which should be delivered to all participants, while another is used for higher quality frames, and delivered only to participants running on nodes that are connected through high bandwidth links to the video sender. In addition, audio data should be delivered in FIFO order, but does not need stronger end-to-end reliability. Indeed, an attempt to overcome infrequent packet loss through a TCP-style flow control and acknowledgement mechanism might introduce undesired latency jitters and hence reduce the perceived reliability of the audio channel. On the other hand, text in the chat area should be delivered reliably and all participants should see postings in the same order.One can also imagine configurations in which subsets of participants would maintain their own private chat groups or side-band conferencing sessions. Such a feature might be useful, for example, in a business negotiation that brings together multiple representatives of one organization in the context of a larger group of participants.Application-sharing systems also demonstrate the need for multiple data streams with independent membership. For example, application multiplexors in the X Windows environment are typically implemented by interposing a 'pseudo-server' between clients and servers. The pseudo-server assumes the role of an X server when interacting with X clients and the role of an X client when interacting with an X server. When input operations are restricted to a single host, an X pseudo-server provides 'output multiplexing', allowing the output of a single application to be viewed simultaneously on multiple screens [6]. An alternate approach called 'input multiplexing' [7,8] replicates the client and employs a simplified pseudo-server. Output operations are passed to the local X server while input operations are multiplexed and communicated to remote replicas via the pseudo-server. ...

Group communication specifications

“…For example, in RMP, the unreliable QoS level provides the guarantees of the underlying communication. Similarly, the MMTS extends Transis by providing a framework for synchronization of messages with different QoS properties; Maestro [Birman et al 1998] extends Ensemble by coordinating several protocol stacks with different QoS guarantees, and the collaborative computing transport layer (CCTL) ] implements similar concepts, geared towards distributed collaborative multimedia applications.…”

“…More recently, GCSs have been exploited for collaborative computing (see Chockler et al [1996], Rhee et al [1997], Birman et al [1998], and Anker et al [1997]), for example, distance learning (see Al-Shaer et al [1997]), drawing on a shared whiteboard (see Shamir [1996]), video and audio conferences (see Chodrow et al [1997] and Valenci [1998]), application sharing (see Krantz et al [1998Krantz et al [ , 1997), and even distributed musical "jam sessions" over a network [Gang et al 1997]. …”

Groups Partitioning Over CORBA for Cooperative Work

“…In each group, one member plays a particular role. It is referred to as a leader [10], manager [31], Interlevel Contact Point [65], or coordinator [21], and is responsible for managing the communication between groups or levels, receiving information and sending it to other members, and supervising internal group organization. The notion of hierarchy is very important in this concept since it allows us to order the various elements of a group.…”

Moshe

“…Light-weight group membership services (for example, [Dolev and Malkhi 1996;Amir and Stanton 1998;Powell 1991;Glade et al 1993;Rodrigues et al 1996;Birman et al 1998]) employ a client-server approach to both virtual synchrony and membership maintenance. In these algorithms, there are two levels of membership, heavy-weight and light-weight.…”