Peer-to-Peer: elosztott rendszerek másként

Csúcs Gergely (wizard@avalon.aut.bme.hu)

Marossy Kálmán (coloman@avalon.aut.bme.hu)

Dr. Charaf Hassan (hassan@avalon.aut.bme.hu)

BME, Automatizálási és Alk. Informatikai Tanszék

Bevezetés

Napjainkban az elosztott rendszerek jelentőssége megkérdőjelezhetetlen. Az elosztott rendszereken, mint általános csoporton belül is a közismert többrétegű architektúrák mellett egyre inkább tért nyernek az egyenrangú résztvevők együttműködésén alapuló, úgynevezett Peer-to-Peer (P2P) rendszerek.

A P2P hálózatok az ügyfél-kiszolgáló kapcsolathoz képest jelentősen eltérő módon működnek: a szerepek nincsenek előre meghatározva; többnyire követelmény is, hogy az összes résztvevő képes legyen valamilyen erőforrást a rendszer egésze számára elérhetővé tenni viszonzásképp az általa igénybevett szolgáltatásokért. Az így megosztható erőforrások általában a következő három kategóriába sorolhatók: fájlok, számítási kapacitás, felhasználói jelenlét (legegyszerűbb esetben csevegés).

Peer-to-Peer rendszerek felépítése

A P2P rendszerek az aktuális feladattól függetlenül egy úgynevezett overlay ("fölöttes") network létrehozásával működnek. Erre azért van szükség, mert ezek a rendszerek alapvetően szomszédossági alapon működnek: hogy ne legyen szükség kitűntetett szerepű résztvevőkre, ugyanakkor elegendő legyen, hogy minden node csak korlátos számú másikkal tartson kapcsolatot, az üzenetek továbbítása logikai pont-pont kapcsolatokon keresztül történik.

Ez a működési mód igazából nem újdonság: az "ős-Internet" pontosan ugyanígy működött, minden csomópont útvonalválasztóként is funkcionált és az ügyfél-kiszolgáló szerepek sem különültek el. A mai Internet már erősen specializált, ez a három szerep tipikusan szeparáltan valósul meg. Emiatt, és azon tény miatt, hogy az Internet közösségének jelentős hányada nem képezi részét egy adott P2P rendszernek, szükséges a saját logikai hálózat kialakítása saját üzenettovábbítási mechanizmusokkal.

A saját útvonalválasztó és üzenettovábbító alrendszer szükségessége természetesen munka, viszont egyben szabadságot is jelent: az adott applikáció számára protokollszinten biztosíthatunk támogatást (ez például a tartalom szerinti route-olás lehetőségét jelenti), illetve a megcélzott hardver eszközök és átviteli közeg ismeretében dönthetünk, hogy milyen routing algoritmust alkalmazunk (egy adott algoritmus számításigénye és az általa generált forgalom a gyakorlati tapasztalatok alapján fordítottan arányosnak tekinthető).

A P2P rendszerekben az útvonalválasztás ill. a protokoll nem választható el az alkalmazástól, hiszen egy file-sharing alkalmazás esetében elegendő, ha legalább egy példányt megtalálunk egy adott állományból, míg egy csevegés-jellegű (chat, whiteboard, vagy bármilyen applikáció-megosztás) együttműködés esetében értelemszerűen szükséges, hogy az összes résztvevőhöz eljussanak az események. Ezen okok miatt általános protokollszintű optimalizációról nem beszélhetünk.

Fájl megosztás megvalósított Peer-to-Peer rendszerekben

Cikkünkben azon P2P architektúrákat vizsgáljuk, amelyek célja alapvetően a fájl megosztás. Az ilyen rendszerek a legelterjedtebbek, és többféle megoldás alakult ki a felhasználók közötti dokumentum megosztására.

Centralizált, hibrid

