FTP - II.

V předchozím dílu jsme se začali zabývat konkrétními vlastnostmi protokolu FTP, který má v rodině protokolů TCP/IP na starosti netransparentní přenos souborů. Přitom jsme se věnovali hlavně způsobu, jakým se tento protokol vyrovnává s odlišnostmi různých počítačů a jejich operačních systémů v pohledu na soubory, jejich vnitřní strukturu a vlastní obsah. Dnes se již dostaneme k tomu, jak přenos souborů podle protokolu FTP v praxi probíhá - kým je iniciován, kým je řízen, jakými příkazy atd.

Implementace protokolu FTP vychází z architektury klient-server, kterou jsme si přiblížili již v 64. dílu seriálu. Předpokládá tedy existenci dvou navzájem nerovnoprávných složek: klienta a serveru. Složka v roli klienta je iniciátorem, z jehož popudu k přenosům souborů dochází, a server je druhou stranou, která přitom spolupracuje. Server tedy nabízí jako svou službu spolupráci na přenosu souborů, a klient je tím, kdo o tuto službu žádá. Typicky je složka v roli klienta představována aplikačním programem, který si uživatel spouští na svém počítači, a složka v roli serveru démonem (FTP démonem v prostředí Unixu, resp. obdobným systémovým procesem v jiném prostředí) na tom počítači, ze kterého či na který uživatel chce přenést nějaký soubor. Vlastní směr přenosu (od serveru ke klientovi či naopak) přitom není pro rozlišení obou složek relevantní.

Trvale jen nezbytné minimum

Obr. 72.1. Představa složek v roli klienta a serveru protokolu FTP

Protokol FTP vychází vstříc takovému způsobu implementace, který se snaží minimalizovat své nároky na různé systémové prostředky - umožňuje žádat o jejich přidělení až na základě skutečné potřeby, a po jejich použití je zase vrátit. Konkrétní myšlenka je taková, že po celou dobu komunikace mezi klientem a serverem (tedy po celou dobu existence relace mezi nimi) musí existovat jen to, co zajišťuje vysílání a příjem nejrůznějších příkazů a odpovědí na ně mezi klientem a serverem, zatímco všechno ostatní, co je potřeba pro vlastní přenos dat, může vznikat dynamicky, až na základě skutečné potřeby.

Této představě odpovídá i vnitřní členění složek v roli klienta a serveru i povaha komunikačních kanálů mezi nimi - viz obr. 72.1.

Interpret protokolu a přenosový proces

Ta část složky v roli klienta, která existuje trvale (resp. po celou dobu práce s aplikací, která protokol FTP implementuje), je tzv. interpret protokolu (PI, Protocol Interpreter). Jeho úkolem je nejprve navázat spojení s partnerským interpretem protokolu na straně serveru, a poté iniciovat jednotlivé akce a řídit jejich průběh. Činí tak prostřednictvím příkazů, které zasílá svému partnerskému interpretu protokolu na straně serveru, a dále tím, že na své straně dynamicky vytváří a řídí tzv. přenosový proces (DTP, Data Transfer Process), který pak zajišťuje vlastní přenos dat na základě pokynů od svého interpretu protokolu a pokynů druhé strany.

Řídící a datové spojení

Interpret protokolu na straně klienta navazuje spojení se svým partnerským interpretem na straně serveru prostřednictvím protokolu TCP - to znamená, že spojení mezi oběma interprety má povahu spojovaného a spolehlivého spojení. Interpret na straně serveru musí čekat na žádost o navázání spojení na jednom z tzv. dobře známých portů (konkrétně na portu č. 21). Jakmile je spojení navázáno, existuje po celou dobu existence relace, ale je využíváno jen pro pro potřeby řízení této relace - proto se mu také říká řídící spojení (control connection).

Jakmile si oba interprety mezi sebou vykorespondují, že má být proveden nějaký přenos, vytvoří za tímto účelem své přenosové procesy. Ty si pak mezi sebou naváží samostatné spojení (opět prostřednictvím protokolu TCP, tedy spolehlivé a spojované), a jeho prostřednictvím pak zajistí vlastní přenos dat. Proto se tomuto spojení také říká datové spojení (data connection). Za povšimnutí stojí skutečnost, že zatímco navázání řídícího spojení iniciuje klient (přesněji interpret protokolu na straně klienta), povinnost iniciovat navázání datového spojení má naopak server (resp. jeho přenosový proces). Interpret protokolu na straně klienta naopak instruuje svůj přenosový proces, aby čekal na zadaném portu na navázání spojení.

Protokol FTP ovšem připouští i jinou možnost, než jen přenos souborů mezi jedním klientem a jedním serverem. Dovoluje, aby uživatel z jednoho počítače inicioval přenos souborů mezi dvěma jinými počítači (tedy mezi dvěma vzdálenými počítači). V tomto případě existuje složka v roli klienta na počítači, na kterém pracuje uživatel, a na obou vzdálených počítačích musí existovat složky v roli serveru. Řídící spojení musí být navázána dvě, a to mezi interpretem protokolu klientské složky a interprety obou serverů, a jejich prostřednictvím instruuje klient oba servery, jak mají zajistit požadovaný přenos. Datové spojení je pak ale vytvářeno jen mezi oběma servery, tj. vlastní data již neprochází přes klientský počítač.

Příkazy pro řízení přenosu

