Wget už nikdy!!! (diskuse)

[brk]

Máš blbě zadané linky na http://aria2.sourceforge.net/.

[Petr Jelínek]

Zajímavý.

Jenom připomínka: nevyužiji. Vypadá to dost blbě...

[miro]

To aj slovaci pisu s tvrdym y. Ze by u vas nebola predpona vy s ypsilonom? ;)

[David Watzke]

Jenom připomínka: nevyužiji. Vypadá to dost blbě...

Cože?

[Kníže Ignor]

publikováno: 08:17

publikování komentáře, na který reaguješ: 08:27

poslední úprava: 08:39

[David Watzke]

Nechápu

[Käyttäjä 11133]

Jo jo, proč asi jsou ty distribuce na těch torrentech, co? Nic proti, ale dobře ti tak!

[xvasek]

Nebo nedělat md5 checksumy.

[happy barney]

hmm, ten, co si mysli, ze program je zodpovedny za chyby na trase, ten vskutku vie, o com vravi

odporucam pozriet si zdrojaky wgetu a pripadnu "zamenu dat" opravit

[kozzi]

Tady nejde o to, že ten program je či není zodpovědný za chyby na trase, ale o to, že wget nedělá kontrolní součty, ale aria2c ano.

[Kyosuke]

Jenom taková blbůstka: Jak si to představuješ s těmi „kontrolními součty“ u HTTP? Podotýkám, že jsem wgetem navazoval už nejeden image (a většinu ne jednou) a po několik let jsem nezažil problém.

[kozzi]

No myslím to, že když stahuju s ftp tak se mi stává, že wget stahuje stahuje a kolikrát i přes velikost souboru.

[happy barney]

to sa stava u niektorych ftp serverov, akceptuju prikaz (tusim reget, ale uz si nepamatam presne), ale subor posielaju znova, od zaciatku.

to, za aria2 robi checksumy, to je u bittorent klienta nutne . pre ftp/http ti to nepomoze.

[kozzi]

ale alspon mam dobry pocit a vsechno zatim funguje tak nevim cim to je.

[Kníže Ignor]

Může třeba začít navázané stahování o pár kilobajtíků dřív a zkontrolovat, jestli to odpovídá tomu, co už bylo dříve staženo.

[Kyosuke]

Dobrý nápad na patch a nový switch, iniciativa se cení, směle do toho!

[Filip Jirsák]

A když neodpovídá, tak co? Ostatně, wget má sloužit ke stažení souborů z internetu, nějakou magii při skládání částí, které k sobě možná patří a možná ne, to už ať si dělá nějaký jiný program. A vůbec, nebylo by lepší tlačit na autory serverů, aby si je laskavě opravili?

[Kníže Ignor]

Tak nemá smysl stahovat dál a říct provozovateli serveru, aby si to laskavě opravil

((No a pokud už teda může být nějaký bajt přenesen špatně, řekl bych, že je docela šance, že taky bude špatně na tom konci, protože pak to spojení spadlo - trasa byla třeba už moc zarušená nebo něco.))

[Kyosuke]

Heh? Já myslel, že TCP jaksi má nějaký ten smysl?

A jaktože jsi mi ukradl patičku, bídáku?

[Kníže Ignor]

Jak může TCP garantovat, že v přenosu nenastane chyba? Nijak. To lze pouze pokud by přenosová cesta byla 100% spolehlivá.

[kozzi]

Prostě může.

[Kníže Ignor]

A jak? Data v paketu se můžou změnit tak, že kontrolní součty budou sedět.

[Filip Jirsák]

Garantovat nijak. Ale checksum v hlavičce TCP paketu nebu úplně omylem… A aby se změnila data paketu i 16bitový checksum tak, aby seděl, to by byla docela náhoda, ne?

[Kníže Ignor]

Jakkoli je to nepravděpodobné, tak se to stát může. Krom toho se nemusí ani měnit checksum...

Prostě garantovat, že odvysílaný bajt bude shodný s tím přijmutým, nelze.

Ale ta věta v tom komentáři byla ve dvojitých závorkách, napsal jsem to jako blbost, která mě zrovna napadla, nad tím jsem nečekal diskuzi

