Vyšlo v týdeníku CHIPweek č. 10/96, 5. března 1996
Vytištěno z adresy: http://www.earchiv.cz/a96/a610k150.php3

X Window System

V dnešním dílu si popíšeme jedno zajímavé řešení, které je možné považovat buď za jednu konkrétní implementaci modelu klient/server, nebo za něco přesně obráceného, co vzájemně zaměňuje role klienta a serveru. Nevěříte?

Jednou za základních premis modelu klient/server je předpoklad, že dostupná přenosová kapacita je relativně malá a vzácná, a je tudíž třeba s ní šetřit. Bezprostředním důsledkem toho je pak snaha minimalizovat přenosy dat mezi jednotlivými uzlovými počítači, čehož se dosahuje zpracováním dat v místě, kde se tato data nachází. Přenášeny jsou pak jen požadavky na určitý druh zpracování, a dále již jen jeho výsledky. Výpočetní model klient/server, ke kterému jsme dospěli minule, však není jediným možným vyústěním zmíněné premisy - existuje dokonce celá škála různých řešení, které také vychází ze stejného předpokladu a snaží se jej naplnit, ale sledují přitom i své další specifické potřeby, a od modelu klient/server se mohou lišit jen velmi málo, nebo také dosti podstatně - zejména v tom, jaká je role a jaké je postavení jednotlivých složek celého vzájemně spolupracujícího systému. Na jedné straně spektra přitom stojí taková řešení, která počítají s existencí a se stejnou dělbou práce jako původní model klient/server, a v zásadě se tedy od něj příliš neliší (resp. Je možné je považovat za konkrétní způsob aplikace modelu klient/server). Příkladem může být koncepce systému X Window System, kterou si dnes popíšeme. Uprostřed spektra možných řešení pak jsou taková řešení, která místo s interakcí stylem 1:1 (jako v případě klienta a serveru) počítají spíše s interakcí 1:n, stále předpokládají určité specifické zaměření jednotlivých složek, ale již počítají s poněkud jinou dělbou práce než jen původní poskytování služeb (serverem) a jejich využívání (klientem). Příkladem může být koncepce, používaná v oblasti správy sítí (zejména v implementacích protokolu SNMP), a označovaná neformálně jako agent/manažer. No a na druhém konci spektra pak jsou plně distribuované systémy, předpokládající vzájemnou spolupráci n víceméně rovnoprávných složek. Toto si ale již necháme na příště.

Klient/server naruby?

