Zase další P2P?

7.11.2009 18:54 | Přečteno: 1757× | Opensource | poslední úprava: 7.11.2009 18:56

Už dlouho jsem si nic nenaprogramoval a v podstatě nikdy jsem nenapsal žádnou větší desktopovou aplikaci s grafickým uživatelským rozhraním. Tak jsem se rozhodl vytvořit zatím pouze ve fázi úvah a návrhů P2P aplikaci na sdílení souborů.

Určitě si řeknete: "Zase další zbytečná aplikace". Jenže ta moje má být samozřejmě lepší než doposud běžně používáné a měla by se stát spíše náhradou Direct Connectu než Bittorrentu. Ve struktuře tedy bude server obsahující seznam všech sdílených souborů, ve kterém pak bude umožněno uživatelům vyhledávat. Původně jsem přemýšlel na použítím distribuované hash tabulky (DHT), ovšem to by bylo mnohem náročnější na implemetaci, vyhledávání soubrů by bylo pomlaješí a navíc by byl stejně stále potřeba server, který by uživateli sdělil adresy nodů.

A v čem bude tedy lepší než Direct Connect? Tak především se bude jednat o nový na XML založený protokol, ne zbastelný a reverzním inženýrstvím získaný DC. Bude podporovat kompresi a šifrování. Soubory bude možno hodnotit a psát k nim komentáře. Vyhledávání souborů bude díky centrálnímu serveru velmi rychlé. Ze souborů bude umět získat meta informace, které se pak budou moci využít při vyhledávání nebo informování uživatele před stažením souboru (třeba ID3 tagy u MP3 souborů, rozlišení a bitrate u videa nebo náhled u obrázků). Automatické segmentované stahování při nízké rychlosti stahování a mnohem víc. Uplatnění vidím hlavně ve sdílení souborů v různých skupinách lidí, převážně na kolejích. Například na kolejích VUT v Brně se používá podle mne celkem špatný Direct Connect, na kolejích 17. listopadu v Praze má zase krkolomně hodně lidí nainstalován FTP server s centrálním vyhledávačem. S mým programem a protokolem by to bylo mnohem jednodušší a pohodlnější.

A proč to zde vlastně píši? Zaprvé se vás chci zeptat, jestli má vůbec cenu něco takového psát a zabít tím obrovské množství času, protože i pokud by se mi to podařilo dopsat a byl by to hodně dobrý program, bojím se, že by ho používalo jen velmi málo lidí. A za druhé: vše má být napsáno v Pythonu, protože je to podle mne jeden z nejlepších jazyků s velkou dopstupností různých knihoven. Jenže nevím, jaké použít grafický framework. Chci, aby má aplikace běžela na Windows, Mac OS a taky na Linuxu. Bude QT nejvhodnější? Nebo má smysl použít pro každou platformu jiný framework? Díky za každý váš komentář.

       

Komentáře

[Grunt]

Co furt máte všichni s tím Pythonem? Jde to vůbec kompilovat?

[Ladicek]

Taky to nechápu. Ruby je přece mnohem lepší :-P

[pools]

Python ma jednu zajimavou vlastnost - dokaze v tom neco napsat neprogramator kteremu das hodinovou prednasku. Jinak je to relativne dobra kalkulacka...

[Acci]

