FTP - kontrola úplnosti uploadu

[Medo77]

Caves.
Nie som si isty, kam to spravne zaradit.
Dumam uz par dni, ako zistit, ze subory su kompletne nahrate na strane FTP servera, aby si ich druha strana mohla stiahnut. Cas "necakania" je dolezity, cize nieco take, ze ak sa subory nahraju o 9:00, stiahni si ich o 10:00, je neziaduce (idealne sosat hned ako sa da) a tak isto sa postupne cas uploadu postupne v priebehu dna natahuje (pocet suborov je nemenny, ale ich velkost sa kazdu hodinu zmeni do plusu - zvecsuju sa). (co o 9:00 trva 5 minut, o 18:00 aj 40 min).
Zatial ma nenapadlo nic inteligetnejsie ako na zaciatku uploadu zmazat nejaky kontrolny subor upload_ok_%hodina%.txt a konci ho zase umiestnit, cim druhej strane poviem, ze ak subor na ftp existuje, moze upload povazovat za skonceny a korektny a moze sosat k sebe.

Pre uplnost uvediem strukturu:
Windows klient to nahra z nejakeho uloziska (A) na nejaky Linux FTP (B) (2 rozne verejne IP v ramci toho isteho hostingu), na na druhej strane to z toho FTPcka zase window sklient potiahne. (C)
Ak sa pokusam to upnut rovno z jednej infry (A) do druhej (C), jednak je to o poznanie pomalsie, jednak tu prvotnu IPcku zabijam 2x. (a linka je sharovana, takze sa snazim ktomu aj tak chovat, ze tam nie je som sam), z tej druhej Ipcky, kde je FTP ta zataz uz nevadi. Logicky aj ked na 2 roznych IP, ale v ramci tej istej infry to prelezie s co najmensou reziou.

Skusal som aj Resilio sync, ale rychlost nebola nic moc ..Proste FTP sa javi ako najchodivejsie ...

Za napady vopred diky.

[Reklama]

[Filip Jirsák]

Tohle záleží na konkrétní implementaci FTP serveru. Ideální je, když uploadovaný soubor nahrává do dočasného adresáře mimo publikovanou strukturu a po dokončení uploadu soubor jen přesune do správného umístění. Přesun v rámci jednoho souborového systému je na Linuxu atomická operace, tj. nikdo přes FTP neuvidí částečně nahraný soubor – buď tam nebude vůbec, nebo už tam bude celý soubor.

Doufám, že aspoň používáte FTPS (šifrované FTP), když už používáte takovýto prehistorický protokol…

[soriako]

Doufám, že aspoň používáte FTPS (šifrované FTP), když už používáte takovýto prehistorický protokol…

Co je špatnýho na FTP? Když člověk přenáší nedůležitý data po LAN, ať už doma nebo ve firmě, tak je to snad jedno.

[Exceptions]

FTP nemá žádné kontrolní součty, sice FTPS díky šifrování je odolné proti ztrátě dat cestou, ale pokud se zdrojová strana ukončí, tak soubor zůstane nahraný pouze částečně.

Často tohle jsme řešili nahráváním souboru do tmp a až poté přesun na cíl, ale pořád existovali situace, kdy se soubor nenahrál celý. Jediná možnost je mít na straně serveru implementovaný nějaký checksum mechanismus.

Jako náhradu mohu doporučit SFTP, kde probíhá kontrola při přenosu a upload do tmp nebo rsync, který přímo dělá kontrolní součty na obou stranách (ať už nešifrovaně přes rsync protokol nebo přes ssh).

[Filip Jirsák]

Co je špatnýho na FTP? Když člověk přenáší nedůležitý data po LAN, ať už doma nebo ve firmě, tak je to snad jedno.

Za prvé, nedůležitá data nikam nepřenáším, rovnou je mažu. A u dat, která nejsou zjevně nedůležitá, odmítám přemýšlet o tom, zda jsou důležitá nebo nedůležitá a podle toho volit přenosový protokol.

