Dotaz: Grafický FTP klient s protokolem "klasického" střihu

[lertimir]

Hledám grafický ftp klient, který z ftp serverm komunikuje velmi klasickým starým střihem. Tedy jedno řídící spojení, seriově uváděně příkazy, žádný paralelismus, žádné víc proudové stahování. žádné otevření dalšího ftp kanálu (řídícího spojení). Používám filezillu už léta, ale ta nevyhovuje, otevírá nová řídící spojení v případě že v bufferu je více než jednen soubor. i když mám nastavono souběžné stahování 1. Problém je v tom, že FTP server je dosti restriktivní a druhé řídící spojení ze stejné IP neakceptuje. A utlačit to na klasickém řádkovém FTP je také nepříjemé, protože server vzme jen get ne mget a s tím se více souborů stahuje blbě.

---

---

Odpovědi

[Kit]

Určitě bych nejprve zkusil řádkového klienta lftp, který má pár zajímavých vychytávek navíc, včetně mirrorování obsahu.

[NN]

Zakladni implementace FTP bude ve spravci souboru, webovem prohlizeci, nebo v mc.

[Petr Šobáň]

Já používám gftp ovšem zda se to dá nastavit na jedno spojení netuším.

Ale jak píšou v mc je taky ftp párkrát jsem to používal.

[Chytrex]

eh a nepomůže prostě nastavit passive mode?

[pavlix]

Jak řeší passive mode počet spojení? Nehledě na to, že passive je snad dneska už standard a default.

[Chytrex]

passive řeší část dotazu, nebo tedy jak jsem to pochopil já..(přikazy i data v jednom spojení)

[pavlix]

Jednak nevidím v dotazu nic o požadavku na příkazy a data v jednom spojení, jednak by pasivní FTP takový požadavek ani nesplňovalo, jednak se pasivní FTP používá dnes většinou. Mám pocit, že v tom děláš jenom větší zmatek.

[lertimir]

Samozřejmě to passive neřeší. Přečti si dokumentaci k protokolu. příkaz passive pro klienta specifikuje jak budou datová spojení administrována. Pokud je spojení klient posílá do řídícího spojení příkaz PORT (a,b,c,d,x,z) v případě klienta v režimu passive posílá příkaz PASV a dostane odpověď 227 Entering Passive Mode (a,b,c,d,x,z). V obou případech čísla a,b,c,d jsou dekadicky zapsané 4 byty IP adresy a x,y dekadicky zapsané 2 byty portu na nichž příslušná strana (tedy pro aktivní spojení klient a po pasivní spojení server) otevřela port a na kterém se data budou přenášet. pro každý datový přenos jak výpisu adresáře (příkaz LIST) tak přenosu souboru (příkaz RETR) se vždy musí pomoci PORT/PASV znovu otevřít datový port, protože po přenosu se datový kanál ihned uzavírá. to v čem byl problém je ten že mnozí klienti se snaží urychlovat přenos tím, že na cíl budují více než 1 řídící spojení. Třeba tak, že když stahuji obsah adresáře, tak vybudují nové řídící spojení na stahování dat i když už mají jedno, kterým stáhli výpis adresáře. Protokol je velmi striktní, a myslím že žádný pipelining v něm není a dokud po žádosti o přenos nedostanu 200 hlášku, že data byly přenesena, (např226 Directory send OK.) tak nemohu do spojení nic posílat. takže pokud server dovoluje více posjení tak větším množstvím řídících spojení se zvětší celkový průtok dat.

[lertimir]

Nakonec to řeším batchem pro klasické ftp: stará dobrá ruční práce.