Erőforrásmegosztás p2p hálózatokon Czigola Gábor

Erőforrásmegosztás Motiváció: véges kapacitás, azonban egyenletes elosztás hiánya Disk space CPU time Bandwidth

Hálózati topológiák

Kliens-szerver modell Olyan központi szerver kell amely a maximális igényeknek is megfelel Drága Hamar elavul Szerver leállása esetén egész rendszer használhatatlan Erőforrásigények ingadoznak, ezt a szerver képtelen eloszlatni p.l.: AFS, NFS, CIFS, DFS, plan9

GRID rendszerek Résztvevő gépek közben gyakran másra nem használhatóak Résztvevők maguk nem profitálnak (közvetlenül) abból, amiben részt vesznek Mind csak a közös (ismeretlen) célt szolgálják Gyakran központosított feladatkiosztás p.l.: GridEngine, Avaki, legtöbb Linux

P2P Számítógépek összessége, melyek topológiailag egy hálózatot alkotnak A hálózat minden tagja azonos jogosultságokkal rendelkezik A hálózat minden tagja azonos működést és szolgáltatásokat feltételez a többi résztvevőről A hálózat tagjai erőforrásaik (p.l.: CPU idő, lemezterület, sávszélesség) egy részét a tagságért cserébe „feláldozzák”) „peer” = 1. egyenrangú, 2. társ

