Fórum Root.cz

Hlavní témata => Sítě => Téma založeno: Jan Ťulák 29. 11. 2011, 16:55:08

Název: Přenos souborů s nestabilním připojením
Přispěvatel: Jan Ťulák 29. 11. 2011, 16:55:08
Řeším, jak posílat velké soubory (jednotky GB) přes relativně rychlé ale nestabilní připojení.
Chtěl jsem to řešit přes HTTP s následným navázáním spojení, ale po delší době výpadku (minuty) se prohlížeče (zkoušeno Chrome i Opera) zatváří, že pokračují ve stahování, které ale o vteřinu později "úspěšně" ukončí - aniž by se stáhl zbytek souboru. Použití wget v úvahu nepřichází, potřebuji jednoduché řešení pro windows.

Zkoušel jsem i SCP, ale taky si nedokázalo s výpadky poradit.

V současné době to řeším přes Skype, který po výpadku opět naváže stahování, je to ale takové drbání se levou nohou za pravým uchem, protože musí zbytečně běžet počítač se skype s připojeným síťovým diskem...

Má někdo nápad, jak to vyřešit, například nastavením apache, aby ponechával možnost navázání stahování?
Název: Re:Přenos velkých souborů s nestabilním připojením
Přispěvatel: anonym 29. 11. 2011, 17:47:15
zkusil bych neco zalozenyho na prenosu/kontrole po blokach, treba torrent
Název: Re:Přenos velkých souborů s nestabilním připojením
Přispěvatel: vokurka 29. 11. 2011, 18:13:13
openvpn pres tcp - ozkouseno
Název: Re:Přenos velkých souborů s nestabilním připojením
Přispěvatel: Jan Ťulák 29. 11. 2011, 18:23:51
Openvpn mi sice obnoví tunel, ale i v něm musím nějak přenášet soubory, takže to nic nevyřeší, ne? Pokud teda nějakým způsobem openvpn nedonutí programy přenášející soubor, aby jim nevypršel timeout...

Za torrent díky, to být ono.
Název: Re:Přenos velkých souborů s nestabilním připojením
Přispěvatel: cuketa 29. 11. 2011, 20:35:17
No, to se potom budes pripojovat pres soukromou IP skrz VPN. A jeste to budes mit sifrovany a komprimovany
Název: Re:Přenos velkých souborů s nestabilním připojením
Přispěvatel: Solitary 29. 11. 2011, 20:48:40
Co takhle zsync?
Název: Re:Přenos velkých souborů s nestabilním připojením
Přispěvatel: Jan Ťulák 29. 11. 2011, 21:19:43
Tak s torrentem je problém, že by bylo třeba vytvořit tunel. Co se tunelů týče - nejsou nepřekonatelný problém, ale lepší by to bylo bez nich (šifrovat umí i https). A samotný tunel mi v tomto případě (mimo obejití neveřejných IP pro torrent) nepomůže v ničem, když odpadne spojení, vyprší timeout a stahování se přeruší, i když se pak tunel zase obnoví.

Na zsync se podívám.
Název: Re:Přenos velkých souborů s nestabilním připojením
Přispěvatel: Jan Ťulák 29. 11. 2011, 21:45:10
Tak zsync by byl fajn, ale není pro windows (cygwin v úvahu nepřichází).
Název: Re:Přenos velkých souborů s nestabilním připojením
Přispěvatel: # 29. 11. 2011, 22:12:21
a proc nepouzit klienta, co umi automaticky navazat na spadly spojeni ... napr http://jdownloader.org/  (+ urcite spousta dalsich), mluvim tady o beznym http(s) prenosu
Název: Re:Přenos velkých souborů s nestabilním připojením
Přispěvatel: DarkKnight 30. 11. 2011, 00:44:23
jaky je problem u torrentu s navazanim stahovani? torrent stahuje po blocich velikych nekolik malo kilobajtu, proste se stahne znovu dany blok, pokud nebyl stazen cely

jedinym "problemem" u tohoto je vytvorit tracker, jinak pouzit napr vyse zmineny jdownloader
Název: Re:Přenos velkých souborů s nestabilním připojením
Přispěvatel: KapitánRUM 30. 11. 2011, 03:02:31
Cesta je hrozně snadná, jde to buď skriptem nebo si napsat malý prográmek.

Následuje řešení, jak jsem to udělal na jedné prolhané a padavé lince.
Linka totiž nejen že padala, ale čas od času si data vymýšlela.

Popis řešení:
V adresáři PRENOS se objevil soubor.
A) došlo k zabalení zdrojových souborů na jednotlivé soubory archivu o velikosti 300KB s výstupem do adresáře ZABALENO, název archivu odpovídal datu, přípona pořadovému číslu kabinetu archivu, to se všechno dá nastavit snadno na widlo i Linuxu
B) zdrojový soubor byl automaticky odstraněn (to udělá parametr archivačního programu) a skript pro každý soubor přidal CRC soubor (to umí některé archivační programy a jde to i utilitou)

