Horus and Multi-Media

Advances in network technology make it possible for applications to present their functionality in a mixture of media like text, graphics, audio and video. A number of advances have been made in how to deal with the media distribution and dissemination aspects of multi-media systems, but as these applications are, conceptually, distributed, they benefit from using the distribution framework that Horus offers. In many cases, a large part of the complexity of a multi-media application is devoted to distributed control and collaboration mechanisms.

The Berkeley Video-On-Demand [5] service, for example, is able to greatly enhance its reliability in both availability and predictability by moving its media transport system into Horus and replacing its TCL/DP-based control mechanism with some of the basic Horus blocks. We are converting this system to use Horus for all its distributed activities and it is one of the systems that we use for experiments in the NYNET NY-state-wide ATM environment. The Video-On-Demand system was built using the CM toolkit, which consists of a set of libraries implemented in C and TCL/DP. The system has three distinct parts:

1. a collection of file servers that store video and audio data. The data can be striped over several servers by storing segments of a movie at different servers.
2. a display server, responsible for receiving the data that comes from the file servers and displaying using the X-windows shared memory extensions.
3. a VCR-style control application (cmplayer), controlling the flow of data from the file servers to the display server.

Using cmplayer, the user selects a movie from a configuration data base. The application will then, based on the configuration for that movie, request a data stream to be started between the display server and the file server that has the starting segment. When the segment is finished, cmplayer will ensure that the server with the next movie segment will start transmitting. The user has regular VCR controls to manipulate the data stream, and can control display speed and direction with a fine granularity. The control mechanism uses a logical time stamp (lts) mechanism, which is implemented as a TCL/DP distributed object.

Although the original system works, it needs improvements to the robustness and system control and management functionality. Progress in these areas has stalled because of the lack of an integrated approach to the distributed aspects of the system. By porting the system to Horus it is possible to make several of these improvements:

• Integrated management of the system resources (memory, message, CPU, timing and network) to ensure higher predictability of the operation environment. The facilities offered by Horus make it possible for the media transport protocol (Cyclic UDP [6]), the distributed control protocol (LTS), and the data compression modules to reserve resources to ensure proper operation, without other activities interfering.
• The implementation of the TCL/DP Distributed Object is rudimentary, slow and prone to failures. Each Object uses a single site to which updates are sent, and which then disseminates the new data over several TCP channels to the other system components that share the Object. Horus provides a large set of group communication facilities that are much more suitable to implement distributed objects and operations. Horus is able to send updates to a distributed object at very high speed (more than 10,000 per second), and is able to maintain of consistent state of the object even if participants or their connectivity fail.
• In the original implementation, the cmplayer needs to know which file server hold which segments. By restructuring the file servers using Horus, it is possible to make the location of the segments transparent to the clients. After a movie has been selected, the file servers that hold the movie segments form a group representing that movie to the client application. All requests for transmission (using the LTS) are being made to the group which then internally decides which server should send the data. Horus has the facilities to implement this structure in a way that will induce a minimum of overhead.
• High availability. To ensure that the movie segments are available even if a server becomes inactive, replication of the movie segments is needed. Horus provides protocols that implement replication control and transparent server switching if one of the segment holders fails.
• Load-balancing. Replication is not only needed to implement a level of fault-tolerance but also to enable high numbers of clients accessing the servers. Decisions about which server will send the next segment of the movie can be made based on the number of current connections, geographical location, and network capacity. The client/server protocols supported by Horus allow us to build these schemes in a transparent fashion.

We are reaching the point where we can demonstrate this integrated functionality, and plan to make the resulting software available early in 1995.