Unstructured P2P Networks

1. Unstructured P2P Networks

2. m=16 k=3 h1 h2 h3 b 0 0 0 0 0 0 0 0 a c True positive: bS S={a,b,c} 1 1 False positive: f S 0 1 0 1 0 0 1 0 0 1 1 0 1 0 True negative: gS f b g Bloom Filters • Data structure for representing sets • Allows set membership test • Parameters: m, {h1, h2, …hk} Membership test • Keyword Search • The Lord of the Rings the Two Towers  S={the, lord, of, rings, two, towers} • Service Discovery • S={ServiceType=LightPathObj, Source=UWaterloo, Destination=UToronto, … }

3. unstructured structured high query traffic low query traffic P2P search no storage high storage Un-informed Local info. Global info. Proactive DHT-based Flooding & variants Super-peers Skipnet Walking & variants Local index Others… NSS Reactive Intelligent BFS Symantec search Others … Search in P2P

4. 1 X.mp3 2 3 4 5 7 9 6 8 10 Gnutella: Constrained Flooding • Every peer forwards packets to ALL of its neighboring peers (typically 4). • Lifetime of packets are limited by time-to-live (typically set to 7). • Packets has unique id to detect loops. Example: Node 1 searches for document X.mp3. Node 4 has X.mp3.

5. Gnutella Flooding • Simple • Robust • Network traffic is overwhelming • Example: • C (average degree per peer) = 4 • TTL = 7 1 search request can cause = 4,372 packets.

6. Example: Node 1 searches for document X.mp3. Node 4 has X.mp3. 1 X.mp3 2 3 4 5 7 9 6 8 10 Random Walk • A peer forwards a packet to ONE randomly selected neighboring peer.

7. Random Walk • Simple • Robust • Lookup latency is high • Network traffic is still high to secure success

8. Basic Techniques • Flooding • Forward incoming search msg. to all neighbors • Termination : TTL restriction • High bandwidth + Moderate success rate • Good for highly dynamic networks/low join overhead • Walking • Forward incoming search msg. to only one neighbor • k simultaneous walkers are used. • Termination : • (a) success (b) TTL reached (c) explicitly by initiator • Low bandwidth + Poor success rate • Good for highly dynamic networks/low join overhead

9. Flooding Variants - Blind • Modified BFS • Forward msg. to a ratio of randomly chosen neighbors • Still not scalable • Reduced success rate. • Iterative deepening • Expanding ring search • Good for highly replicated/popular contents • Network overhead can be higher than flooding if ring size increases.

10. Flooding Variants - Informed • Intelligent BFS • Informed version of modified-BFS • Store <query, neighborID> for recent queries • Forward to a set no. of neighbors that returned most relevant results in pervious queries. • No extra overhead during join operation • Local indices (LI) • Index document in nodes within radius r • BFS like search with jumps of 2r+1 hops at each step. • Flooding with TTL=r is required during the join operation • High index storage overhead • Neighbor signature search (NSS) • Similar to LI but Bloom filters are used as index to reduce index storage.

11. 1 INFOCOMM HPSR 2 3 Neighborhood radius = 2 4 5 7 9 8 6 10 b ICON DSOM SIGCOMM ICON Local index • Each peer maintains index for data items stored at peers within its neighborhood. • Example: Neighborhood radius = 2 Node ‘a’ is looking for ICON Peer 1 maintains index for data stored at peer 2, 3, 4 and 8. a

12. Local index • Reduce search traffic compared to Flooding /Random Walk. • Incur high index maintenance cost during peer join/leave/update. • Has high storage requirement. • Constrain searches based on predetermined index attributes.

13. NSS: Data Signature • Construct a signature file • Hash attributes (keywords) of a data record (file) to bit strings • Superimpose (bit-wise OR) the bit strings of all attributes • Superimpose data signatures (bit strings) from several data records • Search using signature files • Generate a search signature • Compare search signature with data signatures • No match • True match • False positive

14. NSS: Data Signature : Example • MP3 File: Title: HeartbreakHotel Artist: ElvisPresley Hearbreak 001 000 110 010 Hotel 000 010 101 001 Elvis 000 100 010 110 Presley 101 000 100 001 Eagles 000 101 001 100 No Match Elvis 000 100 010 110 True Match Beatles 100 100 010 100 False Positive Data Signature  (bitwise-OR) 101 110 111 111 Search Search Signature Results

15. NSS: Data Signature : Features • Has much lower storage requirement than local index. • Data signatures can adapt to available storage • On the contrary, Local Index • Has minimum storage requirement. • The storage requirement changes discretely according to neighborhood radius. • Place no constrains on the search predicates. • Has false positive.

16. NSS: Neighborhood Signatures • Each peer maintains • A local signature • One or several neighborhood signatures • 3 methods for computing neighborhood signature: • CN : Complete Neighborhood signatures • PN-S : Partial Neighborhood-Superimposing signatures • PN-A : Partial Neighborhood-Appending signatures

17. 1 2 3 4 5 7 9 8 6 10 PN-A3 V V V || || CN PN-S2 PN-S3 PN-A2 V: Superimpose ||: append Neighborhood Signatures: Example Neighborhood signature for node 1 Neighborhood radius = 2

18. Flooding Variants: Superpeer • Gnutella2 • Superpeers index leaf peers’ contents • In superpeer network 1 hop flooding is used • Supeerpeers forward a query message to related leaf peer only

19. Walking : variants • Adaptive Probabilistic Search (APS) • Index : <queried object, neighborID, result> • Probabilistic forwarding of query based on local index • On success walker retraces updating the indices at each node • GIA: • Each node defines its capacity • Each node connects to a number of nodes proportional to its capacity • Forwarding is biased towards higher capacity nodes

20. Walking : variants • Routing Indices (RI) • Documents are classified into thematic categories • Index: <categoryID, linkID, goodness> • linkID  all nodes accessible through this link • Backtracks in case of failure. • Document creation and update requires flooding

21. Bloom filter based techniques • Attenuated Bloom filter • Exponentially decaying Bloom filter