P2P Lookup Protocols
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

P2P Lookup Protocols

on

  • 419 views

Presentation outline: ...

Presentation outline:
P2P Basics
Architecture
Lookup in P2P
Related work in P2P Lookup Protocols
Chord Protocol
Cluster based and Routing Balanced P2P Lookup Protocol
PathFinder
LiChord
Proposed P2P Lookup Model based on RCC8 and Scalable Bloom Filter
Future work for proposed P2P lookup model

Statistics

Views

Total Views
419
Views on SlideShare
419
Embed Views
0

Actions

Likes
0
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-NonCommercial-NoDerivs LicenseCC Attribution-NonCommercial-NoDerivs LicenseCC Attribution-NonCommercial-NoDerivs License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

P2P Lookup Protocols Presentation Transcript

  • 1. Zubin BhuyanMTech (IT), Tezpur University,Assam, INDIADistributed System
  • 2. Outline P2P Basics Architecture Lookup in P2P Related work in P2P Lookup Protocols Chord Protocol Cluster based and Routing Balanced P2P LookupProtocol PathFinder LiChord Proposed P2P Lookup Model based on RCC8and Scalable Bloom Filter Future work for proposed P2P lookup model
  • 3. P2P Basics A model of decentralized communicationwhere every node in the network acts alike without any centralized control or hierarchicalorganization Nodes in such a P2P network are bothsuppliers and consumers of resources Nodes are autonomous popularized by file sharing systems likeNapster
  • 4. P2P Architecture Architecture determines structure of overlaynetwork Structured P2P network Peers are organized following specific criteria andalgorithms Unstructured P2P network Network does not provide any algorithm fororganization Pure P2P systems Centralized peer-to-peer systems
  • 5. P2P Architecture
  • 6. P2P Lookup Providing object location service in P2Psystem P2P system may involve thousands or millionsof live peers (nodes) Deliver high quality service with low responselatency Structured networks -> DHT Unstructured networks -> Exhaustivesearching like Bubble Storm, etc.
  • 7. P2P Lookup challanges Population dynamism Content dynamism Heterogeneity
  • 8. I. Stoica, R. Morris, D. Karger, M. F. Kaashoek,H. Balakrishnan, “Chord: A Scalable Peer-to-peer Lookup Service for InternetApplications”, SIGCOMM, 2001CHORD: A Scalable Peer-to-PeerLookup Protocol
  • 9. CHORD Efficient lookup of a node which stores dataitems for a particular search key. Provides only one operation: given a key, itmaps the key onto a node. Distributed Hash Table approach balances theload When Nth node joins or leaves only O(1/N)fraction of keys moved. Nodes maintains fingers (links) to otherspecific peers
  • 10. Lookup Using Finger TableN1N8N14N21N32N38N42N51N56N48lookup(54)
  • 11. Y. Liu, M. Chen, “Cluster-Based and RoutingBalanced P2P Lookup Protocol” Eighth ACISInternational Conference on Software Engineering,Artificial Intelligence, Networking, andParallel/Distributed ComputingCluster-Based and Routing Balanced P2PLookup Protocol
  • 12. Cluster-Based and RoutingBalanced P2P Lookup Protocol All peers are grouped into clusters accordingto cost in latency A hash function assigns each node and key anm-bit identifier Nodes identifier is hashed IP address Keys identifier is produced by hashing the key Identifiers are ordered in an identifier circlemodulo of 2m
  • 13. Cluster-Based and RoutingBalanced P2P Lookup Protocol Construction: Requires M well-known landmark machines CRP constructs M clusters based on theselandmarks and names them by landmarksnumber, called CID All nodes measure their round-trip-time (RTT) toeach of these landmarks attaches themselves to any one of these nodes basedon minimum RTT value Nodes that have the same CID are grouped intoone cluster Clustered nodes are ordered in a sub-circleaccording to their identifier
  • 14. Cluster-Based and RoutingBalanced P2P Lookup Protocol
  • 15. Cluster-Based and RoutingBalanced P2P Lookup Protocol Intra Cluster Lookup Tree: Inside the cluster, CRP constructs a completeand unique balanced lookup tree for eachnode In the lookup tree of node K, the rest nodes inthe cluster are laid out counterclockwise fromnodeLookup tree of Node 0 of previous diagram
  • 16. Cluster-Based and RoutingBalanced P2P Lookup Protocol Lookup Table: Lookup table is composed of inner-clustersection and outer-cluster section Inner-cluster section is a list of (target,forwarder) pairs Outer-cluster section has at most M-1 rows each row shows the corresponding node inother different clusters These nodes are the closest nodes to node
  • 17. Dirk Bradler, Lachezar Krumov, Max Mühlhäuser,Jussi Kangasharju, “PathFinder: EfficientLookups and Efficient Search in Peer-to-PeerNetworks”, 12th International Conference onDistributed Computing and Networking, 2011PathFinder: Efficient Lookups and EfficientSearch in Peer-to-Peer Networks
  • 18. PathFinder Attempts to combines an unstructured and astructured network in a single overlay Builds a robust network of virtual nodes on topof the physical peers Actual data transfer still takes place directlyamong the physical peers Based on random graph theory
  • 19. PathFinder Construction Two Pseudo Random Number Generators areused Given a number c, the first generator returnsPoisson distributed numbers with mean value c. The second pseudo number generator given anode ID produces a deterministic sequence ofnumbers which is used as IDs for the neighborsof the given node [It is known that the degree sequence in arandom graph is Poisson distributed.]
  • 20. PathFinder Construction PathFinder starts construction of the numberby choosing a number, c, according to the sizeof the network required Then, for each virtual node determine thenumber of neighbors with the first numbergenerator The actual nodes IDs to which the currentvirtual node should be connected are chosenwith the second number generator
  • 21. PathFinder Routing Table Each peer keeps track of its own outgoing links and incominglinks from other virtual nodes A peer learns the incoming links when the other peersattempt to connect to it Keeping track of incoming links makes key lookups much moreefficient
  • 22. PathFinder Storing Objects: An object is stored on the virtual node which matches theobject’s identifier Key Lookup Suppose that peer A wants to retrieve an object O. Peer Adetermines that the virtual node w is responsible for object Oby using the hash function described above For each virtual node who is its neighbors, A calculates theneighbors of those nodes using the PRNG. This process is repeated recursively until the required virtualnode for O is found The average path length of PathFinder is , where N is thenumber of virtual nodes and c is the average number ofneighbors
  • 23. Shuling Wang, Shoubao Yang, Liangmin Guo,“LiChord: A Linear Code Based Structured P2Pfor Approximate Match”, Third InternationalConference on Communications and MobileComputing (CMC), April 2011LiChord: A Linear Code based structuredP2P for Approximate Match
  • 24. LiChord General DHT-based structured P2P applicationscan work only for exact match cases LiChord has been proposed to overcome thisproblem by employing a mapping process thatcan give approximate match for lookup operations Hamming Distance performs a mapping of node identifiers onto k-bitslong codes objects are mapped to nbits long ones
  • 25. LiChord Index Distribution A hash function is applied in LiChord to assignnode i a k-bits node identifier IDi by hashingnode i’s IP address all of these nodes denoted by u are organizedin the same way with Chord based on thepartial order of u Objects’ identifiers are produced byconsecutive insertions operated onto an emptybloom filter
  • 26. LiChord Query Identification Queries in LiChord are identified in the sameway as objects a query requesting for keys x, y and z, theidentifier of this query is 010111000001010010
  • 27. Proposed P2P Lookup Model based onRCC8 and Scalable Bloom Filter
  • 28. Proposed P2P Lookup Model based on RCC8 andScalable Bloom Filter The region connection calculus (RCC) serves forqualitative spatial representation and reasoning RCC8 consists of 8 basic relations that are possiblebetween two regions: disconnected (DC) externally connected (EC) equal (EQ) partially overlapping (PO) tangential proper part (TPP) tangential proper part inverse (TPPi) non-tangential proper part (NTPP) non-tangential proper part inverse (NTPPi)
  • 29. Proposed P2P Lookup Model based on RCC8 andScalable Bloom Filter Assumption: The overlay of virtual nodes, datakeys are arranged on the basis of similarity usingHamming distance calculated from Bloom Filter we use a PathFinder like lookup mechanism to restrict the unnecessary bubbling of data andlookup query, we propose a Bloom Filter to restrictthe query propagation in a specific direction achieved by using a bloom filter to generate keysfor objects Scalable Bloom Filter may be used
  • 30. Proposed P2P Lookup Model based on RCC8 andScalable Bloom Filter For very large topologies, the number of hashfunctions for the bloom filter might not suffice The entire topology might be divided into differentregions based on the Hamming distances of theobjects keys stored in the nodes Use RCC8 to decide propagation or restriction ofqueries in between regions Since the object key generating Bloom Filter isavailable to everyone, every node in the overlayneeds to know the Region SeparationParameter (RSP). RSP is Hamming distance among object keys, whichis used to determine whether an object belongs to asame region or not
  • 31. Proposed P2P Lookup Model based on RCC8 andScalable Bloom Filter Proposed idea, in theory, should showimproved performances over existing P2Pmodels because we have used selectivedirectional propagation of queries No unnecessary query propagation is done Dividing the entire system into regions basedon similarity helps in deciding when the querybroadcast has to be stopped
  • 32. Future work for proposed P2PLookup model More extensive study of the idea has to bedone. Proper formal definition of rules for thealgorithm has to be formulated. Exact arrangement and selection of hashfunctions for the Scalable Bloom Filter A generic heuristic for determining RSP needsto be done. Simulation and comparison with other P2PLookup Protocols is required
  • 33. References Shuling Wang, Shoubao Yang, Liangmin Guo, “LiChord: A Linear Code Based StructuredP2P for Approximate Match”, Third International Conference on Communications and MobileComputing (CMC), April 2011 R. Ahmed, R. Boutaba, “A Survey of Distributed Search Techniques in Large ScaleDistributed Systems”, IEEE Communications Surveys & Tutorials, Second Quarter 2011 Dirk Bradler, Lachezar Krumov, Max Mühlhäuser, Jussi Kangasharju, “PathFinder: EfficientLookups and Efficient Search in Peer-to-Peer Networks”, 12th International Conference onDistributed Computing and Networking, 2011 I. Stoica, R. Morris, D. Karger, M. F. Kaashoek, H. Balakrishnan, “Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications”, SIGCOMM, 2001 W. Terpstra, J. Kangasharju, C. Leng, , A. Buchmann, “Bubblestorm: resilient, probabilistic,and exhaustive peer-to-peer search”, Proc. SIGCOMM, pp. 49–60, 2007 Donald Knuth. "The Art of Computer Programming”, Errata for Volume 3 (2nd ed.) Randell, D. A., Cui, Z. and Cohn, A. G.: A spatial logic based on regions and connection, Proc.3rd Int. Conf. on Knowledge Representation and Reasoning, Morgan Kaufmann, San Mateo, pp.165–176, 1992. P. Almeida, C. Baquero, N. Preguica, D. Hutchison, "Scalable Bloom Filters", InformationProcessing Letters 101 (6): 255–261, 2007. Y. Liu, M. Chen, “Cluster-Based and Routing Balanced P2P Lookup Protocol” Eighth ACISInternational Conference on Software Engineering, Artificial Intelligence, Networking, andParallel/Distributed Computing
  • 34. Thank You!!