190 likes | 279 Views
Decentralized Location Services. CS273 Guest Lecture April 24, 2001 Ben Y. Zhao. Review: Object Location. Neighborhood covers Each server knows about all objects in its neighborhood Object implosion at root cover node Goals: Given ID, Locate nearest object in network
E N D
Decentralized Location Services CS273 Guest Lecture April 24, 2001 Ben Y. Zhao
Review: Object Location • Neighborhood covers • Each server knows about all objects in its neighborhood • Object implosion at root cover node • Goals: • Given ID, Locate nearest object in network • Do so w/o centralization
PRR (SPAA 97) • Namespace large enough to avoid collisions (N, Log2(N) bits) • Insert Object: • Hash Object into namespace • For (i=0, i<Log2(N), i++) { • Insert entry into nearest node matches onlast i bits • If no matching node, then pick node w/ i-1 bits with highest ID value
PRR97 Object Lookup • Lookup object • Traverse same nodes as insert, except searching for entry at each node • For (i=0, i<Log2(N), i++) { • Search for entry in nearest node matching onlast i bits • Expected length of pointer at ithnode is 2i
Neighbor Map For “6271” (Octal) 0271 x071 xx01 xxx0 1271 x171 xx11 6271 2271 6271 xx21 xxx2 3271 x371 xx31 xxx3 4271 x471 xx41 xxx4 5271 x571 xx51 xxx5 6271 x671 xx61 xxx6 7271 x771 6271 xxx7 4 3 2 1 Routing Levels PRR97 Reaching nodes • Routing between successive nodes • Pointer map required • Forwarding for any object name • Needs to be compact • Reduce complexity, insert at node matching every n bits
PRR97 Limitations • Setting up the pointer maps • Uses global knowledge • Lack of adaptability in dynamic systems • Finding node with i matching bits • How do you find node with highest ID value • What happens as network changes • Need to maintain deterministic way to find the same node over time
Tapestry • Zhao, Kubiatowicz and Joseph • Help from Hildrum, Rao, Zhuang, et al. • A fault-tolerant wide-area location and routing application infrastructure • Core location/routing based on PRR97 • Algorithmic and system extensions • Decentralized dynamic algorithms • Redundancy everywhere for fault-tolerance
What do we want • A dynamic mapping algorithm • Deterministic over network changes • Globally consistent mapping • Assumptions • All nodes with same matching suffix contains same null/non-null pattern in next level of routing map • Requires: consistent knowledge of nodes across network
Dynamic Object Mapping • Mapping object ID to deterministic sequence of nodes to store location ptrs • At ith hop while routing to object ID • Insert entry in local storage • If no next node exists matching i+1 digits • Route on next highest indexed non-null pointer • End node reached when no other pointers in rest of route map • Else route to nearest such digit
Analysis Globally consistent deterministic mapping • Null entry no node in network with suffix • consistent map identical null entries across same route maps of nodes w/ same suffix Additional hops compared to PRR solution: • Reduce to coupon collector problemAssuming random distribution • With n ln(n) + cn entries, P(all coupons) = 1-e-c • For n=b, c=b-ln(b), P(b2nodes left) = 1-b/eb = 1.8 10-6 • # of additional hops Logb(b2) = 2 Distributed algorithm with minimal additional hops
Border Cases • Two cases • A. If a node disappeared, and some node did not detect it. • Routing proceeds on invalid link, fails • No backup router, so proceed to surrogate routing • B. If a node entered, has not been detected, then go to surrogate node instead of existing node • New node checks with surrogate after all such nodes have been notified • Route info at surrogate is moved to new node
Algorithm: Dynamic Insertion • New node desires integration w/ ID 11111 • Step 1: copy route map recursively ?1111 ??111 ???11 ????1 11111
Dynamic Insertion cont. • Step 2: Get relevant data from surrogateinform edge nodes of your existence • Step 3: Notify neighbors to optimize paths surrogate .. ?1111 ... ... ..
Summary • Globally unique names • Objects and nodes • Randomly distributed • Represented as digits of size b = 2i • Per node routing table size: bLogb(N) • N = size of namespace, n = # of nodes • Find object in Logb(n) hops • Key properties • Application controls modifications to object • Overlay follows physical network distance
Alternatives: P2P Indices • Content Addressable Networks • Ratnasamy et al. • ACIRI / Berkeley • Chord • Stoica, Morris, Karger, Kaashoek, Balakrishnan • MIT / Berkeley • Pastry • Druschel and Rowstron • Rice / Microsoft Research
Content-Addressable Networks • Distributed hashtable addressed in d dimension coordinate space • Routing table size: O(d) • Hops: expected O(dN1/d) • N = size of namespace in d dimensions • Efficiency via redundancy • Multiple dimensions • Multiple realities • Reverse push of “breadcrumb” caches • Assume immutable objects
Chord • Associate each node and object a unique ID in uni-dimensional space • Object O stored by node with highest ID < O • Finger table • Pointer for next node 2i away in namespace • Table size: Log2(n) • n = total # of nodes • Find object: Log2(n) hops • Optimization via heuristics Node 0 0 1 7 2 6 3 5 4
Pastry • Incremental routing like Plaxton / Tapestry • Object replicated at x nodes closest to object’s ID • Routing table size: b(LogbN)+O(b) • Find objects in O(LogbN) hops • Issues: • Does not exploit locality • Infrastructure controls replication and placement • Consistency / security
Comparing Key Metrics Chord CAN Pastry Tapestry • Properties • Parameter • Logical Path Length • Neighbor-state • Routing Overhead (RDP) • Messages to insert • Mutability • Load-balancing Base b None Dimen d Base b Logb(N) O(d*N1/d) Logb(N) Log2(N) bLogb(N) bLogb(N)+O(b) Log2(N) O(d) O(1) ? O(1)? O(1) O(1) O(Log22(N)) O(d*N1/d) O(Logb2(N)) ? O(Logb(N)) App-dep. ??? App-dep Immut. Good Good Good Good Designed as P2P Indices