Jól haladnak a natív linuxos uTorrent fejlesztésével

Szerszám

Július elején értesülhettünk arról, hogy az uTorrent fejlesztők ígéretet tettek arra, hogy lesz natív uTorrent Linux-ra. Akkor még "planned", azaz tervezett státuszban volt a projekt. Most azonban már "started" az állapota. A fórum adminisztrátora szerint jól haladnak a munkával és azt ígérte, hogy hamarosan érkezhet a kiadás.

( utpKabel | 2010. 08. 17., k – 13:11 )

Végre lesz egy jó torrent kliens Linuxra.

tudom, hogy megnézhetném, de sosem visz rá a lélek, de hátha van kedved segíteni :) hogy lehet a seed-et állítani? elég ritkán használom, nem nagyon vagyok warezpistike, de pl. van egy csomó ingyen cucc, amit már hál istennek torrentben osztanak meg a világgal. viszont nálam a seed nem megy, csak akkor, ha töltök le. amikor már lejött, akkor tojik rá, hogy seedeljen. engem nem izgat, hogy nem simul be a gnome-ba, vagy akárhova, jó nekem így is. csak pár dologban kissé még kényelmetlen (pl. nem igen tudtam még azt sem megoldani könnyen, hogy egy millió file-os torrentből csak 1-2 file-t húzzon le, mert nekem pl. csak az kell; ez meg rossz üzlet mondjuk ha csak egy md5 sum kell és nem az iso, ami mellette van :) )

--
xterm

Az rTorrent egy libTorrenten alapuló BitTorrent kliens. Ncurses-t használ a konzolon való megjelenítéshez. Stabil és megbízható. Elsősorban unix like operációs rendszereken örvend népszerűségnek. Egyik legnagyobb előnye alacsony erőforrásigényében rejlik.

  • Ctrl+q = szabályos kilepés.
  • Ctrl+d = aktív torrent leállítása, leállított (inaktív) torrenten alkalmazva = kiszedi a kliensből, torli a torrent filet (fizikailag nem törli a seedelt/leechelt fileokat).
  • Ctrl+s = leállított (inaktív) torrent élindítása seedre/leechre.
  • Ctrl+r = hash ellenőrzése (amit Ctrl+d-vel lehet leállítani/félbeszakítani, kell utána egy Ctrl+s is).
  • Enter = torrent file felvétele seedre/leechre külön útvonal megadassál, leállított/inaktív állapotban - nuku seed/leech.
  • Backspace = torrent file felvétele seedre/leechre külön útvonal megadassál, elindul/megy a seed/leech.
  • Ctrl+o = megadható más letöltési útvonal (eltérő az .rtorrent.rc-ben meghatározottól) az adott torrent részére, de csak is új és addig nem aktivált torrent szamara.

Titkosítás használata rtorrent esetén, de szerintem szinte az összes kliensben (uTorrent, Azureus, etc.) bekapcsolható, általában encryption címszó alatt. Pl. rtorrent kliens rtorrent.rc konfigurációs file a következőkre ad lehetőséget:

  • allow_incoming (elfogadja a bemenő titkosított kapcsolatokat)
  • try_outgoing (használja a titkosítást kimenő kapcsolatokhoz)
  • require (nem fogadja el titkosítatlan kapcsolat kezdeményezést (handshake) másik klienstől)
  • require_RC4 (letiltja sima szöveges (plaintext) adat továbbítást titkosított kapcsolat kezdeményezés (handshake) létrejötte után)
  • enable_retry (ha a kimenő kapcsolat létrejötte sikertelen volt, akkor kikapcsolja a titkosítást ha az be volt kapcsolva vagy bekapcsolja azt ha ki volt kapcsolva)
  • prefer_plaintext (sima szöveges adattovábbítást (plaintext) választ ki, amikor a többi kliens (peer) felkínálja a választást sima szöveges adattovábbítás és RC4 titkosítás között, minden egyéb esetben RC4 titkosítást használ)Valahogy így kell használni:encryption = allow_incoming,try_outgoing,require,require_RC4Amennyiben olyan paranoid valaki mint szerénységem, javasolt verzió:

    encryption = require,require_RC4

