|
|
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
- 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
- within the network.
The Da CaPo++ system provides an efficient
end-system middleware for multimedia applications, capable of handling
various types of applications in a modular fashion. Application needs
and communication demands are specified by values in terms of QoS
attributes and functional properties, such as encryption requirements
or multicast support. Da CaPo++ automatically configures suitable
communication protocols, provides for an efficient run-time support,
and offers an easy-to-use, object-oriented application programming
interface. While its applicability to real-life applications was shown
by prototype implementations, performance evaluations have been
carried out yielding practical experiences and numerical results.
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.
- 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.
- 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.
- 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
|