[Kyosuke]

Ano, může. Stejně tak může uprostřed sítě zákeřný hardware NSA, který bude měnit pakety rovnou na aplikační úrovni. Možné je ouplně, ale fakt ouplně všechno.

[Michal Kubeček]

Garantovat nijak. Ale checksum v hlavičce TCP paketu nebu úplně omylem… A aby se změnila data paketu i 16bitový checksum tak, aby seděl, to by byla docela náhoda, ne?

Na to vám typicky stačí v paketu invertovat dva bity na stejné pozici modulo 16 bitů. Než začnete pronášet podobně radikální soudy, račte si zjistit, jak se ten kontrolní součet počítá. Pak si uvědomte, kolik paketů je potřeba na přenesení 10 GB dat, a zkuste aplikovat základní poučky teorie pravděpodobnosti…

[Filip Jirsák]

TCP pakety se neposílají jako bity přímo po drátě, ale jsou typicky zabalené do nějaké nižší síťové vrstvy, která má také své kontrolní mechanizmy. A protože nevím, na jako pravděpodobnost chyby jsou počítány tyto kontrolní mechanizmy nižších vrstev, těžko můžu aplikovat jakékoliv poučky teorie pravděpodobnosti.

Můžu ale zkusit opačný postup. Chyby se podle teorie pravděpodobnosti nebudou vyskytovat jen v paketech patřících přenosu 10 GB souborů, ale v libovolných paketech. Taková chyba se projeví třeba na webové stránce změněným písmenkem, pokud se trefí na nějaký důležitý znak, tak třeba rozpadem layoutu stránky. U obrázku to může znamenat různé deformace obrázku. U stažených souborů to bude znamenat to, že stažený soubor bude mít správnou velikost, ale např. nepůjde rozbalit jako zip, nepůjde spustit jako program, nebo prostě jen nemude sedět MD5 součet.

Ani jednou jsem se s něčím takovým nesetkal u souboru staženého najednou. Vždy byl problém buď ve zkrácení souboru (rozpad spojení), a pokud byl soubor správně velký, ale data nebyla OK, pak to byl vždy soubor stahovaný po částech. Navíc chybných souborů stažený po částech bylo často z jednoho serveru víc, zatímco soubory z jiných serverů byly OK.

Ale možná se začnu vymlouvat na to, že moje překlepy v diskuzích nejsou překlepy, ale chyby vznikají až rušením na sítích, které zrovna kontrolní součty neodhalily

[Michal Kubeček]

Ani jednou jsem se s něčím takovým nesetkal u souboru staženého najednou.

Já ano, dvakrát. V obou případech se jednalo o image CD, tj. soubory o velikosti 600-700 MB. Samozřejmě je pravděpodobné, že něco podobného se stane i u krátkých souborů - jenže když se vám na webové stránce změní jedno písmenko, pravděpodobně si toho vůbec nevšimnete. A pokud ano, nenapadne vás podezírat kontrolní součty TCP.

[Filip Jirsák]

Na stránce to nemusí být písmenko v textu, ale třeba v názvu tagu, změní se ", < nebo >, změní se url, a to už se pozná. Chyba také může postihnout JavaScript, na nevhodném místě obrázku se taky dobře projeví. Když se tahle chyba uloží do cache nebo proxy, objeví se několikrát po sobě. Rovněž můj /usr/portage/distfiles má 1 až 2 GB, krát čtyři počítače, všechno stahováno wgetem, kontrolní součty souborů se tam kontrolují a v těch několika případech, kdy kontrolní součet neseděl, nikdy nebylo chybně pár bitů.

Takže asi mám obrovské štěstí, že jsem se ještě nesetkal s chybou, kterou by některá z vrstev síťových protokolů neodchytila. Nebo kombinace různých kontrolních součtů na různých úrovních protokolů a kvality ppřenosových cest je natolik robustní, že se pro běžné použití nevyplatí nějakou chybu očekávat.

I ty vaše dva vadné obrazy CD bych spíš přisoudil nějakému nedorozumění mezi serverem a klientem, než pokaženému TCP streamu. Samozřejmě nevylučuju, že jste HTTP provoz při stahování sledoval, víte, že to stahování nebylo přerušeno a následně jste si ověřil, že v obraze jsou chybné jeden nebo dva bity. Pak bych připustil, že máte hroznou smůlu, když se vám to podařilo už dvakrát

