1 / 13

Common approach

Common approach. 1. Define space: assign random ID (160-bit) to each node and key 2. Define a metric topology in this space, that is, the space of keys and node IDs 3. Each node keeps contact information to O(log n) other nodes 4. Provide a lookup algorithm, which maps a key to a node

wardah
Download Presentation

Common approach

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Common approach 1. Define space: assign random ID (160-bit) to each node and key 2. Define a metric topology in this space, • that is, the space of keys and node IDs 3. Each node keeps contact information to O(log n) other nodes 4. Provide a lookup algorithm, which maps a key to a node • i.e., find the node, whose ID is closest to a given key • the metric identifies closest node uniquely 5. Store and retrieve a key/value pair at the node whose ID is closest to the key (ro alternative functionality)

  2. DHT: Comparison axes • Efficiency • Lookup, insertion, deletion • Size of Routing Table • How much state information maintained on each peer • O(n), O(log N) or O(1) • Tradeoff: Larger state  higher maintenance cost (but faster lookup) • Flexibility of Routing • Rigid routing table • Requires higher maintenance costs – need to detect and fix failures immediately • Complicates recovery • Preclude proximity-based routing

  3. Chord: MIT • Overlay: • Peers are organized in a ring • Successor peer • <k, value> is stored on the successor of k • Routing: • Finger Table: • More info for near part of the ring • Large jumps, then shorter jumps • Resembling a binary search

  4. Chord: Characteristics • Efficient directory operations • insertion, deletion, lookup • Analysis • O(logN) routing table size • O(logN) logic steps to reach the successor of a key k • O(log2N) for peer joining and leaving • High maintenance cost • Node join/leave induces state change on other nodes • Rigidity of Routing Table (in original proposal): • For a given network, there is only one optimal/ideal state • Unique, and deterministic

  5. CAN: Berkeley • Overlay: • A virtual d-dimensional Coordinate space • Each peer is responsible for a zone • Routing: • Each peer maintains info about neighbors • Greedy algorithm for routing • Routing table d information • Joining • chose random point, split its zone • Performance Analysis: • Expected: (d/4)(n1/d) steps for lookup • d: dimension

  6. Pastry: Rice • Circular namespace • Routing Table: • Peer p, ID: IDp • For each prefix of IDp, keep a set of peers who shares the prefix and the next digit is different from each other. • Routing: • Plaxton algorithm • Choose a peer whose ID shares the longest prefix with target ID • Choose a peer whose ID is numerically closest to target ID • Exploit the locality • Similar analysis properties with Chord

  7. Symphony: Stanford • Distributed Hashing in a Small World • Like Chord: • Overlay structure: ring • Key ID space partitioning • Unlike Chord: • Routing Table • Link to immediate neighbor (replicate for reliability) • k long distance links for jumping (not replicated) • Long distance links are built in a probabilistic way • Neighbors are selected using a Probability Distribution Function (pdf) • Exploit the characteristics of a small-world network • Dynamically estimate the current system size

  8. Symphony: Performance • Each node has k = O(1) long distance links • Lookup: • Expected path length: O(1/k * log2N) hops • Join & leave • Expected: O(log2N) messages • Comparing with Chord: • Discard the strong requirements on the routing table (finger table) • Idea that has been incorporated in Chord in a different way.

  9. Kademlia: NYU • Overlay: • Node Position: • shortest unique prefix • Service: • Locate closest nodes to a desired ID • Routing: • “based on XOR metric” • keep k nodes for each sub-tree which shares the root as the sub-trees where p resides. • Share the prefix with p • Magnitude of distance (XOR) • k: replication parameter (e.g. 20)

  10. Kademlia: • Comparing with Chord: • Like Chord: achieving similar performance • Routing table size: O(logN) • Lookup: O(logN) • Lower node join/leave cost • Deterministic • Unlike (the original) Chord: • Flexible Routing Table • Given a topology, there are more than one routing table • Symmetric routing

  11. Skip Graphs: Yale • Based on “skip list” [1990] • A randomized balanced tree structure organized as a tower of increasingly sparse linked lists • All nodes join the link list of level 0 • For other levels, each node joins with a fixed probability p • Each node has 2/(1-p) pointers • Average search time: O(log N) (same for insert, delete)

  12. Skip Graph: • Skip List is not suitable for P2P environment • No redundancy, Hotspot problem • Vulnerable to failure and contention • Skip Graph: Extension of Skip List • Level 0 link list builds a Chord ring • Multiple (max 2i) lists for level i (i = 1, … logn) • Each node participate in all levels, but different lists • Membership vector m(x): decide which list to join • Every node sees its own skip list

  13. Skip Graph: • Performance: • Since the membership vector is random, the performance analysis is also probabilistic. • Expected Lookup cost: • O(log n) messages (conclusion from skip list) • Insertion: • same as search, but more complicated due to the concurrent join • Overall about skip graph: • Probabilistic (like Symphony) • Routing table is flexible • Given the same participating node set, no fixed network structure

More Related