Názory k článku
Jak rychle poslat velký objem dat? Přes úschovnu

Dobrý den,
Úschovna.cz patří mezi nejstarší tuzemské služby, které slouží k zasílání souborů. Povědomí o této značce je proto mezi uživateli tradičně velmi silné. Já v článku také uvádím, že se jedná o zřejmě "nejznámější" file hosting. V otázce "nejoblíbenějšího" file hostingu pak samozřejmě záleží na preferencích každého z nás.

Ondřej Špulák

Já také ne. Za to, od té doby co jsem na ulozto.cz objevil funkci Vyhledavani, muj zivot uz nebude nikdy takovy jako driv.

že je nejstarší automaticky neznamená že je nejznámější, možná spíše naopak

No osobně jsem o uschovna.cz také nikdy neslyšel, jak jsem ji viděl na začátku, okamžitě mi to evokovalo PR článek.

Nejznámější CZ filehostingy jsou ULOZ.TO (kde ale dost nešikovně udělali premium, se mi zdá), EDISK.CZ (v dnešní době nejlepší varianta). Share-rapid.cz, co vím, je svinstvo.

No pokud bych chtěl někomu poslat velký objem dat který už se nehodí do emailu tak ho hodím na FTP. Posílat soubor o velikosti stovek megabajtů přes webové rozhraní a pak ho tak i stahovat je šílenství.

A pokud by to mělo být opravdu několika gigabajtový balík dat tak to nahraju na DVD nebo flashku a pošlu to poštou doporučeně :D Adresát to bude mít druhý den já ani on nebudeme muset trávit několik hodin posíláním a stahováním dat u internetu :D

Ve všech případech data samozřejmě zašifrovaná, to je jasné. Ale posílat to na nějaká pofidérní webová úložiště, nebo za to ještě platit přes SMS? To opravdu ne...

presne tak!

Všechno z toho, co zmiňujete, jsou použitelné metody, které mají výhody a nevýhody.

Ne každý má možnost FTP použít (nebo jako BFU o této službě ani neví). Služby založené na HTTP protokolu jsou dostatečně intuitivní, protože uživatelé mají potřebný „nácvik“ z příkládání příloh k mailu ve svém webmailu.

Posílání souborů na datovém nosiči klasickou poštou znamená zaplatit poštovné, zajít na poštu nebo k nejbližší schránce a na straně příjemce nejméně jeden den čekání, bez garance doručení do druhého dne. Anebo zaplatit dražší expresní nebo kurýrní službu.

Stáhnout jeden větší soubor z internetové úschovny (víc souborů může odesílatel zabalit do jednoho) za předpokladu, že vám nepadá připojení, není problém, během stahování můžete dělat svou běžnou činnost dále. S HTTP uploadem velkých souborů osobní zkušenost nemám, zatím jsem to vždy řešil SCP nebo SFTP uploadem na náš WWW server; internetové úschovny využívám často jako příjemce.

Pozor - přijde nečekané odhalení. Ne všichni žijí v Praze!

A s tím trochu souvisí to, že mimo Prahu (velká města) to taky není s rychlostí připojení žádná sláva a pořád může být výhodnější to vypálit / nahrát na flashku a poslat poštou / po někom, než to půl dne uploudovat přes ADSL 512 1:50 a druhou půlku to bude někdo tahat k sobě. Obojí za cenu, že si nikdo z firmy nestáhne ani kurzovní lístek.

Bohužel, IETF v této problametice totálně zaspalo. Chtělo by to RFC, které by umožnilo posílat mailem velké soubory. Ať přímo, nebo s uložením někam na server a stažením na základě klíče poslaného mailem...

Z hlediska uživatele by to mělo ideálně vypadat tak, že prostě k mailu přiloží soubor a nemusí řešit, že do téhle velikosti se dá přiložit k mailu, do jiné ho musí někam nahrát a poslat jen odkaz.

