# SLoPCloud: An Efficient Solution for Locality Problem in Peer-to-Peer Cloud Systems
## 1 Introduction  
[PERSON] et al. [1] defined Cloud systems as \"a large-scale distributed computing paradigm that is driven by economies of scale, in which a pool of abstracted, virtualized, dynamically scalable, managed computing power, storage, platforms, and services are delivered on demand to external costumers over the Internet\". Such systems can be implemented as peer to peer (P2P) networks to avoid bottlenecks and single point of failure in addition to meeting other advantages of P2P systems [2; 3]. Cloud systems that are implemented as peer to peer networks are called P2P cloud systems. These systems have been become a very attractive area of research in recent years while P2P systems have become quite popular due to the ability of accessing shared resources, regardless of their location worldwide [4; 5; 6; 7]. In P2P cloud systems, services are offered at the end user machines, which referred to as peers, rather than any central server. In contrast to traditional client-server systems, services are provided directly between peers in P2P cloud systems. These systems usually form a logical layer over other networks, such as TCP/IP, as underlay or physical infrastructure. Despite the structure of P2P cloud systems, most of these systems consider no dependency between the real distance of the nodes and their position in the overlay network. Hence, if one of the nodes requests a service, it is not guaranteed to be assigned to the nearest available service providerin the physical network. Such mismatching may waste the network resources, such as bandwidth, and impose delay to the network services. The mismatching problem between the overlay and the physical or underlay layer is known as _locality problem_[8]. Locality problem is a challenging problem in P2P cloud systems as in the former P2P overlay networks such as Chord [9], Pastry [10], and Tapestry [11]. Unfortunately, locality is not considered in most of the current P2P designs. There are three main solutions to provide the locality in P2P Systems that suffer from some kind of deficiencies. The first one uses address prefixes to locate those nodes that are being geographically closer to each other, however, similar prefixes can be located at different geographic zones [12]. In addition, the prefixes could not be extracted from the hashed IP addresses. The second solution uses distributed reliable servers that are some kind of network hotspots, multiple single points of failure, and bottlenecks. The third category of locality solutions uses a method with the random initialization of node coordinates which leads to the high probability of instability of the network estimations and comparisons. Overall, these solutions are not suitable for most of the current P2P networks. In this paper, we extend our previous specific-purpose locality solution [13; 14] to become a general solution for locality problem in P2P cloud systems while increasing the performance of the network. Obviously, any solution for matching the position of joining nodes in overlay layer with their real physical position has some overhead. The overhead is typically control traffic overhead and imposed delay. Accordingly, we perform comprehensive simulations to represent the performance gain of our proposed solution. Moreover, simulation results show the applicability of this solution on most of the well-known overlay networks. Hereupon, the main contribution of this paper is to propose an efficient solution for locality problem based on RTT in P2P cloud systems. More specifically:  
1. This paper uses RTT as a metric to estimate the distance between nodes. Consequently, it proposes a locality solution referred to as SLoPcloud, to solve the mismatch problem between the overlay and physical layer. The proposed solution does not impose a serious overhead on network performance parameters, such as traffic and delay, while it could be applied to most of the well-known overlay networks. 2. This paper suggests a flexible topology, i.e.