1. Peer-to-Peer Information Systems Week 12: Naming
Old Dominion University
Department of Computer Science
CS 495/595 Fall 2004
Michael L. Nelson
11/16/04

2. 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”,
"Maintenance-Free Global Data Storage”,
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?

3. 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

4. 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

5. 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

6. Distributed Hashing Projects
see for more links
CAN
Chord
Kademlia
Pastry
Tapestry
Viceroy

7. 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)

8. 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)

9. 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…

10. 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)

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

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

13. 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

14. 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

15. 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…

16. 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

17. 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…

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

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

20. Tapestry Insertion
slides from Ben Zhao, UCB

21. UUIDs / GUIDs UUIDs and GUIDs, Internet Draft, Leach
according to Jim Whitehead, the proposed RFC overlapped with an ISO standard, and the IETF did not want to duplicate effort
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

22. 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…