Megy a részleges letöltés is, akár egy file több százból is.
A gond inkább az, hogy egyrészt akkor is létrehozza a filet 0 mérettel, ha egy grammot nem húz le a tartalmából. Másrészt, hogy hajlamos "szivárgásra", azaz kis mennyiséget letölteni olyan fileokba, amik off prioritással nem letöltendőként vannak kijelölve.

A nehézkes kényelmetlen jelölgetéssel én is egyetértek. Az is idegesít, hogy nem helyezi át a sikeresen letöltött filet pl. leech könyvtárból seed könyvtárba, ha több fileból áll a torrent, hiába nincs letöltésre kijelölve a többi file.

Állitolag dolgoznak ennek javításán rTorrent 0.8.2/0.12.2-ben nincs, tehát leghamarabb ősszel/téllel történik meg szerintem eme várt esemény.

  • Letöltöd a *.torrent filet
  • rtorrentben [View: incomplete] nézetben nyomsz egy Enter-t, megadod az útvonalat az előbb letöltött *.torrent filehoz, nyomsz egy Enter-t. (így nem kezdi egyből tölteni a torrentet, inactive lesz).
  • [View: incomplete] nézetben kurzor nyilakkal odatolatod a három függőleges csillagot a részlegesen letölteni kívánt torrent nevéhez, nyomsz egy ==> jobbra nyilat.
  • Benn a torrent nézetben legyalogolsz nyilakkal File list-ig vagy egyszerűen nyomsz egy i betűt, utána nyomsz egy ==> jobbra nyilat, meg kell jelenni egy kijelölő sávnak.
  • Amennyiben könyvtárnév is van pl. \ VIDEO_TS, akkor ráállsz és nyomsz egy Space-t, minek hatására az összes e könyvtárban tartózkodó file neve mellett balról Pri oszlop alatt megjelenik egy off felírat - ezzel az jelezted rtorrent részére, hogy ezeket nem kell letölteni. Ami filet letölteni kívánod, arra rávezeted kurzor nyilakkal a kijelölő sávot és kétszeri Space lenyomásával leveszed az off kijelölést.
  • Balra nyíllal, kétszeri lenyomásával, kilépsz torrent neve elé. Nyomsz egy Ctrl+s gomb kombinációt, ezzel aktívvá teszed a torrentedet, megindul a letöltés.Természetesen egy már eleve aktív torrentben is tudod módosítani a fileok prioritását tetszésed szerint.p.s. én screen alol használom rtorrentet xtermben, tehát esetlegesen használt webgui alatt hogy kell ténykedni nem tudom. :)

rtorrentben már megy a torrenten belüli (File list-ben)*-gal való összes file kijelölése.
--
http://opensolaris.org/os/project/indiana/
http://www.opera.com/browser/

Mert esetleg eleve van 1000 seeder, akiből 500 garantáltan közelebb van (jobb a traceroute. ping) ahhoz a pár nagyon ritkán feltűnő leecherhez.
Ugyanis van "súlyozás" is a torrentben, swarmon belül.
Hiába vagy gigabites Mon, ha a letöltő Kanadai, akkor nagyobb részt amerikai seederektől fogja megkapni az anyagot.

Én anno "vékony" nettel csak úgy tudtam sikeresen seedelni (védekezni a szeléssavúak és a serveresek ellen :), hogy növeltem a rendelkezésre állást (értsd, hetekig nem töröltem a "lejött anyagot" és járattam a gépemet).
--
http://opensolaris.org/os/project/indiana/
http://www.opera.com/browser/

( Chronos | 2010. 08. 17., k – 13:20 )

Delugéval eddig is meg voltam elégedve, de meglátjuk mit kezdenek az uTorrent-el.

A stabilitást a utorrent hozni fogja, inkább arra leszek kíváncsi összeroskad-e Gbit-es linken. Az rtorrent-el ki lehet használni az 1Gbit sávszélt, míg a windowsos utorrent-el tudtommal nem. Bár sokat nem teszteltem és nem is ma volt (v1.8 táján), de sokaknak ez volt akkor a véleménye.

