A Resilient P2PArchitecture for Mobile Resource Sharing · management [1], heterogeneous resource...

© The British Computer Society 2014. All rights reserved.For Permissions, please email: [email protected]

doi:10.1093/comjnl/bxu056

A Resilient P2P Architecture for MobileResource Sharing

Khalid Elgazzar∗, Sharief M. A. Oteafy, Walid M. Ibrahim and

Hossam S. Hassanein

School of Computing, Queen’s University, Kingston, Canada∗Corresponding author: [email protected]

Peer-to-peer (P2P) systems present a unique medium for resource sharing among cliques ofparticipants (peers) in a distributed and self-organized manner. With the advent of mobile users andthe increasing power of mobile devices, the spectrum of P2P capabilities should scale. Peers establishtransient or persistent relationships with other peers based on mutual interest. Communicatingpeers may use intermediary peers to forward communication messages, if a direct link is beyondtheir communication range. A critical design parameter is establishing a resilient communicationtopology, yet reduce the overhead of control messages required to instill and maintain it. This rises asa significant hindrance in mobile environments, which pose additional challenges on P2P networksdue to the heterogeneity of nodes, limited resources, dynamic contexts in addition to the inheritedwireless network stringencies. Thus far, efforts in establishing P2P networks via super peers (SPs)have been capped by considering a subset of peer properties to evaluate their candidacy. This paperpresents RobP2P, a robust architecture to construct mobile P2P networks and efficiently maintainnetwork state. RobP2P introduces a SP selection protocol based on a dynamic score function that takesinto account peers’ capabilities and context, such as location and quality of connectivity. The paperalso presents an agile utility function through which SPs can delegate monitoring responsibilitiesto comparably powerful and stable peers to ensure self-healing topology maintenance. We presentan elaborate performance evaluation of RobP2P implemented on Network Simulator NS-3. Ourresults illustrate the efficiency of RobP2P, its resilience to failures, and the improvements in lowering

overhead traffic while reliably maintaining the consistency of network state.

Keywords: resource sharing; Peer-to-peer; Super-peer selection; Super-peer; mobile computing

Received 9 November 2013; revised 30 May 2014Handling editor: Michael Sheng

1. INTRODUCTION

Peer-to-peer (P2P) systems have evolved from simplefile sharing to advanced distributed paradigms. In recentmanifestations, P2P spans social applications and collaborativeactivities. Nowadays, the P2P horizon extends to mobile datamanagement [1], heterogeneous resource sharing [2, 3] andmobile service provisioning [4]. P2P systems aim to utilize self-organizing protocols, capable of maintaining a consistent statedespite dynamic changes in network topology and number ofpeers. Generally, P2P systems share common characteristicssuch as distributed architecture, collaborative communication,aggregate shared pool of resources/services and decentralizedcontrol over shared resources [5].

The choice of the underlying network architecture hasa great impact on overall system performance. Super-peer

(SP) networks take advantage of centralized schemes, whilebenefiting from the robustness of distributed architectures [6]. InSP overlay infrastructures, the network topology is constructedin two layers. One layer contains SPs (or super nodes) that haverelatively higher capability and assume special responsibilities.The second layer contains all other peers (called ordinarypeers). SPs handle the communications inside their respectivegroups as well as exchange information with other SPs.Query resolving (resource discovery) in a SP architectureis much faster than any other P2P topology. However, SPselection is challenging due to the many factors that governthe selection decision which have direct impact on the SPperformance. Mobile environments pose additional challengesto SP selection due to the constantly changing topology and thevarious constraints stemming from either the limited capability

Section B: Computer and Communications Networks and Systems

The Computer Journal, 2014

The Computer Journal Advance Access published July 4, 2014 at Q

ueen's University on June 2, 2015

http://comjnl.oxfordjournals.org/

Dow

nloaded from


2 K. Elgazzar et al.

of mobile nodes or the intrinsic characteristics of wirelessnetworks.

Much of the research which has investigated the challengeof SP selection and contributed with many algorithms andtechniques were designed either for static networks [7–10] or to address a specific constraint of dynamic mobileenvironments [11–13]. Most of these approaches either sufferfrom high failure rates due to sparse considerations of thedynamic mobile environment constrains, or trade-off reliabilityfor cost of maintaining the overlay topology and incur longerquery latency. The core goal of this work is investigating andquantifying the impact of inclusive profiling for SP selection.That is, adopting techniques for profile fusion that incorporatea multitude of measures representing the fitness of any givenpeer in assuming the role of a SP.

The fundamental problem of constructing a resilient topologyin P2P architectures extends to other domains that feature self-organizing and self-healing properties. For example, sensornetworks utilize the concept of rendezvous points (cluster-heads) to collect aggregate data from less powerful sensors,whether these rendezvous points are static [14] or mobile [15].In ad hoc wireless networks, some powerful intermediarynodes are selected, using connected dominating sets, to serveas a virtual backbone that can form communication bridgesbetween nodes that are out of communication range fromeach other [16, 17]. Therefore, the need for an efficient P2Parchitecture extends to several other domains beyond P2Psystems.

