Számítógép hálózatok. A hálózati réteg általánosan. Magasabb rétegek. Vadász Ea4 1

Átírás

1 Számítógép hálózatok A hálózati réteg általánosan. Magasabb rétegek Vadász Ea4 1 1

2 Miről lesz szó? A hálózati rétegről (általánosan) A címzések, a címterek. A funkciók A hálózatszervezés (ÖK alapú, ÖK mentesség) A forgalomirányítás követelmények, mozzanatok, módszerek A torlódásvezérlés Általánosan átnézzük a felső 4 réteget A szállítási (Transport), a viszony (Session), a megjelenítési (Presentation) és az alkalmazási (Application) réteget. Vadász Ea4 2 Alatta end-to-end: a MAC címvilágban Keretekben csak MAC forrás-cél címek. Felette valódi forrás cél címzések, de a hálózati-gép címvilágban 2

3 A hálózati réteg jellemzői A szállítási és az adatkapcsolati réteg között vagyunk A szállítási réteg valódi end-to-end bázisú: valódi forráscél "elképzelése" van, nem tud a hálózatról, annak topológiájáról Az adatkapcsolati réteg egyetlen "vonalon" (single link) keresztüli keretmozgatást végez, erről tud, ezen pl. forgalomszabályozást végez A hálózati réteg (már) forrás-cél átvitellel foglakozik, ugyanakkor (még) az "egész hálózatot" is ismeri (annak konfigurációját, jellemzőit [pl útvonalárakat ]). Ezért ez különös réteg... Vadász Ea4 3 Alatta end-to-end: a MAC címvilágban Keretekben csak MAC forrás-cél címek. Felette valódi forrás cél címzések, de a hálózati-gép címvilágban 3

4 Általánosan: A réteg feladatai jól meghatározott szolgáltatások a szállítási réteg felé, azaz a szállítási funkcionális elemtől NSAP-on át (Network Services Access Point) kapott és megcímzett adategységet (csomagot) a cím szerinti NSAP-hoz (a funkcionális társelemhez) (és sehová máshová) eljuttatni. Más szóval A csomagokat a forráscsomóponttól a célcsomópontig eljuttani a hálózaton keresztül Vadász Ea4 4 4

5 A címzések (addressing) A címzés egyfajta azonosítás, címzés kell, hogy entitásokat megkülönböztessünk, elérjünk Pl. az adatkapcsolati rétegben volt a MAC címtér a fizikai (eszköz) címek az elemei. A MAC címeket a HW gyártók biztosítják, egyediek Más címterek? Ismerjük a SAP címeket: a szolgálatok címeit Itt és most az NSAP címeket hálózati szolgálatokat azonosítanak (egy funkciót, egy "processzt"). Vadász Ea4 5 5

6 A címzések (addressing) Más címterek? Szükségünk lesz csomópontok címeire egy hálózaton (alhálózaton) belül Ez a cím a csomópontot (gazdagép vagy kapcsológép) elérhetővé teszi egy hálózaton belül. Ezek mások, mint a MAC címek. Egy csomóponton lehet két hálózati eszköz, két MAC címmel Érezzük, hogy ez a csomópont cím előbb-utóbb leképzendő MAC címmé (hisz az adatkapcsolati rétegben már az kell). Szükségünk lesz a hálózatok (alhálózatok) címeire. Ezek hálózatok, alhálózatok elérhetőségi irányának meghatározásához kellenek Hálózatot azonosítanak. Logikai hálózati címeknek is nevezik ezeket (Logical Network Address) Vadász Ea4 6 6

7 Végül A címzések (addressing) a hálózatok elérhetőségi irányainak címterei is felmerülnek. Pl. felépített virtuális áramkör azonosítók, port- csatornacímek, útvonal-címek stb. A hálózati réteg feladatát így fogalmaztuk A csomagokat a forráscsomóponttól a célcsomópontig eljuttani a hálózaton keresztül de ebbe beleérjük az esetleges hálózatközi együttműködést is! Vadász Ea4 7 7

8 A "szokásos" ábránk... NSAP Szállítási réteg Hálózati réteg Adatkapcs. réteg szegmensek csomagok keretek Transport Layer Network Layer Data Link Layer Fizikai réteg Physical Layer bitek A szegmensekben forrás és cél címek (LNA+HA), továbbá az NSAP cím. Utóbbi kijelöli a cél NSAP cimet A csomagokhoz elérhetőségi irány cím kijelölődik (itt egyszerű, de ) A keretekhez már MAC cím kell Vadász Ea4 8 8

9 Hálózatközi együttműködés is... A hálózat B hálózat Szállítási Hálózati Adatkapcs. (VA) (MAC) Szegmensek (LNA+HA) Hálózati (PA) Adatkapcs. Adatkapcs. (VA) (MAC) Szállítási Hálózati Adatkapcs. Fizikai Fizikai Fizikai Fizikai Mondjuk, virtuális áramkörön (VA) alapuló N szolgálat: az LNA+HAcím leképződik VA címmé a csomagokban. Ez útvonalat ad A kapcsolócsomópontban a VA címhez port cím (PA) is rendelődik. Ez az elérhetőségi irány cím Természetes a VA (+PA) MAC cím leképzés is Vadász Ea4 9 A címterek a hálózati rétegben HA - hoszt címek LNA - (al)hálózati címek PA - port cimek egy routerben VA - virtuális áramkör címek SAP - szolgálatok azonosítói 9

10 A hálózati réteg funkciói F N N Forgalom (útvonal) irányítás A csomag célbajuttatása. N Nyilvánvaló, ehhez ismerni kell a "topológiát", terhelésmegosztást kell elérni (alternatív utakat választani)... Torlódásvezérlés Ne legyenek a hálózat egyes részei túlterheltek Más mint a forgalomszabályozás (az csak 2 pont között szabályoz, ez a hálózatra [annak részére])! Ez is foglakozik persze pufferezéssel Hálózatközi együttműködés Heterogén hálózatok is összekapcsolhatók legyenek: internetworking Vadász Ea4 10 C 10

11 Az eddigiekből kivehető Elemi követelmények: A hálózati szolgálatoknak függetleneknek kell lenni az alhálózati technikáktól! A szállítási rétegtől elrejtendő az alhálózatok száma, típusa, a topológia! A szállítási réteg számára ismert (hozzáférhető) hálózati+hoszt címeknek egységes rendszert kell alkotniuk! Vadász Ea

12 A nyújtott szolgálattípusok Összeköttetés alapú szolgálat (Virtuális áramkör, Circuit Switching) Összeköttetésmentes szolgálat Üzenetkapcsolásos (Message Switching) F F N VC N N N M2 N C C Csomagkapcsolásos (Packet Switching) Datagram Packet Switching F M1 N N P2 N C P1 N Virtual Circuit Packet Switching VC#2:P3, P4 F N N C VC#1:P1, P2 N Vadász Ea4 12 Ezekből a csomagkapcsolás lesz a lényeges. Az IP ilyen. 12

