Vyšlo v týdeníku CHIPweek č. 25/95, 18. října 1995
Vytištěno z adresy: http://www.earchiv.cz/a95/a525k130.php3

Spolehlivý a nespolehlivý přenos

Skutečnost, že při nejrůznějších přenosech dat může docházet k chybám, asi není třeba zdůrazňovat. Povídali jsme si o tom již v minulém a předminulém vydání této rubriky, kdy jsme se zabývali možnostmi rozpoznat, že k nějaké chybě vůbec došlo - konkrétně se jednalo o tzv. detekční kódy, které mají za úkol odpovědět na otázku „Jsou přenesená data poškozená, nebo nikoli?". Naznačili jsme si také, že odpověď poskytovaná detekčními kódy není nikdy absolutně spolehlivá, protože každému detekčnímu kódu může „něco uniknout". Nejlépe jsou na tom ale tzv. CRC kódy, jejichž spolehlivost se ideálnímu stavu blíží nejvíce.

Velmi zajímavou otázkou je ale to, jak má být využit verdikt, který nad přijatými daty vynese použitý detekční kód. Neboli jak se má zachovat příjemce, když zjistí že přijal poškozená data?

V prvním okamžiku asi nejspíše každého napadne, že by bylo vhodné se postarat o nápravu. Tedy oznámit odesilateli, že jím vyslaná data došla poškozená, a požádat jej o opakování přenosu. Podmínkou k tomu je samozřejmě možnost zpětné komunikace, neboli existence vhodného přenosového kanálu pro přenos od příjemce dat směrem k jejich původnímu odesilateli. Kromě některých, spíše singulárních případů (jako například komunikace pozemního střediska se vzdálenou družicí) možnost zpětné vazby většinou existuje, a tak se příjemce poškozených dat má možnost obrátit na odesilatele a vynutit si opakování přenosu. O konkrétních metodách a postupech, které přitom připadají v úvahu, si však budeme povídat až příště. Dnes se totiž zamyslíme spíše nad něčím jiným: je vůbec nutné, aby se příjemce poškozených dat staral o nápravu?

Za tímto zdánlivě paradoxním dotazem stojí dvě důležité skutečnosti, které je vhodné si uvědomit. Za prvé: počítačové sítě jsou realizovány hierarchickým způsobem, a jejich implementace je členěna na vrstvy. Kontrola nepoškozenosti přijatých dat se dělá obecně na každé vrstvě. Má se ale každá z těchto vrstev snažit o nápravu, když usoudí že k poškození došlo? A teď ten druhý aspekt: vyžádat si nápravu něco stojí - jednak to trvá určitý čas, a jednak to spotřebovává určitou přenosovou kapacitu. Navíc je dobré si znovu uvědomit, že i samotné detekční mechanismy, které mají upozornit na chybu, nejsou stoprocentně spolehlivé. Mohlo by tedy dojít například i k takové situaci, kdy by se jedna vrstva snažila vždy postarat o nápravu, byť za cenu celkového zpomalení a větší „spotřeby" přenosové kapacity, ale pro bezprostředně nadřazenou vrstvu by to nebylo dostatečné - kdyby tato vyšší vrstva měla přísnější požadavky na bezchybnost přenosu, než jaké dokáže zajistit nižší vrstva, musela by si veškerou agendu kolem jejího zajištění realizovat znovu a sama. Má pak ale vůbec cenu, aby se o zjednání nápravy snažila současně i nižší vrstva? Nebylo by výhodnější, aby nižší vrstva raději fungovala co možná nejrychleji, byť za cenu ignorování případných chyb, a o nápravu starala až ta vyšší vrstva, která bezchybovost přenosu skutečně potřebuje?

Situace, kdy určitá vrstva se chápe jako svou povinnost postarat se o nápravu případných chyb při přenosu, odpovídá tzv. spolehlivému přenosu (reliable transfer). Opačná situace, kdy daná vrstva sice detekuje případné chyby, ale při jejich výskytu nemá povinnost se postarat o nápravu, odpovídá tzv. nespolehlivému přenosu.

Pro správné pochopení rozdílu mezi oběma variantami je vhodné si zdůraznit, že ani „spolehlivý přenos" není nikdy stoprocentně spolehlivý, protože stoprocentně spolehlivé nejsou již ony detekční mechanismy, které mají za úkol chybu rozpoznat. Na druhé straně přívlastek „nespolehlivý" u nespolehlivého přenosu rozhodně neznamená, že by zde některá ze zúčastněným stran samovolně a z vlastní iniciativy ničila přenášená data - nespolehlivost je třeba chápat v tom smyslu, že příjemce se sice snaží zajistit bechybný přenos, ale když se mu to nepodaří a k nějaké chybě přeci jen dojde, nepovažuje za svou povinnost postarat se o nápravu. Poškozená data jednoduše zahodí a počítá s tím, že o nápravu se postará někdo jiný.

Názor na volbu mezi nespolehlivým a spolehlivým přenosem se dosti různí. Například ve světě TCP/IP měl od začátku navrch pragmatický přístup, založený na jednoduchosti a maximální možné rychlosti nižších přenosových vrstev. V rámci TCP/IP se proto od nižších vrstev požaduje pouze nespolehlivý přenos, s tím že spolehlivost je zajišťována až na vyšších vrstvách (a ještě jen pro takové aplikace, které ji skutečně vyžadují). Naproti tomu ve světě tzv. referenčního modelu ISO/OSI je dávána přednost tomu, aby se spolehlivost zajišťovala znovu na každé vrstvě, resp. aby se o nápravu chyby postaral již ten, kdo ji zjistí jako první.