Looking up data In P2P systems

Innhold Søkeproblemet Distribuerte Hash Tabeller Noen eksempel systemer: CAN Pastry Tapestry Chord (som vil bli sett nærmere på) Liten oppsummering

Søkeproblemet (the Lookup Problem) Hvordan finner man ting i P2P-nett? Sentralisert enhet Tar mot og videreformidler forespørsler Flaskehals, dårlig skalerbarhet Eks: Napster

Søkeproblemet Hierarkisk Forespørselen blir sendt ned en trestruktur til den når riktig mål Bedre, men lasten er fremdeles ujevnt fordelt Eks: DNS, FastTrack based (KaZaA, Gokster)

Søkeproblemet Flooding En node spør naboene sine som igjen spør sine naboer Generere alt for mye nettverks trafikk Eks: Gnutella

Søkeproblemet Altså: Prøve å fordele lasten over ALLE nodene UTEN å produsere en uhordelig nettrafikk Så kanskje: Gi hver node mulighet til å sende forespørselen videre i ”riktig retning”

DHT (Distributed Hash Tables) Omtrent som vanlig Hashing Konverter identifier til en nøkkel Med for eksempel SHA-1 Bruk denne nøkkelen til å bestemme hvilken node (bøtte) filen/filinfoen skal plasseres på Og tilsvarende kan en bruke nøkkelen til å finne på hvilken node filen ligger

DHT Last balanse Det er viktig at hashe-funksjonen bruker hele spekteret tilgjengelig til den (i.e. last balansert) Filen blir så plassert på den noden som har id som er nærmest match til nøkkelen På denne måten vil filene bli spredt gjevnest mulig over alle nodene

DHT Den distribuerte delen Hver node må ha muligheten til å sende forespørsler for en nøkkel videre til en node som er ”nærmere” denne nøkkelen enn seg selv Eks: En node som har høyere id enn seg selv, men som er lavere enn nøkkelen søkt etter Eks: En node som har flere siffer til felles med nøkkelen (i.e. binære nøkler/id’er)

DHT Hver node må derfor vite Om sin etterfølgende node (numerisk stigende) Eller om noder som har mange siffer i id’en til felles De følgende 4 metodene er forbedringer på dette slik at man raskere finner frem til riktig node

CAN CAN deler nøkkelrommet inni et n- dimensjonalt kartetisk rom Hvert siffer i nøkkelen tilsvarer en dimensjon Rommet blir delt in i hyper-rektangulære soner Hver node for ansvar for hver sin sone

CAN Her er et eksempel i 2d rom: Hvis 2 soner har en side til felles, så vet nodene om hverandre Node joins/parts håndteres med sone splitting/merging Eks: routing:

Pastry Har peker til de n nærmeste nodene som er større enn seg Har også peker til de n nærmeste som er mindre enn seg Dette er ’Leaf set’et I Tillegg har den pekere til noder lenger borte ->

Pastry Essensen: Om man deler id-rommet i et tre, så har hver node peker til en node som er på en annen gren enn den den selv er på

Tapestry Basere seg på å sende spørringen videre til noder som har et siffer i id’en riktigere enn seg selv Så node 351 vil for eksempel vite om node 242 og 464, 343 og 366, 352 og 350 At denne noden vet om 242 og ikke 299 er basert på underliggende nettverkskostnader

Chord ID rommet er formet i en sirkel, dvs. id 0 følger den høyeste mulige id’en En nøkkel tilhører den første noden med id høyere enn seg selv (etterfølgernoden) Hver node har peker til sine m etterfølgere I tillegg den som er en halv sirkel foran seg, en kvart, en åttendel osv.

Chord Disse pekerne fremover kalles fingrer Det er nærmeste etterfølgernode som blir gjeldende

Chord Chord kan da gjøre søk i log(n) tid, ved å følge fingertabellen til den treffer riktig node, eller en node med riktig node i etterfølgerlisten Det å ha m etterfølgere hindrer sirkelen å bryte sammen om en node detter ut

Chord Joins n2 joiner mellom n1 og n3 ved å si til n3 at den joiner Chord-nettet n3 oppdatere forløpernoden sin fra n1 til n2 n1 spør gjevnlig etterfølgeren (n3) sin om forløperen dens Dette er nå n2 og ikke n1, n1 oppdatere derfor etterfølgeren sin til å være n2 i stedet for n3

Chord Joins Nodene oppdatere også gjevnlig sine fingernoder n2 vil da etter hvert få en komplett fingerliste Man kan bruke lookups til let å populere fingerlisten

Chord Ufrivillig frafall m etterfølgernoder Når en etterfølgernode faller ut, byttes den ut med neste i etterfølgerlisten De passive kallene som fikser fingerlistene og spør etter forløpernoden vil til slutt stabilisere Chord nettet (ikke at det noen gang kommer til å nå en stabil tilstand i realistiske omgivelser)

Chord Frivillig frafall I grunn dekket av ufrivillig frafall Om noden sender sine nøkler til etter sin etterfølger først, sparer dette mye bry Også om den informerer resten av verden om dens frafall, så de slepper å finne det ut gjennom timeouts De at etterfølgernoden kan holde på forølgeren sine nøkler kan brukes som replisering

Liten Oppsummering Over er kostnadene i de forskjellige systemene -d er antall dimensjoner i navnerommet i CAN -N er antall noder i nettet