Middleware Design and Architecture

Transcript

Progetto Strategico CNR (Legge 449/97)
Settore Piattaforme ITC abilitanti complesse ad oggetti distribuiti
Infrastruttura Software per Reti Ad Hoc
Orientate ad Ambienti Difficili
WP4: Middleware – Deliverable #2
Middleware Design and Architecture
The necessity of rapid, flexible and temporary connections between possibly
heterogeneous mobile devices has recently motivated intense research activities in the
Mobile Ad-hoc NETworks (MANET) area. For a detailed overview of the recent
advances in MANET hardware equipment and of research efforts and projects for
MANET software support, please refer to the IS-MANET Deliverable #1 produced by
the Work Package 1 (WP1).
MANET nodes can move at any time, even during service provisioning, while a
client node has started to access a distributed server component in the MANET but not
terminated yet. Node mobility and consequent variations in network topology force
continuous network reorganizations. Due to the temporary and spontaneous nature of
MANET connections, it is almost impossible to rely on a statically deployed network
support infrastructure. Therefore, MANET nodes tend to be autonomous entities that
cannot guarantee a durable and continuous presence in cooperating and performing
information delivery via multi-hop MANET-specific routing protocols.
The high dynamicity of these networks makes the design and implementation of
distributed applications over MANET significantly more complex than in traditional
wired environments. In particular, most development challenges stem from two key
MANET properties: lack of a statically deployed (and known) support infrastructure
and high mobility of terminals.
On the one hand, several infrastructure-based solutions, effective in wired networks,
hardly suit MANET environments. For instance, in MANET it is unlikely to assume
that a configuration server is continuously available to provide the needed network
configuration data, such as temporarily assigned IP addresses in DHCP. As a
consequence, MANET require the design and implementation of completely distributed
ad-hoc protocols for dynamic host configuration.
On the other hand, node mobility may cause frequent disconnections of MANET
clients and needed distributed resources, e.g., due to the loss of direct connectivity when
either resources or clients move out of the reciprocal wireless coverage area and none
can perform multi-hop routing. MANET force to reconsider even well established
distributed interaction models, such as the client/server one. For instance, clients cannot
assume that, once discovered and bound to a suitable server component, their
established connections could persist for the whole service session. In other words, it
seems responsibility of the application logic to continually verify and update the list of
reachable service components, and manage the possible disconnections by performing
rebinding operations accordingly.
Let us note that, even when mutual node movements do not cause the interruption of
established connections, it could be relevant to dynamically re-qualify the bindings to
service components to favor optimal exploitation of local (at single-hop distance)
resources. For instance, when two reachable and functionally equivalent servers are
visible, it is preferable to rebind to the currently local one over the other at multiple-hop
distance from the client.
For the sake of simplicity, let us consider the case of a server that belongs to one
MANET locality (with all the nodes in direct, single-hop, visibility) and moves to
another locality while running active service sessions. For instance, suppose a civil
protection coordinator that is sending (even audio-based) command messages to a group
of civil protection operators on the field and that exits from the locality of one of its
clients. The server change of locality would either require the dynamic organization of
routing chains of forwarding nodes to maintain the client-server connectivity or produce
the abrupt interruption of the service sessions if no MANET nodes in the locality
support multiple-hop routing. To enable the continuous transmission of commands
notwithstanding the server movements, any client should be capable of:
• reacting to the coordinator disconnection,
• understanding whether it is possible to rebind to an equivalent (sub-)coordinator in
its locality,
• performing a multi-hop inter-locality search for (and routing to) the moved
coordinator.
Similar considerations apply in the case of client movements with regards to their
needed and unmoved server.
We claim that it is unviable to think about application deployment scenarios where
any MANET client node should own all the above capabilities. First of all, MANET
nodes are heterogeneous and often very resource-constrained: it is impossible to
statically equip any node with all the functions possibly needed at runtime to support
dynamically adaptive and continuous services in the case of mutual client/server
mobility. Most important, charging application developers with the burden of
implementing such complex support functions significantly slows down the realization
of MANET applications, thus hindering the emergence of this novel service market. For
these reasons, we claim the need for a middleware-level approach to support and
facilitate the development of distributed applications in the highly dynamic and
statically unpredictable MANET scenario.
In the first year of the IS-MANET Project, WP4 has worked on the definition of a
middleware architecture suitable to support the design, development, and deployment of
MANET-enabled distributed services. In particular, WP4 defined a middleware
architecture composed of two separated layers, a Basic Facility Layer that provides all
the fundamental mechanisms required for developing distributed services over
MANET, and an Advanced Facility Layer that exploits the basic facilities to provide
application developers with more complex support functions at a higher level of
abstraction.
The second phase of the IS-MANET project (12 months) has focused on the
implementation of all services composing the Basic Facility Layer and of first services
2
specified in the Advanced Facilities Layer. In the second phase, the joint efforts have
directed toward the convergence of a common set of implemented middleware
mechanisms and tools, resulting from the establishment of a stable software base to
increase the durability and the applicability of the development work within the project.
The third project year will pursue the goals of concluding the implementation of the
Advanced Facilities refining the prototypes of solutions at the Basic Facility Layer. In
addition, in the third project year, WP4 will work on developing and deploying demo
applications based on the proposed middleware both to show the suitability of our
middleware solutions for MANET-enabled application domains and to provide
additional application-driven feedback for final middleware refinement.
Middleware facilities for MANET: a Layered Architecture
Figure 1 depicts the layered architecture for the IS-MANET middleware identified in
the first year of the project. The architecture consists of six basic middleware facilities
(naming, routing, communication, allocation/reallocation, location-awareness, and
monitoring) and four advanced middleware facilities (group management, coordination,
data storage & dissemination, and quality of service management), capable of
addressing all the support issues of interest for the IS-MANET project and for its
application domains.
Application
Layer
Advanced
Facility Layer
Basic
Facility Layer
Collaborative
Save&Rescue
VoD/Audio
Distribution
Group
Management
Naming
Coordination
Routing
Commun.
Disseminated
Info Services
Data Storage&
Dissemination
Allocation/
Reallocation
QoS
Management
Location
awareness
Monitoring
Heterogeneous Distributed Resources
Figure 1. The architecture of the proposed IS-MANET middleware.
Basic Facility Layer
The Basic Facility Layer includes low-level functionality to allow devices to access
their MANET, to support naming, communication, discovery/binding, location-
3
awareness and network monitoring. All these services have been implemented within
the second project year and will be improved and refined in the following.
The routing service provides protocols to access resources located at multi-hop
distances. This service component provides both unicast and multicast/broadcast
functionalities. Although the component typically works in a reactive fashion, it is also
possible to obtain proactive operation modes to build and organize routing paths and
tables before they are needed. This permits to avoid delays in path discovery, which
typically affect reactive protocols.
The communication facility provides basic support to enable the interoperation
between different collaborating parties. The communication facility provides a rich set
of API for enabling various forms of collaboration via message passing, tuple spaces
and publish/subscribe.
The naming facility permits to uniquely identify entities along with the resources
they share. The naming facility can either use traditional naming models or advanced
ad-hoc ones according to application requirements.
The allocation/reallocation component permits the discovery of entities and resources
of user interest. In addition, the component provides application developers with the
possibility to bind entities/resources of their interest and to re-qualify obtained bindings
dynamically, at run-time, depending on the current network situation.
The location awareness component provides application developers with the locality
abstraction, to foster and favor collaboration between neighbor entities. The component
permits to build and manage network localities and provides support for managing
differentiated roles within the locality. In particular, election protocols permit to design
a locality manager entity, with a decentralized management role typically associated.
The Monitoring component permits to identify a partial view of the current network
situation notwithstanding the high dynamicity of the addressed environment. It is
typically devoted to application with QoS requirements.
Advanced Facility Layer
Advanced services are only partially implemented and are currently still under
investigation. The implementation of these services will be finished in the third year of
the project. Advanced services provide larger management functionalities than basic
services and are implemented on top of them. However, for the sake of performance
optimization, advanced services will also benefit from cross-layering implementation
approaches.
The group management component permits to compose/dissolve and manage groups
of collaborating entities dynamically.
The coordination component exploits both grouping and communication to manage
collaboration activities. In particular, the coordination support can be either based on
tuple or publish/subscribe models according to application requirements. The
coordination component permits to dispatch events of interest to different collaborating
parties and with different fault-tolerance guarantees.
The data storage & dissemination component permits to effectively disseminate and
retrieve resource replicas with lazily consistent requirements in a MANET environment.
The component works to maintain the desired degree of replication by providing
mechanisms to manage read-only replicas distributed in the network.
4
The QoS upper layer component provides applications different QoS guarantees
according to their requirements, based on resource availability controlled by the lower
monitoring component.
Implementation of the IS-MANET Middleware Architecture
The high degree of dynamicity of MANET settings, along with the severe constraints
that characterize user devices in mobile ad-hoc domains, requires to face challenging
problems in the development of support solutions at the middleware level. To this aim
the implementation of the IS-MANET middleware architecture has taken into account
three main design/implementation principles: cross-layering, middleware
customizability and resource saving.
Layering is crucial in simplifying the service support in traditional distributed
systems. For instance, one of the most relevant reasons of the worldwide success of the
Internet is largely recognized being its well-defined layered architecture. However, a
strict layered design is demonstrating to be not flexible enough to cope with the
dynamics of MANET environments, thus preventing performance optimizations. It is
not accidental that one of the question at the state-of-the-art for the MANET community
is to what extent developers must modify the pure layered approach by introducing
stricter cooperation among MANET-specific solutions belonging to different layers. At
the one end, some approaches use strict layering to maintain compatibility and solve
interdependencies between different protocols and different solutions. A full cross-layer
middleware design represents the other extreme, often present in the current MANET
literature. In particular, the MANET research community recognizes that cross-layering
can provide significant performance benefits, but also observes that a layered design
provides a key element in the success and proliferation of a technology. Strict layering
guarantees controlled interaction among layers because developing and maintaining
single layers takes place independently of the rest of the stack. On the contrary, an
unbridled cross-layer design can produce spaghetti-like code that is impossible to
maintain efficiently because every modification must be propagated across all layers.
The second implementation principle followed by WP4 is customizability. In
particular, the different facilities have been implemented in a completely modular way,
so to enable the possibility to deploy also lightweight middleware configurations with
only limited subsets of the basic and advanced facilities. In addition, a middleware
configuration can be modified at runtime, by adding/discarding the needed/useless
middleware modules to/from the currently deployed software support. This not only
makes the middleware dynamically adaptive to a specific MANET execution
environment and to the specific needs of running applications, but also addresses the
requirement of MANET nodes that are typically resource-constrained and cannot host
articulated and complex software suites. Along this direction, WP4 also promotes the
exploitation of mobile code implementation technologies, which can definitely simplify
the dynamic installation and deployment of software components where and when
needed during service provisioning.
Finally, the third implementation principle, which has inspired the implementation
of the IS-MANET middleware, is resource saving. MANET users operate via
5
heterogeneous and battery-operated devices that often show severe limitations both in
memory availability and CPU power. As a consequence the IS-MANET middleware
has been implemented by minimizing resource use on constrained devices to fit terminal
characteristics and constrained capabilities. In particular, mechanisms to minimize the
use of memory have been adopted. Finally, WP4 has adopted energy-efficient solutions
in the implementation of network protocols. This has permitted to reduce networkrelated energy costs, which typically consume half of the whole energy budget of user
devices.
The Basic Facilities of the IS-MANET Middleware
Naming. The naming system is a crucial building block in any distributed application.
Traditional naming systems cannot cope with the high dynamicity of MANET
environments because they are based on a centralized service model and cannot easily
face up with frequent user/device mobility. In addition, it is very difficult to guarantee
name agreements in MANET settings [3].
The proposed IS-MANET middleware architecture introduces the Proximity
Enabled Naming facility (PEN) that provides support for naming and for the discovery
of available neighbor entities. On the one hand, PEN is in charge of randomly
generating unique identifiers by exploiting a naming approach similar to the one
proposed for P2P environments [4]. On the other hand, the PEN facility permits each
entity to advertise its on-line availability. At regular intervals the entities broadcast a
beacon to all the direct neighbors. The beacon includes information with entity
identifiers and the IP address. In addition, a Time to Live (TTL) field expresses the
number of hops the message propagates. Upon reception, the receiver decrements the
beacon TTL. If the TTL field is nonzero, the entity re-broadcasts the message,
according to a gossiping algorithm, to all its direct neighbors with a probability p(n) that
decreases if the number of entities located in proximity increases. This approach permits
to avoid broadcast storming [5]. In addition, PEN senses the on-line advertisement
packets from neighbors and builds a table associating each available entity with an entry
that includes its identifier and IP address. [BO1]
A further research direction investigated within WP4 is the identification of an
innovative discovery and naming solution that extends P2P frameworks (in particular
JXTA) to suit highly dynamic wireless scenarios. The original JXTA naming and
discovery support has been enhanced in order to adapt to ad-hoc environments. Each
entity is identified by exploiting a peer identifier (PID) and the group identifier (GID)
she belongs to. In addition shared resources are uniquely identified by exploiting a
resource identifier (ID). The JXTA platform has been extended to monitor the network
interfaces every of new peers that turn active. In particular, each new network interface
will be made available to the application layer as a new visible endpoint [CT1].
Routing. To enable communications among devices not in direct visibility, the ISMANET middleware exploits the multi-hop routing facility. Several search and rescue
use cases call for information exchange with remote devices. Let us depict some
compelling situations. If (i) fire fighters need to share data with other operators not
6
located in their proximity, or if (ii) they want to notify an event to the base camp or yet
(iii) to exploit the long-range communication technologies of fire trucks while being
detached, they can hang on other nodes to relay messages. MANET characteristics
undermine traditional routing solutions. In MANET, a static infrastructure for packet
delivery is not available. Therefore, nodes should implement collaborative multi-hop
routing and participate in message forwarding. Second, MANET topology is dynamic,
thus it emphasizes undesirable features of traditional table-driven routing protocols.
Finally, current technologies permit only low bandwidth and high error rates.
Despite these considerations, many effective protocols have been proposed in last
ten years. Unfortunately, most devised solutions aim at minimizing path length. Hence,
from the energy dissipation standpoint, their performance is quite leveled. This is due to
the energy consumption of network interface, which reveals not much different during
transmissions, receptions, and in idle state. Although WP4 does not focus on routing
protocol design at the network layer, by considering cross-layer design as a fundamental
guideline, some efforts in the second phase of the project have been done toward
application-aware solutions. The criticality of our target scenarios calls for power-aware
strategies. Thus, a novel routing protocol improving MERG (Minimum Energy
Reachability Group)-based algorithm with Link Selection has been implemented [1]
[GE1]. MERG may lead to a faster drain-out of some critical nodes. Link Selection can
achieve a more uniform energy dissipation, by considering residual battery energy on
next-hop nodes before forwarding packets.
Inter-node communications in IS-MANET also calls for multipoint communication
capabilities. In fact, fire fighters could, for instance, require sending messages to all
operators belonging to the same team. The current implementation of the IS-MANET
middleware can use either flooding or probabilistic flooding protocols. However, we are
evaluating the adoption of available multicast protocols, such as MAODV.
Communication. IS-MANET scenarios involve different communication models. For
instance, PDAs carried by fire fighters and equipped with 802.11-based interfaces
should reciprocally connect. Moreover, they need to get in touch with fire trucks that
host base stations interconnecting operator teams with the base camp. Finally, the base
camp, in its turn, may provide interconnection with the fixed network infrastructure.
WP4 has worked on a Communication Facility (CF) that provides several primitives
for message-oriented communication and for run-time adaptation of message
presentation and scheduling [BO1]. Designing and implementing communication
supports for MANET is significantly more difficult than in wired networks. The
infrastructure lack requires reconsidering issues such as routing, loss of connectivity
and connection reliability, typically delegated and (at least partially) solved by the
network infrastructure. In addition, frequent terminal mobility requests clients to
perform continuous discovery operations to update the list of devices in direct visibility,
and to operate communication rebinding in case of loss of direct visibility.
In particular, CF supports asynchronous and unreliable message-oriented
communication and implements two primary communication patterns: context-based
any-cast and multi-cast:
7
•
Context-based any-cast permits point-to-point communication. When one group
member has to communicate, one and only one co-located member entity matching
a specified profile is selected as the message recipient.
• Context-based multi-cast permits multipoint communication. This pattern permits
to deliver the same message to all the co-located entities matching the desiderated
profile.
CF also permits to schedule incoming messages by assigning a priority to exchanged
messages depending on application-specific scheduling preferences. Context
information including the identity and attributes of the message provides foundation to
the dynamic assignment of priorities. In addition, information including time and
location guides the dynamic run-time re-qualification of message priorities.
In addition, CF permits to tailor exchanged message presentation format to suit the
preferences of communication parties and their characteristics. Message content
adaptation can involve very different operations, ranging from data filtering to data
transcoding and down scaling. For instance, downscaling operations may permit to
convert pictures from GIF to JPG format before delivering images to a resource-limited
mobile device. In addition, according to application-specific considerations, the
recipient may filter incoming messages to a format that is suitable to the actual
application need. For example, incoming messages text to speech conversion may
permit user hand-free interoperation.
The IS-MANET middleware also integrates content-based publish/subscribe
communication support [MI1-MI5]. In particular, the publish/subscribe communication
facility provides mechanisms to manage device mobility, dynamic configuration and reconfiguration of the message dispatching network, and message acknowledges. In
particular, the IS-MANET middleware allows to subscribe events of user interest and to
reply to received event notifications. The publish/subscribe communication support
collects all reply messages and forward them to the event publisher. This mechanism
provides application developers with asynchronous request/response multicast support
along with a more traditional publish/subscribe support. In addition, the
publish/subscribe communication support also permits to publish and subscribe events
on the basis of the current location of involved users.
Moreover, the IS-MANET middleware supports spatially-distributed tuple spaces
for communication and coordination. Tuples can be injected in the network and
propagated accordingly to application-specific patterns. On the one hand, tuple
propagation patterns could be dynamically re-shaped by the IS-MANET middleware to
implicitly reflect network and applications dynamics, as well as to reflect the evolution
of coordination activities. On the other hand, application agents have simply to locally
“sense” tuples to acquire contextual information, to exchange information with each
other and to implicitly and adaptively coordinate their activities [MO1].
Finally, WP4 is addressing communication issues among ad-hoc networks
supported by more capable devices (called gateways) [RM1]. This support can help in
integrating long-range transmission devices with peer-to-peer connectivity. Thus, other
peer nodes can exploit gateways to connect with stations located far away.
Allocation/Reallocation. The IS-MANET middleware supports roaming users with
discover mechanisms to obtain the visibility of locally available partners for
8
collaboration, along with the set of services and resources they share. In addition, the
middleware allows to dynamically re-arrange the bindings between the communication
parties, and to re-qualify bindings to services and resources of user interest.
First of all a discovery solution has been implemented [BO1, CT1]. In particular, the
system periodically advertises the local availability of partners for collaboration, along
with their services and resources. The visibility of this information is propagated up to
the application level and permits both to discover services/resources of user interest and
to continuously monitor their on-line availability. In fact, entities flood advertisements
at regular times. Following to the expiration of a timeout, if entities do not receive the
advertisements from a collaborating partner, they assume that the partner for
collaboration is no more available.
The IS-MANET support implements several modules that application-level
components can use to support discovery/rebinding operations. First of all, a proxybased support to address service continuity has been implemented. Proxies are
dynamically elected application-transparent entities that act as decoupling agents
between client and server endpoints. Middleware proxies support dynamic rebinding
between communicating parties independently of their mutual movements during
service delivery. For instance, when a server exits a locality during a service session, the
local proxy becomes responsible for transparently discovering a suitable server
component, either local or remote, and for forwarding to it the client requests, which
can be automatically directed to the local proxy by the middleware [BO2].
A context-aware binding service has also been developed to handle the
communication the bindings among communicating entities. This service requires the
visibility of the attributes and characteristics of all co-located (and possibly)
collaborating partners. To enable middleware-level binding management, the
applications must provide information including:
• Searching Profile that expresses the entity collaboration preferences in terms of
attributes and profile characteristics that the referred entities must match.
• Binding strategy that determines the set of members matching the searching
profile. In particular, two different binding strategies have been identified: EarlyBinding and Late-Binding. While Early-Binding identifies the set of (possibly)
message recipients once, at the time the binding is created, the Late Binding strategy
determines recipients on the basis of their availability each time a message is sent.
• Designation Criteria permits to identify one and only one message recipient among
a number of available ones matching the same searching profile. The designation
criteria are necessary only in the case of point-to-point communication.
For each entity, the binding facility manages a table (the binding table) that maintains
the associated bindings to the addressed communication partners for all the open service
sessions. In particular, each entry of the binding table is set up according to the
searching profile, binding strategy and the eventually designation criteria. The binding
facility can filter the list of actually available partners to identify message recipients
dynamically [BO1].
A further middleware component implemented during the second project year
permits the possibility to achieve policy-based resource rebinding. The main advantage
of this approach is that it decouples binding mechanisms and strategies. In particular,
application developers are allowed to express in a high level declarative language
9
rebinding strategies that will be enforced by the middleware components at service
provision time [BO3].
Location Awareness. The IS-MANET Location Awareness middleware facility allows
to restrict entity collaboration activities to the scope of a location. This is particularly
important in MANET scenarios, where co-located users are likely to collaborate
together more frequently than with remote ones. In addition, it is also technically
different to enable tight collaboration activities between remote users. In fact, the high
degree of dynamicity of mobile ad-hoc environments makes it very difficult to achieve
acceptable message delivery ratios by exploiting long length route paths.
On the one hand, the IS-MANET middleware implements a location-awareness
support that exploit the visibility of the current network topology to define the locality
abstraction. In particular, the different entities can either be Location Manager Entities
(LME) or Managed Entities (ME), according to the capabilities of their devices. A
locality is defined as the set of entities whose devices is connected to the locality LME
by a bounded number of hops, h. The value of h can be setup at deployment time
according to application-domain considerations [BO6, MO1].
In order to simplify location management in dense mobile ad-hoc network another
topology-based location awareness component has been implemented. This component
implements a protocol to identify the boundaries of management of an area where a
number of network terminals are co-located, i.e. a dense MANET. In addition the
service permits to elect a manager entity within the dense MANET, which is central to
the dense MANET, by exploiting a decentralized approach [BO6].
On the other hand, a further location-awareness service incarnation has been
implemented. In particular, a location broker has been implemented that restrict the
collaboration activities to only entities that are currently located within the boundaries
of a specified area. The location broker requires the availability of a location/tracking
service, such as a GPS [MI4, MO1].
Monitoring. Due to the constrained nature of devices participating in MANET,
distributed applications need to continuously monitor available resources and eventually
adapt their behavior to the current resource state. For instance, QoS management
requires a monitoring facility to inspect the state of the system during service
provisioning and to decide whether it is necessary to downscale service quality. The
monitoring facility should be both in charge of controlling device resources (CPU and
memory usage, battery status, …) and of examining network operating conditions. In
particular, network traffic analysis techniques permit to provide statistics about the
bandwidth utilization in the device proximity. Recent trends in this research field charge
the Monitoring facility with the duty of gathering environmental parameters, especially
related to device context, e.g., tracking its position.
A basic monitoring support has been developed that exploit the characteristics of the
IEEE 802.11 network to monitor the current status of availability of neighbors entities
that are located in reciprocal visibility. In particular, the support allows both to discover
new devices connected to the network and to detect their disconnections [MI2, MO1].
In addition, a Java-based monitoring support has been implemented that offers a
multi-platform tool to retrieve the state of applications and (to some extents) of
10
resources. As for Java applications-related monitoring information, the tool exploits
JVMPI, a two-way API between the JVM and a dedicated profiler agent. The agent fires
events upon Java thread state changes, beginning/ending of methods invocations, class
loading operations, and so on. For non-Java resources, instead, the API employs JNI to
invoke dynamic (platform-dependent) libraries methods. These methods extract
information about active processes, network utilization or file system conditions from
either the WinNT registry keys or the Unix /proc directory. WP4 is currently working
on the adaptation of this API to the IS-MANET context and to its integration within the
proposed middleware architecture.
Few research efforts addressing the development of a monitoring component for
MANET have already emerged. WANMon represents an original approach in that
context [6]. It aims at determining the employed resource amounts for routing purposes.
To this end, the network monitoring component provides not only statistics that
summarize sent/received packets, but even estimations of power consumption and
CPU/memory usage. WP4 is currently investigating the development of an innovative
Monitoring facility that permits to inspect not only device resources but also its context
(including its location) and to propagate gathered information to the application layer.
Finally, search and rescue scenarios could benefit from deployment of Wireless
Sensor Networks [7]. Wireless Sensor Networks are MANET composed by strictly
constrained devices, outfitted with sensors. Even if the IS-MANET project does not
focus on this kind of networks, it could be useful to explore the integration of
monitoring architectures in resource-limited devices. That could help improving our
external environment awareness.
The Advanced Facilities of the IS-MANET Middleware
This section describes the functions of the advanced middleware facilities. The
implementation of the advanced facilities has begun in the second project year and will
be concluded in the third project year.
Coordination. Emergency rescue scenarios call for the possibility to achieve adaptive
interactions between (possibly) new and previously unknown users. The required
support for enabling these interaction schemas calls for novel solutions that should
permit the coordination between the different communication parties.
The support for coordination implemented within the IS-MANET middleware is
composed by two main service incarnations. On the one hand, a publish/subscribe-based
support provide application developers with asynchronous request/response multicast
support has been implemented. A peculiarity of the implemented support is that it
permits publish and subscribe events on the basis of the current location of the user
[MI5].
On the other hand, a spatially distributed tuple-based coordination support has been
implemented. Entity coordination occur by injecting tuples into the network. The
different tuples are propagated accordingly to application-specific patterns to implicitly
reflect network and applications dynamics, as well as to reflect the evolution of
coordination activities. Application agents can locally “sense” tuples to acquire
11
contextual information, to exchange information with each other and to implicitly and
adaptively coordinate their activities [MO1].
Group Management. Emergency rescue scenarios call for group management solution
to support the development of collaborative applications by organizing co-located users
sharing common goals in impromptu coalitions. Traditional group communication
systems are designed to maintain global and synchronized views of all interacting
entities [10]. Usually, these groups are built on lists of currently active and connected
group members that tend to be distributed to all participants. When these membership
list changes, variations are advertised to all group members. However, traditional group
scenarios assume to operate in network environments with high bandwidth capacity and
with stable properties. Mainly, in communication environments where connections are
reliable, network partitions never or rarely occur, group member disconnection is
considered an exceptional event, and group members are likely not to change their
network point of attachment.
MANET undermine these assumptions. Frequent network partitions, user/device
disconnections and changes of location make inefficient and even unviable to ensure a
global and consistent view of all group members. Global agreement on group members
and consistency of group views may be not only unfeasible in MANET, but also
unnecessary in most envisioned application scenarios. Let us consider emergency rescue
users located in the same network locality. It is reasonable to suppose that they are
likely to reciprocally collaborate more often than with members located in different
physical network areas. In these cases only the direct visibility of the locally available
group members may be needed.
The IS-MANET Group Management facility provides APIs to create/dissolve
groups, to allow entities join/leave a group, and to create and disseminate group views
to the member entities. Each entity can dynamically promote at execution time the
formation of a group by specifying a group profile that expresses common goals,
activity and interests that must be commonly agreed by all members. Once a group of
interest is discovered, roaming entities may initiate the joining phase to affiliate. In
particular, during the joining phase, all entities provide the group management facility
with their user/device profiles. If the entity is allowed into the group, the facility returns
to the new entity the needed information including the group identifier and the
applicable view. The view contains the list of the only group members located within
the scope of a cluster. In particular, each view entry associates each group member
reference with user and device/group profile information. When members join or leave
the group, connects or disconnects from the network or when they change access device
and/or group profile, the IS-MANET middleware reports the view changes to all
interested group members within a cluster locality [BO1], [CT].
Data Storage & Dissemination. Data accessibility in MANET is a particularly relevant
issue within the IS-MANET project due to the need to deliver data including maps and
infrastructure plans to the different civil protection operators. The IS-MANET
middleware proposal introduces a Data Storage & Dissemination facility that provides
the required support for caching and data replication.
12
The lack of infrastructure in MANET settings along with frequent device mobility
drastically lower data availability. We cannot assume the continuous availability of a
central server for its client. Mobile devices have poor resources; hence, they cannot hold
local copies of all the needed data items. This situation requires the design of data
replication strategies and the management of disconnected operations. Data replication
is particularly important when the node mobility rate is high and hence network
partitioning is likely to occur frequently. Two different approaches are possible to avoid
permanent data losses. Proactive strategies consist in collecting information about the
current node location and the movement patterns to predict group partitioning [14].
Alternatively, they could allocate replicas such as to provide the highest possible
accessibility [15], e.g., by replicating data on strategic nodes. Reactive strategies consist
in entrusting nodes moving in the direction of disconnected network segments with
critical information. Both solutions are object of current investigations within the ISMANET framework [PI1].
Data replication raises consistency issues in case of conflicting update operations on
different copies of the same resource. In the last years, several solutions have been
proposed for disconnected operations on cellular networks [16, 17]. However, MANET
environments undermine the assumptions of these systems and call for innovative
solutions. WP4 is contributing to this research field by implementing an allocation
transparent support for disconnected operations. Nodes share available resources with
all the other nodes in the MANET environment. Each operation on the shared
information that affects data consistency is propagated to all interested nodes through
events [MI1, MI2, MI3].
MANET devices could request also information stored in repositories placed at
multi-hop distance. Frequent access to that data imposes a high communication burden,
thus producing possible link congestions, especially in the case of large file transfers
over multiple hop links. Those reasons justify the implementation of collaborative
caching on nodes. We have implemented a proxy-base file caching support based on
primary/secondary copies of web pages [GE2]. Devices hosting the primary copy can be
selected in many different ways, e.g. by considering their position or connectivity
characteristics. When a node requires a file, it can download its content from a primary
or a secondary copy. In the first case, the node can choose to store data locally and
make it available as a secondary copy.
A further incarnation of the data storage and dissemination facility has been
implemented. In particular, the implemented support allows to store files over a
MANET by maintaining a specified redundancy degree over the time, despite to node
mobility and failures [BO], [PI]. The file descriptor maintains information about the
placing of the file and about its coding schema. The file descriptors can either been
stored in the entity that has created the file or in a fully distributed fashion. WP4 is
currently evaluating the possibility to improve the current prototype in order to
implement optimizing strategies for replica placement [PI].
QoS Management. QoS represents an emerging field in MANET research. Several
research proposals illustrate scenarios requiring “some level of assurance” in service
delivery [11, ME1]. For instance, the IS-MANET search and rescue use case calls for
QoS support to enable fire fighters and civil protection operators to show captures of
13
current emergency situations. Fire fighters may need to carry out safety measures on
injured people under remote guidance, by video calling a central medical staff, while
waiting for qualified aid.
Different MANET applications require different QoS guarantees. Interactive
multimedia imposes constraints on delay and jitter, while audio/video streaming calls
for high available bandwidth. In MANET it is difficult to meet these requirements due
to the constrained nature of the networks. In fact, state-of-the-art wireless
communication technologies offer low bandwidth, high delay, and high error rates.
Moreover, participant devices have limited resources (processing power, memory size,
and power), thus imposing further constraints on service provisioning.
Recent researches show how MANET QoS Management issues need to be tackled
from lower communication layers. In fact, the infrastructure lack imposes distributed
mechanisms to achieve a fair channel assignment, while avoiding packet collisions.
CSMA/CA implemented in IEEE 802.11 DCF does not assure sufficient guarantees on
packet delivery delays. Afterwards, traditional routing operates in a connectionless
mode, thus intermediate nodes are not aware of associations between endpoints. For
QoS Management, instead, nodes should be aware of active flows and eventually
reserve resources. QoS routing needs to select source-destination paths, maximizing an
objective function [12]. This raises many issues stemming from link resources
monitoring (carried on in our middleware by the Monitoring facility) to route repairing
in response to link failures (due to node mobility or power depletions). Finally,
integrated and differentiated services do not offer suitable models for MANET. IntServ
per-flow provisioning results in high storage and processing overhead; DiffServ applies
to structured bounded networks since it requires the identification of ingress, egress, and
interior routers. Therefore, novel models, such as FQMM [13], have been recently
proposed to avoid the above problems.
To achieve a great efficiency in tackling all these issues, we are exploring crosslayer design to build the QoS Management facility. In the MANET context, this implies
integrating components that provide support services at different levels. First, we need a
QoS-aware routing implementation that establishes and maintains suitable paths. To
assure required QoS levels, that component should interface with Admission Control
and Resource Reservation facilities (e.g., Resource Broker [BO5], RSVP protocol
[ME2]). At provision time, a QoS adaptation module is useful to tailor the service to the
user device (e.g., QoS Adapters [BO5, ME2]). Finally, to verify that current service
provisioning meets the negotiated service requirements, the QoS Management facility
should exploit the Monitoring facility.
Emerging Guidelines and Lessons Learned
During the second year of the project, the WP4 implementation efforts fostered fruitful
discussions between the different research groups over middleware implementation
principles and led to first joint experimental experiences. WP4 has considered different
deployment scenarios, with different characteristics to exacerbate the requirements
stemming from the support to applications in MANET. In particular, we considered
14
three main scenarios i.e., pure MANET environments, wired-wireless integrated
environments, and highly heterogeneous wireless networks.
In pure MANET environments, all nodes are homogeneous from the point of view
of available resources (CPU, memory, battery, bandwidth, …), which are usually rather
limited. In these environments, typically the middleware support should be purely peerto-peer, without any point of centralization and without any privileged role among the
participating nodes.
In wired-wireless integrated environments, MANETs are wireless access networks
that extend (with either single- or multiple-hop wireless connectivity) the traditional
fixed Internet infrastructure. In these scenarios, the middleware support should
primarily consider the possibly abrupt changes in resource availability when passing the
edges between the wired Internet and the wireless MANET. The middleware should
organize and support service provisioning by deploying its components differently to
the differentiated participating nodes, e.g., by placing complete middleware
configurations at the wired-wireless network edges over the fixed Internet (where it is
crucial to smooth the resource discontinuities by properly downscaling service
provisioning) and more lightweight middleware configurations over resourceconstrained wireless nodes.
Finally, in highly heterogeneous wireless networks, very different connectivity
technologies interwork to compose an integrated network infrastructure and the resource
differentiation of involved nodes is pushed to the extreme. For example, MANET
environments that integrate usual IEEE 802.11 connectivity with satellite network links
will be more and more usual in the following days, e.g. in emergency response scenario
where it is necessary to orchestrate rescue operations between different teams
distributed in large areas. In these environments, the middleware support has to
recognize the indispensable centralized role of some nodes that act as gateways among
more traditional pure MANET localities.
The different characteristics of the above introduced scenarios require the different
middleware support functions to address different issues. The joint efforts within the
WP4 permitted to design and implement middleware solutions capable to adapt their
behavior accordingly to the current situation of the service provisioning environment. In
addition, the available service prototypes permit to reduce the use of resources such as
memory, CPU, and battery on constrained devices.
With the term adaptation we mean the possibility for the middleware to change its
behavior according to the environment where the user is currently operating. Two main
factors should be taken into account in order to provide an adaptive middleware solution
for mobile ad-hoc environments. First of all, it is necessary to provide suitable support
for context awareness. On the one hand, context awareness is particularly important in
order to efficiently implement middleware services. For instance, the awareness of the
available battery information is crucial for basic facilities such as routing and cluster
head designation. On the other hand, context awareness permits to decide which are the
middleware components that better fit the current operating context to adapt the
middleware accordingly. For example, when a user moves from a pure MANET
scenario to a wired-wireless integrated one, the middleware should be able to tailor the
service behavior accordingly. Finally, we claim that the required support for context
awareness should be able to provide the full visibility of context information up to the
15
application layer in order to enable the development of self-adaptive context-dependent
distributed applications even in MANET environments, which is emerging as a ultimate
ambitious goal of the project.
In addition to context awareness, adaptation requires implementing the middleware
in terms of different modules that are specifically tailored to fit the peculiar
characteristics of the operating environment and of application requirements. We
adopted a modular implementation of the middleware that permits to decide and install
different configurations of the middleware facilities, thus configuring and reconfiguring its architecture at run-time. For example, the required naming support for
pure MANET environments should operate according to a peer-to-peer model and
should address problems related to frequent network merging and partitioning. Wiredwireless networking infrastructures, instead, may benefit from more traditional supports
based on the client-server model that permit the deployment of naming service on the
wired infrastructure. In the above example, the middleware should be capable of
installing and using the appropriate naming support according to the current operating
environment.
The need for providing suitable support for MANET applications on portable
constrained devices call for solution that keep into account CPU, memory and battery
utilization. First of all, it is necessary to benefit from the visibility of device
characteristics to delegate CPU/memory intensive task to nodes with richer capabilities
within the network. This permits to balance computational load between different
participating nodes in order to not overload constrained ones. In addition, it is necessary
to careful consider the battery degradation. In particular, the middleware should
minimize the number of exchanged messages and should aggregate together several
messages to reduce network-related energy costs. In addition, the implementation
should include energy-efficient algorithms and data structures that permit to reduce the
processing-related energy consumption.
Finally, other minor directions of research work, which WP4 will follow in the
remaining months of the project, relate to relevant (but subordinate) challenging issues,
such as flexibly and effectively guaranteeing the suitable level of security and
supporting the dynamic extension/update/deployment of middleware and service
components via code mobility mechanisms specialized for MANET. MANET-specific
security solutions should take into account the resource limitations of MANET nodes
and should enable highly decentralized distributed trust models, for instance, to avoid
the need for continuous connectivity with an external and centralized certificate
authority. Code mobility mechanisms are crucial, as previously stated in the deliverable,
for the dynamic deployment of differentiated middleware configurations. MANET force
to re-think code mobility solutions explored for traditional distributed systems, to
maximize the exploitation of the scarce bandwidth/battery resources and to address also
very limited MANET nodes that, for instance, cannot host the full version of the Java
virtual machine.
16
References to IS-MANET WP4 Publications
(grouped according to research units)
[BO1]
[BO2]
[BO3]
[BO4]
[BO5]
[BO6]
[CT1]
[GE1]
[GE2]
[ME1]
[ME2]
[MI1]
[MI2]
[MI3]
D. Bottazzi, A. Corradi, R. Montanari, "A Context-Aware Approach to Group
Communication in Dynamic Ad-Hoc Environments", Proc. 2nd Int. Conf.
Wired/Wireless Internet Communications (WWIC’03), Frankfurt, Germany,
Feb. 2004.
P. Bellavista, A. Corradi, E. Magistretti, “Proxy-based Middleware for Service
Continuity in Mobile Ad Hoc Networks”, Proc. of the 4th Italian Workshop
"From Objects to Agents: Intelligent Systems and Pervasive Computing"
(WOA'03), Cagliari, Italy, Sep. 2003.
P. Bellavista, A. Corradi, R. Montanari, C. Stefanelli, “Dynamic Binding in
Mobile Applications: a Middleware Approach”, IEEE Internet Computing,
Special Issue on "Mobile Applications", Vol. 7, No. 2, Mar.-Apr. 2003.
P. Bellavista, A. Corradi, C. Stefanelli, “Java for On-line Distributed
Monitoring of Heterogeneous Systems and Services”, The Computer Journal
Oxford Press, , Nov. 2002.
P. Bellavista, A. Corradi, “Mobile Middleware Solutions for the Adaptive
Management of Multimedia QoS to Wireless Portable Devices”, Proc. IEEE
WORDS’03, Capri, Italy, Sep. 2003.
D. Bottazzi, A. Corradi, R. Montanari, "A Location-Aware Group
Membership Middleware for Pervasive Computing Environments", Proc. 8th
Int. Symp. Computer and Communications (ISCC’03), Antalya, Turkey, June
2003.
O. Tomarchio, M. Bisignano, A. Calvagna, G. Di Modica, “ExPeerience: a
JXTA Middleware for Mobile Ad-Hoc Networks”, Proc. IEEE P2P’03.
A. Clematis, D. D'Agostino, V. Gianuzzi, “A Local Decision Algorithm for
Maximum Lifetime in Ad Hoc Networks”, Proc. EUROPAR’02.
V. Gianuzzi, “File Distribution and Caching in MANET”, DISI Technical
Report, 2003.
M. Guarnera, M. Villari, A. Zaia, A. Puliafito, “MANET: Possible
Applications with PDA in Wireless Image Environment”, Proc. IEEE
PIMRC’02.
D. Bruneo, M. Villari, A. Zaia, A. Puliafito, “VOD Services for Mobile
Wireless Devices”, Proc. 8th Int. Symp. Computer and Communications
(ISCC’03), Antalya, Turkey, June 2003.
P. Costa, G. Cugola, M. Migliavacca, “Epidemic Algorithms for Reliable
Content-Based Publish-Subscribe: an Evaluation”, Proc. 24th Int. Conf.
Distributed Computing Systems (ICDCS’04), Tokyo, Japan, Mar. 2004.
P. Costa, G. Cugola, M. Migliavacca, “Introducing Reliability in ContentBased Publish-Subscribe through Epidemic Algorithms”, Proc. 2nd Int.
Workshop on Distributed Event-Based Systems (DEBS'03), San Diego, USA,
June 2003.
G. Cugola, A.L. Murphy, “Efficient Content-Based Event Dispatching in
Presence of Topological Reconfigurations”, Proc. 23rd Int. Conf. Distributed
Computing Systems (ICDCS’03), Providence, USA, May 2003.
17
[MI4]
G. Cugola, D. Frey, and A.L. Murphy, “Minimizing the Reconfiguration
Overhead in Content-Based Publish-Subscribe”, Proc. 19th ACM Symp.
Applied Computing (SAC’04), Nicosia, Cyprus, Mar. 2004.
[MI5] G. Cugola, A.L. Murphy, “Towards Dynamic Reconfiguration of Distributed
Publish-Subscribe Systems”, Proc. 3rd Int. Workshop Software Engineering
and Middleware (SEM’02), Orlando, USA, May 2002.
[MO1] M. Mamei, F. Zambonelli, “Programming Pervasive and Mobile Computing
Applications with the TOTA middleware”, Proc. IEEE PERCOM’04.
[PI1]
S. Chessa, P. Maestrini, “Dependable and Secure Data Storage and Retrieval
in Mobile, Wireless Networks”, Proc. IEEE DSN’03.
[RM1] M. Patini, R. Beraldi, C. Marchetti, R. Baldoni, “A Middleware Architecture
for Inter ad-hoc Networks Communication”, Proc. MMIS’03-WISE’03, Rome,
Italy, Dec. 2003
Non-IS-MANET References
[1]
V. Rodoplu, T. H. Meng, “Minimum Energy Mobile Wireless Networks”, IEEE
JSAC, Aug. 1999.
[2] T. Sheltami, H. T. Mouftah, “An Efficient Energy Aware Clusterhead Formation
Infrastructure Protocol”, Proc. 8th Int. Symp. Computer and Communication
(ISCC’03), Turkey, June 2003.
[3] M. Fischer, N. A. Lynch, M. S. Paterson, "Impossibility of Distributed Consensus
with One Faulty Process", Journal of the ACM (JACM), Vol. 32, No. 2, Apr. 1985.
[4] A. Rowstron, P. Druschel, "Pastry: Scalable, Distributed Object Location and
Routing for Large-scale Peer-to-peer Systems", Proc. 4th Int. Conf. Distributed
Systems Platforms (Middleware), Germany, Nov. 2001.
[5] B. Williams, T. Camp, “Comparison of Broadcasting Techniques for Mobile Ad
Hoc Networks”, Proc. 3rd ACM Int. Symp. Mobile Ad Hoc Networking &
Computing (MobiHoc2002), Lausanne, Switzerland, June 2002.
[6] Don Ngo, N. Hussain, M. Hassan, J. Wu, “WANMon: a Resource Usage
Monitoring Tool for Ad Hoc Wireless Networks”, IEEE ICLCN’03.
[7] I. Akyildiz, S. Weilian, Y. Sankarasubramaniam, E. Cayirci, Special Issue of IEEE
Communications Magazine, Aug. 2002.
[8] G. Picco, A. L. Murphy, G.-C. Roman, “Lime: Linda Meets Mobility”, Proc. 21st
Int. Conf. Software Engineering (ICSE’99), California, May 1999.
[9] C. Mascolo, L. Capra, S. Zachariadis, W. Emmerich, “XMIDDLE: a Data-Sharing
Middleware for Mobile Computing”, Kluwer Personal and Wireless
Communications Journal, Vol. 21, No.1, Apr. 2002.
[10] D. Powell (ed.), “Group Communication”, Special Issue on Group
Communications, Communications of the ACM, Vol. 49, No.4, Apr. 1996.
[11] QoS Forum, “QoS Protocols and Architectures”, White Paper of the QoS Forum,
Jul. 1999.
[12] S. Chakrabarti, A. Mishra, “Quality of Service in Mobile Ad Hoc Networks”,
Handbook of Ad Hoc Wireless Networks, CRC Press, 2003.
18
[13] X. Hannan, C. K. Chaing, S. K. G. Winston, “Quality of Service Models for Ad
Hoc Wireless Networks”, Handbook of Ad Hoc Wireless Networks, CRC Press,
2003
[14] K. Chen, K. Nahrstedt, “An Integrated Data Lookup and Replication Scheme in
Mobile Ad Hoc Networks”, Proc. SPIE ITCom, 2001.
[15] T. Hara, “Effective Replica Allocation in Ad Hoc Networks for Improving Data
Accessibility”, Proc. IEEE INFOCOM, 2001.
[16] M. Satyanarayanan, “Coda: A Highly Available File System for a Distributed
Workstation Environment”, Proc. IEEE WWOS, 1989.
[17] A.J. Demers, K. Petersen, M.J. Spreitzer, D.B. Terry, M.M. Theimer, B.B. Welch,
“The Bayou Architecture: Support for Data Sharing among Mobile Users”, Proc.
IEEE WMCSA, 1994.
19
Appendix A
Appendix A reports the detailed descriptions of the research activities of the different
participating research units, listed in research unit alphabetical order. In particular, the
reports indicate the research results and the research contributions of each research unit
to the implementation of the different middleware services resulting from the WP4
work in the first two years of the IS-MANET project.
20
Unità di Ricerca: DISI Università di Genova
Collocazione dell’attività di ricerca
all’interno del WP4
Progetto di middleware per il supporto dell'accesso WEB a file distribuiti su MANET,
tramite Proxy Cache.
1) Obiettivo
L'obiettivo di questa attività è lo studio e sviluppo di un sistema di accesso a file
distribuiti su rete wireless ad-hoc che consenta di ottenere:
(a) la localizzazione delle informazioni (dove questa e' richiesta) attraverso caching, in
modo da minimizzare la quantita' di energia e di tempo di latenza necessari per il
trasferimento del file
(b) load-balancing delle copie di file nei terminali mobili per evitare l'overloading delle
unita' mobili che sono owner di file molto richiesti, cosa che porterebbe ad un maggiore
sovraccarico energetico in caso di richiesta di tali file.
2) Descrizione della attività
(a) Sviluppo di strumenti di supporto e monitoraggio del sistema reale per l'analisi dello
stato del sistema e del consumo energetico relativamente a varie modalita' di
funzionamento radio.
(b) Sviluppo di moduli software per la simulazione del sistema all'interno del simulatore
ns-2.
(c) Realizzazione di un sistema software di proxy per il raggiungimento dell'obiettivo
sopraesposto, nell'ambito di un sistema di accesso WEB ai file, che consenta il
download e upload di file distribuiti.
3) Stato e prospettive di sviluppo ed evoluzioni
Sono stati sviluppati:
(1) Il sistema di Proxy Cache MobEYE che supporta l'accesso attraverso browser a
pagine HTML replicate in modo adattativo sulla MANET. Il sistema e' basato sullo
sniffing dei messaggi radio.
(2) Un'interfaccia di supporto che consente di monitorare l'utilizzo della cache sui vari
nodi del sistema, nonche' lo scambio dei messaggi effettuati durante la contrattazione
per l'accesso alla stessa per il download di file.
(3) Un insieme di moduli software per la simulazione del sistema sotto ns2. Sono in
corso di sviluppo test di simulazione per la validazione del prodotto e la valutazione
della performance.
È anche in corso un'analisi dell'applicabilità del sistema in ambiente MANET
scarsamente denso, in cui le comunicazioni avvengono in modalita' "epidemica".
4) Collaborazioni in atto, previste e prevedibili
21
Collaborazione in atto con ISTI (Pisa) per integrare i due sistemi di gestione di file
distribuiti tramite frammentazione (ISTI) e di accesso agli stessi tramite proxy cache.
E' stata approfondita la possibilita' di utilizzare in MobEYE pagine WEB memorizzate
nel FS distibuito DS2 che utilizza frammentazione e codici di criptazione, arrivando alla
definizione di un prototipo software.
E' infine prevista la collaborazione con le unita' di Messina e Catania, per la
comunizione di streaming multimediali.
Scheda Prodotto
MobEYE (Mobile intErcepting proxY cachE system)
1) Descrizione
MobEYE e' un prototipo di middleware che consente di utilizzare come proxy cache
all'interno di un ambiente WEB, le unità mobili che installano il sistema (non
necessariamente tutte quelle della rete). Qualora le richieste di file arrivino
frequentemente da una data area, consente di localizzare copie di tale file in modo da
risparmiare sull'energia spesa per il trasferimento e il tempo di latenza.
2) Funzionalità principali
MobEYE consente l'intercettazione di richieste di file da parte di nodi intermedi del
path fra il client e l'owner del file. Le copie possono essere memorizzate all'interno della
cache del client o di nodi intermedi, scelti con un algoritmo opportuno. L'intercettazione
puo' essere estesa a tutti i nodi che cadono nel rango della trasmissioni dei nodi
appartenenti al routing path verso l'owner.
3) Vincoli di hardware, sistema operativo, software da utilizzare
Il prototipo di MobEYE è stato collaudato sia su Linux (laptop o palmari, con Linux
Familiar) eche su Windows (laptop) ed scritto in C (compilatori di distribuzione e
Cross-Arm per Linux Familiar).
4) Aderenza e rispetto di standard (di qualunque tipo)
Protocolli HTTP e UDP. Estensione per le funzionalità MANET del protocollo ICP
(Inter Caching Protocol). Per il sistema e' stato usato il protocollo di routing OLSR,
open source e largamente utilizzato, ma puo' funzionare con qualsiasi altro protocollo,
in quanto non richiede scambio di informazioni con il livello di rete.
5) Disponibilità via Web, documentazione varia, ecc.
Sul sito
http://SEALab.disi.unige.it/Krakatoa/MobEYE
sono disponibili:
• Codice per il download di MobEYE con manuale di installazione e di uso
(versione 1 e 2, ampliata con interfaccia per la verifica del protocollo)
• Codice di simulazione sotto ns2
• Documento di studio di fattibilita' dell'interfacciamento di MobEYE con DS2
Maggiori e piu' dettagliate informazioni sono disponibili sul sito
22
http://SEALab.disi.unige.it/Krakatoa/ismanet.html
Attivita' collaterali
Il sistema MobEYE e' stato collaudato su una MANET relalizzata utilizzando il
protocollo di rete OLSR. Per una corretta valutazione dell'operativita' del sistema
hardware e software, e' stato utilizzato un ambiente che riproduce uno degli scenari
proposti dal progetto, e sono stati eseguiti un insieme di test per: (i) la valutazione dei
tempi di latenza dell'algoritmo di routing, (ii) le prestazioni relative a 2 tipi di antenne
differenti, (iii) la qualità del segnale per verificare la possibilita' di trasferimenti di file
audio. I risultati sono esposti in un deliverable del progetto.
23
Unità di Ricerca: Politecnico di Milano
Collocazione del sistema REDS
all’interno dell’architettura di riferimento WP4
SERVIZI di BASE
Addressing: si assume che ai diversi nodi della rete (MANET
o fissa) siano assegnati indirizzi ip distinti attraverso opportuni
protocolli.
Broker e client REDS: ogni nodo REDS (broker o client) ha
un’identificatore univoco assegnato dal middleware.
Trattandosi di un middleware P/S content-based non esiste in
REDS alcun concetto di canale o subject che richieda
meccanismi di naming.
Se configurato per operare una rete fissa, REDS assume la
ROUTING
presenza di un sottosistema di routing IP. Se configurato per
operare su MANET, REDS non richiede alcun protocollo di
routing. Fornisce un supporto alla comunicazione P/S
attraverso meccanismi di routing diversi a seconda dei moduli
di routing utilizzati (message o subscription forwarding su uno
spanning tree costruito e mantenuto dinamicamente, più
protocolli probabilistici in fase di implementazione.
COMMUNICATION REDS realizza un sistema di comunicazione P/S contentbased. Rispetto ai tradizionali sistemi P/S, oltre a meccanismi
per gestire mobilità e riconfigurazione dinamica della
topologia di dispatching, fornisce anche il supporto a messaggi
con risposta. E’ possibile sottosriversi e rispondere ai messaggi
ricevuti a seguito di tali sottoscrizioni. Il middleware si
incarica di collezionare le risposte per restituirle al
pubblicatore. Ciò consente una comunicazione di tipo
richiesta-risposta asincrona e multicast, accanto al classico
modello P/S. Un ulteriore modulo di REDS (location-router),
se istallato, può fornire supporto a sottoscrizioni e
pubblicazioni basate su locazione.
Quando configurato per MANET, REDS può beneficiare di
ALLOCATION/
notifiche provenienti dai protocolli di più basso livello
DEALLOCATION
(IEEE802.11) per conoscere lo stato dei nodi vicini
(raggiungibili in un hop) o può utilizzare un proprio
meccanismo di HELLO.
Un opportuno “location-router”, se istallato in REDS, fornisce
LOCATION
supporto a sottoscrizioni e pubblicazioni basate sulla locazione
AWARENESS
dei nodi. Per operare richiede da parte di ogni nodo la
conoscenza della propria posizione, attraverso l’uso di GPS o
NAMING
24
MONITORING
analoghi sistemi di autorilevazione della posizione.
Sono attualmente in fase di studio meccanismi che consentano
ad una rete di broker REDS di monitorare il traffico al fine di
riconfigurare la propria topologia per minimizzare lo stesso.
SERVIZI AVANZATI
--GROUP
MANAGEMENT
COORDINAMENTO REDS realizza diversi modelli di coordinamento: P/S contentbased, P/S con risposte, P/S location aware.
--DATA STORAGE/
DISSEMINATION
--QoS
MANAGEMENT
25
Unità di Ricerca: Università di Catania
Collocazione del sistema JMOBIPEER
SERVIZI di BASE
NAMING
Addressing: l’architettura JMOBIPEER assegna ai singoli
nodi (Peer) della rete indirizzi logici unici e conformi allo
standard JXTA. Tale forma di indirizzamento permette di
astrarre completamente dalla locazione fisica del nodo
all’interno della rete. In particolare un peer viene identificato
principalmente mediante il suo identificatore (PID) e il suo
gruppo di appartenenza (GID); altre informazioni sono: il
nome, una breve descrizione e i protocolli di comunicazione
mediante i quali è possibile raggiungere il peer stesso.
Risorse: le risorse (peer, gruppi, servizi) sono identificate
mediante un ID univoco. Per rendere visibile la risorsa nella
rete viene pubblicato uno specifico documento XML
(advertisement) contenente tutte le informazioni necessarie per
localizzare e usare la risorsa.
ROUTING
La modularità dell’architettura JMOBIPEER permette
l’utilizzo di un qualsiasi algoritmo di routing per MANET.
L’implementazione di default fornisce il supporto alla
comunicazione multi-hop utilizzando un protocollo di
flooding limitato in cui la pubblicazione e la ricerca delle
risorse è ristretta a un numero finito di hop dalla sorgente.
COMMUNICATION JMOBIPEER supporta i protocolli di comunicazione TCP/IP,
HTPP e DATAGRAM. I messaggi (advertisement) vengono
scambiati tramite pacchetti TCP unicast o UDP
broadcast/multicast (limitato). In particolare JMOBIPEER
prevede due tipi di comunicazione:
• One-hop che consente la comunicazione punto-punto.
Questo tipo di comunicazione viene utilizzata nel caso
in cui i peer che devono comunicare sono direttamente
visibili (stessa rete) tra loro.
• Multi-hop che consente la comunicazione tra peer non
direttamente visibili (rete diversa).
ALLOCATION/
DEALLOCATION
La pubblicazione degli advertisement è l’unico modo per
rendere disponibile una specifica risorsa all’interno della rete.
26
LOCATION
AWARENESS
MONITORING
Tale pubblicazione prevede lo scambio di advertisement
all’interno di della rete a tempi regolari. Qualora
l’advertisement di una risorsa non arrivi entro un certo tempo
si assume che tale risorsa (peer, gruppo, servizio) non sia più
disponibile/accessibile.
Nella versione corrente di JMOBIPEER non è implementato
nessun meccanismo per la gestione della località.
---
SERVIZI AVANZATI
JMOBIPEER fornisce il supporto necessario alla creazione di
nuovi gruppi, al discovery dei gruppi localmente disponibili e
al join in gruppi di interesse. JMOBIPEER fornisce gli
strumenti per la gestione di tutti gli aspetti relativi a un gruppo
di appartenenza quali la creazione di nuove risorse nel gruppo,
la lista delle risorse del gruppo, l’attivazione/disattivazione di
protocolli di comunicazione
COORDINAMENTO ----DATA STORAGE/
DISSEMINATION
--QoS
MANAGEMENT
GROUP
MANAGEMENT
27
Unità di Ricerca: Università di Bologna e Ferrara
Collocazione del sistema AGAPE
SERVIZI di BASE
Addressing: si assume la possibilità di assegnati indirizzi IP
(ed eventualmente modificarli dinamicamente) attraverso
protocolli di autoconfigurazione (PMWRS, MANETconf,
ecc.).
Entità AGAPE: i gruppi AGAPE sono caratterizzati da un
identificatore (supposto statisticamente unico) ottenuto tramite
una funzione random. Ogni membro di un gruppo AGAPE è
caratterizzato da un identificatore che viene assegnato
all’ingresso nel gruppo. Questo identificatore identifica ogni
membro in modo statisticamente unico all’interno del gruppo e
viene generato tramite una funzione random.
AGAPE richiede la presenza di un qualunque protocollo di
ROUTING
routing unicast per ambienti ad-hoc. Inoltre fornisce un
supporto alla comunicazione multipoint costituito da un
protocollo di flooding probabilistico limitato in cui la
disseminazione delle informazioni è ristretta ad un numero
finito di network hop dalla sorgente.
COMMUNICATION AGAPE fornisce un supporto context-aware alla
comunicazione basato su scambio di messaggi. In particolare
AGAPE introduce due pattern di comunicazione:
• Context-based any-cast che consente la comunicazione
punto-punto. In particolare, questo pattern di comunicazione
consente di individuare il destinatario dei messaggi sulla base
dei suoi attributi e caratteristiche.
• Context-based multi-cast che consente la comunicazione
multi-point. In particolare, questo pattern di comunicazione
consente di consegnare uno stesso messaggio a tutte le entità
co-locate che verificano determinati attributi e caratteristiche.
Il supporto di AGAPE alla comunicazione include inoltre la
possibilità di effettuare lo scheduling dei messaggi sulla base
di informazioni di contesto quali le preferenze utente. Inoltre
AGAPE permette anche l’adattamento del formato dei
messaggi scambiati fra le diverse entità sulla base delle
caratteristiche dei dispositivi utente.
NAMING
ALLOCATION/
DEALLOCATION
Vengono scambiati advertisement all’interno di una località di
rete a tempi regolari. Qualora l’advertisement di una entità non
28
LOCATION
AWARENESS
MONITORING
arrivi entro un certo tempo si assume che l’entità si sia
disconnessa.
In AGAPE si identificano due ruoli che un membro può
coprire. Le Managed Entities (ME) e le Locality Manager
Entities. In particolare, ogni LME definisce una località di rete
per cui ha l’onere della gestione del gruppo. La località è
definita come l’insieme dei membri del gruppo i cui dispositivi
distano dall’LME un numero dato di network hop.
Ad istanti di tempo regolari le diverse entità spediscono degli
advertisement che contengono diverse informazioni quali gli
identificatori di gruppo ed entità e l’indirizzo IP. L’LME della
località beneficia della visibilità degli advertisement
disseminati dai membri del suo gruppo per determinare
l’insieme di membri correntemente disponibili.
---
SERVIZI AVANZATI
AGAPE fornisce il supporto necessario alla creazione di
nuovi gruppi on-demand, abilita discovery dei gruppi
localmente disponibili e consente a nuovi membri di
entrare/uscire da gruppi di interesse. AGAPE fornisce a ogni
membro la context-dependent view della località. La contextdependent view include diverse informazioni ed, in
particolare, la lista di tutti i membri del gruppo correntemente
co-locati.
COORDINAMENTO ----DATA STORAGE/
DISSEMINATION
La disseminazione delle context dependent view avviene a
QoS
tempi regolari. Se da un lato un intervallo molto breve fra la
MANAGEMENT
disseminazione di una vista e la successiva consente di fornire
la visibilità dei membri della località anche in condizioni
altamente dinamiche, dall’altro questo comporta un notevole
overhead. AGAPE consente di variare dinamicamente
l’intervallo di tempo fra una vista e la successiva in base alla
attuale situazione di rete. In particoalre, se il numero di
variazioni rispetto alla vista precedente supera una determinata
soglia percentuale, allora l’intervallo fra le trasmissioni di
viste consecutive viene ristretto. Analogamente, nel caso in
cui il numero di variazioni rispetto alla vista precedente sia
inferiore ad una determinata soglia percentuale l’intervallo
viene allargato.
GROUP
MANAGEMENT
29
Unità di Ricerca: Università di Bologna e Ferrara
Collocazione del sistema REDMAN
SERVIZI di BASE
Nodi
Per quanto riguarda questo aspetto, REDMAN
presuppone che ai nodi vengano assegnati indirizzi IP unici
attraverso protocolli di autoconfigurazione (PMWRS,
MANETconf, ecc.). Gli indirizzi IP vengono usati
direttamente per mantenere ai livelli superiori riferimenti alle
entità interagenti.
Risorse Il naming delle risorse non è invece ancora stato
approfondito a sufficienza. Finora si è supposto che ciascuna
risorsa fosse identificata da un valore testuale.
REDMAN non è legato a nessun particolare algoritmo di
ROUTING
instradamento. Nella fase di configurazione della rete
(identificazione della dense MANET ed elezione del nodo
manager) e distribuzione/ritrovamento delle risorse non vi è
necessità di supporto alla comunicazione multi-hop, in quanto
le interazioni avvengono solo su scala locale. Nella fase di
maintenance del numero delle repliche invece è necessario
supporre la presenza di un (qualunque) protocollo di routing
sottostante.
COMMUNICATION I messaggi vengono scambiati tramite pacchetti UDP unicast o
broadcast (limitato).
ALLOCATION/
• Ruoli
DEALLOCATION
o L’algoritmo di identificazione delle dense MANET
richiede che i nodi appartenenti aggiornino il
numero dei vicini in diretta visibilità. In tal modo
possono essere identificate situazioni in cui il
numero di vicini diviene inferiore alla soglia
stabilita, impedendo quindi ai partecipanti di far
parte del nucleo denso. REDMAN implementa
questa funzionalità attraverso il broadcast di
HELLO packet periodici da parte dei nodi.
o In seguito alla sua elezione, il manager può
abbandonare la zona centrale della rete. Per questo
proponiamo due strategie:
Reattiva Il manager rivaluta la propria
posizione ad intervalli Tr
Proattiva Il manager delega il proprio
ruolo lanciando una nuova elezione ad
NAMING
30
LOCATION
AWARENESS
MONITORING
intervalli Tp>>Tr
• Identificazione dei nodi appartenenti alla dense
MANET Un nodo decide di appartenere alla dense
MANET nel caso il numero dei suoi vicini sia superiore ad
un prefissato valore di soglia. Un algoritmo distribuito è
stato proposto a tal fine.
• Elezione del replica manager REDMAN mira ad
identificare un nodo collocato in posizione centrale nella
rete cui assegnare il ruolo di replica manager. Alcune
strategie euristiche hanno permesso di determinare una
soluzione con overhead limitato.
• Determinazione dei nodi più lontani L’algoritmo di
elezione del manager prevede che i nodi esplorati
determinino quali appartenenti alla dense MANET sono
collocati alla massima distanza da essi (e quali vicini 1-hop
si trovano in direzione dei nodi più lontani). REDMAN
propone una soluzione distribuita.
REDMAN attualmente non si preoccupa del monitoring delle
risorse.
SERVIZI AVANZATI
REDMAN non mira a gestione di gruppi, coordinamento e
GROUP
QoS management.
MANAGEMENT
COORDINAMENTO
QoS
MANAGEMENT
DATA STORAGE/
• Determinazione del grado di replicazione Quando un
DISSEMINATION
nodo entra in una dense MANET, esso invia una
descrizione delle proprie risorse al manager che determina
per ciascuna di esse il grado di replicazione (restano da
approfondire i criteri per la scelta di detto grado). Il
manager mantiene una SharedResourceTable contenente
per ogni risorsa la lista (lazy consistent) dei nodi che
(probabilmente) sono in possesso di una copia.
• Data dissemination/retrieval REDMAN prevede che le
risorse (read-only) vengano distribuite e ritrovate
attraverso
protocolli
altamente
decentralizzati.
Dissemination/retrieval di repliche sono aspetti
strettamente correlati, ed in tal senso vengono
implementati tramite strategie duali. Le strategie proposte
prevedono che i nodi che inoltrano le risorse durante la
fase di replicazione mantengano IRP (information on
replica placement) che permettano loro di rispondere ai
31
•
messaggi di ricerca. Secondo tali strategie, i nodi che
decidono di mantenere copie delle risorse devono
comunicare la decisione al manager, in modo che esso
possa aggiornare la sua SharedResourceTable.
REDMAN propone due diverse soluzioni:
o Gossip-based La distribuzione avviene inoltrando
ricorsivamente le risorse a vicini che possono
decidere o meno di mantenerne copie. La ricerca si
basa su una strategia expanding ring.
o Rows-Columns
Repliche ed IRP vengono
disseminati su nodi appartenenti a linee
“topologicamente” rette. La fase di ricerca tenta di
coinvolgere nodi appartenenti a linee che
intersechino le linee di disseminazione.
Mantenimento del grado di replicazione delle risorse Il
protocollo di gestione delle repliche tenta di riassegnarle in
caso nodi “delegati” (ossia in possesso di almeno una
replica) abbandonino la rete. Sono state individuate tre
situazioni:
o Il delegate si rende conto di muoversi verso
l’esterno della rete Esso “scarica” le proprie
risorse ad un vicino.
o Il delegate si rende conto di essere uscito dalla
rete quando oramai è fuori dalla dense MANET
Esso comunica al manager il proprio abbandono. Il
manager richiede ad uno dei nodi nella
SharedResourceTable di diffondere una nuova
replica della risorsa.
o Il delegate fallisce
Ad intervalli di tempo
periodici i nodi devono comunicare la propria
presenza e la lista delle proprie risorse al manager.
Nel caso il manager non riceva l’update atteso da
parte di un nodo, esso si comporta come al punto
precedente.
32
Unità di Ricerca: Università di Messina
Collocazione dell’attività di ricerca
all’interno del WP4
Il WP4 prevede la realizzazione di un middleware per l’interscambio di informazioni in
ambito Ad Hoc, all’interno di uno scenario di Disaster Recovery. Alla luce delle
problematiche riscontrate nel suddetto contesto, l’Unità Operativa-Università di
Messina, può fornire un contributo sia implementativo che teorico, con le seguenti
attività:
1. Media Server JXTaDoK
2. Information Dissemination context: CCID
La prima attività (implementativa) riguarda la realizzazione di una piattaforma basata su
JXTA in grado di implementare su una rete Ad Hoc un Server Multimediale distribuito
e totalmente trasparente ai generici client multimediali necessari per la riproduzione di
streaming. La seconda attività (teorica) concerne lo studio di nuovi algoritmi necessari
alla disseminazione delle informazioni in ambiente MANET; si e’ pensato di analizzare
le questioni riguardanti l’Information Dissemination in rete Ad Hoc, attraverso lo
strumento simulativo NS2.
L’apporto teorico si e’ reso necessario per l’ottimizzazione del comportamento della
parte implementata, in special modo si sono ricercate delle tecniche innovative di
distribuzione dei frammenti multimediali. Attualmente l’approccio di distribuzione
seguito dalla piattaforma realizzata, poggia su normale flooding dell’informazione.
1. Media Server JXTaDoK
Le problematiche che si è cercato di risolvere, attraverso questa piattaforma, sono quelle
dell’immagazzinamento, transcodifica e visione di contenuti multimediali in reti AdHoc. Tali aspetti sono infatti di cruciale importanza in un contesto altamente dinamico
ed eterogeneo. Coesisteranno infatti, dispositivi con caratteristiche di computazione,
immagazzinamento e visualizzazione molto limitati quali ad esempio PDA e
SmartPhones e potenti Laptop presenti su nodi privilegiati quali mezzi di soccorso o
campi base. In questa situazione l’informazione multimediale dovrà essere
dinamicamente adattata alle capacità, anche temporanee dei dispositivi in gioco in
maniera tale da ottimizzare le risorse globali della rete.
Un meccanismo di transcodifica distribuito si rende essenziale al fine di non delegare
questa onerosa operazione a dispositivi con risorse limitate e nel contempo consente di
non generare inutile traffico sui vari link coinvolti nella comunicazione.
L’immagazzinamento delle informazioni multimediali sarà effettuato attraverso la loro
frammentazione e successiva disseminazione su tutti i nodi della rete privilegiando
quelli dotati di una posizione topologica, di risorse o di ruoli favorevoli.
33
Si vuole proporre a tale scopo un middleware basato su JXTA che consenta di
implementare su una rete Ad-Hoc un Server Multimediale distribuito e totalmente
trasparente al fine di non intervenire su ciascun specifico software di riproduzione.
Al fine di illustrare le funzionalità di questo sistema si individuano tre eventi:
1. Il contenuto multimediale è già disponibile e deve essere inserito nella rete AdHoc da un nodo
2. Il contenuto è frutto di una registrazione live da parte di uno o più nodi
3. Il contenuto deve essere visionato da un qualunque nodo
Nel primo evento (già implementato) il contenuto multimediale viene inserito da un
utente e, dopo essere stato frammentato in piccoli spezzoni, viene suddiviso sui nodi
componenti la rete ed eventualmente processato.
Nel secondo evento (implementato in parte) lo stream multimediale proviene da un
dispositivo che sta realizzando una ripresa o una registrazione live. Anche in questo
caso il contenuto multimediale viene distribuito fra i nodi componenti la rete ed
eventualmente processato.
Infine nel terzo evento (deve essere implementato il profilo dei dispositivi) viene
effettuata una richiesta al middleware tramite un normale player multimediale. Tale
richiesta viene processata, tenendo conto del profilo utente/dispositivo, attraverso un
modulo proxy che interfaccia il layer JXTA, e richiedendo un eventuale riadattamento
del contenuto.
2. Information Dissemination: CCID
Nell’ambito del contesto di analisi e sintesi delle problematiche inerenti la
disseminazione delle informazioni e’ stato realizzato un nuovo algoritmo per l’
Information Dissemination per una rete wireless ad hoc (MANET). La tecnica di
dissemination introdotta si basa sulla costruzione di una Core Network che permette lo
scambio di informazioni tra i nodi della rete tramite una dorsale. Le informazioni non
attraversano indiscriminatamente tutti i nodi della rete, ma passano attraverso
determinati nodi chiamati Core Nodes. Ogni Core Node fornisce servizi ai nodi vicini,
denominati Normal Node; in particolare garantisce la connettività con un qualsiasi altro
nodo della rete. Tale algoritmo denominato Core Construction algoritm for Information
Dissemination (CCID) è basato sul concetto di inductive connectivity
maintenance(ICM), node degree(DBC) e node coverage(CBC). Questi algoritmi
definiscono delle regole per eleggere ciascun nodo a Core Node, o a declassare i Core
Node a Normal Node. CCID lavora indipendentemente dai vari algoritmi di routing
anche se sfrutta in piggybacking i messaggi di broadcast utilizzati da questi ultimi.
CCID lavora basandosi sulla conoscenza dell’insieme dei vicini two-hop dal nodo in
considerazione. In uno scenario di Disaster Recovery e’ difficile ottenere informazioni
sulla posizione dei nodi a causa di diversi fattori come indoor operation e possibili
distorsioni dei segnali dovute ad ostacoli. Per questo motivo CCID non utilizza uno
schema che si appoggia sulla conoscenza della posizione dei nodi della rete, ma cerca di
costruire una Core Network robusta indipendentemente da questo. Ogni nodo agisce
34
autonomamente dentro il suo range di trasmissione ed ha una conoscenza parziale della
rete (vicini two-hop). Tutti i nodi scambiano informazioni con i nodi vicini (che cadono
nel range di trasmissione del nodo) in modo tale che ogni nodo possa costruire un grafo
contenente tutti i nodi distanti al massimo two-hop. Una volta che e’ stato costruito il
grafo vengono eliminati i nodi che non rispettano determinate regole. Così facendo ogni
nodo ottiene un NodeSub-Graph (NSG), l’unione dei NSG relativi ad ogni nodo
costituisce la Core Network.
Per la realizzazione della Core Network ogni nodo esegue due step:
1. Costruzione del Node Sub-Graph tramite i seguenti passi:
- Costruzione del grafo contenente i nodi vicini two-hops;
- Rimozione dei Link unidirezionali;
- Rimozione dei nodi terminali.
2. Eliminazione dei Core Node ridondanti tramite le tecniche:
- Inductive Connectivity Maintenance (ICM);
- Degree Based Core (DBC);
- Coverage Based Core (CBC).
Attualmente tutti gli algoritmi suddetti sono stati implementati in ambiente simulativo
NS2. Sono stati valutati la robustezza di costruzione del Core Network e l’overhead
degli algoritmi introdotti, e sono stati effettuati confronti tra le tecniche di de-selezione
dei Core Nodes: ICM, DBC e DBC.
35
Unità di Ricerca: Università di Modena
Collocazione del sistema TOTA
SERVIZI di BASE
In TOTA l’unica interazione consentita tra i nodi è il broadcast
all’interno del raggio di comunicazione wireless. Quindi il
problema di indirizzare a livello di rete i singoli nodi non si
pone in maniera stringente. L’unicast non è stato previsto nella
prospettiva di implementare il middleware in dispositivi (come
micro-sensori) che possono non essere dotati di capacità di
unicast. I nodi vengono identificati sulla base di parametri a
livello di applicazione e le interazioni possono essere ristrette
ai nodi che presentano determinati parametri.
In TOTA è importante identificare univocamente le tuple
propagate nella rete. L’implementazione attuale consiste
nell’identificare le tuple sulla base del nodo che le ha iniettate
e sulla base di un contatore crescente. Il nodo può essere
identificato sulla base del proprio indirizzo MAC o sulla base
di un numero elevato generato casualmente (univoco con alta
probabilità).
L’astrazione fondamentale proposta da TOTA è quella di tuple
ROUTING
distribuite che possono essere propagate nella rete ad hoc.
Queste tuple offrono un supporto efficace per lo sviluppo di
algoritmi di routing. In particolare è stato analizzato e
realizzato, sulla base di TOTA, sia un protocollo di routing
reattivo che un protocollo di routing geografico.
COMMUNICATION In TOTA la comunicazione avviene tramite la propagazione di
tuple distribuite. Un nodo può iniettare una “tupla distribuita”
nella rete. Questa si propaga e crea una struttura dati distribuita
che permane nella rete. Altri nodi possono leggere questa
struttura dati e reagire di conseguenza – eventualmente,
iniettando altre tuple.
In TOTA questo servizio è trattato in merito all’inserimento di
ALLOCATION/
nuovi nodi nella rete, alla dipartita di nodi dalla rete e, in
DEALLOCATION
generale, ai cambiamenti topologici della rete stessa. Le tuple
di TOTA sono in grado di mantenere in modo autonomo la
loro struttura. Se un nuovo nodo si connette alla rete, le tuple
si propagano in modo autonomo verso quel nodo. Se un nodo
si disconnette dalla rete o cambia posizione, le tuple contenute
nel nodo si cancellano o cambiano di valore automaticamente.
Questo servizio ha una grande rilevanza in TOTA. Le tuple di
LOCATION
NAMING
36
AWARENESS
MONITORING
TOTA, infatti, creano delle strutture dati distribuite che
possono identificare e contrassegnare determinate aree e zone
della rete. Le applicazioni possono agire in modo locationaware sulla base delle tuple percepite dinamicamente. Questo
meccanismo premette tre tipologie di location-awrness.
• Location-awareness basata sulla rete. In questa
categoria intendiamo quei servizi in cui la locazione è
espressa in termini di distanza – in temini di hop – da
un determinato nodo della rete.
• Location-awareness basata sullo spazio fisico. In
questa categoria intendiamo quei servizi in cui la
locazione è espressa in termini di un’area geografica.
Le tuple di TOTA permettono di sfruttare informazioni
geografiche tramite meccanismi di auto-localizzazione
od opportuni dispostivi (es. GPS).
• Location-awareness basata sullo spazio virtuale. Le
tuple di TOTA e i meccanismi di routing permettono di
costruire una struttura dati globale che può essere
percepita – a livello applicativo – come uno spazio
virtuale, in cui i nodi possono collocarsi e sulla base
del quale possono modificare le proprie attività. Questo
approccio trae ispirazione ed estende il concetto di
overlay network proposto nei moderni sistemi peer-topeer.
TOTA attualmente non si preoccupa del monitoraggio online
delle risorse. Tuttavia sono stati effettuati alcuni esperimenti
intesi a verificare quale sia il consumo di risorse da parte di
TOTA e come tale consumo si ripartisca tra i vari componenti
del sistema.
SERVIZI AVANZATI
GROUP
MANAGEMENT
COORDINAMENTO
QoS
MANAGEMENT
DATA STORAGE/
DISSEMINATION
TOTA non mira alla gestione di gruppi, coordinamento e QoS
management. Eventualmente, queste tematiche possono essere
trattate a livello applicativo sulla base delle astrazioni e dei
meccanismi offerti da TOTA.
In TOTA ogni nodo della rete dispone di uno spazio di tuple
in cui immagazzinare informazioni. I componenti applicativi
possono accedere, in modo diretto e reattivo, al proprio spazio
di tuple e – in lettura – agli spazi di tuple dei nodi vicini.
L’accesso alle tuple è consentito sia sulla base di un
meccanismo di pattern-matching, che tramite un accesso
diretto (hash) basato sull’ID delle tuple.
Un nodo può iniettare una tupla distribuita nella rete. Le tuple
37
di TOTA sono caratterizzare tramite un contenuto e una legge
di propagazione. Il contenuto rappresenta il payload della
tupla. La legge di propagazione stabilisce come la tupla deve
propagarsi nella rete e come il proprio contenuto cambi
durante tale propagazione. Le singole istanze di una tupla
distribuita vengono memorizzate all’interno degli spazi di
tuple dei vari nodi. Attraverso un meccanismo basato su eventi
le tuple archiviate nei nodi restano attive e in grado di
effettuare dinamicamente le azioni necessarie al mantenimento
della loro struttura.
38
Unità di Ricerca: Università di Pisa
Collocazione del sistema DS2
SERVIZI di BASE
Nodi Per quanto riguarda questo aspetto, DS2 presuppone che
ai nodi vengano assegnati indirizzi IP unici attraverso
protocolli di autoconfigurazione (PMWRS, MANETconf,
ecc.). Gli indirizzi IP vengono usati per distribuire i file e
mantenere le tabelle sull’associazione tra i files e i nodi che li
memorizzano.
Risorse In DS2 ogni nodo mantiene la corrispondenza tra i file
che utilizza e i nomi associati. Questa associazione è locale al
nodo e non necessita di un servizio di naming distribuito..
DS2 non è legato a nessun particolare algoritmo di
ROUTING
instradamento anche se presuppone l’esistenza di un algoritmo
di instradamento per il supporto della comunicazione
multihop.
COMMUNICATION I messaggi vengono scambiati tramite pacchetti UDP unicast.
DS2 gestisce in maniera autonoma l’allocazione/riallocazione
ALLOCATION/
delle risorse.
DEALLOCATION
Al momento DS2 non utilizza alcun servizio di location
LOCATION
awarness, anche se tali servizi potrebbero essere utilizzati per
AWARENESS
migliorarne l’efficienza. Questa possibilità non è comunque
stata ancora approfondita.
Al momento DS2 utilizza un sistema di monitoraggio dei nodi
MONITORING
presenti nella rete molto grossolano. Il monitoraggio è
necessario per avere informazioni sui nodi nella rete
raggiungibili al momento di distribuire i frammenti di un file
durante la sua creazione.
Oltre alla connettività altri servizi di monitoring utili
potrebbero essere relativi alla disponibilità di risorse sui nodi
(intesa come spazio per la memorizzazione)
NAMING
SERVIZI AVANZATI
DS2 non mira a gestione di gruppi, coordinamento e QoS
GROUP
management.
MANAGEMENT
COORDINAMENTO
QoS
MANAGEMENT
39
DATA STORAGE/
DISSEMINATION
DS2 fornisce il supporto alla memorizzazione distribuita di
files in una rete MANET gestendo un grado di ridondanza
specificato dall’utente in fase di creazione. Il descrittore del
file che mantiene le informazioni relative alla posizione del
file nella MANET e alla sua codifica (necessarie per le
operazioni di dissemination/retrieval) vengono conservate nel
nodo creatore ma possono essere distribuite ad altri nodi. Per
migliorare le strategie di memorizzazione del descrittore DS2
può essere combinato con strategie per replicare il descrittore.
Inoltre DS2 può essere integrato con strategie per determinare
il grado di ridondanza da utilizzare nella codifica del file e i
nodi più adatti a memorizzarne i frammenti. In questo senso si
possono studiare possibili convergenze con il sistema
REDMAN.
40

Middleware Design and Architecture

Transcript

Documenti analoghi

Edouard Manet

Un bar aux folies-Bergère

Le déjeuner sur l`herbe [ La colazione sull`erba]

La terza rivoluzione rid

AnnaSenzaNome

Centrostiledesign di Davide Cipriani

SCARICA L`ACTIVITY BOOK

lezione 2 - Istituto Santa Maria