Peer-to-Peer (P2P) hálózatok

1. Peer-to-Peer (P2P) hálózatok 2006 május 11

2. TBCP • Tree Building Control Protocol • L. Mathy, R. Canonico, D. Hutchison. An overlay tree building control protocol. In Proceedings of International Workshop on Networked Group Communication (NGC), London., 2001. http://citeseer.ist.psu.edu/mathy01overlay.html • Tree-first protokoll • Peer párok közötti mérésekre alapul • Az adatátviteli fát lokális „teljes mesh”-re alapuló dontések sorozata alapján állítja össze 2

3. 1) N HELLOüzenetet küld a P gyökérnek 2) P válaszol egy HELLO_ACK üzenettel melyben elküldi a gyermekei listáját (Ci) N N N N C1 C1 C1 C1 C2 C2 C2 C2 C3 C3 C3 C3 JOIN HELLO HELLO_ACK P P P P TBCP algoritmus • Alap ötlet: • Minden peer a forráshoz küldi először csatlakozó üzenetét • A peer-ek „dominóként hullanak” a fa mentén 3) N leméri a távolságát a P és a Ci gyerekek felé, és elküldi azt egy JOINüzenetben 3

4. P Ha P fokszáma 4 ... ... C3 C2 C1 C2 C3 C3 C1 P C1 C2 P P C2 C1 C1 C3 C2 P C1 C3 P C1 C3 C2 P C3 C2 N N N N N N N … … … TBCP algoritmus (2) • Meghatározunk egy érték függvényt, mely a konfigurációk minőségét jellemzi • Ezt a függvényt használva P értékeli az összes lehetséges konfigurációt, és kiválasztja a „legjobbat” (helyi döntés) • Különböző metrikákat használhatunk • Különböző értékek különböző fák • Melyik a jobb fa? Attól függ mire akarjuk használni... Előny/hátrány:a fát helyi dontések sorozata alapján építjük ki 4

5. Ha P elfogadja N-t mint saját gyerekét, küld egy WELCOME üzenetet • Ha P „meg akar szabadulni” N-től (vagy valamelyik gyerekétől), küld egy GO(Ck)üzenetet • P, vagy a Ci peer amelyik megkapja a GO(Ck)üzenetet újrakezdi az algoritmust, és elküld egy HELLOüzenetet Ck-nak • Ci nem csatlakozik le azonnal a fáról, kap egy kis időt az új kapcsolat felépítésére N N N N C1 C1 C1 C1 C2 C2 C2 C2 C3 C3 C3 C3 WELCOME_ACK WELCOME P P GO_ACK GO P P TBCP algoritmus (3) 5

6. R Vevők csoportosítása(1) • Ha a vevők fizikailag csoportosíthatóak (közel állnak egymáshoz a fizikai topológiában), akkor célszerű ezt a csoportosítást megtartani a TBCP fában is Tartomány „gyökerek” A tartományokat egy domainID azonosítja • A fa gyökere tartományonként választ egy helyi gyökeret (például az elsőként csatlakozó peer), és megjegyzi annak a címét 6

7. Ha egy peer nem helyi gyökér, akkor az apja ugyanahhoz a tartományhoz kell tartozzon Egy peer nem küldhet el egy helyi gyökeret ha több mint 1 saját tartományához tartozó gyereke van P P Vevők csoportosítása(2) • Ha csoportosítjuk a vevőket, a root azonnal a megfelelő helyi gyökér felé irányítja az új csatlakozót • Az előző algoritmus a helyi gyökérnél kezdődik • Ha egy csoportosított fát akarunk kialakítani, a következő kiegészítő szabályokat is figyelembe kell venni: 7

8. Értékelés • Viszonylag jól skálázható megoldás • Semmilyen információ nem szükséges a fizikai topológiáról • Nem szükséges ismerni a csoport összes tagját • Elosztott megoldás • Több peer akár egyszerre is csatlakozhat • Egyszerre csak egy peer csatlakozhat egy gyökérhez • Könnyen telepíthető • Viszonylag jó fát épít viszonylag gyorsan • Implementációs hack a hatékonyság javítására • Ha túl sokáig tart egy cél felé a mérés, akkor állitsuk az értéket végtelenre 8

9. Más tree-first protokollok • Yoid - Your Own Internet Distribution • P. Francis, „Yoid: Extending the Multicast Internet Architecture”,White paper, 1999. http://www.aciri.org/yoid/ • HTMP – Host Multicast Tree Protocol • B. Zhang, &.Jamin, L Zhang, "Host Multicast: A Framework for Delivering Multicast to End Users,"IEEE INFOCOM '02, New York, NY, June 2002. http://citeseer.ist.psu.edu/zhang02host.html • ALMI – Application Level Multicast Infrastructure • D. Pendarakis, S. Shi, D. Verma, M. Waldvogel, "ALMI: An Application Level Multicast Infrastructure," in Proc. 3rd Usenix Symposium on Internet Technologies & Systems, March 2001. http://citeseer.ist.psu.edu/456978.html 9