Na to není potřeba žádné RFC. Tohle může implementovat jakýkoliv e-mailový program: 1) velký přiložený soubor nahraje na nějaký server dostupný přes HTTP (je jedno jak - přes FTP, na jabber disk, něco jako dropbox, MS Sky Drive ...) a 2) odkaz na soubor vloží na konec těla e-mailu.

Příjemce pak klikne na odkaz (obsahující třeba nějaký hash pro zabezpečení), a žačne stahování přes HTTP. Závěr: nároky na příjemce žádné (jen možnost stahovat z HTTP adresy), implementace u odesílatele libovolná podle možností. Proč to ještě nikdo neudělal a nerozšířilo se to? Nejspíš proto, že není nějaké obecně (nejlépe zdarma) dostupné online úložiště.

Možné vylepšení, ke kterému by bylo vhodné mít RFC by spočívalo v tom, že se k e-mailu přiloží odkaz na soubor s nějakým speciálním content-type, a e-mail klient příjemce by ho transparentně zobrazil jako "obyčejnou" přílohu.

No právě, není nic "obecně rozšířeného", protože to není nijak standardizováno. Na každé úložiště se nahrává jinak a MUA obecně netuší, na jakém URL se příloha objeví. Tedy možnost atomatizace jen pro konkrétní případy, obecně nula.

Chtělo by to, aby to byla featura SMTP protokolu / serveru. MUA by řekl SMTP serveru "mám tu velkou přílohu, posílám" a SMTP server by mu odpověděl "OK, bude přístupná na tomto URL". Pak by stačilo jen správně nakonfigurovat SMTP server (což udělá admin, to jde mimo BFU) a mít klienta podporujícího RFC a vše by fungovalo.

SMTP server by uložil a poskytoval přílohu sám, nebo by se mu dal nakonfigurovat FTP server, kam by to hodil...

Mohl by na to být speciální content type nebo tak něco, MUA nepodporující RFC by měli v textu odkaz, MUA RFC podporující by mohli přílohu automaticky stáhnout / nějak to uživateli "hezky" zobrazit atp.

Potíž je v tom, že tohle by nefungovalo pro "legacy" SMTP servery (ty, co to ještě nepodporují). Teoreticky by stačila podpora prvního SMTP serveru, přes který e-mail posíláte. Málokterý poskytovatel vám ale bude jen tak poskytovat prostor o kapacitě stovek MB jako úschovnu.

Ale třeba takový Gmail by to mohl implementovat i pro SMTP protokol, a případně to může být transparentní pro klienta, který by neuměl tuhle signalizaci.

Ale momentálně je zásadně jednodušší tohle implementovat ve webovém rozhraní, kde lze uploady velkého objemu a mnoha souborů řešit elegantně pomocí Flashe nebo Javy - funguje to fakt hezky. Použít jednou za měsíc při odesílání "velkého e-mailu" nějakou dobře udělanou úschovnu, to není problém".

Sám to mám takhle udělané na hostingu: 1) otevřu v browseru URL ze záložky, 2) kliknu na "nahrát soubory", 3) vyberu adresář k nahrání, 4) vidím průběh uploadu, 5) do schránky se mi vloží link, který dám do těla e-mailu. Je to prostě jednoduché, a v integraci do mail klienta nevidím moc výhodu.

Ano, stačila by podpora prvního serveru, tedy typicky firemního, eventuelně u mého poskytovatele.

Na starých SMTP serverech by to samozřejmě nefungovalo a muselo by se to řešit jako doteď, ale znamenalo by to zachování stávajícího stavu, ne zhoršení.

Jenže ne každý má podobnou aplikaci na hostingu. Ona je vpodstatě jednoduchá, komplikovanější věc je, "kdy smazat uložený soubor". Adresát si přečte mail, soubor stáhne, ale pak ho omylem smaže, k mailu se po nějaké době vrátí a soubor už stáhnout nejde. Zde by byla také malá výhoda standardizace - MUA by mohl přílohy stahovat automaticky.

