Transparentní sdílení souborů

V posledních třech dílech jsme se podrobněji zabývali dvěma protokoly (FTP a TFTP). Ty mají v rodině protokolů TCP/IP na starosti takový přenos souborů, který jsme si označili jako netransparentní. Nyní je na řadě transparentní přístup k souborům a protokol NFS.

Nejprve si ale znovu zopakujme, v čem je rozdíl mezi transparentním a netransparentním přístupem (tak, jak jsme si je zavedli v 70. dílu): netransparentní přístup je takový, při kterém pro uživatele existuje principiální rozdíl mezi místními soubory a vzdálenými soubory. Uživatel si musí být vědom, že určitý soubor není místní, ale že se nachází na vzdáleném počítači (navíc musí vědět kterém), a když s ním chce pracovat, musí pro to nejprve něco udělat - zajistit přenos tohoto souboru ze vzdáleného počítače na svůj počítač.

Naproti tomu v případě transparentního přístupu pro uživatele neexistuje žádný principiální rozdíl mezi místními a vzdálenými soubory. Uživatel (resp. jím provozovaná aplikace) si může myslet, že všechny jemu dostupné soubory jsou místní, a jako s takovými s nimi také pracuje. Skutečnost, že některé soubory místní nejsou, je před uživatelem skryta, stejně tak jako všechny mechanismy, které potřebnou iluzi vytváří, a které zajišťují potřebné přenosy celých souborů či jejich částí mezi místním a vzdáleným počítačem.

Jak vzniká iluze

Principiální způsob, jakým lze transparentní přístup ke vzdáleným souborům realizovat, ukazuje obrázek 74.1.:

Obr. 74.1.: Představa přístupu ke vzdáleným souborům

vychází opět z modelu klient/server, ve kterém uživatelův počítač vystupuje v postavení klienta, a vzdálený počítač v postavení serveru (file serveru, který jako službu nabízí svým klientům uchovávání souborů). Pro uživatele (resp. jím provozovanou aplikaci) je ovšem i tento vztah transparentní - uživatel vznáší veškeré své požadavky na přístup k souborům jedné a téže entitě (složce operačního systému, kterou prozatím nazveme shell). Ta rozhoduje o tom, zda požadavek je požadavkem na přístup k takovému souboru, který je lokální, nebo zda jde o požadavek na přístup ke vzdálenému souboru, a podle toho pak příslušný požadavek předá k vyřízení buď místnímu systému souborů, nebo programové entitě, která implementuje klienta. Pokud nastal tento druhý případ, klient zformuluje požadavek na přístup ke vzdálenému souboru do takového tvaru, který je srozumitelný pro entitu v roli serveru na vzdáleném počítači, a požadavek jí odešle. Server zajistí vše potřebné pro vyřízení požadavku (např. načtení souboru, který pro něj již je místní), a výsledek odešle po síti zpět klientovi. Ten jej pak vrátí zpět shellu, a ten zase uživateli.

Praktické naplnění tohoto schématu má dvě relativně samostatné stránky: tou první je konkrétní protokol, prostřednictvím kterého komunikuje klient se serverem, a tou druhou je plně transparentní "začlenění" mechanismu přístupu ke vzdáleným souborům do celkového systémového prostředí na klientském počítači. Právě u této druhé stránky se nyní zastavíme podrobněji, zatímco tu první si ponecháme na další díly.

Záleží na operačním systému

Máme-li na určitém počítači implementovat takový mechanismus přístupu ke vzdáleným souborům, který má být pro uživatele plně transparentní, pak se nutně musíme přizpůsobit tomu, jaké konvence, postupy a mechanismy používá pro přístup k souborům operační systém daného počítače. Má-li totiž uživatel pracovat i se vzdálenými soubory přesně stejným způsobem, jako se soubory místními, musí k tomu využívat přesně stejné prostředky a postupy.

Jestliže tedy konkrétní protokol pro vlastní přenos souborů mezi uzlovými počítači může (či spíše musí) být stejný, způsob jeho zpřístupnění uživatelům a jimi provozovaným aplikacím je již závislý na konkrétním počítači, přesněji na jeho operačním systému.