Obsah adresáře ZABALENO pak vypadal nějak tahle:
010120112205.r01
010120112205.r01.crc
010120112205.r02
010120112205.r02.crc
(V posledním kroku se vytvářel CRC soubor, proto nemůže dojít k tomu, aby se začal stahovat ještě nezkopírovaný soubor.)

C) skript na cílovém počítači se připojoval na zdrojový stroj a prohledával adresář ZABALENO, jestli v něm není nějaký soubor CRC, pokud nějaký CRC soubor našel, zkopíroval si ho k sobě, otevřel, zjistil jméno původního souboru a ten zkopíroval k sobě.
Pokud CRC seděl, pak odstranil zdrojové soubory, pokud ne, tak smazal přenesený CRC soubor (co kdyby chyba byla v přeneseném CRC souboru) a restartoval se.

Jak vidíte, je to o nastavení Cronu a vykoumání pár parametrů.

Trochu nějaké logiky je jen v tom bodu C, kde nejprve vyhledáte první soubor CRC (to je přece směšně snadné), vyparsujete z jeho názvu název origo souboru (to jsou jen čísla např. 010120112205.r01.crc -> pokusíte se zkopírovat soubor 010120112205.r01), pokud CRC sedí, což zjistíte zavoláním utility a vyhodnocením jejího návratového kódu -> a když je kód OK, tak skriptem smažete soubory ze zdroje, pokud ne, tak smaže místní CRC i špatně stažený soubor.

Názvy originálních souborů opravdu doporučuji pojmenovávat automaticky číselně podle data.
Totiž řetězec jako je tento: 010120112205.r02 se snadno parsuje!

Šlo by udělat podstatně lepší a robustnější řešení, ale tohle je prostě hrozně jednoduché.

Bittorent použít lze, je to dobré řešení, kde můžete nastavit vytížení linky, ale musíte mít pořád spuštěný bittorentový server.
Skript má tu výhodu, že se spustí 1x za hodinu, pokud nějaké soubory najde, tak je přesune, pokud ne, tak chrápe a nevytěžuje paměť serveru.
Název: Re:Přenos velkých souborů s nestabilním připojením
Přispěvatel: Jan Ťulák 30. 11. 2011, 09:03:10
S torrentem jsem skončil na tom, že podle všeho musí aspoň jeden účastník mít veřejnou IP, proroutování portů zřejmě nestačí.

jdownloader bude asi nejlepší řešení. Nenapadlo mě ho zkusit, protože jsem tak nějak (trochu nelogicky) předpokládal, že když blbne navazování spojení u downloaderů v prohlížečích, budou blbnout i specializované programy. Umělým testem to prošlo, takže uvidím v ostrém provozu.

Každopádně díky za rady, kdyby to nějak blblo, zkusím v dalším kroku kapitánův způsob.
Název: Re:Přenos souborů s nestabilním připojením
Přispěvatel: KapitánRUM 30. 11. 2011, 13:12:16
Jestli linka padá, měl bys to řešit tím skriptem, jinak se budeš divit.
Název: Re:Přenos souborů s nestabilním připojením
Přispěvatel: Veverak 30. 11. 2011, 20:42:40
Rsync - program ktery zajistuje synchronizaci adresaru s tim ze kopiruje jen rozdily v souborech... tj. kdyz 1/2 souboru neni tak jen pokracuje v kopirovani

hlavne nepracuje s nicim specialnim jen s adresari, a v praxi by pro tebe uz nemel byt problem nazdilet adresar z windows stanice na linux stanici...

Název: Re:Přenos souborů s nestabilním připojením
Přispěvatel: KapitánRUM 30. 11. 2011, 20:59:27
Rsync je naprosto super nástroj, ale na chybující lince (mě) zlobil.
To, jestli bude zlobit i v tomto konkrétním případě nevím.
Název: Re:Přenos souborů s nestabilním připojením
Přispěvatel: Veverak 30. 11. 2011, 21:03:55
no, mne moji linku uspesne shazoval (par slabych clanku..... zejmena prehrivajici se wifi v notesu) ovsem vzdycky po shozeni to slo v pohode obnovit a nikdy nejel znova, takze pro ucely zde popsane :-)
Název: Re:Přenos souborů s nestabilním připojením
Přispěvatel: sanoma 30. 11. 2011, 23:35:21
Byl by problém použít wget pro windows z projektu GnuWin32?
Název: Re:Přenos souborů s nestabilním připojením
Přispěvatel: Jan Ťulák 01. 12. 2011, 00:41:07
KapitánRUM: nestabilita není taková, že by docházelo k pádům každých pár minut, obvykle to jede v pohodě, dokud se nenechá něco běžet, zatímco u toho člověk není (signore Murphy :D ). Pokud se neobjeví problémy se špatně přenesenými daty, stačí řešení přes downloader.

Rsync mi v tomto případě připadá taky trochu jako zbytečně složité řešení, když je dostačující použití downloaderu přes HTTP.

wget z gnuwin bych stejně musel obalit skriptem, který se bude ptát na URL - jdownloader svůj účel splní stejně dobře.