Egy hibrid P2P rendszer valójában nem teljesen felel meg a P2P rendszer definíciójának. Bár minden csomópont egyenrangú, a felhasználók dokumentumainak attribútumai (fájlnév, milyen IP-vel rendelkező gépen található, minőség, szerző, cím, stb.) egy központi szerveren vagy szerver csoporton vannak tárolva. Az egyik első P2P rendszer, a Napster is ilyen architektúrájú, az ilyen rendszerek a P2P rendszerek legelső generációjához tartozik.

Ezen architektúra előnyének mondható, hogy a szerver kiszolgáló-képességének határáig gyors, a keresés az összes dokumentumban történik, viszonylag kis hálózati forgalmat igényel. E sok előnyből azt gondolhatnánk, hogy mindenki ezt az architektúrát választja. De egy ilyen, félig centralizált rendszer hátránya, hogy a dokumentumok adatait tároló szerver miatt rendelkezik a centralizált rendszerek minden hátrányával, vagyis az egész rendszer működése megszűnik a szerver hibája, vagy megszűntetése miatt (mint például a Napster esetében, jogi okok miatt).

Teljesen elosztott, homogén

A P2P rendszerek következő generációja a teljesen elosztott, homogén, "igazi peer-to-peer" rendszer. Leggyakoribb példája a Gnutella hálózat. Az ilyen rendszerben valóban minden résztvevő (csomópont) egyforma: a csomópontok teljesen azonos szerepűek, ugyanazt a feladatot látják el. Egy ilyen rendszerben a dokumentumok adatai nem egy központi szerveren találhatók, hanem ténylegesen egy adott résztvevő tudja csak, hogy milyen attribútumokkal rendelkeznek az általa tárolt dokumentumok.

A keresés tehát megnehezedik: egy adott fájl keresése a hálózatban már nem csupán egy központi szerverhez való adatküldésre korlátozódik. Az egyik csomópont megkap egy kérést (keresést), megvizsgálja, hogy nála megtalálható-e az adott dokumentum, majd ha nem, tovább küldi az általa ismert résztvevőknek, akik szintén ezeket a műveleteket hajtják végre a kérésen.

Az előnyök és hátrányok már láthatók: ebben a rendszerben egy résztvevő hibából, vagy más okokból történő leállása, leállítása nem okoz problémát. Azonban a keresés lassabb lesz, és ami a legfontosabb, nagy hálózati forgalmat generál egy keresés. Ha egy adott kérés bizonyos mélységű továbbküldözgetésével szeretnénk elérni egy adott dokumentum megtalálásának valószínűségét, akkor figyelembe kell vennünk, hogy az általunk használt résztvevő megengedheti-e magának azt a hálózati forgalmat, ami ehhez szükséges.

Sok rendszer született, ami ezt az architektúrát választja, és még több, ami alapvetően nem ezen az architektúrán alapul, de támogatja az ilyen protokollt. A legtipikusabb példák: LimeWire, Shareaza, Morpheus.

Félig elosztott, hierarchikus

Manapság a gyakorlatban (fájlmegosztásra) használt rendszerek jelentős része hierarchikus szerkezetű. Ilyen rendszereknél bár nem minden csomópont azonos, de azonos viselkedési típusok, szerepek közül választhatnak. Egy nagyobb hálózati forgalmat, vagy nagyobb számítási kapacitást kiszolgálni képes csomópont kiválaszthatja a neki megfelelő szerepet, amivel a többlet erőforrásai kihasználhatóvá válnak, míg a kisebb teljesítményű résztvevők sem kényszerülnek olyan feladatok ellátására, amire nem képesek.

Az ilyen rendszerek jelentős része mindössze kétszintű: a kisebb képességű résztvevők közvetlenül nem vesznek részt a keresésben, hanem dokumentumaik információit odaadják egy nagyobb képességű résztvevőnek, akivel közvetlen kapcsolatban állnak. Egy adott attribútumokkal rendelkező dokumentum iránti kérést szintén ehhez a nagyobb képességű csomóponthoz intézi. A nagyobb képességű résztvevő (super-node) a többi társához továbbítja a kérést, akik mind információval rendelkeznek a hozzájuk kapcsolódó kisebb képességű résztvevők dokumentumairól is.

