Rodina protokol
TCP/IP v. 2.2
Katedra softwarového inženýrství, Matematicko-fyzikální fakulta, Univerzita Karlova, Praha
Rodina protokol TCP/IP, verze 2.2
ást 8: TELNET, FTP a NFS Ji í Peterka, 2005
Rodina protokol
TCP/IP v. 2.2
P ipomenutí: aplikace v TCP/IP
• jsou vesm s postaveny na • historický vývoj: architektu e klient/server – zpo átku se používaly p edevším tyto aplikace: • sou ástí aplika ní vrstvy • TELNET jsou takové ásti aplikací, • p enos soubor (FTP) které jsou nutné pro • el. pošta (SMTP, FRC 822) interoperabilitu a "základní – pozd ji také: fungování" konkrétní služby • sdílení soubor (NFS) – obdobn jako v RM ISO/OSI – nap . transport zpráv a soubor
• uživatelské rozhraní již není sou ástí aplika ní vrstvy – není svázáno standardy trend k "platformizaci" – p vodn samostatné služby se stávají nadstavbou nad WWW
• Gopher • ….
– dnes p evládá (krom pošty):
• WWW (jako samostatná aplikace i jako platforma pro provozování dalších aplikací, nap . vyhledávacích služeb, adresá , …)
2
Rodina protokol
TCP/IP v. 2.2
Vzdálené p ihlašování (remote login)
• cílem je možnost "používat aplikace na dálku" – uživatel je na místním po íta i, ale aplikace b ží na vzdáleném po íta i
• týká se aplikací fungujících na bázi výpo etního modelu "host/terminál" – typicky: starších aplikací fungujících ve znakovém režimu – aplikací které ani nemusí po ítat s tím že fungují v prost edí sít
• podmínka: – aplikace musí podporovat tzv. terminálové relace • musí své výstupy posílat "skrz OS" na terminál a své vstupy p ijímat "skrz OS" z terminálu – takto se d je nap . v prost edí UNIXu
• nesmí "jít napevno" do videoRAM a klávesnicového bufferu – jako v MS DOS
– také opera ní systém musí podporovat terminálové relace 3
Rodina protokol
TCP/IP v. 2.2
P edstava výpo etního modelu host/terminál
aplikace
aplikace
terminál
opera ní
systém
vstupy
procesor pam soubory programy
terminál
výstupy
hostitelský po íta
4
Rodina protokol
TCP/IP
P edstava terminálové relace
v. 2.2
po íta ová sí
aplikace
hostitelský po íta
hostitelský po íta
(lokální) (lokální) terminálová terminálová relace relace
vzdálená vzdálená terminálová terminálová relace relace
A
B
TA1
TA2
TA3
TB1
TB2
TB3
terminál
terminál
terminál
terminál
terminál
terminál
5
Rodina protokol
TCP/IP v. 2.2
Vzdálené p ihlašování v TCP/IP
• TELNET
• rlogin – vzniknul v prost edí BSD Unixu – je vázán na prost edí Unixu (BSD Unixu), a podporuje tzv. “trusted hosts”
– “hlavní” prost edek pro realizaci vzdáleného p ihlašování v rámci TCP/IP, snaží se být maximáln univerzální
• dokáže si n které informace “vytáhnout” ze svého okolí (nap . jméno uživatele a jeho heslo) .... • ... a pak je využít, nap . pro automatické p ihlášení uživatele na vzdáleném po íta i
• snaží se nevázat na konkrétní systémové prost edí (nebýt závislý na opera ním systému) • podporuje terminálové relace mezi r znými platformami – na stran uživatele po ítá i s terminálovou emulací
• ... nabízí jen jednoduché služby, a nikoli nap . možnost automatického p ihlašování apod.
– podporuje pouze znakové uživatelské rozhraní
• ICA (WinFrame, MS Terminal Server) – nové ešení, podporuje grafiku
•
áste n také: – systém X Window 6
Rodina protokol
TCP/IP v. 2.2
Terminálová emulace vs. TELNET aplikace TELNET server
(lokální) terminálová relace
IP sí emulátor emulátorterminálu terminálu protok
ol TE LNET
TELNET klient
A hostitelský po íta
TA1
TA2
TA3
terminál
terminál
terminál
vzdálená vzdálená terminálová terminálová relace relace
T1
po po íta íta , ,emulující emulující jednoú jednoú elový elovýterminál terminál
TB3
7
Rodina protokol
TCP/IP v. 2.2
TELNET - principy
• TELNET server je realizován na aplika ní úrovni – – – –
jako systémová úloha - démon, a nikoli “uvnit ” OS výhoda: snazší modifikace nevýhoda: ne každý OS tomu vychází vst íc nevýhoda: je to mén efektivní než p ímé zabudování do OS TELNET server
TELNET klient Opera ní systém
aplikace
Opera ní systém
IP sí
používá používáse se TCP TCP
8
Rodina protokol
TCP/IP v. 2.2
TELNET – základní problém
• “každý terminál je jiný”
– v p ípad TELNETu jde hlavn o tvar, v jakém se mají data p enášet TCP/IP sítí
• liší se: – v rozsahu schopností – v parametrech – v režimu fungování • znakový • celoobrazovkový • formulá ový
• TELNET zavádí jeden, pevn daný mezistupe : virtuální terminál NVT (Network Virtual Terminal)
• s odlišnostmi terminál se lze vyrovnat p izp sobením stylem “každý s každým” – ... nebo p es spole ný mezistupe , s p izp sobením typu “každý s jedním” a “jeden s každým”
– NVT má vždy stejné vlastnosti – reálné terminály se mu p izp sobují (jsou mapovány z/do NVT) – NVT p edevším definuje formát skute n p enášených dat 9
Rodina protokol
TCP/IP
TELNET - p edstava
v. 2.2
platforma 1 TELNET klient
zde zdejejepoužíván používán specifický specifickýformát formát platformy, na platformy, nakteré které "stojí" klient "stojí" klient
zde jsou data p enášena ve formátu NVT
platforma 2 TELNET server
aplikace
zde zdejejepoužíván používán specifický specifickýformát formát platformy, na platformy, nakteré které "stojí" klient "stojí" klient
10
Rodina protokol
TCP/IP v. 2.2
Vlastnosti NVT
• NVT je “spole ným jmenovatelem” ... – ... povinným minimem, které musí “um t” všechny reálné terminály – NVT odpovídá jednoduchému ádkovému terminálu
• TELNET obsahuje mechanismy, pomocí kterých se klient se serverem mohou dohodnout “na lepším” – jde o tzv. options
• NVT odpovídá jednoduchému znakovému terminálu, tj.: – data jsou len na na ádky – data jsou p enášena po znacích – komunikuje se pouze poloduplexn – používá se lokální echo
• p vodní p edstava: – NVT odpovídá klávesnici a tiskárn
11
Rodina protokol
TCP/IP v. 2.2
Vlastnosti NVT
• pro p enos využívá spolehlivé p enosové služby TCP (ale jen poloduplexním zp sobem) – p enos je znakov orientovaný – a vždy 8-bitový (tj. jednotlivé znaky se p enáší vždy v 8 bitových bytech) – ... ale standardn se p edpokládá p enos 7-bitových ASCII znak • je povinnost zobrazovat 95 tisknutelných ASCII znak (s kódy 32 až 127) • ... a povinnost interpretovat znaky NULL, CR a LF • dále je p esn definován význam znak BEL, BS, HT, VT, FF (ale jejich interpretace není povinná)
– ostatní znaky nemají mít žádný efekt – požaduje se, aby klávesnice byla schopna generovat všech 128 ASCII znak – znak, kterým je zakon ena ádka (resp. znaky), musí TELNET klient nahradit dvojicí znak CR a LF • klient server naopak nahradí CR a LF takovým znakem (znaky), které na jeho stran p edstavují zakon ení ádky
– p enos 8-bitových znak je jedním z volitelných režim (options) 12
Rodina protokol
TCP/IP v. 2.2
TELNET - ídící p íkazy
• NVT po ítá i s implementací ídících mechanism – nap . pro p erušení práv probíhajícího programu, pomocí CTRL+C)
• ...a k tomu pot ebuje p enášet ídící p íkazy, povely atd. –
ídící p íkazy mají zásadn znakovou povahu (tvo í je ídící znaky)
• pro zajišt ní transparence se používá prefixace (uvození) speciálním znakem IAC (Interpret As Command), s kódem 255 – p ípadný výskyt znaku IAC v datech se eší jeho zdvojením.
•
ídící p íkazy jsou trojího druhu: – edita ní p íkazy: • umož ují mazat znak a ádku
– ídící p íkazy: • umož ují p erušit probíhající proces, zastavit jeho výstup ...
– “dohadovací” p íkazy: • umož ují ob ma stranám dohodnout se na p ípadných rozší eních oproti NVT 13
Rodina protokol
TCP/IP v. 2.2
TELNET - rozší ení
• umož ují ob ma stranám • zásada: použití rozší ení je dohodnout se na jiném, než co dobrovolné vyplývá z pevn daných – kterákoli strana má právo navrhnout použití konkrétního vlastností NVT, nap .: rozší ení (tj. jak klient, tak i – zda budou komunikovat v plném server) duplexu, – druhá strana má právo použití – že p enášená data budou rozší ení odmítnout odesílána po ádcích s možností jejich lokální editace • k “dohadování” slouží – že budou používat vzdálené samostatné p íkazy: echo – WILL ("já chci používat – jakou velikost displeje budou rozší ení ….") používat • odpov : DO vs. DON'T – jaký zp sob ízení toku budou – DO ("chci abys ty používal používat rozší ení ….") – …… • odpov
: WILL vs. WON'T
14
Rodina protokol
TCP/IP v. 2.2
TELNET - rozší ení
• p esná specifikace jednotlivých rozší ení ( íselný kód, sémantika) není apriorn uzav ena (omezena) – nová rozší ení mohou vznikat postupn (a být definována prost ednictvím dokument RFC) – existuje dokonce i mechanismus pro “rozši ování rozší ení”
• další p íklad rozší ení: vým na informací o konkrétním typu terminálu – umož uje aplikacím lépe p izp sobit sv j výstup možnostem terminálu (nap . p ímým nastavováním kurzoru na zadanou pozici apod.)
• pro jednotlivá rozší ení m že dojít k podrobn jším “licitacím” – TELNET jejich pr b h nespecifikuje – ... je definován až samotným rozší ením (a m že tedy být pro n j specifický) – TELNET definuje pouze zp sob zajišt ní transparence dat p i další “licitaci” 15
Rodina protokol
TCP/IP v. 2.2
Vzdálené p ihlašování vs. práce se soubory
• cíl: – “chci pracovat se souborem, který se nachází na jiném po íta i” – p esn ji: chci zpracovávat obsah vzdáleného souboru, pomocí aplikace, která b ží na “mém” uzlu
• !!!... ú elem není dostat se do role vzdáleného terminálu jiného uzlu … !!! – pak by byl soubor zpracováván aplikací b žící na vzdáleném po íta i 16
Rodina protokol
TCP/IP v. 2.2
P enos vs. sdílení soubor
• p enos soubor : – jde o netransparentní ešení • uživatel/aplikace si uv domuje, že soubor se nachází na vzdáleném po íta i • uživatel/aplikace musí explicitn znát umíst ní souboru na vzdáleném po íta i • uživatel/aplikace musí explicitn podnikat ur ité kroky ke zp ístupn ní souboru
– typicky: vzdálený soubor se celý p enese na "místní" po íta a zde se zpracuje
• ozna uje se jako "file transfer" – v rámci TCP/IP eší protokol FTP (File Transfer Protocol)
• sdílení soubor : – jde o transparentní ešení • uživatel/aplikace si neuv domuje, že soubor se nachází na vzdáleném po íta i • uživatel/aplikace nemusí explicitn znát umíst ní souboru na vzdáleném po íta i • uživatel/aplikace nemusí podnikat žádné explicitní kroky ke zp ístupn ní souboru
– typicky: vzdálený soubor se "chová" ("tvá í") jako místní soubor, a také se s ním jako s místním pracuje
• ozna uje se jako "file sharing" – v rámci TCP/IP eší protokol NFS (Network File System)
17
Rodina protokol
TCP/IP v. 2.2
Problémy p enosu a sdílení soubor
• protokoly pro p enos a sdílení se musí vyrovnat s mnoha úskalími, typu: – rozdílnost v pohledu na soubory, jejich jména, p ípony .... – vlastnictví soubor , jejich atributy – .....
•
• problém je i se zajišt ním vícenásobného p ístupu k soubor m – lze použít “obecné” techniky typu: • uzamykání celých soubor jejich ástí • replikace • ponechat vše na uživateli • .....
i
ešení je snazší u netransparentního p ístupu (file transfer)
– kde lze požadovat po uživateli, aby rozdílnosti vy ešil vlastním rozhodnutím – nap íklad aby zadal atributy místního souboru, do kterého má být p enesen (zkopírován) obsah vzdáleného souboru 18
Rodina protokol
TCP/IP v. 2.2
Protokol FTP (File Transfer Protocol)
• je starší než rodina protokol TCP/IP – pochází již z roku 1971 (vznikl nad protokolem NCP) – teprve pozd ji “portován” nad p enosové protokoly TCP/IP – .... p esn ji nad protokol TCP
• protokol FTP vzniknul v dob , kdy se opera ní systémy a platformy lišily více než dnes
• dnes ale v tšina t chto "dávných" vlastností není podporována – protože mezitím došlo ke zna nému sjednocení • jediný významn jší poz statek:
– mj. ve velikosti slov, znázorn ní znak , nap .: – n kdo umis oval ty i 9-bitové znaky do • jednoho 36-bitového slova – jiný OS umístil do 36-bitového slova p t 7bitových znak – ..... musí se mu íci, co bude p enášet
musí se mu íci, co bude p enášet (zvolit (zvolitjeden jedenzzrežim režim ))
– snaha konvertovat text p i jeho p enosu mezi r znými platformami • nap íklad kódování, konce ádek, …
FTP pracuje ve dvou režimech: – textovém – provádí konverze • implicitn
– binárním – konverze neprovádí
19
Rodina protokol
TCP/IP v. 2.2
FTP – textové p enosy
• FTP zavádí jednotný formát dat pro pot eby p enosu – veškeré konverze z/do tohoto formátu ponechává na koncových uzlech – umož uje ale ob ma stranám dohodnout se v konkrétním p ípad na jiném formátu (kv li v tší efektivnosti p enosu)
• FTP p enáší data zásadn jako 8-bitové byty • pro text používá FTP stejný formát, jako protokol TELNET: – jednotlivé znaky p enášeny v 8 bitech – konec ádky = CR+LF – kódování ASCII
• alternativní možností je použití kódu EBCDIC, použití nestandardní velikosti bytu atd. 20
Rodina protokol
TCP/IP v. 2.2
FTP – p edstava a p enos soubor
dnes se již nepoužívá
• FTP implicitn chápe soubor • implicitn je obsah souboru jako dále nestrukturovaný (bez p enášen jako spojitý proud vnit ní struktury) - ozna ováno dat (tzv. stream mode) jako file structure – alternativou je blokový režim (block mode), p i kterém je – alternativn je schopen se na n j dívat jako na posloupnost stejn velkých záznam (records) -
record structure
– nebo jako na množinu stránek (které mohou tvo it nespojitý soubor) - page structure
možné vkládat mezi bloky “zarážky”, a po ev. výpadku spojení se k nim vracet – další alternativou je zhušt ný režim (compressed mode), kdy je používána jednoduchá metoda komprese (eliminující opakující se znaky)
21
Rodina protokol
TCP/IP v. 2.2
FTP - implementace
• vychází z modelu klient/server – klient je typicky aplika ním programem – server obvykle systémovým procesem (démonem, rezidentním programem apod.) – návrh protokolu je uzp soben možnosti úsporné implementace (takové, která si nárokuje v tšinu systémových zdroj až v okamžiku jejich skute né pot eby)
• zajišt ní pot ebných funkcí v rámci FTP je rozd leno mezi dva subjekty: – interpret protokolu (PI, Protocol Interpreter) – p enosový proces (DTP, Data Transfer Process)
• interpret protokolu existuje trvale, – p enosový proces vzniká až na základ konkrétního požadavku
• používají se dv r zná spojení: – ídící (pro p enos p íkaz ) – datové (pro p enos soubor ) 22
Rodina protokol
TCP/IP v. 2.2
Implementace protokolu FTP požadavek na p enos p enos souboru
systém soubor
klient uživatelské rozhraní
interpret protokolu
ídící spojení
interpret protokolu
p enosový proces
datové spojení
p enosový proces
systém soubor
využívají se transportní služby protokolu TCP 23
Rodina protokol
TCP/IP v. 2.2
Datové a ídící spojení
• odd lení datového a ídícího spojení je výhodné: – kv li zajišt ní transparence – kv li možnosti p erušit probíhající p enos – kv li možnosti signalizovat konec souboru • uzav ení datového spojení signalizuje konec souboru • lze p enášet soubory které b hem p enosu nar stají
• definice FTP (RFC) požaduje aby datové spojení bylo 1 pro všechny p enášené soubory – v praxi se pro každý p enášený soubor používá 1 (samostatné, nové) datové spojení
•
ídící spojení "p ežívá" po celou dobu relace, datová spojení se m ní
•
ídící spojení iniciuje (navazuje) klient – ze svého (dynamicky p id leného) portu na port 21 • ruší se až explicitním p íkazem
• datové spojení iniciuje (navazuje) server – ze svého portu 20 na port klienta, ze kterého bylo navázáno ídící spojení – passive-mode: datové spojení nenavazuje server, ale klient • kv li firewall m, které neakceptují žádosti o otev ení spojení vedoucí dovnit na "náhodný" port 24
Rodina protokol
TCP/IP v. 2.2
Uživatelé a FTP
• FTP je “user aware” – uv domuje si existenci uživatel
• server p i p ístupu k místním soubor m vždy vystupuje jménem konkrétního uživatele – FTP pot ebuje mechanismy pro p ihlášení uživatele a jeho autentikaci (ov ení identity)
• uživatelé se v rámci "FTP relace" musí identifikovat – musí se p ihlásit místním uživatelským jménem a prokázat platným heslem
• anonymní FTP – konvence: má-li být n co ve ejn p ístupné, uživatelé se hlásí jako "anonymous" • a heslo není významné, obvykle se požaduje emailová adresa kv li statistikám 25
Rodina protokol
TCP/IP v. 2.2
ídící jazyk FTP
• FTP definuje vlastní ídící jazyk – p íkazy ídícího jazyka jsou p enášeny ídícím spojením
•
ídící p íkazy mají textovou povahu, a jsou p enášeny ve stejném tvaru, jakou p edpokládá protokol TELNET – resp. pro jejich p enos mohou být využívány již existující implementace TELNETu
• p íkazy lze rozd lit na: ízení p ístupu (access control commands) - nap . pro zadání uživatelského jména a hesla – nastavení parametr p ístupu (transfer parameter commands) - nap . pro zm nu implicitních ísel port , pro nastavení režimu p enosu apod. – výkonné p íkazy (FTP service commands) - pro vlastní p enos soubor , rušení, p ejmenovávání atd., pro p echody mezi adresá i apod. –
26
Rodina protokol
TCP/IP v. 2.2
Odpov di na p íkazy FTP
• každý p íkaz vyvolá alespo jednu odpov • odpov di mají íselný charakter (s textovým komentá em) • odpov di tvo í trojmístné íslo: – první íslice vyjad uje celkový charakter odpov di – druhá íslice up es uje odpov – t etí ješt blíže specifikuje
• hierarchický charakter odpov dí vychází vst íc r zné inteligenci proces , které je vyhodnocují – “hloupý” klient i server se m že spokojit jen s první íslicí – “chytrý” klient (server) využije všechny íslice
1xx
p edb žná kladná odpov (akce byla zahájena, budou ješt další odpov di)
2xx
kladná odpov
3xx
prozatímní odpov (jsou nutné další p íkazy)
4xx
do asná záporná odpov (nepoda ilo se, ale je vhodné opakovat)
5xx
trvalá záporná odpov (nepoda ilo se a nemá smysl opakovat)
27
Rodina protokol
TCP/IP
P íklad
v. 2.2
klient • RETR <soubor> za átek pr b h innosti konec
server • .... požadavek • 160 ASCII retrieve of <soubor> started • .. probíhá p enos • 226 Transfer completed, 123456 bytes transferred
textový textovýkomentá komentá ––generování generovánílze lzevypnout vypnout 28
Rodina protokol
TCP/IP v. 2.2
ídící vs. uživatelský jazyk
• pevn definován a závazný je ídící jazyk – p íkazy ídícího jazyka mohou být vysílány “ru n ”, pomocí TELNETu (na porty FTP)
• v praxi je na stran klienta vždy implementováno n jaké uživatelské rozhraní ( ádkové, grafické, ..…) – toto rozhraní m že nabízet uživateli v podstat jakýkoli "uživatelský" ( ídící) jazyk
uživatelský ídící jazyk jazyk
RETR
GET
STORE
PUT
LIST
DIR
CWD
CD
• a p ekládat jej do ídícího jazyka
typické typicképro pro ádkové ádkovéklienty klienty 29
Rodina protokol
TCP/IP v. 2.2
P íklad
30
Rodina protokol
TCP/IP v. 2.2
P íklad ( ádkový klient)
PP íkaz íkazuživatele uživatele pro provypsání vypsáníobsahu obsahu adresá adresáee
31
Rodina protokol
TCP/IP v. 2.2
P íklad (grafický klient) p íkaz kopírování
soubory místního po íta e
soubory vzdáleného po íta e
32
Rodina protokol
TCP/IP v. 2.2
P íklad (grafický klient)
vzdálené vzdálené soubory soubory
33
Rodina protokol
TCP/IP v. 2.2
TFTP – Trivial FTP
• existují situace, kdy protokol FTP není nejvýhodn jší: – nap . pro tzv. bootstrap bezdiskových stanic je p íliš složitý – pro n které jednoduché OS je problém jej implementovat
• v rámci rodiny TCP/IP existuje “o ezaná” verze FTP pod názvem TFTP (Trivial FTP) – používá se hlavn pro "natažení" tzv. boot image p i startu bezdiskových stanic
•
využívá p enosových služeb protokolu UDP (FTP využívá TCP) – TFTP si spolehlivost zajiš uje sám, • využívá jednotlivé potvrzování • p enáší data po blocích velikosti 512 byt
•
TFTP nezná pojem uživatele – nezajiš uje žádné p ihlašování na vzdáleném po íta i • ponechává na implementaci, jak se vy eší p ístupová práva. • Obvykle: pro TFTP dostupné je to, co je dostupné pro všechny uživatele
•
TFTP nezajiš uje na vzdáleném po íta i žádné systémové akce typu ls, cwd, rm apod. – nezná pojem aktuálního adresá e
•
uživatel musí explicitn zadat úplnou p ístupovou cestu k souboru, který má na mysli (a musí jej znát) 34
Rodina protokol
TCP/IP v. 2.2
Protokol NFS (Network File System)
• protokol pro transparentní sdílení soubor (file sharing) – v rámci TCP/IP není jediný, ale je nejrozší en jší
• má jiný p vod než “klasické” protokoly TCP/IP – pochází od firmy Sun Microsystems (p vodn byl proprietárním ešením) – posléze byl NFS p edložen IAB (IETF) ke standardizaci – dnes je standardem (RFC 1094) a jeho specifikace jsou public domain
• vznikl v prost edí Unixu (SunOS, na bázi BSD Unixu) – je ale koncipován jako otev ený (jako univerzální sí ové rozší ení systém soubor na r zných platformách)
• není vázán ani na SunOS, ani na Unix jako takový – dnes je implementován snad na všech platformách
• p ipouští, aby klient i server stáli na r zných platformách 35
Rodina protokol
TCP/IP v. 2.2
Protokol NFS (Network File System)
• NFS je bezestavovým protokolem
• bezestavový charakter p ipouští pouze použití – každý jednotlivý požadavek idempotentních operací klienta v i serveru je (takových, které lze vícekrát “uzav ený”, p ed a po provedení opakovat se stejným p íkazu se server nachází ve stejném stavu efektem)
– velmi to zjednodušuje zajišt ní korektnosti komunikace klienta a serveru (reakci na nestandardní situace, výpadky, ..)
• bezestavovost NFS je klí em k velké robustnosti NFS – není nutné ošet ovat r zné výpadky a singularity
– nelze nap . používat p íkazy typu “pošli mi další ást souboru XY” – mohou to být pouze p íkazy typu “pošli mi M byt souboru XY, po ínaje bytem N”
dd vod vodúsp úsp šnosti šnostiNFS NFS 36
Rodina protokol
TCP/IP v. 2.2
Problémy kolem NFS
• je možné realizovat všechny • NFS si klade za cíl být použitelný požadavky na p ístup k soubor m na r zných platformách pomocí idempotentních operací? – nem že se proto vázat na konvence – NE, nelze nap . provést OPEN žádné specifické platformy (otev ení), a soubor ponechat – p i odkazech na soubory nem že otev ený, obdobn pro CLOSE používat specifikace p ístupových – NFS eší tak, že pro pot eby vy ízení cest typu /usr/bin/neco.txt (které jsou každého jednotlivého požadavku závislé na platform ) soubor nejprve otev e, a pak jej zase ihned zav e
• n které p ípady nelze obejít – jako u OPEN a CLOSE – nap . APPEND (p idání za aktuální konec souboru) • NFS eší zákazem takovýchto operací
• p ístupové cesty sestavuje vždy až klient podle místních konvencí, server používá vždy jen "jednorozm rná" jména soubor a adresá
– po áte ní "p imontování" (mount) ásti adresá ového stromu není bezestavové • NFS eší vy len ním do tzv. MOUNT SERVERU 37
Rodina protokol
TCP/IP v. 2.2
P edstava dd láláto, to,co coNENÍ NENÍ bezestavové bezestavové
dd láláto, to,co coJE JE bezestavové bezestavové
klient klientaaserver serverppi ivzájemné vzájemnékomunikaci komunikacipoužívají používajísystémové systémové identifikace soubor (a adresá ) – tzv. file handle identifikace soubor (a adresá ) – tzv. file handle
38
Rodina protokol
TCP/IP v. 2.2
Systémová identifikace - handle
• pro odkazy na konkrétní soubory se v rámci NFS používají tzv. systémové identifikace (file handles) – pro klienta je handle identifikátorem (dále ned litelnou posloupností bit ) – pro server handle obsahuje t i složky, identifikující • systém soubor • soubor • instanci souboru
• systémová identifikace (handle) jednozna n identifikuje bu soubor, nebo adresá – systémové identifikace p id luje server, klient je pouze používá – systémové identifikace mají absolutní povahu (a nikoli relativní, NFS nezná pojem aktuálního adresá e)
• systémová identifikace (handle) je ukazatelem na jedno konkrétní místo v rámci systému soubor serveru – když klient vlastní systémovou identifikaci adresá e, m že si vyžádat výpis jeho obsahu – sou ástí výpisu je seznam znakových et zc , popisujících jednotlivé soubory a podadresá e – klient si m že vyžádat na serveru systémovou identifikaci zadaného souboru v adresá i ( i identifikaci podadresá e) .... • ... serveru p itom musí p edat systémovou identifikaci adresá e, a znakový et zec popisující soubor i podadresá
39
Rodina protokol
TCP/IP v. 2.2
MOUNT server
• klient musí získat alespo jeden vstupní bod do systému soubor serveru (alespo jednu systémovou identifikaci) – pak má k dispozici prost edky pro procházení celého stromu (systému soubor serveru)
• poskytnutí "prvního" handle ale není v silách NFS serveru – vyžaduje specifikaci p ístupové cesty
• první handle poskytuje MOUNT server !!
• MOUNT server eší další innosti, které také nem že zajiš ovat NFS server – vede evidenci zp ístup ovaných (exportovaných) adresá ových strom – po áte ní "p imontování" adresá ového stromu • v etn ov ení identity uživatele a jeho p ístupových práv
• MOUNT server je typicky ešen na aplika ní úrovní – nezáleží na jeho rychlosti – NFS server bývá sou ástí jádra a je optimalizován na rychlost 40
Rodina protokol
TCP/IP v. 2.2
Implementace NFS
• poprvé významn ji použit koncept tzv. vzdáleného volání procedur – prost ednictvím protokolu RPC - Remote Procedure Call) – jde v zásad o zm nu na úrovni programování • programátor nemusí ešit asynchronní komunikaci, ale pouze volá p edem p ipravené procedury knihovního charakteru
• implementace RPC je ešena tak, že m že být využita i samostatn – mimo implementaci NFS
• dále je využit také protokol XDR (eXternal Data Representation) – samostatný standard, který definuje spole ný p enosový mezitvar – je standardem v rámci TCP/IP – definuje jednotný zp sob reprezentace p enášených dat, nezávislý na konkrétní architektu e p íjemce a odesilatele – definuje jazyk pro nezávislý popis t chto dat
• také XDR je implementováno samostatn , jako RPC
41
