Peer-to-Peer (P2P) hálózatok BMEVITT9176 Választható tárgy 2006 március 2

P2P hálózatok 2 CAN Sylvia Ratnasamy, Paul Francis, Mark Handley, Richard Karp, Scott Shenker, “A Scalable Content-Addressable Network”, Proceedings of the ACM SIGCOMM'01 Conference, San Diego, CA (August 2001).  Sylvia Ratnasamy, „A Scalable Content-Addressable Network”, Ph.D. Thesis, October 2002 

2006 március 2P2P hálózatok 3 CAN Optimalizálás Optimalizációs lehetőségek  Rövidebb utak: kevesebb ugrás a forrás és a cél között  Rövidebb ugrások: két szomszéd közötti ugrás a fizikai topológián  Optimalizált zónafelosztás

2006 március 2P2P hálózatok 4 CAN valóságok CAN valóságok (Reality): többszörös koordináta rendszerek Minden csomópont több koordináta rendszer (valóság) része Egy csomópontnak különböző zónai vannak a különböző valóságokban A zónák kiosztásakor a P pontot véletlenszerűen valasztjuk A hash tábla tartalma minden valóságban elérhető – nagyobb rendelkezésre állás Minden valóságban...  Egyenlő a zónák száma  Ugyanazok a tárolt adatok  Ugyanaz a hash függvény

2006 március 2P2P hálózatok 5 Útválasztás a valóságokban b. Az üzenetet a legjobb valóságban küldi tovább a. Minden csomópont az útvonalon ellenőrzi, hogy melyik valóságban a legkisebb a távolsága a célhoz 1.A cél minden valóságban ugyanabba a H pontba hash-elődik Minden valóságban más-más csomópont zónájába tartozhat a H pont 2. A hagyományos útválasztás a következő módon egészítjük ki:

2006 március 2P2P hálózatok 6 Útválasztás a valóságokban b. Az üzenetet a legjobb valóságban küldi tovább a. Minden csomópont az útvonalon ellenőrzi, hogy melyik valóságban a legkisebb a távolsága a célhoz 1.A cél minden valóságban ugyanabba a H pontba hash-elődik Minden valóságban más-más csomópont zónájába tartozhat a H pont 2. A hagyományos útválasztás a következő módon egészítjük ki:

2006 március 2P2P hálózatok 7 Többdimenziós koordináta rendszer A routing hatákonysága függ a koordináták számától Az útvonal átlagos hossza: Ha a dimenziók száma ( d ) nő, az út hossza csökken n = 1000, egyenlő zónák DÚt átlagos hossza

2006 március 2P2P hálózatok 8 Több valóság vagy több dimenzió? A dimenziók növelése hatékonyabb az útvonal optimalizálásában mint a valóságok növelése  A valóságok nagyobb hibatűrést és rendelkezésre állást biztosítanak

2006 március 2P2P hálózatok 9 Zónák túlterhelése (overloading) Egy zóna – több csomópont A csomópontok melyek ugyanazért a zónáért felelnek: peer-ek MAXPEERS – maximum hány csomópont felelhet egy zónáért Minden csomópont ismeri a peer-jeit A szomszédok száma ugyanannyi A hagyományos routing algoritmust használjuk

2006 március 2P2P hálózatok 10 Új csomópont csatlakozása Egy új csomópont (A) csatlakozni: 1. Felfedez egy zónát (melyért B felel) 2. B ellenőrzi hány peer-je van: 3. Ha kevesebb mint MAXPEERS 1.A csatlakozik mint a B új peer-je 2.B elküldi A-nak a peer-ek és szomszédok listáját 4. Másképp 1. B zónája ketté osztódik 2. A peer-ek listája is ketté osztódik 3. A peer-ek és a szomszédok listáját frissíteni kell

