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

Transportnφ rozhranφ - Streams a TLI

Pro sprßvnΘ pochopenφ myÜlenek, na kter²ch je zalo₧ena implementace protokol∙ TCP/IP v prost°edφ AT&T Unixu, je vhodnΘ si nejprve up°esnit Φasov² sled jednotliv²ch udßlostφ. Mechanismus "sockets", kter²m jsme se zab²vali minule, byl vyvinut pro verzi 4 BSD Unixu, kterß se poprvΘ objevuje v roce 1981. Do AT&T Unixu se obdobn² mechanismus dostßvß a₧ ve verzi System V Release 3 (zkrßcen∞ SVR3), kterou firma AT&T ohlßsila v roce 1987. Rozdφl Üesti let je hodn∞ dlouhou dobou, za kterou se zcela zßkonit∞ musely projevit r∙znΘ v²vojovΘ trendy, novΘ koncepce i novΘ po₧adavky na operaΦnφ systΘm Unix jako takov².

Jednφm z t∞chto po₧adavk∙ byl tlak na v∞tÜφ modularitu a flexibilitu celΘho vstupn∞/v²stupnφho subsystΘmu. OperaΦnφ systΘm Unix je toti₧ koncipovßn tak, ₧e jeho jßdro (kernel) obsahuje zßkladnφ Φßst, nezßvislou na konkrΘtnφm hardwaru, a dßle pak r∙znΘ ovladaΦe (drivers), kterΘ zßkladnφ Φßsti jßdra zprost°edkovßvajφ vÜe, co ji₧ je zßvislΘ na konkrΘtnφm hardwaru danΘho poΦφtaΦe. Tyto ovladaΦe se sice navenek "tvß°φ" jako specißlnφ soubory (a jako s takov²mi se s nimi takΘ pracuje), ve skuteΦnosti jsou ale souΦßstφ jßdra. To vÜak mj. znamenß, ₧e p°i p°idßnφ novΘho ovladaΦe Φi jakΘkoli jinΘ zm∞n∞ je t°eba minimßln∞ znovu sestavit celΘ jßdro.

Krom∞ z°ejmΘ nepru₧nosti mß tato strategie i dalÜφ nev²hodu, kterß se nejvφce projevila prßv∞ u implementace sφ¥ov²ch protokol∙. Souvisφ s tφm, ₧e takto °eÜenΘ ovladaΦe Φasto znovu implementujφ funkce, kterΘ jsou souΦasn∞ implementovßny i v jin²ch ovladaΦφch. Celkovß koncepce operaΦnφho systΘmu a jeho jßdra p°itom nevychßzφ p°φliÜ vst°φc mo₧nosti realizovat tyto spoleΦnΘ funkce jen jednou, a p°φsluÜnΘ moduly sdφlet. MyÜlenka °eÜit sφ¥ov² software formou ovladaΦ∙ (drivers), tedy "v jednom balφku", takΘ nenφ p°φliÜ v souladu s vrstevnatou koncepcφ sφ¥ovΘho softwaru, kterß si p°φmo °φkß o modulßrnφ implementaci.

PoΦßtkem osmdesßt²ch let, kdy byly protokoly TCP/IP zaΦle≥ovßny do BSD Unixu, nebyl jeÜt∞ tlak na modularitu a flexibilitu vstupn∞/v²stupnφho subsystΘmu Unixu takov², aby si vynutil i nov² zp∙sob implementace samotn²ch sφ¥ov²ch protokol∙. V BSD Unixu jsou tyto protokoly stßle chßpßny a implementovßny jako ovladaΦe (ovladaΦe specißlnφch za°φzenφ), a nov∞ je °eÜen pouze zp∙sob prßce s nimi. "Sockets" jsou z tohoto pohledu jen tenkou "slupkou", kterß ovladaΦe p°ekr²vß, a zajiÜ¥uje takov² zp∙sob p°φstupu k nim, jak² vyhovuje i nejr∙zn∞jÜφm sφ¥ov²m aplikacφm.

Do AT&T Unixu se protokoly TCP/IP dostßvajφ ji₧ v dob∞, kdy si nepru₧nost dosavadnφ koncepce V/V subsystΘmu sama vynutila zm∞nu. Zhruba v roce 1984 p°ichßzφ jeden ze spoluautor∙ Unixu, Dennis Ritchie, s myÜlenkou novΘho mechanismu, p°φznaΦn∞ nazvanΘho streams (doslova: proudy). Ten pak byl takΘ pou₧it i pro implementaci TCP/IP protokol∙ v prost°edφ AT&T Unixu, a pro zp°φstupn∞nφ t∞chto protokol∙ byla vytvo°ena novß p°ekr²vajφcφ "slupka", oznaΦovanß jako TLI neboli Transport Layer Interface (rozhranφ transportnφ vrstvy).

Co jsou proudy?

Obr. 63.1.: P°edstava p°φstupu k ovladaΦi
a/ bez proud∙
b/ s proudy

