Ji°φ Peterka

Minule jsme si popisovali äklasickΘ" aplikace jako elektronickou poÜtu, p°enos soubor∙ a vzdßlenΘ p°ihlaÜovßnφ. Jsou to vÜechno aplikace (a s nimi souvisejφcφ protokoly), kterΘ vznikly p°φmo v samotnΘm sv∞t∞ TCP/IP. V souΦasnΘ dob∞ se ale zaΦφnß Φφm dßl tφm vφce prosazovat pon∞kud odliÜn² model - novΘ aplikace vznikajφ mnohdy mimo äsv∞t TCP/IP", tedy jako vlastnφ (obvykle proprietßrnφ) °eÜenφ jin²ch subjekt∙, a teprve nßsledn∞, kdy₧ prokß₧φ svou ₧ivotaschopnost a ·Φelnost, jsou zaΦle≥ovßny do äsv∞ta TCP/IP" a stßvajφ se jeho standardy. Prvnφ vlaÜtovkou tohoto trendu byl protokol NFS pro sdφlenφ soubor∙ v lokßlnφch sφtφch, pochßzejφcφ od firmy Sun Microsystems. DalÜφmi p°φklady pak mohou b²t protokoly zajiÜ¥ujφcφ fungovßnφ dnes tolik oblφben²ch Internetov²ch slu₧eb jako WWW, Gopher, IRC apod.

Sdφlenφ soubor∙ (NFS)

Pot°eba sdφlenφ soubor∙ se zaΦala objevovat s nßstupem lokßlnφch sφtφ, od kter²ch se oΦekßvalo ₧e sv²m u₧ivatel∙m nabφdnou mo₧nost sdφlenφ soubor∙ - navφc takovΘho sdφlenφ, p°i kterΘm by skuteΦnΘ fyzickΘ umφst∞nφ jednotliv²ch soubor∙ p°estalo hrßt roli (p°estalo by b²t äviditelnΘ", odsud takΘ" transparentnφ sdφlenφ). S postupem Φasu se objevila r∙znß °eÜenφ, kterß takovouto pot°ebu sdφlenφ soubor∙ dokßzala naplnit. Jednφm z nich bylo i °eÜenφ, kterΘ si pro sebe vyvinula firma Sun Microsystems, a nazvala jej NFS (Network File System).

V∙dΦφmi myÜlenkami sdφlenφ souboru ß la NFS jsou snaha o maximßlnφ robustnost a snaha o nezßvislost na konkrΘtnφ platform∞. A pak samoz°ejm∞ takΘ architektura klient/server, kterß je pot°eb∞ sdφlenφ soubor∙ doslova Üita na mφru - serverem (konkrΘtn∞ tzv., file serverem) je zde poΦφtaΦ, na kterΘm jsou sdφlenΘ soubory skuteΦn∞ umφst∞ny, zatφmco v roli jeho klienta vystupuje poΦφtaΦ, kter² k t∞mto soubor∙m chce mφt p°φstup. Snaha o maximßlnφ robustnost se pak projevuje v tom, ₧e komunikace mezi klientem a serverem je tzv. bezestavovß - co₧ znamenß, ₧e ka₧d² jednotliv² po₧adavek klienta zaΦφnß v₧dy äna zelenΘ louce", a je zcela nezßvisl² na tom, jak² byl p°φpadn² p°edchozφ po₧adavek. Server si pak nemusφ pamatovat v∙bec nic o p°φpadnΘ p°edchozφ komunikaci se sv²mi klienty - co₧ je doslova k nezaplacenφ pro p°φpadnΘ v²padky a poruchy, po kter²ch nenφ pot°eba v∙bec nic obnovovat. P°ispφvß k tomu i skuteΦnost, ₧e klient smφ klßst pouze tzv. idempotentnφ po₧adavky, neboli takovΘ kterΘ lze libovoln∞krßt opakovat, ale jejich v²sledek bude v₧dy stejn² - pak to toti₧ mß velmi jednoduchΘ i klient. Pokud se nedoΦkß odezvy na n∞kter² sv∙j po₧adavek, jednoduÜe jej vznese znovu.