No sice pořád nechápu k čemu potřebujete standardizaci v IETF, ale pokud máte ten pocit, tak navrhuji, že byste to I-D napsal. IETF není žádný magický mozek lidstva a pokud tu práci někdo neudělá, tak se sama nestane. I-D můžete podat jako individual submission nebo si najděte nějakou pracovní skupinu (tak od oka by se to mohlo hodit do yam).

+1 :-)

Obavam se, ze dochazi k nejakemu totalnimu nedorozumeni na tema, co je to vlastne IETF a jak vznikaji standardy. Neco podobneho jako kdyz se v diskusi o IPv6 objevilo, ze ho IPv6 navrhovali akademici.

Ale SMTP s velkými soubory nemá žádný problém. Jediná komplikace je, že base64 kódování nafukuje velikost dat.

Další podstatná komplikace je ta, že si SMTP neumí rozumně poradit s přerušením spojení. Takže když se odešle 150 MB a spojení se rozpadne, musí se příště začít zase od začátku.

To určitě není neřešitelný problém :-)

To není, i když vzhledem k tomu, že může existovat mnoho cest, přes které servery se e-mail bude posílat, bylo by to docela komplikované. Ale než to hackovat do SMTP a do programů, to je jednodušší použít nějaký jiný protokol, který už to umí.

A který protokol umí provést úkol "tenhle velký soubor přenes člověku s touhle emailovou adresou"? Řekl bych, že žádný ;-)

Nevím odkud máte informaci o tom, že "většina" serverů odesílá emaily sériově. Má zkušenost naopak říká, že většina SMTP serverů je standardně konfigurována na paralelní odesílání.

IETF totalne nezaspalo. IETF se neridi tim, co chteji uzivatele, IETF se ridi tim, co je dobre pro sit.

Montovat dalsi funkcionalitu do SMTP je cesta do pekel - napriklad kvuli overheadu nebo principu nekontrolovaneho "store and forward".

Nebo Ty bys rad, aby Ti chodily desetimegabajtovy spamy? Ja ne.

Navic ... IETF je otevrena platforma pro diskusi, ale nejak si nevzpominam, ze bys v nejake z WG toto tema otevrel. Samozrejme nesleduju vsechny ... rad se budu mylit. V takovem pripade Ti patri moje hluboka a uprimna omluva.

Samozřejmě posílat přímo v mailu není ideální, ale v tom uložit bokem a poslat odkaz nevidím problém (takže 10M spamy by nechodily). Koneckonců, je to totéž, jako se děje už dnes, jen by to bylo více uživatelsky přítulnější.

Ad IETF: Bohužel, ani já nejsem dokonalý a nemám kapacitu napravovat všechny nedokonalosti tohoto světa ;-)

Dokonaly nejsme asi inkdo, tim mene ja.

Ale kdyz uz kritizujes nejakou organzaci, mel by sis o jejim fungovani neco zjistit :-)

jinak riskujes, ze budes pusobit ponekud komicky.

Aha, odtud vítr vane :-) Mohu Tě ujistit, že můj první příspěvěk nebyl míněn jako kritika IETF, ale jako idea, jakou cestou situaci zlepšit.

Mimochodem, _vážně_ si mysíš, že se někdo v IETF bude seriózně zabývat návrhem člověka, který nemá v rámci IETF žádnou historii a ani není významným členem nějaké velkého komerčního nebo akademického subjektu z oboru? Nadto když ten návrh řeší problémy, které mají prakticky výhradně BFU a techniky, tedy členy IETF moc nepálí? ;-)

IETF jsou pracovni skupiny. A v pracovnich skupinach se seriozne zabyvaji i vetsima kravinama nez je ten Tvuj.

Samozrejme, pokud mas nakou historii, tak je to lepsi.

Prosim zastav dalsi diskusi na toto tema, dokud nezjistis, jak IETF funguje. Nijak netouzim byt IETF verozvestem :-)

"IETF totalne nezaspalo. IETF se neridi tim, co chteji uzivatele, IETF se ridi tim, co je dobre pro sit."