13 Megjegyzés Az összeköttetés alapú és összeköttetésmentes szolgálattípusok nemcsak itt jelennek meg a felsőbb rétegekben is lehetnek ilyenek, az adatkapcsolati rétegben is lehetnek és lehetséges a "váltás"! Pl. Modemes kapcsolt vonalon (összeköttetés a fizikai rétegben) összeköttetésmentes adatkapcsolati protokollon virtuális áramkör alapú (összekötettéses) hálózati protokoll és "fordítva" A hálózati rétegben nagyobb a jelentősége az ÖK alapú-ök mentes filozófiának, mint az adatkapcsolatiban volt! A hálózati rétegben a választásra nagyobb hatással van a szállítási rétegbeli filozófiának, mint az adatkapcsolati rétegbeliének! Vadász Ea

14 A lényeges szolgálattípusok Az összeköttetés alapú (VC) szervezés. Előnyei dedikált átviteli csatorna alakul ki, garantált átviteli sebességgel; Az áramkör kialakítása után elvileg nincs csatornahozzáférési késleltetés. és a datagram csomagkapcsolásos (összeköttetésmentes). Előnyei Jobban kihasználható media; A nem dedikált csatornák lehetnek olcsóbbak; Kis forgalom esetén nincs fölösleges út lefoglalás... Vadász Ea

15 A virtuális áramkörön alapuló alhálózat-szervezés A hívásfelépítés során a forrás és célállomás között virtuális áramkör (Virtual Circuit) alakul ki. Ebből: Forgalomirányítás a hívásfelépítéskor történik! A kommunikáció során a csomagok ugyanazon az úton (a nyitott VC-n) haladnak mindkét irányban. A kommunikáció befejezése után a VC-t fel kell szabadítani! Az egyes csatornákon több VC építhető. Számuk maximált. Vadász Ea4 15 VC alapú 15

16 A címzés jellegzetessége Összeköttetéses (VC alapú) szervezés esetén a teljes forrás - cél címre csak a hívásfelépítés során van szükség! A kommunikáció során már elegendő a virtuális áramkör jelzése! Vadász Ea4 16 VC alapú 16

17 A forgalomirányítás forgatókönyve A hivásfelépítéskor a csomópont kiválasztja a megfelelő irányú csatornát és azon virtuális áramkört foglal le (általában a legkisebb szabad sorszámút) Ha nincs szabad áramkör, másik útvonalat választ. Ha ez sincs, a hivásfelépítés sikertelen. Minden csomópontban épül táblázat, a nyitott VC-t rögzítendő: melyik vonal melyik áramkörre kapcsolódik) Mindez ismétlődik az útvonalat érintő valamennyi csomópontra... Vadász Ea4 17 VC alapú 17

18 Egy példa A B C C VC#0 A B C D E C VC#0 E D C E D Van 5 csomópont: A, B, C, D, E Az egyes csomópontokban a vonalak (csatornák) címe (a portcím) egyszerűen a szomszéd neve Induláskor már létezzen B-C-D között egy virtuális áramkör. Egy vonalom max 2 VC alakítható ki Feladat: A és D között két VC igény... Vadász Ea4 18 VC alapú 18

19 Az első VC A-ból D-be A B C C VC#0 VC#0 A B C D E C VC#1 VC#0 E D C E D A táblák a csomópontokon A B C D E 0C 0B 0D 0C 0C 0A 1D 1C VC alapú hívásfelépítés 1 Vadász Ea

20 A másik VC A-ból D-be A B C C VC#0 VC#1 VC#0 A B C D E VC#0 C VC#1 VC#0 E D VC#0 C E D A táblák a csomópontokon A B C D E 0C 0B 0D 0C 0C 0A 1D 1C 1C 1A 0E 0E 0C 0D Vadász Ea4 20 VC alapú hívásfelépítés 2 20

21 A kommunikáció C szempontjából A B C C VC#0 VC#1 VC#0 A B C D E VC#0 C 0B 0D 0A 1D 1A 0E VC#1 VC#0 C E VC alapú kommunikáció D VC#0 C E D C az A-tól VC#0 csomagot kap: a táblázata 2. sora szerint VC#1re módosítja és küldi a D-nek C az A-tól #1 jelzésű csomagot kap: a 3. sora szerint intézkedik, #0-val küldi E-nek C a D-től #0-val csomagot kap: 1. sora szerint #0-val B-nek küldi C a D-től #1-gyel kap: #0A a továbbítás... Vadász Ea

22 VC alapú kommunikáció Végül a lebontás: a táblabejegyzések törlése. Lehetne más technika? Persze! Pl. Nincsenek táblák a csomópontokon (de portcímek vannak!) Hivásfelépítéskor a forrás összegyűjti az útvonal portcímeit, ésezt elhelyezi minden csomag címében pl VC#0 A-tól D-ig: A-C-D VC#1 A-tól D-ig: A-C-E-D A router ebből a címből minden csomagnál különösebb döntés nélkül tudja, melyik portjára kell továbbítani egy bejött csomagot Vadász Ea4 22 VC alapú 22

23 Datagram alapú alhálózat szervezés Minden csomag teljes forrás-célcímet tartalmaz A cím = (hálózat + hosztcím) + NSAP cím Az egyes csomagok egymástól függetlenül haladnak, minden csomagra külön-külön van útvonalirányítás! Vadász Ea4 23 Datagram alapú 23

24 A két szervezés összehasonlítása Áramkör létesítés Címzés Állapotinformáció Foorgalomirányítás Torlódásvezérlés Csomóponti hibák hatása Összetettség Szükséges Minden csomag rövid VC címet tartalmaz Minden nyitott VC bejegyzést igényel az érintett csomóponton Csak áramkör felépítéskor Könnyű (ismert számú VCre lehet előre puffert foglalni) A csomóponton átmenő VC megszakad A hálózati rétegben Nem lehetséges Minden csomag teljes címet tartalmaz Az alhálózat állapotmentes Minden csomagra újból Nehéz Nincs, legfeljebb egyes csomópontokra A szállítási rétegben Tipikus alkalmazás ÖK alapú szolgálatra Vadász Ea4 24 ÖK mentes szolgálatra 24

25 A hálózati réteg funkciói Forgalom (útvonal) irányítás A csomag célbajuttatása. Nyilvánvaló, ehhez ismerni kell a "topológiát", terhelésmegosztást kell elérni (alternatív utakat választani)... Torlódásvezérlés Ne legyenek a hálózat egyes részei túlterheltek Más mint a forgalomszabályozás (az csak 2 pont között szabályoz, ez a hálózatra [annak részére])! Ez is foglakozik persze pufferezéssel Hálózatközi együttműködés Heterogén hálózatok is összekapcsolhatók legyenek: internetworking Vadász Ea