Értem, szóval az utorrentnek semmi értelme headless módban, mivel van default webuija, ellenben az rtorrentel aminek nincs alapból. Nincs több kérdésem.

Egyrészt az rtorrenttel is vannak stabilitási problémák. Nekem minimum havonta elszáll mindenféle log nélkül. Másrészt meg az utorrent stabilitásáról maximum annyit tudok mondani, hogy windows alatt betonstabil. Amiből persze a linuxos klienssel kapcsolatban következtetést levonni fölösleges.

--
40% of OpenBSD installs lead to shark attacks. It's their only standing security issue.

( uid_15426 | 2010. 08. 17., k – 13:36 )

Pont kesz lesz, mire a nagyuzemi torrentezesnek vege.

----------------------
while (!sleep) sheep++;

Nem igazán P2P-re szánták, sőt a blokkolják is a portokat, sokkal inkább a hazai vipvpn-hez vagy ipoltalom-hoz hasonló VPN szolgáltatásokra gondoltam, amiknek igen jó hasznát venni mobilnettel meg kollégiumi, egyetemi és munkahelyi hálózatokon, meg persze minden olyan főleg vezetéknélküli kapcsolódással elérhető hálózaton aminek nem te vagy a rendszergazdája.

UPC nem azárt lassít, mert warezol (illetve de). Nálam bevezették a digi-t. Mindenki átváltott, talán egydül maradtam a házban UPC-s, és azóta titkosítás nélkül is full sávszélen tudok torrentezni. Ezelőtt itt is lassították. Ahol sokan vannak és nem bírja sávszéllel, ott gondolom korlátoz.
--
ez ugye csak valami vicc

mivel egyedul hasznalod, tied minden. de amig tobben is voltatok egy vonalon, csak a minimum jott ki belole, ugye?

"Mindenki átváltott, talán egydül maradtam a házban UPC-s, és azóta titkosítás nélkül is full sávszélen tudok torrentezni. Ezelőtt itt is lassították."

Nem lassitottak, csak az elofizetesek szama * garantalt savszel volt meg akkor is.

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

Van oylan haverom, akinek semmi nem mukodik Torrenten titkositva, viszont a valknut-strongdc ssl kombojaval ssl-nek kulon portot nyitva nem korlatozta le a UPC (es DC-n is egyedul nalam mukodott a gyors transfer oda-vissza, ott is midnenki massal korlatozott volt)

------------
Az az igazi troll, akinek a jelenlete a varhato kommentek szamat elosztja nullaval

Jelentem nálunk UPC monopol helyzetben van, és megy a torrent ami a csövön kifér. Egyszerű uTorrent titkosítással. Szerintem ma már a lassulás mögött más lehet.
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

( sartek | 2010. 08. 17., k – 14:43 )

nem tudom mivel nyujthat tobbet mint a meglevo linuxos -grafikus- kliensek, max stabilabb + jobb dht + pex + utp

mindenesetre nagyon meglennek lepodve hogyha elteritenenek rtorrentrol

rtorrent sosem volt nagyon aktív fejlesztés alatt, épp mindig csak működött épp hogy. Már mióta ez megy. Kiadnak egyet 3 évben egyszer, patchelik össze-vissza a distrok, kiadnak még egyet, bugtracker hemzseg a bugtol, az rtorrent is...kabaré.

Transmission már egy fokkal jobb. Deluge se rossz , de lemarad a fejlesztési üteme a libtorrent-rasterbar-tól. Egyedül qBittorrent-nek van most stabil, gyors kiadási ciklusa ÉS JAVÍTJÁK a hibákat ami hatalmas plusz ha ránézünk most az összes kliensre mivel egy épkézláb sincs köztük ezen kívül.

Átláthatóbb a felülete, meg ahogy írtad is: "max stabilabb + jobb dht + pex + utp". Arról nem is beszélve, hogy a szolgáltatói p2p korlátokat ezzel maximálisan ki lehet játszani. A korrekt magnet link kezelésről meg nem is szólva.

--------------------------

Csak a viták elkerülése végett. Ha nem használok ékezetet, mobiltelefonról írok.

