Protocols for Implementing Histogram LOB in chord Networks S.BhagyaRekha Assistnat Professor, Vignana Bharathi Institute of Technology Ghtkesar-Hyderabad Telangana Abstract - Peer-to-Peer networks have grown most important now- a - days. Load balancing is the most important feature for networks. In this paper, we provide here with Load balancing techniques for Peer – to – Peer Networks. We further provide here with protocols for chord networks. Here we provide two protocols for Load Balancing techniques. Our first protocol balances the distribution of the key address space to nodes, which yields a load-balanced system when the DHT maps items “randomly” into the address space. Our second protocol aims to directly balance the distribution of items among the nodes. This is useful when the distribution of items in the address space cannot be randomized—for example, if we wish to support range searches on “ordered” keys. We give a simple protocol that balances load by moving nodes to arbitrary locations “where they are needed.” As an application, we use the last protocol to give an optimal implementation of a distributed data structure for range searches on ordered data. Keywords – P2P Systems, Load balancing ,Chord Networks. 1. INTRODUCTION A core problem in peer to peer systems is the distribution of items to be stored or computations to be carried out to the nodes that make up the system. A particular paradigm for such allocation, known as the distributed hash table (DHT), has become the standard approach to this problem in research on peer-to-peer systems [7, 10, 12, 15]. An important issue in DHTs is load-balance — the even distribution of items (or other load measures) to nodes in the DHT. All DHTs make some effort to load balance, generally by (i) randomizing the DHT address associated with each item with a “good enough” hash function and (ii) making each DHT node responsible for a balanced portion of the DHT address space. Chord is a prototypical example of this approach: its “random” hashing of nodes to a ring means that each node is responsible for only a small interval of the ring address space, while the random mapping of items means that only a limited number of items land in the (small) ring interval owned by any node. This attempt to load-balance can fail in two ways. First, the typical “random” partition of the address space among nodes is not completely balanced. Some nodes end up with a larger portion of the addresses and thus receive a larger portion of the randomly distributed items. Second, some applications may preclude the randomization of data items’ addresses. For example, to support range searching in a database application the items may need to be placed in a specific order, or even at specific addresses, on the ring. In such cases, we may find the items unevenly distributed in address space, meaning that balancing the address space among nodes is not adequate to balance the distribution of items among nodes. We give protocols to solve both of the load balancing challenges just described. Address-Space Balancing. Current distributed hash tables do not evenly partition the address space into which keys get mapped; some machines get a larger portion of it. Thus, even if keys are numerous and random, some machines receive more than their fair share, by as much as a factor of O(logn) times the average. To cope with this problem, many DHTs use virtual nodes: each real machine pretends to be several distinct machines, each participating independently in the DHT protocol. The machine’s load is thus determined by summing over several virtual nodes’, creating a tight concentration of (total) load near the average. As an example, the Chord DHT is based upon consistent hashing [8], which requires O(logn) virtual copies to be operated for every node. Virtual nodes have drawbacks. Besides increased storage requirements, they demand network bandwidth. In general, to maintain connectivity of the network, every (virtual) node must frequently ping its neighbors, make sure they are still alive, and replace them with new neighbors if not. Running multiple virtual nodes creates a multiplicative increase in the (very valuable) network bandwidth consumed for maintenance. Below, we will solve this problem by arranging for each node to activate only one of its O(logn) virtual nodes at any given time. The node will occasionally check its inactive virtual nodes, and may migrate to one of them if the distribution of load in the system has changed. Since only one virtual node is active, the real node need not pay the original Chord protocol’s multiplicative increase in space and bandwidth costs. As in the original Chord protocol, our scheme gives each real node only a small number of “legitimate” addresses on the Chord ring, preserving Chord’s (limited) protection against address spoofing by malicious nodes trying to disrupt the routing layer. (If each node could choose an arbitrary address, then a malicious node aiming to erase a particular item could take responsibility for that item’s key and then refuse to serve the item.) Another nice property of this protocol is that the “appropriate” state of the system (i.e., which virtual nodes are active), although random, is independent of the history of item and node arrivals and departures. This Markovian property means that the system can be analyzed as if it were static, with a fixed set of nodes and items; such analysis is generally much simpler than a dynamic, history- dependent analysis. S.BhagyaRekha / (IJCSIT) International Journal of Computer Science and Information Technologies, Vol. 7 (1) , 2016, 149-152 www.ijcsit.com 149