Design and Implementation

Dc and the service processes are implemented as Mash applications. Mash is a multimedia toolkit for developing distributed collaboration applications [13]. It provides the basic objects needed to create multicast applications (e.g., media stream receivers/transmitters, media codecs, etc). Mash is a split architecture software system. Routines that are performance sensitive (e.g., media coding and decoding, network transmitting and receiving, etc.) are implemented in C++. User-interface abstractions and performance insensitive code is implemented in the Tcl/Tk scripting language. Mash also uses the Object Tcl (Otcl) extension for object-oriented programming.

Dc and the service programs make extensive use of the following packages written in Mash:

• Active Service Framework.
  The AS framework provides a programmable substrate on which to build arbitrary network services [1]. These services reside in one or more pools of active service nodes. Client applications instantiate service agents on one or more nodes. The framework ensures fault-tolerance and load-balancing for clients. The replayproxy and specialfxproxy services use the AS framework to instantiate MARS and PSVP system services, respectively.
• Scalable Naming and Announcement Protocol.
  SNAP is a framework for selective reliable multicast. It provides a hierarchical naming system and a scalable session announcement protocol [16]. The SDS service uses SNAP to deliver reliable messages between clients, services, and SDS servers for the service architecture. In addition, SNAP provides containers for messages. Container names are organized into a hierarchical name space. Clients connect to a SNAP multicast and session register callback procedures for containers when a message is transmitted to that container. This facility supports a general-purpose filtering mechanism for messages sent to a multicast session. The webcasting service architecture uses UPDATE, QUERY_REQUEST, and QUERY_RESPONSE SNAP containers for service announcements, client queries, and SDS service query results, respectively.

  

Figure: Dc Architecture.

The internal architecture of dc is shown in figure 9. A network agent receives packets from the video studio session and demultiplexes them to a handler for each stream. A stream may be displayed in one or more windows and, if it is in the broadcast set, the packets are sent to the multicast session for the broadcast. A stream is always displayed in a thumbnail so the packets must be decoded and rendered to a thumbnail window. If the stream is also being displayed through one or more video windows, the decoded packets are passed to additional renderers for each window. Packets for streams selected for broadcast are duplicated before they are passed to the decoder. The duplicate packets are sent to the broadcast session.

The dc application is approximately 2,800 lines of code, which includes 430 lines of C++ and 2,400 lines of Tcl/Tk code. C++ is used to duplicate packet buffers for broadcast and relay them to the transmitter. The breakdown of the Tcl/Tk code is shown in table 2. The code length does not include inherited objects and consequently may appear skewed. For example, the agent-broadcast object inherits transmission functionality from the MASH video-agent object. So even though dc only shows 48 lines of code, video-agent includes over 1,000 lines of code.

 

Table: Table listing dc code. Each object name is followed with code length and a summary of its function.

Name	Lines	Functionality
agent-broadcast	48	Network agent transmitting to the broadcast session.
agent-studio	119	Network agent responsible for receiving packets from the studio session and demultiplexing the packets into its constituent streams.
application-dc	224	Application object responsible for creating and organizing other objects in the dc .
session-dc	129	Objects used to discover services.
ui-dc	118	The main window object of dc. Creates the panel objects that reside within it.
ui-dcbroadcast	212	Object responsible for broadcast panel.
ui-dcpreview	177	Object responsible for preview panel.
ui-dcthumbnail	475	Object responsible for thumbnail panel. It is responsible for new services.
ui-dcthunbnailservice	284	Control service objects.
ui-dcthunbnailvideo	89	Media service objects.
ui-dcvideo	248	Video Window Object.
dc-link	324	RMI mechanism used to send commands between dc and services.

Services are implemented only with Tcl/Tk code. Table 1 above shows the number of lines for each service. The null_service shows the code needed by all services. It contains code to interface with the SDS service and clients but has no functionality. The proxy services act as intermediaries between clients and backend servers which explains why replayproxy can be written in only 612 lines. The majority of the replayproxy service is in the MARS backend process. This example shows the power of Tcl/Tk as a ``glue language" for building interfaces between disparate applications.