26 A forgalomirányítás A útvonalválsztó algoritmus (routing alg.) dönti el, hogy a beérkező csomagot melyik kimenő vonalra kell továbbítani datagram hálózatoknál csomagonként, VA hálózatoknál csak a hívásfelépítés során (VC létrehozás során). Routing refers to the process of choosing a path, which often involves multiple hops, over which to send packets from a source machine to a destination machine across multiple physical networks. Router refers to a computer making such a decision. Vadász Ea4 26 Forgalomirányítás 26

27 Követelmények, tervezési szempontok Egyszerűség, megbízhatóság Helyesség (1 példányban, a megadott címre ) Robosztusság: meghibásodás esetén is maradjon működőképes (legalább valamilyen mértékben) Adaptivitás. Adaptív, ha képes önállóan felépülni és alkalmazkodni a körülményekhez Stabilitás: indulástól véges idő alatt stabil állapotba kerüljön Optimálás: költség, késletetés, min. ugrásszám szempontok lehetnek... Vadász Ea4 27 Forgalomirányítás 27

28 Az útvonalválsztás "mozzanatai" Információgyűjtés. Kellenek információk a döntésekhez. Pl. táblázatokat kell létrehozni, melyekben cél címekhez továbbítási irány címeket rendelünk Döntések. Ezeket a (router) csomópontok "hozzák", hogy merre továbbítsák a vett csomagot Vadász Ea4 28 Forgalomirányítás 28

29 Egy modern útvonalirányító Funkcionális részei, feladatmegosztás CPU, ami kezeli Routing protokollt (RIP, OSPF) Ez szolgálati protokoll, routing tábla előallításhoz Egyéb protokollokat Forwarding engine Routing table Lookup Blocking/non-blocking Input interfaces Link Layer kezelése Esetleges input puffer Otput interfaces Pufferek (Queueing) Scheduling Link Layer kezelés Vadász Ea4 29 I/O interfészekből több van 29

30 Is it Difficult? Dealing with multiple physical network connections (multi-homed hosts), single connections are straightforward. Selecting the best path in view of: network load (congestion, delay, throughput) datagram length (fragmentation and assembly) type of service (specified in the datagram header) connectivity changes (updates and temporal changes). connectionless protocol (datagram) vs connection oriented (virtual circuit). fairness Vadász Ea

31 Hierarchia a címzésekben Valamennyi célcím-irány pár táblázatba rendelése esetén túl nagy táblázatok alakulnának ki (és túl sok szolgálati kommunikáció kellene), legalább is nagy hálózatoknál Megoldás: hierarchiát alakítunk ki: a teljes hálózatot alhálózatokra, ezeket al-alhálózatokre stb. bontjuk Az alhálózatokra bontás szempontjai többfélék lehetnek. Pl: földrajzi elhelyezkedés; funkcionális összetartozás (pl. közös cél); fizikai közeghatárok, adatkapcsolati protokollok szerinti... Vadász Ea4 31 Forgalomirányítás 31

32 Hierarchia a címzésekben Ekkor a címzés: Hálózat cím + alhálózat cím + hoszt cím alakú. Ekkor a csomóponti táblázatokban elegendő alhálózat cím elérhetőségi iránya és saját alhálózaton belüli cél cím elérhetőségi iránya bejegyzéseket írni! Lássuk be, hogy ez sokkal kevesebb bejegyzést eredményez! Vadász Ea4 32 Forgalomirányítás Elérhetőségi irány: a portcím 32

33 Forgalomirányítási döntési módszerek Néhánnyal foglakozunk: Egyutas, többutas, táblázat nélküli módszerek, adaptív centralizált, adaptív elszigetelt, fordított tanulás (Ez az osztályozás nem tiszta szempontú! Pl adaptív elszigetelt módszerek a táblázatnélküli módszerek, és a fordított tanulás módszerek ) Vadász Ea4 33 Forgalomirányítás 33

34 Egyutas forgalomirányítás Minden címhez (akár hálózati, akár hoszt cím) egy továbbítási irány rögzített Előnye: egyszerű. Csak akkor optimális, ha a tárolt irány optimális. Hátránya: nem robosztus (nem hibatűrő). Forgalomirányítás, döntés Vadász Ea

35 Többutas forgalomirányítás Minden címhez több, súlyozott továbbítási irány rögzített. Ezek közül súlyozott sorsolással választunk. Pl. B egy táblabejegyzése a következő cím A: 0,75; C: 0,2; D: 0,05 Az irányok választásának szempontjai (sorsolási súlyok): előre megadott (fix) súlyok; a prioritás (a csomagok prioritás adja meg); a kommunikációtípus (a forgalmi osztály adja meg, pl gyors választ igényel, v. nagy sávszélességet igényel stb.) A B C D E Forgalomirányítás, döntés Vadász Ea

36 Előnyei több szempont is figyelembevehető; robosztus; adaptív. Hátrány Többutas forgalomirányítás Bonyolult. Több feldolgozást igényel. Forgalomirányítás, döntés Vadász Ea

37 Táblázat nélküli módszerek A "forró krumpli" módszer Amerre a legrövidebb a sor, arra továbbítjuk a csomagot (minél korábban "megszabadulni" a csomagtól) Előnye: Nem kell információt gyűjteni! Egyszerű. Robosztus. Hátránya: rossz vonali kihasználtság. A késleltetési idő nem korlátos. Forgalomirányítás, döntés Vadász Ea

38 Táblázat nélküli módszerek Az "elárasztásos" (flooding) módszer Minden csomagot minden irányba - kivéve, ahonnan jött - továbbítunk. Előnye: Nem kell információt gyűjteni! Egyszerű. Robosztus. Hátránya: Nagyszámú többszörözött csomagot eredményez. Ezt "fékezni" lehet: Ugrásszámlálással. Csomag fejben számlálómező, melyet minden csomópont inkrementál. Egy bizonyos ugrásszám (ez a hálózat "átmérője") után a csomópontok eldobják a csomagot (hálózatátmérőig történő elárasztás). Csomagok sorszámozásával. Az adó sorszámozza a csomagokat. Ha egy csomópont ugyanattól a feladótól ugyanolyan szorszámú csomagot kap, mint amilyet már korábban kapott (és az időzítés nem járt le), akkor eldobja... (mégis van információgyűjtés ) Forgalomirányítás, döntés Vadász Ea

