1)

1. Fyzicka vrstva (Physical Layer)
Ukol teto vrstvy je zdanlive velmi jednoduchy - zajistit prenos jednotlivych bitu mezi prijemcem a odesilatelem prostrednictvim fyzicke prenosove cesty, kterou tato vrstva bezprostredne ovlada. K tomu je ovsem treba vyresit mnoho otazek prevazne technickeho charakteru - napr. jakou urovni napeti bude reprezentovana logicka jednicka a jakou logicka nula, jak dlouho "trva" jeden bit, kolik kontaktu a jaky tvar maji mit konektory kabelu, jake signaly jsou temito kabely prenaseny, jaky je jejich vyznam, casovy prubeh apod. Problematika fyzicke vrstvy proto spada spise do pusobnosti elektroinzenyru a techniku.
 
2. Linkova vrstva (Data Link Layer)
Fyzicka vrstva poskytuje jako sve sluzby prostredky pro prenos jednotlivych bitu. Bezprostredne vyssi linkova vrstva (nekdy nazyvana tez: spojova vrstva ci vrstva datoveho spoje) pak ma za ukol zajistit pomoci techto sluzeb bezchybny prenos celych bloku dat (velikosti radove stovek bytu), oznacovanych jako ramce (frames). Jelikoz fyzicka vrstva nijak neinterpretuje jednotlive prenasene bity, je na linkove vrstve, aby spravne rozpoznala zacatek a konec ramce, i jeho jednotlive casti. 
Na prenosove ceste muze dochazet k nejruznejsim porucham a ruseni, v jejichz dusledku jsou prijaty jine hodnoty bitu, nez jake byly puvodne vyslany. Jelikoz fyzicka vrstva se nezabyva vyznamem jednotlivych bitu, rozpozna tento druh chyb az linkova vrstva. Ta kontroluje cele ramce, zda byly preneseny spravne (podle ruznych kontrolnich souctu, viz 3. dil naseho serialu). Odesilateli potvrzuje prijeti bezchybne prenesenych ramcu, zatimco v pripade poskozenych ramcu si vyzada jejich opetovne vyslani. 

3. Sitova vrstva (Network Layer)
Linkova vrstva zajistuje prenos celych ramcu, ovsem pouze mezi dvema uzly, mezi kterymi vede prime spojeni. Co ale delat, kdyz spojeni mezi prijemcem a odesilatelem neni prime, ale vede pres jeden ci vice mezilehlych uzlu? Pak musi nastoupit sitova vrstva, ktera zajisti potrebne smerovani (routing) prenasenych ramcu, oznacovanych nyni jiz jako pakety (packets). Sitova vrstva tedy zajistuje volbu vhodne trasy resp. cesty (route) pres mezilehle uzly, a take postupne predavani jednotlivych paketu po teto trase od puvodniho odesilatele az ke konecnemu prijemci. 
Sitova vrstva si tedy musi "uvedomovat" konkretni topologii site (tj. zpusob vzajemneho primeho propojeni jednotlivych uzlu). 

4. Transportni vrstva (Transport Layer)
Sitova vrstva poskytuje bezprostredne vyssi vrstve sluzby, zajistujici prenos paketu mezi libovolnymi dvema uzly site. Transportni vrstvu proto zcela odstinuje od skutecne topologie site a vytvari ji tak iluzi, ze kazdy uzel site ma prime spojeni s kterymkoli jinym uzlem site. 
Transportni vrstve diky tomu staci zabyvat se jiz jen komunikaci koncovych ucastniku (tzv. end-to-end komunikaci) - tedy komunikaci mezi puvodnim odesilatelem a konecnym prijemcem. 
Pri odesilani dat zajistuje transportni vrstva sestavovani jednotlivych paketu, do kterych rozdeluje prenasena data, a pri prijmu je zase z paketu vyjima a sklada do puvodniho tvaru. Dokaze tak zajistit prenos libovolne velkych zprav, prestoze jednotlive pakety maji omezenou velikost. 

5. Relacni vrstva (Session Layer)
Ukolem teto vrstvy je navazovani, udrzovani a ruseni relaci (sessions) mezi koncovymi ucastniky. V ramci navazovani relace si tato vrstva vyzada na transportni vrstve vytvoreni spojeni, prostrednictvim ktereho pak probiha komunikace mezi obema ucastniky relace. Pokud je treba tuto komunikaci nejak ridit (napr. urcovat, kdo ma kdy vysilat, nemohou-li to delat oba ucastnici soucasne), zajistuje to prave tato vrstva, ktera ma take na starosti vse, co je potreba k ukonceni relace a zruseni existujiciho spojeni.
 
6. Prezentacni vrstva (Presentation Layer)
Data, ktera se prostrednictvim site prenasi, mohou mit mj. povahu textu, cisel ci obecnejsich datovych struktur. Jednotlive uzlove pocitace vsak mohou pouzivat odlisnou vnitrni reprezentaci techto dat - napr. strediskove pocitace firmy IBM pouzivaji znakovy kod EBCDIC, zatimco vetsina ostatnich pracuje s kodem ASCII. Podobne jeden pocitac muze zobrazovat cela cisla v doplnkovem kodu, zatimco jiny pocitac v primem kodu apod. - potrebne konverze prenasenych dat ma na starosti prave tato prezentacni vrstva. 
V ramci teto vrstvy byva take realizovana pripadna komprese prenasenych dat, eventualne i jejich sifrovani.
 
