A Component-Based Architecture for Scalable

1 downloads 0 Views 327KB Size Report
algorithms, access control lists, costs, list of currently connected users, etc.). A major ..... Brian W. Kroeger and Paul J. Peyla. Robust IBOC DAB AM and ... MPFL97] Joan L. Mitchell, William B. Pennebaker, Chad E. Fogg, and Didier J. LeGall.
A Component-Based Architecture for Scalable Distributed Multimedia Fabio Kon

Roy H. Campbell

ff-kon,[email protected]

Department of Computer Science University of Illinois at Urbana-Champaign

See-Mong Tan Miguel Valdez Zhigang Chen Jim Wong fstan,miguel,zchen,[email protected]

Vosaic Laboratories { Urbana, IL

Abstract

Digital video and audio multimedia systems will rapidly take the place of existing analog systems in the next millennium's radio and television broadcasts. Current initiatives in digital radio will soon provide near-CD quality radio channels in many countries. However, due to the very nature of their broadcasting architecture, user interactivity and exibility is limited. We demonstrate an architecture for capturing, distributing, and displaying digital multimedia content through existing Internet and intranet infrastructures using personal computers. Our solution is much more exible than previous systems, increases the degree of interactivity between the user and the broadcasting system, and opens a new range of possibilities not o ered before. The distribution infrastructure supports both live and stored data and enables a exible combination of di erent policies and mechanisms. A component-based architecture for the development of customized multimedia clients and servers facilitates software maintenance and updates as application requirements evolve. Moreover, it promotes a large degree of code reuse. Initial experiments with the world-wide broadcast of NASA's JPL Path nder mission delivered more than one million live video streams to dozens of countries across the planet.

1 Introduction The evolution of existing television and radio broadcasting systems leads to the desire to store and manipulate video, audio, text, and graphics in a digital form. Digital data o ers a high degree of exibility for data storage, transport, and processing. It also guarantees minimal quality degradation while performing these operations. Our research seeks to build a set of software components for creating scalable distributed multimedia applications especially tailored to evolving user requirements. These components are highly exible, extensible and, at the same time, easy to maintain and update. The evolution of computer hardware and recent research results in multimedia algorithms allow the capture and display of video and audio with quality comparable to existing analog standards. The MPEG2 video standard [MPFL97] can support High-De nition Television (HDTV) with a resolution of up to 1920  1152 pixels at 60 frames per second with data rates between 15 and 80Mbps. Conventional TV quality can be achieved at data rates around 3 to 6Mbps. High-quality digital audio is already a commonplace in home audio systems. DVD technology permits the storage of multiple high-quality videos on a small disk and will probably replace analog VCR's in the near future. Digital radio will soon be available. Stereo music with quality close to that o ered by audio CD's can be achieved at 96 kbps, and stereo FM-like quality at 48 kbps [CSSZ96]. Also, a technique called IBOC [KP96]  Fabio

Kon is supported in part by a grant from CAPES, the Brazilian Research Agency, proc.# 1405/95-2.

enables digital radio broadcasting within the currently allocated channel masks. Therefore, broadcasters can simultaneously transmit both analog and digital signals allowing full compatibility with existing analog receivers. Networks of geostationary satellites will be established to provide continental broadcasting of hundreds of CD-quality radio channels, including separate data sub-channels carrying other types of information (e.g., text, gures, HTML pages, etc.). However, these systems will require that users buy special digital receivers. The initial cost of a compatible receiver is estimated to be at least 25 to 50% higher than the price of comparable analog receivers. DirectTV currently supports live broadcasts of compressed and encrypted video streams. More than 175 channels are streamed from a network of geostationary satellites to small, individual satellite dishes. These approaches present serious limitations as they do not leave room for user interaction. Since potentially hundreds of millions of users can be tuned in, a broadcaster cannot receive messages from its clients and modify its data stream according to requests received from each listener. Thus, a di erent solution is required in order to enable user interaction. A very limited solution adopted in some cases is to push textual data in a sub-channel and allow the user to browse through a limited number of text pages. A more powerful solution is required. In contrast, the major goal of our research is to provide an architecture for distributing digital multimedia content through the existing Internet and intranet infrastructures utilizing existing personal computers. Current MBone and point-to-point solutions do not provide the degree of control and the possibilities for QoS management that our system provides. The solution we demonstrate in this paper is much more exible than previous systems, improves the interactivity between the user and the broadcasting system, and is scalable. It opens a new range of possibilities not o ered before. Its exibility enables specially-customized combinations of policies for security, authentication, and accounting. Independent, pluggable components for capturing, encoding, and transporting video and audio in a wide variety of formats can be combined to build di erent applications. The system supports both live and stored content, one-way broadcasting, and multi-way conferencing. By allowing user interaction, a multimedia broadcaster can make a variety of adjustments and optimizations such as dynamically changing encoding algorithms and parameters to meet speci c hardware requirements, adapt the bit rate according to resource availability, multiplex audio streams, or even select di erent speech and subtitles tracks on multi-language videos. Scalability is achieved through a dynamic network of re ectors which can be remotely monitored and recon gured. Re ector managers can remotely inspect statistics about bandwidth utilization, user accesses, and accounting. Managers can also dynamically recon gure re ector policies and the distribution network topology. This technology was utilized in the live broadcast of NASA's JPL Path nder mission [GCE+ 97]. During this broadcast { which lasted for several months { more than one million live video sessions were delivered to dozens of di erent countries across the globe by a network of re ectors spread across ve continents. In the near future, we will experiment with other applications that will use this distribution architecture, including collaborative work and multimedia presentation systems. A related research project in our group is currently investigating operating system [CKB+ 98] and middleware [SSC97] support for our architecture.

1.1 Contents

Section 2 describes the overall system architecture and previous results. Section 3 describes our distribution framework which is composed by the Re ector (section 3.1), the Administration Panel (3.2), and the Directory Service (3.3). Section 4 describes our component-based approach for building multimedia servers (4.1) and clients (4.2). We then present experimental results in section 5 and discuss our ongoing and future work in section 6. Related work is discussed in section 7 and our conclusions are presented in section 8.

2 System Architecture Our architectural framework is divided into three applications with speci c functions: multimedia servers, multimedia clients, and distribution. Multimedia servers produce data for distribution by capturing video and audio using a hardware capture card, retrieving data from a persistent store, or dynamically generating data (e.g., a computer graphics animation, or a weather station generating weather data). Multimedia clients run on user workstations, receiving data from the distribution infrastructure and displaying it to the user. This involves decrypting, decoding, and rendering video and audio as well as other multimedia types of data. Note that some user applications, like a videoconferencing tool, actually work both as a client and a server. They locally capture, encode, and send data out at the same time they receive, decode, and display it. Distribution is achieved through a network of Re ectors distributed throughout a wide-area network. They are responsible for spreading the data through the network in an ecient way. An application called Administration Panel can remotely monitor and con gure a Re ector. A distributed database (or Directory Server) is responsible for storing information about users (name, e-mail, password, access rights, account balance, etc.) and about broadcast and conference channels (textual description, data format, encoding algorithms, access control lists, costs, list of currently connected users, etc.). A major requirement on the design of our distribution framework is that it should be able to carry data generated by any application and deliver it to any kind of client whose protocol is known. Thus, it can be used with multimedia applications developed by other research groups and companies. Section 4 describes some of the multimedia clients and servers we have developed as an example of such applications.

2.1 Previous Results

Previous work in our research group has led to the design and implementation of protocols and tools for delivering Multimedia data via the Internet [CTCL95, CTS+ 96] and over low bandwidth connections [TCC+ 96]. The Vosaic client was rst designed as an extension to the NCSA Mosaic Web browser. The server is a stand-alone application that can serve a large number of stored video clips to hundreds of simultaneous clients. The client implements the Video Datagram Protocol (VDP) [CTCL95]: it monitors network utilization and CPU congestion, and sends feed-back messages to the server which adapts the video stream by increasing or decreasing the video frame rate. Thus, the system can provide the best video quality without saturating the communication channel or the client CPU. Later, the Vosaic MediaClient was transformed into a plugin for commercial web browsers. Recently, we have released Java applets that can receive and decode streamed audio and video in several di erent encoding formats.

3 The Distribution Framework Observing the limitations in coverage, exibility, and manageability of the MBone [SRL96], we found that a number of extensions to the MBone model were required. In order to provide the large-scale distribution capabilities we were seeking, we developed a powerful and exible distribution framework composed of: (1) a Re ector which is responsible for distributing multimedia streams and communicating with clients, (2) a Directory Service responsible for storing information about multimedia channels and users, and (3) an Administration Panel used to monitor and control the distribution network. We now describe each of these components separately.

3.1 The Re ector

The Re ector is the key component of the distribution framework. It works as a relay, receiving input data packets from a list of trusted sources and forwarding these packets to other re ectors or to end-user clients. Data packets are arranged in logical groups called channels. Each channel has a unique system-wide identi cation number for internal system use and a string channel name for end-users. Every incoming data packet has a header eld that contains the ID of the channel with which the packet is associated. The re ector examines this eld and forwards the packet to clients and re ectors that are are supposed to receive data from this speci c channel. A re ector can currently handle up to 216 di erent channels, and each channel can contain multi-track data for di erent applications. This include video and audio conferencing, live high-bandwidth MPEG broadcasting with conventional TV quality, stored low-bandwidth H.263 video and GSM audio, HTML news, current stock values, etc. Moreover, clients and administration programs can connect to a re ector in order to get information about currently available channels, current load, bandwidth utilization, historical statistics, etc. The Re ector Network topology is determined by each Re ector's con guration. This information speci es input and output connections, access privileges, maximum allowed number of users, etc. and is stored in a database controlled by the Administration Panel (see section 3.2). Upon startup, a re ector connects to one of the directory servers and requests its own con guration information by providing its IP address and its local ID as the key for a database search. After receiving the search result, it sets up all speci ed connections and prepares to provide the requested service. Clients get information about available channels in a re ector by using the RTSP [SRL97] and SDP [HJ97] protocols. As described in 3.3, re ectors communicate with the Directory Service using the LDAP protocol. A secure alternative to these protocols will be supported by using Secure Sockets [EH95].

3.1.1 Internal Re ector Architecture

We are currently working on a new version of the re ector that is implemented as a highly portable, multithreaded application which will be working by the time of the conference1 . The main thread is responsible for listening for connection requests on a speci c port and for receiving and sending multimedia data. void Reflector::MainLoop() { for(;;) { if(ReceiveIncomingData()) { SendDataToClients(); SendDataToReflectors(); } CheckForNewRequests(); } }// MainLoop()

Figure 1: The re ector main loop The main thread's loop code is shown in gure 1. ReceiveIncomingData() veri es if a data packet was received and, if that was the case, parses its header to determine to which channel it belongs. SendDataToClients() and SendDataToReflectors() scan the list of recipients for that channel and send the packet by calling the Send() method in the Connection2 object associated with that recipient. CheckForNewRequests() veri es if a new connection request was received and, if one was, creates a new thread to handle it. This new thread then establishes a connection and communicates with its peer using an extension of the RTSP protocol. Requests may ask for the list of channels, the description of a particular channel (using SDP), the establishment of a connection to a speci c channel using a speci c protocol, current 1 2

The existing version of the re ector is similar but it is organized as a single-threaded application. The Connection class hierarchy is discussed in 3.1.2.

statistics such as the number of connected users, the current bandwidth for each channel, or even request a recon guration of the re ector by giving new values for its con guration parameters. Along with its request, the client speci es a principal name and password so the re ector can perform authentication and access control when appropriate.

3.1.2 Data Distribution Protocols

The logical concept of a network connection is captured by an abstract class named Connection that de nes the basic interface for all the kinds of network connections used by the Re ector. This abstract class implements some of its own methods but the majority of the connection-related code is implemented by its subclasses: TCPConnection, UDPConnection, MulticastConnection, UDPInputConnection, UDPOutputConnection, MulticastInputConnection, MulticastOutputConnection, etc. Section 3.1.3 describes the concept of connection streams used to implement high-level protocols such as HTTP, RTP, RTSP, etc. All control information and meta-data is sent through reliable TCP connections. When security is desirable, secure sockets are employed by subclassing from SecureConnection which is derived from Connection. The re ector currently supports input based on both the UDP and the IP-Multicast transport protocols. We also plan to extend it to support TCP and VDP-based input. Output connections can be based on UDP, IP-Multicast, or TCP, and we plan to add support for VDP, as well. In our initial broadcast experiments (see section 5), UDP \connections" were used between re ectors and TCP connections (sending HTTP streams) between re ectors and end-user clients. In our audioconferencing application, di erent protocols are chosen based on available network bandwidth, reliability, and rewall constraints. Most of the Re ector's code deals with objects of type Connection and is not aware of the Connection's underlying implementation. The actual connection type is speci ed when the connection is created and does not need to be known after that. For example, when the re ector receives a packet for a particular channel, it forwards this packet by calling the Send method for every connection in the list of recipients for that channel. Some of these connections might be UDPConnections, some might be TCPConnections, and others might be MulticastConnections, or VDPConnections. Di erent connection types implement the Send() method in di erent ways but the Re ector main loop code is not aware of those di erences. This approach allow programmers to create customized Connection types by providing their own implementation of the Open, Close, Bind, Connect, Send, and Receive methods in order to add specialized functionality.

3.1.3 Connection Streams

Higher-level protocols such as HTTP, RTP, or RTSP can be built on top of a network connection such as UDP, TCP, or IP-Multicast. They are abstracted by a ConnectionStream class whose instances have { as one of its member variables { a reference to a Connection object. An HTTPStream object, for example, has, as a member variable, a reference to a TCPConnection object. The HTTPStream class contains knowledge about the HTTP protocol. Its methods are capable of building and parsing HTTP headers and, if required, formatting the data to be transmitted. The same mechanism can be used to implement user-level protocols or application-speci c requirements. An AudioConferenceConnection object, for example, can automatically multiplex audio packets coming from di erent sources. This approach is roughly analogous to the Java API since, in this language, one can create a FileStream object from a File object or create a DataInputStream from a network Socket object.

3.1.4 Client Interaction

The system supports interaction between re ectors and its clients using customized connection streams. Interaction can occur both at connection startup and during data transfer. The basic connection stream implements an extended RTSP protocol [SRL97] and allows clients to receive information about broadcast and conference channels, conference participants, user information, etc. In addition, our architecture assumes that clients may need to send application-speci c requests which will be processed by customized connection streams running within the re ector. Thus, it is possible to

dynamically change the characteristics of multimedia streams based on interaction with clients. This feature could be used, for example, to select subtitles in a speci c language or even to request that the video bit rate be automatically decreased by selectively dropping frames.

3.1.5 Redundancy and Bandwidth Control

In order to provide fault-tolerance, we have implemented the re ector in such a way that it can accept input from several sources. It assumes one of them is the primary source and ignores the data coming from other sources. If any error in the connection with the primary source is detected or if this source remains silent for a pre-de ned period of time, the re ector automatically switches to the next source in its list. Figure 6 depicts a redundant Re ector network. In the current implementation, all redundant streams are always sent causing some bandwidth to be wasted. We are working in a new re ector-to-re ector protocol which will be used to activate and deactivate data streams so they are only sent when required. A bandwidth control subsystem is used to measure the bandwidth utilization and dynamically limit the number of users who can access a particular Re ector. The maximum available network bandwidth reported by the Re ector manager (or by the operating system QoS API if available) is never surpassed, avoiding the degradation of the service quality.

3.2 The Administration Panel

The distribution scheme is based upon a network of collaborating re ectors administered by a group of managers. Each manager is responsible for a disjoint part of the distribution network. Groups ranging from one to hundreds of re ectors are remotely con gured through an Administration Panel. In our initial implementation, this panel lets the re ector manager specify the con guration of each of the re ectors in his domain. At any time, the re ector manager could also request the reinitialization of a speci c re ector. Upon startup, a re ector connects to one of its con guration servers and downloads its con guration. In opposition to this pull model, our new implementation will adopt a push model [ZF97]. Every time the re ector manager commits a set of updates to the global con guration, the Administration Panel connects to the a ected re ectors and sends their new con guration parameters. These parameters are locally saved by each re ector in a persistent form so they can be recovered in case of machine failure. The Administration Panel can be used to specify input and output connections, list of users and machines allowed to dynamically establish new connections, maximum number of users and maximum bandwidth per channel and per re ector, etc. It is also used to update information stored in the Directory Service (see section 3.3) such as the list of channels and their characteristics, list of users known to the system, etc. The communication between the Administration Panel and the re ectors will follow an extension to the SNMPv2 protocol [CMRW96] for network management. Re ectors will act as network agents that receive requests for updating their working parameters and requests for returning information about their current state. In case of exceptional behavior, a re ector may send trap noti cations back to the Administration Panel. One of the reasons for adopting a standard network management protocol was to be able to interact with existing network management applications for controlling and monitoring the re ector network. We intend to perform experiments with tools such as University of Twente's Scotty which allows the implementation of graphical network management software using a high-level API [SL95, Sch98].

3.3 The Directory Service

A Directory Service is responsible for storing information about the currently available channels. In addition, it will also be able to store information about individual users when ne-grain access control is desired. The Directory Service is implemented using the standard Lightweight Directory Access Protocol (LDAP) [YHK95] for communication between distributed databases and Re ectors. Each database { or, as we call it, directory server { stores a list of currently available channels and detailed information about them including

media format, encoding algorithms, estimated bandwidth, number of sessions served, current number of users receiving the channel stream, etc. Some channels may not be open to the general public. In this case, a list of users, or group of users, to whom access is permitted is also stored in the channel entry in the database. Also, the database contains a list of users who have special permissions to access certain channels. For each user, the database stores his or her real name, login name, password, and additional personal information such as e-mail, home page, phone number, etc. In the future, the Directory Service will also be able to store detailed information on per-user systemutilization. So, he or she will be automatically billed for accessing and using the service.

4 Component-Based Clients and Servers We have organized our code base as independent components which communicate among themselves using object-oriented interfaces. In the server, for instance, components for capturing, reading from disk, transforming, mixing, encoding, adding meta-data, and networking are combined to build a directed graph through which the information ows. We developed a generic component framework based on an abstract class that de nes how components communicate with each other. Arbitrary concrete components written in C++ or Java are created by deriving from the given abstract class. They are connected to form a directed graph. So, part of the graph can be implemented in Java and part of it in C++, a component does not need to be aware of which language was used to implement other components. The C++ and Java stubs used to perform the transitions between the two languages are created from the abstract component class only once. Therefore, they are part of the basic framework and do not need to be created every time a new component is written. As a matter of fact, programmers using this framework will never have to write any code to handle such transitions.

4.1 Capturing and Encoding

Components for capturing raw video and audio were implemented for di erent operating systems and hardware platforms, but all of them present the same external interface. Encoding components currently support a number of di erent schemes including MPEG-1, MPEG-2, and hardware and software H.263 for video, and GSM, half-rate GSM, G.723, MPEG, and AC-3 for audio3. Finally, networking components are plugged to the directed graph in order to send the data to the distribution network. Figure 4 shows our TVStation user interface. Alternatively, a component that reads data from the disk can be used to serve stored data on demand. It replaces the capturing and (possibly) encoding components and may connect directly to the networking components.

4.2 Decoding and Rendering

The same component-based code organization is found on the client side. Here, components are responsible for requesting and reading data from the distribution infrastructure, parsing meta-data, synchronizing packets, decoding, transforming, multiplexing, and nally, displaying multimedia data to the user. A special component for saving data to the disk can be inserted at any point of the client or server graph in order to store the data for later use. Figure 2 depicts the component directed graph for an audioconferencing tool. In the top, one can nd a representation of the data ow from the local microphone to the outside world and, in the bottom, the data

ow from an external encrypted GSM audio stream to the local speakers. Note that this component directed graph can vary dynamically depending upon the number of participants in a conference, the format of the data generated by each participant, etc. In our current implementation, this graph is composed of C++ objects generated on demand. When the user joins a multimedia 3

Current workstations are not yet capable of encoding MPEG streams in real-time, special hardware support is required.

1 0 0 1 0 1

Audio Capture

GSM Compressor

Application Protocol

Encryption

Network Protocol

Disk

Network Protocol

Application Protocol

GSM Decompressor

Decryption

Audio Output

Figure 2: An Audioconferencing Tool Component Graph channel, the client receives a description of the channel data format and dynamically creates the required C++ objects. When the session is over, the objects are destroyed and the resources allocated by them are released. Figure 3 shows how the component directed graph would look like after two additional audio streams were added to the session. It adds to the previous picture a non-encrypted MPEG audio stream and an encrypted G.723 audio stream. Decryption

Network Protocol

Application Protocol

GSM Decompressor

MPEG Decompressor

Decryption

Multiplexer

Audio Output

G.723 Decompressor

Figure 3: A Component Graph with Three Input Audio Streams

4.3 Java Applets Versus Native Code

Clients and servers implemented in C++ can encode, decode, and multiplex several simultaneous audio streams. However, such implementations exhibit two important disadvantages relative to equivalent Java versions. First, they are not as easily portable as Java code. Second, Java programs can take the form of applets which are automatically loaded by Internet browsers, facilitating code distribution and updates. Since our goal was to deliver multiple multimedia streams from a few broadcasting sources to millions of simultaneous clients, we have decided that, whenever possible, clients would be implemented as Java applets so no special installation procedure is required on the client computer. In order to free web servers from being overloaded serving multimedia applets, we will delegate the responsibility of serving the applets to Re ectors. This approach allows the use of specially-customized clients for each broadcast. The problem encountered when using Java applets is their lower performance. Even with just-in-time compilation, a Java applet tends to run several times slower than a native code implementation of the same program. However, we found that some codecs, such as H.263 and MPEG for video and GSM, G.723 and AC-3 for audio, allow for real-time decoding by a Java applet running on a 133MHz personal computer with just-in-time compilation. Using H.263 video and GSM audio, for example, one can obtain ten (176 by 144) frames per second and one 8kHz audio channel from a 53kbps bitstream.

Thus, even though encoding of multimedia streams by Java applets is very dicult with current technology, decoding can be done easily. Thus, we have made available Java applets that can display streamed audio and video in commodity personal computers as shown in gure 5. The same applets can be used to display stored video clips delivered by an HTTP server or to display live audio and video captured and encoded by inexpensive personal computers. We are now working with the Java Media Framework (JMF) [Sun97], which provides a Java interface for video and audio codecs implemented in native code or hardware. Using the JMF, it will be possible to implement the whole system using Java only.

Figure 4: The Vosaic TVStation

5 Experimental Results Our rst set of experiments were performed in March/April, 1997. At that time, we ran our TVStation software in three SPARCstations 20 using the SunVideo interface for video capturing and software H.263 for real-time encoding. These machines sent video showing a view from their rooms at three frames per second uninterrupted for about one month. Meanwhile, the machines continued to be used as personal workstations without problems. The video was sent to a group of re ectors to which users could connect by pointing their browsers to Web pages. A Java applet was automatically loaded and displayed live video comfortably even over standard phone lines. Besides the software H.263 encoder, which can produce ve (176 by 144) color frames per second on a 200MHz machine, we also utilize the Osprey-1000 hardware encoding card which can produce a higher frame rate with comparable image quality. This card can generate around 5 frames per second at 28kbps and

around 12 frames per second at 53kbps. The frame rate varies depending upon the images being encoded4 .

5.1 The JPL Mars Path nder Broadcast

Our technology was later chosen to broadcast, live over the Internet, the coverage of the NASA JPL Mars Path nder mission [GCE+ 97] that landed on Mars on July 4, 1997. A 133MHz Pentium-based PC with an H.263 Osprey encoding card served as the capture station at NASA's Jet Propulsion Laboratory. The data rate was set to 24kbps and contained 3 to 5 frames per second of H.263 video and half-rate GSM audio (see gure 5).

Figure 5: The TV Client Applet The broadcast was carried out by a distribution tree composed by more than 30 re ectors spread across ve continents. As shown in gure 6, Master re ectors received the data from the capturing station for4 High-quality video at 30 fps can be achieved using hardware MPEG-2 encoders which produce streams with bit rates on the order of Mbps.

warding it to primary re ectors across the globe. These would then forward the data to public re ectors which were associated with Web pages and accepted connections from end-user applets.

Master Reflector

Primary Reflector

Public Reflector

Public Reflector

Capture Station Primary Reflector

Public Reflector Primary Reflector Capture Station Master Reflector

. . .

Primary Reflector Public Reflector

Figure 6: A Redundant Re ector Network This scheme provided live audio and video to dozens of countries around the globe. Each of the re ector sites was capable of serving from 30 to 300 simultaneous clients depending upon the bandwidth of its connection to the Internet. This re ector network could potentially serve more than 3,000 simultaneous clients 24 hours a day. During the four initial days of the broadcast, the re ector network was able to deliver half a million multimedia streams. Within two weeks, usage climbed to more than one million video and audio sessions. After the rst few weeks, interest in the Path nder mission decreased, but our broadcast of NASA Select TV over the Internet continued for several months. It is worth mentioning that lack of experience with events of this magnitude led to some disastrous situations. The re ector was able to limit the number of clients that were allowed to connect to an speci c machine. However, we did not foresee that, at some of the public re ector sites, the web servers were not capable of limiting the number of simultaneous HTTP sessions they would allow. Thus, some sites that had agreed to serve up to 30 video sessions, ended up trying to service thousands of HTTP requests per minute. This unexpectedly large number of requests was responsible not only for making those sites' Internet connections unusable but also for congesting the local servers and impairing hundreds of local users. The solution was to shut down the web service and to install a new HTTP server that could limit the number of concurrent requests. This episode led to a redesign of the system that enabled the re ectors to serve client applets and limit the bandwidth spent on this task [KCT+ 98]. During the course of the broadcast, some recon guration of the network topology was required in order to accommodate our collaborators' requests. We had to redirect the streams to di erent primary re ectors

and often add or remove public re ectors. All these modi cations were performed remotely without stopping the transmission. We could even switch primary re ectors without a ecting the stream received by end-user clients.

5.2 System Potential

Note that the only bottleneck in the previous experiments was the bandwidth of Internet connections on the sites hosting Re ectors. During a di erent broadcast (featuring the Indy 500 race), a single re ector running on a Sun Ultra 2 was capable of serving between 700 and 800 simultaneous clients. This shows that a much larger number of users could be serviced if enough bandwidth were available. Experiments in our laboratory showed that a Re ector running on a Sun Ultra 2 with two 200MHz processors and 256MBytes of RAM requires less than 9% of one of the processors' time to stream a 24kbps video to 100 simultaneous clients using TCP over a 10Mbps Ethernet. In fact, the CPU utilization varies signi cantly. We believe that this is due to the adaptation performed by the TCP layer. During most of the time, the CPU utilization was below 1%. Assuming that unlimited network bandwidth were available, we could use the software technology described in this paper to build, for example, a network of 300 Re ectors running on 200MHz machines and serving 800 clients each, totaling 240,000 simultaneous clients. In this case, our problem would start to be the manageability of such a large number of re ectors from a single point5. Therefore, we have been concentrating our e orts on the development of a better management interface, which led to the design described in section 3.2.

6 Ongoing and Future Work Our group's experience with Internet Multimedia started in 1995 with the development of our pioneering Internet multimedia streaming technology. In the rst quarter of 1997, we performed our rst experiments with large-scale distribution infrastructures. Our ongoing research focuses on further developing our existing technology by (1) incorporating support for security (encryption and authentication), (2) improving the system's manageabilityby utilizing SNMPv2based graphical tools for network management, and (3) implementing a powerful LDAP-based Directory Service for storage and retrieval of channel and user information. We also intend to investigate the adaptation of applications such as collaborative work tools and multimedia presentation systems to work within our distribution infrastructure. A related research project in our group is currently investigating operating system [CKB+ 98] and middleware [SSC97] support for our architecture. In the future, we plan to enhance system exibility by introducing a mechanism for updating the re ector's executable code using the capsule technology [WGT98] developed by the mobile agent and active networking community. Programmers will be able to create customized Connection subtypes that can be dynamically loaded by the Re ector. Our approach will let the re ector manager send capsules containing dynamically loadable libraries or Java bytecode through the network in order to add new capabilities to the re ector network. Application-speci c code (e.g., a multiplexer for audio conferencing or a bid manager for distributed auctions) will be loaded dynamically into the re ector process, adding functionality to it. If desired, these modules will be unloaded and discarded when not in use anymore. Another issue we will address is automatic management of network topologies by adaptive protocols. We have developed an adaptive protocol for streaming video [CTCL95] to a xed client/server pair and we plan to incorporate it into the distribution framework. Further work is required to design and implement protocols for dynamically changing (1) the location of re ectors, (2) the data streams between re ectors, 5 In a real-world situation, the re ector network could be managed by di erent independent network administrators each one being responsible for 30 to 100 re ectors. However, in our experiments we never had more than one or two persons to manage the whole network.

and (3) the assignment of clients to re ector sites. The common goal of these protocols will be to minimize the load on the network while maximizing the quality of the service delivered to end-users.

7 Related Work Following the initial release of the Video Mosaic Internet browser in 1995, several commercial companies began work in this eld. At the moment, there are a number of di erent solutions for multimedia streaming and conferencing on the Internet. Although there are other re ector-like systems for multimedia distribution (e.g., White Pine's MeetingPoint [Hal97]), not much scienti c literature on this topic is available. MeetingPoint, the successor of White Pine's Re ector, is the system that share most similarities with the one described in this paper. It is mainly used for Internet videoconferencing and supports the H.323 standard. RealNetworks o ers the Real Broadcast Network as a service to its customers. Companies can lease RealNetworks' hardware and software infrastructure for a xed period of time and perform live broadcasts. We were not able to nd information about their system's architecture. The highly-competitive character of the Internet multimedia market precludes the distribution of technical information about these systems to the broader research community. With this paper, we expect to contribute to the collective understanding of issues related to the design and implementation of scalable multimedia distribution architectures. Our research bene ts from and builds on previous work on IP-Multicast [Dee89] and the Internet MBone [SRL96]. The MBone is a virtual network that is layered on top of the Internet to support routing of IPmulticast packets. It is composed of islands that can directly support IP-multicast (e.g., multicast LANs connected by multicast-capable routers), linked by virtual point-to-point links called tunnels.  Research in multimedia storage systems [ORS96] is orthogonal to and complements our work in the sense that it can be used for storing and retrieving data in the three modules of our system: servers, re ectors, and clients. The system described in this paper was not designed to provide video on demand on large scale. Further research is needed to understand the techniques which would have to be applied in order to serve, asynchronously, thousands of di erent videos to millions of clients on demand. Systems such as Tiger [BFD97] and Skyscraper [HS97] address this issue.

8 Conclusions We have presented a exible and extensible distribution framework for multimedia data. It scales well from a single client/server system to a network of re ectors capable of serving a potentially unlimited number of clients. The only limitations to the size of the system are the number of machines available to function as re ectors and the available network bandwidth. The support for di erent kinds of transport protocols including UDP, TCP, IP-Multicast and VDP gives the system manager extra tools for building an optimal distribution infrastructure. We have designed, implemented, and tested a set of reusable software components that can be combined to form customized clients and servers that meet speci c requirements. The use of Java applets greatly facilitates code distribution and updates. We expect this technology to in uence future large-scale broadcasting systems which are now limited in

exibility and interactivity by their current design. Wide-area conferencing systems are also supported by the same software infrastructure. We believe that Internet-based conferencing systems will incrementally replace the existing telephone system over the next few decades.

Acknowledgments The authors gratefully acknowledge the help provided by Charles Thompson, David Raila, and Drew MacGregor and all the support from Vosaic LLC.

References [BFD97] [CKB+ 98] [CMRW96] [CSSZ96]

[CTCL95] [CTS+ 96] [Dee89] [EH95] [GCE+ 97]

[Hal97] [HJ97] [HS97] [KCT+ 98]

William J. Bolosky, Robert P. Fitzgerald, and John R. Douceur. Distributed schedule management in the tiger video leserver. In Proceedings of the Sixteenth Symposium on Operating Systems Principles, Saint Malo, FR, October 1997. ACM. Roy H. Campbell, Fabio Kon, Francisco Ballesteros, Ashish Singhai, Dulcineia Carvalho, and Robert Moore. 2K: A Component-Based Network-Centric Operating System. Project home page: http://choices.cs.uiuc.edu/2K, 1998. J. Case, K. McCloghrie, M. Rose, and S. Waldbusser. Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2). RFC #1905, January 1996. R. L. Cupo, M. Sarraf, M. Shariat, and M. Zarrabizade. An OFDM All-Digital In-Band-OnChannel (IBOC) AM and FM Radio Solution Using the PAC Encoder. Technical report, Bell Laboratories, Lucent Technologies, Holmdel, NJ, 1996. Available at http://www.usadr.com/ tech_lucent910.shtml. Zhigang Chen, See-Mong Tan, Roy H. Campbell, and Yongcheng Li. Real Time Video and Audio in the World Wide Web. In Fourth International World Wide Web Conference, Boston, December 1995. Also published in World Wide Web Journal, Volume 1 No 1, January 1996. Z. Chen, S. M. Tan, A. Sane, Y. Li, R. Campbell, and D. Xie. Video and Audio: Organization and Retrieval in the WWW. White Paper, May 1996. Available at http://vosaic.com/corp/ papers/www5.html. S. Deering. Host Extensions for IP Multicasting. Network Working Group, IETF, August 1989. RFC 1112. Taher Elgamal and Kipp Hickman. The SSL Protocol (version 3). Internet Draft, September 1995. M. P. Golombek, R. A. Cook, T. Economou, W. M. Folkner, A. F. Haldemann, P. H. Kallemeyn, J. M. Knudsen, R. M. Manning, H. J. Moore, T. J. Parker, R. Rieder, J. T. Scho eld, P. H. Smith, and R. M. Vaughan. Overview of the Mars Path nder Mission and Assessment of Landing Site Predictions. Science, 278(5344):1734{42, December 1997. Andrew Hally. Meetingpoint: Bandwidth optimization technology. White paper available at http://www.wpine.com/mp/whitepaper.html, 1997. Mark Handley and Van Jacobson. SDP: Session Description Protocol. Internet Draft, September 1997. Kien A. Hua and Simon Sheu. Skyscraper Broadcasting: A New Broadcasting Scheme for Metropolitan Video-on-Demand Systems. In Computer Communication Review, volume 27, Cannes, France, October 1997. ACM SIGCOMM. Fabio Kon, Roy H. Campbell, See-Mong Tang, Miguel Valdez, Zhigang Chen, and Jim Wong. A scalable distribution framework for live and stored multimedia. Submitted to ACM Multimedia, 1998.

[KP96]

Brian W. Kroeger and Paul J. Peyla. Robust IBOC DAB AM and FM Technology for Digital Audio Broadcasting. Technical report, Westinghouse Wireless Solutions Co., Linthicum, MD, 1996. Available at http://www.usadr.com/tech_ibocdab.shtml. [MPFL97] Joan L. Mitchell, William B. Pennebaker, Chad E. Fogg, and Didier J. LeGall. MPEG Video Compression Standard. International Thomson Publishing, New York, NY, 1997.   [ORS96] B. Ozden, R. Rastogi, and A. Silberschatz. Disk Striping in Video Server Environments. In IEEE International Conference on Multimedia Computing and Systems, June 1996. [Sch98] Jurgen Schonwalder. Scotty - Tcl Extensions for Network Management Applications. Project home page: http://wwwsnmp.cs.utwente.nl/~schoenw/scotty, 1998. [SL95] Jurgen Schonwalder and H. Langendorfer. Tcl Extensions for Network Management Applications. In Proceedings of the 3rd Tcl/Tk Workshop, Toronto, July 1995. [SRL96] Kevin Savetz, Neil Randall, and Yves Lepage. MBone: multicasting tomorrow's Internet. IDG Books, Foster City, CA, 1996. [SRL97] H. Schulzrinne, A. Rao, and R. Lanphier. Real Time Streaming Protocol. Internet Draft, October 1997. [SSC97] Ashish Singhai, Aamod Sane, and Roy Campbell. Re ective ORBs: Support for robust, timecritical distribution. In Proceedings of the ECOOP'97 Workshop on Re ective Real-Time ObjectOriented Programming and Systems, volume (to appear) of Lecture Notes in Computer Science. Springer Verlag, June 1997. [Sun97] Sun Microsystems, Inc. Java Media Framework API. Project home page: http://java.sun. com/products/java-media/jmf, 1997. [TCC+ 96] S. Tan, R. Campbell, Z. Chen, W. Liao, D. K. Raila, F. Kon, and M. Valdez. Adaptation and Synchronization in Low-Bandwidth Internet Video. In World Wide Web Consortium Workshop on Real Time Multimedia and the Web (RTMW '96), INRIA Sophia Antipolis, France, October 1996. [WGT98] D. Wetherall, J. Guttag, and D. Tennenhous. ANTS: A Toolkit for Building and Dynamically Deploying Network Protocols. In IEEE OPENARCH'98, San Francisco, CA, April 1998. [YHK95] W. Yeong, T. Howes, and S. Kille. Lightweight Directory Access Protocol. RFC #1777, March 1995. [ZF97] Stanley Zdonik and Michael Franklin. A framework for scalable dissemination based systems. In Proceedings of the 12th Conference on Object-Oriented Programming, Systems, Languages, and Applications, Sigplan Notices:32(10), pages 94{105. ACM Sigplan, October 1997.