Designing a DHT for low latency and high through TDT2 – Avanserte distribuerte systemer Øystein Ellingbø

Oversikt Teknisk bakgrunn  Chord, DHash++, Vivaldi Lav latency  Iterativ og rekursiv lookup, proximity neighbor selection, koding og replisering, integrasjon Høy throughput  TCP, STP Oppsummering

Chord Lookup protokol Alle noder har en finger- og etterfølgertabell O(logN) kjøretid

DHash++ Bruker SHA-1 hash funksjon Lagrer blokker (nøkkel/verdi) på forskjellige noder IDA koding Bruker Chord til å bestemme server Flytter blokker etter som noder kommer og går

Vivaldi System for å beregne syntetiske koordinater for å gjette latens mellom nodene Desentralisert system Piggy-backer på Chord og DHash++ meldinger

Lav latency - Iterativ lookup Sender melding til og får svar fra alle involverte noder Må vente på svar Detekterer nodefeil

Lav latency - Rekursiv lookup Forespørselen videresendes direkte Reduserer antall meldinger Detekterer ikke nodefeil

Lav latency - Iterativ vs rekursiv Rekursivt i gjennomsnitt 0.6 ganger iterativt DHash++ bruker rekursivt, men faller til bake på iterativt ved gjentatt feil

Lav latency - Proximity neighbor selection Velger nærliggende noder som innslag i fingertabellen for å redusere latens Sjekker X noder Velger node med lavest latency DHash++ bruker X=16

Lav latency - Koding og replisering Koding  Datablokker splittes i l fragmenter.  Bare m fragmenter trengs for å rekonstruere en blokk  Redundant lagring av data Replisering  Spesialtilfelle av koding: m = 1, l = antall replikater  Redundant informasjon spredd over færre noder Grad av redundans: r = l/m Sannsynlighet for at blokk p er tilgjengelig:

Lav latency - Koding og replisering Høy r gir større valgmulighet i hvor data hentes fra, men øker nettverksbehovet ved skriving Hva som lønner seg kommer an på belastningen på systemet:  Lese-intensivt vil ha lavere latency med replisering  Skrive-intensivt vil bruke mindre båndbredde med koding DHash++ bruker koding, med m=7 og l=14

Lav latency - Integrasjon De siste hoppen for å finne en nøkkels forgjenger er dyre. Men for å hente en blokk trenger vi bare m av l fragmenter! Lookup kan altså avsluttes så fort vi har en node som har m av nodene med fragmenter i sin etterfølgerliste Dette gir dessverre færre fragmenter å velge i, som øker latency ved henting

Lav latency - Integrasjon Antall etterfølgere man minimum ønsker: d (d >= m) Lav d : Raskere lookup men høyere latency ved henting Høy d : Tregere lookup men lavere latency ved hetning Optimalt: d = l

Høy throughput Ønsker  Rask sending og mottak av store mengder data  Parallell sending og mottak av data  Overflytskontroll  Detektering og retransmisjon ved pakketap

Høy throughput - TCP Standard protokoll – slipper å implementere selv Tar seg av overflyt, retransmisjon osv Tar tid å koble opp -> Noen få langlivete oppkoblinger (til alle i finger- og etterfølgertabellen) Krever rekursiv lookup OG henting av data Rekursiv henting medfører høyere latency

Høy throughput – Striped Transport Protocol (STP) Spesialisert protokol for DHT Data kan sendes direkte mellom noder (ikke rekursiv henting) Vindustørrelsen økes ved vellykkede RPC og minkes ved time-out Bruker Vivaldi (noe modifisert) for å bestemme time- out Ved time-out sender man til neste node på listen i stedet

Høy throughput – TCP vs STP Figur til venstre, throughput:  STP: Gjennomsnittlig 261 KB/s  TCP: Gjennomsnittlig 133 KB/s Figur til høyre, latency ved henting:  STP: Gjennomsnittlig 192 ms  TCP: Gjennomsnittlig 447 ms

Oppsummering Latency:  Rekursiv lookup -> Reduserer antall sendte pakker  Proximity neighbor selection -> Søker nærliggende noder  Koding -> Øker tilgjengeligheten av data  Integrasjon -> Reduserer antall hopp ved lookup  TOTALT: Reduksjon med en faktor opp mot 2 Throughput  STP -> Tilpasset DHash++. Direkte oppkobling mellom noder  TOTALT: Ytterligere reduksjon av latency i tillegg til at throughput økes med en faktor opp mot 2