39 Adaptív centralizált forgalomirányítás Működése: (Nagykapacitású) központ begyűjti az összes információt a csomópontokról (topológia, forgalmi irányok, terhelések ) Ebből kiszámítja az optimális utakat és letölti azokat a csomópontok tábláiba. Előnye: adaptív és optimális. Hátrányai: Sebezhető. A központ hibáira védetlen. Hiba esetén elvesztheti az adaptivitását, optimalitását. Túlterhelődnek a központ felé vezető utak (az informciógyűjtés és a letöltés is forgalom ). Általában nagy a szolgálati forgalom. Esetenként instabil lehet: késleltetések lehetnek... Vadász Ea4 39 Forgalomirányítás 39

40 Adaptív elszigetelt módszerek Ilyenek a táblázatnélküli módszerek és a "fordított tanulás" (backward learning) módszer Backward learning Minden csomag (fejében) ugrásszámláló, amit a csomópontok inkrementálnak Kezdetben "senki nem tud semmit" Ekkor "elárasztás" történik Forgalomirányítás Vadász Ea

41 A fordított tanulás Ha egy állomás valamely vonalán csomagot kap j ugrásszámlálóval, akkor tudja, hogy a feladó című állomás legfeljebb j lépés távolságban van A vett adatokat a táblázatában gyűjti, "tanul" meghatározza, hogy melyik állomás melyik irányban érhető el a legkevesebb ugrásszámmal Időnként "felejtenie kell" a régi bejegyzéseket (hogy alkalmazkodhasson a változásokhoz) Előnyei: nem igényel szolgálati kommunikációt. Adaptív, robosztus. Hátrányok: A "kezdeti elárasztás" fölösleges kommunikáció. Sámításigényes. Csak ugrásszám optimumot biztosít (mást nem). Forgalomirányítás Vadász Ea

42 A fordított tanulás alesete Szelektív elárasztás A topológia ismeretében előre hoz forgalomirányítási döntéseket (nagyjából) és e szerint áraszt el Előny: robosztus, egyszerű. Optimális késleltetést eredményezhet. Hátrány: rosz vonalkihasználás lehet... Forgalomirányítás Vadász Ea

43 Csomagszórásos forgalomirányítás Csomópont valamennyi (sok) állomásnak küldi (ugyanazt) a csomagot. Ez a "broadcasting". Némely alkalamazásban ez amúgy is elengedhetetlen! Pl. osztott AB frissítése egy ütemezési felhívás Ennek lehetséges implementációi: Mindenkinek külön csomag. Hát ez elég gyenge: listát kellene vezetni a broadcasting-ban résztvevőkről Gyenge sávszélességkihasználás jön ki Ez nem is broadcasting igazán Az ún. többcélcsomópontos forgalomirányítás (multidestination routing). Ez jobb... Forgalomirányítás, különlegesség Vadász Ea

44 Multi-Destination Routing A csomagban benne az összes célcím (lista v. bittérkép formában) Egy csomópont vizsgálja az "összes célcím" struktúrát (pl a listát), hogy meghatározza a kimenő vonala(ka)t. Tegyük föl, talált valamennyi kimenő vonalat. Minden vonalra készít új csomagot, benne új "összes célcím" struktúrát (pl listát) és küldi ezt a vonalra... Forgalomirányítás, különlegesség Vadász Ea