Dynamick²m vklßdßnφm jednotliv²ch modul∙ do proudu vznikß cel² °et∞zec, na jeho₧ jednom konci stojφ ovladaΦ (oznaΦovan² takΘ jako stream end, neboli koncov² modul proudu), a na druhΘm konci tzv. hlaviΦka proudu (stream head). Ta zajiÜ¥uje pot°ebnΘ p°izp∙sobenφ mezi procesem, kter² s proudem pracuje, a proudem jako takov²m. Mezi hlaviΦku a ovladaΦ jsou za°azovßny moduly, kterΘ mohou provßd∞t v podstat∞ jakΘkoli akce s daty, kterΘ skrz n∞ prochßzφ. Cel² proud p°itom pracuje v pln∞ duplexnφm re₧imu - data tedy mohou prochßzet proudem ob∞ma sm∞ry souΦasn∞. KonkrΘtnφ zp∙sob komunikace jednotliv²ch modul∙ v rßmci proudu je takov², ₧e ka₧d² v₧dy zpracuje data, p°evzatß od svΘho bezprost°ednφho souseda z jednΘ strany, a v²sledek zpracovßnφ zase p°edß svΘmu sousedovi z druhΘ strany.

Podstatn² je ovÜem takΘ zp∙sob, jak²m proud vznikß a utvß°φ se. Na poΦßtku je ka₧d² proud vytvß°en jen jako dvouprvkov², a obsahuje tedy jen vlastnφ ovladaΦ (stream end) a svou hlaviΦku (stream head). Za°azovßnφ jednotliv²ch modul∙ "doprost°ed" proudu (konkrΘtn∞ bezprost°edn∞ za hlaviΦku) se pak provßdφ dynamicky, na zßklad∞ skuteΦnΘ pot°eby. Slou₧φ k tomu operace, oznaΦovanß p°φznaΦn∞ jako push (vlo₧enφ novΘho modulu do proudu, bezprost°edn∞ za hlaviΦku). Stejn∞ tak je mo₧nΘ jednotlivΘ moduly z proudu dynamicky vyjφmat, a to operacφ pop (kterß vyjme modul bezprost°edn∞ za hlaviΦkou).

Tφmto zp∙sobem je mo₧nΘ za°azovat do proudu moduly, zajiÜ¥ujφcφ nejr∙zn∞jÜφ funkce - od jednoduch²ch filtr∙ a p°evodnφk∙ a₧ po mnohem slo₧it∞jÜφ transformace. Pro pot°eby sφ¥ovΘho softwaru se p°φmo vnucuje myÜlenka realizovat p°enosovΘ protokoly jednotliv²ch vrstev ve form∞ takov²chto modul∙, a pak z nich dynamicky sestavovat celΘ hierarchickΘ sestavy protokol∙ (protocol stacks). Tedy nap°φklad transportnφ protokoly TCP a UDP realizovat jako dva (alternativnφ) moduly, sφ¥ov² protokol IP jako dalÜφ modul, a na ovladaΦi (nap°. ovladaΦi sφ¥ovΘho adaptΘru) ponechat p°φmΘ ovlßdßnφ hardwaru (resp. protokoly, spadajφcφ do vrstvy sφ¥ovΘho rozhranφ).

Transport Layer Interface

Pro nßs je ovÜem podstatnΘ, ₧e v²sledn² proud (stream) se nadßle "tvß°φ" jako specißlnφ soubor, a zp∙sob jeho implementace (pomocφ proudu) tudφ₧ nenφ pro aplikaΦnφ procesy p°φliÜ relevantnφ. Pro n∞ je naopak zapot°ebφ obdobnß "slupka", jakou je BSD Unixu rozhranφ socket interface (viz minule), kterß by p°ekryla p°φsluÜnΘ proudy, a zp°φstupnila transportnφ slu₧by takov²m zp∙sobem, jak² vyhovuje aplikaΦnφm proces∙m.

V BSD Unixu je zmφn∞nß "slupka" realizovßna formou systΘmov²ch volßnφ, co₧ jsou ve skuteΦnosti vstupnφ doby do jßdra, a teprve to pak zajiÜ¥uje veÜkerΘ po₧adovanΘ slu₧by. DatovΘ struktury, kterΘ se v tΘto souvislosti pou₧φvajφ (tj. vlastnφ sockety) jsou vytvß°eny v pam∞ti, kterß takΘ pat°φ jßdru, a to si zabezpeΦuje vÜe pot°ebnΘ pro alokaci a nßslednΘ uvol≥ovßnφ tΘto pam∞ti.

U AT&T Unixu jsou analogiφ systΘmov²ch volßnφ v BSD Unixu volßnφ knihovnφch rutin, kterΘ se p°ilinkovßvajφ k aplikaΦnφm proces∙m, a jsou tudφ₧ provozovßny v adresovßm prostoru t∞chto proces∙. Stejn∞ tak jsou v adresovΘm prostoru aplikaΦnφch proces∙ alokovßny i veÜkerΘ datovΘ struktury, kterΘ jsou t∞mito knihovnφmi rutinami vyu₧φvßny.

