Da CaPo++ — A Flexible Middleware for Multimedia Communications

Distributed multimedia applications require a variety of communication services. These services and different application requirements have to be provided and supported

1. within end-systems in an efficient and integrated manner, combining the precise specification of Quality-of-Service (QoS) requirements, application interfaces, multicast support, and security features, and
2. within the network.

Design

Protocols determine the middleware's view of application flows. Flows are split into two data paths for the forward (data and control) and backward (feedback) direction. User data transfer only occurs in one direction (forward path), where resource reservation based on the requirements may be applied. The backward path is used for control information only (e.g., acknowledgments, quality feedback), which encompasses usually small amounts of data. Thus, flows are uni-directional from an application point of view, but they are bi-directional for control.

Although the session hierarchy may suggest that there is a lot of hierarchical overhead involved, this overhead is negligible for protocol processing. A limited amount of overhead occurs at session setup and almost no penalties are to be paid at run-time, where all protocols' selected module instances are directly accessed, making the layering a conceptual tool only. The deep hierarchy was chosen to provide modularity, functionality, and to simplify construction of applications out of building blocks.

In each data path, data is transported by an algorithm called Lift, an active transport mechanism, originally developed in a first version in the predecessor project Da CaPo (without the ++). Once started, the Lift works autonomously calling in turn modules' processing functions, according to the sequence set out at protocol configuration time. The Lift goes on to transfer data from the network to the user or vice versa, until it receives new instructions from the application or one of the modules it passes by. The Lift passes a packet along all modules within a protocol and each module performs appropriate changes and may request the Lift to pause, bring another packet, or discard the packet. The independence of the Lift—every Lift responsible for a single protocol runs in a separate thread—frees other system parts from duties. It also makes a protocol easy to trace and schedule and would allow for easy implementation of real-time constraints.

Compared to most other flexible protocol architectures, this scheme does not cause each module to be stacked on top of each other on the function call stack, possibly requiring a large stack for local variables. Compared to traditional stacking architectures, after a module returns the control back to the Lift, only minimal module state is present, making this an ideal point for efficient context switching. An additional advantage is that module implementation can be simplified. They do not need to care for special cases, such as errors returned from called modules. Instead, the Lift determines the decision-making mechanism. To relieve the programmer from a burden, generally, a module's handler function will be called. This is achieved by requesting a module for its requirements at protocol set-up time. Knowing all the requirements in advance enables for further optimizations. This approach eases configuration changes, since there is only one location knowing about the protocol chaining.

Application Composition

As control mechanisms and user interfaces for different data and connection types may be reused in different applications, a three-level application framework has been defined and is depicted on the right.

It is per se independent of Da CaPo++ and can be applied to all sorts of applications.

1. The application component level comprises atomic units providing a well-defined functionality, e.g., the display of video data. In Da CaPo++, this will generally be handled directly by the core.
2. An application consists of one or more application components and offers a single, homogeneous functionality being provided in close cooperation by the application components. E.g., a picture phone determines an application in this sense.
3. An application scenario in turn handles a fully specified task within a real-world scenario in its entirety. It consists of one or more applications being logically structured. As the application and application scenario level often cannot be separated clearly, a picture phone can be used as part of, e.g., a telebanking scenario (application) or as a simple picture phone (application scenario).

Publications

Earlier information can be found on the Da CaPo++ project management site.

Participants

• Daniel Bauer
• Germano Caronni
• Christina Class
• Christian Conrad
• Julia Fominaya
• Bernhard Plattner
• Erich Rütsche
• Markus Soland
• Burkhard Stiller
• Martin Vogt
• Marcel Waldvogel