The Mash archive system provides a set of archive tools which are compatible with the MBone collaboration tools, including vic, vat and mb. Implemented using the Mash code base, it records and plays (multicast or unicast) both RTP (audio and video) and SRM (whiteboard) data. The system is implemented as a number of independent but interrelated units. The Mash archive tools include a stand-alone recorder and player, and a client-server playback system. In this documentation, we will cover the software architecture of the system, and how to run and use the components of the system.
The Mash archive system has been designed as a collaboration archive, which records and plays not movies or television programs, but distributed collaborations. Distributed collaborations differ from passive programming in that there are multiple participants, producing multiple streams to play and record. These participants may have heterogeneous connectivity and processing capabilities, so the system should support transcoders and proxies. Participants may interact using a variety of tools, with a variety of data formats. In addition, at this stage in technology development, collaboration tools are under constant development and modification. As a result, the archive system must be easy to modify. Since modifications may introduce bugs, the system must be fault-tolerant, not just of hardware and network faults, but also of software faults.
Two independent tools, the Mash player and the Mash recorder, are intended for locally controlled playback and recording, and provide a rich user interface. Since playback is in the RTP or SRM protocols, the Mash MBone tools (vic, vat, mb) may be used for viewing playback as well as live data. The Mash recorder accepts an SDP announcement or a set of multicast addresses and records the data in the file formats described above. The Mash player accepts a catalog file or the specification of a number of individual data files. The user also specifies a set of multicast addresses for playback. Standard playback functionality of random access and pause is also implemented. More information is available on the Mash player and Mash recorder and the file formats used.
The Mash Archive Server (MARS) reads the same file formats as the Mash player, but accepts remote requests from clients for playback. Used in conjunction with the AS1 framework (described below) the MARS server is a distributed, fault tolerant archive server. Servers are implemented as a cluster of machines which listen on a shared multicast address. The playback service is implemented as a soft state service, with periodic refresh of playback information. This allows individual server component machines to seamlessly assume the playback responsibilities of a failed machine.
Clients connect to the MARS server by first downloading a mashlet file for the session they wish to view. This file may be accessed from a separate web server (for example MARS Pathfinder). This mashlet contains contact information for the server, information about the playback session, and a Mash application stub. Executing this stub with the included parameters will launch a customized playback client. This client multicasts requests for playback to the server cluster. A server component machine will respond and begin multicasting (or unicasting) the requested data. Clients may seek or pause playback. The figure below shows a screen shot of one MARS client playback application, Collaborator.
MARS is implemented using the AS1 active service framework. The AS1 framework, developed by Elan Amir, provides a fault-tolerant, distributed platform for implementing location-independent services (services which are not tied to a particular network address). The basic system architecture of AS1 as used with MARS is shown in the figure below. A server is constructed out of a number of server component machines, all listening to a single multicast address. Each component machine runs a host manager (HM) process. This process is responsible for listening to control traffic and launching AS1 service agents, such as MARS, when needed. If a service agent stops responding before a session has finished, a new agent will be launched on another component machine. The AS1 system also allows the set of member host machines to be completely fluid. The entire service can migrate to a new set of component machines within a very short time period. In our MARS service, the component machines are on the same local network, and have access to the same disk system. For more information on AS1, see [1].
Other AS1 service agents include the media gateway service (MeGa), which transcodes video and audio, for example, into a lower bandwidth or a different format. Service agents can be chained together to operate on a stream of data. For example, in the figure above, the MARS agent streams data from disk, and the MeGa agent transcodes that data into the requested format. For more information on the MARS archive agent and the communication protocol between the playback client and MARS, see [2].
The MARS archive service is available for download in compiled form and as source code. This is a research prototype which is currently under development, and, as such, may not be completely bug free. Please report problems and suggestions to openmash-developers@www.openmash.org
The MARS server can be run on a single machine, but for fault-tolerance, it is recommended that several machines, all with access to the archive data, be used.
To run AS1 and MARS on a single machine:
Now, when clients (such as collaborator) send requests on the megaCtrl address, the host manager will launch the requested services. When the client stops requesting the service, the service agent will shut down. The host manager (hm)must be running for service requests to be processed.
When multiple machines are a part of the AS1 cluster, host managers are automatically started and restarted on the component machines. provides an additional level of fault tolerance for the system.
To run AS1 on multiple machines:
This host manager will gradually launch host managers on the other machines in the pool. When a client request arrives, one of the host managers will launch the requested servent. When the client stops requesting the service, the service agent will shut down. If one of the host managers crashes, another host manager will be launched in the pool, too keep the total number of host managers at the target.
The monitor also provides a mechanism for killing service agents and host managers.
More information on the components of the AS1 system is also available in the Mash man pages.
The Pathfinder application, written using the Mash shell, is an automatic web-page generator which allows easy web-based use of Mash applications. Pathfinder can dynamically generate a list of archived sessions, and serve the catalog files necessary for client playback. Pathfinder can also build an sdr style listing of live sessions, and be used to launch client viewing applications. Pathfinder is not a requirement for MARS operation, archive access can also be facilitated through static web pages. A man page for Pathfinder gives more details.