10. Implicit ALM • Az elosztott hash-táblákra alapuló P2P kommunikációs megoldásokat multicast szolgáltatásra is lehetne használni • A DHT-k egy speciális kontroll topológiát építenek fel • Az adattovábbítási szabályai a topológiának implicit módon definiálhatnak egy multicast fát 10

11. CAN Multicast • S. Ratnasamy, M. Handley, R. M. Karp, S. Shenker, Application-level multicast using content-addressable network, In Proceedings of NGC, 2001. http://citeseer.ist.psu.edu/ratnasamy01applicationlevel.html • A CAN DHT alapú útválasztását használja • Ha a CAN összes eleme tagja a multicast csoportnak, akkor hatékony elárasztást alkalmaz • Ha nem, a multicast csoport tagok egy „mini-CAN”-t alakítanak ki, és azon történik majd az elárasztás 11

12. Mini-CAN • Legyen egy C CAN • Legyen a C elemeinek egy halmaza mely egy G multicast csoportot akar alkotni • Létrehozzuk a CG „mini-CAN”-t, az eredeti CAN-t használva • A G címet egy (x,y) koordinátára hash-eljük, és a C-ben az (x,y)-ért felelős peer-t használjuk kiinduló pontként (bootstrap node) az új CAN építésében • Bárki aki be akar csatlakozni a csoportba ehhez a ponthoz fordul (a hash függvényt alkalmazva a G cimre) • Megkapja néhány a CG - be már becsatlakozott csoporttag címét • A továbbiakban a hagyományos CAN kiépítési algoritmust használja 12

13. Multicast adatátvitel • A mini-CAN összes elemének elküldjük a csomagot – hatékony elárasztás • Bárki kezdeményezheti az elárasztás • Bárki lehet forrás • Nincs multicast fa • Hagyományos elárasztásnál gond a csomagduplikálás • Ki kellene a CAN-t használni arra, hogy csökkentsük a duplikálást 13

14. Elárasztási szabályok • Az elárasztás a következő szabályok szerint történik • A forrás minden szomszédjának elküldi a csomagot • Egy peer aki a szomszédjától az i dimenzió-n keresztül kapott egy csomagot, továbbküldi azt az összes 1...(i-1) dimenziós szomszédjához, és azokhoz az i dimenziós szomszédaihoz, melyek ellentétes irányban vannak az érkezési iránnyal • Egy peer nem küld tovább egy csomagot egy dimenzió-n belül, ha az a csomag a forrástól számítva már a tér több mint felét bejárta abban a dimenzióban • Elkerüli a hurkokat a tér „mögött” • Egy peer tárolja a kapott csomagok sorszámát, és duplikálás esetén nem küldi tovább őket 14

15. Példa 15

16. Bayeux: An Architecture for Scalable and Fault-tolerant Wide-area Data Dissemination S. Q. Zhuang, B. Y. Zhao, and A.D. Joseph 11th ACM/IEEE NOSSDAV, New York, June 2001. http://citeseer.ist.psu.edu/465642.html

17. Bayeux Tapestry • A bayeux-i kárpit • Bayeux – város Normandiában • A hastingsi csata megörökítése, Hódító Vilmos és Harold gróf között • A kárpitot 1077-ben ajándékozták a bayeux-i székesegyháznak • Több mint 60 méter hosszú 17

18. Bayeux Tapestry (részlet) • EDWARD REX. UBI HAROLD DUX ANGLORUM ET SUI MILITES EQUITANT AD BOSHAM. • Edward király. Amikor Harold, az angolok grófja, és az ő kisérete, Bosham felé lovagol 18

19. Bayeux • Egy hatékony, forrás-specifikus, explicit-join alapú, alkalmazás rétegbeli multicast megoldás • A Tapestry útválasztó mechanizmusait használja • Skálázhatóság • Hibatűrő adatátvitel • Optimalizálási megoldások • Önszerveződő csoport particiók • Azonosító csoportosítás (clustering) 19

20. Bayeux architektúra • Egy Bayeux multicast csoportot egy <csoport név, UID> címpár azonosít • A multicast forrás (MS) egy nyilványos hash függvényt használva, az azonosító címpárból egy 160 bit hosszú Tapestry azonosítót (MG) generál • A forrás létrehoz egy triviális állományt, melynek ezt a nevet (MG) adja. Ezután elkezdi terjeszteni az információt a Tapestry hálózatban • Publish (ObjectID(MG), ServerID(MS)) a Root(MG) felé • Ha egy kliens be akar csatlakozni a csoportba, ismernie kell a <csoport név, UID> címpárt • Ugyanazt a hash függvényt alkalmazva, megkapja az MG állomány nevet • Elkezdi keresni ezt az állományt a rendszerben • A keresés a Root(MG) felé irányul, és végül eljut a forrásig • A multicast forrás minden csatlakozni kívánó peer-től kap egy üzenetet 20