Obrázek 1.
Představa systému X Window (redirectoru, shellu)
Koncepčně velmi zajímavá myšlenka se objevila u systému X Window, vyvinutého na prestižní univerzitě MIT (Massachussets Institute of Technology). Cílem přitom bylo vyřešit problém se zobrazováním grafických výstupů na rastrových displejích v síťovém prostředí, kde „výkonná" část provozovaných aplikací obvykle (ale ne nutně) běží na jiném uzlu, než na kterém pracuje uživatel a chtěl by s touto aplikací komunikovat. Na první pohled tato situace může připomínat centrální hostitelské počítače s jejich terminály a výpočetním modelem host/terminál, ale je zde jedna velmi významná odlišnost - zatímco zde je požadován grafický režim zobrazování, v případě modelu host/terminál se prakticky vždy pracuje ve znakovém režimu (tj. výstupy jsou generovány po celých znacích, a nikoli v rastrové grafice). Jestliže se pak mezi hostitelským počítačem a terminálem posílají data potřebná pro aktualizaci obrazovky, pak jde o kódy jednotlivých znaků, a jejich objem je relativně velmi malý. Pokud by se ale v rámci modelu host/terminál přešlo na grafický režim zobrazování, objem přenášených dat by náhle enormně stoupnul. Jen pro představu: zaplnit ve znakovém režimu celou obrazovku o 25 řádcích po 80 znacích, při „spotřebě" jednoho bytu na znak, vyžaduje přenos 25 x 80, resp. 2000 bytů. V grafickém režimu, při rozlišení 640 x 480 a 256 barvách na každý pixel (tj. při „spotřebě" 1 bytu na každý pixel), to obnáší již 307 200 bytů! Tedy zvýšení více než 150-násobné!

Systém X Window, jak už jeho název napovídá, usiluje o vytváření uživatelského rozhraní „okenního" typu, samozřejmě v grafickém režimu. Aby se však vyhnul neúnosně velkým přenosům grafických dat, snaží se zařídit věci tak, aby „velká" grafická data potřebná pro rastrovou grafiku byla generována přímo v místě kde budou zobrazována, a nikoli tam kde vzniká popud k jejich zobrazení. Usiluje tedy o to, aby po dostupných přenosových cestách byly přenášeny pouze pokyny, povely či jiné druhy příkazů specifikujících co má být zobrazeno, a nikoli vlastní data představující již hotový rastrový obrázek. Důsledkem je pak nutná dělba práce - vedle aplikace, která zadává popud k zobrazení a která může běžet v zásadě kdekoli v rámci sítě, musí existovat ještě další složka, provozovaná přímo v místě kde dochází k zobrazování - tedy na uživatelově počítači. Velmi zajímavé je pojmenování těchto složek: ta, která se stará o zobrazování, vlastně poskytuje tuto svou schopnost jako službu tomu, kdo k zobrazení zadává popud. Takže je asi na místě hovořit o serveru, konkrétně o X serveru. Druhá složka, tedy ta která zadává popud k zobrazení, pak služeb X serveru využívá, a je tedy správné ji označovat jako klienta (X klienta).

Nyní si to zkusme zrekapitulovat: představme si nějakou aplikaci, například databázového charakteru, která běží na určitém uzlovém počítači - tato aplikace bude v rámci systému X Window vystupovat v roli klienta (X klienta). Naproti tomu na počítači uživatele bude muset běžet složka zajišťující zobrazování, vystupující v roli X serveru. Kdykoli bude aplikace (X klient) potřebovat svému uživateli něco zobrazit, požádá o to X server na jeho počítači, neboli pošle tomuto serveru svůj požadavek na zobrazení. Naproti tomu X server informuje svého klienta o všech vstupech od uživatele - zejména o všech znacích zadaných z klávesnice, a o všech pohybech a kliknutích myší.

Není ale právě popsaný vztah X klienta a X serveru přesně opačný, než jaký jsme až dosud předpokládali u modelu klient/server? Ano, i ne. Je přesně opačný v tom, že aplikace zajišťují určitou specifickou funkčnost je zde v postavení klienta, zatímco v modelu klient/server bývá v postavení poskytovatele služby, neboli serveru. Mohlo by se tedy zdát, že zde došlo k určitému převrácení rolí oproti klasickému modelu klient/server. Na druhé straně je ale možné doložit i tvrzení, že k žádnému obrácení rolí nedošlo: vždyť poskytovanou službou je zde přeci zobrazování na uživatelově displeji a sběr vstupů od něj! No a ten, kdo tuto službu poskytuje, je serverem, zatímco ten kdo ji využívá je jeho klientem!

X Window

O historii a dalších zajímavostech kolem systému X Window se můžete dočíst také v dnešním dílu rubriky „Co to znamená, když se řekne ....", na straně 33. Zde si jen ve stručnosti řekněme konkrétnějšího o technické stránce. X Window System je jednak ucelená představa o rozdělení rolí a působností v tom smyslu, v jakém jsme si ji právě popsali. Kromě toho je součástí X Window System i komunikační protokol, prostřednictvím kterého si spolu „povídají" X klient a X server. Tento protokol je přitom protokolem aplikační úrovně, provozovaným nad takovým transportním protokolem, jaký je v dané síti k dispozici. Díky tomu je možné provozovat řešení na bázi systému X Window v zásadě kdekoli, v jakékoli síti nabízející obvyklé transportní služby rozumně - nejčastěji zřejmě v sítích na bázi TCP/IP. Díky tomu, že se mezi X serverem a jeho klientem přenáší pouze pokyny k provedení různých grafických operací, a tudíž relativně velmi malé objemy dat, nebývají nároky na přenosovou kapacitu sítě příliš velké.

Co naopak není součástí systému X Window je představa o tom, jak by mělo vypadat grafické uživatelské rozhraní, předkládané uživateli - co všechno by mělo obsahovat, jaký by mělo mít celkový „image", jaké funkce by mělo nabízet atd. To je ponecháno plně na aplikacích, vystupujících v roli X klientů. Stejně tak nejsou součástí systému X Window žádné tiskové služby či jiný druh podpory tisků.