7. Aplikacni vrstva (Application Layer)
Koncovi uzivatele vyuzivaji pocitacove site prostrednictvim nejruznejsich sitovych aplikaci - systemu elektronicke posty, prenosu souboru, vzdaleneho prihlasovani (remote login) apod. Zaclenovat vsechny tyto ruznorode aplikace primo do aplikacni vrstvy by pro jejich velkou ruznorodost nebylo rozumne. Proto se do aplikacni vrstvy zahrnuji jen casti techto aplikaci, ktere realizuji spolecne resp. obecne pouzitelne mechanismy. Uvazujme jako priklad prave elektronickou postu - ta jeji cast, ktera zajistuje vlastni predavani zprav v siti, je soucasti aplikacni vrstvy. Na vsech uzlovych pocitacich, ktere pouzivaji tentyz system elektronicke posty, je tato cast stejna. Uzivatelske rozhrani systemu elektronicke posty, tedy ta jeho cast, se kterou uzivatel bezprostredne pracuje a jejimz prostrednictvim cte dosle zpravy, odpovida na ne, pripravuje nove zpravy a zadava je k odeslani, jiz neni povazovana za soucast aplikacni vrstvy, nebot se muze v kazdem konkretnim uzlu dosti vyrazne lisit - napr. ve zpusobu sveho ovladani (radkovymi prikazy ci pomoci ruznych menu, s okenky ci bez nich apod.). Jinym nazornym prikladem muze byt emulace terminalu, potrebna napr. pro vzdalene prihlasovani (remote login). Ve svete dnes existuje nepreberne mnozstvi ruznych terminalu, a realizovat potrebne prizpusobeni mezi libovolnymi dvema typy terminalu je v podstate nemozne. Proto se zavadi jediny "referencni" terminal - tzv. virtualni terminal - a pro kazdy konkretni typ terminalu se pak vytvori jen jedine prizpusobeni mezi timto virtualnim terminalem a terminalem skutecnym. Prostredky pro praci s virtualnim terminalem pritom jsou soucasti aplikacni vrstvy (nebot jsou vsude stejne), zatimco prostredky pro jeho prizpusobeni konkretnimu terminalu jiz soucasti aplikacni vrstvy nejsou. 
2), 3), 4), 5), 6), 7), 8) - (ups01.jpg a ups02.jpg)

9) 

Pri synchronnim prenosu jsou obvykle prenaseny cele bloky znaku. Datove bity jednotlivych znaku pritom nasleduji tesne po sobe, bez jakychkoli casovych odstupu, a nejsou prokladany zadnymi start- ci stop-bity (mohou vsak byt doplneny jednim paritnim bitem). Zacatek bloku je indikovan jednim nebo nekolika specialnimi synchronizacnimi znaky (tzv. znaky SYN), jejichz hlavnim smyslem je zajistit potrebnou casovou synchronizaci odesilatele i prijemce - tzn. pomoci prijemci presne stanovit casove okamziky, ve kterych ma vyhodnocovat jednotlive datove bity. Blok znaku je pak opet zakoncen synchronizacnimi znaky, ktere mohu (ale nemusi) byt nepretrzite vysilany az do zacatku nasledujiciho datoveho bloku. 
Synchronni prenos je obecne rychlejsi nez asynchronni, nebot neni zatizen rezii pripadajici na start- a stop-bity. Jeho technicka a programova realizace vsak byva ponekud slozitejsi nez u prenosu asynchronniho. 














10), 11), 12), 13) - (ups03.jpg)


































14)























































15), 16), 17), 18) - nepocitane, ale princip a priklad na RIMG0002.jpg 

19), 20)  - RIMG0005.jpg

21) 
Princip technologie ATM
Ackoli technologie ATM vznikla ve svete spoju, je pravdou ze jeji koncepce preci jen urcitym zpusobem vybocuje z tradic sveta telekomunikaci a vychazi vstric filosofii sveta pocitacovych siti a jeho potrebam. V cem presne? 
Ve svete telekomunikaci je tradici provozovat nejruznejsi prenosy a prenosove cesty synchronnim zpusobem. Tedy tak, ze urcita prenosova kapacita se dopredu rozdeli na dilci casti (technikou oznacovanou v odborni literature jako casovy multiplex, na tzv. sloty ktere se pravidelne stridaji v case), a tyto casti dostanou pevne prirazeni, ktere se v case nemeni - jednotlive prenosy ("proudy" dat) dostanou pevne pridelenu urcitou sekvenci dilcich casti (slotu) slotu, ktere mohou vyuzit. Pokud je ale nevyuziji, tyto zustavaji nevyuzite (neni mozne je vyuzit pro potreby jinych prenosu). Je to v zasade princip, oznacovany jako "prepojovani okruhu" (circuit switching). Jeho vyhodou je schopnost garantovat konkretni objem prenosove kapacity, nevyhodou naopak neefektivni vyuziti celkove dostupne kapacity - pokud se tato statickym a nemennym zpusobem rozdeli mezi jednotlive prenosy, musi byt dimenzovana na maximum vsech pozadavku. 
ATM ale funguje na jinem principu. Ten je v telekomunikacni literature nejcasteji oznacovan jako tzv. statisticky multiplex, a je velmi blizko tomu, co se ve svete pocitacovych siti oznacuje jako prepojovani paketu (packet switching). Myslenka je takova, ze dostupna prenosova cesta bude opet rozdelena na pevne velke (fakticky spise pevne male) casti, oznacovane nyni jako bunky (cells), ale tyto jiz nebudou mit pevne prirazeni. To fakticky znamena, ze jiz nebude predem jasne, komu patri obsah te ktere bunky (drive slotu). Kvuli tomu musi kazda bunka explicitne identifikovat svuj obsah, prostrednictvim tzv. hlavicky (leader). Jeji existence samozrejme zvysuje rezii prenosu. Na druhou stranu moznost priradit bunku tomu, kdo ji prave potrebuje (a ne dopredu nekomu, kdo ji treba nevyuzije), vede na mnohem efektivnejsi vyuziti celkove dostupne prenosove kapacity, nez jake umoznuje casovy multiplex. 
Jak velke jsou ATM bunky? 
Bunky, se kterymi technologie ATM pracuje, jsou skutecne velmi male - maji pevnou velikost 53 bytu, z nichz 5 bytu tvori hlavicku a 48 bytu nabizi prostor pro "uzitecny naklad". Pokud vam techto 48 bytu pripada jako nezvykle cislo, ktere neni mocninou 2, pak nejste sami. Jedine dostupne vysvetleni teto zvlastni volby je neoficialni a rika ze jde o kompromis, ktery byl ucinen primo u kolebky ATM. Zastanci telekomunikaci, kteri stali u zrodu teto technologie, prosazovali co mozna nejmensi velikost nakladoveho prostoru, maximalne vsak 32 bytu. Argumentovali tim, ze cim mensi bude bunka, tim vice jich bude existovat a tim vetsi bude sance, ze kdyz nejaka data bude treba rychle odeslat, podari se najit nejakou volnou bunku a do ni data vlozit. Naopak zastanci datovych prenosu pozadovali vetsi rozmer bunky (alespon 64 bytu, spise ale vice). Jejich argumentem zase byla efektivnost - cim mensi bude velikost nakladoveho prostoru, tim vetsi bude rezie pripadajici na velikost nezbytne hlavicky a tim bude i mensi efektivnost prenosu. 
No a kdyz jedna strana prosazovala nejvyse 32 bytu, zatimco druha nechtela slevit pod 64, vysledkem byl obycejny kompromis: aritmeticky prumer mezi 32 a 64, neboli 48 bytu. 
Co umi ATM? 
Snad nejvyznamnejsi prednosti technologie ATM je jeji schopnost vyjit vstric ruznym pozadavkum na kvalitu sluzeb. Kazdy prenos, ktery chce vyuzit sluzeb ATM site, totiz musi nejprve vytvorit spojeni (rici kam chce sva data dopravovat), a take uzavrit cosi jako "kontrakt" s touto siti. Soucasti tohoto kontraktu pak jsou konkretni pozadavky na chovani prenosove site - treba na to, ze pro dany prenos bude garantovana urcita konkretni prenosova kapacita, nebo ze prenosove zpozdeni nebude vetsi nez nejaka konkretni hodnota, ze ztraty prenasenych dat nebudou vetsi nez urcite procento atd. Pokud je ATM sit schopna takoveto pozadavky uspokojit, kontrakt prijme a spojeni navaze (v opacnem pripade navazani spojeni odmitne). 
ATM sit tak dokaze vyjit vstric multimedialnim prenosum, napriklad prenosum ziveho obrazu ci zvuku, ktere maji velke pozadavky na pravidelnost a rychlost dorucovani, a to jak komprimovanym tak i nekomprimovanym. Stejne tak dokaze vyjit vstric i takovym prenosum, ktere maji jine pozadavky - treba klasickym datovym prenosum, ktere tolik nespechaji na sva data a nevyzaduji jejich pravidelne dorucovani, ale zase volaji po efektivnosti. Dulezite pritom je, ze ATM sit dokaze vyhovet takto ruznym pozadavkum soucasne. 
V tomto ohledu je tedy mozne chapat ATM jako technologii, ktera skutecne vychazi vstric potrebam tradicniho sveta telekomunikaci (s prenosy obrazu a zvuku), i pozadavkum sveta pocitacovych siti s jejich tradicnimi datovymi prenosy. 
Navic neni ATM sit omezena ci vazana na urcitou konkretni prenosovou rychlost. Dokonce si lze predstavit, ze sama ani zadna data fyzicky neprenasi, ale vyzaduje pod sebou vhodnou (fyzickou) prenosovou technologii, ktera zajisti prenos jednotlivych bitu - a ATM pak prostrednictvim teto technologie prenasi sve vlastni bunky. Site ATM tedy mohou pracovat ruznymi rychlostmi a nejsou nejak apriorne rychlostne omezeny. 