FTP je nešifrovaný protokol, což se dá zalepit FTPS. FTP potřebuje pro přenos více portů a spojení navazované v obou směrech, což dělá problémy firewallům. Dá se to zalepit pasivním přenosem, ale i ten otevírá nové spojení na port, který není předem znám. Protokoly, kde se nejprve musí zalepit problémy, aby se vůbec daly začít používat, nemám rád.

Nejsou tam kontrolní součty ani kontrola přenosu, prakticky nemáte jak zjistit, pokud se soubor kvůli chybě nepřenese celý. Nedají se přenášet metadata souboru (kromě pár základních, se kterými počítá historický standard). Musí se řešit konce řádků, stačí drobná chybka a přenášený soubor poškodíte. Při přenosu můžete použít jen velmi slabou kompresi.

Místo FTP používám raději WebDAV, který je založený na HTTP, takže projde všude. Implementací HTTP klientů i HTTP serverů je všude spousta, takže i kdyby vám nevyhovovalo žádné z hotových řešení, není problém si něco upravit nebo si napsat vlastní (třeba posílat notifikaci v okamžiku nahrání souboru, ať nemusí druhá strana pořád zkoušet, zda už tam soubor není).

[Reklama]

[Daniel Mašek]

Co jsem videl ruzna reseni, tak se ten soubor obvykle po uploadu prejmenovava, takze nejdrive ma treba priponu .tmp a pak teprve .xml apod. Nepotrebujete v tom pripade zadny dalsi adresar.

[Filip Jirsák]

Co jsem videl ruzna reseni, tak se ten soubor obvykle po uploadu prejmenovava, takze nejdrive ma treba priponu .tmp a pak teprve .xml apod. Nepotrebujete v tom pripade zadny dalsi adresar.

To má tu nevýhodu, že to musí dělat klient, který soubory nahrává. Výhoda je naopak v tom, že to udělá až po té, co bezpečně ví, že se tam soubor nahrál celý – tedy to řeší i případy přerušeného nahrávání, když se soubor nenahrál celý.

[S.A.]

Co je špatnýho na FTP? Když člověk přenáší nedůležitý data po LAN, ať už doma nebo ve firmě, tak je to snad jedno.

Na FTP není špatného vůbec nic. A kdo tvrdí opak, tak o tom vůbec nic neví.

[Medo77]

Pod pojmom FTP som myslel cestu ako taku, nie konkretnu implementaciu.
v kazdom pripade, sa mi to podarilo vytunit ako som popisal vyssie, ze klient caka, nez sa tam objavi konkretny potvrdzujuci textak, a dovtedy hodi na minutu sleep a zase pokus ...
Slo by to este rozvinut k dokonalosti, ze by textak obsahoval info pre porovnanie na druhej strane, cim by sa dostiahol 100%-ny stav so zdrojom .. (pocet suborov, ich velkost, pripadne idealne checksum).

[soriako]

Co je špatnýho na FTP? Když člověk přenáší nedůležitý data po LAN, ať už doma nebo ve firmě, tak je to snad jedno.

Na FTP není špatného vůbec nic. A kdo tvrdí opak, tak o tom vůbec nic neví.

Odpověď od Filipa Jirsáka jsem dostal a se spoustou bodů s ním souhlasím, ale pořád na FTP nevidím nic špatnýho, klidně bych ho doma používal jako způsob přenosu dat mezi PC a serverem. Až otevírání FTP do internetu by byla kravina.

[k3dAR]

Pod pojmom FTP som myslel cestu ako taku, nie konkretnu implementaciu.
v kazdom pripade, sa mi to podarilo vytunit ako som popisal vyssie, ze klient caka, nez sa tam objavi konkretny potvrdzujuci textak, a dovtedy hodi na minutu sleep a zase pokus ...
Slo by to este rozvinut k dokonalosti, ze by textak obsahoval info pre porovnanie na druhej strane, cim by sa dostiahol 100%-ny stav so zdrojom .. (pocet suborov, ich velkost, pripadne idealne checksum).

