p2p ma
tanulmány a Korszerű szoftver-architektúrák tárgyhoz

A p2p (peer-to-peer) olyan hálózati architektúra, melyben a csomópontok kliens és szerver funkciókat is ellátnak. Tiszta p2p esetén minden csomópont egyenrangú, hibrid p2p esetén több csomópontosztály is elképzelhető (például sima csomópont és szopercsomópont, ez utóbbi nagyobb felelősséget vállal az adott p2p hálózat által nyújtott szolgáltatás üzemeltetésében). E tanulmány olyan mai p2p hálózatokkal foglalkozik, melyek fő célja a fájlmegosztás. Az ilyen hálózatokról és a használható szoftverekről friss információ tarlálható a zeropaid portálon.

Indypeer a p2p hálózatokat az alábbi generációkba sorolja:

p2p fájlmegosztó hálózatok tulajdonságai

A p2p hálózaton történő fájlmegosztás előnyei (+) és hátrányai (-) a kliens-szerver alapú fájlmegosztásokhoz (pl. FTP, HTTP) képest:

Egy p2p fájlcserélő hálózat által nyújtható funkciók:

A p2p szoftverek a hálózattól függetlenül az alábbi értékeket adhatják hozzá:

A p2p üzleti lehetőségei:

Elosztott hashelés (DHT)

Ez a rész a egy, Linux Journal-ban 2003-ban megjelent cikk alapján készült. A cikk egy sorozat első része, de további részek nem jelentek meg. A cikkben Python nyelvű, igen egyszerű példakód is található.

A feladat egy kulcs--érték párokat tartalmazó elosztott adatbázis létrehozása. A funkciók: új kulcs--érték pár beszúrása, érték keresése ismert kulcs alapján, kulcs--érték pár törlése, érték megváltoztatása ismert kulcs alapján. Az adatbázisnak elosztottan kell működnie, vagyis a párokat a különböző csomópontokon elosztva kell tárolni. Kezelni kell a csomópontok ki- és belépését a rendszerbe, és redundanciával biztosítani kell egy csomópont figyelmeztetés nélküli kiesésének kezelését is.

Egy ilyen adatbázis tipikus alkalmazásai: keresés és felderítés tiszta p2p hálózatban, elosztott DNS, biztonsági másolatot tartalmazó elosztott winchester, jól skálázható chat, szerver nélküli internetes játékok, elosztott portscannelés. A p2p hálózatban való keresésnél a kulcs a szó (amit a fájlnév tartalmaz), az érték pedig a letöltéshez szükséges információk (pl. hash és méret). A felderítésnél a kulcs a hash--méret pár, az érték pedig azon csomópontok listája, melyekről letölthető az adott fájl.

A továbbiakban az egyszerűség kedvéért feltesszük, hogy az elosztott hálózat már felépült, és a csomópontok ismerik ,,szomszédaik'' IP címét, és csomópont csak úgy eshet ki, hogy a kilépési protokollt szabályosan végrehajtja. A valóságban ezen feltételezések nem helytállóak, ezért az itt bemutatottnál bonyolultabb DHT algoritmus szükséges (lásd például a p2p fájlmegosztásban (pl. AMule) ma is használt Kademlia DHT-ről szóló 2002-es cikket).

Az adatbáziunk hashtábla alapú. A kulcsból egy k bites hash-et képezünk (k tipikus értéke 128), és ezen érték egyértelműen kijelöli, hogy melyik csomópontnál van meg a kulcshoz tartozó érték. A csomóponton belüli keresést a szokásos keresési algoritmusokkal (pl. hash-elés vagy rendezett fák) végezhetjük. A csomópontok belépéskor egy véletlenszerű, használaton kívüli k bites sorszámot választanak maguknak. A címtartomány (0 .. 2**k-1) elég nagy ahhoz, hogy ne legyen az összes cím foglalt. Egy kulcs--érték párt annál a csomópontnál tárolunk, melynek sorszáma legközelebb van a kulcs hash-éhez. (A távolságon nem feltétlenül a számok különbségének abszolút értékét értjük, lásd később.) Az érték keresése tehát a következő módon végezhető: minden csomópontra kiszámítjuk a csomópont és a kulcs hash-ének távolságát, és a legkisebb távolságú csomóponttal kapcsolatot létesítve megkérdezzük tőle az értéket a kulcs alapján. Különböző technikákkal (pl. ujjtábla, lásd később) biztosítható, hogy ne a legkisebb távolság megtalálásához ne kelljen az összes csomóponot bejárni.