Nálam az rtorrent és a transmission nem használhatóak, semmilyen beállítással, feltehetően a kábelmodem miatt, ahogy elkezd letölteni beáll a sebesség 0-ra és 5-10 percig nem használható az internetkapcsolat, böngészés közben 80%-os packet loss.

Ezzel szemben a utorrent megy, a sebesség nem csökken le és packet loss sincs.

Ez egy meglehetősen érdekes hálózati probléma aminek már régóta próbálom megtudni az okát, csak ezen a kábelmodemen, internetkapcsolaton jelentkezik csak és kizárólag Linux alatt.

Egy ideig a TCP window scaling-re gyanakodtam, de nem az okozza, a router megkerülésével sem változik a helyzet, tehát az sem okozhatja.

Wireshark-al lehetne vizsgálódni, de egyelőre ennyire nem értek a hálózatokhoz, esetleg megnézni, hogy ha a Linux egy Windows-os hálózaton keresztül csatlakozik akkor is marad a probléma vagy sem.

A kábelmodemet lehetne kicserélni, de nem biztos, hogy megéri a fáradtságot, mert egy hét múlva költözök el.

Előfordulnak néha bizonyos use case -k esetén, adott hálózati környezetekben ilyen rejtélyes "Linux lehúzza az egész netet" dolgok.

Nálam is így van, bármelyik gépemen bootolok Linuxot, akár ethernet, akár wifi, bármelyik distro. De nekem elég firefox-szal leszednem egy nagyobb fájlt. Amint elkezdi, a subnet összes többi gépe alig kap valami sávszélt. Fogalmam sincs mitől lehet.

Routertől nem függ, mert a korábbi WRT54GC -vel is csinálta, meg a jelenlegi WR340GD -vel is. Most majd talán meglátjuk hogy a modem csere feloldja-e a problémát (most vitték el a Cisco modemet, hoztak egy Motorola -t, kiderül).

Amúgy Győr, VidaNet, 15mb/1mb kábelnet.

--
"ktorrent utan az utorrent volt [...] beallithatatlan"
...

Nagyon gyakran a hálózati interfész nem megfelelő MTU beállítása is okozhat ilyet.

Azonosítatlan okokból egyes Linux disztribúciók alatt 576 az alapértelmezett MTU, ezt érdemes 1500-ra állítani: 

ifconfig eth0 mtu 1500

Ha Networkmanager-t használsz az automatikusan 1500-ra állítja.

Érdemes letiltani az IPv6 modult: 

alias net-pf-10 off

, ez mehet az /etc/modprobe.d/ könyvtárba.

További lehetőség a TCP window scaling letiltása: 

echo 0 > /proc/sys/net/ipv4/tcp_window_scaling

576-os MTU-val ugyanazt tapasztalom, mint te, ezekkel a változtatásokkal már csak az említett bittorrent kliensekkel, és a masszívabb többszálú letöltéssel történik fennakadás, packet loss.

Ezzel az 576-os MTU-val én is találkoztam már Debian alatt.

Amikor a dhclient megkérte az IP-címet a szolgáltatótól, az MTU 576 lett.
Ifconfig-gal 1500-ra visszaállítva semmi gond nem volt, de a lease time lejárta után újra 576-ra frissítette.

A megoldást az jelentette, hogy a dhclient beállításai közül kiszedtem az mtu lekérését a szolgáltatótól, így maradt az alapértelmezett 1500-on.

Így esetemben 1500 volt alapértelmezetten, viszont a szolgáltató szerverével való egyet(nem)értés következményeként változott 576-ra.

Ezért nem vagyok biztos benne, hogy a Linuxszal volt a probléma. Ill. esetemben vagy a dhclient, vagy a szolgáltató kiszolgálójának beállítása szerintem.

Tényleg, már emlékszem (néhány éve telepítettem fel a Linuxomat, valahogy kiesett), nem a disztribúciók alapértelmezett MTU értéke, hanem a DHCP szerver okozza a problémát, ahhoz, hogy ne kérje le az MTU-t a dhcpcd.conf-ban a következőt kell kikommentezni: 