Snaha o nezßvislost na konkrΘtnφ platform∞, kterou mß systΘm NFS takΘ doslova vrozenou, pak p°inßÜφ v²znamnΘ praktickΘ d∙sledky. ZejmΘna v tom, ₧e file server i jeho klient mohou stßt na r∙zn²ch platformßch. Nap°φklad file server m∙₧e b²t Unixov²m poΦφtaΦem, a jeho klient nap°φklad poΦφtaΦem PC s DOS-em, MS Windows atd.

V²Üe uvedenΘ vlastnosti systΘmu NFS se pak postaraly o to, ₧e p∙vodn∞ proprietßrnφ °eÜenφ firmy Sun Microsystems se prosadilo do praxe, a na celΘ Φß°e porazilo svΘ konkurenty - nap°φklad systΘm RFS (Remote File System, vyvinut² firmou AT&T). Ten toti₧ fungoval na stavovΘm principu (tj. jeho server si pamatoval urΦitΘ informace o sv²ch klientech mezi jejich jednotliv²mi po₧adavky), a tak byl mΘn∞ robustnφ. Ne₧ se ale systΘm NFS mohl stßt standardem äsv∞ta TCP/IP", musely b²t jeho specifikace pln∞ zve°ejn∞ny, a musely se stßt äve°ejn²m vlastnictvφm" (v tom smyslu, ₧e vyu₧itφ t∞chto specifikacφ nesm∞lo b²t vßzßno na ₧ßdnΘ licenΦnφ poplatky). Vlastn∞ tedy celΘ °eÜenφ, kterΘ p∙vodn∞ pat°ilo firm∞ Sun Microsystems (a kterß jej vyvinula na svΘ nßklady) muselo b²t p°edßno do äsv∞ta TCP/IP". Navφc muselo projφt celou standardizaΦnφ maÜineriφ TCP/IP, kterß specifikace NFS p°ejala a vydala jako sv∙j standard.

Zajφmavß je i implementaΦnφ strßnka sdφlenφ soubor∙ ß la NFS. I zde toti₧ firma Sun Microsystem p°iÜla se zajφmav²mi a podn∞tn²mi myÜlenkami, kterΘ se zßhy prosadily do sv∞ta TCP/IP. èlo p°edevÜφm o to, ₧e samotn² protokol NFS, realizujφcφ vlastnφ sdφlenφ soubor∙, doslova äpodlo₧ili" dv∞ma samostatn²mi slu₧bami - slu₧bou pro tzv. vzdßlenΘ volßnφ procedur (RPC, Remote Procedure Call], a XDR (eXternal Data Representation]. Smyslem mechanismu RPC (implementovanΘho stejnojmenn²m protokolem] je skr²t p°ed programßtory existenci sφt∞ a vytvo°it jim iluzi toho, ₧e vÜe se odehrßvß na jednom jedinΘm poΦφtaΦi - programßto°i zde volajφ procedury a funkce, o kter²m si myslφ ₧e jsou lokßlnφ (a pou₧φvajφ mj. i lokßlnφ konvence pro svΘ volßnφ, p°edßvßnφ parametr∙ apod.), ale ve skuteΦnosti jsou tyto procedury a funkce vykonßvßny (provßd∞ny) na vzdßlen²ch poΦφtaΦφch (odsud takΘ: vzdßlenΘ volßnφ procedur). V²hodou je pak skuteΦnost, ₧e aplikaΦnφ programßtor nemusφ znßt specifika sφt∞ a prßce v sφti. Mechanismus XDR pak zajiÜ¥uje p°φpadnΘ konverze datov²ch formßt∙, pokud jsou zapot°ebφ. Firma Sun Microsystems p°itom vymyslela oba mechanismy takov²m zp∙sobem, aby netvo°ily integrßlnφ souΦßst systΘmu NFS, a byly naopak relativn∞ nezßvislΘ a vyu₧itelnΘ i jin²mi aplikaΦnφmi slu₧bami a jejich protokoly.