21. Bayeux adatátvitel • A Tapestry útválasztó mechanizmusa kiválóan alkalmas multicast forgalom kezelésére • A multicast csomagokat a vevők címének utótagja alapján továbbítja • Számjegyenként haladunk a címben, jobbról balra • Ha két multicast vevőnek bizonyos mértékig megegyezik a címük, egy darabig lehet közösen küldeni a csomagot • A csomagot csak ott kell duplikálni, ahol a címek eltérnek • A multicast fa maximális „mélysége” korlátozott (a címek hossza által) • Az overlay ugrások korlátozása növeli a hatékonyságot • A többi ALM megoldással ellentétben, nem minden Tapestry peer kell Bayeux multicast vevő legyen • A Tapestry háló egy infrastruktúrát biztosít a multicast szolgáltatásnak 21

22. Bayeux multicast fa • Egy csatlakozni kívánó peer egy Join üzenetet küld az MS forrásnak • = elkezdi keresni az MG állományt a hálózatban • A forrás egy Tree üzenetet küld vissza a csatlakozónak • A Tree üzenet felépíti a multicast fa új ágát • A közbeeső alkalmazás-rétegbeli „router”-ek bejegyzik az útválasztó táblájukba az új vevő címét • Asszimetrikus útvonalak – a Join és a Tree más-más irányba terjedhet • Minden csatlakozást a forrás kezel • Előny – mindenkiről tud • Hátrány – nagy terhelés, hibalehetőség (single point of failure) • A kilépéshez Leave, majd Prune üzenet • A közbeeső router-ek frissítik az útválasztó táblájukat 22

23. PRUNE LEAVE TREE JOIN Bayeux: Adatátviteli fa kezelése node6 node3 node1 node7 node9 node2 node8 node4 forrás node5 23

24. 79FE 79FE 793E 79FE 793E 79FE 793E 793E Útválasztó bejegyzések 79FE Receiver 23FE 993E F9FE 43FE 73FE 44FE F990 29FE 035E 04FE 13FE 555E ABFE 9990 Multicast Root 793E 239E 1290 093E 423E Receiver 24

25. Útválasztó bejegyzések 25

26. Hatékonyság • A modell hátrányai: • Az egyedi multicast forrás szűk keresztmetszet • Skálázhatóság • Hibalehetőség (single point of failure) • A hatékonyság növelése: • Önszerveződő csoport particiók • Azonosító csoportosítás (clustering) 26

27. Csoport partíciók • Több multicast gyökeret hozunk létre • A vevőket a hozzájuk legközelebb álló gyökér partíciójába osztjuk, a Tapestry-t használva • Több Bayeux peer (leendő multicast gyökerek – MSi) belép a Tapestry rendszerbe • Kiszámoljuk a multicast csoport hash-elt Tapestry azonosítóját (MG) • Minden gyökér (MSi) létrehoz egy MG nevü fájlt, és elkezdi hírdetni azt • Publish (ObjectID(MG), ServerID(MSi)) a Root(MG) felé • A csatlakozó vevők Join üzenetei a legközelebbi gyökérhez jutnak el • Különböző, egymástól független multicast fák alakulni • Előnyök: • Nő a skálázhatóság, nő a megbízhatóság – nincs szűk keresztmetszet • Lehetséges a terheléselosztás a gyökerek között 27

28. JOIN Receiver JOIN 43FE Receiver JOIN Csoport partíciók - példa 79FE 23FE 993E F9FE 43FE 73FE 44FE F990 29FE 035E 04FE 13FE 555E ABFE 9990 Multicast Root Multicast Root 793E 239E 1290 093E 423E Receiver 28

29. Azonosító csoportosítás • Egy Tapestry címzés akkor a leghatákonyabb a Bayeux multicast szempontjából ha... • A földrajzilag közel álló peer-eknek minék hosszabb utótaguk közös • Csak a fa alján kell a csomagokat duplikálni • Habár a Tapestry a hash függvény által biztosított egyenletes címelosztásra alapul... • A Bayeux csoportok sokkal kisebbek lesznek mint a Tapestry háló • Ezeknek a peer-eknek a csoportosított címkiosztása nem befolyásolja jelentősen a globális Tapestry rendszer hatékonyságát 29

30. Azonosító csoportosítás Forrás 0x0ABC 0x1ABC 0xABC 0x0XYZ 0x1XYZ 0xFXYZ 30