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

Transportnφ rozhranφ

V minul²ch dφlech naÜeho serißlu jsme se podrobn∞ji zab²vali sφ¥ovou a transportnφ vrstvou sφ¥ovΘho modelu TCP/IP. D°φve, ne₧ se budeme v∞novat aplikaΦnφ vrstv∞ a jednotliv²m aplikacφm, se musφme jeÜt∞ zmφnit o jednΘ d∙le₧itΘ v∞ci: o vazb∞ mezi transportnφ vrstvou a aplikaΦnφmi programy. Tedy o tom, jakΘ mechanismy a jakΘ postupy mohou, resp. musφ aplikaΦnφ programy pou₧φvat, cht∞jφ-li zφskat p°φstup ke slu₧bßm transportnφ vrstvy.

JeÜt∞ d°φve si ale musφme uv∞domit jednu v²znamnou skuteΦnost: implementace nejni₧Üφch vrstev urΦitΘho sφ¥ovΘho modelu je v₧dy souΦßstφ operaΦnφho systΘmu poΦφtaΦe, zatφmco nejvyÜÜφ vrstva (aplikaΦnφ) ji₧ souΦßstφ operaΦnφho systΘmu nenφ. O p°esnΘ hranici, tedy o tom, kterß vrstva jeÜt∞ je souΦßstφ operaΦnφho systΘmu a kterß ji₧ ne, pak rozhoduje p°edevÜφm samotn² sφ¥ov² model a jeho p°edstava o tom, jak mß b²t sφ¥ov² software Φlen∞n na vrstvy. V p°φpad∞ sφ¥ovΘho modelu TCP/IP je za souΦßst operaΦnφho systΘmu pova₧ovßna jeÜt∞ transportnφ vrstva, zatφmco vrstva aplikaΦnφ ji₧ stojφ nad operaΦnφm systΘmem.

To mß ale jeden velmi zßva₧n² d∙sledek: p°φstup ke slu₧bßm transportnφ vrstvy TCP/IP zprost°edkovßvß aplikacφm operaΦnφ systΘm. Zp∙sob, jak²m se tak d∞je - tedy jednotlivΘ mechanismy a postupy - jsou pak dßny konkrΘtnφm operaΦnφm systΘmem a jeho celkovou koncepcφ. Proto je dobrΘ rozliÜit dv∞ v∞ci: protokoly, pou₧φvanΘ na ·rovni transportnφ vrstvy, a rozhranφ transportnφ vrstvy sm∞rem k vrstv∞ aplikaΦnφ (tzv. transportnφ rozhranφ). Transportnφ protokoly musφ b²t na vÜech vzßjemn∞ komunikujφcφch poΦφtaΦφch stejnΘ, a proto mohou b²t v rßmci sφ¥ovΘho modelu TCP/IP standardizovßny. Transportnφ rozhranφ je ale zßvislΘ na konkrΘtnφm operaΦnφm systΘmu, a na r∙zn²ch poΦφtaΦφch tedy m∙₧e b²t r∙znΘ. Proto dost dob°e nem∙₧e b²t v rßmci sφ¥ovΘho modelu TCP/IP jakkoli standardizovßno.

V tΘto souvislosti je vhodnΘ si znovu zd∙raznit, ₧e TCP/IP rozhodn∞ nenφ to samΘ, co Unix. Unix je jeden z mnoha operaΦnφch systΘm∙, a TCP/IP je jedna z mnoha soustav protokol∙ a nßzor∙ na to, jak majφ vypadat a fungovat poΦφtaΦovΘ sφt∞ (tedy to, co zde oznaΦujeme jako sφ¥ov² model). Tv∙rci operaΦnφho systΘmu Unix si sφ¥ov² model TCP/IP oblφbili natolik, ₧e pro pot°eby propojovßnφ sv²ch poΦφtaΦ∙ do sφtφ ji₧ nepou₧φvajφ nic jinΘho. To ale rozhodn∞ neznamenß, ₧e by v prost°edφ Unixu nemohly b²t implementovßny jinΘ sφ¥ovΘ modely resp. architektury. Stejn∞ tak to rozhodn∞ neznamenß, ₧e by sφ¥ov² model TCP/IP nemohl b²t implementovßn i v prost°edφ jin²ch operaΦnφch systΘm∙. Dnes takΘ skuteΦn∞ existujφ implementace TCP/IP snad pro ka₧d² existujφcφ operaΦnφ systΘm, od MS DOSu pro poΦφtaΦe PC a₧ po operaΦnφ systΘm VM/CMS st°ediskov²ch poΦφtaΦ∙ firmy IBM. Je zde vÜak p°eci jen urΦitß odliÜnost, kterß svßdφ ke ztoto₧≥ovßnφ TCP/IP s Unixem: implementace protokol∙ TCP/IP je dnes ji₧ pova₧ovanß za standardnφ souΦßst Unixu, tj. je p°φmou souΦßstφ dodßvky tohoto operaΦnφho systΘmu. V p°φpad∞ ostatnφch operaΦnφch systΘm∙ je vÜak pouze jednφm z mnoha dopl≥kov²ch produkt∙, kterΘ si u₧ivatel dokupuje zvlßÜ¥ (a Φasto si takΘ m∙₧e vybrat z ÜirÜφ nabφdky r∙zn²ch implementacφ).

