Referenční model ISO/OSI - druhy služeb

Na referenčním modelu ISO/OSI se silně projevila skutečnost, že při jeho koncipování měli hlavní slovo lidé spíše "od spojů", než "od počítačů". Celý model je totiž prodchnut spojařskou mentalitou a pohledem na svět, což se projevilo například ve výhradní podpoře tzv. spojovaných služeb na úkor služeb nespojovaných, a v představě o způsobu realizace těchto služeb.

Služby, které poskytují vrstvy různých úrovní, mohou mít charakter spojovaných či nespojovaných služeb. Spojovaná služba (Connection-oriented Service) pracuje na obdobném principu, jako telefonní systém. Chcete-li s někým hovořit po telefonu, musíte nejprve vytočit jeho číslo, a on musí na vaše volání odpovědět zvednutím telefonu. Tím mezi vámi vzniká spojení, prostřednictvím kterého spolu komunikujete, a které na konci hovoru zaniká (položením sluchátka). Analogicky je tomu i v případě dvou entit na stejných úrovních, které spolu chtějí komunikovat - nejprve musí být mezi nimi navázáno spojení. Jakmile je toto spojení navázáno, chová se v jistém smyslu jako roura - vysílající do ní na jedné straně vkládá to, co si přeje odeslat, a příjemce si to na druhé straně ve stejném pořadí odebírá.

Nespojovanou službu (Connectionless Service) lze naopak přirovnat k běžné listovní poště. Ta nepočítá se zřízením spojení mezi odesilatele a příjemcem, ale místo toho považuje jednotlivé části přenášených dat (zprávy) za samostatné celky, opatřené adresou svého konečného příjemce, a doručuje je nezávisle na ostatních zprávách. Jednotlivé zprávy tedy mohou být v principu přenášeny různými cestami, takže se může i stát, že při příjmu nebude zachováno jejich správné pořadí - což se u spojované služby stát nemůže.

Spojovaný (connection-oriented) charakter mají jak telefonní sítě, tak i např. většina veřejných datových sítí a jiných telekomunikačních systémů, zatímco např. v lokálních sítích mají přenosy obvykle nespojovaný (connectionless) charakter. Původní verze referenčního modelu ISO/OSI však počítala pouze se spojovanými (connection-oriented) službami a protokoly, a zavedení nespojovaných bylo provedeno až dodatečně.

Spojované služby jsou v obecném případě výhodnější pro přenos větších objemů dat. Mají sice větší jednorázovou počáteční režii (na navázání spojení), ale na druhé straně vykazují menší režii na vlastní přenos dat. Naopak nespojované služby nemají prakticky žádnou jednorázovou režii, mají však relativně vyšší režii na vlastní přenos jednotlivých částí přenášených dat. Jsou proto naopak výhodnější pro přenos menších objemů dat (tj. kratších zpráv).

Je dobré si uvědomit, že spojovaný resp. nespojovaný charakter mohou mít služby všech vrstev od aplikační po linkovou (zatímco na úrovni fyzické vrstvy již rozlišování mezi oběma variantami ztrácí smysl). V 17. dílu našeho seriálu, ve kterém jsme se zabývali veřejnými datovými sítěmi, jsme si ukazovali příklady takovýchto služeb na úrovni síťové vrstvy - přepojování okruhů a virtuálních okruhů (které mají spojovaný charakter) a datagramové služby (která má nespojovaný charakter). V dalších pokračováních našeho seriálu si ukážeme, že služby spojovaného a nespojovaného charakteru existují mj. i na úrovni transportní vrstvy, a že např. nespojovaná transportní služba může být implementována prostřednictvím služby síťové vrstvy, která má naopak spojovaný charakter.

Kromě rozdělování služeb na spojované a nespojované je možné i jiné rozdělení - na spolehlivé a nespolehlivé.

