Middleware Design and Architecture
Transcript
Middleware Design and Architecture
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 all’interno dell’architettura di riferimento WP4 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 all’interno dell’architettura di riferimento WP4 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 all’interno dell’architettura di riferimento WP4 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 all’interno dell’architettura di riferimento WP4 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 all’interno dell’architettura di riferimento WP4 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