2006 március 2P2P hálózatok 11 Új csomópont csatlakozása Egy új csomópont (A) csatlakozni: 1. Felfedez egy zónát (melyért B felel) 2. B ellenőrzi hány peer-je van: 3. Ha kevesebb mint MAXPEERS 1.A csatlakozik mint a B új peer-je 2.B elküldi A-nak a peer-ek és szomszédok listáját 4. Másképp 1. B zónája ketté osztódik 2. A peer-ek listája is ketté osztódik 3. A peer-ek és a szomszédok listáját frissíteni kell

2006 március 2P2P hálózatok 12 Új csomópont csatlakozása Egy új csomópont (A) csatlakozni: 1. Felfedez egy zónát (melyért B felel) 2. B ellenőrzi hány peer-je van: 3. Ha kevesebb mint MAXPEERS 1.A csatlakozik mint a B új peer-je 2.B elküldi A-nak a peer-ek és szomszédok listáját 4. Másképp 1. B zónája ketté osztódik 2. A peer-ek listája is ketté osztódik 3. A peer-ek és a szomszédok listáját frissíteni kell

2006 március 2P2P hálózatok 13 Új csomópont csatlakozása Egy új csomópont (A) csatlakozni: 1. Felfedez egy zónát (melyért B felel) 2. B ellenőrzi hány peer-je van: 3. Ha kevesebb mint MAXPEERS 1.A csatlakozik mint a B új peer-je 2.B elküldi A-nak a peer-ek és szomszédok listáját 4. Másképp 1.B zónája ketté osztódik 2.A peer-ek listája is ketté osztódik 3.A peer-ek és a szomszédok listáját frissíteni kell

2006 március 2P2P hálózatok 14 Valóságok és túlterhelés Létrehoztunk egy valóságot

2006 március 2P2P hálózatok 15 Valóságok és túlterhelés Ehhez a valósághoz túlterheléssel peereket rendelünk hozzá

2006 március 2P2P hálózatok 16 Valóságok és túlterhelés Létrehoztunk egy második valóságot

2006 március 2P2P hálózatok 17 Valóságok és túlterhelés A második valósághoz egy más elosztásban rendeljük hozzá a csomópontokat

2006 március 2P2P hálózatok 18 Optimalizálás a fizikai topológián Periódikus önfrissítés 1.Szabályos időközönként egy csomópont megkapja a szomszédai peer-jeinek listáját 2. Megméri minden peer felé az RTT-t 3. A fizikailag legközelebb álló peer-t választja szomszédjénak abban az irányban Előnyök Rövidebb utak (kevesebb zóna) Rövidebb ugrások (periódikus önfrissítés) Nagyobb hibatűrés és rendelkezésre állás (több peer tárol egy adatot)

2006 március 2P2P hálózatok 19 Egyenletes felosztás 1.A csomópont melyre a zónafelosztás esett osszehasonlítja a zónája méretét a szomszédai zónáinek méretével 2.A legnagyobb zónát osztjuk fel

Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, Hari Balakrishnan - MIT

2006 március 2P2P hálózatok 21 Hogyan találjuk meg az adatot egy elosztott fájlmegosztó rendszerben? Hatékony keresés a fő probléma! Internet Publisher Key=“LetItBe” Value=MP3 data Lookup(“LetItBe”) N1N1 N2N2 N3N3 N5N5 N4N4 Client ? Motiváció

2006 március 2P2P hálózatok 22 Követelmények: O(M) állapot M a megosztott állományok száma Központi elem kiesése megbénítja a rendszert Internet Publisher Key=“LetItBe” Value=MP3 data Lookup(“LetItBe”) N1N1 N2N2 N3N3 N5N5 N4N4 Client DB Központi szerver (pl.: Napster) Központosított megoldás

2006 március 2P2P hálózatok 23 Legrosszabb esetben O(N) üzenet / keresés N a csomópontok száma Internet Publisher Key=“LetItBe” Value=MP3 data Lookup(“LetItBe”) N1N1 N2N2 N3N3 N5N5 N4N4 Client Elárasztás (pl.: Gnutella, Morpheus) Elosztott megoldások - I