22), 23) - nemam neco na RIMG0004.jpg, nebo v UPS-cviceni.pdf

24) - ups03.jpg

25), 26) - nemam, vetsinou se ale resilo na cviceni

27) - RIMG0002.jpg

28) - RIMG0004.jpg

29) - nevim

30)

Pristupova metoda Ethernetu, kterou jsme si zacali popisovat v minulem dilu, vychazi z nekolika zakladnich predpokladu: prvnim z nich je existence takoveho prenosoveho media, ktere ma sdileny charakter, a nemuze tudiz slouzit vice uzlum soucasne - konkretne v tom smyslu, aby po tomto mediu mohlo vysilat svoje data vice uzlu najednou (zatimco vysilani jednoho uzlu, ktere ma vice prijemcu soucasne, je mozne a s oblibou vyuzivane). Dalsim predpokladem je skutecnost, ze soucasne vysilani vice uzlu je sice velmi nezadouci, protoze vede ke vzajemnemu "znehodnoceni" jednotlivych signalu a jimi reprezentovanych dat, ale na druhe strane nehrozi zadnym mechanickym ani elektrickym poskozenim prenosove cesty ani prijimacich a vysilacich obvodu. Pristupova metoda Ethernetu se proto nesnazi apriorne zcela vyloucit soucasne vysilani vice uzlu, oznacovane jako kolize. Samozrejme se jim snazi predchazet, a to zpusobem, ktery jsme si jiz popsali v predchozim dilu - tim, ze kazdy uzel ma povinnost nejprve poslouchat, zda prave nikdo nevysila, a sam ma pravo zacit vysilat pouze tehdy, pokud je "ticho". Dalsim dulezitym predpokladem pristupove metody Ethernetu je proto skutecnost, ze jednotlive uzly jsou vubec schopny detekovat, zda prave nekdo vysila ci nikoli. 

Co si pocit s kolizi?
Zdurazneme si nyni znovu fakt, ze pristupova metoda Ethernetu se sice snazi predchazet kolizim, ale na druhe strane se nesnazi zcela a uplne eliminovat moznost jejich vzniku. Bylo by to totiz relativne narocne a komplikovane, zatimco Ethernet sazi spise na jednoduchost a na "statisticky dobre" chovani pri mensich zatezich. Proto v prevenci kolizi jde jen urcity kus cesty (a ne az "na doraz"), ale pak radeji preci jen pripousti moznost vzniku kolizi a zameruje se na to, jak ex-post eliminovat jejich nepriznive nasledky.
 
Kdy a za jake situace tedy muze ke kolizi dojit? 
Nejcastejsim pripadem zrejme jsou situace, kdy v dobe prave probihajiciho vysilani nekolik uzlu pojme umysl take neco odvysilat. Vsechny tyto uzly vsak zjisti, ze spolecne sdilene prenosove medium je prave obsazene, a tak cekaji na jeho uvolneni. Jakmile se tak stane, zaregistruji to vsichni vicemene ve stejny okamzik (plus-minus jejich reakcni doba), a zacnou vysilat vsichni najednou, cimz zpusobi kolizi. 