option interface_mtu

Ettől függetlenül nálam a kábelmodemmel is probléma lehet, de az MTU és a TCP window scale beállítása közel használhatóvá teszik.

Megyek továbbképzem magam egy TCP tutoriallal.

Így van, ezzel volt a probléma.

Már csak azt nem értem, miért jó a szolgáltató oldali beállítás így.
Van valami különös oka, vagy egyszerűen Win alatt és úgy általában jó, csak ne kérjük le az MTU-t?
...vagy ez a "kitöltetlen" állapot és nem piszkálták?
Esetleg értelmezési probléma a dhclient-nél?

Nem igazán értem...

Amúgy ez UPC volt.

( balintdavid | 2010. 08. 17., k – 19:45 )

Hogy fognak ennek örülni a windowsról áttérő warezzoltánkák!
-------------------------------------------
Dell Vostro 1015 // Ubuntu 10.04 //

Sok éve Linuxon dolgozom, 100Mb-s hálón lévő gépeken boldogan használom az ssh+rtorrent kombót, de az otthoni UPC-n semmi sem megy olyan jól mint a wine+utorrent...

És elgyengültem: sok belső csata után a pragmatizmusom legyőzte az idealizmusom

Most nem tudok a tükörbe nézni, egy elvtelen senki szar alak lettem, és időnként még mindig véreset vizelek, igaz Virág elvtárs?

( nagy_peter v | 2010. 08. 17., k – 20:46 )

Igazából uTorrentet nem használtam még sosem, csak érdekelne, hogy mondjuk egy ktorrentnél valamivel többet tud, vagy inkább csak az ismerős felület (már aki windowson is használta) szól mellette?

Az utorrent nem a funkcionalitásával hódítja meg a felhasználókat (bár minden lényeges dolgot ismer, de mondjuk egy Azureus/Vuze agyontweakelhetőségével nem vetekszik), hanem a letisztult, gyors, kényelmes felületével, stabilitásával. Látszik rajta, hogy profik írták. (a legtöbb kliens az utorrent által bevezetett layoutot használja, emlékeim szerint a ktorrent és a deluge is).

Hogy a kérdésre is válaszoljak: kb. egy súlycsoportban van a tudásuk.

http://en.wikipedia.org/wiki/Comparison_of_BitTorrent_clients

szerk.: most nézem az aláírásomat, nanto kollegától származik ;)

--
"ktorrent utan az utorrent volt [...] beallithatatlan"
...

Köszönöm, közben én is kerestem képernyőmentéseket az uTorrentről, és bizony egy megfelelő ikoncsomaggal jó ideig nem jönnék rá, hogy most ktorrent vagy utorrent alatt vagyok-e. Az utóbbi időben a ktorrent csapata is megtáltosodott, mert a bugok jórésze eltűnt, a random szegmenshibák eltűntek, és egész használható lett. Persze annyit még nem tud, mint a vuze, meg a fájlok közti prioritást is rosszul kezeli, de ha esetleg az uTorrent is QT-s felületet kap, adok neki egy esélyt.

szerk:
Gondolom elírás a Wiki-n, de azért rákérdezek. Az uTorrent Windowson igényli a Wine Libeket? szerintem csak felcserélték az ostzlopokat, de találkoztam már olyan windows progival, ami WINE-t igényelt windows alatt (DX10-et akart használni XP alatt)

;) Engem az utorrentben ami a legjobban zavar, hogy nincs egy rendes config file. StrongDC-s koromban megszoktam, hogy kell a menekulout, még azok a DC-s xml file-ok is jobbak voltak a binaris config file-nal. (tudom, hogy egy allat vagyok, meg hogy az regen rossz, ha config file-t kell ganyolni, de nekem az a megbizhatobb bizonyos esetekben)

Meg a masik egy korabbi utorrent verzional jatszodott le: ktorrent mindig viszti a 6881 portot es kesz, utorrent meg egyik verziojanal kitallata, hogy mindig elso inditasnal random port (lehet ezt javitottak, de miutan apam engem hivott at minden ujrahuzott Win utan, hogy nyissak portot a routeren, es volt hogy utorrent at se engedte irni a portot, ezekutan valahogy megutaltam az utorrentet, lehet azota sokkal jobb mar)

