FatRat download manager (1)

26.11.2006 15:58 | Přečteno: 3707× | FatRat | poslední úprava: 23.2.2008 17:44

Od léta, co jsem začal pracovat v Qt 4, je tu můj třetí letošní open source projekt.

Před rokem jsem začal dělat na download manageru FatRat. Práce na něm byla velmi složitá, byl pro GTK+ (GTKmm). Jakmile jsem poznal Qt 4, projekt jsem odložil a včera jsem začal psát vše od nuly. S Qt je vývoj úplně jiný... rychlý a jednoduchý, kód je krátký a přehledný. Původní FatRat měl naprosto šílené závislosti (gtk, gtkmm, libglademm, libxmlpp, libcurl, libtorrent, ...) - tento FatRat bude záviset jen na Qt 4, podporu BitTorrentu pravděpodobně založím na této ukázce.

Cíle projektu

Cílem projektu je download manager pro Linux s podporou HTTP/FTP/BitTorrentu a možná i dalších protokolů. Downloady se zařazují do front, samozřejmostí je omezování rychlostí front i samostatných přenosů. Plánuju webový interface (budu si muset oprášit Javu). K HTTP/FTP downloadům plánuju možnost paralelního stahování z více serverů, ale tak daleko ještě nejsem.

Logo projektu

Sesmolil jsem logo projektu:

Screenshoty

Od včerejška jsem dal dohromady toto:

Hlavní zobrazení	Detaily přenosu (není dokončené!)
Nastavení fronty	Přidání nového přenosu

       

Komentáře

[David Watzke]

Will Rock, kamaráde...

[xxxxxxxx]

V čem to programuješ?

[Luboš Doležel (Doli)]

C++

[xxxxxxxx]

A v jakym vývojovym prostředí?

[Luboš Doležel (Doli)]

V žádném.

[eXces]

Super. Jen jak jsem tam viděl time left, tak mě napadla jedna věc.. Znám spoustu programů, který to počítají z aktuální rychlosti, případně hodně podivně. Přimluvil bych se pro nějakou průměrnou rychlost, nebo inteligentní odhad budoucnosti

[Luboš Doležel (Doli)]

Rychlost je počítána podle průměru za posledních 7 sekund (tohle číslo mě napadlo náhodou), odpovídá tomu tedy i zbývající čas.

[disorder]

tak to sa trba inspirovat libtorrent/rtorrent, ten to nejak inteligentne odhaduje...

[Jmenomineverte]

Zajímavé by mohlo být zkoušet fitovat polynom/nějakou exponencielu a extrapolovat :)

[Kníže Ignor]

bláblá blá napsal jsem příspěvěk se slovy fitovat a extrapolovat :-P

Průměrná rychlost v intervalu [-t, 0] je určitě základ pro dobrý odhad, to co bych ale nechal program automaticky adjustovat by byl parametr t, který by se program postupně naučil v průběhu (toho jednoho) přenosu.

[kreten]

Držím palce a jen tak dál!

[kreten]

A šup na kde-apps.org

[Luboš Doležel (Doli)]

Ještě to není na žádnou první verzi, první vydám příští týden. Pak to dám na kde-apps.org

[Josef Kufner]

Nojo, ale k čemu mi to je, když download poběží na routeru a notebook s Xkama bude vypnutej na stole? Když už, tak ať to umí víc než ssh+screen+wget

[disorder]

+rtorrent

[Luboš Doležel (Doli)]

Tohle má být GUI program. Headless běh bude až bude web interface (to má nejnižší prioritu).

[Josef Kufner]

Takže počítáš už teď s tím, že to bude mít oddělený backend, který poběží úplně někde jinde, a že jediné čím ty dvě části můžeš jednoduše spojit je unix socket?

[Luboš Doležel (Doli)]

Ne, počítám s tím, že se klient spustí bez GUI a poběží jen smyčka front a webserver/server na příjem požadavků.

[Luboš Doležel (Doli)]

Tím chci říct: psát celé GUI tak, aby mohlo fungovat i přes socket, by bylo šílené a je to úplně mimo mé potřeby

[Josef Kufner]