Jestli₧e tedy mohou b²t protokoly TCP/IP implementovßny v prost°edφ r∙zn²ch operaΦnφch systΘm∙, znamenß to souΦasn∞, ₧e v ka₧dΘm z nich budou slu₧by transportnφ vrstvy p°φstupnΘ jin²m zp∙sobem. To je velmi d∙le₧itΘ nejen pro samotnΘ aplikace a jejich tv∙rce, a takΘ pro zp∙sob, jak²m mohou b²t v rßmci sφ¥ovΘho modelu TCP/IP standardizovßny nejobvyklejÜφ aplikace typu elektronickΘ poÜty, p°enosu soubor∙, vzdßlen²ch terminßlov²ch relacφ apod. Standardizovat je mo₧nΘ (a nutnΘ) celkovou koncepci t∞chto aplikacφ a konkrΘtnφ protokoly, prost°ednictvφm kter²ch budou spolupracovat (nap°. p°edßvat si jednotlivΘ zprßvy v rßmci elektronickΘ poÜty, celΘ soubory v rßmci aplikacφ pro p°enos soubor∙ atd.). Nenφ ale ji₧ mo₧nΘ standardizovat p°esn² zp∙sob, jak²m budou tyto aplikace vyu₧φvat slu₧eb transportnφ vrstvy.

Budeme-li si dßle popisovat konkrΘtnφ °eÜenφ transportnφho rozhranφ v prost°edφ Unixu, je dobrΘ mφt na pam∞ti, ₧e jde jen o konkrΘtnφ p°φklady mo₧nΘho °eÜenφ.

Jak je to v Unixu

Pro nßs je zajφmavΘ to, ₧e operaΦnφ systΘm Multics jako prvnφ sjednotil zp∙sob prßce se vstupn∞/v²stupnφmi za°φzenφ - na vÜechna tato za°φzenφ se dφval jako na zvlßÜtnφ soubory, a pracoval s nimi stylem "otev°i - Φti - piÜ - zav°i".

Kdy₧ pak Bellovy laborato°e (Bell Labs, souΦßst tehdy jeÜt∞ mamutφho AT&T) odstoupily od projektu Multics, vznikl na jejich p∙d∞ (v roce 1969) operaΦnφ systΘm Unix. Jeho auto°i (Ken Thompson a jeho spolupracovnφk Dennis Ritchie) do n∞j p°evzali i jednotn² pohled na vstupn∞/v²stupnφ za°φzenφ z p∙vodnφho Multicsu. Unix se tedy ji₧ od svΘho vzniku sna₧il dφvat se na vÜechna vstupn∞/v²stupnφ za°φzenφ jako na specißlnφ soubory, a jako s takov²mi s nimi takΘ pracoval. Na ·rovni operaΦnφho systΘmu proto nabφzel operace typu: open (otev°enφ souboru), read (Φtenφ z ji₧ otev°enΘho souboru), write (zßpis do souboru) a close (uzav°enφ d°φve otev°enΘho souboru, signalizujφcφ konec prßce s nφm), pomocφ kter²ch se pak realizovaly veÜkerΘ vstupn∞/v²stupnφ operace. Specißlnφm souborem, se kter²m se p°itom pracovalo, byl ve skuteΦnosti ovladaΦ p°φsluÜnΘho za°φzenφ (kter² se jako soubor pouze "tvß°il").

Tento pohled na vstupn∞/v²stupnφ za°φzenφ a zp∙sob prßce s nimi si Unix v podstat∞ ponechal dodnes, a pro b∞₧nß vstupn∞/v²stupnφ za°φzenφ (terminßly, disky apod.) je toto °eÜenφ vcelku postaΦujφcφ.

Kdy₧ se pak v prost°edφ Unixu zaΦaly implementovat sφ¥ovΘ protokoly TCP/IP, bylo vcelku p°irozenΘ, ₧e se nejprve pou₧il stejn² mechanismus. Sφ¥ byla pova₧ovßna za vstupn∞/v²stupnφ za°φzenφ, a "tvß°ila" se jako specißlnφ soubor. P°φsluÜnΘ protokoly pak byly implementovßny v rßmci ovladaΦe p°φsluÜnΘho za°φzenφ, kter² navenek vystupoval prßv∞ jako specißlnφ soubor.

