Robustnější alternativa k FTP pro přenos souborů
Zdravím a pozdravuji,
Nemáte někdo ozkoušenou alternativu k FTP, pokud možno robustnější a "inteligentnější"?
Momentálně používám k přenosu souborů po Internetu (v CZ, cca 50km vzdálenost) Filezillu server i klienta, nejnovější verze stažené z netu.
Stává se mi více než často, že při přenosu např 1,5GB souboru se přenese jen 1.2GB a přenos se típne, resp. ukončí se přenášení souboru a Filezilla se začne pokoušet znovu navázat spojení a dotáhnout zbytek, ale nepodaří se jí to, stále má problémy jakoby velikost již staženého souboru odpovídala velikosti zdrojového souboru, ale část dat tam není, resp. je nahrazena nesmysly (nechal jsem to přes noc a žádná změna).
Jindy zase přenese všechno a tváří se, že vše OK, nicméně nesedí MD5 zdrojového a cílového souboru.
Hledám nějaké automatické řešení pro spolehlivější přenosy - např. aby si ve výše uvedeném případě ten 1.5GB soubor rozkouskovalo na deset částí, přeneslo je, ověřilo MD5 vůči zdroji, nesedící části by stáhlo znovu a nakonec vše spojilo a znovu ověřilo MD5. Možná to umí nějaký jiný FTP server? Hrál jsem si i s RSyncem, ale zatím ne moc úspěšně.
Server i klient běží na Windows.
Děkuji.
1. tvůj zásadní problém není FTP, ale nespolehlivé linky
2. tvým řešením by mohl být unison, věnuj se však pečlivě zabezepčení, speciálně pak šifrování přenosu.
Tak už jsem našel příčinu - na straně klienta je použit adsl router TD-W8901GB. Pokud ho nahradím za historický Siemens Santis 150, vše funguje korektně.
Uvedený TP-link router nicméně mrší SIP hlavičky u VoIP telefonu, který je k němu též připojen, takže to mršení muselo být vypnuto přes telnet "ip nat service sip sw off". Nevím, co všechno ještě mohlo být tímhle příkazem ovlivněno.
Každopádně malé (desítky MB) soubory se přenesou korektně, velké (stovky MB) se přenesou do 100 procent, ale přenos se neukončí a zůstanou viset. Pokud přenos odstřelím na straně klienta, je soubor poškozen. Pokud přenos odstřelím na ftp serveru, je soubor v pořádku. Nemá někdo nějakou představu, co na routeru bych měl zkontrolovat?
Na strane routru pozri jeho dodaci list a posli ho na reklamaciu. Nevidim dovod preco by mal zakaznik riesit problemy cisnky vyvojarov.
To je jedna možnost a hypoteticky vzato je možné, že se podaří domoci vrácení peněz.
Nicméně který router dneska není vyvíjený v Číně a bude mi garantovat, že má sw vyladěný?
To bych taky mohl ztvrdnout v bludném kruhu zkoušení a reklamací.
Ten historický Santis pro změnu píská jak prase.
Pokial sa jedna o dsl tak u mna SMC, v zavese za nim Zyxel.
Tak třeba Zyxel P-660R-63C mrší SIP hlavičky úplně stejně.
Tak zrovna R nepoznam, ale HW robia s VOIP bez problemov.
zkus ještě na PC nastavit MTU u síťovky na 1492 bajtů.
Na PC, kde je FTP klient nebo FTP server?
na PC za tím failujícím DSL modemorouterem.
Tak tuhle volbu tam nemám. Bylo tam disabled. Zkusím tedy nastavit 2K, jestli se to zlepší.
[img=/file/view/7404-jf-png]http://pc.poradna.net/file/view/7404-jf-png[/img]
Jumbo frame s tym nemaju nic spolocne (pouzivaju sa len na gigabitovych sietach), MTU nastav na routri nie na klientoch.
já teda na síťovkách mtu nastavit nemůžu a na routru jo- jak jsi psal, ale zajímalo by mě, co to je ten sloní rámec?
podle http://cs.wikipedia.org/wiki/Maximum_transmission_ unit to má něco společnýho. proč tw radí nastavit menší packet? není to po selsku tím, že něco nestíhá? díky za objasnění.
na síťovkách to jde: Change the Maximum Transmission Unit (MTU) Size
test průchodnosti:
na routerech bývá mtu default nastaven na 1500 nebo 1492 byte, snad proto nastavit síťovku na max. 1492.
achá, díky, snad to moasovi pomůže. ale řekni mi proč? jaký to má důsledek?
krámy by sice měly správně fungovat, ale nějak nefungují...
... snad proto ten tip, ať se vyloučí jeden problém.
zdá se mi ale, že xp mívají default mtu nějakých 1300byte, takže router by jejich paket neměl fragmentovat. já už jsem si to kdysi rozdrbal, nemůžu ověřit.
pokud router je nějaký čínský plebs, je možné (a už jsem se s tím setkal), že špatně zpracuje větší pakety, než má MTU dalšího rozhraní (typicky právě u PPP spojení, kde MTU je těch 1492 bajtů - tj. 1500 bajtů minus 8 bajtů pro zapouzdření PPP). Projevuje se to právě na větších souborech.
Router totiž musí, při obdržení paketu většího, než jaký "proleze PPP dírou", provést "split" takového paketu na dva - to samozřejmě zvyšuje nároky na pásmo i výkon CPU.
teda, vážně, toto je luxus. užívat si tři síťaře, kteří vysvětlí. tohle se prostě nevygoogluje. promiň moasi za narušení tvého dotazu, zato jsme vzdělanější. díky i tobě tw.
Díky, tohle ještě zkusím nastavit podle návodu doporučeného brtníkem. Nicméně tady to vypadá, že pro PPPoE musím nastavit nikoliv 1492, ale 1480B ?
třeba pppoe potřebuje jinak velkou hlavičku.
ping na bránu providera s parametrem -f by to mohl ověřit.
já bych šel hned ke kováři: http://www.cisco.com/en/US/tech/tk175/tk15/technol ogies_tech_note09186a0080093bc7.shtml
jinak vcelku ucelený výklad je zde: http://en.wikipedia.org/wiki/Maximum_transmission_ unit
Zjednodusene, namiesto klasickych 1500B framov sa pri jumbo robia az 9k, cim sa zmensi fragmentacia a zvysi sa priepustnost siete (menej ramcov=menej pocitania=menej chyb), ako som pisal pouziva sa pri 1Gb sietach.
Inak podla mna MTU na klientoch nema zmysel, kedze MTU aj tak zmeni router vo finale, takze to co radil tw je asi zbytocne.
moc ti děkuju, jako brtníkovi.
Ať se na tom routeru dívám jak se dívám, nevidím tam tuhle možnost. Ani v emulátoru.
To mám asi smolíka.
Je to sice už postarší téma, ale teprve teď se mi povedlo ho rozseknout.
Chyba nebyla nakonec v žádném routeru.
Něco bylo špatně na FTP serveru. Vůbec nevím, proč se od některých uživatelů problém neobjevoval a od jiných ano, nicméně stačilo přeinstalovat OS, znovu nainstalovat Filezilla server, nastavit účty a už to všechno lítá všem jak z praku.