Offensive and defensive adaptation in distributed multimedia systems.

Full text

Page 1

ComSIS Vol. 1, No. 1, February 2004 45
Offensive and Defensive Adaptation in Distributed
Multimedia Systems♣ ♣
Roland Tusch
1
∗,
László Böszörményi
Hermann Hellwagner
1
, Balázs Goldschmidt
1
2
,
1
, Peter Schojer
1 Institute of Information Technology, Klagenfurt University, Klagenfurt, Austria
2 Department of Control Engineering and Information Technology, Budapest
University of Technology and Economics, Budapest, Hungary
Abstract. Adaptation in multimedia systems is usually restricted to
defensive, reactive media adaptation (often called stream-level
adaptation). We argue that offensive, proactive, system-level adaptation
deserves not less attention. If a distributed multimedia system cares for
overall, end-to-end quality of service then it should provide a meaningful
combination of both.
We introduce an adaptive multimedia server (ADMS) and a supporting
middleware which implement offensive adaptation based on a lean,
flexible architecture. The measured costs and benefits of the offensive
adaptation process are presented.
We introduce an intelligent video proxy (QBIX), which implements
defensive adaptation. The cost/benefit measurements of QBIX are
presented elsewhere [1].
We show the benefits of the integration of QBIX in ADMS. Offensive
adaptation is used to find an optimal, user-friendly configuration
dynamically for ADMS, and defensive adaptation is added to take usage
environment (network and terminal) constraints into account.

Key words: stream-level adaptation, server-level adaptation, MPEG-4,
MPEG-7, MPEG-21.

♣ This research project is funded in part by FWF (Fonds zur Förderung der wis-
senschaftlichen Forschung), under the projects P14788 and P14789, and KWF
(Kärntner Wirtschaftsförderungsfonds).

∗ Corresponding author. Tel.: +43/463/27003622. Fax: +43/463/27003699
Email addresses: roland@itec.uni-klu.ac.at (Roland Tusch), laszlo@itec.uni-klu.ac.at
(László Böszörményi), balage@inf.bme.hu (Balázs Goldschmidt), hellwagn@itec.uni-
klu.ac.at (Hermann Hellwagner), pschojer@itec.uni-klu.ac.at (Peter Schojer).

Page 2

46 ComSIS Vol. 1, No. 1, February 2004
1. Introduction
Adaptation is - in a general sense - the capability to respond to changes of the
environment by the change of some own characteristics, without losing the own
identity. If a living creature feels hungry, but sufficient food is not available, then
it has two choices for survival: Either it is able to enlarge the available food
resources, e.g. by moving to a better place, or to change its inner need and
learn to be satisfied with less or worse food. The first approach could be called
offensive, the second defensive adaptation. Obviously both have their limits
and have a common prerequisite: flexibility. (Our creature has to be flexible
either to go outside and find new places or to go inside and be satisfied with
less food - or to do both, if e.g. a new place can be found, which is, however,
still not sufficiently rich of food.) Offensive adaptation is usually proactive (it is
better to start to look for an opulent place before getting too hungry), whereas
defensive adaptation is usually reactive (if there is no food, there is no other
choice than getting humble).
In distributed multimedia systems - especially in video management systems
- adaptation is becoming increasingly important. The reason is simple: due to
the challenging amount of data involved and the soft real-time constraints,
video management systems are always ”resource hungry”. This hunger can be
satisfied neither by best-effort resource management, which cannot handle
timing constraints, nor by reservation, which over-allocates resources (for the
worst case). Therefore, on the long term, adaptation is a necessity. It is -
fortunately - also an opportunity, both in its defensive and in its offensive forms.
To find new places and new food, we have to be able to communicate with
the environment, we must understand its signals. In a computerized world this
means: being able to support standardized communication.
Fairly much research has been done on media adaptation, which is
obviously defensive [2–5]. The required flexibility lies in the inner structure of
the media data. Especially by sophisticated video coding techniques, ample
space is created for transcoding of video data resulting in smaller size and
bitrate and in still acceptable perceptual quality. Fortunately, the relation
between size and quality reduction is usually non-linear: up to a certain limit,
large size reduction causes a moderate quality loss.
Much less research has been done on offensive (also called server-level)
adaptation. The reason for this reduced interest lies probably in the fact that
most distributed multimedia systems lack the necessary flexibility. Such a
system must be able to dynamically acquire new resources and move/replicate
its own code and data as needed. This requires flexibility of the architecture
and consequent adherence to standards – both rare characteristics in current
distributed multimedia systems. In the course of the ADMITS (Adaptation in
Distributed Multimedia IT Systems) project [6,7] we address both kinds of
adaptation and their integration as well.
Offensive adaptation is realized by an Adaptive Distributed Multimedia
Server (ADMS), which is able to allocate new server nodes on the network and
migrate functionality and data to them on demand. ADMS has a highly flexible
architecture enabling this kind of migration operations. If for example the host