A o tom, co je dobre pro sit, rozhoduje IETF... :-) To zni skoro jako z Orwella.

Nastesti clenem IETF je kazdy, kdo se za clena IETF povazuje :-)

Data do nějakých 200 MB posílám FTP na svoje WWW (to co nechci aby bylo úplně veřejné do adresáře s řízeným přístupem a šifrované). Ale pokud jde třeba o fotky z nějakých akcí, které bude stahovat spousta lidí, nebudu si plácat traffic a pošlu to na nějakou úschovnu. U dat v řádu GB bych to taky poslal na DVD.

nahrávat něco na CD nebo na DVD? posílat "analogovou" poštou? proboha to je návrat do středověku!!!

Jak rika jedno stare moudro - nikdy nepodcenuj datovou prenosovou kapacitu kamionu nacpanyho disky nebo paskami v pripade.

Pro odesilani velkych souboru se take da dobre pouzit IM.

Skype to zvlada i kdyz jsou oba za NATem, ale rychlost je silene pomala, protoze to jde pres nekoho tretiho. Pokud ma aspon jedna strana verejnou IP je to v pohode a jede se plnou rychlosti.

myslel som ze sa tu hovori o VELKYCH suboroch(0.5-10GB) a nie o 15 fotkach z dovolenky

Sice mám 8 Mbit rychlost stahování, ale 0,5 Mbit "rychlost" uploadu. A to se opravdu nic velkého nedá... mám pronajatý server, takže často posílám i na něj nějaká data, takže by se mi větší rychlost hodila i za příplatek. Provider mi ale sdělil, že navýšení uploadu není možný. Tak mám smůlu...

Předpokládám že "rychlé" ADSL. S tím se bohužel fakt nic dělat nedá, jedině přejít na bezdrát.

Nevím proč je ten nepoměr mezi down a up tak veliký..
Pochopím že je ale proč tak velký? :D
Proč to není třeba jen 4:1

příklad nabídky z praxe: 16384/512
tedy 32:1

Protože se vyšší upload nedá marketingově prodat, lépe řečeno ho nikdo prodávat nechce. ADSL2+M (kterou teda 02 nepoužil) umožňuje na up až reálných 2,5 Mb.

Bohužel ne, jedná se o bezdrát v pásmu 5 GHz.

Tim by se vysvetlovalo, proc se mi nektere filmy nepodari prehrat ani s temi nejnovejsimi kodeky. :)

Kdo využívá Dropbox nebo podobnou službu, tak je to pro něj asi nejlepší. Nakopírovat do public složky a poslat link.

Kdyby provideři poskytovali opravdový internet (každý uživatel vlastní IP adresu, žádné filtrování, NAT apod.) jednoduše by se mohly spojit počítače mezi sebou přímo a žádné úschovny by nebyly potřeba. Potom by se mohlo naplno říct, že všechny ty úschovny jsou primárně určeny na šíření warez.

Ne. Chci teď poslat Frantovi 100 MB soubor, ale Franta bude u počítače až zítra dopoledne v práci. To mám kvůli tomu nechávat zítra od rána celý den doma zapnutý počítač, aby si to mohl stáhnout? Když doma celý den nebudu? Nebo mám jen notebook, který budu potřebovat ráno odnést...

Nebo mám pomalý upload, a ještě nestabilní připojení, a Franta má v práci rychlou linku, tak proč by on měl čekat, když přes úschovnu se mu to stáhne řádově rychleji?

Je třeba se oprostit od vnímání "u počítače sedim furt, a vypínat ho je škoda". Normální lidi počítač zapnou třeba jen na 2 hodiny denně.

Počítač se dá zapnout i na dálku. Poslat to přímo z jednoho počítače na druhý je opravdu ten nejpřirozenější a nejefektivnější způsob, jak si data poslat. Bohužel funguje jen na internetu ale ne na celosvětovém propojení NATů.

A slyšel jste už slovo "firewall"? ;-)