This paper proposes RobP2P, a robust mobile P2P SParchitecture with a 3-fold vision: (1) Adopting a granularmechanism for profile fusion that implicitly ranks peers infitness to assume SP roles; (2) laying the foundation forefficient and scalable P2P overlay networks; (3) developinga reliable P2P infrastructure that enables efficient resourcesharing and service provisioning in mobile environments withno infrastructure support. RobP2P presents a novel SP selectionmechanism that improves the stability of SP P2P architectures.It also introduces a reliability improvement scheme that reducesthe network maintenance overhead, while improving the overallnetwork reliability and stability. In addition, it reduces theoverdue burden on resource-constrained nodes by distributingloads evenly across the network.

This paper extends our previous work [18]. In this paper,we provide in-depth development of our SP selection protocol,enhanced role changing scheme and detailed algorithms for fail-safe SP election. We present a fail-safe join scheme that enablesthe SP to carry out its tasks, and delegate a designated set ofnodes to check on its survivability in case of an unexpectedfailure. The remainder of this paper is organized as follows.Section 2 gives a brief background and outlines related work.Section 3 provides an abstract description of RobP2P. TheRobP2P architecture, SP selection criteria, selection algorithmand role changing scheme are presented in Section 4. Section 5presents and discusses the findings and simulation results

carried over NS-3. Section 6 concludes the paper and drawsfuture directions.

2. BACKGROUND AND RELATED WORK

Recent P2P architectures adopt models where resources areshared in a collaborative manner. Peers that request or offeraccess to resources may join, leave and participate in anad hoc fashion. Peers discover each other based on mutualinterests, such as shared location or contents. A P2P overlaynetwork is constructed between interested peers with orwithout an underlaying communication infrastructure. Thevast majority of P2P systems/applications are built on topof existing communication infrastructures [7–9, 19]. In suchcases, P2P topology construction algorithms connect peerswith each other through the underlying network infrastructure,which allows peers to utilize the existing communicationchannels to exchange messages with one another. In mobileenvironments, P2P systems can function with no infrastructuresupport. TerraNet [20] is currently testing a new P2P-basedtechnology that will allow mobile phones to connect with oneanother without the need of cell towers and base stations.This feature makes P2P technology a suitable candidatein disaster recovery scenarios and emergency managementprocedures.

P2P system architectures are classified, based on the wayP2P systems locate resources in the network, into twocategories [21]: structured and unstructured. The topologyof structured P2P systems is tightly coupled to the locationof the shared resources (including peers themselves) in thenetwork. In such architectures, the mapping between resourcesand their respective locations is carried out using distributedhash tables techniques. Unstructured P2P architectures [7, 8]assumes no relation between overlay network and sharedresources. In addition, all nodes have equal responsibilitiesregardless of their location or context. The unstructured schemetypically generates high traffic due to broadcasting resourceadvertisements and requests. Nodes may be required to maintaina copy or a reference to all advertised resources in the networksand run a local query processing engine to determine whether toanswer a request or forward it to all immediate neighbors [22].These requirements render unstructured architectures inefficientin resource-constrained environments, despite their flexibility,fault-tolerance and easy-to-maintain features. Therefore, theSP architecture were introduced to overcome the shortcomingsof unstructured networks. SP architectures dominate theinfrastructure of P2P systems [21].

Since the introduction of the SP P2P network architecture,many research efforts contributed different variations ofSP selection algorithms and overlay topology maintenanceschemes. Chawathe et al. [23] introduce several modificationsto the original design of Gnutella [7] in order to accommodatefor node heterogeneity and efficiently handle the load when



at Queen's U

niversity on June 2, 2015http://com

jnl.oxfordjournals.org/D

ownloaded from


A P2P Architecture for Mobile Environments 3

high aggregate-query rates occur. Mahdy et al. [12] studied theperformance of two SP selection approaches: Control Loop andEvent Triggered. The authors claim that a hybrid SP selectionapproach that switches back and forth between control loopand event triggered based on predetermined threshold valuesoutperforms both individual approaches. Min et al. [24] addressthe problem of selecting a SP to join from multiple that are inthe range of new joining peer. Their strategy selects the SP thatwould offer a lower query latency rather than network distanceproximity. The SP capacity is measured based on average CPUutilization and accessibility to contents that the joining peer isinterest in.

Other studies address the inherent constraints of mobileenvironments, such as limited resources and mobility, inselecting SPs. For example, Kim et al. [13] propose a double-layered P2P system, in which SPs are selected based ontheir mobility pattern in order to enhance the system stabilityand reliability. Kim et al. [11] qualify SPs based on theintegration of mobility and available energy. Merz et al. [25]propose a SP topology construction and maintenance schemebased on network coordinates. These approaches considerpartial factors and leave out parameters that might havesignificant impact on the performance of SPs, such as availablecomputational resources. Liu et al. [26] present a SP selectionalgorithm (SPS), in which peers periodically build their setof SP candidates through gossip communications [27] withneighbors. SP candidacy is determined based on an aggregate

capacity indicator that includes computational resources,network bandwidth and lifespan. However, they overlookimportant constraints such as energy level and networkconnectivity.

Ultimately, overlooking the impact of these factors on SPselection and performance are often to the detriment of thenetwork. Not only does it limit the performance of the SPand the network in general, but also results in significantinstability in the topology. In this work, we emphasize thefusion of profile information for nodes contenting to becomeSPs, aggregating their resourcefulness measures in light of theircontext. In RobP2P, we emphasize the inevitable trade-offsbetween aggregating more parameters in the efficient selectionof SPs, and the resulting overhead in control message exchange.In Section 4, we highlight the trade-offs and importance ofincorporating these factors, and the design parameters adoptedto overcome the control overhead.