Ez az architektúra tehát az előző két típusú rendszere előnyeit próbálja ötvözni. Talán ennek köszönhető, hogy a legtöbb mai rendszer kétszintű: a talán legtöbbek által ismert Kazaa, és Grokster társa, illetve korábban a Morpheus rendszer is (mindannyian a FastTrack nevű rendszert használják), valamint a szintén közkedvelt WinMX is, de a Gnutella 0.6 vagy 2 protokollt használó számos rendszer (Shareaza, LimeWire) is ebbe a kategóriába tartozik.

Elosztott indexelés

A legelső, centralizált változat azért volt gyorsabb (és kisebb erőforrás-igényű) a második, decentralizált változatnál, mert nem kellett az összes résztvevőt végigkérdezni, rendelkezik-e az adott dokumentummal, hanem egy központi szerver tudott erre a kérdésre válaszolni. A központi szerver ilyen szerepét azonban rábízhatjuk a többi résztvevőre is. Egy megfelelően szervezett struktúra majdnem hasonlóan gyors lehet, míg hibákra és egyéb tényezőkre érzéketlen marad az elosztott tárolás következményeként.

Az indexek legtöbbször bináris formába alakítás után egy fa, vagy egy gyűrű struktúrában tárolhatók, ahol az index utáni keresés logaritmikus mértékű a résztvevők számához képest, ami hatékonynak mondható. Az ilyen rendszerek azonban többnyire egyszerre csak egy kritérium (például fájlév) indexelését támogatják, ami nem elég flexibilis.

Ezen a problémán például az előző architektúrákkal való kombinálással lehet segíteni (például Gridella). Szintén ezen a problémán próbálnak megoldást javasolni olyan struktúrák, ahol több, hierarchikus felépítésű index-szerkezet létezik (például "Content-based aggregation network"). Szintén jellemző ezen kívül a keresések gyorsítása olyan módon, hogy a P2P struktúra figyelembe veszi az egyes résztvevők földrajzi elhelyezkedését, vagy a hálózati késleltetést (például Grapes).

Ezeknek a rendszereknek tehát rendkívüli előnyük a teljes elosztott működés melletti gyors, kis hálózati forgalmat generáló keresés a dokumentumok között, míg hátrányul sorolhatjuk fel a csökkent mértékű flexibilitáson kívül a meglehetősen bonyolult felépítést is. Egy index fa, vagy gyűrű, esetleg egyéb, elhelyezkedésen alapuló struktúra felépítése és karbantartása legtöbbször nem egyszerű algoritmusokat igényel. Külön probléma lehet - a résztvevők folyamatos változása (kilépés, belépés) miatt - a rendszer nem stabil állapotban lévő teljesítményére vonatkozó állítások megfogalmazása is.

Az ilyen rendszerek sok előnye, ám sok problémája miatt többféle megoldás is született, ami elosztott indexelést alkalmaz. Példaként sorolható fel: Gridella (P-Grid fa), Chord, CAN, Pastry, Tapestry, Freenet, Grapes, stb.

Homogén Peer-to-Peer architektúra felépítése

Vizsgálataink alanyául az egyik legelterjedtebb kevéssé számításigényes protokollt, a Gnutella-t választottuk. File-sharing protokollról van szó, de ez a gyakorlatban csak kérések és válaszok továbbítását jelenti, a tényleges átvitel az overlay network-ön kívül történik.

A Gnutella protokoll

