Other System Components

0

0

0

Figure 12: Rendezvous of advertisements (starting at ‘P’) and queries (starting at ‘C’)

3.2.7 Other System Components

In Section 2.3, we introduced a coarse system architecture of our proposed peer-to-peer ser-vice overlay. We introduced several components providing different functionality of a serser-vice overlay. Furthermore, we highlighted the importance of service placement and service dis-covery in harsh environments. In the previous sections, we investigated related concepts to design service overlays for harsh environments and evaluated state of the art service placement and service discovery approaches. In the present section, we provide a brief overview on the remaining system components: service registry, matching, replication and failover, monitoring. We investigate existing solutions that could be used as these system components to provide the needed functionality.

Service Registry

The service registry provides functionality to add, search, and access services in the service overlay (cf., Section 2.3). In most systems, this functionality is covered by the service dis-covery as it already provides means to search and access services in the system [37, 76].

Depending on the type of service discovery, adding (i.e., registering) services is possible, too. But as we discussed in Chapter 2, the properties of harsh environments require further components of the service registry. These components are the service placement and the matching components. We investigated service placement and service discovery above and present existing solutions to the matching component in the next section.

3.2 Distributed Service Provision 51

Matching

In harsh environments, different types of devices must be handled. Devices vary in terms of their hardware specifications and available resources for service provision. At the same time, services have varying resource requirements for service execution. This leads to a problem: the heterogeneity of devices in terms of hardware and software resources does not allow the execution of any type of application. Especially, resources of peers do not automatically match the requirements of service objects for execution. Peers cannot execute and host service instances requiring other resources than are available. Hence, a mechanism is needed to match resource requirements of service objects and available resource capacities of potential service providers. Such a mechanism is called matching.

In most state of the art matching approaches, this problem is broken down to finding the maximum flow in a bipartite graph [106, 115, 195, 201]. Figure 13 shows a simplified example for a bipartite matching of services and peers. All service objects and all peers are mapped onto the bipartite graph and are represented by one group of nodes, respectively. A service node on the left is connected to every peer node on the right that is in principle ca-pable of providing the necessary resources for hosting the respective service instance. These connections are weighted edges, where weights correspond to the costs of all needed re-sources (i.e., CPU, memory, etc.). A source node and a sink node are inserted and connected to every service and every peer node, respectively. Finally, a maximum flow from source to sink has to be calculated such that every service instance is placed on one peer at most (splitting a service is not allowed).

Service 1

In harsh environments, it is most important that a matching algorithm is distributed and does not require a central instance coordinating the matching process. Wattenhofer pre-sented a fast and fully distributed algorithm for the matching problem [195]. This approach would be a good fit for our peer-to-peer service overlay in harsh environments.

Replication and Failover

Peer-to-peer systems are exposed to high churn rates (peers connecting to and disconnect-ing from the system). This compromises the availability of objects (e.g., service objects) distributed in the peer-to-peer system. Adding peer and service mobility in harsh environ-ments further increases this problem due to possible connection loss resulting from limited

range of wireless hardware. This high dynamic requires a replication mechanism to auto-matically replicate popular services, thus, increasing the availability of service objects and also the robustness of the entire system.

A comprehensive survey on different replication techniques is provided by Amjad et al. [12]. In peer-to-peer service overlays the replication of service instances also includes their execution states which have to be synchronized continuously. For example, with pas-sive replication a primary service replicates itself onto a second peer and transmits state updates to synchronize the execution states [200]. If the primary service provider fails, a replicated service instance must take over; this is called failover [23].

The approach by Snoeren et al. groups service providers into so-called support groups to quickly and efficiently take over, if group members fail [177]. Such an approach would be a good fit for peer-to-peer service overlays in harsh environments, provided the support groups are close by in the network topology. In particular, a combination of the placement and the replication component could enhance this approach further. Once a service instance is migrated to another peer nearby, the instance is not shut down on the old peer. If the new service provider fails, the old service provider is selected for the failover process.

Monitoring

In peer-to-peer service overlays, service instances can be subject to (severe) failures or even to misuses from internal or external sources (i.e., cyber-attacks). Thus, the current state of the network and the peers must be monitored. As discussed earlier, service placement also requires monitoring information about the current local network state and about the executed service instances to make decisions. Hence, the gathered data must also be avail-able to other system components, e.g., service placement, service discovery. This helps to analyze running service instances and to trigger possible countermeasures in critical situa-tions. Finally, the monitoring component must also oversee the functionality of the other components to ensure high system performance.

Monitoring schemes known from literature mainly differ in the overlay topology they cre-ate to exchange monitored information. Monitored information is also called attributes.

In literature, meshes [96, 104] and trees [119, 202] constitute the two prominent moni-toring topologies for a decentralized environment. In tree-based monimoni-toring schemes, the tree topology is built on top of a well-defined or stable structure of the communication net-work. The information is only exchanged between peers who are direct children and parents in the virtual tree topology. But, a well-defined or stable network structure cannot be as-sumed in harsh environments. Hence, tree-based monitoring schemes are not suitable for our peer-to-peer service overlay.

In mesh-based monitoring schemes, attributes are exchanged randomly among participat-ing peers usparticipat-ing a mesh topology [62]. One or several direct neighbors are randomly chosen to exchange monitored information. This information exchange within mesh-based mon-itoring mechanisms is also called gossip-based communication. The communication links are limited to the nearest neighborhood, i.e., physical or overlay neighborhood. Mesh- or gossip-based monitoring schemes are suitable in decentralized environments with no well-defined structure or with a dynamic structure. Hence, these monitoring schemes are the best fit for our peer-to-peer service overlay in harsh environments.

3.2 Distributed Service Provision 53