Peer-to-Peer Information Systems Week 12: Naming Old Dominion University Department of Computer Science CS 495/595 Fall 2004 Michael L. Nelson <mln@cs.odu.edu> 11/16/04

Naming, or “The Lookup Problem” Not really addressed in the Oram book The bulk of this lecture comes from: "Looking Up Data in P2P Systems”, http://doi.acm.org/10.1145/606272.606299 "Maintenance-Free Global Data Storage”, http://oceanstore.cs.berkeley.edu/publications/papers/pdf/ieeeic.pdf Lookup problem: how do you find any given data item in a large P2P system in a scalable manner without any centralized servers or hierarchy?

Data Lookup Approaches Napster approach: 1 root server (or set of root servers) that know the node location of data objects not scalable, not resilient Gnutella approach: broadcast search to all known neighbors until the object is found scalability problems

Data Lookup Approaches Superpeers (KaZaA, Gnutella Reflectors) scalability through hierarchy questions about resiliency creating many “little Napsters” Freenet symmetric lookup forward lookup requests to a node that is “closer” to the data object focus on anonymity makes it difficult to have predictable topologies; also makes data stewardship difficult

Distributed Hashes Premise: don’t: do: keep an index do traditional searches do: tie object location to name employ a common hashing algorithm to map name to location

Distributed Hashing Projects see http://www.etse.urv.es/~cpairot/dhts.html for more links CAN http://www.icir.org/sylvia/ Chord http://www.pdos.lcs.mit.edu/chord/ Kademlia http://kademlia.scs.cs.nyu.edu/ Pastry http://freepastry.rice.edu/ Tapestry http://www.cs.berkeley.edu/~ravenben/tapestry/ Viceroy http://www.wisdom.weizmann.ac.il/~naor/viceroy.pdf

Common Elements of Distributed Hashing Lookup Algorithms Mapping keys to nodes in a load balanced way keys & nodes identified using m-bit ids each key is stored at >= 1 nodes which have node ids “close” to the key Forwarding a lookup for a key to an appropriate node a node that recvs a request for key s must be able to forward it to a node that is “closer” to s. from p. 45, CACM 46(2)

Common Elements of Distributed Hashing Lookup Algorithms distance function regardless of implementation, the algorithms must support “distance” semantics adaptively build routing tables routing tables are kept to store the location of other nodes routing tables must be correctly maintained in the face of asynchronous & concurrent joins and failures O(log N) lookup time from p. 45, CACM 46(2)

Chord each node keeps a list (“finger table”) of (log N) nodes: 1/2 the way through id space 1/4 the way 1/8 the way 1/16 the way etc… node 8 node 52 node 22 node 42 node 32 node 28 node 52 is responsible for K52 - K63 cf. Akamai’s consistent hashing…

Routing in Chord When a node receives a query for a key k, it forwards the query to the node in the finger table with the highest ID <= k the node with ID <= k is known as the “successor” of k intuitively, we see that this is O(log N)

Routing Example lookup(58) K58 node 64 node 1 node 8 node 56 node 52

Routing Example K128 lookup(128) node 128 node 64 node 1 node 8

Successor Lists For resiliency, each node in Chord will keep track of r successors e.g., r nodes immediately “after” it in ID space r ~ log N Think of the successor list as a short-range backup in case some of the long-arcing fingers are down lookup fails only if all fingers and successors fail IDs are randomly assigned to nodes, so it is unlikely that simultaneous, related failures will take contiguous sections of ID space

Adding New Nodes in Chord a new node n asks an existing node to lookup(n) n and its predecessor must update their successor list other nodes will update their successor lists during maintenance this is for optimization, not correctness… a Chord ring with new nodes is still correct, just not optimal

Successor List Maintenance each node n periodically contacts its successor s(n) and requests it for its predecessor p(s(n)) if p(s(n)) != s(n), then do maintenance a node has either joined or failed…

Tapestry Chord is the distributed naming service for projects such as the Cooperative File System… …Tapestry is a similar distributed hashing algorithm for the OceanStore global, distributed data storage system

Tapestry GUIDs Storage nodes, data objects and messages all receive GUIDs that are location- and semantics-independent OceanStore publishes pointers to object locations by placing a pointer to the object’s replica location at each hop between the new replica and the objects root node objects root node is a function of the objects GUID To locate an object: route a message to the object’s root node until a replica pointer is found…

Tapestry API publishObject(ObjectID, [serverID]) sendmsgToObject(ObjectID) sendmsgToNode(NodeID)

Tapestry Routing figure 2 from IEEE IC, Sept/Oct 2001, p. 43

Tapestry Insertion slides from Ben Zhao, UCB

UUIDs / GUIDs UUIDs and GUIDs, Internet Draft, Leach http://www.ics.uci.edu/~ejw/authoring/uuid-guid/draft-leach-uuids-guids-01.txt according to Jim Whitehead, the proposed RFC overlapped with an ISO standard, and the IETF did not want to duplicate effort http://mailman.lyra.org/pipermail/dav-dev/1999-May/000245.html 128 bit ID guaranteed to be different (or very likely different, depending on generation mechanism) until 3400 A.D. see, in particular, sections 3.1.2, 3.2.1, 3.3, 3.4

Open Issues Distance function matters… Very little practical experience (yet) in building real large-scale systems Improved proximity routing Malicious and byzantine nodes Keyword search? cf. Freenet…