Podivejme se nyni na celou situaci z pohledu jednoho zucastneneho uzlu (je jedno ktereho): tento uzel rozpozna, ze ke kolizi doslo, a z tohoto faktu si muze odvodit, ze vysilat zacaly i nektere dalsi uzly. Dulezite ovsem je, ze dany uzel nepozna, kolik takovychto uzlu bylo - zda jeden, dva, tri apod. Pozna pouze to, ze vysilat zacal alespon jeden dalsi uzel krome nej. Krome poctu ostatnich uzlu v kolizi dany uzel samozrejme nepozna ani to, ktere konkretni uzly se spolu s nim do kolize dostaly. 
Absence vzajemneho povedomi o ostatnich ucastnicich kolize brani deterministickemu (rizenemu) vyreseni teto neprijemne situace - jelikoz jednotlive uzly o sobe nevedi a vzhledem k povaze sdileneho prenosoveho media nemaji moznost se vzajemne domluvit, nemuze byt kolize resena napriklad vhodnym "rozpocitanim", tak aby z ni vzdy vzesel jeden konkretni vitez a ten mel pravo pokracovat ve vysilani. 

Bez moznosti vzajemneho dorozumeni se jednotlive uzly zucastnene v kolizi musi spolehnout na nahodu - kazdy z nich si "hodi kostkou" a doufa ze alespon nahodny faktor dokaze vybrat z jejich stredu jednoho viteze, ktery bude moci uskutecnit svuj zamer vysilat (ve skutecnosti se kazdy uzel odmlci na nahodne zvolenou dobu, a pote se snazi uplatnit svuj pozadavek na vysilani znovu). Dulezite ovsem je uvedomit si, ze ani "hod kostkou" nemusi vest k zarucenemu vysledku, protoze vice uzlum muze "padnout" stejna hodnota - mohou se odmlcet na stejnou dobu, ev. se po svem "probuzeni" znovu seradit pri cekani na konec prave probihajiciho vysilani a pak se znovu dostat do kolize. 

Mechanismus, zvoleny autory Ethernetu pro reseni jiz nastalych kolizi (tj. odmlceni se na nahodne zvolenou dobu) proto take nemusi vest ke kyzenemu vysledku, neboli neodkaze zcela eliminovat moznost naslednych (zavlecenych) kolizi. Pouze snizuje jejich pravdepodobnost. K teto snaze ostatne prispiva svym dilem i kazdy uzel, ktery se dostane do opakovane kolize - aby snizil pravdepodobnost dalsi kolize, zvetsi si na dvojnasobek interval, ze ktereho si nahodne voli dobu na kterou se odmlci. Takto postupuje kazdy uzel celkem desetkrat, a po desatem neuspesnem pokusu to vzda a ohlasi svym vyssim vrstvam neuspech. 






Omezena velikost kolizni domeny
Mechanismus vzniku kolizi, ktery jsme si popsali v predchozim odstavci, je zrejme v praxi nejcastejsi, ale neni jedinym moznym zpusobem resp. duvodem, kvuli kteremu ke kolizim muze dochazet. Dalsi moznosti, byt mene pravdepodobnou, je situace kdy dva uzly (ev. vice uzlu) ve stejny okamzik pojmou umysl zacit vysilat, oba ve stejny okamzik otestuji stav prenosoveho media, oba zjisti ze je prave volne a oba zacnou vysilat. V praxi pritom nemusi jit uplne o "jeden a tentyz okamzik", ale o maly casovy interval, dany konecnou rychlosti sireni signalu po prenosovem mediu a reakcni dobou jednotlivych uzlu. 
S konecnou rychlosti sireni signalu a nenulovou reakcni dobou konkretnich uzlu pak souvisi jeste nektere dalsi zajimave technicke aspekty kolem kolizi, ktere maji dulezite prakticke dusledky. Jde zejmena o otazku spravneho rozpoznani kolize vsemi zainteresovanymi uzly, a o presne chovani kazdeho jednotliveho uzlu v okamziku, kdy zjisti ze prave on se ocitnul ke kolizi. 
V prvnim priblizeni by se mohlo zdat nejrozumnejsi to, aby dotycny uzel okamzite prestal vysilat. Ve skutecnosti to ale udelat nesmi. Duvody souvisi prave s konecnou rychlosti sireni signalu o nenulovou reakcni dobou - pokud by jeden z uzlu, zucastnenych v kolizi, prestal vysilat okamzite pote, co on sam rozpoznal kolizi, mohlo by se stat, ze ostatni uzly by tuto kolizi jiz nedokazaly korektne rozpoznat (lze si predstavit, ze informace o vyskytu kolize by se k nim nestacila vcas dostat). Kazdy uzel, ktery zjisti ze se dostal do kolize, se proto musi zachovat zcela opacne, nez by mu radil zdravy rozum - musi jeste nejakou dobu vysilat, aby kolizi nalezite "utvrdil" (a umoznil tak ostatnim korektne ji rozpoznat).
 
Doba, po kterou musi uzel kolizi "utvrzovat", je pritom pevne dana (ve standardech Ethernetu). Z jeji pevne velikosti, konecne rychlosti sireni signalu v prenosovem mediu a velikosti zpozdeni na opakovacich pak vychazi velmi dulezite omezeni na pocet segmentu a mezi ne zapojenych opakovacu, ktere je mozne v Ethernetu pouzit. V pristich dilech se k teto otazce vratime podrobneji, nyni si pouze zdurazneme, ze tato maximalni velikost se tyka pouze oblasti, do kterych musi byt kolize sireny - a ktere jsou proto oznacovany jako tzv. kolizni domeny. Jsou to jednotlive kabelove segmenty ci skupiny kabelovych segmentu, propojene na urovni fyzicke vrstvy, neboli prostrednictvim opakovacu. Ty totiz propousti kolize, zatimco aktivni sitove prvky pracujici na vyssich urovnich (napr. mosty, switche, smerovace) jiz kolize nepropousti. Kolizni domeny tedy konci vzdy u nejblizsiho mostu, smerovace ci switche. 