Page 3

ComSIS Vol. 1, No. 1, February 2004 47
recommender component notices that a certain group of clients could be better
served if the data collector component (collecting stripe units from the data
storage nodes and streaming them to the clients) were physically located near
to this client group, then it simply allocates a new node and sends a copy of the
data collector code there. A detailed description of ADMS is given in Section 3.
Defensive adaptation is realized by a Quality Based Intelligent Proxy (QBIX).
The proxy is able to handle different quality levels of the same video (based on
MPEG-4 [8] coding and on transcoding, supported by MPEG-7 [9] meta data).
It can operate as a cache, in which case it uses adaptive cache replacement
algorithms. Instead of discarding replacement candidates it reduces their
quality as long as possible, thus raising the hit rate considerably. It can also
operate as a gateway, in which case it serves client devices with different
capabilities by videos of different quality. It can e.g. send a high quality version
of a video to clients on a personal computer and a low quality version to clients
with a PDA. A detailed description of QBIX is given in Section 4.
An integration of the offensive and defensive adaptation is given if we use
the intelligent proxy itself as a component of the adaptive server. Due to the
flexible architecture this is technically easy. The usual strategy is that we first
try to apply offensive adaptation by enlarging the server by new nodes to host
the proxy functionality. As the proxy is able to perform defensive adaptation, it
still can reduce the quality of the stored videos if necessary. Whereas ADMS
and QBIX are already fully operational, the integration is still in progress. The
quantitative evaluation of the effect of the integration is the next step in the
ADMITS project.
2. Related Work
In [10] it is shown that distributed multimedia servers have benefits over
single server architectures regarding scalability and server-level fault tolerance.
We discussed in earlier papers [11,12] that existing distributed server
architectures like the Berkeley Distributed VoD System [13], the Tiger Video
Fileserver [14], or the EURECOM VoD Server [15] have a monolithic
architecture and are performance-optimized to one main goal: serving
thousands of simultaneous client requests. However, in heterogeneous
environments, it is usually not the server, but the network that becomes a
bottleneck. This is especially the case if a certain level of quality of service is to
be guaranteed in terms of latency times, bandwidth availability or packet loss.
Although sophisticated commercial systems like the Darwin Streaming
Server (DSS) – an open source version of Apple’s modular QuickTime
Streaming Server – or the Helix Universal Server (HUS) [16,17] –
developed by RealNetworks –, show a highly distributed architecture, their
organization is static, they cannot acquire new resources on the network on
demand.
Content distribution networks (CDNs) are dedicated collections of servers
(called data centers) strategically located across the Internet. A typical

Page 4

48 ComSIS Vol. 1, No. 1, February 2004
example for a CDN is Akamai’s distributed content delivery system, which
deploys more than 12000 servers in over 1000 networks around our planet
[18]. Based on the assumption that the strategic locations of the data centers
are well chosen, a CDN is definitively a good solution for adapting the physical
location of a media stream. It is highly available and serves the streams from
locations where clients perceive a good quality of service. However, the
strategic positioning of data centers and edge servers is typically done
manually by observing client demands. A CDN does not provide means for
performing strategic placements automatically.
In a peer-to-peer (P2P) file sharing network, peers collaborate to form a
distributed system for the purpose of exchanging content [19]. However, the
applicability of P2P networks for adapting the location of media streams in a
distributed streaming environment is rather poor. In particular, it faces the
following two problems: (i) Participation in a P2P network is purely voluntary. A
recent study has shown that most peers are run by end users, who suffer from
low availability, and have network connections with a relatively low capacity
[20]. (ii) It is server-less, which makes a controlled distribution of content very
difficult [21]. Nevertheless, there are approaches that use P2P content delivery
for media streaming, as e.g. presented in [21] and [22].
An offensive server architecture requires a QoS-aware middleware providing
active support for adaptation steps. Extensive work has been done in the area
of QoS-aware middleware for ATM-based networks and also for systems using
RSVP [23–25]. These systems are hardly appropriate for the Internet, where
resource reservation is still rather theory than practice. On the other hand,
considerable work has been done on end-to-end distance monitoring and
estimation in the Internet [26–29].
measurement/estimation algorithms can be used to approximate QoS
awareness for a middleware as needed for offensive adaptation. Although
certain middleware systems support dynamic replication or migration of
services and components, like Jini [30] or Symphony [31], they do not provide
measurements and estimations of network distances and server resources.
One possibility to cope with typical Internet problems such as network jitter
and bandwidth limitations is media adaptation. QBIX [1] is a quality based
intelligent proxy that caches whole videos and offers media adaptation support
to reduce the size/bandwidth requirements of the cached videos. Related work
in this area is sparse. Examples are periodic caching of layered coded videos
[32], combination of replacement strategies and layered coded videos [33],
quality adjusted caching of GoPs (group of pictures) [34], adaptive caching of
layered coded videos in combination with congestion control [35] or simple
replacement strategies (patterns) for videos consisting of different quality steps
[36]. Most of these proposals rely on simulation to evaluate the performance of
the caching techniques. Therefore some assumptions have to be made about
the structure of the videos (e.g. layered videos).
Because QBIX supports re-encoding of videos without layered encoding, a
real implementation was used to evaluate the impact of re-encoding on the
quality of cache replacement, something which is hard to simulate. The only
other project we know about, also offering a real implementation is described in
Such bandwidth and delay