Zßhy se ale ukßzalo, ₧e zp∙sob prßce se sφtφ je p°eci jen komplikovan∞jÜφ a nßroΦn∞jÜφ, ne₧ zp∙sob prßce se skuteΦn²mi vstupn∞/v²stupnφmi za°φzenφmi, a ₧e tudφ₧ vy₧aduje jinΘ, obecn∞jÜφ mechanismy. Uka₧me si to na p°φkladu.

Operace open, kterou se v Unixu otevφrß soubor, signalizuje operaΦnφmu systΘmu, ₧e danß ·loha (proces) chce pracovat s urΦit²m konkrΘtnφm souborem - jeho p°esnß specifikace musφ b²t p°i volßnφ operace open zadßna. V p°φpad∞, ₧e je operace open provedena nad specißlnφm souborem, kter² implementuje p°φsluÜnΘ p°enosovΘ protokoly, by analogiφ k otev°enφ skuteΦnΘho souboru m∞lo b²t navßzßnφ spojenφ na ·rovni transportnφ vrstvy, tak aby nßslednΘ operace read a write ji₧ mohly p°enßÜet "u₧iteΦnß data", a operace close zase mohla spojenφ zruÜit. To by ovÜem takΘ znamenalo zadat v okam₧iku navazovßnφ spojenφ (volßnφ operace open), s k²m mß b²t spojenφ navßzßno (mφsto specifikace souboru, kter² mß b²t otev°en). ProblΘm je ale v tom, ₧e n∞kterΘ aplikace nemusφ b²t v okam₧iku navazovßnφ spojenφ v∙bec schopny urΦit, s k²m mß b²t navßzßno (jde-li nap°φklad o proces, kter² plnφ funkci serveru, a bude teprve Φekat na to, a₧ mu n∞jak² klient zavolß). Mφsto jednΘ operace open, zajiÜ¥ujφcφ navazovßnφ spojenφ, by bylo zapot°ebφ rozliÜovat operace dv∞: tzv. pasivnφ otev°enφ, kterΘ pouze signalizuje operaΦnφmu systΘmu p°ipravenost k p°ijetφ ₧ßdosti (p°ichßzejφcφ z druhΘ strany) o navßzßnφ spojenφ, a tzv. aktivnφ otev°enφ, kterΘ spojenφ skuteΦn∞ navazuje. To vÜe by ale platilo zase jen pro spojovanΘ transportnφ slu₧by, realizovanΘ protokolem TCP, zatφmco pro nespojovanΘ transportnφ slu₧by protokolu UDP (kde se spojenφ nenavazuje v∙bec) by operace open musela fungovat jeÜt∞ jin²m zp∙sobem.

SpecifickΘ po₧adavky prßce se sφtφ by samoz°ejm∞ bylo mo₧nΘ °eÜit ·pravou stßvajφcφch operacφ typu open, read, write a close, Üit²ch na mφru prßci se soubory - nap°φklad zavedenφm dalÜφch parametr∙. Co by ale nap°φklad znamenalo pasivnφ a aktivnφ otev°enφ souboru? Musela by se p°i otevφrßnφ skuteΦnΘho souboru uvßd∞t takΘ IP adresa, kterß je doopravdy pot°ebnß jen p°i z°izovßnφ transportnφho spojenφ? Pokud by jedna a tatß₧ operace (nap°φklad open) m∞la v r∙zn²ch kontextech r∙znΘ vstupnφ parametry, zase by se tφm ztratila v²hoda jednotnΘho pohledu na vÜechna za°φzenφ jako na soubory.

Zavedenφ obecn∞jÜφch mechanism∙, kterΘ by lΘpe vyhovovaly pot°ebßm p°enosov²ch protokol∙ a umo₧nily vytvo°it dostateΦn∞ pru₧nΘ transportnφ rozhranφ, se tak brzy stalo nezbytnostφ.

Dv∞ v∞tve Unixu

Jak jsme si ji₧ uvedli ve 42. dφlu naÜeho serißlu, byly protokoly TCP/IP poprvΘ implementovßny prßv∞ pro BSD Unix, a to firmou BBN (Bolt, Beranek & Newman) na zakßzku od vlßdnφ agentury DARPA, kterß takΘ financovala v²voj protokol∙ TCP jako takov²ch. Pro BSD Unix pak byl vytvo°en nov² mechanismus na ·rovni operaΦnφho systΘmu, kter² aplikaΦnφm program∙m zprost°edkovßvß p°φstup ke komunikaΦnφm protokol∙m. Je oznaΦovßn jako socket interface (doslova: rozhranφ s objφmkami, zßsuvkami), a p°φÜt∞ se mu budeme v∞novat podrobn∞ji.

Do AT&T Unixu se protokoly TCP/IP prosadily a₧ o n∞co pozd∞ji, a pro jejich zaΦlen∞nφ do operaΦnφho systΘmu byl pou₧it jin² mechanismus, oznaΦovan² jako streams (doslova: proudy, toky). TakΘ o n∞m si povφme podrobn∞ji.