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
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).
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.
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.
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).
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.
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.
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.
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 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.
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
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.
·
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)