Jinym zajimavym dusledkem prave popsaneho chovani uzlu (i celkoveho charakteru pristupove metody Ethernetu) je skutecnost, ze ke kolizim muze dochazet jen na zacatku vysilani jednotlivych Ethernetovych ramcu - pokud se totiz kazdy uzel chova disciplinovane a dodrzuje pravidla pristupove metody Ethernetu, nemel by "skocit do reci" jinemu uzlu v dobe, kdy tento vysila. Muze se tak stat pouze na zacatku vysilani, diky tomu ze jiny uzel otestoval stav prenosoveho media jeste v dobe, kdy nikdo nevysilal, a o neco pozdeji (diky sve nenulove reakcni dobe a diky konecne rychlosti sireni signalu) zacal vysilat take. Jakmile toto pevne dane a predem zname "nebezpecne obdobi" skonci, ma prave vysilajici uzel zaruku, ze uz mu do jeho vysilani nikdo nevstoupi, neboli ze bude moci dokoncit sve vysilani bez nebezpeci kolizi. Diky tomu staci kazdemu uzlu monitorovat pripadne kolize jen po urcitou dobu na zacatku jeho vysilani. I to prispiva k celkove jednoduchosti a pruznosti Ethernetu. 

31)
Token (opravneni, pesek) 
charakteristickym rysem Token Ringu, i vsech jemu pribuznych prenosovych technologii, je zpusob rizeni pristupu ke sdilenemu prenosovemu mediu, ke kteremu nemohou pristupovat (hlavne: vysilat po nem) vsichni najednou. V Ethernetu se tento problem resi pomoci pristupove metody CSMA/CD, ktera pripousti vznik tzv. kolizi (soubezneho vysilani) a resi je teprve nasledne, a je ze sve podstaty nedeterministicka. Naproti tomu v pripade site Token Ring je vse koncipovano jinak - pravo vysilat po sdilenem mediu ma ten, kdo je momentalnim drzitelem specialniho opravneni (opravneni vysilat). Toto opravneni muze mit prakticky libovolnou "fyzickou" podobu, resp. na jeho konkretni fyzicke podstate prilis nezalezi - nejcasteji to je specialni (a maly) blok dat. Podstatne je pouze to, aby kazdy dokazal spolehlive rozpoznat, zda je ci neni momentalnim drzitelem takovehoto opravneni, a aby toto opravneni bylo mozne predavat mezi uzly navzajem. Tedy aby toto opravneni mohlo "kolovat" mezi potencialnimi zajemci o vysilani, ne nepodobne detske hre na predavani peska - na koho pesek padne (resp. kdo ziska opravneni), ten ma pravo provest urcitou cinnost (zde: zacit vysilat).   
Token Passing (predavani opravneni, predavani peska) 
pro spravne a korektni fungovani metody "predavani peska" (token passing) je bezpodminecne nutne, aby byl definovan logicky kruh - tedy poradi, ve kterem si jednotlive uzly cyklicky (dokola) predavaji to, co pro ne reprezentuje zminene opravneni (peska, neboli token). Dulezite je, ze tento kruh je skutecne pouze logickou zalezitosti a nevynucuje si zadnou konkretni fyzickou topologii. Na principu "token passing" (predavani peska) tak mohou fungovat site s ruznymi fyzickymi topologiemi - napriklad sit Token Ring se skutecne kruhovou fyzickou topologii, nebo treba sit Token Bus, s fyzicky sbernicovou topologii. Princip "token passing" lze pritom chapat jako zaklad pristupovych metod lokalnich siti, resp. povazovat za alternativu k pristupove metode CSMA/CD, pouzivane v Ethernetu. Navic jde o alternativu s vyznamne odlisnymi vlastnostmi: zatimco CSMA/CD je nedeterministicka pristupova metoda, ktera nedokaze zarucit ze se zajemce o vysilani vubec dostane ke slovu, metody zalozene na principu token passing jsou deterministicke, a zarucit to dokazi. To se projevuje i pri vyssich zatezich site, kdy se prenosove schopnosti Ethernetu relativne zhorsuji, prave diky nedeterminismu metody CSMA/CD, zatimco celkova pruchodnost siti na principu token passing se pri rostouci zatezi nezhorsuje, a blizi se teoretickemu maximu. Dani za deterministicke chovani a lepsi pruchodnost pri vyssich zatezich je celkove vetsi slozitost metod na principu token passing. Dusledkem je pak i relativne vyssi cena konkretnich produktu.   
Active monitor 
site s pristupovymi metodami na principu token passing musi explicitne resit takove situace, jako je napriklad ztrata opravneni (token-u), nebo preruseni logickeho kruhu (vypadkem nektereho z uzlu v logickem retezci, ktery tvori logicky kruh). Stejne tak musi byt explicitne osetreny situace, kdy se nejaky novy uzel chce pridat do logickeho kruhu (napriklad kdyz je zapnut dosud nekomunikujici pocitac), nebo z tohoto kruhu naopak chce vystoupit (pocitac ma byt vypnut apod.). V pripade Ethernetu takoveto situace neni vubec nutne jakkoli explicitne osetrovat, zatimco zde ano, a to casto dosti komplikovane. Nejcasteji (napriklad u siti Token Ring) jsou prislusne spravni funkce vykonavany jednou ze stanic v siti, ktera vystupuje v roli tzv. aktivniho monitoru. Nezbytna funkcnost ale musi byt implementovana ve vsech uzlech site, tak aby roli aktivniho monitoru mohl v pripade potreby vykonavat kterykoli uzel (napriklad i v jednoclenne siti).   