2006 március 2P2P hálózatok 24 Internet Publisher Key=“LetItBe” Value=MP3 data Lookup(“LetItBe”) N1N1 N2N2 N3N3 N5N5 N4N4 Client Kizárólag teljes egyezés Elosztott megoldások - II Irányított (Routed) üzenetek (Freenet, Tapestry, Chord, CAN, stb…)

2006 március 2P2P hálózatok 25 Keresés kihívásai Kevés ugrás Mérsékelt méretű útválasztó tábla  mérsékelt == „pont megfelelő” Robusztus működés  gyorsan változó résztvevők

2006 március 2P2P hálózatok 26 Chord jellegzetességei Hatékony: O(Log N) üzenet keresésenként  ahol N a kiszolgálók (csomópontok) száma Skálázódik: O(Log N) állapot csomópontonként Robosztus: megbirkózik jelentős résztvevő változással Állítások bizonyításai [tech_report]  Feltételezés: nincs rosszakaratú résztvevő

2006 március 2P2P hálózatok 27 Chord Azonosítók (IDs) m bites azonosító tér a kulcsoknak és a csomópontoknak  m tetszőleges szám, elég nagy, hogy az ütközés valószínűsége kicsi legyen  SHA-1 (Secure Hash Standard) Kulcs azonosító = SHA-1(key)  KEY=“LetItBe” ! SHA-1 ID=60 Csomópont azonosító = SHA-1(IP address)  IP=“ ” ! SHA-1 ID=123 Egyenletes eloszlással Hogyan lehet a kulcs azonosítókat a csomópont azonosítókhoz rendelni?

2006 március 2P2P hálózatok 28 Chord Gyűrű Azonosítók egy azonosító gyűrű mentén elhelyezve modulo 2 m  Chord ring  Példa: m = 6 Minden K kulcs az őt követő legközelebbi N csomópontnál kerül tárolásra  N = successor(k)

2006 március 2P2P hálózatok 29 Consistent hashing D. Karger, E. Lehman, T. Leighton, M. Levine, D. Lewin, R. Panigrahy, „Consistent hashing and random trees: distributed caching protocols for relieving hot spots on the World Wide Web”, Proceedings of ACM Symposium on Theory of Computing, El Paso, Texas, Tim-Berners Lee és T. Leighton eredeti ötlete Akamai  MIT spin-off cég  Elosztott cache-rendszer az Interneten  szerver, 1100 hálózat, 69 ország  15% az Internet forgalomnak rajtuk megy keresztül

2006 március 2P2P hálózatok 30 N21 N42 N56 0 Hash(“LetItBe”) = K38 N8N8 N32 Hol van a “LetItBe”? “N42 tárolja a K38-at” K38 Consistent hashing Minden csomópont ismeri az összes többi csomópontot  globális információ tárolási kényszer  üzenet továbbítási táblák nagyok O(N) Gyors keresés O(1)

2006 március 2P2P hálózatok 31 Chord: alap keresés Minden csomópont ismeri az őt követőt a gyűrűn  Az öt megelőzőt is hasznos ismernie Keresési idő ~ üzenetek száma: O(N)

2006 március 2P2P hálózatok 32 Minden egyes csomópont m számú további csomópontot tart nyilván Az előre mutató távolság exponenciálisan növekszik finger[i] = successor (n + 2 ) „Mutató táblák” (Finger tables) i-1

2006 március 2P2P hálózatok 33 A mutató táblák segítségével a keresésnek O(log N) csomópontot kell bejárnia Chord: gyors/skálázódó keresés

2006 március 2P2P hálózatok 34 A mutató táblák segítségével a keresésnek O(log N) csomópontot kell bejárnia Chord: gyors/skálázódó keresés

