| VyÜlo v Φasopise: | Computer Echo |
| ╚φslo: | 2/93 |
| Datum: | 1993 |
| Strana: | 4-10 |
| Rubrika/kategorie: | Interoperabilita |
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.
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.
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.
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.
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∞.
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.
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.
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).