Část 2. Praxe vzájemné spolupráce
V první části série článků na téma "Interoperabilita" jsme se zamýšleli nad tím, jak si tento pojem správně vykládat. Dospěli jsme k představě, že jde o spolupráci různých platforem. Dnes se budeme zabývat tím, jaké může být vzájemné postavení dvou operačních systémů, které stojí na různých platformách.
Položme si hned na úvod zdánlivě banální otázku: mají-li vedle sebe existovat (a vzájemně spolupracovat) Unix s MS DOSem, potřebují k tomu každý svůj vlastní počítač, nebo mohou "žít vedle sebe" na jediném počítači?
Není jistě těžké uhodnout, že vystačí i s počítačem jediným. Zajímavější je spíše to, jaká může být forma jejich "spolubydlení".
Nejméně pružnou je taková varianta, při které oba sice "obývají" tentýž počítač, jsou jeho rovnocennými spolumajiteli, ale nikdy nejsou "doma" současně. Pevný disk je v tomto případě rozdělen nejméně na dvě části (tzv. oddíly, angl.: partitions), které si každý z obou operačních systémů může "zabydlet" zcela podle svého. Pouze jeden z těchto oddílů však může být tzv. aktivní - což znamená, že po zapnutí počítače se operační systém načítá právě z tohoto oddílu, zatímco oddíl (partition) druhého operačního systému není většinou vůbec přístupný. Přejít z používání jednoho operačního systému na druhý pak znamená vhodným způsobem (pomocí k tomu určené systémové utility) zařídit, aby se aktivním stal jiný diskový oddíl, a pak provést restart celého počítače.
Víceúlohová (multitasking) koncepce Unixu však vychází vstříc i jinému řešení - možnosti provozovat MS DOS jako jednu z úloh přímo v prostředí Unixu. Tedy takovému řešení, kdy Unix je "pánem domu", tedy přímým vlastníkem celého počítače a všech jeho systémových zdrojů, a MS DOS je v postavení jednoho z mnoha "podnájemníků", kteří využívají společné systémové zdroje pouze prostřednictvím "pana domácího". Zastavme se podrobněji u možností, jak tuto formu vzájemného soužití obou operačních systémů realizovat.
Když je DOS v podnájmu
Zopakujme si znovu, co jsme si naznačili již v prvním článku této série: že operační systém Unix není vázán na jednotný hardware, zatímco MS DOS ano. Jinými slovy: MS DOS může běžet jen na procesorech řady 80x86 firmy Intel, a není pravděpobné, že by byl kdy přenesen (anglicky: ported) i na jiné procesory. Naproti tomu operační systém Unix (který je mnohem starší než MS DOS) byl původně ušit na míru procesoru počítačů PDP-7 firmy DEC, ale záhy byl přepsán do vyššího programovacího jazyka (jazyka C), a je možné jej přenést obecně na kterýkoli procesor. Dnes již také skutečně existují jeho verze pro snad každý rozumně výkonný procesor.
Je zde však ještě jeden zajímavý aspekt, který souvisí s poznámkou o "rozumně výkonném procesoru". Operační systém MS DOS byl vytvořen pro mikroprocesor 8086 (resp. 8088) firmy Intel, a vzhledem ke své jednouživatelské a jednoúlohové koncepci s možnostmi tohoto mikroprocesoru vcelku vystačil. Když se pak objevily vyšší prvky mikroprocesorové řady 80x86, tedy mikroprocesory 80286, 80386 a 80486, MS DOS nedokázal využít jejich zabudovanou podporu multitaskingu (tj. současného běhu více úloh), a používá tyto mikroprocesory v takovém režimu, kdy se chovají jen jako rychlejší mikroprocesor 8086.
Také Unix může být v principu implementován i na základním mikroprocesoru Intel řady 80x86, tedy na 8086. Absence jakékoli podpory multitaskingu u tohoto mikroprocesoru však znamená, že by si Unix musel všechny potřebné mechanismy realizovat sám, programovými prostředky. To je samozřejmě možné, ale velmi neefektivní, a tudíž nepříliš praktické. S první rozumnou implementací Unixu se proto můžeme setkat až na mikroprocesoru 80286, který již nabízí základní podporu multitaskingu.
Pro "podnájem" MS DOSu v prostředí Unixu má ale mikroprocesor 80286 jednu podstatnou nevýhodu: v režimu, kdy podporuje multitasking (v tzv. protected módu), se vůči aplikačním úlohám "tváří" jinak, než původní mikroprocesor 8086. To pak ale znamená, že v tomto režimu na něm nelze provozovat (jako jednu z úloh) ani samotný operační systém MS DOS, ani pro něj vytvořené aplikační programy. Celý mikroprocesor 80286 lze sice přepnout do takového režimu, kdy se chová jako původní 8086 (do tzv. reálného módu), ale tím se současně ztrácí možnost souběžného provozování více úloh neboli multitasking, resp. jakákoli jeho podpora ze strany mikroprocesoru. Použijeme-li i zde naše přirovnání k podnájmu, odpovídalo by to situaci, kdy MS DOS sice může být "podnájemníkem" Unixu, ale po dobu, kdy se v podnájmu zdržuje (tj. v době, kdy mikroprocesor pracuje v reálném módu), musí být podnájemníkem jediným (jedinou úlohou), a navíc v té době vedle sebe nesnese ani svého domácího.
Toto nepříjemné omezení mikroprocesoru 80286 odstranil až jeho nástupce, 80386. Ten již umožňuje, aby si ve víceúlohovém režimu (protected mode) každá úloha sama zvolila (nastavením příslušného příznaku), zda se na ni má mikroprocesor "tvářit" jako původní 8086, nebo zda jí má nastavovat jinou, s původním mikroprocesorem 8086 nekompatibilní tvář. Zde je pak již možné zařídit věci tak, aby operační systém MS DOS mohl běžet jako jedna z úloh pod Unixem, a dokonce aby takovýchto úloh mohlo běžet více - tedy aby na jednom počítači s Unixem běželo více instancí operačního systému MS DOS, a každá z nich nabízela plnohodnotné (jednouživatelské) prostředí MS DOSu, s možností spouštět aplikační úlohy pod DOSem apod.
Virtuální PC
Právě naznačená možnost provozovat MS DOS jako úlohu v prostředí Unixu skutečně existuje, ale není zcela automatická. Musí být pro ni splněny i některé další předpoklady, o kterých jsme se dosud nezmínili. Především je třeba si uvědomit, že operační systém MS DOS a pro něj psané aplikace neběží "ve vakuu". Naopak přímo počítají s tím, že jsou provozovány na skutečném počítači PC, a že tento je jim plně k dispozici, se všemi svými systémovými zdroji a prostředky - od operační paměti a disků až po monitor a klávesnici. Mají-li být takovéto úlohy provozovány v jiném hostitelském prostředí, musí jim toto prostředí vytvářet dostatečně věrnou iluzi skutečného počítače PC - tedy jakési virtuální PC. Nejde přitom jen o zpřístupnění nejrůznějších souborů z prostředí Unixu v takovém formátu a pomocí takových mechanismů, jaké používá MS DOS, ale také např. o věrné reprodukování způsobu práce s klávesnicí a výstupu na monitor (včetně přímého zápisu do obrazové paměti, neboli tzv. video RAM).
Některé komerční implementace Unixu pro procesor 80386 mají výše popsanou možnost implementovánu jako svou standardní součást (například SCO Unix + Open Desktop). Jinde je vše řešeno formou samostatných doplňkových produktů - nejznámějšími z nich jsou zřejmě Merge/386 firmy Locus Computing, a VP/ix firmy Interactive Systems.
Co ale dělat v případě, kdy potřebujeme provozovat MS DOS výše naznačeným způsobem v prostředí Unixu, ale nikoli na počítači s procesorem řady 80x86? Zde je situace radikálně odlišná, neboť MS DOS a jeho aplikační programy zde nemají k dispozici procesor, na který jsou vázány, a bez kterého se neobejdou. Jediným řešením je pak rozšířit poskytovanou "iluzi" virtuálního počítače PC i na předstírání samotného mikroprocesoru 80x86.
Jednou z možností, jak předstírat existenci mikroprocesoru řady 80x86, je jeho softwarová emulace. Toto čistě programové řešení je obecně použitelné pro libovolný typ hostitelského procesoru. Problém je ale v tom, že každá softwarová emulace jednoho procesoru na jiném je obecně velmi pomalá. Přesto se ale i toto řešení v praxi používá. Například firma Insignia Solutions nabízí dva takovéto softwarové emulátory DOSu pro prostředí Unixu, příhodně nazvané SoftPC: jeden pro počítače Macintosh II s operačním systémem A/UX (což je verze Unixu pro tento typ počítačů, s procesorem Motorola řady 68000), a druhý pro pracovní stanice firmy Sun (s procesorem SPARC). Firma Insignia uvádí, že na počítačích Macintosh II dosahuje její softwarová emulace rychlosti původního počítače PC/XT, zatímco na počítači Sun rychlosti počítače PC/AT.
Kromě softwarové emulace je další možností i řešení hardwarové. Spočívá v tom, že se do Unixovského hostitelského systému nainstaluje rozšiřující deska, vybavená vším, co ještě chybí k předstírání "virtuálního PC" - tedy především procesor Intel řady 80x86. Příkladem řešení tohoto typu může být produkt firmy Sun, určený pro její pracovní stanice, a pojmenovaný příznačně "integrovaný osobní počítač" (SunIPC, Integrated Personal Computer).
Ať již je ale konkrétní způsob implementace "virtuálního PC" jakýkoli, stále jde jen o "podnájem" MS DOSu v prostředí Unixu: například všechny soubory, se kterými takto provozovaný MS DOS pracuje, patří ve skutečnosti Unixu. To mj. znamená, že na disku jsou uloženy takovým způsobem, jaký používá Unix, a nikoli takovým, jaký používá MS DOS. DOS má pouze k dispozici "okénko", kterým se na tyto soubory může dívat takovým způsobem, na jaký je sám zvyklý. Při implementaci toho "okénka" pak ovšem musí být vhodně vyřešeny mj. i všechny odlišnosti obou operačních systémů a jejich rozdílné pohledy na soubory (o čemž jsme se zmiňovali v prvním dílu) - např. co do přípustných tvarů jmen a přípon souborů, jejich vnitřních formátů apod.
Dalším problémem při tomto druhu soužití MS DOSu s Unixem pak mohou být i používané terminály. Mnohé Unixovské počítače totiž stále ještě používají jednoduché, znakově orientované alfanumerické terminály, v angličtině příznačně označované jako "dumb" (doslova: hloupé, míněno ovšem ve smyslu: bez vlastní výpočetní kapacity). Jejich schopnosti zobrazování odpovídají ve světě počítačů PC obstarožnímu videoadaptéru MDA (Monochrome Display Adapter), se kterým se ale mnoho dnešních aplikací pro MS DOS již odmítá spokojit. Tyto aplikace pak není možné na "dumb" terminálech provozovat. Další komplikace pak způsobuje i skutečnost, že alfanumerické terminály Unixu mají obvykle 24 řádek, zatímco počítače PC pracují v alfanumerickém režimu s 25 řádky.
Vraťme se ale k případu, který přeci jen bude asi častější - tedy k tomu, kdy MS DOS a Unix běží každý na svém počítači, a tyto mají možnost spolu komunikovat.
Nejprve se ale zamysleme nad další obecnější otázkou: jaké může být vzájemné postavení dvou počítačů, které spolu mohou nějakým způsobem komunikovat? Na chvíli teď zapomeňme, že máme na mysli spolupráci dvou různých operačních systémů, a zůstaňme jen na půdě Unixu.
Model terminál - hostitelský počítač
Jednou z možností je situace, ke které dochází při používání vzdálených terminálových relacích, které jsme si popisovali již v prvním článku. Zde jeden z počítačů hraje roli jednoúčelového vstupně/výstupního zařízení (terminálu) jiného počítače, který si naopak ponechává postavení "plnohodnotného" počítače, na kterém si uživatelé spouští své "užitečné" aplikace. Tento druhý počítač se pak obvykle označuje jako hostitelský počítač (anglicky: host).
Podívejme se podrobněji, jak tento mechanismus funguje v prostředí Unixu (viz obr. 1):
 |