Page 5

ComSIS Vol. 1, No. 1, February 2004 49
[35]. This work relies on proprietary systems and protocols, whereas QBIX
integrates modern multimedia standards like MPEG-4 [8], MPEG-7 [9], the
upcoming MPEG-21 standard [37] and communication standards like RTP and
RTSP [38]. Integrating QBIX into ADMS will create the very first distributed
multimedia server that combines offensive and defensive adaptation.
3. QoS-driven Server-level Adaptation
In a statically configured distributed server architecture with a behavior
steered by several sorts of distance metrics to the clients (e.g. by evaluating
RTCP statistics of former clients), client requests can either be accepted or
denied (admission control). There is no third option. In cases of increased
denials due to network resource shortages, such a server has no chance to
adapt its layout to serve more clients. Defensive media adaptation (see more in
Section 4) cannot always cope with such situations either, because (1)
adaptation of the media content is not always possible and (2) it may even be
prohibited by the content provider.
In the sequel, we therefore introduce an adaptive distributed server
architecture that can modify its configuration according to client requests. We
discuss this architecture and evaluate its performance behavior.
3.1. Components of a Distributed Multimedia Streaming Server
3.1.1. Guidelines for Component Identification
In [11,12] we describe the architecture of an adaptive distributed multimedia
streaming server (ADMS), which explicitly controls its own layout. There is a
trade-off between the grade of flexibility and the complexity caused by too large
a number of components. We identified four basic components that are
necessary and sufficient for the composition of a dynamically reconfigurable
streaming server. Figure 1 illustrates a sample combination of these
components, including the standard protocols used.

Page 6

50 ComSIS Vol. 1, No. 1, February 2004

Fig. 1. Components and Protocols Used in a Component-based Streaming Server Environment
The following two guidelines have to be taken into account when designing a
component-based distributed streaming server. First, each component must be
independent, reusable, adaptable, and combinable as much as possible. These
considerations are valid for a static distributed environment as well. For a
dynamically adaptable system the components must additionally be movable.
Second, in order to get a lean structure with a strongly limited number of
components, each component should fulfill one substantial logical task. Such
substantial tasks are data acquisition, data streaming, data storage
management and overall control. For example, during a data acquisition
scenario initiated by a production client, a media stream has to be distributed
(”striped”) among a set of server nodes. One single component is needed to
receive the stream data, to split the stream into smaller pieces, and to distribute
the pieces among a set of data nodes. The data nodes themselves are
equipped with a component for storing and retrieving pieces of media data.
Thus, a distribution component can be combined with a number of storage
components, which all may run on separate server nodes.
Following these guidelines, four basic components have been identified to
constitute a component-based distributed streaming server: data managers
(DMs), data distributors (DDs), data collectors (DCs), and cluster managers
(CMs). The implementation of the components can use different technologies,
interoperability is achieved by using CORBA as communication medium [39].
3.1.2. Data Manager
Data managers are the key components in the ADMS architecture. A data
manager provides means for efficient storage and retrieval of elementary
streams or segments thereof. Since one elementary stream or segment may be
striped among a number of data managers, each data manager only stores a