[Michal Kubeček]

Samozřejmě nevylučuju, že jste HTTP provoz při stahování sledoval, víte, že to stahování nebylo přerušeno

Poznat to na výstupu wgetu není zase tak těžké…

a následně jste si ověřil, že v obraze jsou chybné jeden nebo dva bity

Samozřejmě jsem se snažil zjistit, jak ta chyba vypadá. Chybné bity byly lokalizovány natolik blízko sobě, že mohly být v jednom paketu, a zároveň tak, že by je kontrolní součet TCP pravděpodobně neodhalil.

[Filip Jirsák]

Myslel jsem, že wget umí stavové kódy 1xx a chunked-encoding, takže by mohl soubor dostávat po částech i během jednoho stahování. Alespoň verze 1.10.2 to po zběžném prohlédnutí zdrojáků neumí, tak to asi na chybu serveru nesvalím. V tom případě vás s těmi 2 chybnými bity, které prošly několika checksumy síťových vrstev, pasuji na smolaře roku

[happy barney]

kody, ktore sa pouzivaju na prenosovych linkach, su odolne len do urciteho poctu chyb.

Priklad: kod vie opravit 1 chybny bit a detekovat 2 chybne bity z 16bitovej spravy.
ak sa pokazi bitov viac, moze sa stat aj situacia, ze "opravi" spravny bit na nespravny

[Kyosuke]

Řekl bych, že tuhle vlastnost budou mít asi všechny kódy. Ostatně je tu vždycky riziko toho, že se kus informace zdeformuje i se svým samoopravným kódem, ne?

[Filip Jirsák]

Nezmiňujete ale stejně důležitou druhou stranu: přenosové linky mají spočítánu nějakou chybovost (třeba střední délku mezi dvěma chybami). Samoopravný kód, nebo kontrolní součet, se pak nastaví tak, aby s pravděpodobností x nedošlo k žádné chybě. Ono x si lze libovolně zvolit a v praxi bude nejspíš voleno dostatečně malé x (ne x=0,01 jako u aktuálního startu raketoplánu). Tipnul bych si, že vyhrát ve sportce bude daleko pravděpodobnější, než vyhrát vadný bit v TCP

No ale pokud někdo víte, na jakou chybovost jsou dělané třeba optické trasy, nebo s jakou chybostí počítá ADSL a jakou chybovost mají prohnilé dráty Telecomu, podělte se o informaci s námi. Ať máme co počítat Nějaký ČVUŤák by to mohl vědět, ne?

[Filip Jirsák]

Zatím jsem našel: ethernet požaduje max 1 vadný bit na 10^8 dobrých, běžně se dosahuje 10^12. CAN (automobilové sítě) mají pravděpodobnost výskytu chyby 4,7×10^-11 .

[Zdeněk Štěpánek]

jen detail, CAN neni automobilova sit, ale prumyslova sit (automaty PLC, roboti, rizeni apod) a vymyslel ji bosch pro svou elektroniku do automobiloveho prumyslu, ale dnes se uplne bezne pouziva v jakekoliv prumyslove automatizaci.

[Michal Kubeček]

Technická poznámka: nebavíme se o ethernetu, bavíme se o Internetu.

[Michal Kubeček]

Tipnul bych si, že vyhrát ve sportce bude daleko pravděpodobnější, než vyhrát vadný bit v TCP

Už jste se místo tipování podíval, jak se ten checksum v TCP hlavičce počítá? Podle toho, co píšete, asi ne. Nezapomínejte také, že ten algoritmus byl zvolen před nejméně pětadvaceti lety (RFC 793 je datováno září 1981), kdy bylo množství přenášených dat o několik řádů nižší než dnes. Koneckonců, pokud si dobře vzpomínám, ještě v první polovině devadesátých let veškerou zahraniční konektivitu Československa obstarávala jedna 64 Kb/s linka. Je tak těžké si představit, že tvůrci TCP podcenili rozvoj Internetu stejnou měrou, jakou to udělali, když zvolili 32-bitovou adresu (a ještě s třídními delegacemi)?