Token Ring 
nejcasteji je princip token passing spojovan s jednim konkretnim druhem site, oznacovane jako Token Ring. Jde o sit s kruhovou topologii, a to jak logickou (ve smyslu predavani token-u), tak i fyzickou (jednotlive uzly jsou zapojeny fyzicky do kruhu). Koncepce teto site pochazi od firmy IBM, ktera vyvinula jeji prvni verzi jiz v roce 1969. Dalsi verze pak byly uzpusobeny potrebam propojeni siti LAN a strediskovych pocitacu IBM, ale casem se zacaly pouzivat i pro samotne budovani lokalnich siti jako takovych. Prvni konkretni produkty pro site Token Ring se objevily na trhu v roce 1985, a to pracujici s prenosovou rychlosti 4 Mbps. Od roku 1989 je pouzivana verze pracujici s prenosovou rychlosti 16 Mbps. Ve skutecnosti je ale nazev "Token Ring" neformalne pouzivan pro dva ruzne druhy siti: IBM Token Ring a IEEE 802.5.   
IBM Token Ring vs. IEEE 802.5 
Reseni vyvinute firmou IBM bylo standardizovano spolecnosti IEEE, zabyvajici se standardizaci lokalnich siti, konkretne pracovni skupinou 802.5. Od toho je pak odvozen i nazev takto vznikleho reseni: IEEE 802.5. Naproti tomu firma IBM vyrabela a vyrabi vlastni verzi site Token Ring (IBM Token Ring), ktera je standardu IEEE 802.5 opravdu velmi blizka, je s n9m plne kompatibilni, ale neni s nim zcela identicka. Rozdil je napriklad v tom, ze IBM Token Ring specifikuje konkretni topologii (do hvezdy), zatimco IEEE 802.5 zadnou fyzickou topologii explicitne nepredepisuje (ale v praxi jde temer vzdy o zapojeni do hvezdy). Dalsi rozdil je napr. v prenosovem mediu: IBM Token Ring predepisuje kroucenou dvoulinku, IEEE 802.5 nepredepisuje zadne konkretni prenosove medium.  
MSAU (MultiStation Access Unit) 
jak muze mit Token Ring fyzicky kruhovou topologii a soucasne topologii do hvezdy, jak se uvadi vyse? Je to dano tim, ze se predpoklada pouziti zarizeni fungujicich jako "rozbocovace" ci "koncentratory", presneji MSAU (MultiStation Access Unit). Uvnitr tohoto zarizeni je realizovano propojeni do kruhu, zatimco ven z tohoto zarizeni vychazi paprskovite pripojky k jednotlivym koncovym uzlum - z hlediska obvodoveho zapojeni (zapojeni kabelu) pak skutecne jde o kruhovou topologii, zatimco zpusob vedeni kabelu odpovida zapojeni do hvezdy (v jejimz stredu je prave zarizeni MSAU, schopne propojeni s dalsimi zarizenimi sveho druhu). 
Token Bus 
oznaceni dalsiho druhu site fungujici na principu Token Passing: fyzicka topologie teto site je sbernicova (stejne jako napr. u puvodniho Ethernetu), a kruhova je pouze logicka topologie (system predavani opravneni mezi jednotlivymi uzly).   
FDDI (Fiber Distributed Data Interface) 
dalsi technologie s fyzicky kruhovou topologii, vyuzivajici ke svemu fungovani princip Token passing (s prenosovou rychlosti 100 Mbps)   
Switched Token Ring 
podobne jako v pripade Ethernetu, doslo i u Token Ringu na snahy o zrychleni a zvyseni celkove propustnosti pomoci tzv. prepinani (switching-u). Konkretni reseni pro prepinany Token Ring (Switched Token Ring) se ale objevila vyrazne pozdeji nez u Ethernetu.  
Dedicated Token Ring 
dalsim vyvojovym stadiem technologie Token Ring, ktere navazuje na switchovany Token Ring, je jeho tzv. dedikovana verze. Je charakteristicka tim, ze kazdemu uzlu dava dedikovanou (tj. s nikym nesdilenou) pripojku k nejblizsimu prepinaci (switchi) Token Ringu, zatimco u nededikovane verze jsou k prislusnemu switchi pripojovana cela "kolecka" (nekolik uzlu zapojenych do kruhu).   
HSTR (High Speed Token Ring) 
snahy o dalsi vyvoj technologie Token Ring se ubiraji cestou radikalniho zvyseni prenosove rychlosti, na 100 Mbps - tedy obdobne jako v pripade puvodniho Ethernetu, jen mnohem pozdeji. Prislusny navrh ma nazev High Speed Token Ring (HSTR), a v soucasne dobe jiz existuje i aliance vyrobcu, usilujici o prosazeni tohoto stomegabitoveho Token Ringu. Podrobnejsi informace lze nalezt na adrese http://www.hstra.com.
32) - nevim

33)
Sitovy protokol, ktery zprostredkovava pristup k siti se sbernicovou topologii, jako kdyby se jednalo o sit Token Ring viz vyse.

34) - ups04.jpg

35,36)
Odborna pocitacova terminologie je dnes samostatnym svetem, ktery zije vlastnim zivotem, a ktery si sam vytvari vlastni nove terminy. Presto ale na pocatku pocitacova veda prevzala mnoho terminu z jinych disciplin, a nektere z nich dokonce obohatila merou, o jake se puvodnim oborum ani nesnilo. 
Jednim z nejvyznamnejsich "dodavatelu" bezesporu byla ta cast matematiky, ktera se honosi nazvem teorie grafu. Zde se bezne operuje pojmy jako strom, koren, list ci les, a ty se natolik zalibily lidem od pocitacu, ze je prevzali i s jejich puvodnim vyznamem. 

Jednou z oblasti informatiky, ve ktere se stromum zvlaste dobre dari, jsou i pocitacove site. Jak jsme si jiz nekolikrat naznacili, mohou mit pocitacove site topologii sbernicovou, kruhovou, hvezdicovitou, stromovitou (ci jeste obecnejsi, kterou nelze zahrnout do zadne z techto kategorii), pricemz prave stromovita struktura je v soucasne dobe velmi oblibena, diky nastupu kroucene dvoulinky, rozbocovacu (hub/u) a tzv. strukturovane kabelaze vubec. 
Kdyz jsme si v CW 41/93 vysvetlovali, co je most (anglicky: bridge), a popisovali zpusob fungovani samouciciho se (self-learning) mostu, zminili jsme se o jedne zajimave drobnosti: pro spravnou funkci tohoto druhu mostu je nezbytne nutne, aby sit mela prisne stromovitou strukturu - jinak totiz muze dojit k tomu, ze samoucici se most doslova "zblbne". 
Pripomenme si nejprve, v cem spociva podstata samostatneho uceni: most si sam odvozuje skutecnou topologii site z toho, odkud prijima bloky dat od konkretnich odesilatelu. Jestlize napriklad prijme ze smeru A (presneji: z kabeloveho segmentu A) datovy ramec od odesilatele X, pak si z toho odvodi, ze uzel X lezi prave v tomto smeru, a veskere ramce, adresovane uzlu X jako prijemci, pak bude posilat smerem A. 
Ted si ale predstavme, ze by most "zaslechl" ramec od jednoho a tehoz odesilatele ze dvou, ci dokonce z vice ruznych smeru soucasne. Co by si mel odvodit pak? 