Nejde o to aby fungovalo "i" přes socket, stačí, aby fungovalo "jen" přes socket. Šílené to není. Vlastně se ti to tím i zjednodušší. Stačí si zapouzdřit socket do nějakého jednoduchého API ve stylu "pošli příkaz", "vyzvedni události" a gui tohle bude jen zobrazovat a backend jen provádět. Obojí budou jednoduché a nezávislé programy. Jako bonus získáš možnost napsat velmi lehce GUI v jakémkoliv jazyce a prostředí, což výrazně zvedne životaschopnost programu. Je to malá investice, která se bohatě vyplatí. Hlavně si na tom rozhraní dej záležet, je to vpodstatě jedna z nejdůležitějších částí.

[Luboš Doležel (Doli)]

Vzhledem k tomu, jak velké množství informací by se muselo přenášet a kolik tříd bych pro něco takového musel připravit, se mi to nevyplatí - sám o to nestojím.

Pošli příkaz není tak jednoduché - tady máte hromady různých objektů různých tříd s rozličnými argumenty metod.

To, co chci připravit pro webinterface, má výt značně odlehčené.

[Josef Kufner]

Potřebuješ jednu třídu pro API zapouzdřující socket, nic víc.

Pošli příkaz jednoduché je. Prostě máš akorát ten příkaz. Jedna třída. A klidně to udělej textové (ne API, ten protokol) - o to jednodušší to bude. Když to dobře navrhneš, opravdu bude stačit jedna funkce na poslání příkazu a druhá na vyzvednutí událostí.

Informací se bude přenášet málo. Ty data se budou ukládat tam, kde poběží backend. Přenést 1x za sekundu "tam ten je na tolika %" je pár bytů i v textové podobě. To by plynule fungovalo i po sériovém portu. Nehledě na to, že by nemusel být problém to přes ten sériový port procpat.

Ač se to možná na první pohled nezdá, na složitosti programu ti to nepřidá, spíš naopak. Nehledej v tom žádné složitosti a záludnosti. Základem úspěchu je to udělat jednoduché a univerzální. Klidně si to načmárej na papír, nakresli si kudy která data půjdou a co je kde potřeba. Jestli se ti to nevejde na jednu stranu A6, tak to máš zbytečně složité.

[Luboš Doležel (Doli)]

Vy se mě snažíte přesvědčovat o něčem, co není pravda. Napsat software, který místo přímého volání něco zapouzdřuje a tahá přes socket, není jednodušší. Tohle není přenášení nějakých hloupých procent - při segmentovém stahování se budou zobrazovat informace segmentech, bude tam správa mirrorů atd. Další hromada rozmanitých informací o Bittorrent downloadech (podívejte se, kolik toho zobrazuje Azureus). Tohle by práce každopádně přidělalo hodně a získal bych funkci, která je mi na nic (ano, jako neplacený autor budu takhle sobecký).

Tohle je desktopový GUI program, tohle není a nebude server/klient software.

[Josef Kufner]

Hm, takže z toho bude další program, který nic nového nepřinese.

[Luboš Doležel]

Vám možná ne, mně ano.

[Josef Kufner]

Mám takový pocit, že ani Vám ne

[Luboš Doležel]

Tohle je v GTK+, nepodporuje segmentové stahování, nepodporuje BitTorrent, nemá webinterface, rozhraní je v ruské angličtině (dobře jsem se některým rádoby anglickým hláškám zasmál), nelíbí se mi systém front... mohl bych pokračovat.

[Josef Kufner]

Ok, špatný příklad.

Chceš tam webové rozhraní. Jak si tedy představuješ, že to do toho programu zakomponuješ?

[Luboš Doležel]

Budou se přes síť exportovat pouze základní informace společné pro všechny typy downloadů. Žádné komplikované specifické (pro tento typ přenosu) detaily, pouze jednoduchý společný základ. To je zatraceně velký rozdíl.

[Josef Kufner]

Ale jak je budeš exportovat? Zabuduješ do toho programu i http server?

[Luboš Doležel (Doli)]