[Filip Jirsák]

Na ten checksum v TCP hlavičce jsem se díval před tím, než jsem psal svůj první příspěvek. Uznávám, nebyl úplně přesný, protože na konzistenci přenášených dat se podílí víc checksumy nižších vrstev, než je TCP/IP. TCP/IP neposílá svoje bity přímo po drátech, ale je zabaleno do nějaké nižší síťové vrstvy. Takže nestačí, že vyjde kontrolní součet u TCP paketu, on musí u těch samých dat vyjít třeba i CRC-32, pokud to bylo posláno přes ethernet. WiFi má také svoje kontrolní součty, páteřní spoje je budou mít jistě také. Navíc bych řekl, že kvalita spojů se od roku 1981 spíš zlepšila. Množství přenesených dat nemá na pravděpodobnost chyby v jednom bitu vliv.

[Michal Kubeček]

Množství přenesených dat nemá na pravděpodobnost chyby v jednom bitu vliv.

To jistě ne. Ale že pravděpodobnost výskytu chyby při přenosu 650 MB dat je poněkud vyšší než pravděpodobnost výskytu chyby při přenosu 60 KB dat, to mi, doufám, vymlouvat nechcete.

[Kyosuke]

Třeba tím, že provádí kontrolní součty? Jistě, není to zaručené, ten mechanismus je celkem primitivní, ale dost nepravděpodobné, zvlášť, když je to tam v podstatě „pro jistotu“, protože linky mají chyby ošetřené slušně. Každopádně tam, kde potřebuješ superneprůstřelný přenos, je to do značné míry problém aplikačního protokolu. Ale že by byl "nějaký bajt přenesen špatně, protože padlo spojení nebo byla zarušená trasa nebo tak něco", to mi přijde dost nevěrohodné. Blame the applications™.

[Kníže Ignor]

Ta citace není přesná - píšu tam "protože pak spojení spadlo". To znamená, že ke konci se mohli dít "divné" věci (zahazování paketů, ale mohl být třeba přijat špatný paket - špatná data, součet sedí), které nakonec vyústili až v ukončení spojení (TCP už to nerozdýchalo ).

Ale měl jsem to ve dvojitých závorkách, vůbec si nemyslím, že se tohle děje.

[Zdeněk Štěpánek]

a jak by asi mohl wget delat kontrolni soucty bez prime spoluprace nejakeho programu na strane serveru? to je prece nesmysl....

[Megaherz]

S wgetem namam problemy, stahuju a stahuju a vsechno je OK a OK. Takze problem asi nebude ve wgetu

[brk]

Těžko říct, kde je chyba, ale mám velmi podobné zkušenosti. Někdy v 99, když jsem začínal s Linuxem, jsem taky stáhl nejedno distro, než jsem si našel to pravé. ISO, které jsem stahoval ve Windows Getrightem bylo vždy OK. ISO, které bylo stažené wgetem mělo naopak skoro vždy rozdílné MD5. Jestliže se mi modem dopískal na 26.4kbps a stahoval jsem to pár dnů, tak jsem byl taky slušně naštvaný.

[Filip Jirsák]

A nebude to náhodou problém serveru nebo chyb na trase, a ne wgetu? Pokud totiž data pošle blbě server, wget nemá šanci, jak to zjistit. Tedy mimo toho, že to stáhne znovu a porovná obě dvě varianty.

[Marián Kyral]

A co zkusit rsync? Ten je na opravy poškozených souborů (synchronizaci ) určen.

Takhle jsem si kdysi v pohodě opravil tři blbě stáhnuté isa Fedory. Nejsložitější bylo zprovoznění rsync pod windows. GUI se nějak nechytalo a chvíli mi trvalo, než jsem našel ty správné přepínače.

[fakenickname]

Já vím, že je to rada nicotná, ale stejně. Žijeme v jednadvacátém století. Mít doma internet, pro člověka který ho potřebuje, s nižší rychlostí než je únosná mez, mi přijde jako zbytečný masochismus.

[kozzi]

sice žjeme v 21. století, ale také nesmíš opomenout jednu skutečnost a to tu, že žijeme v české republice!