Firewall má za úkol propouštět jen chtěnou komunikaci a tu ostatní zastavit. Pokud si ho někdo nakonfiguruje špatně a zablokuje si i tu chtěnou, je to jeho problém. Třeba k webovému serveru lze takhle taky zablokovat přístup, a nikdo to nepovažuje za problém HTTP protokolu nebo tím neargumentuje proti používání webu.

este sa da vycvicit domace zviera(macka, pes) aby ho Fero prezvonil, ono si zapne komp , vygeneruje secure key, nasharuje mu subory...
ale preco to riesit jednoducho, ze?

O Wake On LAN jsi někdy slyšel?

noo, skuste mi prosim poslat jednoduchy navod (pre ucitelku v skolke) ako sa to da cele jednoducho(12 minut max.) nastavit(Wake on Lan,Sharovanie - samozrejme zabezpecene) ... dufam ze ten navod bude jednoduchy a univerzalny - tj. bude fungovat za NATom, proxy,u nejakeho obskurneho lokalneho poskytovaleta netu
dakujem

Řešením není vymýšlet „jednoduché návody“, jak obejít NAT. Řešením je NAT zrušit a přejít na IPv6. Když pak bude běžné, že jsou domácí počítače z internetu přístupné bez hackování NATu, nějaké řešení se určitě uchytí – WoL bude umět poslat váš domácí router. Celé „nastavení“ pak bude spočívat v tom, že si zvolíte nějakou adresu (jako si dnes volíte třeba e-mailovou adresu na freemailu) a zadáte jméno a heslo.

Jasně. Ještě štěstí že IP je neomezený počet, co? Protože jinak by mohl být trošku problém aby měl každý svoji ;-)

To je klasický problém vejce a slepice. Adres protokolu IPv4 je opravdu málo na to, aby každé zařízení (včetně přehrávačů atd.) mělo svoji adresu. Proto se vymyslel NAT, aby se více počítačů schovalo za jednu adresu. To bylo v dřevních dobách internetu.

Protokol IPv6 poskytuje dostatek adres, ale provideři se do něj nehrnou, protože mají zavedené NATy a nechtějí na tom cokoliv měnit -- například můžou prodávat pevnou veřejnou adresu za zvláštní příplatek.

A mimochodem, IP znamená internet protocol a bylo by záhodno, aby jich moc nebylo.

Snad u všech ISP od nějakého počtu adres, které vám přidělí, závisí platba právě na jejich počtu. Někde se platí už za první, někde je to jinak (obvykle v závislosti na celkovém měsíčním plnění - jestli jim necháváte pár stovek nebo pár desítek tisíc).

Účtuje se to třeba jako "administrativní poplatek spojený se správou přidělených adres", což je pravděpodobně neprůstřelné.

Tak předně, provider IP adresy neprodává, ale propůjčuje nebo poskytuje do užívání po dobu trvání smluvního vztahu, ale pokud je to jen hraní se slovíčky, které na možné porušení pravidel RIPE nemá vliv, pořád má provider možnost definovat různé programy služeb, které se budou lišit i v něčem dalším než jen přidělení veřejné nebo privátní IP adresy, a pochopitelně balíčky s veřejnou IP adresou budou dražší než s adresou v privátním rozsahu.

Aha, a pokud chci poslat 10 lidem 150 MB dat (třeba fotek), tak to budu posílat každému extra a v době, kdy si určí? To mi přijde jednodušší nahrát to jednou a poslat 10 odkazů.
Ano při nutnosti poslat třeba grafické podklady od člověka k člověku by to smysl mělo, ale zase - pokud to potřebuju (klient mi posílá věci k úpravě), nahraje to přes FTP ke mně a já si to stáhnu.

Nějak jste tam zapomněli napsat že na ulozto lze stahovat soubory z rapidshare.

To se mi zdá jako velký plus !!!

Čao

To teda jo ! Uz jsem si tam stahl hafec hustejch veci

Diky za ulozto !

.. z jaké planety? :)

"Ještě před pěti lety se zdálo být nereálné, abychom prostřednictvím Internetu běžně posílali či stahovali stovky či dokonce tisíce MB dat."