Jak jsem psal: existuje pro něj obrovské množství knihoven (už to mám dost promyšlené a zatím na vše, co budu potřebovat existuje už nějaká hotová a dobrá knihovna), je rychlý a snadno se v něm vyvíjí multiplatformní aplikace. Sice mi v něm některé věci vadí (jako třeba blokové komentáře), ale stále je to podle mne nejlepší jazyk pro psaní normálních aplikací (C je moc nízkoúrovňové, C# je platformě závislé, ObjectiveC se používá snad jen na Macu a Java je kapitola sama pro sebe).

[Conyx]

co mas proti blokovym komentarum v Pythonu?

[Luboš Doležel (Doli)]

C# není platformně závislý a nějak ti vypadlo C++.

K rychlosti bych měl značné připomínky. Navíc mi dost vadí miliardy wrapperů v systému.

[Fluttershy, yay!]

C# není platformně závislý...

Mono vs patenty MS.

[Dušan Hokův]

V pythonu pisu engine pro textove hry, pro gui jsem pouzil pygtk a vyzkousene je to na windows, linuxu, macu a freebsd

[Acci]

Já věřím, že PyGTK ti na těchto platformách funguje, ale já od takového frameworku čekám něco víc. Třeba aby nebylo poznat, že do toho prostředí nepatří. Zatím, co jsem tak zkoumal, tak nejlepší asi bude použít Qt.

[Tomáš]

Na Macu bude QT fungovat, ale řekl bych, že MACisti jsou hodně citliví na design, takže co není Cocoa, je ošklivé.

[s0]

qt na macu uz s cocoa jede. a v budoucnu to bude zapnute implicitne.

[Acci]

Jsem Macista a právě proto tohle celkem řeším. Ale zaujalo mne, že třeba Last.fm scrobbler je napsán v Qt a kdybych to nevědl, tak bych řekl, že je to nativní aplikace pro Mac. Zkusím si s tím pohrát a vyzkoušet, jak to bude na jednotlivých platformách vypadat. Určitě budu informat.

[JS]

Me by se hlavne libilo, kdyby to (tedy P2P aplikace, momentalne pouzivam aMule a na hledani Kad) umelo projit disk a vybrat vzacne soubory, ktere nekdo shani, a nemuze sehnat, a ty nasdilelo. Nechci mit trvale nasdilene vsechno (a ani to neni fyzicky mozne), ale rad se o neco podelim.

[ja]

Me by se hlavne libilo, kdyby to (tedy P2P aplikace, momentalne pouzivam aMule a na hledani Kad) umelo projit disk a vybrat vzacne soubory, ktere nekdo shani, a nemuze sehnat, a ty nasdilelo.

Napriklad eroticke fotky tvojej priatelky/manzelky

[JS]

Ne, ty by prave nikdo najit nemohl, protoze by se sdilely jen ty soubory, co uz nekdo hleda.

[Jiří Němec]

Bonzovat tu jaké sítě se v jaké škole používají, za to byste si tam měl minimálně vysloužit ban.

Jinak pokud se vzdáte myšlenky na centrální server a zavedete mechanizmy díky kterým bude stahování anonymní, tak by to mohlo mít minimální šanci se rozšířit aspoň v těch kolejích. Jo popřemýšlejte o jazyku jako c/c++. Už se moc těším na python hashující takových 10TB dat.

[Acci]

Ban kde? Na těch sítích? Ani na jedné nejsem.

Centrálního serveru bych se rád vzdal, ale mám takové tušení, že bez něj to prostě nepůjde. A anonymní stahování by byl taky problém, to by se musela zavést síť podobná Toru. Ale zkusím nad tím popřemýšlet, třeba to nějak půjde.

A Python hashující 10 TB dat bude zhruba stejně rychlý jako C hashující stejné množství dat.

[Grunt]

A Python hashující 10 TB dat bude zhruba stejně rychlý jako C hashující stejné množství dat.

Není Python náhodou interpretovaný jazyk?

[Acci]

Kupodivu je, jenže interní Pythoní knihovny jsou psány v C a proto jsou stejně rychlé (až na nějakou režiji). Proto bude třeba stejně rychlé i uživatelské rozhraní (Qt) nebo třeba parosvání XML. Python slouží v podstatě jen k rychlému poslepování C knihoven.

[Jiří Němec]

V tom případě musíte sehnat knihovnu, která bude počítat ten hash. Každopádně hodně štěstí a prosím odstraňte ty názvy kolejí z blogpostu.

[Acci]

Nemusím nic hledat, interní knihovna Pythonu hashlib používá hashovací algoritmy z OpenSSL, které patří k jedněm z nejrychlejších. A k odstranění názvu kolejí nevidím důvod, vždyť se nejedná o nic neznámého natožpak nelegálního.

[alblaho]

Zbozňuju lidi, co křičí jak je technologie X pomalá a neschopná, aniž by o ní něco věděli.

Většina programů v Pythonu kupodivu s rychlostí problémy nemá. Samozřejmě proto, že tech 5% kódu, na kterém záleží je typicky v C. Což je z inženýrského hlediska správně - psát GUI nad GTK v čistém C nepřinese žádnou rychlost, akorát mraky chyb.

[Grunt]

Většina programů v Pythonu kupodivu s rychlostí problémy nemá. Samozřejmě proto, že tech 5% kódu, na kterém záleží je typicky v C.

No dobře, ale pak můžeme říct, že Python je dobrý tak max. pro lamy co slepují Céčkovské knihovny. Co když bude chtít napsat novou knihovnu a nebo implementovat nějaký nový důležitý algoritmus? To se asi nižšímu jazyku dost těžko vyhne.

psát GUI nad GTK v čistém C nepřinese žádnou rychlost, akorát mraky chyb.

Asi proto se radši kreslí v Glade a Céčkem pak už jen slepuje.

[alblaho]

Člověk, který použije knihovní SHA-512 místo aby si to psal na koleně je lama?

Když budeš implementovat nějaký nový důležitý algoritmus (patřičně složitý), tak si no nejprve napíšeš v nějakém schopném jazyce (Ruby, Python, Haskell, Scheme, nebo aspoň Java...) a ověříš si, že to funguje. A pokud jo, můžeš z toho udělat knihovnu v C.

Zkrátka, dost často je Python lepší volba než nějaké C, bez ohledu na to jak moc dobrý v tom C jsi. A myslet si, že Python je jenom pro lamy je idiocie: metaprogramování, AOP, DbC, DSL...

Jsou i jiné levely programování než umět zacházet s pointery .

[Grunt]

Člověk, který použije knihovní SHA-512 místo aby si to psal na koleně je lama?

To ne, ale předpokládám, že když chce vyvinout něco echt nového jako je právě tento decentralizovaný cosi, tak se bude muset pustit i do nových algoritmů a knihoven, protože jen poslepovat už něco existujícího a dát tomu nový kabátek asi nebude nic nového.

metaprogramování, AOP, DbC, DSL...

Ani nevím co ty zkratky znamenají.

Jsou i jiné levely programování než umět zacházet s pointery

Já jen že ten procesor nemá dekodér, kupu ALU, kupu registrů a jánevímcoještě jen tak pro srandu králíkům. Nic jiného v tom netřeba hledat.

[Ladicek]

Já jen že ten procesor nemá dekodér, kupu ALU, kupu registrů a jánevímcoještě jen tak pro srandu králíkům. Nic jiného v tom netřeba hledat.

JIT překladač pro Python je ve vývoji

[Grunt]

JIT, JIT. Co já mám z JITu když ten procesorový čas strávený kompilací klidně může propálit někdo jiný?

[Ladicek]

A jéje, zase jeden z těchhle. Nic jsem neřekl, omlouvám se, že jsem vlezl do diskuse.

[Grunt]

Navíc na takovém MIPSelu se kompilace jakékoliv dost hrozím natolik, že se radši pářu i s cross-kompilátorem.

[mess]

Už se moc těším na python hashující takových 10TB dat.

Podle mě mu to nebude trvat o moc déle, než programu napsanému v C/C++, protože ty hashovací knihovny jsou stejně psané jako céčkový modul do pythonu. Pokud se pletu, tak mě opravte

[deda.jabko]

A proč to zde vlastně píši? Zaprvé se vás chci zeptat, jestli má vůbec cenu něco takového psát a zabít tím obrovské množství času, protože i pokud by se mi to podařilo dopsat a byl by to hodně dobrý program, bojím se, že by ho používalo jen velmi málo lidí.

1) timto zpusobem ten program patrne zahubis mozna jeste driv nez budes mit prvni spustitelnou verzi