Veškeré vstupy, které pak uživatel zadává z terminálu T, sice nadále přijímá aplikace telnet na počítači A, ale ihned je zase odesílá na počítač B své partnerské úloze telnetd. Ta je zase předává ke zpracování operačnímu systému počítače B. Může přitom jít například o příkazy operačnímu systému na počítači B (o změnu aktuálního adresáře, výpis obsahu adresáře apod.), nebo o příkazy ke spuštění určité aplikace na tomto počítači. Jde-li o tento druhý případ, je po dobu svého běhu právě tato aplikace koncovým příjemcem všech vstupů z terminálu T, a úloha telnetd ve spolupráci s operačním systémem počítače B zajišťuje, aby aplikace dostávala všechny tyto vstupy stejným způsobem, jako kdyby je uživatel zadával z místního terminálu T1 počítače B. Tedy aby aplikace na počítači B vůbec nemusela rozlišovat, zda s ní uživatel komunikuje prostřednictvím vzdálené či místní relace. Obdobně je tomu i s výstupy úlohy, určené k zobrazení na terminálu. Aplikace je vždy stejným způsobem předává příslušné složce operačního systému počítače B, a očekává, že tento v rámci příslušné relace zajistí jejich zobrazení na terminálu, na kterém uživatel pracuje. V případě vzdálené terminálové relace operační systém počítače B postupuje tak, že ve spolupráci s úlohou telnetd veškeré výstupy pošle na počítač A aplikaci telnet. Ta pak již zajistí, aby se tyto výstupy dostaly až k terminálu T, na kterém uživatel skutečně pracuje, a zde se skutečně zobrazily.
Aby právě naznačený mechanismus mohl správně fungovat, musí existovat vzájemná dohoda mezi aplikací telnet na počítači A a úlohou telnetd na počítači B o tom, jakým způsobem budou vzájemně komunikovat, jaký přitom budou používat jazyk, jaké postupy atd. Jinými slovy - obě strany musí používat stejný protokol, umožňující zajistit fungování vzdálených terminálových relací. Takovýchto protokolů samozřejmě existuje celá řada. Ve světě Unixu jde například o protokol rlogin, používaný v tzv. BSD variantě Unixu. Zřejmě nejrozšířenější je ale protokol TELNET, který je standardem v počítačových sítích na bázi protokolu TCP/IP (a jehož jméno jsme si také vypůjčili pro náš příklad). To, co jsme dosud označovali jako "aplikaci telnet", je pak úlohou, která tento protokol implementuje. Z pohledu operačního systému má tato úloha postavení běžné aplikace (aplikační úlohy), neboť je spouštěna až na explicitní příkaz uživatele. "Úloha telnetd" má však poněkud jiné postavení. Jde totiž o systémovou úlohu, resp. proces, který spouští operační systém (obvykle již při svém startu), a nikoli uživatel. Pro toho není proces tohoto typu vůbec viditelný, a uživatel si jeho činnost nemusí vůbec uvědomovat. Jak jsme si již uvedli v prvním článku této série, jsou systémové procesy tohoto typu v Unixu označovány jako démoni (v našem případě jde o telnet démona).
Vraťme se ale nyní k tomu, co nás v tomto článku zajímá nejvíce: jaké jsou z tohoto pohledu možnosti spolupráce počítačů s MS DOSem a Unixovských počítačů.
Vzhledem k jednouživatelskému a jednoúlohovému charakteru MS DOSu není dost dobře možné, aby počítač s MS DOSem hrál roli hostitelského počítače - k tomuto účelu se hodí jen Unixovské počítače (což ale ve skutečnosti mohou být dostatečně "nadupané" počítače PC, provozující např. SCO Unix). Pokud však jde o počítač, který vystupuje v roli terminálu hostitelského počítače, zde je situace jiná. Tímto počítačem může opět být Unixovský počítač, který "aplikaci telnet" věnuje jen část své výpočetní kapacity, a vedle toho může současně podporovat další místní či vzdálené relace.
Stejně tak je ale možné, aby v roli vzdáleného terminálu vystupoval i počítač s operačním systémem MS DOS. Odlišnost obou operačních systémů zde není na závadu, pokud oba mezi sebou dokáží správně přenášet data - tedy pokud obě strany budou implementovat stejné přenosové protokoly. Limitující nebude ani to, jakým způsobem budou oba počítače ve skutečnosti propojeny - zda půjde o dva uzly v lokální či rozlehlé síti, nebo zda budou oba počítače propojeny např. jen kabelem přes své sériové porty. Aplikační program, který poběží na počítači s MS DOSem, bude samozřejmě muset respektovat protokol, který používá příslušný démon na straně Unixovského hostitelského počítače (tedy TELNET, rlogin apod.). Tento aplikační program se navíc bude lišit od výše uvažované "aplikace telnet" v tom, že nebude pouze přesměrovávat vstupy a výstupy skutečného terminálu z/do datového kanálu, který vede z počítače A do počítače B, ale naopak bude sám zdrojem a koncovým příjemcem všech dat, přenášených v rámci vzdálené relace, a sám bude s využitím technických prostředků počítače PC co nejvěrněji napodobovat (emulovat) chování skutečného jednoúčelového terminálu. Proto se také tento program označuje jako emulátor terminálu (terminal emulator). Vzhledem k charakteru MS DOSu bude emulátor terminálu jedinou úlohou, která v daném okamžiku na počítači PC poběží, takže tento počítač se celou svou výpočetní kapacitou bude věnovat pouhému emulování jednoúčelového terminálu (a kromě toho samozřejmě i implementaci příslušných přenosových protokolů, které mohou být zabudovány přímo ve vlastním emulátoru terminálu, nebo mohou být řešeny "mimo něj", formou rezidentních programů MS DOSu). Na první pohled by se mohlo zdát, že jde o zbytečný luxus, který relativně výkonný počítač PC degraduje na úroveň "hloupého" terminálu. Současné cenové relace jsou ale takové, že cena základní konfigurace počítače PC začíná být s cenou jednoúčelového terminálu plně srovnatelná.
Použití počítače PC v roli emulovaného terminálu má však celou řadu výhod oproti použití jednoúčelového terminálu. Snad nejvýznamnější výhodou je velká flexibilita tohoto řešení. I v dnešní době všeobecné standardizace totiž existuje celá řada různých typů terminálů, které se liší mnoha různými parametry i způsoby ovládání pomocí řídících sekvencí či jiných mechanismů. Unixovské aplikace pak ovšem musí vědět, s jakým typem terminálu pracují, mají-li plně využít všech jeho schopností. Je samozřejmě možné uzpůsobit aplikaci možnostem konkrétního terminálu, který je k dispozici, ale v prostředí Unixu to nemusí být nijak jednoduchou záležitostí - zvláště pokud aplikační programy nejsou důsledné při dodržování zavedených konvencí pro práci s terminály. Při emulaci terminálu programovými prostředky (na počítači PC) je naopak velmi snadné přizpůsobit chování emulovaného terminálu potřebám aplikace. Většina programů pro emulaci proto dnes nabízí celou řadu typů terminálů, které je schopna emulovat.
Také další významná výhoda emulace vyplývá z jejího programového charakteru. Počítač PC, který emuluje jednoúčelový terminál, to nemusí dělat stále. Příslušný emulátor je možné spustit až na základě skutečné potřeby zřídit si vzdálenou relaci s Unixovským počítačem, a jindy naopak provozovat počítač PC s MS DOSem jiným způsobem.
Velmi atraktivní jsou pak také možnosti, které poskytují různé nadstavby MS DOSU - například MS Windows - umožňující multitasking. Jakmile je totiž i v prostředí DOSu (díky těmto nadstavbám) možné provozovat více úloh současně, je možné si na jednom počítači PC spustit více instancí emulátoru, a tím tedy i otevřít více relací současně, a to i s různými počítači.
Další vývoj
Výše naznačený model výpočetního systému typu terminál-hostitelský počítač lze označit za "centralistický", neboť veškeré uživatelské aplikace jsou v něm provozovány na jediném místě - na hostitelském počítači. Tento model se vyvinul v prostředí tzv. střediskových (mainframe) počítačů, a byl motivován snahou zpřístupnit jeden výkonný počítač více uživatelům současně. Proto se místo původního dávkového zpracování (batch processing) přešlo na režim sdílení času, a ke střediskovému počítači se připojil určitý počet (jednoúčelových) terminálů, ze kterých si uživatelé mohli otevírat (místní) terminálové relace.
Stejný model pak při svém vzniku převzal i operační systém Unix, který byl sice původně vytvořen pro minipočítače (konkrétně pro minipočítač PDP-7 firmy DEC), ale předpokládal stejnou architekturu celého výpočetního systému, jakou měly velké střediskové počítače: tedy jediný centrální hostitelský počítač s celou sítí přímo připojených terminálů. Proto je také Unixu přímo vrozena představa terminálových relací, zatímco v mnohem mladším MS DOSu tato představa úplně chybí. Unix se samozřejmě dále vyvíjel, a uzpůsoboval se změnách v architektuře počítačů. Jakmile se jednotlivé Unixovské počítače začaly vzájemně propojovat (nejprve pomocí různých dvoubodových spojů - například sériových kabelů, telefonních linek apod.), byl Unix obohacen o mechanismy, umožňující zřizovat vzdálené terminálové relace ve výše uvedeném smyslu. S nástupem počítačových sítí pak byly tyto mechanismy dále obohaceny tak, aby pro účely zřizování vzdálených terminálových relací dokázaly využít vzájemného propojení počítačů prostřednictvím sítě.
Model klient-server
S prudkým rozvojem počítačových sítí a všeobecným trendem k budování distribuovaných systémů se ale vedle centralizovaného modelu terminál-hostitelský počítač začal stále více prosazovat jiný model: klient - server.
Je založen na myšlence, že dva počítače, schopné vzájemné komunikace, si podrží značnou míru vlastní autonomie, a budou si pouze poskytovat určité služby na základě jejich skutečné potřeby. Jeden z těchto dvou počítačů bude vystupovat v roli poskytovatele služby (tzv. serveru), a druhý v roli příjemce této služby (tzv. klienta). Server ovšem nebude své služby klientovi jakkoli vnucovat. Jejich poskytování bude vždy iniciováno žádostí klienta, adresovanou serveru. Ten požadavek přijme, vykoná vše potřebné pro jeho splnění, pošle zpět výsledek, a čeká na další požadavek. Podstatná je také skutečnost, že jeden server může takovýmto způsobem poskytovat služby více počítačům v roli klientů - omezujícím faktorem je často jen celková kapacita a výkonnost serveru, a také přenosové možnosti jeho propojení s klientskými počítači.
O jaké služby se ale může jednat? Snad nejčastěji jde o službu, spočívající v uchovávání celých souborů. Počítač, vystupující v roli serveru, je obvykle vybaven větším objemem diskové paměti, a svým klientům nabízí možnost uchovávat jejich soubory na svém disku. Tato možnost se označuje jako file serving, a příslušný server jako file server (česky též: souborový server). Další možnosti naznačuje vložený box.
| Server? Ale jaký? |
|
Starší, dnes již nepoužívanou variantou serveru, byl tzv. disk server, který svým klientům nabízel doslova "holý kus" svého disku (na úrovni jednotlivých fyzických stop, cylindrů a sektorů), a klientský počítač s tímto "kusem" hospodařil sám - tj. sám si na něm vytvářel systém souborů, sám si hospodařil s volným místem atd. Disk server tedy svým klientům poskytoval služby typu "zapiš sektor", "přečti sektor", a vše ostatní si musel zajistit klientský počítač sám. Dnes se však místo disk serverů používají téměř výlučně file servery, které si celé své disky organizují podle svého, a samy si také zajišťují veškerou agendu s uchováváním souborů. Svým klientům pak poskytují služby typu "zapiš soubor", "přečti soubor", případně "zapiš část souboru" či "přečti část soubor".
Další možností je poskytování tiskových služeb. Server tohoto typu (tzv. print server) má k sobě připojenu tiskárnu, a svým klientům poskytuje jako službu tisk na této tiskárně. Poněkud exotičtěji mohou znít názvy jako modem server (někdy též: asynchronous communications server), který svým klientům poskytuje přístup k jednomu (či několika) modemům, dále fax server, který zase poskytuje přístup k faksimilnímu zařízení, či tzv. access server (doslova: přístupový server), který zase umožňuje vzdálený přístup k uzlovým počítačům sítě (nejčastěji prostřednictvím komutovaných linek). Existují však i další druhy serverů, jejichž služby nemají povahu sdílení technických prostředků. Může jít například o databázové servery, informační servery apod., které jako své služby poskytují nejrůznější informace a data. |
Zdůrazněme si ještě jednu důležitou skutečnost, která často nebývá explicitně uváděna. V právě popsaném modelu klient-server je možné, aby počítač v roli serveru byl tomuto účelu plně vyhrazen, a nevykonával již žádné jiné funkce. Pak jde o tzv. dedikovaný server (dedicated server). S tímto řešením se můžeme setkat nejčastěji u lokálních počítačových sítí (například u file serverů v sítích LAN na bázi systému Novell NetWare, o kterém bude ještě řeč). Další možností je pak tzv. nededikovaný server (non-dedicated server), který svou funkci serveru vykonává vedle dalších činností - může být současně i pracovní stanicí, na které uživatelé provozují své aplikace.
Je ale možná i jiná strategie, která se v současné době začíná stále více prosazovat v lokálních počítačových sítích. Je označována jako peer-to-peer, a je založena na tom, že jeden a tentýž počítač může současně vystupovat v roli serveru i v roli klienta. Tedy že jeden počítač může současně nabízet některé své služby (například přístup k některým souborům na svém lokálním disku) jiným počítačům, ale sám také bude využívat služby jiných počítačů (například tisk na tiskárně, připojené k jinému počítači, či některé soubory na jeho disku atd.).
V prostředí víceúlohového operačního systému (tedy například v Unixu) je pak také možné, aby jeden a tentýž počítač vystupoval v roli klienta i serveru sám vůči sobě. Tedy aby jedna jeho úloha vykonávala roli serveru, zatímco jiná úloha byla v roli klienta, který využívá jeho služeb.
Klient-server v prostředí Unixu
Podívejme se nyní, podobně jako v případě terminálové emulace, jak může být model klient - server v prostředí Unixu realizován. Zaměřme se přitom na služby, spočívající v uchovávání souborů, tedy na file servery a jejich klienty.
Jak jsme si již naznačili v prvním článku, může být přístup klienta k souborům na serveru realizován dvěma principiálními způsoby: jako transparentní, kdy se soubory na serveru z pohledu klienta "tváří" stejně, jako jeho lokální soubory, a konečně netransparentním způsobem, kdy si klient plně uvědomuje, že soubory na serveru jsou "jiné", než jeho lokální soubory, a proto s nimi také jiným způsobem pracuje.
Způsob realizace druhé z obou možnosti, tedy netransparentního přístupu, je v podstatě shodný se způsobem zajišťování vzdálených relací. Představujme si počítač A s terminálem T v roli klienta, a počítač B v roli file serveru. Uživatel, který pracuje na počítači A z terminálu T, si spustí k tomu určenou aplikaci (označme ji ftp), která naváže spojení s počítačem B v roli serveru. Zde na její výzvu odpoví příslušný démon (označme jej ftpd), který bude partnerem aplikace ftp, a bude jí zprostředkovávat služby file serveru. Když pak uživatel vznese například požadavek na přenos určitého souboru ze serveru (počítače B) na svůj klientský počítač (počítač A), učiní tak prostřednictvím aplikace ftp, která příslušný požadavek předá démonu ftpd na počítači B. Ten pak ve spolupráci s operačním systémem počítače B zajistí odeslání požadovaného souboru na počítač A.
Je jistě zřejmé, že i v tomto případě musí aplikace ftp a démon ftpd používat stejný protokol. V prostředí Unixu jde obvykle o protokol FTP (File Transfer Protocol).
Jak je tomu ale v případě, kdy počítač v roli klienta chce využívat služeb file serveru transparentním způsobem? Zde je situace v principu obdobná, mění se však postavení příslušné klientské složky na počítači A. Ta je nyní spíše v postavení démona, než uživatelem spouštěné aplikace. Musí být totiž zabudována do operačního systému počítače A, a pro uživatele není běžně viditelná. Kdykoli uživatel (resp. jím spuštěná aplikace) vznese požadavek na přístup k souboru, činí tak prostřednictvím operačního systému. Jelikož pro uživatele není rozdíl mezi lokálními a vzdálenými soubory vůbec viditelný, dokáže až operační systém rozpoznat, o který případ jde. Jedná-li se o požadavek na přístup ke vzdálenému souboru, který je ve skutečnosti umístěn na file serveru, musí příslušná klientská složka operačního systému zformulovat požadavek na file server, a doručit jej k tomu určenému démonu na serveru. Ten ve spolupráci s operačním systémem serveru zajistí vše potřebné, a výsledek pošle zpět operačnímu systému klientského počítače A. Ten jej pak vrátí zpět uživateli, jako odpověď na jeho původní požadavek. Vrátí mu jej přitom naprosto stejným způsobem, jako kdyby šlo o požadavek přístupu k některému lokálnímu souboru, a celý mechanismus práce se soubory na vzdáleném serveru tak zůstává pro uživatele zcela neviditelný.
Pro prostředí operačního systému Unix byly vytvořeny dva hlavní protokoly pro plně transparentní přístup k souborům na vzdáleném serveru. Historicky starší je protokol RFS (Remote File Sharing), vyvinutý firmou AT&T. V současné době má však téměř dominantní postavení poněkud mladší protokol NFS (Network File System), vyvinutý firmou Sun Microsystems, Inc.
Když Unix servíruje DOSu
Vraťme se ale opět k tomu, co nás v tomto článku zajímá nejvíce: k možnostem spolupráce MS DOSu a Unixu. I zde je možné, aby počítače v roli serverů a klientů stály na různých platformách. Zaměříme-li se na file servery, bude jistě nejčastějším případ, kdy v roli file serveru bude vystupovat Unixovský počítač, a v roli klientů počítače PC s MS DOSem (i když i opačný případ je možný, jak uvidíme dále). Podobně jako v případě vzdálených terminálových relací musí i zde platit, že operační systémy na straně serveru i klienta musí implementovat stejné přenosové protokoly, aby mezi sebou vůbec dokázaly přenášet jakákoli data. Je-li toto splněno, musí se obě strany dále shodnout i na stejném protokolu pro netransparentní přenos, resp. transparentní sdílení souborů. V praxi to znamená, že na počítači PC s MS DOSem musí být implementovány protokoly FTP resp. NFS.
V případě protokolu FTP přichází v úvahu stejné řešení, jako při terminálové emulaci. Protokol FTP bude implementován jako samostatná aplikace pod MS DOSem, kterou si uživatel na základě skutečné potřeby spustí, přenese z/do serveru soubory, které právě přenést potřebuje, a pak zase práci s aplikací ukončí. Takovéto implementace protokolu FTP pro prostředí MS DOSu jsou dnes již vcelku běžné, a to nejen jako komerční produkty, ale již i jako tzv. public domain software - tj. zadarmo. Téměř vždy tvoří tyto produkty větší programový balík, ve kterém jsou navíc implementovány i prostředky pro vzdálené terminálové relace a terminálovou emulaci (známými programovými balíky tohoto typu, z kategorie public domain, jsou např. NCSA Telnet, a MS Kermit). Některé tyto programové balíky (např. NCSA Telnet) také umožňují, aby se počítač PC stal (dedikovaným) FTP serverem, a jiné počítače (mj. Unixovské) pak mohou vůči němu vystupovat v roli klientů. Jde tedy o prostředek, který Unixovským počítačům umožňuje přístup k souborům na počítači PC s MS DOSem.
 |