Meg a masik kellemetlen elmeny az utorrentte amikor megrogzott DC-s letemre nem tudtam atrakni valamit, hogy ugyan ne a Documents and settingsbe toltse mar le es fol (GUI-n akkor még nem volt, config fileban egyedul a path nem volt akkor binaris, de inkabb ne irtam volna at)

Hozzatennem, hogy a ktorrentet is 3.1 korul szerettem (kde 4.2 idejen), a ktorrent 4.0-tol egyenesen hanyok, es 2-3x annyi ramot el is zabal, mint utorrent

------------
Az az igazi troll, akinek a jelenlete a varhato kommentek szamat elosztja nullaval

( kukukk v | 2010. 08. 18., sze – 08:40 )

Sokan irtak, hogy vegre lesz egy normalis torrent kliens linuxra. Regebben hasznaltam uTorrent-et, es tenyleg jo. De ugyanugy elegedett vagyok most a Ktorrent-el is. A kerdesem igazabol az lenne, hogy mibol gondoljatok, hogy a linuxos verzio (elsore) ugyanolyan jo lesz, mint a windows-os?

Sic Transit Gloria Mundi

A torrent protokoll kezelésének nagy része talán hordózható...

A felületre viszont én is kíváncsi vagyok, mert:

1. Az lényegében nem hordozható, tehát kb. a nulláról írják újra

2. Nem biztos hogy annyira expertek Linux GUI-ban mint a Windowsban (vagy nem tudnak annyira ügyes fejlesztőt találni)

3. Ezért nem biztos, hogy ugyanolyan alacsony szinten írják meg a felületet mint a Windowson (a fórumon sokan rimánkodnak hogy C nyelven GTK+ban készüljön, ne Qt-ban és még véletlenül se Pythonban(bármivel))

4. Így lehet, hogy a GUI kóddal együtt nem is lesz annyira lightweight hanem kb. párba lesz a többi alternatívával

"1. Az lényegében nem hordozható, tehát kb. a nulláról írják újra"

Lehet, hogy összecsomagolják valami kitesztelt Wine verzióval, mint régen a Google, és csak ránézésre lesz natív. Bár a használhatóságban ez nem szempont, hisz ott csak szubjektív szempontok vannak.

--
"ktorrent utan az utorrent volt [...] beallithatatlan"
...

"A torrent protokoll kezelésének nagy része talán hordózható...", de gondolom legalabbis hordozhatova teheto...
E miatt nem ertem, hogy miert van/kell annyi fele fajta torrent kliens. Miert nem lehet kozesen fejleszteni egy libtorrent-et, amihez egy-egy csapat keszitene QT-s, GTK-s, CLI-s, valamint web-es felutet?

Sic Transit Gloria Mundi

( vtechun | 2010. 08. 19., cs – 01:22 )

nah, remelem jon hamarosan, szeretem, hogy felrakom es muxik :) eroforrasban sem veszem eszre hogy jelentosen tobbet enne mint pl. rtorrent, tud queue-t kezelni, beepitett rss tamogatasa van, stb, van azert jo par elonye a legtobb linuxoa klienssel szemben.

( mspike | 2010. 08. 19., cs – 07:26 )

én qbittorrent-et használom, megy egy kis netbookon rájavan kötve egy 1T usbs... és tök jó :) Shared mappa sambával, oda lehet bedobálni a torrent file-t elkezdi tölteni, van webes felület, eredmény megint csak sambán jön.... és simán eldöcög egy netbookon.... nem értem az uTorrent mibe több, de akit csak ez tartott vissza a pingvintől az most végre legyakhatja az összes NTFS partíciót... :D

( eReL | 2010. 08. 19., cs – 14:35 )

Sokkal jobb ez, mint a ktorrent?
(Amire én használom, tökéletes mind a kettő, de lehet, hogy valami nem tűnt fel.)
____
Semmi sem biztos. Még az sem biztos, hogy semmi sem biztos.