Tato situace, ktera musi samoucici se most dokonale zmast, pritom neni zdaleka vyloucena. K tomu, aby mohla nastat, staci jedine: existence redundantnich spojeni, neboli vice jak jedne mozne cesty mezi dvema uzly site. Kdo by ale mohl zajem na tom, aby neco takoveho existovalo? 
Odpoved je velmi jednoducha - redundantni spojeni zvysuji celkovou spolehlivost site, protoze zajistuji existenci alespon jedne cesty i v pripade vypadku nektereho spoje ci prepojovaciho uzlu. Pokud bychom si pak skutecnou topologii site predstavovali jako graf, projevovala by se existence techto redundantnich spojeni v tom, ze prislusny graf by obsahoval cykly. 

Redundantni spojeni jsou nejcasteji vytvarena zcela zamerne, za ucelem zvyseni spolehlivosti ci rozlozeni zateze prenosovych cest. Nekdy ale ke vzniku redundance dochazi nechtene - ve slozitych soustavach vzajemne propojenych siti s neprehlednou topologii muze zapojenim noveho mostu snadno dojit k nepredvidanemu "zacykleni". 
Existence redundantnich spojeni je na jedne strane zadouci (zvysuji spolehlivost), ale na druhe strane znemoznuje spravne fungovani samoucicich se mostu. Jak z toho ven? 

Resenim, ktere jsme si avizovali jiz v CW 41/93, je vybavit mosty dodatecnou inteligenci, ktera jim umozni vyrovnat se i s redundantnimi spojenimi. To, co samoucicim se mostum na redundantnich spojich vadi, je prave existence cyklu v neorientovanem grafu, ktery reprezentuje skutecnou topologii site. "Inteligentni" mosty se proto potrebuji navzajem domluvit, a z cyklickeho grafu vybrat a pouzivat takovou podmnozinu, ktera jiz nebude obsahovat zadne cykly, ale bude stale jeste zajistovat existenci prenosove cesty mezi kazdymi dvema uzly, mezi kterymi existovalo spojeni i v puvodnim cyklickem grafu. V terminologii teorie grafu by se jednalo o neorientovany acyklicky podgraf, neboli o tzv. kostru (ktera je v pripade neorientovaneho grafu vzdy stromem). Odpovidajici anglicky ekvivalent, ktery se pouziva i v souvislosti s mosty, je Spanning Tree. V doslovnem prekladu jde o "strom, ktery pokryva" (nektere starsi odborne prameny tento termin p rekladaly do cestiny jako: "napnuty strom"). 

Aby jednotlive mosty dokazaly ve sve vzajemne soucinnosti takovyto "spanning tree" nalezt, potrebuji k tomu vhodny algoritmus. Tento je oznacovan jako Spanning Tree Algorithm (zkratkou STA). Puvodne byl vyvinut firmami DEC a Vitalink, pozdeji vsak byl prijat jako standard americke spolecnosti elektrotechnickych a elektronickych inzenyru (spolecnosti IEEE, v ramci jeji rady standardu IEEE 802). Soucasti tohoto standardu je mj. i protokol pro vzajemnou komun ikaci, pomoci ktere se jednotlive mosty vzajemne domlouvaji na nejvhodnejsi acyklicke topologii. Z teto vzajemne domluvy vychazi jeden most v roli tzv. korenoveho mostu (root bridge), a vsechny ostatni mosty vybiraji ze vsech svych smeru prave jeden, ktery prohlasi za "korenovy" (ve smyslu: vedouci ke korenovemu mostu). Tim vznika prisne stromovita (a tudiz acyklicka) struktura, v jejimz koreni je korenovy most. 

Cely algoritmus je navic resen tak, aby pri vypadku nektereho mostu ci spojeni dokazal vyuzit existenci redundantnich spojeni a zajistil automaticke zotaveni cele site. 

37) - RIMG0003.jpg
38), 39) - priklady na cvicenih apod.
40)

 
Verze (version) je prvni polozkou zahlavi IP-datagramu. Tato polozka dlouha 4 bity (pul bajtu) obsahuje verzi IP-protokolu. V teto kapitole hovorime o IP-protokolu verze 4, tudiz tato polozka je v nasem pripade rovna hodnote 4. 
Delka zahlavi (header length) obsahuje delku zahlavi IP-datagramu. V  pripade odchyceneho IP-datagramu na obr. 5.8 je delka zahlavi 20, ale jak je videt z hexadecimalniho vypisu z MS Network Monitoru, tak polozka delka zahlavi nabyva hodnoty 5 (nikoliv 20). Vysvetleni je proste. Delka neni uvadena v bajtech, ale v ctyrbajtech a 5x4=20. Delka zahlavi musi tak byt i v pripade pouziti volitelnych polozek nasobkem ctyr. V pripade, ze by zahlavi nevyslo na nasobek ctyr, pak se na nasobek ctyr doplni nevyznamnou vyplni. 
Maximalni delka zahlavi IP-datagramu je tedy omezena tim, ze polozka delka zahlavi ma k dispozici pouze 4 bity (11112=F16=1510). Delka zahlavi IP-datagramu je tedy maximalne 60 B (=15x4). Jelikoz povinne polozky maji 20 B, tak na volitelne polozky zbyva maximalne 40 B. 
Typ sluzby (type of service - TOS) je polozka, ktera v praxi nenasla sveho naplneni. V normach RFC-791 a RFC-1349 lze nalezt konkretni navrhy vyuziti. Zamer spocival v jistem nedostatku IP-protokolu jehoz podstatou je skutecnost, ze v Internetu neni zarucena sire prenosoveho pasma mezi ucastniky. Jisteho vylepseni se melo dosahnout prave touto polozkou, pomoci ktere je mozne oznacit nektere IP-datagramy tak, aby byly dopravovany prednostne ci aby byla zarucena rychla odezvat atp. 
Celkova delka IP-datagramu (total length) obsahuje celkovou delku IP-datagramu v bajtech. Jelikoz je tato polozka pouze dvojbajtova, tak maximalni delka IP-datagramu je 65535 bajtu. 
Identifikace IP-datagramu (identification) obsahuje identifikaci IP-datagramu, kterou do IP-datagramu vklada operacni system odesilatele. Tato polozka se spolecne s polozkami priznaky (flags) a posunuti fragmentu (fragment offset) vyuziva mechanizmem fragmentace datagramu. 
  