2) imho v tomto pripade je nejlepsi zkusit si naimplementovat samostatne nektere veci z toho cos vymyslel... uvidis, co te ceka a nebudes muset pokladat otazky typu, jestli je to dobre programovat v pythonu nebo kdovi cem

3) aby takovou aplikaci nekdo zacal pouzivat, mela by bud byt nejakym zpusobem revolucni (na coz zrovna nevypada) nebo by mela umet integrovat ostatni sluzby (napr. to FTP nebo DC)

4) pokud nechces upadnout do depresi, ze delas praci k nicemu, tak bys mel ten program byt schopen pouzivat hlavne ty

zkratka a dobre... nejdriv programuj a pak az vykladej o tom, co vsechno by tvuj program mohl nekdy umet.

[kralyk z abclinuxu]

V čem bude tohle lepší než bittorent - je nějaký důvod proč upustit od BT a používat radši tohle?

K tomu DirectConnectu: Vůbec si z něj neber příklad, to je starej a blbej protokol.

[Acci]

Lepší než Bittorent bude v tom, že nebudeš muset někde shánět .torrent soubory, vše uděláš jednoduše v jednom programu. Lepší než DirectConnect bude ve všem

[abr]

Vuze umi hledat, navic podporuje search pluginy.

[default]

Lepší než Bittorent bude v tom, že nebudeš muset někde shánět .torrent soubory

Torrent souborů je všude mraky. Včera jsem potřeboval stáhnout instalační DVD CentOSu a minimálně půl hodiny jsem propálil jen hledáním mirroru, který má krom torrent sraček i to podělaný ISO. Najít dneska mirror, který opravdu zrcadlí a funguje přes FTP — no, začíná to být složitý, no…

[kralyk z abclinuxu]

Ale na to tu už přece je spousta programů i protokolů.
Gnutella, eDonkey, RetroShare, WASTE, Gazzera, LimeWire, PeerWeb ... atd. atd. etc. etc.

Mám obavu, že toto bude skutečně "yet another..."