45 Feszítőfát alkalmazó megoldások Feszítőfa (spanning tree): a (al)hálózat olyan alhalmaza, mely hurkot nem tartalmaz, de az összes csomópontot magába foglalja Nyelőfa (sink tree): azon optimális utak halmaza, melt az összes forrásból egy adott célba vezetnek. A csomópontok ismerik a forrás egy feszítőfáját (pl a nyelőfáját), és egy csomópont a feszítőfa vonalaira másolja a csomagot (kivéve azt a vonalat, amiről az érkezett Forgalomirányítás, különlegesség Vadász Ea

46 Információgyűjtési módszerek Már említettünk ilyeneket az eddigiekben is Most összefoglalunk Beszélünk statikus és dinamikus információgyűjtésről.. Statikus (információgyűjtésű) forgalomirányítás A hálózat üzemeltője (menedzsere) tölti ki a csomópontok táblázatait A "input" számára a topológia és egyéb szempontok (költség, késleltetés, legrövidebb út stb.) Nagy tapasztalat kell hozzá... Forgalomirányítás Vadász Ea

47 Dinamikus információgyűjtésű Elosztott forgalomirányításhoz A szomszédok időnként "átadják" egymásnak "tudásukat" a hálózatról: táblázataikat, amik tartalmazzák az egyes célok elérési irányait + az illető cél "távolságát" (ugrásszám, elérési idő becsült érték stb.). A táblát kapó hozzáadja a távolságértékhez a táblát küldő (becsült) távolságát, igazítja az irányt, ebből kiszűri az optimumot ezzel frissíti a saját táblázatát. Előny: adaptiv, robosztus, közel lehet az optimumhoz Hátrány: szolgálati kommunkikáció-igényű + számításigényű Forgalomirányítás Vadász Ea

48 Példa A-t vizsgáljuk, aki B-től és C-től kap táblákat... B 4 1 A D 2 4 C B táblája A A:1 C A:3 D D:4 C táblája A A:2 B A:3 D D:4 A "módosíja" a kapott táblákat: A kiválasztja a legjobbakat: Módosított B B:1 C B:4 D B:5 Módosított CC:2 B C:5 D C:6 A a legjobbakból új táblát készít: (És ez nem függ a régitől!) A táblája B B:1 C C:2 D B:5 Vadász Ea

49 Methods to Build Routing Tables Two main methods to build routing tables are discussed later: Shortest Path: weighs each path usually in terms of time (mean queueing and transmission delay obtained by hourly or daily test runs), geographical distance, bandwidth, average traffic, comms cost, mean queue length, measured delay, etc., or as a function of these. Vector Distance: weighs each path in terms of the number of hops. Vadász Ea

50 Áttérünk a torlódásvezérlésre Eddig forgalomirányítás volt elég általános, megismertünk néhány kifejezést tudjuk, kell az információgyűjtés, és a döntések Most új hálózati rétegbeli funkcióval foglakozunk, ez a torlódásvezérlés. Ismételjük: az LLC-ben forgalomszabályozás volt (két pont közötti probléma), itt torlódásvezérlés Annyi hasonlatosság van, hogy mindkettőben a pufferezés a kulcskérdés, a pufferkapacitások végessége a gond... Vadász Ea

51 A torlódásvezérlés célja Megelőzze és/vagy elhárítsa azokat a szituációkat, melyekben egy összeköttetés vagy egy csomópont túlterheltté válik Nézzük ezt egy ábrán! Kézbesített csomagok száma Optimális eset: pufferes csomópontok Korlát: a hálózat véges kapacitása Valós eset: véges pufferes csomópontok Bedugulás (csomagvesztés), aminek oka már nem a hálózati kapacitás, hanem a pufferek korlátai Elküldött csomagok száma Vadász Ea

52 Torlódásvezérlő algoritmusok Pufferek előrefoglalása Csomageldobás (különböző eldobási szempontokkal) Lefojtócsomagok módszere Izaritmikus torlódásvezérlés Forgalomszabályozásos torlódásvezérlés Vadász Ea

53 Pufferek előrefoglalása VC alapú hálózatokban a hívásfelépítés során a VC-khez mindjárt puffereket is rendelünk: a hívásfelépítő csomag nemcsak táblabejegyzéseket generál, hanem puffereket is foglal Ha nincs elegendő puffer, nem épül fel az áramkör (esetleg más utat keres, végső soron elutasítódik) Mekkora puffereket? Pl. az adóablak méretnek megfelelőt! Ez biztosan elég! Pl. megáll-és-vár esetén elegendő 1 puffer: az ack ui nemcsak "helyességet" igazol, hanem puffer ürülést is! Hátrány: A "biztosan elég" nem gazdaságos. Fölös pufferkapacitást foglal (és elutasíthatnak emiatt más hívásfelépítést). Javítás: sokáig tétlen puffereket felszabadítják (Kockázatos!) Vadász Ea

54 Csomageldobás Nem foglanak előre puffereket, de van minden vonalra valamekkora Ha egy csomóponthoz csomag érkezik és azt képtelen pufferelni, akkor eldobja FCFS pufferhasználat ez.. Előbb-utóbb letelik az időzítés, majd újraadják Meggondolás: bármit eldobni? Ack-t, szolgálati csomagot? Erre két módosítási elgondolás javasolható, 2 szempont... Torlódásvezérlés Csomageldobás Vadász Ea

55 Csomageldobási szempontok Egyik: a bemenetekre legalább egy puffert (foglalunk és) hagyunk szabadon (hogy ne váljon "süketté" a protokoll) Ha szolgálati csomag jön: puffereli és feldolgozza.. Ha egyéb csomag jön (és nincs puffer): eldobja A másik a kimeneti vonalak közötti pufferfelosztás korlátozása: korlátozzuk a kimenő vonalak puffer-sorok hosszait maximális hossz és minimális hossz előírásokkal. A min hossz fix, a "kiéhezés" ellen, a max hossz a forgalom függvénye lehet, változhat. Torlódásvezérlés Csomageldobás Vadász Ea

56 "Ökölszabály" Heurisztikus gyakorlat ahol m = p: a pufferek össz száma; k k: a kimenetek száma; m: a max hossz egy kimenetre. És ezt "módosítják" a terheléstől függően. Lökésszerű terheléseknél ez persze elég reménytelen p Torlódásvezérlés Csomageldobás Vadász Ea

57 Csomageldobási szempont 3 A harmadik: eldobási szempontokat alakítanak ki Mielőtt egy puffersor betelik, adott küszöbértéknél a kimenetekre is Pl. prioritási osztályok befolyásolhatnak vagy az ugrások számát nézik, és azt dobják el, amelyik "kevesebbet" utazott (kisebb erőforrásigényű ennek megismétlése a mögöttes gondolat) Torlódásvezérlés Csomageldobás Vadász Ea

58 Lefojtócsomagok módszere Choke packets A forrásokat kell lefojtani, még mielőtt a torlódás beállna Csomópont figyeli a kimenő vonalak "telítettségét", és ha az egy küszöbértéket elér, fojtócsomagot küld a feladónak (ebbe az irányba csökkentsék a forgalmat jelentéssel), de az eredeti csomagot továbbítja Az eredeti csomagot meg is jelölheti "ez a csomag nálam már váltott ki fojtóüzenetet" (ti, többiek, ne féljetek tovább) Torlódásvezérlés Lefojtás Vadász Ea

59 A küldő Lefojtócsomagok módszere az első lefojtó csomag vétele után csökkenti a forgalmát, majd egy időzítésig nem fogad újabb fojtást (duplikált fojtások lehetnek). Ennek leteltével újabb időzítés: ha ezalatt újabb fojtócsomag jön, tovább lassít, ha nem, visszaállítás az eredeti sebességre Torlódásvezérlés Lefojtás Vadász Ea

60 Izaritmikus torlódásvezérlés Az elgondolás: korlátozzuk a hálózaton egyidejűleg bentlévő csomagszámot maximális csomagszám a hálózatra De hogy? Legyenek a hálózaton ún. engedélyező csomagok (permit packets). (Kezdetben annyi permit, amennyi a maxcsomagszám. Most ne firtassuk, hogy "keletkeznek"). Ezek "körbejárnak" a hálózaton Ha forrás-hoszt küldeni akar, előbb permit-et kell birtokolnia (pl. kapnia), azt megsemmesítenie, és utána küldheti a csomagját... Torlódásvezérlés Izaritmikus Vadász Ea

61 Izaritmikus torlódásvezérlés A cél-hoszt mikor megkapta a csomagját leveszi a hálózatról, azt feldolgozhatja, és utána generál és "körbeküld" helyette permit csomagot Módosítás: van "engedélyező" központ, attól kell kérni permit-et. A hátrány nyilvánvaló, ez szolgálati overhead-del jár (bár nem naggyal), és érzékeny a központ kiesésére. További gondja: ha permit csomagok "megsemmisülnek"? Nehezen menedzselhetők (számbavétel, pótlás), kivéve az engedélyező központos megoldást. Torlódásvezérlés Izaritmikus Vadász Ea

62 Forgalomszabályozásos torlódásvezérlés Mégegyszer, forgalomszabályozás: adó ne árasszon el vevőt (2 entitás viszonyára) A szállítási réteg valódi forás-cél réteg: ott értelmezhető a forgalomszabályozás a vég-vég viszonyban lévő entitások "feldolgozási kapacitásait" (ezek különbségét) kell figyelembe venni. Ha a szállítási (vagy felsőbb) forgalomszabályozást nem az ottani kapacitásoktól függően alkalmazzák, hanem szigorúbb korlátozásokat (is) figyelembe vesznek, az (al)hálózat (talán) nem válik túlterheltté! Ez a forrásra is telepíthető! Közvetlenül a kibocsájtásnál érvényesíthető... Torlódásvezérlés Forgalomszabályozásos Vadász Ea

63 Beláthatjuk, Forgalomszabályozásos torlódásvezérlés ha a "korlát" jó, nem lesz torlódás; ha kicsit "lazább": egyenletes terhelésnél jó lesz, lökéses terheléseknél egyes pontokon kialakulhat torlódás. Nem tervezhetünk a "csúcsra", ez még el kell menjen! Remélem "érzik", értik, miről van szó... Torlódásvezérlés Forgalomszabályozásos Vadász Ea

64 A hálózati rétegről Miről volt szó? felette, alatta end-to-end bázis, itt az egész hálózat látszik A címzések, a címterek. A funkciók A hálózatszervezés (ÖK alapú, ÖK mentesség) A forgalomirányítás követelmények, mozzanatok, módszerek A torlódásvezérlés 5 algoritmus ebben Vadász Ea

65 A további program Általánosan átnézzük a felső 4 réteget A szállítási (Transport), a viszony (Session), a megjelenítési (Presentation) és az alkalmazási (Application) réteget. Vadász Ea

66 A szállítási réteg TSAP TSAP Viszonyréteg Viszonyréteg 4. Szállítási réteg Szállítási entitás Szállítási protokoll TPDU Szállítási entitás 4. Szállítási réteg NSAP NSAP Hálózatiréteg Hálózatiréteg TSAP: Transport Service Access Point TPDU: Transport Protocol Data Unit A 4. réteg, a hálózati- és a viszonyréteg között Vadász Ea

67 A szállítási réteg Feladata Interfész alulra, fölülre Megbízható, gazdaságos adatszállítást forrástól célhosztig, függetlenül a hálózatoktól (a céltól, forrástól, a közbenső alhálózatoktól), ÖK vagy ÖK mentes alapon Tudjuk, hogy valódi end-to-end szolgáltató entitások vannak Miért kell? Az interfész - ha nem lenne, nem kellene e szerep Megbízhatóság - ezt az adatkapcsolati és a fizikai réteg biztosíthatná ÖK alapú és ÖK mentes szolgáltatási jelleg - ezt is biztosíthatják az alsóbb rétegek Vég-vég - ezt a hálózati r. biztosíthatná Vadász Ea

68 A szállítási réteg Miért kell? Demagóg válasz A jó válasz inditékai A szállítási réteg a hálózati fölött operál Tudjuk, a hálózati réteg lehet ÖK alapú és ÖK mentes, és lehet megbízhatatlan! (Az IP ÖK mentes és megbízhatatlan) Még megbízható hálózati réteg mellet is lehet összeomlás Azt gondolnánk: tegyük megbízhatóbbá, és meg van oldva. De: a hálózati (és alsóbb) rétegekre kicsi a hatásunk A hidakat, router-eket (sokszor) nem mi üzemeltejük Az alsóbb rétegek kártyákban, csipekben, esetleg OS-ben implementáltak, nem "változtahatjuk" könnyen... Vadász Ea4 68 Demagóg válasz: csak! Az ARPANET korában a viszony és megjeleítési réteg "üres" volt. Sokan panaszolták is. Ha még a transzport réteg is üres lenne?... 68

69 A jó válasz A szállítási réteg Legyen a hálózati réteg fölött a szállítási, ami valóban megbízható forrás-cél szolgálatokat biztosít, és ekkor fejleszthetünk alkalmazásokat, melyek szabványos interfészeken keresztül különböző hálózatokon (megbízható és megbízhatatlan is) is jól működnek, kliensszerver alapon szolgáltatnak. Ez az érv olyan erős, hogy tervezési szempontból a szállítási réteg lett a legfontosabb. Megjegyzés a szabványosodásról Vadász Ea4 69 Megbízható - nem megbízható: kérésre megerősítés (nyugta, ack) is, nemcsak bejelentés A megjegyzés: Az alsóbb rétegek feladatai szinte e réteg céljainak elérését biztosítani. Az alsóbb rétegek egész jól standardizálódtak. A szállítási és felsőbb rétegekben erősebb a szabványosítási munka. 69

70 A szállítási réteg Fontos cél a szállítási rétegben hibamentes átvitel akár hibákkal terhelt hálózati réteg fölött is! Ebből következik: a a fölöttes rétegeknek tényleg nem kell emiatt nyugtázással stb. foglakozni! (PL. ha egy hálózati összeköttetés megszakad, akkor a szállítási réteg nyit egy újat és ott folytatja, ahol a régivel abbahagyta.. A fölöttes réteg észre sem veszi ezt.) Fontos célja még elrejteni a hálózatok bonyolultságait a felettes rétegek elől... Vadász Ea

71 A tágyalandó témák Csomag - üzenet méretek (legkönnyebben elintézhető, ezért előre vesszük) Címzések és címterek: a szokásosakon kívül itt még a kapcsolat és a tranzakció azonosítás is Kapcsolati szolgáltatások, a lehetséges szolgálat primitívek (és ezek összefüggései az egyéb témákkal) Cím - névfeloldások, a szolgálatot igénylő entitás vagy a szolgálatot biztosító kezdeményezze-e (esettanulmány) Vadász Ea

72 Üzenet szegmentálás-összerakás; nyalábolás-szétbontás Darabolás - összerakás van, hogy egy üzenet (ami a felsőbb rétegtől jön) túl nagy a hálózati (esetleg az adatkapcsolati) rétegnek A szállítási réteg ilyenkor darabol - összerak. Multiplexálás - demultiplexálás Előfordul, hogy sok kis üzenet van ugyanahhoz a célhoz. A szállítási réteg nyalábolhatja ezeket egy csomagba (illetve demultiplxálja ezt a másik oldalon). Teljesítménynövelés. Vadász Ea

73 Kapcsolati szolgálatok Csomagszámozás (szegmensszámozás) A helyes sorrend visszaállítás szogálathoz kellhet (ÖK mentes kapcsolatnál feltétlenül) Hibavezérlés Lehetnek hibás, elveszett, v. késő csomagok a várt csomagszám térből kilógó csomagok A technikák itt Ellenőrző összeg a csomagokban, időzítések, hogy a késő csomagokat eldobjuk, a csomagszámozás egyedi legyen. Az end-to-end bázishoz kell flow-control A kérdés itt: vajon mind a forrás, mind a cél foglakozzon az elveszett - késő csomag problémából való kilábolással Vadász Ea

74 A címterek MAC címek - az adatkapcsolati rétegben. Hidak ezt a címteret használják. Hálózati cím- MAC cím feloldás. Ugyanitt a DSAP címek tere Hálózati címek - a hálózati rétegben. Routerek használják. Hálózatcím - alhálózat cím - hosztcím alak, maszkolás a címrészek szétválasztására. Ugyanitt NSAP címtés is. A szállítási rétegben Hálózati címek. Hálózatcím- hosztcím alak. TSAP címek (portszámok) Társalgások azonosítói (Connection ID) Tranzakciók azonosítói Vadász Ea

75 Ezek új címosztályok A címterekhez... Társalgások azonosítói (Connection ID) a szolgáltatást igénylő (kliens) és a szolgáltatást nyújtó (szerver) közötti társalgást (conversation) azonosítják. A szállítási réteg ezeket használva koordinálja az alacsonyabb réteg címtereit (a hálózati- és a SAP címtereket) Tranzakciók azonosítói Részben hasonlók, de kisebb egységek azonosítására valók, mint a társalgás Kisebb egység pl. egy request-respond pár. Ezekből épülhet a társalgás. Ezeket is azonosítják, ezzel lehetővé téve ezek indulásának - megérkezésének nyomonkövetését. Vadász Ea4 75 Megkülönböztetett terminológia: szolgálat - szolgáltatás 75

76 ÖK alapúhoz A szállítási réteg szolgálatprimitívjei Természetes, lehet ÖK mentes és ÖK alapú szolgálat. Utóbbi lehet megerősítéses. A primitívek T-CN-kérés T-CN-bejelentés T-CN-válasz T-CN-megerősítés (*) T-DC-kérés T-DC-bejentés T-DA-kérés T-DA-bejelentés ÖK menteshez Vadász Ea4 76 Figyelmet arra, hogy ezeket a szolgálat-primitíveket TSAP pontokon érjük el a viszonyrétegből, vagy sok esetben az alkalmazói rétegből magából. Ebből a T a jelölésekben. További jelölés: CN connect DC disconnect DA data * csak megerősítéses szolgálathoz 76

77 T-CN-kér T-CN-meg T-DA-kér T-DA-kér T-DC-kér Forgatókönyv példák (A viszonyréteg szemszögéből) T-CN-bej T-CN-vál T-DA-bej T-DA-bej T-DC-bej T-CN-kér T-DC-bej idő ÖK visszautasítva a hívott által T-CN-bej T-DC-kér T-CN-kér T-CN-bej T-DA-kér T-DA-kér T-DC-bej idő T-CN-bej T-CN-vál T-DA-bej T-DA-bej T-DC-kér idő Megerősített ÖK alapú ÖK alapú, bontást a cél kezdeményezi (Szinkronizációhoz!) Vadász Ea

78 Az előző példákhoz... A szállítási rétegben cél a hibamentes átvitel Persze, mégis lehet hiba T-DA-kér T-DA-kér T-DA-kér T-DA-bej (hiba) Miután az itteni nyilak mind a viszony-szállítási réteg interfészhez tartoznak, nem mutatják, hogy a hibakontrol milyen szolgálatokat kíván (használ) a szállítási-hálózati interfészen! A szállítási protokollon - természetesen lehet (van) hibakezelés! idő ÖK mentes hibátlan, hibás Vadász Ea

79 A szállítási réteg protokolljai Ha (elvileg) nézzük, mit is kívánna az OSI, nagyon bonyolult lenne a helyzet! Attól függően, hogy milyen alattunk a hálózati réteg (általában hibátlan csomagkézbesítés és nincsenek RESET-ek; u.a. de vannak RESET-ek; hibás csomagkézbesítés és RESETek is) eleve több protokoll osztály kell! Nagyon sok protokoll-elem (TPDU) kell, hogy minden protokoll osztály megvalósulhasson. Mindez nem fér be a tárgyba! Lesz viszont szó az ismert szövetekről, (TCP/IP), és ott lesznek esettanulmányok (TCP, UDP) Vadász Ea

80 A szállítási kapcsolat menedzselése A címzés-névfeloldás probléma Az emberek számára is elfogadható gazdagép névterek leképzése hálózati címekké a viszonyréteg problémája A TSAP címek menedzselése viszont itteni kérdés is! A TSAP címek "megtalálása" funkció biztosítható fixen "bedrótozva"; elosztva a hálózat valamennyi entitására speciális névszolgáltató (directory szolgáltató) segítségével; speciális szolgáltatóval. Vadász Ea

81 A TSAP cimek Az utóbbi kettőnél (speciálisak) két stratégia lehet a "kezdeményezőtől" függően az igénylő (kliens) a kezdeményező az kliens a speciális csomaggal kér leképzést a névtérből/be a címtérbe/ből. A szolgáltató (server) a kezdeményező a szolgáltató időnként (rutinból) broadcast csomagban bejelenti, milyen szolgáltatásokat biztosít. Ezeket a hálózati entitások (vagy a név-dir szolgáltatók) összegyűjtik, táblázatba foglalják. Utána már mehet a feloldás. Vadász Ea

82 Esettanulmány A feladat: B gépen van aktuális időt szolgáltató processz (a viszony, vagy magasabb rétegben) Az A gép egy processze (kliens) szeretné lekérdezni az időt ÖK alapon. Tegyük fel Az OS biztosít rendszerhívást egy TSAP-hoz, ebben megadhatunk egy TSAP címet (pl. portot). A kliens processz rendszerhívással a saját pl. TSAP-6-ját el tudja érni T-CNkéréssel. B szolgáltató processze fut, hallgatja a TSAP-122-őt (azon T-CN-bejelentést). A forgatókönyv Az A processz T-CN-kérést ad, forrásként a TSAP-6-ot, célként a B: TSAP-122-őt adva; Az A gép valamilyen NSAP-on hálózati összeköttetést létesít a B gép valamilyen NSAPjához. Ezzel eléri a B szállítási entitását. Ezzel létrejött a szállítási összeköttetés; T-CN-bejeltéssel értesíti a B szállítási entitása a B processzt az összeköttetés létrejöttéről; A B processz a B:TSAP A:TSAP-6 "vonalon" T-CN-válasszal elfogadja; Erről az A T-CN-bejeltéssel értesül; Most már mehet A-ról a T-DA-kérés stb. Vadász Ea

83 Mire világítanák rá? Az, hogy A a TSAP-6-on próbálkozik, az az ő ügye, ő választott a 6-os port címet. De honnan vette a B:TSAP-122 címet? Válaszok: B időszolgáltatója már régen a 122-ös porton szolgáltat, és ezt a felhasználók megszokták, tudják a 122-es port konvencionálisan időszolgáltató, méghozzá ÖK alapon (innen a 122). Szintén konvenció, hogy minden gépen fut időszolgáltató, így a B-n is (innen a B). Esetleg több mint konvenció - szabvány ez (néhány kulcsfontosságú szolgáltatásnál ez valóban így van. Pl. 519/TCP Unix time szolgáltaás). Van egy procesz szerver processz, aminek "fix" portcíme van. Ettől kérhetjük, indítsa el a szolgáltatót, és mondja meg, milyen portcímet hallgat (Ez persze nem jó olyan szolgáltatásra, amit nem lehet csak úgy "indítani", mert pl állandóan futó daemon). Van egy név-szolgáltató (dir-szolgáltató) processz ismert címen. Ez visszadja, hogy milyen deamon fut, és milyen portcímen lehet elérni Ráadásul ennél ascii névvel kereshető egy-egy szolgáltató processz Vadász Ea

84 A viszonyréteg Itt is felmerülhet a szükségesség kérdése A "megbízhatósággal" már nem kell foglalkozni, akkor mivel? Alapvető célja: lehetőséget adjon felhasználóknak (alkalmazásoknak, megjelenítési rétegbeli entitásoknak) viszonyokat létesíteni. A viszony: összeköttetés, amin adatokat cserélhetünk. Dialógus. Vadász Ea

85 Feladata tehát A viszonyréteg dialógus kontroll, ahol a dialógus lehet szimplex, half duplex, full duplex. Viszony adminisztráció, azaz viszony létesítés (authentikáció, dialógus azonosítás, esetleges megegyezés a viszony tartási idejéről, megegyezés, melyik fél kezdje a dialógust stb.); dialógus a viszonyon (az aktuális adatátvitel, nyugtázás, megszakadt kommunikáció helyreállítása stb.); viszony bontás (megkülönböztetendő a megszakadt kommunikációtól). Vadász Ea

86 Viszonyok és szállítási összeköttetések Lehetséges esetek Egy viszony egy összeköttetésen viszony connection Természetes. Több viszony egy összekötteésen viszony Pl. légitársaság helyfoglalás: connection a kisasszony egymás után különböző helyfoglalásokat intéz ua-on a kapcsolaton. Egy viszony több összeköttetésen viszony connection Ha megszakad a kapcsolat, akkor újraépülve másik, folytatható a dialógus. Ilyenkor szinkronizácó! Vadász Ea

87 A viszonyadminisztrációhoz Authentikáció igénye felmerül: egy viszony/dialógus legyen ellenőrzött, azonosított, engedélyhez kötött, esetleg elutasítható egy felhasználó/csoport számára, engedélyezett mások számára. ÖK alapú viszonynál ezt elég egyszer, a viszony kiépítésekor elvégezni. Van tehát szolgálat, ami login nevekkel, jelszavakkal foglakozik, authentifikál, engedélyez, elutasít Dialógusazonosítás Mint a tarnszport rétegben a kapcsolatot, ezt is azonosítani kell... Vadász Ea

88 A viszonyadminisztrációhoz A dialógus kontroll Elvileg a szállítási összeköttetések full duplexek Van helyzet, amikor az alkalmazásnak szimplex, half dulplex dialógus jobban megfelel Példa AB lekérdező rendszer, a lekérdező kérdésére az AB szolgáltató válaszol. Hogy egyszerű lehessen a lekérdező, feladott kérdésére a válasznak meg kell érkeznie, mielőtt új kérdést tesz. Ez tipikusan half duplex működést igényel. Vadász Ea

89 A szinkronizáció Itt a célja: hiba, "meg nem egyezés" esetére a viszonyrétegbeli entitások egy korábbi ismert állapotba jussanak vissza. Miért kellhet? Hiszen az alsó réteg(ek) nyújtják a megbízhatóságot? Azt igen, de a felsőbb rétegbeli hibákat nem! Példa: Fájlrendszert mentünk hálózaton keresztül és a célnál az adathordozó "kimerül". A célnál az operátor új kötetet helyez be, és folytatják De honnan? Nyilvánvalóan az utlsó még jól átvitt fájl utáni ponton... Vadász Ea

90 Még egy kérdés A tárgyalásmódunkban a viszonyrétegek ÖK alapú szolgálat-típus elemek összességének tűnt. Nem lehet ÖK mentes viszony? De lehet. Ilyen pl. az RPC, Java RMI, CORBA (ha ezeket ebbe a rétegbe értelmezzük) Azért nehéz a tárgyalás, mert ezeknél a SW technológiáknál az OSI terminológiát nem nagyon használják Van mindig ez a réteg? Nincs. A DoD modellben nincs. Máshová helyezik ezeket a funkciókat. Vadász Ea

91 A megjelenítési réteg Az OSI első javaslata óta e réteg szerepe változott. Ma jobb volna ábrázolási rétegnek (Representation Layer) nevezni. Míg az alatt lévők a bitek forrástól célig való eljuttatásával foglalkoznak, e réteg feladata megőrizni az átvitt információ jelentését! Az adatok ui. struktúráltak, lehetnek szövegek, adat rekordok, struktúrák stb., fájlok stb. És ezeket a különböző gépek különböző szintaxissal kezelik. Lehet pl. ASCII - EBCDIC karakterkészlet English - Cirill aphabet little endian - big endian byte sorrend fájl szintaxis különbségek stb. Vadász Ea4 91 Mind az ASCII, EBCDIC képes angol ABC-t reprezentálni American Standard Code fot Information Interchange Extended Binary Coded Decimal Interchange Code Shift-JIS ABC a japán karaktereknek... Intel processzorok little endian (reverse-byte-order) módszerűek: a kevésbé szignifikáns bitek (least significant bits; lowest binary values) "elől" vannak az üzenetkben, az összetettebb (pl. word) típusokban A Motorola processzorok pedig big endian jellegűek (most significant bit appears first). 91

92 A megjelenítési réteg feladatai Az adatstruktúrák (bit order, byte order, char code, file syntax) átalakítása (translation) és vissza Adattömörítés (miután szoros összefüggésben van az adatábrázolással, kézenfekvő ) és visszaállítás Titkosítás és visszafejtés (miután ez is kapcsolatos az adatábrázolással, kézenfekvő, hogy ez is ebben a rétegben van). Célja a biztonság növelése. Vadász Ea

93 A megjelenítési réteg Kérdés: van-e szükség e rétegre? Válasz: meg lehetünk nélküle, de akkor az alkalmazásoknak kell elvégezniük a fenti funkciókat, feltéve, hogy igényt tartunk ezekre. Vadász Ea

94 Az alkalmazási réteg A legfelső réteg Szolgáltatásai az felhasználóknak jók. Legnépszerűbbek: fájltovábbítás; levelezés; távoli géphasználat; WEB stb. Mi lehet itt érdekes (és még általános)? Itt nincs SAP azonosítás, érdekes lehet tehát, hogyan (milyen módszerekkel) lehet kérni a szolgáltatást! OS rendszerhívás elfogással (syscall iterception) Távoli oprációval (Remote Operation) Kollaboratív módszerrel (Collaborative Computing) Vadász Ea

95 OS Syscall Interception Az OS-nek "nincs tudomása" a hálózati szolgáltatások létéről Mielőtt a Syscall eljutna a helyi OS szolgáltató rutinjához, elcsípik előle a kérést és a hálózatra irányítják Vagyis a szokásos syscall-okkal kell kérni a hálózati szolgáltatásokat is. Pl. DOS read from file server Vadász Ea

96 Remote Operation A helyi OS törődik a kliens kérésével, azt ő közvetíti a távoli szerverhez, míg a távoli szervernek nincs tudomása az alkalmazásról (a kliensről), csakis az OS-ről tud Collaborative Computing Mind a szolgáltatást kérő, mind a szolgáltató tudomással bír a másikról, együtt koordinálják a munkát Peer-to-peer együttműködés. Vadász Ea

97 Vége Vadász Ea