zpět do archivu článků |
rejstřík |
předchozí díl |
následující díl
Jiří Peterka: Co je čím ... v počítačových sítích (74):
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.
zpět do archivu článků | rejstřík |
předchozí díl |
následující díl
Tento článek může být volně šířen, pokud se tak děje pro studijní účely, na nevýdělečném základě a se zachováním tohoto dovětku. Podrobnosti hledejte zde, resp. na adrese
http://ksi.ms.mff.cuni.cz/~peterka/archiv/copyleft.htm