[Michal Vyskočil]

My možná, Telecom těžko

[Kyosuke]

Tak ze třetiny. Český Telecom? Získejte ještě dnes připojení včerejšími rychlostmi za zítřejší ceny...

[Michal Vyskočil]

Vzhledem k tomu, že ceny připojení obecně klesají, tak ty ceny jsou spíše předvčerejší

[Michal Vyskočil]

BTW: Hezká patička

[trancelius]

když mi nesedí MD5, tak se shellnu na server s tlustším kabelem (100Gbit), ten soubor stáhnu i na něm (je větší šance, že se stáhne nepoškozenej), u sebe i na serveru ten soubor rozdělím na 512 kB fragmenty, ze všech udělám md5tky a porovnám je diffem... ty soubory, u kterých součet nesouhlasí, pak přetáhnu z toho serveru k sobě, zase to spojím a pak už to většinou souhlasí ... něco jako manuální bittorrent chunky :)

[Filip Jirsák]

A nebylo by jednodušší to z toho serveru s tlustším kabelem už rovnou rsyncnout? Odpustíte si to ruční dělení, porovnávání checksumů a opětovné spojování…

[trancelius]

minimálně to ruční dělení bych si odpustit nemohl, protože rsync operuje nad sadou souborů, nedělá binární diffy (takže by ten soubor přenesl celej). Ten server je woody, nemám na něm roota a rsync tam není.

[michich]

rsync operuje nad sadou souborů, nedělá binární diffy (takže by ten soubor přenesl celej)

Není pravda.

[Filip Jirsák]

Opravdu to můžete celé svěřit rsyncu:

Wikipedia – rsync

The recipient splits its copy of the file into fixed-size non-overlapping chunks, say of size S, and computes two checksums for each chunk: the MD4 hash, and a weaker 'rolling checksum'. It sends these checksums to the sender.

The sender computes the rolling checksum for every chunk of size S in its own version of the file, even overlapping chunks. …

The sender then compares its rolling checksums with the set sent by the recipient to determine if any matches exist. If they do, it verifies the match by computing the MD4 checksum for the matching block and by comparing it with the MD4 checksum sent by the recipient.

The sender then sends the recipient those parts of its file that didn't match any of the recipient's blocks, along with assembly instructions on how to merge these blocks into the recipient's version to create a file identical to the sender's copy.

If the sender's and recipient's versions of the file have many sections in common, the utility needs to transfer relatively little data to synchronise the files.

rsync features

• equires no special privileges to install
• can use rsh, ssh or direct sockets as the transport
• supports anonymous rsync which is ideal for mirroring
• …

[kozzi]

a nevis co zadat za parametry rsync aby mi to iso opravil?

[Filip Jirsák]

Podle mě by mělo stačit

rsync remote:/cesta/k/souboru /cestaúk/souboru

rsync si zjistí, že cílový soubor už existuje a tedy jen porovná změny oproti verzi na vzdáleném počítači.

[kozzi]

dik nakonec jsem to nepotřeboval. Aria2 to zvládla sama. Normálně chvilku psal zápornou rychlost a iso soubor se oneco zmencil a pak dotahla zbytek a md5sum(sha1sum) sedi proste nadhera

[kozzi]

Jo a muzu se zeptat na jakej server se shellnes?

[Michal Kubeček]

Doporučuji všem, kdo jsou skálopevně přesvědčeni, že viníkem je stoprocentně wget, protože kontrolní mechanismy TCP protokolu jsou dostatečně neprůstřelné, aby si, až se jim opět stáhne soubor s chybou, zkusili dodatečně porovnat onu chybnou verzi se správnou. Asi budete dost překvapeni…

[jesta.net]

viz http://www.gnu.org/software/wget/faq.html#3.1. Uz jsem si na to taky narazil - starsi verze proste neumi stahnout soubory nad 2GB. Reseni jednoduchy - upgrade wget.

Vinik (pokud si to pamatuju) je pouziti funkce fseek, ktera nepocita s tak velkejma souborama, a proste pretece. Nova verze wgetu pouziva fseek64 - aspon doufam ze si to pamatuju dobre, uz je to dlouho co se tenhle problem resil)