Peer-to-Peer (P2P) hálózatok 2005 október 5. P2P hálózatok 2 Caching - kiegészítés Szerzői jogokat érintő rendelkezések  DMCA – Digital Millenium Copyright.

Az előadások a következő témára: "Peer-to-Peer (P2P) hálózatok 2005 október 5. P2P hálózatok 2 Caching - kiegészítés Szerzői jogokat érintő rendelkezések  DMCA – Digital Millenium Copyright."— Előadás másolata:

1 Peer-to-Peer (P2P) hálózatok 2005 október 5

2 P2P hálózatok 2 Caching - kiegészítés Szerzői jogokat érintő rendelkezések  DMCA – Digital Millenium Copyright Act (USA, 1998)  European Copyright Directive Mindkettő megengedi a cache-elést ha:  Nem változtatja meg a tartalmat  Nem tesz lehetővé egy letőltést mely nem volt lehetséges cache nélkül  Nem javítja a letöltés minőségét (pl. nem gyorsítja azt) Cachelogic megoldás...  Emulálja a mögötte lévő peer-t Ugyanolyan sebességgel tölt fel A legális P2P fájlcsere alkalmazásoknál (pl. iMP) gyorsíthat  A peer úgy is fizet, mintha saját maga töltene fel Nem veszít az ISP ha forgalomfüggő szerződése van a peer-el  Az un. „tit-for-tat” megoldásokat (Kazaa, BitTorrent) is úgy kezeli, mintha a peer töltené fel a tartalmat

3 2005 október 5P2P 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

4 2005 október 5P2P 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

5 2005 október 5P2P 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:

6 2005 október 5P2P 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:

7 2005 október 5P2P 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 215 37.5 55 104.95

8 2005 október 5P2P 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

9 2005 október 5P2P 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

10 2005 október 5P2P 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

11 2005 október 5P2P 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

12 2005 október 5P2P 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

13 2005 október 5P2P 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

14 2005 október 5P2P hálózatok 14 Valóságok és túlterhelés Létrehoztunk egy valóságot

15 2005 október 5P2P hálózatok 15 Valóságok és túlterhelés Ehhez a valósághoz túlterheléssel peereket rendelünk hozzá

16 2005 október 5P2P hálózatok 16 Valóságok és túlterhelés Létrehoztunk egy második valóságot

17 2005 október 5P2P 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

18 2005 október 5P2P 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)

19 2005 október 5P2P 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

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

21 2005 október 5P2P 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ó

22 2005 október 5P2P 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

23 2005 október 5P2P 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

24 2005 október 5P2P 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…)

25 2005 október 5P2P hálózatok 25 Keresés kihívásai Hasznos kulcs egyezőség Alacsony üzenet továbbítási szám Mérsékelt üzenet továbbítási táblázat méret  mérsékelt == „pont megfelelő” Robosztus működés  gyorsan változó résztvevők Chord:  Fókuszban: hatékonyság és egyszerűség

26 2005 október 5P2P hálózatok 26 Chord áttekintés P2P hash-alapú kereső szolgáltatás  Lookup(key)  IP address  Nem az adatokat keresi, hanem azok tárolási helyét! Kérdések:  Hogyan talál meg egy csomópontot?  Hogyan tartja fenn az üzenet továbbítási táblázatot?  Hogyan adaptálódik a résztvevők változásához?

27 2005 október 5P2P hálózatok 27 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]  http://www.pdos.lcs.mit.edu/chord/papers/chord-tn.pdf Feltételezés: nincs rosszakaratú résztvevő

28 2005 október 5P2P hálózatok 28 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=“198.10.10.1” ! SHA-1 ID=123 Egyenletes eloszlással Hogyan lehet a kulcs azonosítókat a csomópont azonosítókhoz rendelni?

29 2005 október 5P2P hálózatok 29 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)