At its core, RobP2P offers a dynamic SP selection protocolthat determines the rank of competing candidates based on anaggregate profile score utility. This profile score integrates manyfactors, including the node’s current mobility, immediate energylevel, network capability, mean uptime and connectivity degree.Network capability aims to assign a higher priority to nodes withhigher bandwidth availability and multiple network interfaces.Whereas the connectivity degree aims to balance the node load(number of served peers) with its computational capacity anduniformly distribute the peer load across the network topology.

FIGURE 1. An abstract overview of RobP2P.



at Queen's U



ownloaded from



3. ROBP2P SYSTEM-LEVEL OVERVIEW�

�

�

�

RobP2P at A Glance:

• Efficient SP selection protocol.• Profile fusion for resilient selection (leader

fitness).• Robust join/leave procedure.• Novel Role Changing Scheme.

Building a robust P2P overlay network enables efficientresource sharing in pervasive environments. The design goalsof RobP2P are 3-fold: (1) developing a robust and efficient SPselection protocol that aggregates fitness measures; (2) reduc-ing the overhead traffic of network topology maintenance; (3)increasing the reliability and stability of the network infras-tructure through enabling peers to flexibly change their role.

Figure 1 shows an abstract overview of RobP2P. We assumethat peers span a wide range of mobile device form factorsand (potentially) wireless sensors with different features and avariety of hardware and software stacks. Some of these peers arehigh-end mobile devices such as laptops, tablets, smart-phones,and vehicles equipped with processing power and networkconnectivity. Other peers have limited processing power, batterylife, storage and network capabilities, such as featured phones,low-end wireless sensors, cameras, etc. We assume that peersform P2P groups based on location proximity, within a few hopsfrom one another, regardless of their interests and resources theymay share. Peers are on the move and their context changesdynamically.

The P2P overlay network is capable of maintaining adynamic and consistent state of established topology. RobP2Pis structured in two virtual layers, one layer contains SPsand the other layer contains ordinary peers. SPs are relativelymore resourceful and highly connected to other peers. Theselection of SPs is based on their current profile, as detailedin Section 4.2. Ordinary peers communicate with the rest ofthe network through their designated SP. Peers cooperate torelay messages between communication peers regardless oftheir group affiliation. Peers also may frequently join andleave the network. Both SPs and ordinary peers assume thatcommunication routes are unidirectional and may not performequally in bidirectional mode.

4. ROBP2P ARCHITECTURE

The P2P network is divided into multiple regions. Each regionrepresents a location-based group that contains peers that arephysically located with the region boundaries. Algorithm 1shows the group initialization procedure. Each group selectsa SP that represents the group head, while the rest of the

peers become ordinary peers. All peers calculate their profilescore using the score function in Equation (1) and participateto the SP selection following Algorithm 2. Once SPs areselected, all advertisements and queries within groups are sentto respective SPs. SPs collect and index the group information,including active peers, advertised resources and offered servicesin order to manage the group communications and resolvequeries addressed to the group. The SP is also responsibleof maintaining the group state, including selecting new SPs,in case its context changes or moves away of the group’scentroid (i.e. where the majority of the group peers can bereached). Ordinary peers generate three type of messages:hello, advertise and query. Each of these messages containsthe peer ID (source), SP ID (destination), message type anda payload. The hello message maintains the peer existence inthe network and is sent at specific time intervals (TTLs). Thehello message has an empty payload. Peers send the advertiseand query messages whenever they announce or request accessto a resource, respectively. Their payload contains informationabout the offered or requested resource. They also reset the TTLcounter of the sender peer. Each advertisement is renewed everyTTL in order to keep the associated resource valid. Otherwise,the advertisement is removed from the SP index. Each groupmaintains its state individually and independently of othergroups. SPs coordinate between each other to communicatetheir indexed information.

4.1. Join/leave

To join a P2P network in RobP2P, new coming peers broadcasta join request. This request serves several objectives: (1) buildsthe peer’s neighboring table, (2) discovers super nodes, if anyexists, (3) initiates a group if no response is received. Theresponse message contains the group ID, peer ID and peer role(i.e. SP or ordinary peer). Figure 2 illustrates the join processand Algorithm 3 shows the join procedure.

The newly joining peer calculates its profile score based onthe network score function and compares it with the profile of thecurrent SP. If the profile of the new peer outperforms the profileof the SP, the new peer takes over the SP responsibility. Then,the current SP downgrades itself and sends an update messageto the group declaring the new SP. This message updates therole of the current SP and provides the ID of the new SP.Figure 2 illustrates the join process and Algorithm 3 shows thejoin procedure.

Owing to the dynamicity of mobile P2P networks and the everchanging context of mobile nodes, SPs may leave gracefully orfail arbitrarily. SP re-selection starts when the network detectsSP failure or the SP itself expects a service disruption or asignificant reduction of its connectivity degree (the numberconnected ordinary peers) due to mobility. In addition, dynamiccontext changes may result in changing the peers capability,and hence their profile score. Ordinary peers may become morecapable to assume SP responsibilities, or SPs might encounter



at Queen's U



ownloaded from



FIGURE 2. Join process.

Algorithm 1 Initialize group (Gi).Input: Ni : Set of nodes in Gi

Output: nullfor j ← 1 to |Ni | do

Broadcast(nj .ID)nj .NC ← 0

endwhile setup_duration&&msg_rcvd(nj .ID) do

