rTorrent és MuSeekD

 ( hajbazer | 2009. január 9., péntek - 15:53 )

A mai napom nagyrészt az rTorrent-tel és a museekd/mucous-sal való szenvedéssel ment el. Az utóbbival lehetett volna ugyanis megoldani, hogy az itthoni linuxos gépem ne csak torrent/emule letöltőgép legyen, hanem soulseek is. Mikor megtaláltam a Museek-et, nagyon megörültem, hogy lám van olyan fejlesztő - ráadásul ugyanaz aki a Nicotine-t is írja - aki nem (csak) a csicsára megy és írt egy konzolos klienst azok számára, akik megelégszenek egy 40W fogyasztású Pentium1-gyel egy több, mint 100W-os grafikus alkalmazásokat is gond nélkül elbíró erőmű helyett.
Tudni kell, hogy ez a Museek dolog egy szerverből (museekd) és egy kliensből (mucous) álló SoulSeek kliens. Hasonlóan mint az aMuled, a minimális erőforrásigényű démon fut a háttérben, letöltöget, a klienssel pedig feladatokat lehet neki adni, pl. letöltéseket berakni.

A probléma gyökere - amit meg is írtam a LinuxQuestions-re - hogy az eredetileg talált Museek Daemon (museek-0.0.040714-2) azon kívül, hogy mindent rendben csinált, nem volt hajlandó keresni a SoulSeek hálózaton. Kiírta, hogy "Searching for: " majd utána egy nagy semmit és természetesen a találati ablakban semmi se jelent meg, hiába vártam rá akár 10 percet is. Miután snifferrel megfigyeltem az adatfolyamot, ami a museekd és a mucous között, illetve a museekd és a központi SoulSeek szerver között zajlik, egyértelműen világossá vált, hogy a keresési kérelem a museekd-n akad fenn. Gondoltam úgyis régi már ez a museekd, 2004-es és annak ellenére hogy én nem hiszek az újabb=jobb ekvivalenciájában, megkíséreltem feltenni egy új verziót.

A Museek+ 0.1.10-essel kezdtem, még reggel, nem volt hajlandó feltelepedni, mert valami ZLIB-et hiányolt. Hiába tettem fel apt-tel az összes olyan csomagot, amelyben szerepel a "zlib" kifejezés, nem volt hajlandó. Délután visszatértem a dologra, gondoltam, megpróbálom egy régebbivel, jött a 0.1.8-as. Ez érdekes módon nem akadt el az elején, viszont nem volt hajlandó lefordulni (fordító szállt el hiábval), biztosan a G++ 3.4 volt neki túl régi. Megpróbáltam egy mégrégebbit, a 0.1.2-est. Ez gond nélkül lefordult és fel is települt, azonban elkezdett Segmentation fault-tal elszállni. Jobban mondva be sem indult, hanem rögtön indításnál meghalt. Hiába írtam hozzá új configot a mellékelt példák szerint, azzal is elszállt. Mindez körül-belül 2-3 órámba telt, mivel meg kellett várni azt is, amíg lefordul és ismerve magamat kijelenthetem, hogy ilyen esetekben nem szoktam elülni a gép elől mást csinálni. Eztuán próbálkoztam még bináris csomagokat feltenni, RPM-eket DEB-bé alakítva alien-nel, majd arch linuxos csomagokat simán felmásolni a gyökérbe, ezalatt szépen lassan beesteledett és most van úgy este tizenegy óra. Feladtam természetesen és amíg nem kapok értelmes választ a fórumokon nem fogom folytatni. Bár inkább utána sem.

