Vyšlo v týdeníku Computerworld č. 41/93 v roce 1993
Vytištěno z adresy: http://www.earchiv.cz/a93/a341c110.php3

NFS I.

V minulém dílu jsme se začali podrobněji zabývat problematikou plně transparentního přístupu ke vzdáleným souborům v počítačových sítích. Na příkladu operačních systémů Unix a MS DOS jsme si naznačili jeden z aspektů této problematiky - principiální způsob "navázání" mechanismů, které přístup ke vzdáleným souborům zajišťují, na konkrétní operační systém. Dnes se již začneme podrobněji věnovat jednomu konkrétnímu mechanismu, protokolu NFS.

Protokol NFS (Network File System) má v síťovém modelu a rodině protokolů TCP/IP poněkud specifické postavení. Jak jsme si uvedli již ve 42. dílu, "klasické" protokoly rodiny TCP/IP (např. IP, TCP, UDP apod.) pochází převážně z akademického prostředí. Vytvořily je kolektivy odborníků z univerzit USA v rámci programu, který financovala grantová agentura DARPA ministerstva obrany USA, a který vyústil ve vznik dnes již celosvětové sítě Internet, založené právě na těchto protokolech. Díky způsobu svého vzniku mohou být protokoly TCP/IP tzv. veřejným vlastnictvím (public domain), neboť v USA praktikují velmi spravedlivou zásadu: co bylo vytvořeno za peníze daňových poplatníků, to je také jejich vlastnictvím. V praxi to znamená, že tyto standardy "nepatří" žádné konkrétní instituci či dokonce komerční firmě, která by přístup k nim mohla komukoli omezovat, či dokonce požadovat za jejich zpřístupnění nějaké licenční poplatky. Jsou naopak běžně dostupné pro kohokoli, kdo o to projeví zájem, a to buď úplně zdarma, nebo jen za nezbytný manipulační poplatek.

Existuje pouze organizace, zajišťující administrativní agendu kolem zveřejňování těchto protokolů - je jí tzv. Network Information Center (zkratkou: NIC), financovaná opět z prostředků ministerstva obrany USA. Konkrétní formou kodifikace protokolů TCP/IP (stejně tak jako dalších mechanismů, zásad či principů, používaných v síti Internet) jsou dokumenty, označované jako RFC (Request For Comment, doslova: žádost o poznámky, resp. připomínky). Tyto dokumenty jsou sekvenčně číslovány, a jsou volně dostupné například prostřednictvím sítě Internet (ve formě textových souborů).

NFS je od Sun-ů

Protokol NFS se od tohoto schématu odlišuje tím, že vznikl jako vlastní řešení jedné komerční firmy - firmy Sun Microsystems, Inc., známého výrobce Unixovských pracovních stanic. Z tohoto pohledu by tedy bylo nutné označit protokol NFS za proprietární (proprietary).

Firma Sun Microsystems však koncipovala svůj protokol velmi důsledně jako otevřený - nejen po stránce technické (jako protokol, který lze implementovat pod různými operačními systémy a na různých počítačích), ale i po stránce autorsko-právní: zcela záměrně zveřejnila přesné specifikace protokolu NFS (i dalších dvou podpůrných mechanismů, RPC a XDR, ke kterým se ještě dostaneme), tak aby je mohli využívat i jiní výrobci, a vytvářet vzájemně kompatibilní systémy. Díky nesporným kvalitám samotného protokolu a díky prozíravé strategii firmy Sun se její očekávání naplnilo, a protokol NFS se stal velmi oblíbeným mechanismem pro implementaci plně transparentního přístupu ke vzdáleným souborům v počítačových sítích.

V současné době, díky jeho velkému rozšíření v sítích na bázi protokolů TCP/IP, lze protokol NFS považovat za součást rodiny protokolů TCP/IP. Svědčí o tom i skutečnost, že specifikace tohoto protokolu jsou zveřejněny formou dokumentu RFC (konkrétně RFC 1094). Příznačná je i skutečnost, že o tomto protokolu se nejčastěji hovoří jako o "protokolu, který vyvinula firma Sun", a nikoli jako o "protokolu firmy Sun".