Nep°ipomφnß vßm to ale samostatnou relaΦnφ a prezentaΦnφ vrstvu v referenΦnφm modelu ISO/OSI, kterou auto°i TCP/IP odmφtli jako nepot°ebnou? Pokud ano, mßte pravdu - zde se ve form∞ mechanism∙ RPC a XDR skuteΦn∞ objevuje n∞co, co lze p°ipodobnit k samostatn²m vrstvßm, zam∞°en²m obdobn∞ jako relaΦnφ a prezentaΦnφ vrstva ISO/OSI. Sv∞dΦφ to o starΘ dobrΘ pravd∞, ₧e nakonec se p°eci jen prosadφ zlatß st°ednφ cesta - a pak to takΘ sv∞dΦφ o tom, ₧e model TCP/IP je dostateΦn∞ pru₧n², kdy₧ dokßzal takov²to p°φstup elegantn∞ ävst°ebat".

World Wide Web

Slu₧ba World Wide Web, kterß dnes doslova h²be cel²m Internetem, mß po technickΘ strßnce mnoho spoleΦnΘho se sdφlenφm soubor∙ a systΘmem NFS. P∙vodn∞ toti₧ vznikla v komunit∞ fyzik∙ zab²vajφcφch se vysok²mi energiemi, jako °eÜenφ jejich pot°eby sdφlenφ informacφ, p°edevÜφm textovΘho charakteru (konkrΘtn∞ ve Üv²carskΘm st°edisku CERN). ╚asem se ale prosadila i do sv∞ta TCP/IP, a postarala se o neb²val² boom Internetu. Po strßnce implementaΦnφ jde op∞t o °eÜenφ, tvo°enφ n∞kolika slo₧kami - zejmΘna protokolem HTTP (HyperText Transfer Protocol), kter² definuje zp∙sob p°enosu WWW strßnek po sφti, mezi WWW serverem a jeho klientem, a pak jazykem HTML (HyperText Markup Language), kter² definuje formßt jednotliv²ch strßnek. V poslednφ dob∞ pak k t∞mto dv∞ma äzßkladnφm" slo₧kßm p°ib²vajφ dalÜφ, kterΘ majφ za ·kol dßle zvyÜovat schopnosti a funkΦnφ mo₧nosti slu₧by WWW. Jde nap°φklad o jazyk Java, mechanismy ActiveX, nebo r∙znΘ zabezpeΦovacφ mechanismy a protokoly (jako SSL, S/HTTP, SET apod.), kterΘ umo₧≥ujφ provßd∞t prost°ednictvφm slu₧by WWW bezpeΦnΘ transakce. Formßlnφ standardizace t∞chto slo₧ek, v rßmci obvyklΘ standardizaΦnφ maÜinΘrie sv∞ta TCP/IP, vÜak zatφm pon∞kud pokulhßvß - nenφ ostatn∞ ani moc divu, vzhledem k neuv∞°iteln∞ rychlΘmu v²voji v tΘto oblasti.

TakΘ po strßnce svΘho fungovßnφ mß slu₧ba WWW hodn∞ spoleΦnΘho se sdφlenφm soubor∙ ß la NFS. Komunikace WWW serveru a jeho klient∙ je toti₧ takΘ bezestavovß, a WWW server si tedy obecn∞ nepamatuje nic o tom, co po n∞m cht∞l urΦit² klient n∞kdy d°φve. D∙sledkem je v∞tÜφ robustnost ne₧ jakΘ by bylo mo₧nΘ dosßhnout p°i stavovΘm zp∙sobu komunikace. V²hody p°itom poci¥ujeme skoro vÜichni: pokud jste k Internetu p°ipojeni po modemu, tj. p°es komutovanΘ linky ve°ejnΘ telefonnφ sφt∞, pak vßÜ browser dokß₧e bez problΘm∙ p°e₧φt i v²padek spojenφ, a po op∞tovnΘm ädovolßnφ se" m∙₧ete ve svΘm brouzdßnφ pokraΦovat, jako kdyby se nic nestalo.