A Chord DHT ,,autóverseny''-távolságot használ. Ehhez a k bites számokat növekvő sorrenben egy gyűrűre írjuk, és kijelöljük, hogy a gyűrűn csak előre (növekvő sorrendben, kivéve a végéről elejére lépést) szabad haladni. Az így megtett távolság a két szám távolsága. Például k==3 esetén 2 és 7 távolsága 5 (mert 2, 3, 4, 5, 6, 7), de 7 és 2 távolsága 3 (mert 7, 0, 1, 2). Az adott hash értékhez legközelebbi csomópont megkereséséhez szükség van egy egyirányú körbeláncolt listára, melyen a csomópontok szerepelnek növekvő sorrendben (ám az értékek nagy része kimarad, mert a legtöbb k bites számhoz nem tartozik aktív csomópont). Minden csomópont tárolja az őt követő csomópont sorszámát. A keresés egyszerű, de lassú: a csomópont önmagából kiindulva végigmegy a láncolt listán, és kiválasztja a keresett hash értékhez legközelebbi csomóponthoz. A végigmenéshez minden csomóponttal fel kell vennie a kapcsolatot, ezért a keresés nagyon lassú (O(n) idejű, ahol n az aktív csomópontok száma). A csomópontok ki- és belépése visszavezethető listaláncolási műveletekre és a szomszédos csomóponttól való kulcs--érték párok átvevésére.

A fenti keresés gyorsítható az ujjtáblák bevezetésével. A továbbiakban a csomópontok nem egy körbeláncolt listát, hanem egy szövevényesebben körbeláncolt adatstruktúrát tartalmaznak. Minden csomópontnak k db mutatója van, és csomópont[id].mutató[x]==felelős(id-2**x mod 2**k), ahol felelős(h) a h hash értékű kulcs tárolásáért felelős csomópont sorszáma, x egész és 0<=x<k. (A fenti mutató tömb nem általánosítása a láncolt listának.) A fent idézett cikkben mínusz helyett plusz szerepel a fenti képletben, de ekkor a elképzelhető lenne, hogy mutató[0], mutató[1] stb. az eredeti csomópontra mutatnak vissza, így nem lehet 1-esével előre lépni. Az ujjtáblák segítségével az O(n)-es keresési idő O(log n)-re csökkenthető. Tegyük fel például, hogy egy csomópont keresi a saját sorszámánál 13-mal kisebb hash értéket. Ehhez megnézi mutató[3]-at és mutató[4]-et, s mivel ezek különböznek, tudja, hogy csak id-16, id-15, id-14 vagy id-13 lehet a keresett csomópont. Ekkor mutató[3]-tól elkéri az ő mutató tömbjét, és ezzel felezni tudja a szóba jövő csomópontok körét. A következő lépésben újabb mutató tömböt kér le, mellyel újabb felezére van lehetőség stb.

Az ujjtáblás módszer fő hátránya, hogy csomópontok ki- és belépése esetén bonyolult a mutatók karbantartása. Az ekkor elküldött üzenetek száma csökkenthető egy szimmetrikus távolságdefiníció bevezetésével, mert ekkor a normál keresési műveletek mintegy melléktermékeként a mutató tömböket is lehet frissíteni. Természetesen adódó szimmetrikus távolság a két érték bitenkénti kizáró vagy (xor) kapcsolata. A már említett Kademlia is ezt használja.

Kitekintés

A p2p mára biztos helyet taposott ki magának a hálózati architektúrák körében, de jelenleg nem váltotta be a hozzá fűzött reményeket. A letöltések megkezdésére sokat kell várni, a letöltések lassúak, a kliensek nem elég stabilak, és nem szolgálják ki eléggé a felhasználót. A megosztott fájlokkal kapcsolatban jogi problémák is felmerülnek.

Fejlődés várható a harmadik generációs, elosztott hálózati technológiák terén (a folyóiratok és konferenciák listája itt olvasható). Ezek előre láthatóan csak lassan fognak beépülni a népszerű p2p kliensekbe (például a 2002-ben publikált Kademlia 2005-ben még nincs benne az AMule kliensben, pedig régóta ígérik). Növekszik az anonimitás jelentősége, élénkül a jogi és technikai harc a p2p ellenzői (lemezkiadók, filmgyártók, internet-szolgáltatók) és pártolói között.


Írta: Szabó Péter <pts(kukac)fazekas.hu> 2005 júniusában
Valid HTML 4.01!