Page 7

ComSIS Vol. 1, No. 1, February 2004 51
portion of the stream or segment. Figure 2 illustrates the internal storage
organization of the media streams. The data manager stores a set of partial
media streams, which themselves consist of a set of leaf and compound media
segments. Real media data is only stored in leaf media segments. Compound
segments are used to describe syntactic and semantic relations among
elementary segments.


Fig. 2. Objects Comprising a Data Manager Component
3.1.3. Data Distributor
A data distributor component is responsible for the distribution of media data
received from a production client or a live camera to a selected set of data
managers. The unit of distribution is a so-called stripe unit, which can be either
of constant data length (CDL), or of constant time length (CTL). In CDL mode,
parity units are generated in order to cope with data manager failures. The
number and location of target data managers and the mode of striping (single,
narrow or wide) is advised by the cluster manager component.
In cases of a non-live source, the process of distribution can be driven by
MPEG-7 [9] metadata which describe the temporal decomposition of the media
stream. A media stream can be decomposed into a number of segments,
organized in an arbitrary number of levels. Figure 3 presents a sample
temporal decomposition of a video stream into two segments, using an MPEG-
7 descriptor.
The data distributor distributes only elementary streams, since the target
system is designed for streaming scenarios based on RTP. Thus, if the media
source contains a multiplexed stream, it has to be demultiplexed into elemen-
tary streams before striping.

Page 8

52 ComSIS Vol. 1, No. 1, February 2004

Fig. 3. Temporal Decomposition of a Video Stream using MPEG-7
3.1.4. Data Collector
The data collector performs the inverse operation of data distribution. It
collects stripe units of a certain media stream from the appropriate set of data
managers, re-sequences the units and sends the buffered stream to the client
via an RTP connection. It provides server-level fault tolerance by exploiting
parity units in case of unavailable data managers. The collector may also
incorporate a caching component, thus reducing client startup latencies and
bandwidth consumption. In particular, the data collector can play the role of a
proxy server, which is dynamically assigned to serve a group of clients by the
cluster manager. This constitutes the difference to usual proxies, which are
selected by the clients themselves.
An interesting approach is the integration of gateway functionalities into the
data collector. A gateway performs transcoding in order to adapt to given
network or client device constraints. It may e.g. reduce the resolution of a video
which is sent to a client equipped with a small-resolution screen. A data
collector incorporating gateway functionality is a particularly appealing example
for the combination of offensive and defensive adaptation. We use offensive
adaptation to bring the gateway to the proper place, and there use defensive
adaptation to comply with the given client capabilities.

Page 9

ComSIS Vol. 1, No. 1, February 2004 53
3.1.5. Cluster Manager
A cluster manager is the initial entry point for clients. In contrast to the three
component types described before, there is (usually) only one instance of it in
an ADMS cluster. It dynamically manages the locations of the other three
component instances and maintains knowledge about the distribution of
elementary streams among data managers.
An important point is that the cluster manager does not serve client requests
by itself. Instead, it redirects a request to an appropriate data collector or
distributor, respectively. The most appropriate node to host a data collector or
distributor is found by the so-called adaptation engine (abbreviated as AE in
Figure 1), which is a sub-component of the cluster manager. In a static
distributed multimedia server (SDMS) system the adaptation engine may
perform several selection algorithms for finding the most appropriate candidate
among the given set of nodes. However, if no appropriate candidate can be
found, the request has to be denied. In contrast, in an ADMS environment, the
adaptation engine may transmit (replicate or migrate) a data collector or
distributor instance to an idle server node candidate, thus satisfying requests
which might have been denied by a static architecture.
3.1.6. Protocols for Component and Client Interaction
As demonstrated in Figure 1, the only control protocol used between clients
and DMS components is the RTSP [38] protocol. Keeping the client
implementation CORBA-unaware has the benefit that it may interact with any
streaming server which conforms to media streaming standards. The control
protocols used internally between DMS components are CORBA-based and
conform to the IDL specifications of the components. The ”master mind” behind
all kind of scenarios is an MPEG-7 meta database, which stores syntactic and
semantic information about the media streams stored on the server.
3.2. ADMS: An Adaptive Distributed Multimedia Streaming Server
The components introduced in Section 3 could be parts of either a static or a
dynamic distributed multimedia streaming server (SDMS resp. ADMS).
Before introducing the middleware, which is the engine making the server
dynamic (see Section 3.2.2), we discuss the main shortcomings of a static
architecture.
3.2.1. Discussion of the Static Architecture
In [10] it is claimed that distributed video servers are load balanced
regardless of the skew in video popularities. This is only valid for an
architecture where the data collectors are integrated into the client application