Add_neighbor(nj .ID)nj .NC ← nj .NC + 1

endchoose_leader(Gi)

Algorithm 2 choose_leader (Gi).Input: Ni : Set of nodes in Gi ,MAX_BW // maximal BW in Gi over all heterogeneousdevicesOutput: Li : Supper − peer of Gi

nj .prof ile ← compute_prof ile // profile score (1)Li ← nj

best_prof ile ← 0while selection_duration&&msg_rcvd(nj .prof ile) do

if nj .prof ile > best_prof ile thenLi ← nj

best_prof ile ← nj .prof ile

endend

performance depredation. Therefore, in addition to recoveringthe mobile P2P network state from SP failure/disruption, weintroduce the Role Changing Scheme, aiming at enhancing theoverall system reliability.

Algorithm 3 Join(Gi).Input: nnew : new node joining Gi ,MAX_BWOutput: nullnnew.prof ile ← compute_prof ile

Broadcast(nnew.ID, “join”, nnew.prof ile)while wait_duration do

if msg_rcvd(nj .prof ile) > nnew.prof ile thenLi ← nnew

break //i.e. end search

endendbest_prof ile ← nnew.prof ile

Broadcast(Li, best_prof ile)

Algorithm 4 Rcv_join_REQ(nnew).Input: nnew : new node joining Gi

