Az előadás letöltése folymat van. Kérjük, várjon

Az előadás letöltése folymat van. Kérjük, várjon

Elosztott adatbázisok és peer- to-Peer (P2P) Simon Csaba

Hasonló előadás


Az előadások a következő témára: "Elosztott adatbázisok és peer- to-Peer (P2P) Simon Csaba"— Előadás másolata:

1 Elosztott adatbázisok és peer- to-Peer (P2P) Simon Csaba

2 2013. október 16. Miről lesz szó? Mi a P2P? Kell-e nekünk és miért? Struktúrálatlan P2P DHT Elosztott P2P adatbázisok 2

3 P2P

4 2013. október Mi a P2P? P2P - napjaink egyik legforróbb témája Alkalmazások  Kazaa – minden idők legtöbbször letöltött alkalmazása > 300 millió letöltés  Az Internet forgalom 50-70% P2P Nehezen mérhető, az eredmények nem megbízhatóak  FastTrack, eDonkey, iMesh > 7 millió felhasználó (2004. február 8) Felhasználói statisztikák:

5 2013. október P2P (II) Kutatás  3rd IEEE International Conf. on P2P Computing  P2P „Tutorial” és P2P szekció Infocom, Sigcomm, stb.  P2P Research Group IRTF (Internet Research Task Force) Internet2 Stanford, Berkeley, stb.

6 2013. október Definíció Peer–to–Peer (P2P):  egy alkalmazáscsoport mely kihasználja az Internet peremén levő felhasználók erőforrásait: Tárolás – merevlemez kapacitás CPU – számítási kapacitás Tartalom – adatok, informaciók megosztása Bármilyen más megosztható erőforrás, szolgáltatás, funkció Egy alkalmazás rétegbeli Internet a fizikai Internet topológia fölött

7 2013. október Definíció (II) „Peer-to-peer network” = egyenrangú hálózat  „Peer” = veled egyenrangú felhasználó „Kommunista” rendszer – mindenki egyenlő A kliens-szerver architektúra ellentéte

8 2013. október Ádámtól Ádámig A. Oram, editor. Peer-to-Peer : Harnessing the Power of Disruptive Technologies. O'Reilly & Associates, 2001.

9 2013. október Jellemzők Minden résztvevő peer egyszerre kliens és szerver Nincs központi vezérlés Nincs központi adatbázis Senkinek nincs globális képe a hálózatról A rendszer globális működése a lokális kölcsönhatások eredménye

10 2013. október Jellemzők (II) Bármilyen megosztott erőforrás elérhető bárki által Akkor férhetsz mások erőforrásaihoz, ha megosztod a sajátaidat A peer-ek függetlenek egymástól A peer-ek és a kapcsolatok alapvetően megbízhatatlanok  Gyakori be- és kilépés

11 2013. október Mire jó? P2P ≠ fájlcsere Sokminden más:  Elosztott adatbázisok  Elosztott számítás (distributed computing)  Elosztott hálózati szuperszámítógépek (grid computing)  Instant Messaging  CSCW (Computer Supported Cooperative Work)  Vezetéknélküli ad-hoc hálózatok  Alkalmazás rétegbeli multicast szolgáltatás  E-commerce, e-business alkalmazások  Stb, stb, stb....

12 2013. október Miről lehet beszélni P2P kapcsán? WinMX FastTrack iMesh CAN Chord Pastry Tapestry LimeWire Grokster BitTorrent eDonkey eMule SoulSeek IRC MP2P Piolet RockitNet Blubster BearShare Shareaza Morpheus eBay Mojo Nation Jxta OceanStore Farsite Jabber Napster Kazaa Gnutella Freenet ICQ OverCast Yoid

13 2013. október Pontosabban... Visszatekintés  „korabeli” P2P rendszerek Usenet, DNS, Telnet, FTP  az Internet átalakulása  az új generációs P2P rendszerek megjelenése A P2P hálózatok sajátosságai:  Szolgáltatás felderítés, topológia felépítés  Keresés, útvonalválasztás  Hozzáférhetőség, megbízhatóság  Biztonsági kérdések