Velice primitivní HTTP server, který poskytne HTML stránku a aplet - aplet si pomocí jednoduchého požadavku požádá o výpis + může poslat nějakou základní změnu. Podívejte se na web rozhraní Azureusu, to je můj vzor.

[Josef Kufner]

Ok. Jak si představuješ spolupráci web a qt rozhraní s backendem, který bude stahovat data?

[Luboš Doležel (Doli)]

Velmi snadno - všechno je chráněno pomocí QReadWriteLock, takže se o přístup prát nebudou.

GUI si bude volat co chce, od web serveru budou přicházet jen základní povely.

[Josef Kufner]

Takže to bude mít více vláken. Co rozhraní to vlákno + vlákno s backendem (případná vlákna co si backend vytvoří pro sebe nepočítám)? Pokud ano, tak stejnak budeš muset definovat nějaké API, které bude mezi backendem a rozhraními. Proč tedy už předem ochuzuješ webové rozhraní o velké množství funkcí, když může mít stejné schopnosti jako Qt rozhraní?

[Luboš Doležel (Doli)]

Tady není žádné "rozhraní". Existuje pouze generic třída Download s několika metodami, které jsou pure virtual. Qt frontend, pokud má např zobrazit detailní informace o downloadu, zavolá virtuální metodu z třídy Download a získá tak megaWidget o jehož naplnění údaji se stará třída z backendu (GUI dá megaWidgetu vědět, kdy se aktualizovat).

Dvojklikněte si na torrent v Azureusu (zobrazení detailů) a to, co uvidíte, si zkuste naimplementovat a data si přenášejte přes TCP - budete mít práce nad hlavu, to mi věřte. Proč ho ochuzuji? Protože takové detailní informace ve web interface jsou NAPROSTO ZBYTEČNÉ - účelem tohoto rozhraní je zkontrolovat si stav přenosů, případně přihodit nějaký torrent (=účely,které od toho požaduji já).

Pokud chcete víc, běžte a naprogramujte si/doprogramujte si to/babrejte se s tím sám, patche od vás uvítám. Já tohle prostě dělat nebudu a nehodlám o tom ani diskutovat - ať už tuto debatu "vyhrajete", nic to na tomto faktu nezmění. Běžte a chtějte něco podobného od autorů KGetu, zaklepají si na čelo...

[Luboš Doležel]

Z vás jde velmi zajímavý pocit: nemá to funkci, co chci já => je to úplně na nic, nepřináší to nic a nepotřebuje to ani autor (ten tedy asi není soudný a neví, co chce).

[Luk]

Proč unix socket? Proč ne TCP socket (např. tunelovaný skrz SSH)?

[Josef Kufner]

Protože na zabezpečení unix socketu stačí chmod 600. U TCP socketu se to nedá omezit pod všechny uživatele na localhostu. Ale vpodstatě je to jedno, změny v kódu tcp vs. unix jsou minimální.

[Luk]

Ale mně šlo o něco jiného - unixový socket je jen lokální, kdežto TCP lze využít i odjinud.

[Josef Kufner]

Když to nejdřív udělá po unix socketu, nebude se muset zatěžovat zabezpečením a lehkou oklikou jej lze po síti využít taky (ssh + miniaturní klient). Takže bude mít něco, co funguje hned a kam lze velmi jednoduše doplnit komunikaci po síti – doplní nějaké to zabezpečení a změní typ socketu.

Nehledě na to, že kominukace po TCP není pro tohle nezbytně nutná. Pokud bude chtít někdo používat jen webové rozhraní, tak je bezpečnější a plně vyhovující unix socket (viz mysql + php na jednom stroji).

[kotyz]

vypada to velice slibne. ja si sice vystacim s ktorrentem, kgetem a kftgrabberem. ale mit na to jeden peknej program by nebylo vubec od veci ...

[ondrab]

ta krysa se mi zda malo "fat", doporucil bych ji trochu roztahnout do sirky :)

[David Watzke]

Ale ne moc, ať z ní není FAT32.

[pedro]

nešlo by do toho přidat možnost "vypnout pc po dokončení všech stahování", nebo alespoň "ukončit program po dokončení..." ? Za tohle funkci bych byl moc vděčný...