2006 március 2P2P hálózatok 35 Chord: gyors/skálázódó keresés Minden csomópont m további bejegyzést tartalmaz Minél közelebbi a kulcs annál részletesebb információval rendelkezik róla a csomópont Általában nem biztosítja az azonnali célba jutást

2006 március 2P2P hálózatok 36 Új érkezők Három lépésben (alap működés)  Újonnan érkező mutató táblájának feltöltése  Gyűrű csomópontok mutató táblájának frissítése  Kulcsok cseréje „Lusta” vagy kevésbé agresszív működés  Csak a követő csomópont beállítása  Periodikus követő successor, megelőző predecessor ellenőrzés  Periodikus mutató tábla frissítés

2006 március 2P2P hálózatok 37 N14 1. Lookup(15,16,18,…,78) N32 N21 N2N2 N8N8 N56 N42 Új érkező: mutató táblák Kiindulás: bármely p ismert csomópontból  Kérjük meg p-t, hogy építse fel a mutató táblánkat  Táblázat visszaadása

2006 március 2P2P hálózatok 38 Új érkező A gyűrű csomópontok mutató tábláinak frissítése  új érkező a frissítés funkciót kelti életre a szomszédos csomópontokban  csomópontok rekurzívan frissíttetik a további csomópontok mutató tábláit

2006 március 2P2P hálózatok 39 Új érkező N26 belép a rendszerbe N26.successor = N32 N26 értesíti N32-t N32.predecessor = N26

2006 március 2P2P hálózatok 40 Új érkező N26 átmásolja a ráeső kulcsokat N21.frissítés: lekéri N32-től a predecessor-t, aki N26

2006 március 2P2P hálózatok 41 Új érkező N21.successor = N26 N21 értesíti N26-ot a létezéséről N26.predecessor = N21

2006 március 2P2P hálózatok 42 Új érkezők: keresés Korrekt mutató táblák esetén O(log N) Ha csak a követő lánc helyes, akkor is korrekt, de lassabb működés

2006 március 2P2P hálózatok 43 Csomópontok kiesése (hiba) helytelen keresést eredményezhet Mi van ha az N14, N21 és N32 egyszerre meghibásodik? Hogyan tud az N8 tudomást szerezni az N38-ról? Hibák kezelése

2006 március 2P2P hálózatok 44 Csomópontok kiesése (hiba) helytelen keresést eredményezhet Mi van ha az N14, N21 és N32 egyszerre meghibásodik? Hogyan tud az N8 tudomást szerezni az N38-ról? Hibák kezelése

2006 március 2P2P hálózatok 45 Hibák kezelése (II) Követő lista  Az egyetlen követő helyett r soron követő csomópont regisztrációja  Hiba esetén ismeri a soron következő (élő) csomópontot helyes keresés Valószínűségi garancia  r megválasztása, hogy a keresési hiba valószínűsége megfelelően alacsony legyen r ~ O(log N)

2006 március 2P2P hálózatok 46 Teljesítmény elemzés Gyors keresés nagy rendszerekben Alacsony szórással a keresési időben Robosztus, még gyakori csomóponti hibák esetén is

2006 március 2P2P hálózatok 47 Chord implementáció 3000 soros C++ kód Library amely tetszőleges alkalmazáshoz linkelhető Kis Internet teszthálón kipóbálva Funkciók:  lookup(key): azon csomópont IP címe amely a kulcsért felelős  kulcs-felelősség változások terjesztése

2006 március 2P2P hálózatok 48 Alkalmazás: Chord-DNS DNS keresési szolgálat  host name  IP cím Chord-based DNS:  nincsenek root serverek  nincs manuális routing information menedzsment  nincs naming structure

2006 március 2P2P hálózatok 49 Irodalom I. Stoica, R. Morris, D. Karger, F. Kaashoek, H. Balakrishnan, "Chord: A Scalable Peer-To-Peer Lookup Service for Internet Applications," AC Sigcomm2001, The Chord Project

2006 március 2P2P hálózatok 50