Rozhranφ k aplikaΦnφm proces∙m, kterΘ tyto knihovnφ rutiny vytvß°φ, je v AT&T Unixu verze System V oznaΦovßno jako Transport Layer Interface (zkrßcen∞: TLI, doslova: rozhranφ transportnφ vrstvy).

Obr. 63.2.: Sockets (a/) vs. transport endpoints (b/)

Operace, kterΘ toto rozhranφ nabφzφ, jsou v mnohΘm obdobnΘ operacφm, kterΘ se pou₧φvajφ pro prßci se sockety v BSD Unixu. V²znamn∞jÜφm rozdφlem je vÜak povaha objekt∙ na rozhranφ mezi transportnφ a aplikaΦnφ vrstvou. Zatφmco v BSD Unixu je tφmto objektem datovß struktura (tj. socket), v p°φpad∞ TLI hraje tutΘ₧ roli spojenφ dvou entit - u₧ivatele slu₧by (kter² sφdlφ v aplikaΦnφ vrstv∞), a poskytovatele slu₧by (kter² sφdlφ ve vrstv∞ transportnφ), viz obr. 63.2.b/. Toto lokßlnφ spojenφ je v terminologii TLI oznaΦovßno jako transport endpoint (doslova: koncov² bod transportnφho spojenφ), a je tedy analogiφ socketu v BSD Unixu. Z°izuje se pomocφ rutiny t_open, kterß je obdobou systΘmovΘho volßnφ open v BSD Unixu, a teprve nßsledn∞ s nφm musφ b²t sdru₧eno i vhodnΘ Φφslo portu (jako adresa transportnφho spojenφ), rutinou t_bind (kterß je analogickß systΘmovΘmu volßnφ bind v BSD Unixu).

Obr. 63.3.: P°edstava prßce s rozhranφm TLI p°i spojovanΘ komunikaci

DalÜφ postup na stran∞ serveru ukazuje obrßzek 63.3.: po volßnφ rutiny t_bind si p°φsluÜn² aplikaΦnφ proces v roli serveru sßm alokuje pam∞¥ pro datovΘ struktury, kterΘ bude p°i komunikaci pou₧φvat, a pak volß rutinu t_listen. Ta Φekß na volßnφ od klienta, a vracφ °φzenφ zp∞t v okam₧iku, kdy takovΘto volßnφ p°ijde. Klient naopak vyu₧ije k navßzßnφ spojenφ rutinu t_connect, s obdobn²m efektem jako v BSD Unixu.

Pokud je server ochoten akceptovat p°ichßzejφcφ volßnφ (kterΘ p°edstavuje v²zvu k navßzßnφ spojenφ), volß rutinu t_accept, kterß volßnφ p°ijme, a zajistφ navßzßnφ spojenφ s klientem. Pak ji₧ m∙₧e nßsledovat vlastnφ p°enos dat (rutinami t_rcv a t_snd, nebo p°φmo operacemi read a write), a ukonΦenφ spojenφ (kterΘ m∙₧e b²t realizovßno bu∩ jako "°ßdnΘ", zaruΦujφ doruΦenφ vÜech ji₧ odeslan²ch dat, nebo jako ukonΦenφ "okam₧itΘ", kterΘ toto nezaruΦuje).

Obr. 63.4.: P°edstava prßce s rozhranφm TLI p°i nespojovanΘ komunikaci

P°φpad nespojovanΘho zp∙sobu komunikace mezi klientem a serverem ukazuje obrßzek 63.4.: zde po alokaci pam∞ti pro datovΘ struktury ihned nßsleduje vlastnφ p°enos dat.

Zajφmavou odliÜnostφ AT&T Unixu a BSD Unixu je to, zda server m∙₧e odmφtnou volßnφ klienta, Φi nikoli. V BSD Unixu to mo₧nΘ nenφ - systΘmovΘ volßnφ accept zde Φekß na jakΘkoli volßnφ, a to v₧dy p°ijme. Teprve pak se server dozvφdß (z v²stupnφch parametr∙ systΘmovΘho volßnφ accept), kdo mu vlastn∞ zavolal, a pouze nßsledn∞ m∙₧e ji₧ navßzanΘ spojenφ zase zruÜit. Naproti tomu v AT&T Unixu mß server mo₧nost odmφtnout urΦitΘho klienta, a spojenφ s nφm v∙bec nenavßzat. Na volßnφ klienta toti₧ Φekß rutina t_listen, kterß s nφm vÜak nenavß₧e spojenφ, ale pouze vrßtφ pot°ebnΘ informace o tom, kdo vlastn∞ volß. Server se podle nich rozhodne bu∩ volßnφ p°ijmout (tj. navßzat spojenφ, pomocφ rutiny t_accept), nebo jej odmφtnout (v tomto p°φpad∞ volß rutinu t_snddis).