A torrent protokoll lényege, hogy elválasztjuk egymástól a tényleges tartalmat, a metaadatokat, és a felhasználókat összekötő hálózatot. A metaadatok leírására szolgálnak a torrent fájlok. Ezek nagyon egyszerű felépítésű állományok, tartalmazzák a tartalom megnevezését, a fájl egyedi azonosítóját (hash), a tracker szerverek címeit (erről mindjárt írok) és még néhány adatot. A nagy torrent oldalak tulajdonképpen nem tesznek mást, mint ilyen torrent fájlokat gyűjtenek egy helyre, indexelik, és kereshetővé teszik ezeket. Amikor letöltünk egy torrent fájlt és elindítjuk kedvenc torrent kliensünkben, a kliens végigfut a fájlban lévő trackerek listáján, és a tartalom egyedi azonosítója (hash) alapján lekérdezi azokat az IP-ket, ahol a tartalom elérhető. A tracker tehát egy egyszerű interfésszel rendelkező kis adatbázis, ami azt tárolja, hogy egy adott tartalmat az adott pillanatban kik osztanak meg. Ha megvan az IP címek listája, a kliensek direkt módon egymáshoz kapcsolódhatnak, és megkezdődhet a letöltés. Az architektúrából jól láthatóak annak gyenge pontjai. Az egyik gyenge pont a torrent fájlok, és az azokat nyilvántartó szerverek, a másik pedig a trackerek. Mivel torrent fájlokat elég egyszerű szétszórni a neten (keresésre meg ott a jól megszokott Google), az ezek elleni küzdelem elég nehézkes. Persze a nagy torrent keresők bezárásával azért meg lehet nehezíteni a felhasználók dolgát, amit viszont inkább támadni lehet az a trackerek rendszere. Ha leállítják a tracker szervereket melyre a torrent fájl hivatkozik, a fájl használhatatlanná válik. Az igazi gyenge pont tehát ezeknek a tracker szervereknek a léte, amik a struktúra centralizált jellegét adják. A megoldás tehát olyan architektúra lehet, ahol ezeket a rendszereket decentralizált megoldások váltják fel. De milyen módon építhető fel egy ilyen decentralizált rendszer?
A megoldás, amire én jutottam, szinte adja magát. Egy baráti közösségben ha meg akarok szerezni mondjuk egy ritka zeneszámot, körbekérdezem a barátokat, hogy kinek van meg. Ha az adott szám nincs meg egyik barátomnak sem, akkor ők is körbekérdezik a barátaikat, azok is az ő barátaikat, és valakinek csak meglesz. Ez az architektúra nagyon hatékony tud lenni, hiszen hálózatelméletből jól tudjuk, hogy a földön két ember között átlagosan 6 lépés a maximális távolság. Tehát tulajdonképpen, ha minden barátom lelkiismeretesen körbekérdezi minden barátját, legfeljebb 6 lépésből megszerezhetem amire szükségem van. Ha ezt az architektúrát képezzük le a weben, máris egy nagyon hatékony decentralizált architektúrát kapunk, amit szinte lehetetlen megbénítani. De lássuk hogy nézhetne ki ez a gyakorlatban.
Az első alapvető probléma, hogy hogyan szólítsuk meg a barátainkat. A probléma az, hogy a weben beazonosítani valakit nem olyan egyszerű, ugyanis az egyetlen azonosítónk az IP cím, ami egy általános netszolgáltatónál gyakran változik. Köthetünk DNS-t a címhez, de ez bonyodalmas. Van viszont egy mára már általánossá vált megoldás arra, ha el akarjuk érni a másikat, ez pedig az IM (Instant Messenger) rendszerek használata. Ilyen az MSN, az ICQ, a Google Talk, de tulajdonképpen ide sorolhatjuk az IRC-t is. Ezekben a rendszerekben a felhasználónak van egy jól azonosítható neve, ami alapján megszólíthatjuk őt, így ezekre építve kialakítható a fenti hálózati struktúra. Lássuk hogyan.
Ha valaki egy állományt keres, szétküld egy keresési parancsot az ismerősei között. A parancs tartalmazza a keresési mintát (a tartalom címe), egy egyedi azonosítót, és egy timestamp-et, tehát valahogy így néz ki:
#search [kereső kifejezés] [id] [timestamp]
Például:
#search "Nyolcadik utas a halál" 1234 12344567
A kereséshez tehát egy ilyen szöveges üzenetet kell elküldeni valamilyen IM csatorna (akár többet is kombinálva) használatával az ismerősöknek. Az ismerősök a parancs alapján keresést végeznek saját adatbázisukban, és amennyiben találnak egy a kereső kifejezésnek megfelelő állományt, visszaadják az állomány hash-t, valamint az IP címet. Ezzel tulajdonképpen egyszerre valósul meg a tracker és a torrent kereső funkcionalitás. Egy válasz üzenet valahogy így nézne ki:
#found [id] [hash] [ip]
Például:
#found 1234 aba123 12.34.56.78
A válasz üzenet tehát tartalmazza a keresés azonosítóját (erre azért van szükség, mert egyszerre akár több keresést is indíthatunk, és valahogy azonosítani kell, hogy egy találat üzenet melyik keresés üzenetre érkezett), a hash-t, és az IP-t. A hash és az IP ismeretében pedig megindulhat a letöltés. Persze a működés itt nem áll meg, hiszen az ismerős továbbítja a kereső kifejezést az ő ismerősei felé, és ha tőlük kap egy találat üzenetet, azt pedig felénk továbbítja. Ezzel a megoldással néhány perc alatt az üzenet bejárhatja az egész hálózatot, és megkapjuk azon felhasználók (IP-k) listáját, akiknél megtalálható a keresett állomány. A #found üzeneteket hash alapján csoportosítva tehát egy listát kapunk arról, hogy milyen kifejezésre illeszkedő állományok vannak a rendszerben. Az üzenetcsomagok továbbítása folyamán egyetlen dologra kell odafigyelni, mégpedig, hogy ne alakuljanak ki végtelen hurkok. Ekkor jut szerephez a keresés timestamp része. Egy keresés bizonyos idő elteltével (pl. 10 perc) lejár. Ha egy node ilyen lejárt keresést kap, egyszerűen eldobja, így az üzenet nem keringhet a végtelenségig a hálózatban. A másik védelmi mechanizmus, hogy a node-ok egy listát vezetnek a rajtuk átfutó kérésekről id alapján. Egy keresés addig marad a listában, amíg aktív. Ha a node kap egy keresési parancsot, ellenőrzi, hogy válaszolt-e már rá (id alapján bent van-e a listában). Ha igen, eldobja a kifejezést, így kivédve, hogy többször is válaszoljon ugyanarra a kérésre. A rendszer vizuálisan kb. ugyanúgy jelenne meg, mint a jelenlegi torrent rendszerek. Indítást követően a kis IM robotok feljelentkeznének a megfelelő hálózatokra, amiből a felhasználó semmit nem érzékel. Ha egy fájlra van szüksége, kiadja a keresési parancsot, majd várja, hogy összegyűljenek a seederek, és letöltődjön az állomány. A különbség annyi, hogy itt vannak partnerek, amik kicsit a meghívásos hálózatokra emlékeztetnek. Új partnereket az IM rendszerekhez hasonló módon lehetne hozzáadni. Egy ilyen architektúrát szinte lehetetlen megbénítani, hiszen ehhez kontrollálni kellene az összes IM hálózatot, ami lehetetlen. Maga a protokoll pofon egyszerű, a megvalósítás sem bonyolult. Az IM üzenet küldésre ott a libpurple programkönyvtár, amit többek közt a Linuxos körökben jól ismert Pidgin is használ, a p2p fájláttöltésre pedig használható a torrent kliensekben eddig is jól működő mechanizmus.
Az én tippem szerint a jövőben valami ehhez hasonló "szociális" útra lép a fájlmegosztás, a jogvédők pedig újra vakarhatják a fejüket, hogy hogy állítsák meg a folyamatot. Talán nem is a rendszer támadása a legjobb megoldás, de ez már egy másik történet ...