Peer-to-Peer Data Structures Christian Scheideler Dept. of Computer Science Johns Hopkins University Peer-to-peer data structures Internet Data structures dispersed over dynamic set of potentially large number of peers Peer-to-Peer Data Structures 2 Outline of Talk How to design peer-to-peer forms of classical data structures like hash tables, skip lists, and search trees? How to formulate a general model for the design of peer-to-peer data structures? Peer-to-Peer Data Structures 3 Sequential data structures Hash table Skip list 2-3 tree [Pugh ‘90] [Hopcroft ’70] h How to design peer-to-peer forms of these data structures? Peer-to-Peer Data Structures 4 Parallel data structures Based on PRAM model or derivatives: Multiple processing units (1,2,…,n) P P .. local computation (1 step) .. P read, write (1 step) requests synchronized Linear addressable memory Peer-to-Peer Data Structures 5 Parallel Data Structures Parallel hash tables: n Insert/Delete operations: O(log * n) time n Search operations: O(1) time [Gil, Matias, Vishkin ’91], [Bast, Hagerup ’91] Parallel skip lists: n Insert/Delete/Search operations: O(log n) [Gabarro, Martinez, Messeguer ’94] Parallel 2-3 trees: n Insert/Delete/Search operations: O(log n) [Paul, Vishkin, Wagener ’83] Peer-to-Peer Data Structures 6 Are we done?? Limitation of parallel designs: only parallelize the way the data structure is accessed, not the data structure itself! Is it realistic to assume that a reliable shared memory can be provided in a peerto-peer system? If at all, the overhead is high! ( W(log n) time and work for read/write) Peer-to-Peer Data Structures 7 Peer-to-peer scenario Dynamic set of peers, no consecutive numbers P P .. .. P Reliable shared memory Peer-to-Peer Data Structures 8 Peer-to-peer data structures Basic requirements: Remains well-connected even under massive failures. Desirable: high expansion U N(U) min |N(U)| U |U| Low maintenance overhead. Necessary: low degree Allows efficient concurrent execution of operations. Peer-to-Peer Data Structures 9 Sequential data structures Hash table Skip list 2-3 tree [Pugh ‘90] [Hopcroft ’70] h How to design peer-to-peer forms of these data structures? Peer-to-Peer Data Structures 10 Hash graphs [Stoica, Morris, Karger, Kaashoek, and Balakrishnan ’01] Idea: organize objects in cycle according to hash function h:Names [0,1). 0.28 0.43 Peer-to-Peer Data Structures 0.58 11 Hypercubic Shortcuts 1 0 +1/2 +1/4 fingers +1/8 +1/16 x Peer-to-Peer Data Structures 12 Hypercubic Pointer Structure Peer-to-Peer Data Structures 13 Sequential data structures Hash table Skip list 2-3 tree [Pugh ‘90] [Hopcroft ’70] h How to design peer-to-peer forms of these data structures? Peer-to-Peer Data Structures 14 Skip Graphs [Aspnes and Shah ’03] Basic approach: organize objects in cycle according to real names. Apple Banana Peer-to-Peer Data Structures Cherry 15 Skip Graphs Shortcuts: pad each object with random bits 1 1 1 0 0 1 1 1 0 0 1 1 0 0 0 1 0 0 1 Peer-to-Peer Data Structures 0 16 Sequential data structures Hash table Skip list 2-3 tree [Pugh ‘90] [Hopcroft ’70] h How to design peer-to-peer forms of these data structures? Peer-to-Peer Data Structures 17 2-3 Graphs [Awerbuch & Scheideler ’04] Same basic approach: organize objects in cycle according to real names. Apple Banana Peer-to-Peer Data Structures Cherry 18 Shortcuts: Intertwined Rings bridge Peer-to-Peer Data Structures 19 Insert and Delete Inserting a node: Peer-to-Peer Data Structures 20 Insert and Delete Deleting a node: Peer-to-Peer Data Structures 21 k-separated 2-3 Graph In every level, bridges are k nodes apart. How large does k have to be to guarantee 1/polylog expansion a? Theorem: a = (1/2) W(log n / k 2 ) min |N(U)| U N(U) So k has to be non-constant ( W( log ). U n )|U| Do areas with old insertions/deletions have to be revisited?? Peer-to-Peer Data Structures 22 k-separated 2-3 Graph Rule: Choose k=6(d+3) d: current degree of node initiating op. Theorem: degree: 2(log n +/- 2) expansion: W(1/log n) work for Insert/Delete: O(log3 n) e Similar DS but only with 1/n expansion in worst case was proposed by [Harvey & Munro ’03] Peer-to-Peer Data Structures 23 Outline of Talk How to design peer-to-peer forms of classical data structures like hash tables, skip lists, and search trees? How to formulate a general model for the design of peer-to-peer data structures? Peer-to-Peer Data Structures 24 Hierarchical vs. Flat Internet Peer-to-Peer Data Structures 25 How do objects find each other? Internet Peer-to-Peer Data Structures 26 Model (JXTA) Application searching, multicast Middleware shared space, DNS Core rendezvous service Network Peer-to-Peer Data Structures 27 Middleware Model Actor local computation (1 step) leave P/M spawn P/M notify (1 step for reliable actors) P/M P/M P/M join(AID) join (to (un)register(AID) random bootstrap actor) notify Rendezvous Simplified model, sufficientservice for most purposes Peer-to-Peer Data Structures 28 Application Model Common approach: shared space may be unreliable! Operations: space operations Insert(addr, o) Delete(addr) Lookup(addr) Join(peer) Leave() peer operations Available to application-level data structures Peer-to-Peer Data Structures 29 Shared Space Consistent hashing: [Karger et al. ’97] h:Addr [0,1), g:Peers [0,1) Object o stored at peer p with min g(p) s.t. h(o)<g(p) 0.34 0.28 0.43 Peer-to-Peer Data Structures 0.58 30 Shared Space Solutions: Chord, CAN, Pastry, Tapestry (~2001/02) OpenHash, KBR, Bamboo (more open) Problems: How to deal with heterogeneous peers? How to deal with adversarial peers? Peer-to-Peer Data Structures 31 Heterogeneous Peers Peers of non-uniform bandwidth: Previous approach: cut into uniform peers, multi-tier architecture (KaZaA) Our approach [SPAA 2004] : PAGODA Thm: Any concurrent multicast problem can be routed in PAGODA with at most O(D+log n) more congestion than with best possible network of degree D. Peers of non-uniform memory size: Previous approach: as above Our approach [SPAA 2004] : Thm: As long as peers are at most (1-e)-utilized, an O(e) rate of insert/delete requests to peers can be sustained. Peer-to-Peer Data Structures 32 Adversarial Peers Assumption: e-fraction of peers adversarial Challenges: Organization of peers in regions Enforcement of random IDs stochastic process / secure peer-to-peer random number generator based on verifiable secret sharing Enforcement of limited lifetime Results: (only Join/Leave) Trust-but-Verify [IPTPS 2004] Group Spreading [ICALP 2004] Enforced Spreading [submitted] Peer-to-Peer Data Structures 33 Conclusion In this talk: Peer-to-peer forms of classical data structures General model for peer-to-peer data structures Challenges: Data structures for unreliable shared space Stability studies (reliable/adversarial peers) Locally self-stabilizing data structures Other applications: mobile ad-hoc, configware Peer-to-Peer Data Structures 34 Questions ??