30 2005 október 5P2P hálózatok 30 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, 1997. http://theory.lcs.mit.edu/~karger/Papers/web.ps.gz Tim-Berners Lee és T. Leighton eredeti ötlete Akamai  MIT spin-off cég  Elosztott cache-rendszer az Interneten  15.000 szerver, 1100 hálózat, 69 ország  15% az Internet forgalomnak rajtuk megy keresztül

31 2005 október 5P2P hálózatok 31 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)

32 2005 október 5P2P hálózatok 32 Chord: alap keresés Minden csomópont ismeri az őt követőt a gyűrűn Keresési idő ~ üzenetek száma: O(N)

33 2005 október 5P2P hálózatok 33 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

34 2005 október 5P2P 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

35 2005 október 5P2P hálózatok 35 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

36 2005 október 5P2P hálózatok 36 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

37 2005 október 5P2P hálózatok 37 Ú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

38 2005 október 5P2P hálózatok 38 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

39 2005 október 5P2P hálózatok 39 Ú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

40 2005 október 5P2P hálózatok 40 Új érkező N26 belép a rendszerbe N26.successor = N32 N26 értesíti N32-t N32.predecessor = N26

41 2005 október 5P2P hálózatok 41 Új érkező N26 átmásolja a ráeső kulcsokat N21.frissítés: lekéri N32-től a predecessor-t, aki N26

42 2005 október 5P2P hálózatok 42 Új érkező N21.successor = N26 N21 értesíti N26-ot a létezéséről N26.predecessor = N21

43 2005 október 5P2P hálózatok 43 Ú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

44 2005 október 5P2P 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

45 2005 október 5P2P hálózatok 45 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

46 2005 október 5P2P hálózatok 46 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)

47 2005 október 5P2P hálózatok 47 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

48 2005 október 5P2P hálózatok 48 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

49 2005 október 5P2P hálózatok 49 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

50 2005 október 5P2P hálózatok 50 Irodalom I. Stoica, R. Morris, D. Karger, F. Kaashoek, H. Balakrishnan, "Chord: A Scalable Peer-To-Peer Lookup Service for Internet Applications," AC Sigcomm2001, http://www.acm.org/sigcomm/sigcomm2001/p12.html The Chord Project http://www.pdos.lcs.mit.edu/chord/

51 Tapestry: A Resilient Global-scale Overlay for Service Deployment Ben Y. Zhao, Ling Huang, Jeremy Stribling, Sean C. Rhea, Anthony D. Joseph, and John Kubiatowicz IEEE Journal on Selected Areas in Communications, January 2004, Vol. 22, No. 1.