Output: msg_responseif msg_rcvd(“join” then

Unicast(nnew, “leader”, Li)

end

Algorithm 5 Leave(Gi).Input: Li : current SP of Gi

Output: Li : new SP of Gi

Broadcast(“choose_leader”)Li ← Choose_Leader(Gi)

4.2. SP selection

The efficiency of a P2P network is highly dependent on theperformance of its SPs and their communication. Selecting SPsin P2P systems is always challenging. A SP must be capable



at Queen's U



ownloaded from



to improve the overall performance of P2P networks, otherwiseit might become a bottleneck. The goal of our SP selectionprotocol is to satisfy the following criteria:

(i) Accessibility—SPs must be accessible with minimalcost(delay) by all ordinary peers. Peers with multi-homing capability (i.e. run multiple network interfaces)must have preferences in SP selection, as they canemploy their different interfaces to communicate witha wide range of other devices [28].

(ii) Resourcefulness—SPs must possess sufficientresources to handle the group communications andresolve queries with reasonable delay.

(iii) Distribution—SPs must be selected so that every nodein the P2P network has at least one reachable SP andeach SP must serve a reasonable number of ordinarynodes according its current capacity.

(iv) Mobility—peers with low mobility profiles mustbe given higher preferences to avoid frequent SPselections.

(v) Context-awareness—SPs should be capable of detect-ing their status and re-select new SPs or delegate theirresponsibilities to the next best candidate node if theyexpect service disruption or experience degradation intheir performance.

4.3. SP profile score

To measure whether a peer nj is a candidate to assume SPresponsibilities in a group Gi , we define the peer profile usingthe score function in Equation (1). In this equation, b is thecurrent battery power level on nj , Emax denotes the maximumenergy level that any peer belongs to Gi might have, m is thecurrent mobility pattern of nj , Mmax is the maximum mobilitynj can reach, BW is the current available bandwidth of nj ,BWmax represents the maximum bandwidth across Gi , ut is thenormalized mean uptime of nj , which denotes how stable thepeer is, NC represents the network connectivity, i.e. how manypeers in Gi can reach nj , w1 −w5 are weights that represent thefactor importance, where

∑5k=1 wk = 1. In this score function,

we reverse the peer mobility, since peers with low mobilitypattern are of higher preferences. The peer profile ranges from0 to 1. The higher the profile value, the higher the possibility apeer could be selected as a SP. Each peer in Gi calculates andshares its profile with other peers. The peer with the highestprofile declares itself the SP serving Gi . RobP2P assumes thatall peers are trustworthy when declaring profile values.

nj · profile = 1

5

(w1

nj · b

Emax(Gi)+ w2

Mmax − nj · m

Mmax

+ w3nj · BW

BWmax(Gi)+ w4nj · ut + w5

nj · NC

|Ni |)

(1)

The SP selection procedure is shown in Algorithm 2. Whenestablishing connectivity in a group, we assume symmetriccommunication between all nodes (however, no mandate fordirect 1-1 messaging to hold the diversity constraint). Weassume that BW is aggregated bandwidth over all interfaces ofa node. This gives preferences to nodes with multiple interfacesin SP selection.

4.4. Role changing scheme

The role changing scheme aims to accommodate the dynamiccontext change of mobile P2P networks, while maintainingthe system reliability. A peer initiates the procedure tocall for changing its current role, either promoting ordemoting itself according to its current situation. SPs invokethe procedure shown in Algorithm 5 when they detectdegradation in their performance with more than 10% oftheir original calculated profile. This enables peers with morecapability to assume SP responsibilities. An ordinary peermay also initiate the procedure if it experiences a significantimprovement in its capability (such as battery life, bandwidthor connectivity degree). This improvement in capability mustexceed the last reported profile value by the current SP. Thesethreshold values are chosen to maintain the network stabilityand avoid undue overhead that might occur due to falsecalls.

4.5. Fail-safe SP election

In a typical scenario, a SP would trigger the Leave procedure tosignal that it could no longer serve as leader of the group. Thiswould trigger a sequence of events, as previously highlighted,to elect a new SP. It is unavoidable to consider the case wherea SP would fail to serve as a leader, and not get the chanceto trigger the Leave procedure. This is typical in cases ofintermittent/permanent failures. To be clear, this case doesnot include degradation in profile score; that is handled inSection 4.3.

Capturing a scenario where a SP had abruptly failed is non-trivial. Since we have emphasized the design of a decentralizedapproach to SP selection, there is little information for ordinarypeers to decide if the SP had failed, or lags in response. Wealso note that adopting fail-safe schemes almost always incursadditional control overhead. Thus, we present a fail-safe SPelection algorithm to augment the operation of RobP2P, to beimplemented in applications that require a fine-tuned resiliencemeasure. The procedures are detailed in Algorithm 6. The ideais enlisting an ordered list of ordinary peers β that are closecontenders to the profile score of the SP, to keep an eye on it.If they detect the SP is no longer responsive, and have not beentriggered through a graceful degradation (Sleep) procedure.These nodes will take over in initiating a fail-safe choose leaderprocess again.



at Queen's U



ownloaded from



Algorithm 6 Fail-safe choose_leader (Gi).Input: τi : Countdown window for Gi ,�: % of the score to make cutoff as delegate ∈ [10, 50]Output: Li : SP of Gi

βi ← φ

nj .prof ile ← compute_prof ile//profile score (1)Li ← nj //i.e. the IDLi.prof ile ← nj .prof ile

Broadcast (nj , nj .prof ile)t imer ← τi

while !t imer&&msg_rcvd(nj .prof ile) doif self.prof ile > Li.prof ile then

βi ← βi ∪ Li

Li ← self

Li.prof ile ← self.prof ile

endelse if self.prof ile × �+100

100 > Li.prof ile thenβi ← βi ∪ self

end// I am the SPif Li == nj then

Broadcast(Li, “leader”)Wait(τ × 0.01)if msg_rcvd(“leader”) then

α ← random(0, 1)

Broadcast(nj , “contending”)while msg_rcvd(“contending”) do

if self.α > Li.α then// i.e. the other node wonLi ← self

endend

endendif Li == nj then

foreach nj ∈ βi doUnicast(self.order, |βi |)

endend

end

Initially, all nodes will compute their profile scores, assignthemselves as temporary SPs and broadcast their computedutility scores.A timer will be triggered, during which each nodewould wait to hear back from all other nodes in Gi . The durationof this timer is application/scenario sensitive, and is a tunableparameter that is an input to the leader election Algorithm 7.For every message received during the wait period, each nodewill decide if the received utility score is higher than the currentbest (initially its own) score, and accordingly update the currentleader. If not, it will check if the received score is within % of thetop utility score seen so far, and insert that node in order inβ.Theset of supporting ordinary peers β will be populated as nodes

communicate. As the algorithm terminates (due to timeout), itwould have populated β and elected the best SP.

The elected SP would broadcast its selection at the end ofthis period. To ensure that multiple SPs are not chosen, incase for example there was a tie in utility scores, a wait period(0.10 * initial countdown timer duration) would be granted forcontention requests. That is, if a node believes it was elected asSP, yet received that announcement from another node, it wouldbroadcast a contention message with a random value in [0, 1]to break this tie. The node with the highest random value wouldbe recorded as the SP between all nodes in Gi . Then, the SPwould unicast to each of its delegates in β a number, indicatingits order in the list.

Algorithm 7 Check-leader(Li).Input: oi : Order in list of delegates in Gi ,Oi : Size of list of delegates,CF: Check_f requency

Output: null

k ← 0wait_increment = check_f requency × oi

while current_leader = Li doWait(wait_increment + Oi × k)

Unicast(Li, “checking_on_U”)Wait(t imeout)

if !msg_rcvd(“alive”) thenBroadcast(“choose_leader”)

endk ← k + 1

end

It is important for the delegates assigned by the SP to checkits survival in a consistent and predictable fashion. Each nodein βi will be assigned an interval to check the survival of the SP.Algorithm 7 details the procedure followed by each node in βi .The idea is instilling a schedule of survival checks that alternatesbetween the delegates. Each delegate will wait for its turn(incremental over all nodes in βi) and unicast a checking-on-Umessage to the SP. This message has an empty payload, with astatic type. If the SP responds with the m-alive acknowledgment,again an empty payload message, then all goes well (as far asthis delegate is concerned at this round). Otherwise, a failure isdetected and all nodes in Gi would receive a request to initiatethe Join process highlighted in Algorithm 6.

Although a lack of response might be attributed to a lagin response (i.e. the SP did not fail, but slowed down), westill classify this as failure. That is, the SP initially broadcaststhe Check frequency which is correlated with its Accessibilitymetric. That is, if it claims it is highly accessible (hence won theelection) then this should be manifested in the check frequencytolerated. If it then fails to respond (acknowledge survival)within the time-window dedicated for checking, then it hasfailed in its SP duties.



at Queen's U



ownloaded from



FIGURE 3. A deterministic FSM of the operational states and transitions of nodes in RobP2P.

Lastly, it is important to note that different nodes will manifestdifferent roles in the operation of RobP2P. An overview ofthese states is presented in a deterministic finite state machine(FSM) in Fig. 3. In general, a node will typically transition overdifferent roles at different phases in the operation of RobP2P.Initially, all nodes in a given region will start the Join process,after computing their profile score, and initiating a contentionfor the designated SP role. After each nodes settles in a givenstate depending on its profile score, regular operation mandatesthat delegates constantly monitor the survivability of the SP, andtrigger maintenance schemes (re-initiating the Join phase) whenit abruptly fails. Nodes joining the network post the initial Joinprocess will contend to take on a SP role, or join as an ordinarypeer as depicted in Fig. 3. The saturating/final state for any nodewould be its failure, should it not be able to gracefully degradein operation.

5. EXPERIMENTAL RESULTS AND DISCUSSIONS

We conducted several experiments to evaluate the performanceof RobP2P, focusing on its distinguishing features. We limitthe scope of our evaluation setup to investigate the followingaspects: (1) the overhead of SP selection, (2) how RobP2Pmaintains a stable state while reducing the number ofunnecessary SP selection, which will test the quality of our scorefunction, (3) how RobP2P handles the churn of mobile networks(i.e. frequent join and leave of nodes), while maintaining thesystem reliability. Toward these objectives, we measure theoverall network traffic versus the mobility of nodes and churnrate.

We also conducted specific experiments to investigate thequery failure rate and the associated overall generated networktraffic. The failure rate is defined as the number of unsuccessful

TABLE 1. Summary of the experimental parameters.

Parameter Value

Number of peers 200Communication range 100 mTopology area 1 km × 1 kmTime to live (TTL) 10(sec)Experiment time 100 TTLNode energy Random 100–2500 JMobility (m/s) Random 0–2.5

queries to the total number of submitted queries.We compare theperformance of RobP2P with the milestone results presented byKim et al. [11], since their approach is superior to the establishedMOB scheme [13], which in turn outperforms Greedy and MISapproaches [29].

The performance evaluation is performed using the networksimulator NS3 [30]. The topology area is set to 1 km × 1 km,while the communication range of each peer is set to 100 m.The total number of the peers is 200, in our setup we assumesymmetric communication between all nodes. Each node sendsa hello message every 50 s. The mobility pattern of nodes isset to the random way point mobility model. Peers move witha speed between 1 and 2.5 m/s with a pause duration between0 and 20 s. We have defined five categories of energy levelsfrom 100 to 2500 J, where each peer starts the simulation with arandom remaining battery life and changes over time. Each peerhas random periods where it is disconnected from the network.While disconnected, the peer does not receive or transmit anypackets. A random failure pattern is set for each individualpeer. All parameters in the utility function that calculate thepeer profile are assigned equal importance (i.e. w = 0.2).



at Queen's U



ownloaded from



FIGURE 4. Query failure versus join/leave rate.

FIGURE 5. Total network traffic versus join/leave rate.

Table 1 summaries the experimental parameters we used in oursimulation.

Figure 4 reveals that the query failure rate is much lower inour system, which reflects the system reliability and stability.This improvement is attributed to our SP utility function andthe role changing scheme, both of which contribute the most toour system stability through efficient selection of SPs. However,this stability comes at the expense of generating limited extratraffic, as Fig. 5 shows; where newly joining peers exchangemessages to check whether they are more capable to assumeSP functionalities or not. Although this little extra traffic isnegligible compared with other approaches, the performancebenefits to the system reliability are remarkable. We also notethat RobP2P outperforms [11] due to the survivability of peer-exchanged data. Evidently, its effect is manifested when thesystem experiences low join/leave rates. However, as this rateincreases the overhead imposed by RobP2P outweighs theadvantage of survivability in exchanged data.

Figure 6 shows that RobP2P is less-prone to query failure inmobile environments, where most of the nodes are always on themove. The result proves that our SP selection is efficient, givingpreference to peers with lower a mobility profile and higherconnectivity factor. Taking into account the ability of SPs to

FIGURE 6. Query failure versus node mobility.

FIGURE 7. Total network traffic versus node mobility.

communicate over multiple interfaces significantly reduces thequery failure rate, since SPs and ordinary peers are reachedthrough different wireless technologies. Figure 7 shows thatRobP2P accommodates peer mobility while maintaining thenetwork state, with lower cost than other architectures.

Figure 8 illustrates the impact of changing the TTL on thequery failure rate. The longer the TTL is the more query failuresoccur. However, RobP2P outperforms Kim’s approach [11].There are two reasons that explain this observation. First, ourSP selection function takes into account the various factors thataccommodate the inherent dynamics of P2P mobile networks,which by itself makes the SP selection efficient. Secondly,the role changing scheme, that we introduced to handle thenetwork churn and the dynamic change in the node context,enables peers to request changing their role regardless of theTTL. This reduces the number of unnecessary invocations tothe SP selection algorithm, while maintaining an overall highreliability. On the other hand, Fig. 9 shows that a significantreduction of the network maintenance traffic occurs as a naturalresult of extending theTTL period. However, RobP2P is capableof maintaining a stable network state, while others fail whenthe TTL period becomes longer. The results depicted in Fig. 9



at Queen's U



ownloaded from



FIGURE 8. Query failure versus varying TTL periods.

FIGURE 9. Total network traffic versus TTL periods.

demonstrate the edge of RobP2P in reducing the frequency ofupdates, since it depends on an aggregation of profiling factorsthat result in a more stable topology. However, at short TTLrates the overhead of accounting for granular profiling rendersthe solution by [11] more efficient under this case.

We carried out several experiments to quantify the impact ofthe fail-safe leader election mechanism, detailed inAlgorithms 6and 7, on the resilience of RobP2P when handling highfailure rates. Our primary concern is the impact of failures ofcurrent leaders in carrying their task, under different failuredomains. For this purpose, we run simulations to evaluatethe performance of the fail-safe mechanism under varyingjoin/leave rates. Figure 10 demonstrates the resilience of thefail-safe mechanism in handling frequent changes in leaderselection, due to intermittent or permanent failures of peers.Evidently, increasing join/leave rates impact the time taken tochoose a new leader, however, the robustness of the fail-safescheme is demonstrated in its ability to elect a leader quicker,especially due to the frequent timer operation and the interplayof leader selection and checking carried out when new peersjoin a neighborhood.

FIGURE 10. Contrasting the impact of peers joining/leavingnetwork, on the time spent without a leader.

FIGURE 11. Impact of leader mobility on maintaining a leader.

FIGURE 12. Varying theTTL index for peers and its impact on leader-void under both leader election schemes.

An important factor to consider, especially as we advocatefor mobility in peers, is the resilience of RobP2P with the fail-safe scheme in handling peer mobility, and maintaining leader



at Queen's U



ownloaded from



selection under varying mobility rates. Figure 11 depicts theevaluation of varying mobility rates (in meters per second) ofleader nodes in light of original position when they were electedas leaders. While there is an increasing rate of leader ‘void’ timecreated when leaders move (and hence loose connectivity withstationary peers or others moving in a different direction), thefail-safe mechanism shows better mobility handling. In fact,this improvement increases in multiple folds as the mobility ofleaders increases, and hence offers a more resilient solution tohigh-mobility scenarios.

Figure 12 shows the enhancements that the fail-safemechanism brings with varying TTL. While evidently the trendof improvement is seemingly insignificant, we attribute thesimilarity in performance to the beaconing and overhead incommunication that results from extending the TTL. In general,we note that there is significant hindrance in handling mobilityand failures while attempting to maintain a connected clique forlonger times.

6. CONCLUSION

This paper presents RobP2P, a robust mobile P2P architecturethat enables efficient resource sharing. In a domain wherefrequent topology changes and high-sensitivity to mobilitydictate resilient schemes, we present RobP2P as a dynamicarchitecture that caters for the heterogeneity and volatility ofmobile resources. At its core, it introduces an aggregate scorefunction that determines whether a peer is a candidate to assumeSP responsibility. This score function takes into account boththe mobile node constraints and mobile network dynamicity.RobP2P also introduces a scheme that enables peers to call forchanging their role based on a significant change in their currentprofile. This scheme renders the mobile P2P network topology,constructed with RobP2P, more stable. It also significantlyreduces the network maintenance overhead while maintaininga high level of reliability. Simulation results show that RobP2Poutperforms other P2P architectures. In addition, we introducedthe fail-safe scheme that improves the resilience of RobP2P andmakes it more capable of handling intermittent and permanentfailures, leaves and joins in the network. While it introducesmore overhead in checking for existence of leader and stringenttimers schemes, it compensates with improved resilience.

In future, we plan to utilize Principal Component Analysistechniques to estimate the parameters with significant impacton the score function to reduce the transmission overheadof less significant parameters. More importantly, models thatincorporate a dynamic and resilient score function would beinvestigated; shifting from an aggregation scheme to a non-linear assignment of scores to different preferential variablesthat each heterogeneous node would possess. Lastly, a coreprincipal in RobP2P is the exchange of profile information,such that nodes can assign themselves higher profile scorespotentiating their election as leaders. The intrinsic assumption

has been the honest and collusion free calibration andexchange of this information. However, a future directionwould encompass security measures that ensure such scores aregoverned and checked for consistency, fairness and resilience tomalignant efforts in tampering with system stability and load-balancing.

REFERENCES

[1] Ylianttila, M., Harjula, E., Koskela, T. and Sauvola, J. (2008)Analytical Model for Mobile P2P Data Management Systems.Proc. 5th IEEE Consumer Communications and NetworkingConf., Las Vegas, NV, USA, January, pp. 1186–1190.

[2] Barolli, L. and Xhafa, F. (2011) JXTA-overlay: A P2P platformfor distributed, collaborative, and ubiquitous computing. IEEETrans. Ind. Electron., 58, 2163–2172.

[3] Yu, C., Yao, D., Li, X., Zhang, Y., Yang, L.T., Xiong, N. and Jin,H. (2013) Location-aware private service discovery in pervasivecomputing environment. Inf. Sci., 230, 78–93.

[4] Elgazzar, K., Martin, P. and Hassanein, H. (2012) A Frameworkfor Efficient Web Services Provisioning in Mobile Environments.Proc. 3rd Int. Conf. on Mobile Computing, Applications, andServices, Lecture Notes of the Institute for Computer Sciences,Social Informatics and Telecommunications Engineering 95,pp. 246–262. Springer, Berlin, Heidelberg.

[5] Hefeeda, M. (2004). Peer-to-Peer Systems. School of ComputingScience. Simon Fraser University, Surrey, Canada.

[6] Yang, B. and Garcia-Molina, H. (2002). Designing a super-peernetwork. Technical report, Stanford University. Available online:http://infolab.stanford.edu/∼byang/pubs/superpeer.pdf.

[7] Gnutella website. http://www.gnutella.com (accessed January,2013).

[8] Freenet website. http://freenet.sourceforge.net (accessed January,2013).

[9] Kazaa website. http://www.kazaa.com (accessed January, 2013).

[10] Lo, V., Zhou, D., Liu, Y., GauthierDickey, C. and Li, J. (2005)Scalable Supernode Selection in Peer-to-Peer Overlay Networks.Proc. 2nd Int. Workshop on Hot Topics in Peer-to-Peer Systems,La Jolla, California, USA, July, pp. 18–25.

[11] Kim, S.-K., Lee, K.-J. and Yang, S.-B. (2011) An EnhancedSuper-Peer System Considering Mobility and Energy In MobileEnvironments. Proc. 6th Int. Symp. on Wireless and PervasiveComputing, February, pp. 1–5.

[12] Mahdy, A.M., Deogun, J.S. and Wang, J. (2007) A DynamicApproach for the Selection of Super Peers in Ad Hoc Networks.Proc. 6th Int. Conf. on Networking, April, pp. 673–677.

[13] Kim, J.-H., Song, J.-W., Kim, T.-H. and Yang, S.-B. (2011)An enhanced double-layered P2P system for the reliability indynamic mobile environments. Comput. Inf., 30, 1001–1023.

[14] Soro, S. and Heinzelman, W.B. (2009) Cluster head electiontechniques for coverage preservation in wireless sensor networks.Ad Hoc Netw., 7, 955–972.

[15] Alsaliha, W., Hassaneinb, H. and Aklb, S. (2010) Placement ofmultiple mobile data collectors in wireless sensor networks. AdHoc Netw., 8, 378–390.



at Queen's U



ownloaded from

http://infolab.stanford.edu/~byang/pubs/superpeer.pdf

http://www.gnutella.com

http://freenet.sourceforge.net

http://www.kazaa.com



[16] Yu, J., Wang, N., Wang, G. and Yu, D. (2013) Connecteddominating sets in wireless ad hoc and sensor networks acomprehensive survey. Comput. Commun., 36, 121–134.

[17] Khabbazian, M., Blake, I.F. and Bhargava, V.K.B. (2012) Localbroadcast algorithms in wireless ad hoc networks: Reducingthe number of transmissions. IEEE Trans. Mob. Comput., 11,402–413.

[18] Elgazzar, K., Ibrahim, W., Oteafy, S. and Hassanein, H.S. (2013)RobP2P: A Robust Architecture for Resource Sharing in MobilePeer-To-Peer Networks. Proc. 4th Int. Conf. on Ambient Systems,Networks and Technologies, Halifax, NS, Canada, pp. 356–363.

[19] Skype website. http://www.skype.com (accessed January, 2013).[20] TerraNet website. http://terranet.se/ (accessed January, 2013).[21] Vishnumurthy, V. and Francis, P. (2007) A Comparison of

Structured and Unstructured P2P Approaches to HeterogeneousRandom Peer Selection. Proc. USENIX Annual Technical Conf.,Santa Clara, CA, USA, pp. 1–14.

[22] Iamnitchi, A., Foster, I. and Nurmi, D. C. (2002) A Peer-to-PeerApproach to Resource Discovery in Grid Environments. Proc.High Performance Distributed Computing, Edinburgh, Scotland.

[23] Chawathe, Y., Ratnasamy, S., Breslau, L., Lanham, N. andShenker, S. (2003) Making Gnutella-Like P2P Systems Scalable.Proc. 2003 Conf. on Applications, Technologies, Architectures,and Protocols for Computer Communications, Karlsruhe,Germany, pp. 407–418.

[24] Min, S.-H., Holliday, J. and Cho, D.-S. (2006) OptimalSuper-Peer Selection for Large-Scale P2P system. Proc. Int.Conf. on Hybrid Information Technology, ICHIT’06—Volume02, Washington, DC, USA, pp. 588–593. IEEE ComputerSociety.

[25] Merz, P., Priebe, M. and Wolf, S. (2008) Super-Peer Selectionin Peer-to-Peer Networks using Network Coordinates. Proc. 3rdInt. Conf. on Internet and Web Applications and Services,Athens,Greece, June, pp. 385–390.

[26] Liu, M., Harjula, E. and Ylianttila, M. (2013) An efficientselection algorithm for building a super-peer overlay. J. InternetServ. Appl., 4, 1–12.

[27] Jelasity, M., Kowalczyk, W. and Steen, M.V. (2003) NewscastComputing. Technical Report IRCS-006. Department of Com-puter Science, Vrije Universiteit, Amsterdam. 24 pages.

[28] Meads, A. and Warren, I. (2010) Extending Mobile ServiceMiddleware with Support for Context-Aware Service Processing.Proc. IEEE Region 10 Conf., Fukuoka, Japan, November,pp. 2418–2423.

[29] Han, J.-S., Lee, K.-J., Song, J.-W. and Yang, S.-B. (2008)Mobile Peer-to-Peer Systems using Super Peers for MobileEnvironments. Proc. Int. Conf. on Information Networking,Busan, South Korea, January, pp. 1–4.

[30] The Network Simulator website. http://www.nsnam.org(accessed January, 2013).



at Queen's U



ownloaded from

http://www.skype.com

http://terranet.se/

http://www.nsnam.org


A Resilient P2PArchitecture for Mobile Resource Sharing · management [1], heterogeneous resource...

Documents

Transcript of A Resilient P2PArchitecture for Mobile Resource Sharing · management [1], heterogeneous resource...