1. Efficient Peer-to-Peer Lookup Based on a Distributed Trie 2. Complex Queries in DHT-based Peer-to-Peer Networks Lintao Liu 5/21/2002

Existing Lookup Algorithm Broadcase-like search –Gnutella, FreeNet DHT(Distributed Hash Table) –CAN, Chord, Pastry, Tapestry Comparison –Maintenance cost –Efficiency, scalability?

Why introduce Distributed Trie? Each peer holds partitions of the key space according to some assignment policy Relaxing the consistency criteria of partition assignment can reduce the maintenance costs –Stale replicas? –Piggyback the updates –Reconcile conflicting updates

System Model Interfaces –Lookup(key), Insert(key, value), join(); Trie Structure –Internal trie nodes consist of 2 m routing table –Each table consists of l entries –Each entry: (peer address, timestamp) –Structure (refer to the figure in the paper)

Trie lookup structure Leaf node: –the entry in its routing table indicates the peer address holding a value. Intermediate node: –The entry at its ith routing table indicates that the peer a held a replica of the ith child of the node. Ancestor invariant: the path from the root

Algorithm Join –Introducer, join request, bootstrap –Node ID?? How to construct routing table??? Insertion –Performed locally by inserting the key/value pair –????? Lookup –Try local data, –Go deeper on the trie –Backtrack

Different Mode Used for updating trie state –When to do that? While query a key or periodically? Bounded mode –Only return the routing table which is more specific than the current routing table on the caller Unbounded mode –Return the most specific routing table for the key –Looks like they do this while querying a key Full path mode –Return the full path(include the routing table) from the root table to the most specific routing table for the key

Security Issues How much do we believe the routing table from other nodes? Conservative mode –example Liberal mode –Just believe all updates without doubt

Complex queries in DHT-based P2P Networks Motivation –Two problems: scalability, Query languages –DHT (Distributed Hash Table) Chord, Pastry, Tapestry, CAN Improve scalability and “exact match” efficiency Cannot do complex queries

Text Retrieval and Hash Indexes In order to handle “fuzzy” matches –Split each string to be indexed into n-grams –For each such n-grams g i, the pair (g i, I)is inserted into the hash index, keyed by g i Lookup –Split the string into n-grams, and lookup each n-grams in the index –Return those files for which the count of copies is as much as the number of n-grams in the query. Too many I for some popular g i ?

More argues This is not P2P database –A lot of reasons to explain this is not DB even through a lot of DB technique is used here.

Implementation Architecture Three layers –Data Store (Iterator, Accessors to attributes…) –DHT Layer(handle network routing) Put/get, Iterator, Callback newData –Query processing layer (handle parallel queries) Namespace & Multicast –Organize the flat key space into a hierarchical space –Multicast queries to all peers in one group

More Issues Related to DB technique, General Idea is to make parallel queries (not sure) Cannot understand very well. Discussion……