52 2005 október 5P2P hálózatok 52 Tapestry Egy elosztott, hibatűrő, adaptív lokalizáló és útválasztó infrastruktúra Utótag (suffix) alapú hypercube útválasztás A Plaxton algoritmus ötletére alapoz  C.G. Plaxton, R. Rajaraman and A.W. Richa, Accessing Nearby Copies of Replicated Objects in a Distributed Environment., 9th Annual ACM Symposium on Parallel Algorithms and Architectures (SPAA '97), pp 311-320, Newport, RI, USA, 1997 http://citeseer.ist.psu.edu/plaxton97accessing.html

53 2005 október 5P2P hálózatok 53 Plaxton/Tapestry címzés Bármely csomópont lehet:  Szerver – állományokat tárol  Router – csomagokat továbbít  Kliens – kéréseket kezdeményez Név (cím-) tartomány  Csomópontok és állományok egyaránt  Megfelelően nagy az ütközések elkerüléséhez 160 bit, 40 hexa számjegy, 16 40 =2 160 cím ~ Kiegyensúlyozott eloszlás a tartományon belül  Hash algoritmus

54 2005 október 5P2P hálózatok 54 Neighbour Map Legyen N egy csomópont (IP cím, ID)  utótag(N, k) = az utolsó k számjegy az ID-ből Minden csomópontban szomszédossági térkép (neighbour map)  Annyi szint, ahány számjegy az ID-ben  Minden szinten annyi bejegyzés, ahányas számrendszerben címzünk  A j szint (j-1) hosszúságú utótagoknak felel meg  Az i bejegyzés a j szinten – a fizikailag legközelebb álló olyan csomópont IP címe, mely ID-je [„i” + utótag(N, j-1)]-re végződik Példa: a 2. bejegyzés a 5712 csomópont térképének 3. szintjén az a 212-re végződő ID-jű csomópont IP címe, mely fizikailag legközelebb áll az 5712 ID-jű ponthoz

55 2005 október 5P2P hálózatok 55 Neighbour Map N = “5712” (Octal) Útválasztási szintek 1234 xxx1 5712 xxx0 xxx3 xxx4 xxx5 xxx6 xxx7 xx02 5712 xx22 xx32 xx42 xx52 xx62 xx72 x012 x112 x212 x312 x412 x512 x612 5712 0712 1712 2712 3712 4712 5712 6712 7712

56 2005 október 5P2P hálózatok 56 Utótag alapú útválasztás Pontról pontra való továbbítás, számjegyenként  **** → ***0 → **10 → *510 → 7510 Hasonlít a longest prefix match alapú IP útválasztásra Mindegy melyik irányból közelítünk  Az eredeti Tapestry javaslat – utótag alapú  Jelenleg – előtag alapú

57 2005 október 5P2P hálózatok 57 Példa 5712 0880 3210 7510 4510 5712 012 3 45 6 7 0880 012 3 45 6 7 3210 012 3 45 6 7 4510 012 3 45 6 7 7510 012 3 45 6 7 5712 → 7510

58 2005 október 5P2P hálózatok 58 Tapestry csomópont N Neighbour Map Object Store  A helyileg tárolt állományok Object Location Pointers  Információk bizonyos állományok tárolási helyéről  Back Pointers  Azokra a pontokra mutatnak, melyek szomszéduknak tekintik N-t Hotspot Monitor  - segítenek a cache kezelésében

59 2005 október 5P2P hálózatok 59 Tapestry csomópont

60 2005 október 5P2P hálózatok 60 Root Node (Plaxton) Adott egy A állomány (ID A ) Az A állomány gyökere (root node) az az R csomópont, melyre igaz a következő: utótag(ID A, k) = utótag (ID R, k)  és nincs olyan más csomópont X melyre igaz lenne, hogy utótag(ID A, k+1) = utótag (ID X, k+1) Ha több ilyen pont van, a legnagyobb címmel rendelkező lesz a root

61 2005 október 5P2P hálózatok 61 A feszítőfa Root(A) az a pont, ahova mindeki fordul ha A-ra kiváncsi Minden A állományhoz egy Root(A) gyökerű feszítőfa tartozik A hálózat bármely pontjáról, véges számú lépés alatt eljutunk a feszítőfa gyökeréhez  Számjegyenként egyre közelebb kerülünk, ameddig egy üres szomszéd bejegyzéshez érünk  Egy utolsó ugrásként egy shortcut vezet a root-hoz  Információt szerzünk az A állományról Statikus megoldás, a hálózat teljes ismerete szükséges  Az összes shortcut-ot előre ki kell számolni

62 2005 október 5P2P hálózatok 62 Root node (Tapestry) Surrogate routing – elosztott megoldás a root kiszámolására Feltételezi, hogy a ID Root(A) = ID A Mivel a címtartomány ritkán „lakott”, valószínüleg nem létezik Ennek ellenére úgy tesz mintha létezne, arra irányítja a csomagokat  Ha egy üres szomszéd bejegyzésre bukkan, kiválasztja az azon a szinten levő következő nem üres bejegyzést  Ha egy szinten egyetlen bejegyzés sincs saját magán kívül, megáll  Ez a pont lesz a surrogate (root)

63 2005 október 5P2P hálózatok 63 4 2 3 3 3 2 2 1 2 4 1 2 3 3 1 3 4 1 1 43 2 4 Tapestry Mesh - Utótag alapú útválasztás NodeID 0x43FE NodeID 0x13FE NodeID 0xABFE NodeID 0x1290 NodeID 0x239E NodeID 0x73FE NodeID 0x423E NodeID 0x79FE NodeID 0x23FE NodeID 0x73FF NodeID 0x555E NodeID 0x035E NodeID 0x44FE NodeID 0x9990 NodeID 0xF990 NodeID 0x993E NodeID 0x04FE NodeID 0x43FE

64 2005 október 5P2P hálózatok 64 Lokalizáció Egy szerver S bejelenti hogy rendelkezik az A állománnyal  S elküld egy Publish (ObjectID(A), ServerID(S)) üzenetet a Root(A) felé  Minden közbeeső router tárolja a linket (A→S) Query(A) → Root (A) felé  Ha útközben valaki tárolta a linket, a kérést azonnal továbbküldi a megfelelő helyre

65 2005 október 5P2P hálózatok 65 Lokalizáció

66 2005 október 5P2P hálózatok 66 Hibatűrő útválasztás Hibadetektálás  Periódikus hello csomagok a szomszédok között Hibakezelés  Minden bejegyzés a Neighbour Map-ban tartalmaz 2 alternatív útvonalat Másodlagos szomszédok  Ha hiba történik, nem törli ki a hibás útvonalat Egy bitet átállítva bejegyzi hibásnak Egy bizonyos ideig (egy nap) ellenőrizgeti Ha megjavitották, visszaállítja a bitet Nem kell költségesen újra beilleszteni He letelik a tűrési idő, kitörli a Map-ből

67 2005 október 5P2P hálózatok 67 Dinamikus beillesztés Több lépésből áll Feltételezzük, hogy N ismeri egy G gateway címét  Expanding ring search, web, stb Step 1: Felépíti N Neighbour Map-jét  Üzenetet küld minden közbeeső csomópont (H 0..H i ) felé a G → N’ útvonalon, ahol N’ az N-hez legjobban hasonlító pont (ID N’ ~ ID N )  H i visszaküldi az i szintű szomszédai listáját G = H 0 utótag (H i, i) = utótag (N, i)  N optimizálja azt, ha szükséges Kiszámolja hogy az elsődleges és másodlagos szomszédok közül ki van fizikailag közelebb Megváltoztatja a sorrendet, ha szükséges  Ha egy üres bejegyzést talál a H i -ban a következő ugrásra, megáll Surrogate routing-al eljut az N’-höz, es az N-hez tartozó adatokat (melyekre N lesz az új root) atmásolja az N-hez

68 2005 október 5P2P hálózatok 68 Példa a dinamikus beillesztésre NodeID 0x243FE NodeID 0x913FE NodeID 0x0ABFE NodeID 0x71290 NodeID 0x5239E NodeID 0x973FE NEW 0x143FE NodeID 0x779FE NodeID 0xA23FE Gateway 0xD73FF NodeID 0xB555E NodeID 0xC035E NodeID 0x244FE NodeID 0x09990 NodeID 0x4F990 NodeID 0x6993E NodeID 0x704FE 4 2 3 3 3 2 1 2 4 1 2 3 3 1 3 4 1 1 43 2 4 NodeID 0x243FE

69 2005 október 5P2P hálózatok 69 Dinamikus beillesztés (II) Step 2: Értesíti jelenlétéről azokat a csomópontokat, melyek üres bejegyzést tárolnak az ID N -re  A surrogate node-tól (N’) visszaindul a backlink-eken  Egészen addig, ahol már megegyezik az utótag  Ezek a csomópontok bejegyzik N-t a saját táblájukba Step 3: Minden értesített csomópont újrapublikálja az érintett állományokat  Lehet, hogy N lesz az új surrogate egy állomány számára  Értesülnie kell az állomány tárolási helyéről Step 4: Értesít más pontokat is (elsődleges, másodlagos szomszédok) a jelenlétéről  Ezek lemérik a távolságot N felé, és átírják a táblájukat ha szükséges

70 2005 október 5P2P hálózatok 70 Irodalom  http://www.cs.berkeley.edu/~ravenben/tapestry/