Page 10

54 ComSIS Vol. 1, No. 1, February 2004
(proxy-at-client model). Consider that there are M data manager and N data
collector instances in an SDMS, supporting the proxy-at-server or the
independent-proxy model. Each server node has the same capacity C, and
each client request demands the same amount of resources c on a data
collector (Figure 4).

Fig. 4. Host Resource Saturation Progression in an SDMS

In a fair resource reservation scheme with a uniform distribution of requests
to the data collectors, N data collectors can admit at most
⎥⎦
⎥
⎢⎣
⎢
⋅
c
CN

simultaneous requests. On the other hand, a requested media object is striped
among the M data managers, resulting in a capacity demand of
M
c
on each
data manager on average. Thus, the total number of client requests that can be
admitted on one data manager node is bound by
⎥⎦
⎥
⎢⎣
⎢
⋅
c
MC
. Since in a typical
static server configuration M is a multiple of N, overall load-balancing is not
given anymore. Figure 4 illustrates this imbalance showing that although the
M=10 data manager nodes are still under-utilized at 20%, the N=2 data
collectors are reaching their saturation point. The assumed resource demand
ratio is δ = 0.1 per request on a data collector.
To get rid of the shortcomings of the SDMS architecture, an infrastructure is
required which allows for a dynamic composition of the components described
in section 3.1, resulting in an adaptive distributed multimedia streaming server
(ADMS). Components should be replicable and/or migratable on demand,
allowing the dynamic composition of a virtual server [31]. We developed a
CORBA-based infrastructure called Vagabond2 [40], which supports dynamic
instantiation, migration, replication and evacuation of so-called adaptive
applications (a synonym for component in Vagabond2).

Page 11

ComSIS Vol. 1, No. 1, February 2004 55
3.2.2. Vagabond2: A Middleware for Virtual Servers in Internet Settings
Vagabond2 is a CORBA-based middleware, implemented in Java, consisting
of two general modules: a module for component management, and a module
for component adaptation (see Figure 5). The component management module
provides two services for a distributed server like ADMS: an application service
for component movement between Vagabond2 hosts, and a host service for
registering and querying harbours. A harbour represents the runtime
environment which must be running on each Vagabond2 host. Vagabond2
enables loading the Java byte code of an adaptive application, and instantiating
this as a CORBA servant.
The component adaptation module provides two central services for
offensive server adaptation: the adaptation service and the resource broker.



Fig. 5. Modules of the Vagabond2 Middleware
The adaptation service provides the so-called host recommender, which tries
to find an optimally located host for a certain component under a given set of
constraints. An example for a set of QoS constraints described by an MPEG-21
descriptor embedded in an RTSP SETUP message is given in Figure 6.
The MPEG-21 [37] network characteristics descriptor is rooted by the DIA
(Digital Item Adaptation) element. The capability element of the descriptor says
that a bandwidth range between 32 and 128 kbit/sec is acceptable, packets
might be delivered out of order and may be lost. The condition element
specifies that the 128 kbit/sec link may be fully utilized, but on average should
only get 64 kbit/sec. The packet delay from a data collector to the client should
not be greater than 500 msec, and delay variation not greater than 100 msec.
Finally, the packet loss rate must be below two percent.

Page 12

56 ComSIS Vol. 1, No. 1, February 2004

Fig. 6. RTSP SETUP Message Including an MPEG-21 DIA Descriptor

The RTSP message further indicates (field Range) that the client wants to
get the stream segment from the 20th to the 40th second (media relative time).
Additionally, the request should be scheduled for March 1st, 2003, at 14
o’clock. This time indication at session setup enables the adaptation engine to
proactively schedule the request to an appropriate data collector, taking into
account the given QoS constraints, and the location of the data managers,
where the stream data has to be retrieved from.
When a new client request R arrives, the host recommender has to work out
which host should run the data collector instance servicing R, and whether it
should be an existing or a new (replicated or migrated) instance. The host
recommender has to solve the dynamic server selection problem to find the
best available data collector. If no appropriate data collector exists at all, an
SDMS has to reject the request. In contrary, the ADMS may have enough time
to create a new place by solving the capacitated facility location problem [41].
In order to prepare these decisions, the host recommender cooperates with
the resource broker - the second service of the adaptation module. The broker
provides means to admit immediate and future QoS-constrained requests, and
to perform logical reservations of network and host resources. It achieves this
by using two additional services: the network resource service, and the host
resource services, the latter running on each Vagabond2 harbour.
An excerpt of the network resource service’s IDL specification is shown in
Figure 7. Via the NetworkInfo interface we can get for example the capacity of
a route between two arbitrarily connected Vagabond2 server hosts. Supported
distance metrics are bandwidth, delay, packet loss rate, and round trip time. In
this context, the specification of a period is important. If the period covers future
time points, the service provides an estimated value, by applying time series
analysis based on measurements. The network resource service requires that
on each Vagabond2 harbour a network monitor is running, which periodically