Spolehlivá služba (Reliable Service) je taková, která nikdy neztrácí žádná data. Obvykle je tato služba realizována prostřednictvím vhodného mechanismu potvrzování (kdy příjemce potvrzuje úspěšné přijetí resp. znovu žádá o vyslání dat, které byly přijaty chybně). S tím je ovšem spojena určitá režie, která nemusí být vždy žádoucí - představme si např. přenos digitalizovaného zvuku. Zde je jistě výhodnější raději občas přijmout chybná data (tj. poněkud zkreslený zvuk), než připustit výpadky, způsobované potvrzováním resp. opakovaným přenosem chybně přijatých dat.

Proto mají své opodstatnění i nespolehlivé služby (Unreliable Services), což je ovšem poněkud zavádějící označení - je vhodné chápat je spíše jako služby, které mají vysokou míru spolehlivosti, neposkytují však stoprocentní záruku úspěšnosti přenosu. Jelikož ale nepoužívají mechanismy potvrzování (spojené s určitou režií), mohou být rychlejší než obdobné "spolehlivé" služby.

Obr. 27.2.: Služební primitiva - "prostorová" představa

Prakticky jediným možným způsobem, jak zajistit spolehlivou službu, je vhodný mechanismus potvrzování. Dělení služeb na potrvzované (confirmed) a nepotvrzované (unconfirmed) proto obvykle splývá s jejich dělením na "spolehlivé" resp. "nespolehlivé".

Jak jsme si již uvedli dříve, samotný referenční model ISO/OSI neobsahuje přesné vymezení služeb, které jednotlivé vrstvy poskytují vrstvám bezprostředně nadřízeným. Zavádí pouze dosti obecnou představu o tom, jakým způsobem by mělo být zprostředkováno využití těchto služeb na rozhraní mezi jednotlivými vrstvami - prostřednictvím čtyř druhů tzv. služebních primitiv (service primitives) - viz tabulka 27.1. Ty je možné si představit jako požadavky na provedení určitých konkrétních akcí, nebo naopak jako signalizaci určitých situací, hodných zřetele.

Tabulka 27.1.: Druhy služebních primitiv ISO/OSI modelu

Druh primitiva	Význam
Request (žádost)	Entita požaduje na službě provedení určité činnosti
Indication (indikace)	Entita má být informována o určité události
Response (Odezva)	Entita reaguje na určitou událost
Confirm (Potvrzení)	Entita je informována o výsledku vyřízení svého požadavku

Uvažujme jako příklad potvrzovanou službu, např. zřízení spojení mezi dvěma partnerskými entitami stejnolehlých vrstev - viz též obrázek 27.2. Poskytovatelem služby je entita bezprostředně nižší vrstvy, které musí žadatel o zřízení spojení předat svou žádost ve formě primitiva typu požadavek (request). Entitě, se kterou má být spojení navázáno, se požadavek projeví jako indikace (indication), která je dalším typem služebního primitiva. Jde-li o službu potvrzovanou, následuje odezva (response), která pak vyvolá potvrzení (confirmation).

Obr. 27.3.: Služební primitiva - průběh v čase

Zamysleme se ale ještě jednou nad tím, co vlastně jsou ona poněkud vágní "služební primitiva", a to z pohledu programové realizace jednotlivých služeb. Jsou služební primitiva procedury, které vyšší vrstva volá a bezprostředně nižší vrstva vykonává? V případě "požadavku" a "odezvy" je to asi představa dosti vhodná, co ale v případě "indikace" a "potvrzení", které mají příjemce upozornit na určitou skutečnost, a kterou sám nemusí vůbec očekávat? Zde již představa explicitně volané procedury selhává. Vhodnější by byla spíše představa asynchronního přerušení příjemce, což ale jen velmi málo vyhovuje dnešním vyšším programovacím jazykům a je zcela ve sporu se všemi zásadami strukturovaného programování. Z čistě spojařského pohledu na svět je to ale představa velmi přirozená - např. obyčejný telefon v důsledku "indikace" začne vesele zvonit.

---