Prozíravá autorskoprávní politika firmy Sun jistě velmi přispěla k výraznému úspěchu protokolu NFS, ale sama o sobě by zdaleka nestačila k jeho prosazení do života. O to se musely přičinit především přednosti protokolu jako takového. A jaké že tyto přednosti jsou? NFS vs. Unix Protokol NFS rozhodně nezapře, že byl vytvořen v Unixovském prostředí. Firma Sun jej ale nekoncipovala jako síťové rozšíření svého operačního systému SunOS (vlastní verze Unixu, vycházející z větve tzv. BSD Unixu), protože to by vylučovalo jeho využití jinými výrobci a možnost spolupráce s jejich produkty. Místo toho jej od začátku pojala jako univerzální síťové rozšíření, které není vázáno na určitý konkrétní operační systém. Protokol NFS tedy může být (a v praxi také skutečně je) implementován snad pro všechny "příchuti" Unixu. Není však zdaleka omezen je na operační systémy Unixovského typu. Je natolik univerzální, že může být implementován i pod jinými operačními systémy, MS DOS nevyjímaje (i když právě zde se, vzhledem k jednouživatelské a jednoúlohové povaze DOSu, lze setkat jen s implementacemi klientů, a nikoli serverů). Díky tomu pak může být protokol NFS úspěšně využíván jako prostředek pro plně transparentní sdílení souborů nejen mezi počítači s různými variantami Unixu, ale také mezi počítači, které stojí na zcela odlišných platformách - například Unixovský počítač může sloužit jako file server v lokálních sítích s počítači PC, provozujícími MS DOS.

Bezestavová filosofie

Jedním z klíčů k výraznému úspěchu protokolu NFS jistě bylo to, že je důsledně koncipován jako bezestavový (anglicky: stateless). Co to znamená a k čemu to je dobré?

Představme si nejprve opačný případ - tedy stavový protokol. Ten předpokládá, že klient i server se mohou nacházet v různých stavech, a v závislosti na průběhu své komunikace mezi nimi různě přecházet. Například když si klient vyžádá otevření souboru XY, server jeho žádosti vyhoví a soubor otevře. Tím ovšem přejde z jednoho stavu (který by bylo možné charakterizovat jako: soubor XY není otevřen) do jiného stavu (stavu: soubor XY je otevřen). Když si pak klient vyžádá uzavření souboru XY, server opět změní svůj stav atd.

S existencí různých stavů je ovšem spojena určitá stavová informace - ve výše uvedeném příkladu si server musí pamatovat, zda si příslušný klient otevřel soubor XY (a kromě toho i jakým způsobem atd.), nebo nikoli. A právě uchovávání této stavové informace může být velkým problémem. Může se totiž stát, že buď klient, nebo server náhle o tuto stavovou informaci přijdou - ať již vlivem výpadku spojení či v důsledku "pádu" počítače a jeho operačního systému (např. kvůli náhlému výpadku proudu, tzv. přebootování či z jiné příčiny).

Pokud ovšem jedna ze zúčastněných stran náhle přijde o svou stavovou informaci, neví, v jaké fází komunikace s protistranou se právě nachází, a proto v této komunikaci nemůže dost dobře pokračovat. Existují samozřejmě způsoby, jak zajistit potřebnou rekonvalescenci (uzel po výpadku může například rozeslat hlášení typu: "všechno je špatně, začínáme znovu"), ale příslušné mechanismy nejsou zdaleka bezproblémové (co když se například příslušné hlášení ztratí?), a navíc jsou dosti neefektivní.

Celá problematika zajištění korektní stavové komunikace mezi serverem a klientem je sice řešitelná, ale je značně netriviální. Firma Sun se s touto netriviálností vyrovnala tak, že stavový charakter komunikace vyloučila.