Page 13

ComSIS Vol. 1, No. 1, February 2004 57
measures instantaneous values of all supported metrics. For the host resource
service a similar scenario is applied: available host resources (CPU, memory,
and disk space) are periodically measured and their throughputs are
benchmarked on harbour start-up.


Fig. 7. Vagabond2’s Network Resource Service Specification
There is an important difference between finding optimally placed nodes for
ADMS data collectors and Web server replicas as described in [42], namely the
asymmetric character of the recommendation problem. In ADMS, the
connections between data managers and data collectors are different from
those between collectors and clients. In the former, data transmission must be
error-free and is fairly irresistible against jitter, therefore TCP connections can
be used. In the latter, videos must be streamed with limited jitter, but not
necessarily error-free (e.g. B frames might be lost), therefore RTP/UDP based
communication can be used. A simulation experiment has shown that when
many data collectors are near to the client (i.e. low UDP and large TCP
communication), the standard deviation (the jitter) remains low, but the total
amount of data travelling in the network increases (see Figure 8).
3.2.3. Making an ADMS Component ’Movable’
An adaptive component must be derived from the CORBA interface
AdaptiveApplication [40, 12]. The key functionality of this interface is the
getApplicationInfo() method, which is used by a harbour to request for the
binaries of the component, and optionally for a set of files it may depend on.
Figure 9 illustrates this as an excerpt of Vagabond2’s IDL specification.

Page 14

58 ComSIS Vol. 1, No. 1, February 2004


Fig. 8. Jitter (left) and data flow size (right). wdm/wcl is the ratio between the costs of the DC-
DM and DC-client links.

Fig. 9. Vagabond2’s Core Interfaces for Adaptive Components
Figure 10 illustrates how a data manager component is derived from the
AdaptiveApplication interface. First, a common abstraction layer is introduced,
which is valid for all four ADMS component types. It introduces the interfaces
ADMSServerApplication and Session, allowing the establishment of rate-
controlled and transaction-based sessions of certain types (retrieval,
acquisition, or management). Second, the bottom layer defines the interfaces
and structures comprising the
ADMSDataManager is used to create so-called data manager sessions
(DMSession). Each session is associated with exactly one elementary stream.
A data manager session provides means to store stripe units for a certain
stream segment, to compose a segment tree of known segments, or to retrieve
stripe units of a certain segment via a stripe unit iterator. Based on the
session’s admitted data rate (in kbit/sec), the unit iterator allows to retrieve an
according number of stripe units per second.
data manager component. An

Page 15

ComSIS Vol. 1, No. 1, February 2004 59
If an ADMS component is implemented in another language than Java, a
Java wrapper component must be added. The binary code has to be carried in
the dependent files archive as a shared library. Since an ADMS environment
may consist of heterogeneous nodes, the host service provides information
about the operating system on a certain harbour, in order to move suitable
code to it.


Fig. 10. Data Manager Component as Special Adaptive Application of Vagabond2
3.2.4. Discussion of the Adaptive Architecture
We have evaluated a prototype implementation of our component-based
offensive server in the ADMS test bed illustrated in Figure 11. We measured
the effect of replicating data managers between two LANs connected via the
Internet. One of the LANs was located in Budapest (B-LAN), the other one (I-
LAN) in Klagenfurt. The geographical distance of about 500 km assured a
”real” Internet setting. The retrieval client was located in the I-LAN and ran a
data collector instance on its own host. Each performance test consists of five
test runs and is repeated 50 times. In each run, a sample media stream of
12.5MB size is retrieved from the data manager instances. In test run 0, all
data manager instances are running in the remote B-LAN. In test run 1, the
data manager from host 8 is replicated to host 4, meaning that one data
manager moves ”closer” to the data collector. Both the component code and
the requested media stream are replicated, since hosts 1 – 4 are initially