Zastavme se ale ještě u jedné skutečnosti - u toho, jakým způsobem musí být protokol NFS implementován v prostředí MS DOSu na straně klienta. Operační systém MS DOS totiž sám nijak nevychází vstříc možnosti transparentního sdílení souborů. Potíž je v tom, že když MS DOS přijme od aplikace požadavek na přístup k souboru, a tento soubor není lokální, neumí příslušný požadavek sám předat někomu jinému, kdo by jej dokázal uspokojit. Jestliže tedy DOS sám není schopen rozlišit a správně nasměrovat požadavky na lokální a vzdálené soubory, musí být toto rozlišení a následné přesměrování požadavku provedeno ještě dříve, než se příslušný požadavek vůbec dostane k operačnímu systému MS DOS!! V prostředí MS DOSu proto musí být protokol NFS implementován jako "slupka" (označovaná jako: shell, někdy též: redirector) nad vlastním operačním systémem, která místo něj zachytává všechny požadavky aplikací na přístupy k souborům, a vlastnímu MS DOSu pak předává jen ty, které se týkají lokálních souborů. Ostatní požadavky - tj. požadavky na přístup k souborům na vzdáleném serveru - pak řeší ve vlastní režii, bez spolupráce s MS DOSem (viz obrázek 2).
A co Novell ?
Bylo by asi chybou nezmínit se v této souvislosti alespoň stručně o síťovém operačním systému NetWare firmy Novell. Také ten svým uživatelům nabízí plně transparentní přístup k souborům, umístěným na file serveru systému NetWare. Vše přitom funguje na stejném principu, jako výše uváděný příklad, kdy v roli file serveru vystupuje Unixovský počítač, a klientské počítače s MS DOSem mají k jeho souborům transparentní přístup prostřednictvím protokolu NFS. Rozdíl je pouze v tom, že file server systému NetWare používá vlastní (víceúlohový) operační systém, a jiný je samozřejmě také konkrétní protokol pro sdílení souborů, používaný místo protokolu NFS. Ale o tom až příště.