Ji°φ Peterka: Co je Φφm ... v poΦφtaΦov²ch sφtφch (75):

NFS I.

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-∙

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

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φ

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?

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φ

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.