Portál AbcLinuxu, 1. května 2025 03:28
5.7.2006 15:50
David Watzke | skóre: 74
| blog: Blog...
| Praha
Jenom připomínka: nevyužiji. Vypadá to dost blbě...Cože?
5.7.2006 17:05
David Watzke | skóre: 74
| blog: Blog...
| Praha
Nic proti, ale dobře ti tak!
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
4.7.2006 08:36
kozzi | skóre: 55
| blog: vse_o_vsem
| Pacman (Bratrušov)
4.7.2006 08:51
kozzi | skóre: 55
| blog: vse_o_vsem
| Pacman (Bratrušov)
to, za aria2 robi checksumy, to je u bittorent klienta nutne . pre ftp/http ti to nepomoze.
4.7.2006 10:25
kozzi | skóre: 55
| blog: vse_o_vsem
| Pacman (Bratrušov)
((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.))
4.7.2006 11:13
kozzi | skóre: 55
| blog: vse_o_vsem
| Pacman (Bratrušov)
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…
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.
4.7.2006 08:27
4.7.2006 10:46
/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
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.
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
Ostatně je tu vždycky riziko toho, že se kus informace zdeformuje i se svým samoopravným kódem, ne?
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?
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)?
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.
).
Ale měl jsem to ve dvojitých závorkách, vůbec si nemyslím, že se tohle děje.
) 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.
4.7.2006 10:40
kozzi | skóre: 55
| blog: vse_o_vsem
| Pacman (Bratrušov)
Český Telecom? Získejte ještě dnes připojení včerejšími rychlostmi za zítřejší ceny...
4.7.2006 13:10
michich | skóre: 51
| blog: ohrivane_parky
rsync operuje nad sadou souborů, nedělá binární diffy (takže by ten soubor přenesl celej)Není pravda.
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
5.7.2006 17:54
kozzi | skóre: 55
| blog: vse_o_vsem
| Pacman (Bratrušov)
rsync remote:/cesta/k/souboru /cestaúk/souborursync si zjistí, že cílový soubor už existuje a tedy jen porovná změny oproti verzi na vzdáleném počítači.
5.7.2006 19:27
kozzi | skóre: 55
| blog: vse_o_vsem
| Pacman (Bratrušov)
6.7.2006 18:45
kozzi | skóre: 55
| blog: vse_o_vsem
| Pacman (Bratrušov)
4.7.2006 10:28
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…
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.