Protokol NFS je tedy bezestavový v tom smyslu, že server se po provedení jakéhokoli požadavku klienta nachází v přesně stejném stavu, jako před příchodem tohoto požadavku. V důsledku toho si pak nemusí pamatovat nic o průběhu či stavu komunikace s kterýmkoli klientem, a po případném výpadku či ztrátě spojení nemusí být prováděny žádné nápravné akce. Pokud nějaký klient přijde se svým požadavkem v době, kdy server je mimo provoz (či "spadne" právě v době, kdy takovýto požadavek zpracovává), klientovi stačí jeho požadavek opakovat až doby, než server znovu "naběhne". Pokud se klient do výpadku serveru "nestrefí", nemusí si tento výpadek vůbec uvědomit.

Šanci mají jen idempotentní

Bezestavovost tedy sebou přináší velkou robustnost (tj. odolnost proti negativním vlivům, v tomto případě výpadkům). Není to ovšem zadarmo. Cenou, kterou se za tuto robustnost platí, je možnost požadovat na serveru jen takové operace, které se v matematice označují velmi přesným, ale zato nepříliš libě znějícím přívlastkem: idempotentní. Co se tím míní?

Idempotentní je taková operace, kterou lze opakovat s přesně stejným efektem, jaký mělo její první provedení. Ukažme si to na příkladu: operace "načti z daného souboru X bytů, počínaje pozicí Y" je idempotentní, protože při každém svém provedení dá vždy stejný výsledek (a můžeme ji tedy vícekrát opakovat). Naproti tomu operace "načti z daného souboru dalších X bytů" idempotentní není, protože při každém jejím provedení budou načteny jiná data (dokud se nenarazí na konec souboru). Tuto druhou operaci může klient požadovat jen na stavovém serveru, který si jako svou stavovou informaci musí pamatovat, kam až příslušný klient "dočetl" daný soubor.

Jaký charakter má práce se soubory?

Jestliže jsou možné požadavky klienta na server omezeny jen na idempotentní operace, pak se jistě nabízí zajímavá otázka: je možné všechny potřebné akce se soubory realizovat pomocí idempotentních operací? Odpověď na tuto otázku je bohužel záporná.

Například obvyklé schéma práce se soubory, stylem "otevři soubor, zapisuj resp. čti, zavři soubor", je svou podstatou stavové (kvůli možným stavům dotyčného souboru). Lze jej ovšem převést na bezestavové - tím, že odstraní explicitní otevírání a zavírání souborů, a nahradí se implicitním otevřením a následným uzavřením v rámci každého jednotlivého čtení či zápisu. Proto také protokol NFS nenabízí žádné prostředky pro otevírání či zavírání souborů.

Existují ovšem i takové druhy akcí, které při nejlepší vůli není možné převést na idempotentní - příkladem může být tzv. APPEND (neboli připojování dat za aktuální konec souboru), nebo uzamykání souborů či jejich částí pro potřeby vícenásobného přístupu (například když jeden klient potřebuje, aby mezi dvěma jeho přístupy nemohl k témuž souboru přistupovat někdo jiný). Tvůrci protokolu NFS se s tímto problémem mohli vyrovnat v podstatě jediným možným způsobem - zákazem toho, bez čeho se lze obejít (což je příklad tzv. Append-u), či ponecháním takovýchto funkcí "vně" protokolu NFS (tedy tím, že je svěřili samostatným mechanismům, resp. protokolům, jako například uzamykání souborů).

Bezestavový může být efektivní

Další velkou výhodou bezestavového protokolu jsou menší požadavky na spolehlivost přenosových služeb, než jaké nutně musí mít protokol stavový. Ten totiž musí zajistit, aby všechny požadované operace byly prováděny vždy právě jednou, a navíc ještě ve správném pořadí. K tomu ovšem nutně potřebuje spolehlivé přenosové služby spojovaného charakteru. Naproti tomu bezestavový protokol nemusí klást žádné specifické požadavky na kvalitu a charakter transportních služeb, a může využít i nespolehlivé, ale zato rychlé přenosové protokoly.

I to je jeden z důvodů, který napomohl značné popularitě bezestavového protokolu NFS - jelikož nemá žádné specifické požadavky, dokáže vystačit prakticky s kterýmkoli transportním protokolem, který je k dispozici, a může si vybrat ten, který je nejrychlejší. V prostředí TCP/IP sítí obvykle využívá přenosových služeb protokolu UDP.