Do cestiny se nazvy bitu pole priznaky prekladaji v negaci (viz obr. 5.9). Je-li DF bit nastaven na 1, pak je fragmentace zakazana. Nastaveni na 0 naopak znamena, ze fragmentace je mozna. Je-li nastaven bit MF na jednicku, pak vyjadruje, ze neni poslednim fragmentem. 
Doba zivota datagramu (time to live - TTL) slouzi k zamezeni nekonecneho toulani IP-datagramu Internetem. Kazdy smerovac kladnou polozku TTL snizuje alespon o jednicku. Neni-li uz mozne hodnotu snizit, IP-datagram se zahazuje a odesilateli IP-datagramu je tato situace signalizovana protokolem ICMP. 
Jak se hodnota polozky TTL nastavuje? U prikazu ping a traceroute je ji mozne explicitne nastavit. Obecne se vsak jedna o parametr jadra operacniho systemu, pokud ji tvurci programu nenastavi explicitne). 
Protokol vyssi vrstvy (protocol) obsahuje ciselnou identifikaci protokolu vyssi vrstvy, ktery vyuziva IP-datagram ke svemu transportu. V praxi se nesetkavame s pripadem, ze by se komunikovalo primo IP-protokolem. Vzdy je pouzit protokol vyssi vrstvy (TCP nebo UDP) nebo jeden ze sluzebnich protokolu ICMP ci IGMP. Protokoly ICMP a IGMP jsou sice formalne soucasti protokolu IP, avsak chovaji se jako protokoly vyssi vrstvy, tj. v prenasenem paketu je zahlavi IP-protokolu nasledovane zahlavi protokolu ICMP (resp. IGMP). 
Kontrolni soucet z IP-zahlavi (header checksum) obsahuje kontrolni soucet, avsak pouze ze zahlavi IP-datagramu a nikoliv z datagramu celeho. Jeho vyznam je tedy omezeny. Blizsi informace o vypoctu kontrolniho souctu lze nalezt v normach RFC-1071 a RFC-1141. 
IP-adresa odesilatele a IP-adresa prijemce (source and destination adress) obsahuje ctyrbajtovou IP-adresu odesilatele a prijemce IP-datagramu. 
41)
Protokol ARP
V soustave protokolu TCP/IP je zahrnut velmi elegantni mechanismus dynamickeho budovani a udrzovani prevodnich tabulek mezi IP adresami a fyzickymi adresami, zalozeny na protokolu ARP (Address Resolution Protocol). Ten vyuziva schopnosti vsesmeroveho vysilani (tzv. broadcastingu) v nekterych sitich, ktere umoznuji adresovat datovy ramec vsem uzlum dane lokalni (resp. dilci) site soucasne - bez nutnosti znat jejich konkretni adresy. Napriklad v sitich typu Ethernet lze vyslat datovy ramec na jednu, predem znamou specialni adresu, na kterou "slysi" vsechny sitove adaptery bez ohledu na svou konkretni fyzickou adresu. Protokol ARP teto moznosti vyuziva tak, ze si jejim prostrednictvim necha najit majitele prislusne IP adresy: 
Predstavme si situaci, kdy jeden uzlovy pocitac chce zaslat nejaka data jinemu pocitaci v teze dilci siti. Zna vsak pouze jeho IP adresu, nikoli jeho fyzickou adresu. Protokol ARP prvniho pocitace proto vyuzije moznosti vsesmeroveho vysilani, a vsem uzlum dane dilci site posle zvlastni ramec resp. paket s dotazem: "Kdo ma IP adresuş....?" (viz obr. 45.1. a/). Tento ramec prijmou vsechny uzly, a vsechny take vyhodnoti paket, ktery je v nem obsazen. Pouze uzel B vsak rozpozna, ze obsahuje jemu urceny dotaz, a tak na nej odpovi zaslanim sve fyzicke adresy (opet prostrednictvim specialniho paketu, jehoz format definuje protokol ARP). Ostatni uzly pritom na puvodni dotaz neodpovidaji - viz obr. 45.1. b/. 
Nebylo by ale unosne se takovymto zpusobem ptat pri kazdem jednotlivem prenosu vzdy znovu. Kazdy uzlovy pocitac si proto sam prubezne vytvari potrebnou prevodni tabulku mezi IP adresami a fyzickymi adresami (ve vhodne vyrovnavaci pameti), a prave naznaceny mechanismus vyuziva az v pripade, kdy ji potrebuje doplnit ci aktualizovat. 
Protokol RARP
Protokol ARP umoznuje, aby kazdy hostitelsky pocitac (uzel) po svem spusteni vystacil jen se znalosti sve vlastni fyzicke adresy a sve vlastni IP adresy (kterou si obvykle precte z konfiguracniho souboru na svem pevnem disku). Na fyzicke adresy vsech ostatnich uzlu ve sve dilci siti se pak vhodne "dopta". Otazkou ovsem je, jak tomu bude v pripade bezdiskovych stanic, ktere si svou IP adresu z vlastniho pevneho disku precist nemohou. 
Po svem spusteni si kazda bezdiskova stanice musi svou vlastni IP adresu nejprve vyzadat na jinem uzlovem pocitaci, ktery vuci ni vystupuje v roli serveru IP adres. Zpusob, jakym se na nej bezdiskova stanice obraci, je analogicky vyse naznacenemu mechanismu protokolu ARP - prostrednictvim vsesmeroveho vysilani bezdiskova stanice rozesle vsem ostatnim uzlum dotaz typu: "Jaka je moje IP adresa?". Sebe sama pritom stanice identifikuje prostrednictvim fyzicke adresy, kterou ma zabudovanu ve svem sitovem adapteru - viz obrazek 45.2. a/. 
Konkretni protokol, prostrednictvim ktereho si bezdiskova stanice muze svou IP adresu vyzadat, vychazi z protokolu ARP, a je oznacovan jako RARP (Reverse Address Resolution Protocol).