Podívejme se proto, jak vypadá situace v případě dvou operačních systémů - Unixu a MS DOSu.

Unix montuje

Obr. 74.2.: Představa operace mount v OS Unix

Operační systém Unix si organizuje všechny své soubory do jediného adresářového stromu. Fyzicky mohou být tyto soubory umístěny na různých zařízeních (pevném disku, disketě apod.), a sdruženy do tzv. souborových systémů (filesystems) - například obsah diskety může tvořit takovýto souborový systém, samostatný oddíl (partition) pevného disku může tvořit jiný souborový systém apod. Z pohledu uživatele jsou ale tyto souborové systémy sestavovány do jednoho jediného adresářového stromu, jehož základ tvoří tzv. kořenový souborový systém (root filesystem). Konkrétní mechanismus, který toto sestavování umožňuje, je operace mount (doslova: připoj, přimontuj). Z pohledu uživatele funguje tak, že celý souborový systém připojí k zadanému adresáři globálního adresářového stromu jako jeho nový podstrom - viz obrázek 74.2.

Obr. 74.3.: Přístup k místním a vzdáleným souborům v Unixu

Když se pak uživatel či jakákoli aplikace odkazuje na některý soubor z takto "přimontovaného" systému souborů, lze si představit, že jeho požadavek projde od kořene až do místa, kde je příslušný systém souborů připojen, a odsud je pak předán ovladači připojeného systému souborů, který tento požadavek již dokáže vyřídit - viz obr. 74.3.

Takto fungující prostředí vychází vstříc plně transparentnímu přístupu ke vzdáleným souborům, a umožňuje realizovat jej velmi přirozeným způsobem. Stačí rozšířit schopnosti operace mount tak, aby umožňovala připojit i takové systémy souborů či jejich části, které se fyzicky nachází na vzdáleném počítači, a dále zajistit, aby veškeré požadavky na přístup k těmto souborům se na daném počítači dostaly k entitě, která implementuje klienta - viz obr. 74.3. Ta pak již zajistí vše potřebné.

DOS trvá na logických jednotkách

Jestliže operační systém Unix sestavuje všechny systémy souborů vždy jen do jediného stromu, který pak nepotřebuje nijak pojmenovávat, operační systém MS DOS se na své adresáře a v nich obsažené soubory dívá poněkud jiným pohledem. To, co Unix sestavuje pomocí operace mount do jediného celku, ponechává MS DOS oddělené - obsah diskety v každé z disketových mechanik chápe jako samostatný celek, a stejně tak každý oddíl (partition) pevného disku či tzv. RAMdisk. Každý takovýto celek (v terminologii DOS-u nazývaný drive, a představující logickou diskovou jednotku) musí být jednoznačně identifikovatelný, a tak mu DOS přiřazuje jednopísmenné označení: například drive A: je první disketová jednotka, B: případná druhá disketová jednotka, C: první oddíl (partition) prvního pevného disku. Navíc nemá MS DOS žádnou obdobu Unixovské operace mount (a ani ji nepotřebuje).

Obr. 74.4.: Pohled na vzdálené soubory v prostředí MS DOSu

V prostředí MS DOSu proto musí být plně transparentní přístup ke vzdáleným souborům implementován tak, aby systémy souborů vzdáleného počítače či jejich podstromy vystupovaly jako samostatné celky (logické jednotky, drives) - viz obr. 74.4.

Dalším nedostatkem MS DOSu je, že nedokáže vždy potřebným způsobem rozeznávat požadavky na přístup ke vzdáleným souborů a předávat je tomu, kdo je dokáže vyřídit. Proto je obvykle třeba tyto požadavky přesměrovávat ještě dříve, než se dostanou k MS DOSu - vrstvou, která "překryje" DOS, zachytává všechny požadavky na přístup k souborům, ty "místní" předává DOSu, a pro ostatní pak ve spolupráci s dalšími entitami (implementujícími klienta) zařizuje vše potřebné. No a právě touto překrývající vrstvou je entita, kterou jsme si dříve označili jako shell (což v doslovném překladu znamená plášť). V prostředí MS DOSu, který nepodporuje multitasking, musí mít tato entita formu rezidentního programu.

---