[multi]

pokud to ma byt pro koleje tak to vypada, ze by to bylo fakt k necemu dobre

ale bacha at za to nejdes sedet

[Acci]

Za napsání aplikace na sdílení jakýchkoliv souborů? To by snad museli jít sedět třeba programátoři všech FTP klientů a serverů.

[tsLnox]

Nezapomeň, v jaké době a v jakém státě žijeme. Já bych se nedivil už naprosto ničemu...

[kapo]

Pokud hledas decentralizovanou anonymni sit s sifrovanim a vyhledavanim, tak se zkus podivat na http://www.nodezilla.net .

Jinak peknej seznam nejznamejsich p2p siti je treba tady: http://www.p2pxp.info

k.

[unknown_]

Nechapu... trochu se mi chce rict "shut up and hack" ackoliv se to az tak 100% nehodi. Chces neco napsat? Napis to a pis o tom, az bude o cem. Takovyhle obkecavani je na nic, a vetsinou z neho nic neni, zvlast kdyz se neresi dulezity technicky detaily, ale graficka knihovna!

[dark]

Dávám bod. Člověk si často ani nedokáže představit, kolik takový projekt (ať je to cokoliv) může spolknout času - u mě je to třeba Fog;)

[kralyk z abclinuxu]

+1

[xkucf03]

Já zase myslím, že je lepší, když se tu zeptá a lidi mu řeknou, že je to blbost, než kdyby nad tím strávil desítky nebo stovky hodin a až pak zjistil, že to bylo zbytečné.

[unknown_]

Sice mas pravdu, ale predpokladal sem, ze prvnim impulzem pro napsani neceho je, ze to clovek chce pro sebe, pro nekoho, a ne ze se nudi...

[dark]

Python won't survive

Pokud chceš napsat app v PyQt, zkus ještě čisté Qt, uvidíš, že zase tak moooc ti ten python nepomůže.

[xm]

Python FTW!

[Zdenek]

Napsat to muzes, ale bude to k nicemu. V nadchazejici dobe ma sanci uspet jen decentralizovane a plne anonymni reseni. A ktomu se da klidne pouzit bittorent nebo i DC nad takovou siti (jako je treba i2p).

[xkucf03]

Vytvářet nový P2P protokol cenu nemá a je to navíc příliš velké sousto. Co bych ale doporučoval (a uvítal), je nějaká pěkná nadstavba nad Torrenty. Nemusíš vymýšlet nový protokol ani psát GUI klienty* (těch je pro Qt i GTK dostatek) a místo toho se soustředit na nové užitečné věci:

Soubory bude možno hodnotit a psát k nim komentáře. Vyhledávání souborů bude díky centrálnímu serveru velmi rychlé. Ze souborů bude umět získat meta informace, které se pak budou moci využít při vyhledávání nebo informování uživatele před stažením souboru (třeba ID3 tagy u MP3 souborů, rozlišení a bitrate u videa nebo náhled u obrázků).

To je fajn. Ale kvůli těmto věcem není potřeba vytvářet nový protokol. Prostě udělej webové rozhraní (a tracker) k torrentu, které umožní to komentování a hodnocení jednotlivých torrentů. Pak doděláš (klientskou nebo serverovou aplikaci), která ze souborů vytahá metadata (ID3, rozlišení, nebo třeba i vyrobí krátkou ukázku či screenshot) a uloží tyto metadata na server, kde se budou zobrazovat ostatním uživatelům pomocí webového rozhraní. Kromě webového rozhraní bych udělal ještě nějaké XML-HTTP (případně XMPP) API, pomocí kterého by šlo vyhledávat torrenty nebo aktualizovat data na serveru (metadata, komentáře atd.). Díky tomu bude možné udělat tlustého klienta s těmito specifickými funkcemi. Velké plus je v tom, že toho klienta nemusíš psát sám – prostě jen zveřejníš API a pokud ten tvůj výtvor bude za něco stát, jistě se najdou lidi, kteří k němu napíší klienta. Nebo ho napíšeš sám, pokud budeš mít čas a chuť.

Závěr: nový P2P protokol potřeba není, ale pěkné webové rozhraní k bittorrentu ano. Nějaká sice existují, ale nijak moc mě nenadchla (ty, které se mi líbily, byly proprietární, napsané pro nějaký konkrétní server).

*) psaní vlastního klienta s nějakými nadstandardními funkcemi si nech na konec jako třešničku na dortu, ale zpočátku se bez něj určitě obejdeš.

[Trained.Monkey]

Jestli se chces naucit, tak vezmi starou Ckovou aplikaci a prepis ji do modernejsi podoby (Python).