P2P fájl transzfer

Adott egy szerveren néhány bitang nagy (10+ GiB) fájl. Ezeket el kellene juttatnom 300+ darab kliensre. Eddig multicastot használtam, azonban a hálózati topológiában bekövetkezett változás miatt ez már nem járható út a továbbiakban.

Adott tehát az, hogy valami P2P technológiát kellene bevetni. A kliensek között gigabites hálózat van, a szerver felé pedig szűk a cső. A dolognak tehát úgy kellene működni, hogy a kliensek elkezdenek letölteni fájlszegmenseket a szerverről, és helyben továbbosztják a többieknek.

A klienseken egy minimális Linux-alapú beágyazott környezet van. (Nem OpenWRT, de kb. olyat képzelj el.)

Keresem tehát azt a szoftveres eszközt, ami erre képes. Szempontok:
- Kis méretű (max. 1-2MiB) kliens, minimális external library függőséggel)
- Nem-interaktív, scriptelhető
- Képes intelligensen lekezelni azt a szituációt, hogy indításkor egyik kliensen sincs meg a fájl, tehát úgy kell a szerverről hozni az adatokat, hogy lehetőség szerint minden kliens más szegmenst töltsön először, hogy legyen mit továbbosztani a többieknek.
- A szerveren a trackelés minimális változtatást igényeljen. (Jelenleg ~LAMP környezet van)

Külső Internet kapcsolat nincs! Házon belül kell megoldani mindent!

Kinek milyen bevált megoldásai vannak erre?

[UPDATE]

Jelenleg ott tartok, hogy:

- felraktam egy OpenTracker-t (mert értem én, hogy DHT-val nem kell feltétlenül tracker, de egyelőre jobban tetszik a koncepció, hogy van tracker)

- próbálok seedelni "transmission-daemon"-nal

Most ott akadok el, hogy a "transmission-daemon" csak a neki "download-dir"-ként megjelölt könyvtárból hajlandó seed-elni, annak alkönyvtárából nem. Ez nekem nem jó, mert egy meglévő könyvtár-hierarchiából akarok egyes fájlokat seed-elni, tehát nem önthetek össze mindent egy könyvtárba. (Nem, linkelni sem akarom egy helyre.)

Hozzászólások

Kliensnek en az LFTPt neznem meg a helyedben. Ja es persze torrent.

Kösz, nézem az LFTP-t.

Kérdések: (sosem használtam bittorrentet)

- Ha jól értem, nem elég a szerveren elindítanom egy torrent klienst seedelésre, hanem mellé egy trackert is kell telepítenem/indítanom, ugye? (Magyarul, a torrent kliens nem tud tracker is lenni egyszerre?)

- Ha megosztok egy fájlt, akkor generál hozzá egy magnet linket. Ha egy másik torrent kliensbe beírom a magnet linket, nem tudja, hogy merre induljon el, gondolom meg kell neki adni egy trackert is a magnet linken felül, jól értem?

- Ha van egy könyvtár-struktúrám, amit meg akarok osztani fájlonként önállóan, azt hogy kell megoldani? Ha az lftp-nek megadok egy könyvtárat, akkor az egész hierarchiához 1 darab magnet linket ad. Gondolom, nekem az kéne, hogy minden egyes fájlhoz legyen egy magnet linkem?

- Mi van akkor, ha megváltoztatom a megosztott könyvtár tartalmát? (Új fájl hozzáadása, meglévő eltávolítása) Hogyan kell "újraindexelni" a tartalmat?

Ha jól értem, nem elég a szerveren elindítanom egy torrent klienst seedelésre, hanem mellé egy trackert is kell telepítenem/indítanom, ugye? (Magyarul, a torrent kliens nem tud tracker is lenni egyszerre?)

Nem kell tracker, elég mindegyik gépre egy-egy torrentkliens.

1. Létre kell hoznod az adott állományhoz szükséges metafájlt azon a gépen, ahol az átvinni kívánt állomány van.
2. Töltsd be a metafájlt a többi kliensbe.
2. Engedélyezd a kliensekben a DHT-t.
3. Engedd át az egyes gépek tűzfalán azt a portot, amit az adott kliens használ.

Ezek után az átvitel el fog indulni.

Van olyan, hogy bittorent sync, sokat nem tudok róla, lehet hogy egy rápislantást megér.

torrenten superseednek hivjak azt a ficsort, amikor csak egyvalakinek van meg a teljes cucc, a letoltok meg mindig mas reszt kapnak meg a fajlbol, amit aztan ok tudnak tovabb osztani.

transmissionnak tudsz hozzaadni kezzel peert, de keress egy minimal trackert aztan azzal oszt.

de p2p-vel is 300*10G lesz az ossz halozati forgalom, erdemesebb lenne ahol mukodik a multicast ott tovabbra is azt hasznalni. es csak a problemas helyeken p2p-t.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

> transmissionnak tudsz hozzaadni kezzel peert, de keress egy minimal trackert aztan azzal oszt.

Felraktam egy OpenTracker-t.

> de p2p-vel is 300*10G lesz az ossz halozati forgalom

Az nem baj, a helyi switchelt LAN-on elfér az unicast forgalom, a szerver van "messze" - 4-6 hop távolságra, és az arrafelé menő uplink kapcsolatot nem akarom eltömíteni.

> Tehát a helyi LAN-on van egy dedikált seeder, aki letölti a servertől, majd a helyiek tőle.

Végsősoron igen, de nem feltétlenül. Az előnyös lenne, ha nem kellene feltétlenül olyan dedikált seeder, akinek megvan az egész fájl egyben. Tehát: elindítok mondjuk 30 klienst, mindenki hoz valami random szegmenst a szerverről, majd onnantól kezdve a többiek már tudják hozni az adott szegmenst a szerverről IS és az éppen illetékes helyi peerektől IS. Ezzel nem minimalizáltuk a forgalmat a szerver felé, viszont nem tettük szükségessé azt, hogy helyben valakinek teljes egészében meglegyen. (Az igazán szép az volna, ha lehetne hátrébb priorizálni a szervert, tehát ha valakinek megvan helyben, akkor onnan töltse a másik, ne a szerverről)

> Innentől miért nem jó a multicast?

Pl. a helyi hálózatba bekerült néhány nem-menedzselt, IGMP-képtelen switch.

DHT es nem kotelezo a tracker.
rtorrent siman megfelel erre, auto load konyvtar beallit.
tftp ha van akkor azzal szettudod lokni a klienseknek a kezdo filet.

http://karikasostor.hu - Az autentikus zajforrás.

Jelenleg ott tartok, hogy:

- felraktam egy OpenTracker-t (mert értem én, hogy DHT-val nem kell feltétlenül tracker, de egyelőre jobban tetszik a koncepció, hogy van tracker)

- próbálok seedelni "transmission-daemon"-nal

Most ott akadok el, hogy a "transmission-daemon" csak a neki "download-dir"-ként megjelölt könyvtárból hajlandó seed-elni, annak alkönyvtárából nem. Ez nekem nem jó, mert egy meglévő könyvtár-hierarchiából akarok egyes fájlokat seed-elni, tehát nem önthetek össze mindent egy könyvtárba. (Nem, linkelni sem akarom egy helyre.)

én kidobnám a hálózatból az igmp-tlen switcheket és vetetnék megfelelő switcheket vagy multicast-képes routereket, ne a hálózati eszközökön való spórolás szívasson.