no nevim co si tunil kdyz za dokonalost povazujes checkum kterej nemas nevim jak jsou velka data ani jakeho druhu, ale obecne mi prijde normalni to udelat:

Kód: [Vybrat]

Server:
1. zabalit vse do 1 archivu
2. archiv odeslat a zaroven dat pocitat sha256 do archiv.sha256 (paralelne aby se nezdrzovalo)
3. po zkopirovani archivu odeslat archiv.sha256

Klient
1. ceka na archiv.sha256 az bude stahne archiv i archiv.sha256
2. zkontroluje sha256 archivu a rozbali ho
- s tim ze pokud FTP je nesifrovane, ten sha256 poslat pres sifrovanej kanal
- s tim ze pokud data jsou nekomprimovatelna tak pouzit jen tar.gz, pripadne jen tar, pokud jde naopak o dobre komprimovatelna tak tar.xz, resp. vyzkouset jak dlouho trva zabalit a o kolik se usetri cas prenosem dle rozdilu velikosti a rychlosti spojeni...

[Filip Jirsák]

Odpověď od Filipa Jirsáka jsem dostal a se spoustou bodů s ním souhlasím, ale pořád na FTP nevidím nic špatnýho, klidně bych ho doma používal jako způsob přenosu dat mezi PC a serverem. Až otevírání FTP do internetu by byla kravina.

Klidně doma FTP používejte :-) Já jenom nerad používám jiný protokol doma na domácí přenášení, další na přenášení mezi domovem a venkovním serverem a v dalších situacích třeba ještě jiný protokol, když jde stále o tutéž činnost – přenos souborů. Nechci přemýšlet nad tím, že teď sedím doma u svého notebooku a jsem připojen na domácí WiFi, takže můžu použít FTP, ale teď sedím doma u svého notebook a jsem připojen na WiFi hotspot vytvořený z mobilu, tak musím použít něco jiného, než FTP. Nevidím v tom žádnou výhodu. Nemluvě o tom, že bych musel na serveru udržovat další aplikaci.

[Filip Jirsák]

1. ceka na archiv.sha256 az bude stahne archiv i archiv.sha256

Pokud byste to chtěl fakt voděodolné, bylo by potřeba kontrolovat i velikost/obsah toho archiv.sha256 a v případě potřeby počkat, než bude celý. Abyste nevyhlašoval poplach, že vám někdo změnil soubor, když by vám ve skutečnosti jen chyběl kus hashe.

[k3dAR]

@Filip dobra pripominka, tak po archiv.sha256 nahrat prazdnej archiv.sha256.done a klient by kontrolovat dostupnost archiv.sha256.done

[Filip Jirsák]

@Filip dobra pripominka, tak po archiv.sha256 nahrat prazdnej archiv.sha256.done a klient by kontrolovat dostupnost archiv.sha256.done

To není potřeba :-) Délka SHA-256 otisku je známá, pokud by v tom souboru nebylo nic jiného, stačí kontrolovat jeho velikost. Pokud by tam mělo být i něco jiného, je potřeba kontrolovat délku otisku a za ním by už nesmělo být nic důležitého.

(A nebo použít ten WebDAV, kde se otisk pošle normálně v hlavičce…)

Což mi připomíná, že jsem v původním příspěvku zapomněl k WebDAV přidat zmínku o protokolu S3. Je také postaven nad HTTP a za mne jsou WebDAV a S3 plnohodnotné alternativy. WebDAV se obvykle používá pro komunikaci klient–server, zatímco S3 obvykle používají serverové služby pro komunikaci mezi sebou, základní vlastnosti ale mají stejné, liší se až v pokročilých funkcích.