Distributed computing distributed.net (RSA feltörés) grid.org (Human proteome folding) BOINC! (Seti, LHC, Einstein, SZTAKI...):  Létre lehet hozni saját projektet  host, GFlop (TOP500 #1: CPU, Gflop) De  Nincs kommunikáció a résztvevők között  Központi feladatkiosztás

Központi szerver, de p2p adatkapcsolat p.l.: Napster, Skype DC++, eDonkey, BitTorrent (több szerver)

Pure p2p p.l.: Gnutella

Üzenettovábbítás Kevés üzenettípus (ping, pong, query, query hit, push)

Találat, kapcsolatfelvétel

Hátrányok, hiányok Csekély biztonság, kis megbízhatóság Small World Network ellenére csak k.b. 50% elérhetőség Lassú keresés (megoldás: SuperNode-ok, kliensek, melyek körülöttük lévő tartalmat indexelik. p.l.: FastTrack (Kazaa, Grokster, iMesh, Gnutella2)) Denial of Service vagy flood támadásokra rendkívül érzékeny

Útkeresés (route) gyorsítása Túl sok helyre továbbítódnak az üzenetek feleslegesen O(n) hatékonyságú bejárás Szükség lenne a lehetséges adatok valamilyen sorbarendezésére, így a biztos értelmetlen irányba nem kellene továbbítani De túl sok lehetséges cél => HASH

HASH Szürjektív de nem injektív függvény, kompakt értékkészlet, „jól szórjon” Egyszerű példa: írjuk a hashelendő adat bájtjait egymás alá, összegezzük (vagy más logikai művelet) és egy előre meghatározott konstans osztási maradéka legyen a hash Gyakorlatban: SHA1, MD5 Használható:  Tartalom hashelése: Ellenőrző összeg (lépten-nyomon)  Metaadat (p.l.: filenév) hashelése => DHT

Distributed Hash Table Helyezzük el a HASH függvény lehetséges 2 m db. értékét egy köríven óra mutató járása szerint növekvően Helyezzük el a csatlakozókat azonosítójuk (pl. IP cím) hashe alapjána a körön successor(k): Egy keresett k kulcs rákövetkezője az az első kulcs, amely k-ból kiindulva valamely klienshez van rendelve Minden kliens felelős azokért a kulcsokért, melyeknek ő a rákövet- kezője Gyakorlatban: sokkal nagyobb kör, egy kliens több helyre is kerül

Key Based Routing Routolási táblázat:  Az n hashelt azonosítóval rendelkezőnél az i-ik bejegyzés: successor( n+2 i-1 (mod 2 m ) )  Így minden n azonosítójú peernek az első bejegyzése: successor(n) Egy k érték keresése:  Minden routolási táblázatunkban szereplőnek továbbítjuk, aki közelebb van (valamilyen metrika szerint) k-hoz, mint mi  Ha ilyet nem ismerünk, megnézzük nem tároljuk-e mi a keresett adatot  Ha nálunk van visszajelzünk a keresőnek N peer és log(N) routolási tábla esetén: O(log N) keresés (N'=2*N => +1 msg.)!

Csatlakozás, kilépés, rendezés Mivel a hálózat folyamatosan változik (peerek lépnek be és ki) és minden k hashértékért successor(k) a felelős:  Eltároljuk a predecessor (minket megelőző) peer hashét is  Belépéskor értesítjük a minket megelőzőt, hogy már mi vagyunk a rákövetkezője  Rákövetkezőnket értesítjük, hogy már mi vagyunk a megelőzője  Ezek tovább ellenőrzik a routolási tábla helyességét O(log 2 N) üzenetváltás

Felhasználás Tetszőleges metaadat lehet hashelve (filenév, filenév részleteinek különböző variációi (alias-ok), földrajzi elhelyezkedés (Leopard), matematikai feladat részfeladata stb.) Chord, Pastry, Kad, Kademlia (KAD) (XOR metrika, stabil DoS ellen) Nagyon stabil, még ha minden peer meghibásodásának valószínűsége 50% is Coral, Dijjjer: web archívum, cache Azureus (+TOR), FreeNet (+Darknet)

Privacy Erős titkosítások, nem visszakövethető routolás (Onionroue) Még a hálózat beindítóinak sincs hatalmuk (de még információjuk se) a működésről, tartalomról Nem beszüntethetőek De:  Rossz kereshetőség (csak majdnem pontos találatra)  Nincs garancia az egyszer feltöltött adatok meglétére, se megtalálhatóságára  Különböző erős kreditrendszerek

Onionroute, Darknet V >A: ( A to B( B to C ( C to D ( D to W ( W hi I'am V)))) RSA Small World Network SOCKS interface Komoly probléma felügyeleti szerveknek

Általános p2p API Több meglévő rendszer rendelkezik API-val, de legtöbb túlságosan szűk keretek közé szorítja a felhasználót A részproblémákra született különböző megoldások közül nem lehet külön-külön választani Kevés a kernel-szintű kötési lehetőség, nem lehet mountolni a hálózatokat

Kritériumrendszer megbízhatóság/authentikáció routolás privacy/névtelenség stabilitás minden(ki) legyen hatékonyan elérhető stabil, hálózatszakadásmentes idő sávszél lépésszám biztonság kódolás kliensekre ne jelentsen veszélyt bővíthetőség, specializáció, integrálhatóság „igénytelen” és okos: a klienseknek a hálózattal szemben lehető legkisebb igényeket támasszák, ugyanakkor önmagukban, a többiek ismerete nélkül képesek legyenek egy előre meghatározott algoritmus alapján használni és együttműködni

Csatlakozás csatlakozó (s kulcspár) tag (passport) hálózat (route) authentikátor (auth kulcspár,hálózat fejléc, hálózat fejléc auth része külön, passport) s pubkulcs, hálózat pubkulcs s privkulccsal aláírt checksum ha ez a művelet engedélyezett számára, passporttal hálózat fejléc auth része hálózat privkulccsal áláírt checksummal, amiben benne van, hogy mi az authpubkulcs, valamint k ideiglenes pubkulcs auth privkulccsal aláírva, s pubkulccsal titkosítva passporttal ellátava ha passport rendben, meg is érkezik tag-on keresztül (nat, tűzfal megkerülve, hátha csak tag-on keresztül jó a csatlakozónak) ha rendben, saját user/pass ill. metaadat auth. pubkulccsal majd saját privkulccsal, majd ideilenes pubkulccsal titkosítca Megj.: Az összes üzenetváltás valamilyen crypto tunnel felett! ha rendben, passport auth privkulccsal alárva, s pubkulccsal majd ideiglenes privkulccsal titkosítva passporttal ellátott join üzenet