A Gnutella a kevéssé számításigényes protokollok közé tartozik, a P2P hálózaton belül broadcast-ot valósít meg. Az egyes kérések által generált forgalmat az úgynevezett TTL (time to live, hátralevő élettartam) paraméterrel korlátozza, ami általában 7-ről indul, és minden továbbításkor csökken eggyel (mikor eléri a 0-t, a csomag nem kerül továbbításra). Az egyszer már feldolgozott csomagok újraprocesszálásának (és ami még lényegesebb: újratovábbításának) elkerülése érdekében általános módszer az utoljára látott n csomag azonosítójának megőrzése. A Gnutella ezt az információt a forrás összeköttetéssel együtt tárolja, és a válaszok back-route-olására is felhasználja.

A Gnutella kérések ugyanis nem tartalmaznak IP címeket, csak a válaszok. Ez egyfajta - bár megkérdőjelezhető hasznosságú - névtelenséget biztosít a résztvevők számára.

A mai Internet közönsége érthető okokból bizalmatlan. Ennek az egyik leggyakoribb megnyilvánulása a tűzfalak használata, amelyek igen erőteljesen elhatárolják a kiszolgálókat és az ügyfeleket. Ez egy olyan alapvető probléma, amellyel valamilyen módon minden P2P rendszernek számolnia kell: kapcsolatlétrehozás szempontjából a tűzfalak egyirányúak. Az overlay network szempontjából tehát szükséges olyan node-ok jelenléte, amelyek képesek kapcsolatokat fogadni, nincsenek tűzfal mögött. A nagyobb probléma a fájlátvitel támogatása jelenti; ezt a Gnutella akkor bírja megoldani, ha a két node közül legfeljebb az egyiket védi firewall. Ugyanis - ha a szerver szerepet betöltő csomópont van tűzfal mögött - lehetőség van az overlay network-ön belül egy úgynevezett Push Request továbbítására, melynek hatására a fájlátvitelt a szerver fogja megindítani, így a tűzfal - rendszeradminisztrátorok által tipikusan nem támogatott - átkonfigurálására sincs szükség, és mégis létrejöhet az áttöltés.

Topológiák

A Gnutella specifikáció a legteljesebb mértékben nyitva hagyja a hálózatépítés és egyáltalán, a logikai hálózatban megvalósítandó célszerű topológia kérdését, vizsgálatainkat elsősorban ebben a témakörben végeztük.

Négy alap topológiát hasonlítottunk össze az általunk definiált kritériumok alapján.

ˇ Random Mesh: teljesen véletlenszerű gráf, tehát megengedjük izolált node-ok jelenlétét is

ˇ Connected Mesh: található a gráfban olyan részfa, amely minden csomópontot tartalmaz

ˇ Semi-Random Mesh: véletlenszerű gráf, de minden csomópont rendelkezik legalább egy kapcsolattal

ˇ Connected Stars: szoftver szempontból továbbra is él a homogenitás, de az erőteljesebb hardverrel rendelkező résztvevők felismerése segítségével létrehozható egy alhálózat, amelyen a többi csomópont csupán 1-1 kapcsolaton át, levélként függ

Összegzés

Cikkünkben áttekintést nyújtottunk a Peer-to-Peer rendszerarchitektúráról, általános jellemzőiről, majd részleteztük a fájlmegosztó rendszerek különféle indexelési stratégiáit. A kép teljességét egy konkrét protokoll, és a tipikus nehézségekre nyújtott megoldásainak ismertetésével kíséreltük elérni.

Előadásunkban az ismertetett topológiák összehasonlítására kerül majd sor, elsősorban az általunk elfogadható találati arány eléréséhez szükséges forgalom, és annak csökkenthetősége szempontjából.

Irodalom

ˇ Andy Oram (edited by): Peer-to-Peer - Harnessing the Power of Disruptive Technologies. O'Reilly, 2001.

ˇ Gnutella 0.4 specification (http://www.limewire.com)

ˇ Matei Ripeanu: Peer-to-Peer Architecture Case Study: Gnutella Network (http://people.cs.uchicago.edu/~matei/PAPERS/gnutella-rc.pdf)