14 2013. október És még... P2P architektúrák:  Központosított rendszerek – Napster  Elosztott, sík rendszerek – Gnutella  Hierarchikus topológiák – Kazaa  Más fájlcserélő alkalmazások – BitTorrent, stb. Elosztott hash táblákra (DHT) alapuló keresők:  CAN, Chord, Pastry, Tapestry

15 2013. október 16. P2P hálózatok 15 Továbbá... Alkalmazás rétegbeli multicast P2P hálózatokon  A csoportos kommunikáció sajátosságai  A hálózati rétegbeli multicast rövid attekintése  Alkalmazás rétegbeli multicast Háló-alapú (mesh-first) módszerek – Narada, Gossamer Fa-alapú (tree-first) módszerek – HMTP, TBCP, Yoid, Overcast, ALMI Implicit módszerek – CAN-Multicast, Scribe, Bayeux, NICE Pletykára alapuló járványszerű átvitel – SCAMP, SWIM, Bi-modal multicast

16 P2P és elosztott adatbázisok

17 2013. október 16. Hypothesis End 2 End arguments in network community  Implement a feature on upper layer as much as we can to have easier deployment for Internet Fast development of applications  Moore law in computer hardware Relatively slow change in Internet core  Not too many industrial researchers who work on core networking. (http://www.icir.org/floyd/talks/NSF-Jan03.pdf)

18 2013. október 16. Key problem: Location and Routing Hard problem in a system like this:  Locating and messaging to resources and data Goals for a wide-area overlay infrastructure  Easy to deploy  Scalable to millions of nodes, billions of objects  Available in presence of routine faults  Self-configuring, adaptive to network changes  Localize effects of operations/failures

19 2013. október 16. The promise of P2P computing Reliability: no central point of failure  Many replicas  Geographic distribution High capacity through parallelism:  Many disks  Many network connections  Many CPUs Automatic configuration Useful in public and proprietary settings

20 2013. október

21 2013. október 16. DHT implementation challenges 1. Scalable lookup 2. Balance load (flash crowds) 3. Handling failures 4. Coping with systems in flux 5. Network-awareness for performance 6. Robustness with untrusted participants 7. Programming abstraction 8. Heterogeneity 9. Anonymity 10. Indexing Goal: simple, provably-good algorithms Chord

22 2013. október 16. Pond JNI for crypto, SEDA stages, 280+kLOC Java

23 23 Strukturálatlan P2P

24 2013. október Visszatekintés A P2P nem egy új ötlet A kezdeti Internet peer-to-peer volt ARPANET - Advanced Research Projects Agency Network  1969 – US Department of Defense (DoD) University of California at Los Angeles (UCLA) Stanford Research Institute (SRI) University of California Santa Barbara (UCSB) University of Utah  Különböző operációs rendszerek, egyenrangú felhasználók

25 2013. október A kezdeti hálózat

26 2013. október es évek újabb és újabb egyetemek, kutató laboratóriumok csatlakoznak TCP/IP kidolgozása Telnet, FTP

27 2013. október ARPANET

28 2013. október as évek – IP az ARPANET-en 1984 – MILNET (DoD) 1986 – NSFNET  NSF – National Science Foundation 1990 – Az ARPANET bezár

29 2013. október MILNET

30 2013. október Irodalom A History of The Internet: 1962 – 1992  Hobbes' Internet Timeline  The Request for Comments Reference Guide  History of Arpanet 

31 2013. október A kezdeti hálózat Egyenrangú felhasználók Bármely két gép képes volt kommunikálni egymással Egy nyított és szabad rendszer  Tűzfalak nem léteztek a 80-as évek végéig Egyetemi kutatók „játszótere” Biztonsági gondok nem léteztek...

32 2013. október Az első P2P alkalmazások Telnet, FTP  Nem „vérbeli” P2P alkalmazások  Szigorúan nézve, kliens/szerver rendszerek Egy Telnet kliens bejelentkezik egy szerverre Egy FTP kliens fájlokat küld / tölt le egy FTP szerverről  De... Bárki lehetett kliens is, szerver is Szimetrikus rendszer

33 2013. október Usenet A mai P2P alkalmazások nagypapija...  Központi vezérlés nélkül fájlokat másol gépek között 1979  Tom Truscott, Jim Ellis  University of North Carolina, Duke University  3 gépből álló hálózat Unix-to-Unix Control Protocol (UUCP)  Egy UNIX gép automatikus felhívott egy másik gépet  Fájlokat cseréltek  Megszüntették az összeköttetést Levelek, fájlok, programok cseréje

34 2013. október Usenet (II) Csoportok különböző témakörök körül  Newsgroups A helyi felhasználók a helyi newsgroup „szerverre” csatlakoznak A szerverek periodikusan kicserélik információikat  Egy felhasználó üzenete minden érdeklődőt elér A szerverek egy P2P hálózatot alkotnak

35 2013. október Usenet (III) A hálózat ma hatalmas  Több ezer szerver  Több tízezer témakör  Több millió felhasználó A rendszert skálázhatóva kellett tenni  Egy szerver csak bizonyos csoportokra iratkozik fel  A szerverek csak az üzenetek fejlécét továbbítják  Ha valaki kiváncsi, lekéri a teljes üzenetet  Korlátozott időtartamú tárolás

36 2013. október Usenet - jellemzők Elosztott rendszer Nincs központi vezérlés Egy új témacsoport létrehozása  Demokratikus szavazás alapján  Javaslat küldése a news.admin csoportnak  Vita, szavazás Bárki szavazhat -ben  Ha elfogadják, a szerverek elkezdik terjeszteni Megengedett anarchia  Szavazás nélkül nyitható egy alt.* csoport

37 2013. október Usenet Network News Transport Protocol (NNTP)  TCP/IP alapú Optimalizált elárasztás  Útvonal az üzenetek fejlécében  Egy szerver csak egyszer kap meg egy üzenetet Sok új P2P rendszerből hiányzik  Gnutella

38 2013. október Usenet fájlcsere Eredetileg csak text fájlok cseréje Bináris fájlok átalakíthatóak Gond – túl hosszú fájlok  700 Mb film – 15 millió sor  Szerver korlátok – soros üzenetek Több részre vágott fájlok

39 2013. október DNS Domain Name System  Hierarchikus információs rendszer  Fájlmegosztásra találták ki (1983) hosts.txt

40 2013. október IP útvonalválasztás IP útvonalválasztók (routerek) peer-ek Felfedezik és fenntartják a topológiát Egy router nem kliens és nem szerver Folyamatosan kommunikálnak egymással Függetlenek egymástól

41 2013. október Aztán robbant a Net Robbant a felhasználók száma Tudományosból kereskedelmi hálózat Biztonsági intézkedések váltak szükségessé  Tűzfalak Megjelentek az otthoni felhasználók  Egy modemes csatlakozó nem volt többé egyenrangú Elfogytak az IP címek  Dinamikus IP címek, NAT Megjelent a Web  Új kommunikációs szokások (webkliens – webszerver)

42 2013. október Mégis P2P? Újabb fordulat a kommunikációs szokásokban  Elkülönül a „szerző” és a „forgalmazó”  Nem csak a saját maguk által készített adatokat (pl. weboldal) osztják meg a felhasználók MP3 – mérföldkő a P2P tekintetében  Lehetővé válik a zenefájlok cseréje  DivX kódolás 1999-ben megjelenik a Napster

43 Napster 43

44 2013. október Napster Kronológia  1999 május – Shawn Fenning és Sean Parker megalapítják a Napster-t  1999 december – a RIAA elindítja az első pert a Napster ellen Recording Industry Association of America (RIAA)  2000 április – Előbb a Metallica, majd Dr. Dre perlik a Napster-t  2000 július – A bíróság felszólítja a Napster-t a bezárásra  2001 február 12 – A bíróság a megosztott fájlok szűrésére kötelezi a Napster-t  2001 február 20 – 1 milliárd dolláros ajánlat a lemezcégeknek  2001 március 2 – Bevezetik a szűrőket, a felhasználók elpártolnak

45 2013. október Napster Módosítás – fizetős változat  $9,95 – havi bérlet  ¢ 99 – egy fájl  Apple – iTunes 

46 2013. október

47 2013. október 16. P2P hálózatok47 Boldog zenészek?

48 2013. október 16. P2P hálózatok48 Egy CD költségei

49 2013. október A Napster működése Nem „igazi” P2P rendszer  Központi szerver tárolja a megosztott fájlok listáját  Keresés a központi szerveren  Közvetlen letöltés a peer-ek között

50 2013. október 16. P2P hálózatok50 Példa 1. Bejelentkezés (Alíz, Fájl lista) 4. Közvetlen letöltés 3. Alíztól kérd 2. Keresem a ricky.mp3 fájlt Napster szerver Alíz Barbara

51 2013. október A Napster jellemzői Hátrányok:  Rossz skálázhatóság Szerverfarmon belüli terheléselosztás  A szerver szűk keresztmetszet  Könnyen perelhető  Titkosság hiánya  Freeriding lehetőség Előnyök  Gyors keresés  Ismert topológia

52 DC++ 52

53 2013. október DirectConnect Központosított rendszer  Több száz hub Korlátozott belépés  Megosztott tartalom mérete (több Gb)  IP címtartomány  Hozzáférési sebesség Neo Modus DC 

54 2013. október DC++ Nyílt forrású (open source) kliens DirectConnect hálózatot használja Előnyök  Barátságosabb GUI  Több hub-os párhuzamos csatlakozás, keresés  Spyware, adware kiiktatva DC++  

55 2013. október eDonkey Központosított hálózat  286 magán szerver  A szerverek nem kommunikálnak egymással Több szerverre lehet feliratkozni egyszerre  server.met – a szerverek IP címlistája  Folyamatosan kell frissíteni Elosztott letöltés  Megosztáskor egy hash-t (azonosítót) csatol a fájl-hoz  A szerver tárolja a hash-eket  Kereséskor egy listát kapunk a lehetséges peer-ekről  A fájl darabjait külön helyekről, párhuzamosan tölthetjük le

56 2013. október eDonkey Kliens X ricky.mp3 (abcdefg) Kliens Y ricky.mp3 (abc) Kliens Z ricky.mp3 (fg) Kliens W ricky.mp3 () ricky.mp3 (a) ricky.mp3 (g) ricky.mp3 (b) ricky.mp3 (d)

57 2013. október eMule Népszerű eDonkey kliens Open source változat Nincs spyware, adware 

58 Gnutella 58

59 2013. október Gnutella Kronológia  2000 március 14 – Justin Frankle, Nullsoft (winamp) Eredetileg „receptek cseréje” volt a cél GNU General Public License - Nullsoft web szerver  Pár óra után az AOL letiltotta  Több száz példányt már letöltöttek  Kód-visszafejtés (reverse engineering) segítségével  Több új kliens jelent meg

60 2013. október Gnutella Elosztott rendszer, központi szerver nélkül (v0.4) Elárasztás alapú keresés Minden peer...  Megoszt állományokat  Továbbítja a szomszédai felé a kapott Query csomagokat  Válaszol a Query üzenetekre, ha rendelkezésére áll a keresett fájl

61 2013. október Gnutella Keresés Válasz

62 2013. október Gnutella fejléc Byte 0 – 15 : Message ID  Egyéni azonosító  V 0.6 – Byte 8: , Byte 15: Byte 16 : Function ID  Az üzenet tipusa Byte 17 : TTL (Time To Live)  Hányat ugorhat még Byte 18 : Hops  Hányat ugrott már Byte 19 – 22 : Payload Length  A fejléc utáni adatrész hossza  Max csomag hossz: 4 kB

63 2013. október Üzenettipusok Function ID  0x00 Ping : peer-ek keresése a gnutella hálózaton  0x01 Pong : válasz egy Ping-re IP cím, port, megosztott fájlok száma, megosztott könyvtár mérete  0x80 Query : keresés indítása Keresési kritérium (szöveg), minimum sávszélesség  0x81 Query Hit : válasz találat esetén IP cím, port, sávszélesség, fájl név, fájl hossz  0x40 Push : „feltöltés” kérése egy tűzfal mögül Kért fájl adatai, cél IP cím/port

64 2013. október Előnyök Robusztusság, nincs szűk keresztmetszet Egyszerűség Jogilag nehezen támadható  Nincs perelhető központi entitás

65 2013. október Hátrányok Az elárasztás nem skálázható megoldás  TTL-t használva (valamilyen szinten) áthidalható  Nem minden szomszédnak küldjük tovább az üzeneteket  A Message ID alapján, egy üzenetet csak egyszer továbbít egy peer  Egy peer többször megkaphat egy üzenetet

66 2013. október Többszöri kézbesítés

67 2013. október Hátrányok (II) Nagy hálózati forgalmat generál Példa:  4 link L / peer  TTL = 7  Max csomag szám: csomag

68 2013. október Hátrányok (III) A keresés időtartama nem behatárolható A keresés sikerének valószínűsége nem ismert A topológia ismeretlen, az algoritmusok nem tudják felhasználni A peer-ek „hírneve” nincs figyelembe véve Freeriding...

69 2013. október Freeriding Adar, Huberman, Freeriding on Gnutella, 2000 Sept.   24 órás mérések:  a kliensek 70%-a nem oszt meg semmit  a válaszok 50%-át a peer-ek 1%-a szolgáltatja Társadalmi, és nem technikai probléma Következmények  A rendszer hatákonyságának romlása (skálázhatóság?)  A rendszer sebezhetőbb  „Központosított” Gnutella – jogi problémák

70 2013. október Freeriding (II) Mérések elemzése  A felhasználók nagy hányada freerider  A freerider-ek egyenlően oszlanak el a hálózatban  Bizonyos peer-ek olyan fájlokat osztanak meg, melyek senkit sem érdekelnek

71 2013. október Gondok és megoldások Freeloading:  A Gnutella hálózat elérhető volt weboldalakról  Webes keresés, letöltés, megosztás nélkül Megszakadó letöltések  Hosszú letöltési idők a modemes hozzáférés miatt  Csak rövid ideig futtaták a gnutella kliens-t (keresés ideje) Megoldás:  „Nálam van, de foglalt vagyok. Próbalkozz kesőbb”  2000 végén – letöltések 10%-a sikeres  2001 – a letöltések 25%-a sikeres  Megoldás?

72 2013. október Gondok és megoldások Kis méretű elérhető hálózat  2000: átlagosan elérhető peer  Modemes felhasználók – kis sávszélesség a keresések továbbítására routing black holes Megoldás:  Peer hierarchia kialakítása  Csatlakozási preferenciák  Nagy sávszélességű peer-ek előnyben  Nagyméretű megosztott állománnyal rendelkezők előnyben Gnutella v0.6 és más hierarchikus rendszerek

73 2013. október 16. P2P hálózatok73 Irodalom

74 KaZaa 74

75 2013. október KaZaa A jelenleg legelterjedtebb P2P alkalmazás  A FastTrack hálózatot használja  4 millió felhasználó  3,000 terabyte megosztott adat  > 50% az Internet forgalmának Leginkább az USA-ban népszerű A RIAA legnagyobb célpontja  30-40% csökkenés 2003 végén

76 2013. október Kronológia Niklas Zennström ötlete  2001 márciusa - Jaan Tallinn, Ahti Heinla és Priit Kasesalu  FastTrack, KaZaa - fejlesztés Észtországban  Holland cég megbízása – KaZaa BV 2001 – Sharman Networks megveszi a FastTrack-et  Székhely: Vanuatu - sziget a Csendes Óceánban  Titkos igazgatótanács, titkos részvényesek Kazaa.com – LEF Interactive, Ausztrália  LEF – Liberté, Egalité, Fraternité  Alkalmazottak mindenhol a világban, nehezen fellelhetők

77 2013. október KaZaa vs. RIAA Nemzetközi macska-egér játék  Az amerikai jog nem érvényes máshol  Nincs központi entitás, nincs kit perelni Megoldások?  (Amerikai) felhasználókat perelni?  Denial-of-Service (DoS) támadások  Vírusok a rendszerben Hash linkekkel elkerülhetőek Weben keresztül megszerezhető hash-ek

78 2013. október Architektúra Hierarchikus architektúra  A peer-ek egy supernode-hoz csatlakoznak supernode = supernode, hypernode  A supernode-ok egyenrangúak  A supernode ismeri a hozzá tartozó peer-ek IP címeit, és a megosztott fájl-ok listáját Mini Napster/Gnutella hub

79 2013. október Architektúra (II) Titkos forráskód  Kód visszafejtés: peer – supernode kommunikáció  A supernode – supernode kommunikáció alig ismert Egy supernode ismer sok más supernode-ot  Majdnem teljes háló (complete mesh) Bárki lehet supernode  Számítási kapacitás, sávszélesség  Automatikus kiválasztás Kb supernode  Kb peer/supernode

80 2013. október Supernode választás Lehetséges supernode-ok IP címei az alkalmazás letöltésekor Csatlakozás után egy működő supernode keresése Aktuális supernode lista letöltése Ping 5 supernode felé Választás a legkisebb RTT alapján  RTT = Round Trip Time Ha a supernode „meghal”, új választás

81 2013. október Keresés Kulcsszó alapján  A felhasználó beállítja max. hány találatot vár (x) A keresést a supernode-hoz küldi  Ha a supernode-nál van x találat, vége Ha nincs, a kérést a supernode más supernode-oknak küldi  Ha van x találat, vége Ha nincs, újabb supernode-ok kapják meg a kérést  Valószínüleg a kezdeményező supernode indítja az újabb keresést (nem rekurzív)  Válaszok hullámokban

82 2013. október Kazaa A B Keresem a ricky.mp3 fájlt B-nek megvan Közvetlen letöltés

83 2013. október Párhuzamos letöltés Ha több találat, a felhasználó párhuzamos letöltést választhat  A fájl több részre osztva HTTP byte-range header alapján  különbözö részek különböző peer-ektől Új „szerver” peer választása automatikusan, ha az előző „meghal”

84 2013. október Előnyök Skálázható  Egy központi szerver helyett több ezer supernode  Csak a supernode-ek között történik elárasztás Sorbanállás kezelése  Előnyt élveznek azok, akiktől sokat töltenek le  Hátrány a kis sávszélességgel rendelkezőknek lassan kerülnek kiszolgálásra Jogilag nehezen támadható

85 2013. október 16. P2P hálózatok85 Más hierarchikus rendszerek FastTrack  Kazaa Lite  iMesh  Grokster

86 2013. október Más hierarchikus rendszerek Gnutella v0.6  LimeWire  Shareaza  BearShare  Morpheus

87 BitTorrent

88 2013. október BitTorrent 2002 – Bram Cohen, San Francisco Python kód, open source Népszerű nagyméretű adatok elosztott letöltése  Nincs saját keresőmotor Webes keresés  Nincsenek megosztott könyvtárak  Letöltés közben feltöltés mások számára

89 2013. október BitTorrent Hagyományos webes keresés.torrent fájl  Hash információ  Egy „tracker szerver” címe Tracker  A csatlakozó peer-nek megad egy véletlenszerű listát a lehetséges peer-ekről  Statisztika Hány letöltés Hány peer-nél van a teljes fájl Hány peer-nél vannak fájl részek

90 2013. október BitTorrent Mag (seed)  A kezdeti forrás  Egy peer akinél a teljes állomány megtalálható A fájl több részre osztva  250 kB  Minden rész hash információja a.torrent fájlban  A részek további alrészekre osztva

91 2013. október Alapelvek Párhuzamos letöltés és feltöltés „Leech resistance” – piócák kiszűrése  Minél nagyobb a feltöltési sávszélesség, annál több peer-től tölthetsz le részeket párhuzamosan Megbízhatóság maximizálása  Csökkenteni a sikertelen letöltések esélyét  Bizonyos részek „eltünnek”, a fájl használhatatlan A működés ezen alapelveknek van alárendelve

92 2013. október Hogyan működik? Egy rész teljes letöltése  Ha egy rész egy alrészét letöltjük, a következő alrészek előnyben részesülnek más részek alrészeivel szemben  Gyors letöltést biztosít egy rész számára  Ha a rész teljes, a peer ellenőrzi a hash-t  Ha OK, jelzi a Tracker-nek  A rész feltölthetővé válik mások számára

93 2013. október Hogyan működik? A legritkább legelőbb (rarest first)  Azt a részt tölti le előbb, mellyel a legkevesebb peer rendelkezik Előnyök  Növeli a letöltés globális sikerét Ha az a néhány peer (esetleg az egyedüli seed) „meghal”, továbbra is elérhetőek lesznek a ritka részek  Biztosítja a további feltöltési kéréseket Ha egy ritka résszel rendelkezem, mások tőlem fogják azt kérni Növelem a letöltési sebességem  Növeli a globális letöltési sebességet A seed-től külön részeket kér le minden peer Ugyanazt a részt nem kell többször feltöltenie a seed-nek  Különösen előnyös ha „lassú” seed

94 2013. október Hogyan működik? Véletlenszerű első rész  Ameddig nincs mit feltölteni tőlem, letölteni is nehezen tudok – kevés peer-t ismerek  Cél egy részt minél gyorsabban megszerezni Egy ritka részt lassan tudok letölteni  Kevés peer rendelkezik az alrészekkel  Ha letöltöm, sokan kérik majd, nő a letöltési sebességem Egy népszerű rész letöltése gyors, de nem olyan hasznos  Kevesen fogják majd tőlem kérni  Nem tudom növelni a letöltési sebességem  Megoldás: véletlenszerű választás

95 2013. október Tulajdonságok Lassú indulás Változó letöltési sebesség  Függ a feltöltés alatt álló résszel rendelkezők számától, feltöltési sebességétől Sikeres letöltés után illik az alkalmazást tovább futtatni  Ekkor a peer seed-ként működik

96 2013. október BitTorrent vs. eDonkey Hasonló elveken működnek  Részekre osztott fájlok  Párhuzamos letöltés A BitTorrent-ben csak egy fájl-t töltünk le egyszerre  Nagyobb a rendelkezésre álló sávszélesség minden peer-nél  (Elvileg) gyorsabb letöltés Az eDonkey-ban nincs „piócaszűrés”  A feltöltésből nincs igazán haszna a peer-nek A BitTorrent-ben nincs keresőmotor  A.torrent fájlt weben kell megkeresni  Jogilag könnyen támadható A tracker szolgáltatása, IP címe nyílvános Felelősségre vonható

97 2013. október 16. P2P hálózatok97 Egyszerű interfész

98 2013. október BitTorrent linkek Hivatalos oldal  Protokoll specifikáció  FAQ  Torrent-ek 


Letölteni ppt "Elosztott adatbázisok és peer- to-Peer (P2P) Simon Csaba"

Hasonló előadás


Google Hirdetések