Fakticky? Autor asi nezažil Internet mezi lety 1999 a 2001, kdy fungoval Napster. Už tehdy se uplně normálně přenášela data po Internetu a byly to normální sady MP3ek, takže desítky a stovky MB na jedno album.

Dattelkabel (později pohlcen UPC) v Praze rozjel Internet po kabelovce taky v roce 1999. Alespoň na sídlišti kde jsem tehdy bydlel. A rychlost byla tehdá "neomezená", limitovaná 10 mbps, což byl strop tehdejších Nemo modemů.



"Zatímco v dřívějších dobách postačil k poslání souborů e-mail, dnes je nejvhodnějším řešením použití internetové úschovny."
To je taky perla. :)
Já to vidím přesně naopak. Zatímco dříve byl téměř nepsaný zločin poslat mailem větší přílohu, dneska si lidi nedělají starosti s 10 MB i většími přílohami do mailů.



Jinak na přenos souborů po Internetu je už od jeho prapočátků protokol FTP.



Zbytek článku nehodnotím, srovnání web úschoven je samozřejmě chválihodné. Ale ten úvod mě prostě přišel jako drobný fail. :)

Rychlý internet tu byl už dřív, ale každý nebydlí v Praze, kde jsou nový technologie spuštěný rychlejc. Já jsem ještě před pěti lety používal internetovou přípojku s omezeným FUP, takže jsem si o nějakým posílání velkejch dat mohl nechat jenom zdát... Při přenosu objemnejch dat se mi pak úschovny hodily a využívám je prakticky dodnes... e-mailem běžně nepošleš přílohu o velikosti 200 MB :-)

Tak je mi jasné že rychlej Internet není všude ani dneska.
Ale zas bych se neodvolával jen na Prahu. Bezdrátoví ISP umí taky co do rychlosti často divy. A rychlý Internet nabízeli již i dřív.

btw, posílat 200 MB soubor emailej je blbost, o tom žádná.
Ale nahrávat to na nějakou webovou "úschovnu" mi přijde jako stejná blbost. :) Od toho je prostě FTP. A když na to přijde, stáhne si to člověk z jednoduchého http odkazu. Ale využívat na to webový služby, kde člověk musí vyplňovat nějaký captcha ochrany atp, to je fakt extrémní nouzovka.
I když chápu, že BFU často nic jiného neumí.

Jedna věc je umět, a druhá věc je mít k dispozici FTP server :)

Ano a vsechny tyhle uschovny, profitujici z toho, ze na sebe lide nevidi, mozna pomrou az se konecne lide dostanou na IPv6 a budou si moct ty soubory vymenit naprimo pres svuj oblibeny IM program.

Asi jsem zvláštní, ale mám na svém počítači HTTP server, soubor tam prostě vypublikuji a pošlu odkaz.

Nebyl by na to lepší FTP server?

Proč? FTP osobně hodnotím jako značně zastaralý protokol, ty čachry s porty a kontrolními kanály… Samozřejmě ani HTTP není úplně ideální a proto pokud bych potřeboval přenést víc něčeho většího, tak bych spustil rsync.

Řídícími kanály, už jsem se na ty opakované špatné překlady z angličtiny (control → kontrolovat, i když by tam mělo být spíš ovládat/řídit) také chytil…

Autor ještě zapomněl zmínit Nahraj.cz, které sice není kdovíjak vychytané, ale úschovu a stažení dat zvládne a je úplně zadarmo..

Zajimal by me zpusob vyberu prezentovanych projektu, chybi napr. Hellshare.com ...

Navic imho autor mota hrusky s jabkama. Leteckaposta, Depo a spol. jsou imho vetsinou pouzivane pro jednorazovy prenos souboru vs. uloz.to, edisk, cz-share,... jsou masovy filesharingy s free/placenymi downloady.

trochu mi tam chybi xdisk.cz. oproti zminenym ma mnoho vyhod - vetsi soubory a je rychly