1 / 5

Motivation: Why Unstructured?

Motivation: Why Unstructured?. Not all searches for user-IDs search by last name, first name Find a relay for media session by AS number, locality etc (DHT sol: ReDiR – effectively a kludge) Key word searches (DHT sol: inverted index – does not scale)

akando
Download Presentation

Motivation: Why Unstructured?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Motivation: Why Unstructured? • Not all searches for user-IDs • search by last name, first name • Find a relay for media session • by AS number, locality etc (DHT sol: ReDiR – effectively a kludge) • Key word searches (DHT sol: inverted index – does not scale) • Range searches (DHT sol: prefix hash trees – scalable?) • Find all podcasts in New York, in my neighborhood • Random walks have been implemented on top of DHTs (useful to find overlays) • Debunking some myths about structured and unstructured overlayshttp://research.microsoft.com/~antr/MS/myths.pdf • Cannot dispense all research in unstructured systems

  2. Unstructured P2P Networks • Differences from DHTs • Resource-ID • Limited flooding (parallel requests – typically iterative) • Explicit load balancing • need information about other nodes link capacity, machine characteristics • Routing • cannot route based on peer-IDs • Common mechanisms between DHT and unstructured overlays • Connection management • Loop detection • Security • NAT traversal • Bootstrap

  3. Unstructured and RELOAD • Routing mechanisms • symmetric routing • works in unstructured • copies of same request can arrive at an intermediate node (flooding) • disambiguate using Via list? • iterative routing • need more than one peer in response • the next hop information should contain machine / link characteristics • client routing – see next slide

  4. Chord peer-id=x SIP=sipX peer-id=y SIP=sipy • STORE • H(sipY) and destination list X-Y on • FETCH • DHT 1) FETCH( H(sipY) ) 2) FETCH( X ) • unstructured? client peer-id=z

  5. Unstructured and RELOAD • Explicit load balancing • Peers need information about the ‘capacity’ of other peers and ‘size’ of the resources they are storing before issuing a STORE request • capacity: link capacity, memory, CPU utilization, user activity • Do not have to define a priori. Ensure that encoding is flexible enough to support it for a particular unstructured overlay. • Ability to define nested objects

More Related