Interprety protokolu na straně klienta a serveru spolu komunikují prostřednictvím jazyka, který je součástí definice protokolu FTP. Tento jazyk je tvořen příkazy (které vysílá interpret klienta) a odpověďmi na ně (které vysílá interpret serveru). Jednotlivé příkazy lze rozdělit do tří základních skupin, na:

• příkazy pro řízení přístupu (access control commands), umožňují mj. zadat uživatelské jméno a heslo, které pak složka v roli serveru bude používat při všech následných požadavcích na přístup k souborům (viz též 70. díl)
• příkazy pro nastavení parametrů přenosu (transfer parameter commands), které umožňují například změnit implicitní čísla portů, používaných při navazování datového spojení, nastavit režim přenosu, stanovit reprezentaci dat či strukturu přenášeného souboru (viz minulý díl seriálu).
• výkonné příkazy (FTP service commands), které iniciují vlastní přenosy souborů a manipulaci s nimi (přejmenovávání, rušení), práci s adresáři (přechody na podadresář či na nadřazený adresář), výpisy obsahu adresáře (vlastní výpis je pak přenášen prostřednictvím datového spojení) apod.

Odpovědi

Každý příkaz generuje alespoň jednu odpověď (některé dokonce více odpovědí). Jednotlivé odpovědi přitom mají formu číselných kódů - trojmístných desítkových čísel - za kterými následuje vysvětlující text. Představa je ovšem taková, že rozhodující jsou pouze číselné kódy, které v sobě nesou veškerou podstatnou informaci, zatímco text má pouze vysvětlující charakter, a jeho obsah není navíc vůbec závazný (tj. různé implementace mohou ke stejnému číselnému kódu připojovat různé vysvětlující texty). Logika je taková, že číselný kód je určen pro program, který odpovědi vyhodnocuje. Ten může podle svého uvážení vysvětlující text jednoduše ignorovat, nebo jej zobrazit uživateli, aby i on byl pro něj srozumitelnou formou informován o odpovědích serveru.

Zajímavý je i způsob kódování číselných odpovědí, který vychází vstříc různé úrovni detailnosti při vyhodnocování odpovědí. Číselný kód je trojmístný, a jeho první číslice udává to, zda odpověď je dobrá, špatná či neúplná (viz tabulka 72.2.). Nejjednodušší implementace se pak mohou rozhodovat jen podle této první číslice, zatímco propracovanější implementace mohou získat podrobnější informace vyhodnocením druhé, ev. i třetí číslice.

Tabulka 72.2: Význam první číslice odpovědi

1xx	předběžná kladná odpověď (požadovaná akce byla úspěšně zahájena, ještě bude následovat další zpráva o jejím průběhu)
2xx	kladná odpověď (požadovaná akce byla úspěšně provedena, resp. dokončena)
3xx	prozatímní kladná odpověď (příkaz byl přijat, ale pro zahájení požadované akce jsou nutné ještě další příkazy)
4xx	dočasná záporná odpověď (požadovaná akce nebyla úspěšně provedena, ale důvod neúspěchu je dočasný, a má smysl žádat o nové provedení akce)
5xx	trvalá záporná odpověď (požadovaná akce nebyla úspěšně provedena a nemá smysl se o ni pokoušet znovu)

FTP používá Telnet

Za povšimnutí stojí i konkrétní forma, v jaké jsou jednotlivé příkazy a odpovědi na ně přenášeny řídícím spojením. Příkazy i odpovědi mají zásadně textovou formu - jména příkazů tvoří tří až čtyřpísmenné zkratky, a také číselná část odpovědi je přenášena textově (jako trojice desítkových číslic). Vzhledem k tomu se protokol FTP může odvolávat na protokol Telnet a požadovat, aby tyto texty byly přenášeny po řídícím spojení přesně tak, jak to činí protokol Telnet. V praxi to znamená, že implementace protokolu FTP pro přenos příkazů a odpovědí řídícím spojením buďto sama využívá služeb již existující implementace Telnetu, nebo si sama implementuje tu část protokolu Telnet, kterou skutečně potřebuje (protože zdaleka nevyužívá všech možností, na které protokol Telnet pamatuje).

Uživatelský vs. řídící jazyk

Důsledně textová podoba řídícího jazyka i využití protokolu Telnet pro přenos příkazů a odpovědí nevylučuje, aby na straně klienta vydával příkazy řídícího jazyka místo interpretu protokolu přímo uživatel, který si otevře vzdálenou terminálovou relaci s interpretem na straně serveru (pokud přitom dodrží všechny konvence protokolu FTP). Běžný případ to ale rozhodně není.

Obr. 72.3. Příklad průběhu relace protokolu FTP

Obvyklá implementace protokolu FTP obsahuje vedle interpretu příkazů a přenosového procesu ještě i uživatelské rozhraní, které zajišťuje komunikaci mezi uživatelem a interpretem příkazů (viz obr. 72.1.). Toto rozhraní pak může nabízet v podstatě jakýkoli "uživatelský" jazyk, který pak ve spolupráci s interpretem protokolu překládá do řídícího jazyka, a ten již je pro všechny implementace jednotný. Z pohledu uživatele (který využívá služeb protokolu FTP prostřednictvím uživatelského jazyka) se proto různé implementace FTP mohou "tvářit" jinak (mohou používat různé příkazy pro tytéž činnosti, místo řádkového rozhraní mohou používat grafické uživatelské rozhraní apod.), ale díky používání jednotného řídícího jazyka by se měly všechny správně domluvit.

Příklad průběhu relace mezi klientem a serverem ukazuje obrázek 72.3.

---