Sensor Infrared Sensor UserMood Sensor Wrapper Battery Location Wrapper UserMood Wrapper Event UserMood Location Event Battery Event ApplicationProfile <<document>> Context Controller Application Handler Executor ConferenceApplication <<application>> Shell Alice <<user>> Connector Publisher Register CARISMA Core Context Management Application Model CARISMA Core Services Meta−interface Reflective IWrapper IEvent
Figure 5.6: Middleware Architecture Example.
associated sensors (i.e., battery, location and user mood); this means that the application has encoded in its profile an interest in the status of these resources. The active wrappers and sensors vary dynamically, as a result of changes occurring in the profile, as well as activation and de-activation of applications.
5.2
Distributed Auction Protocol
In Chapter 4, we argued that the conflict resolution mechanism we have designed is ‘sim- ple’, in the sense that the computation and communication overhead it imposes on mobile devices is low. Providing a light-weight implementation of this mechanism on a single machine, to solve intra-profile conflicts, is rather straightforward, as no communication is required. However, designing a light-weight distributed algorithm to solve inter-profile conflicts is not trivial, as minimising communication costs and minimising computation costs turn out to be conflicting requirements. In the following sections, we first provide
Chapter 5 5.2 Distributed Auction Protocol
a brief presentation of two different algorithms, the first one that attempts to minimise communication costs, and the second one that aims to minimise computation costs, and then we discuss their similarities and, mainly, their differences. We use UML Sequence Diagrams [Rumbaugh et al., 1998] to illustrate these algorithms.
5.2.1 Minimisation of Communication Costs
Our first attempt to design a distributed algorithm that implements our conflict resolu- tion mechanism aims to minimise communication costs. This means both minimising the amount of data that is sent around, as well as reducing the number of messages exchanged among the involved hosts. Figure 5.7 illustrates the algorithm we designed. We assume here thatpeer1 requests a service that involves the cooperation ofnpeers.
2 2 2 2 4 4 4 4 5 3 3 3 3 1 6 6 6 6 peer3:Peer
peer n:Peer . . . peer2:Peer peer1:Peer . . . peer m:Peer
Figure 5.7: Algorithm for Minimisation of Communication Costs.
Step 1. Whenpeer1 requests a service from the underlying middleware, the first step is
to compute the set of policies that are currently enabled to deliver the service, that is, P1. Although no conflict has been detected yet, peer1 pre-computes a bid for
each of these policies, that is, it computes B1.
Step 2. A service request message is sent to then−1 participating peers, together with
P1 andB1.
Step 3. Each of then−1 peers involved in the service delivery computes the set of locally
enabled policies Pi; also, for each policy in Pi∩P1, that is, for every policy agreed
with the requesting peer, a bid is computed. We refer to the set of bids placed by
Chapter 5 5.2 Distributed Auction Protocol
Step 4. Each of then−1 peers communicatesPi∩P1 and Bi∩1 back topeer1.
Step 5. P eer1 determines P∗ and, in the case that a conflict is detected that can be
solved using our auctioning mechanism, it uses the pre-computed bids to determine the winning policy ˜p, as well as the sums fi, i∈[1, n] that each peer has to pay.
Step 6. Finally, peer1 sends back to each peer information about what policy has been
agreed to deliver the requested service, and how much money has to be paid.
We make the assumption that concurrent requests of the same service, originated by different peers, are identified and resolved prior to the execution of the protocol; in other words, leader election (i.e., peer1) is carried out before this protocol is started. Also,
we assume peer1 to be available throughout the protocol; if it fails, the entire service
request is aborted. We believe this assumption is reasonable, as peer1 is the only peer
to be in reach of all the others, and therefore in the position of being able to conduct the conflict resolution process; because in an ad-hoc network connection is not transitive, we cannot assume that the remaining n−1 peers are connected among themselves, and therefore able to carry out the process withoutpeer1. On the contrary, individual failures
of other participating peers taking place during the protocol execution do not compromise its success, as long as there are at least 0< m≤n peers connected until the end of the process (the minimum number of connected peersm is application dependent).
5.2.2 Minimisation of Computation Costs
The second algorithm that implements our conflict resolution scheme aims at minimising the overall computation costs, that is, minimising the total time that elapses between the service request and the final execution of the service itself. Figure 5.8 illustrates the algorithm; once again, we assume here that peer1 requests a service that involves the
cooperation ofn peers.
Step 1. First, a service request is sent bypeer1 to all the peers participating in the service
delivery.
Step 2. All n peers, including the one that started the service request, evaluate the set
of policies that are locally enabled, that is, Pi, i∈[1, n]. As before, for each policy
in Pi they pre-compute a bid, thus determiningBi.
Step 3. Each of the n−1 participating peers replies to peer1, communicating both Pi
and Bi.
Step 4. The requesting peer uses the information gathered to calculate the solution set
P∗, and, in case a conflict is detected, it uses the pre-computed bids to determine the winning policy ˜p, as well as the sums fi, i∈[1, n] that each peer has to pay.
Chapter 5 5.2 Distributed Auction Protocol peer1:Peer 1 1 1 1 5 5 5 5 3 3 3 3 peer2:Peer peer3:Peer
peer n:Peer peer m:Peer
4
2 2 2 2 2
. . . .
Figure 5.8: Algorithm for Minimisation of Computation Costs.
Step 5. Finally, peer1 sends back to each peer information about what policy has been
agreed to deliver the requested service, and how much money has to be paid.
As before, individual failures of participating peers taking place during the protocol ex- ecution do not compromise its success, as long as there are at least 0 < m ≤ n peers connected until the end of the process. Again,m is an application-dependent parameter. If the requesting peer fails, the entire service request needs to be aborted.
5.2.3 Comparison
As shown, both algorithms perform a pre-computation of bids (Step 1 and 3 for the first algorithm, Step 3 for the second one) in order to avoid an extra round of messages once the solution setP∗ has been computed (Step 5 in the first algorithm, Step 4 in the second), in case a conflict is detected. In this case, in fact, the requesting peer should communicate to the other participating peers the solution set P∗, and these should reply with their bids, thus requiring 2∗(n−1) more messages to be sent around. As a drawback, bids are computed even if they are not necessary (i.e., when no conflict is detected). However, we consider this overhead negligible compared to the time taken by two additional message rounds, so that, as the evaluation chapter will prove (Chapter 6), the pre-computation is actually worthwhile.
The main difference between the two algorithms can be noticed in the early steps: while the first algorithm computes the locally enabled policies on peer1 first, and then issues
Chapter 5 5.2 Distributed Auction Protocol
service request first, and then all the peers, including the requesting one, evaluate their locally enabled policies in parallel. By deferring the evaluation ofP1, the second algorithm
maximises the parallelisation of computation of the variousPi, which we assume to be the
heaviest task of the whole service request process. Computing Pi requires, in fact, the
comparison of the current context configuration against all the ones encoded in the profile and associated with the requested service. In the case of complex context configurations and very detailed profiles (i.e., many contexts associated with a policy, and many policies associated with a service), this task may become much more time-consuming (and resource demanding) than an additional exchange of messages.
As far as communication is concerned, in case of interactions between n >2 peers, both
peer1:Peer peer2:Peer peer1:Peer peer2:Peer Second Protocol First Protocol 6 1 2 3 5
(no step 4 required)
1
2 2
3 4
5