Közben csinálgattam az rTorrent-et is, aminek a legújabb verziójában nem lehetett 0 feltöltést beállítani (ellenben 0.7.*-ban igen), azaz, hogy alapból ne töltsön fel a torrent kliens. Érdekes, hogy a fejlesztőknek mindig a final verzió kiadása előtt egy nappal - vagy legalábbis nagyon későn - jut az eszébe, hogy mi van ha valaki kurvára nem akar ismeretleneknek feltöltögetni egy nem regisztrálós oldalon, mivel a többi 10 szálon privát oldalra tölt ahol nagyon is számít az arány és emellett lassú a netje, mert éppen UPC-nél van, amely újabban layer7-tel korlátolja a torrentet + még néha más téren is szarakodik meg drága is ráadásul. Az rTorrent is egy ilyen kliens, alapból ez sem támogatja a torrentenkénti feltöltési sebességkorlát megadását, viszont kitaláltam egy módszert arra, hogyan lehet kijátszani. A maximum feltöltési kapcsolatok számát (max_uploads) nullára kell állítani és így nem fog egyáltalán semmit se feltölteni, holott a 0 elvileg azt jelentené, hogy nincsen korlát, dehát most ez előnyömre vált hogy nem azt jelenti. Persze az rtorrent-en belül ezeket az értékeket már lehet módosítani torrentenként (nem úgy, mint ahogy előbb említettem a sebességet). Így a fontosabb torrentekre adok feltöltést, a nem fontosakra pedig nem. A hátránya annyi hogy ha áramszünet/reboot/stb miatt újraindul a torrent, nem jegyzi meg a beállításokat, így újra be kell állítani. Ez persze csak annyit jelent, hogy nem fog feltölteni. Felvázolva ennyi és az RTorrent belövésével is eltöltöttem vagy másfél órát. Voltak vele bajok, pl. összeakadt a Debian Sarge-os sigc++-2.0-val így sajátot kellett neki forgatni /usr/local -ba. Utána az is számított neki, hogy az LD_LIBRARY_PATH környezeti változóban felsorolom-e az /usr/lib -et, ahol az előbb említett rtorrent által nem kedvelt sigc++-2.0 volt. Ha felsoroltam, Segfault, ha nem, működött. Így kiegészítettem az előző scriptemet egy LD_LIBRARY_PATH bejegyzéssel is.

Leszarom a szóismétléseket és hogy néha nem írtam értelmes mondatokat. Egy ilyen nap után. Fáj a hátam is rohadtul, ennyi ülés ráadásul görbén mert így szoktam meg. Szar az egész úgy ahogy van.

Most elégedetlenkedés következik
Hihetetlen ebben a világban, hogy aki nem a trendet akarja követni és nem a paletta populáris 1%-a jön be neki az szopja meg a faszt mindennel. Ha másban nem, az informatikában így van, nagyonis. Az új szoftverek egyre lassabbak lesznek, a protokollokat újítják, visszafele nem kompatíbilis semmi, ergo fizess ki egy új gépet, fizesd a magas villanyszámlát utána, fogyasszon 3x annyit, ne legyél hatékony, FIZESS, NE LEGYÉL HATÉKONY, mindeközben hidd azt, hogy minden rendben. Vagy megfizetsz máshogy, pl. az időddel (főleg ha nem vagy jó szakember - én nem vagyok, ezek után semmiképpen sem).

Nem összekeverendő ez a bejegyzés az előző rTorrent-essel, az egy teljesen másik gépen, másik környezetben volt.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Nem tudom, en szerveren is screen+bittornado kombot hasznalok, es kezzel inditok mindig hozza egy uj kepernyot ha uj letolteni valo van. Ez igy kisse fapados, es kell hozza az ssh is, de ha nagyon akarja az ember, akkor cron-bol lehet egy olyan scriptet irni, ami automatikusan inditja el egy konyvtarbol a feltoltott torrenteket, es akkor eleg egy ftp/webdav eleres.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

rtorrentnek a configjaban van schedule funkcio, pont erre :)

régen én is bittornado-t használtam. rtorrent sokkal jobb. gyorsabb, stabilabb. kevesebb memóriát és procit eszik.

Szerintem erdemes lenne beprobalni a lighttpd fluxtorrent kombot (van csomagban, nem kell forditani).

torrentenkenti speed limit: http://libtorrent.rakshasa.no/ticket/20

Nalam hardy-n, az alabbi verziokkal biztos megy:

ii  libtorrent11                                   0.12.2-0ubuntu1.1                   a C++ BitTorrent library
ii  libxmlrpc-c3                                   1.15.6-1                            A lightweight RPC library based on XML and H
ii  rtorrent                                       0.8.2-0ubuntu1.1                    ncurses BitTorrent client based on LibTorren

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

Köszönöm a hozzászólásokat!

Az rTorrent probléma nem annyira fontos, mint a museek-es, mivel arra vannak alternatívák (pl. enhanced ctorrent), de a soulseek-re nincsenek. Grafikus alkalmazás pedig szóba se jöhet...