Foreseer: A Novel, LocalityAware Peertopeer System Architecture for Keyword Searches

1
Foreseer A Novel, Locality-Aware Peer-to-peer
System Architecture for Keyword Searches

• Hailong Cai Jun Wang
• Computer Architecture and Storage Systems (CASS)
  Lab
• Computer Science and Engineering Department
• University of Nebraska, Lincoln

Middleware 2004 Toronto, Ontario, Canada
2
Outline

• Introduction Search in P2P Systems
• Motivation Locality in P2P Systems
• Foreseer Architecture
• Foreseer Design
• Evaluation
• Summary and Discussion

3
Search in P2P Systems

• Unstructured P2P system
• Napster Centralized (poor scalability and
  reliability)
• Gnutella Decentralized
• Search in decentralized unstructured systems
• Blind flooding, random walk
• Informed -- index

4
Search in P2P Systems -- Blind
c
i
e
a
b
k
q
n
m
d
j
l
p
h
f
g
Logical topology Connected peers may be distant.
5
Search in P2P Systems -- Informed

• Building distributed indices
• hints about other peers, suggesting searching
  directions
• Examples APS, Local Indices, Routing Indices
• Problems
• Not accurate
• Indices creation and maintenance

6
How to Search Efficiently?

• How to efficiently search in unstructured,
  decentralized P2P overlays?
• 1. Informed using distributed indices
• More accurate direction
• Compact indices
• 2. Efficient exploiting locality
• Geographical locality
• Temporal locality

7
Locality in P2P Systems Geographical Locality
C

• B1, B2, and B3 exhibit geographical locality if
  they are likely to serve node A in the near
  future.
• Reason f1 is more likely to be reached by
  queries from node A than f1 is.
• More obvious if connections have physical
  proximity

B1
B2
A
B3
f1
D
E
f1
8
Locality in P2P Systems Temporal Locality

• Suppose node C served some requests from node A
  in the past

• C exhibits temporal locality if it is likely to
  offer further service to node A in the near future

A

• Reason Peoples interest does not vary too often

• Node C may be faraway from node A

C
9
Foreseer Architecture Ideas

• Rationale Social relationship in real life
• Ones social relations neighbors and friends
• People use business cards for contacts
• Upon a new request, one lookup up the business
  cards of his neighbors and Friends
• If a neighbor or friend can help, fine
• Otherwise, pass the request to his friends /
  neighbors who, in turn, will seek help from their
  own neighbors and friends

10
Foreseer Architecture
An efficient search mechanism
Distributed indices as business cards Using
Bloom filters
Two orthogonal overlays -- N and F Capturing
localities
Built on top of Internet
11
Foreseer Design Overlays
c
e
i
a
bidirectional
b
k
q
n
m
unidirectional
d
l
p
h
f
g

• Find neighbors with physical proximity (network
  latency)

• Make and refresh friends according to transactions

12
Foreseer Design Distributed Indices

• Each peer maintains
• Its own content filter
• Content filter copies of its neighbors
• Content filter copies of its friends
• Since friend links are unidirectional, a peer
  also need to know where its content filters are
  distributed for indices update back friends
• If a ? F(b), then b ? BF(a)

13
Foreseer Design Search Algorithm

• Each peer p runs a 2-phase search algorithm
• 1. Local matching
• Computes query filter
• Compare it with content filter of each peer q ?
  N(p)UF(p)
• 2. Selective dispatching
• Matched in 1, forward to node q
• Otherwise, forward to its friends / neighbors

14
Foreseer Design Search Policies

• Depending on which overlay to travel and how far
  before switching to the other

• 1. Friend links first

Follow friend links for up to h1 hops and then
follow neighbor links for up to h2 hops (default
policy)

• 2. Neighbor links first

• 3. Both links simultaneously

• Other policies are possible

15
Foreseer Design Searching Example

• Policy used

• Only show paths from a to i to is friends

c
e
i
a
b
k
q
n
m
d
l
p
h
f
g
16
Evaluation Experiment Setup

• Trace driven simulation
• Physical network topology Transit-Stub
• Simulated 50,000 physical nodes, from which peers
  randomly selected
• We rebuild a downloading trace from eDonkey trace
  obtained by Fessant (IPTPS04)
• Default search policy P1 with h15, h21

17
Results Baseline Systems

• Blind search Gnutella
• Informed search
• Local Indices with r1 (LI-1) and r2 (LI-2) (B.
  Yang, ICDCS02)
• Other schemes using interest based locality
• Interest Based Shortcuts (IBS), at most 10
  shortcuts on each peer (K. Sripanidkulchai,
  INFOCOM03)

18
Results Neighbors and Friends in Searching
When h0, a lot of queries are resolved locally
(34). No query messages needed for these requests
19
Results Neighbors and Friends in Searching

• For each hop number, friends serve more queries
  than neighbors
• Friends more likely to serve future requests
• Peers maintain more friends than neighbors
• Traveling in neighbor overlay is useful
• Increases success rate by reaching isolated peers
• Proximity helps to reduce search cost

20
Results Search Performance
Average relative distance follows a similar trend
21
Results Search Cost

• Foreseer reduces messages in a search by more
  than 90

22
Results Search Cost

• Foreseer also reduces nodes touched in a search
  by more than 90

23
Summary and Future Work

• Exploit two dimensional localities
• Use Bloom filters to build distributed indices
• Develop efficient lookup algorithm
• Foreseer boosts search performance and slashes
  search cost
• Can be easily deployed
• Will further study the search policies

24
Questions ?
Thank you !
hcai_at_cse.unl.edu http//www.cse.unl.edu/hcai