lehetséges írásbeli szigorlati kérdések az...

Számítástechnika szigorlat2009

Lehetséges írásbeli szigorlati kérdések az OPERÁCIÓS RENDSZEREK c. tárgy anyagából

1. Az operációs rendszer fogalma (több nézőpontból is).

2. Operációs rendszerek szolgáltatásai (szolgáltatások szerinti komponensek)

3. Operációs rendszerek implementációs szerkezetei (Monolitikus kernel, réteges kernel, mikrokernel struktúra)

4. Az operációs rendszerbeli folyamat (processz) fogalom. Folyamat kontextus. A fonál fogalom.

5. A processz állapotok, állapotváltások, processz futási módok. Taszk és fonál állapotok, állapotátmenetek.

6. Hiba és eseménykezelés: esemény, állapot, jelzés fogalmak. Kivételes esemény és megszakítás összevetése.

7. Processzor idő ütemezése (scheduling). Kívánalmak, technikai alapok. Ütemezési döntési helyzetek. Ütemezés prioritási algoritmusok.

8. Processzek közti kommunikáció: alapfogalmak (szinkronitás, aszinkronitás, névhasználat, pufferezés, primitív mechanizmusok). Direkt és indirekt kommunikáció.

9. Kölcsönös kizárási és pecedencia szabályozási mechanizmusok. Alapfogalmak (Kölcsönös kizárás, kritikus szakasz, belépési szakasz kilépési szakasz stb. fogalmak), követelmények (biztonsági, előrehaladási, korlátozott várakozási, platform).

10. Kölcsönös kizárási mechanizmus: a szemafor. Dijkstra szemafora, használata klasszikus problémákon. A spinlock szemafor.

11. A memória menedzselés feladatai (memória allokálás, címleképzés segítés). Miért lehet szükség címleképzésre?

12. A virtuális memória menedzselés koncepció.

13. Lapozós virtuális memória menedzselésben a címleképzés folyamata. A laptábla és szerepe. Laptábla méret kezelés.

14. A laphiba és kezelése. A laphiba gyakoriság és szerepe a munkakészlet modellben. Lehetséges kilapozási stratégiák.

15. Eszköz driver-ek funkciói, felépítésük. Eszköz osztályok.

16. Fájlrendszer megvalósítási feladatok. Jegyzékszerkezetek. Szabad blokk menedzselési lehetőségek. Fájl attribútum rögzítési lehetőségek (ezen belül fájl testet képező blokkok rögzítési lehetőségei).

-1-


1. Az operációs rendszer fogalma (több nézőpontból is)A legtöbb számítógép felhasználó használja az operációs rendszereket, azok szolgáltatásait,

anélkül, hogy pontosan meg tudná fogalmazni, mi is az operációs rendszer. Tudják, hogy egy rendszer szoftver, ami kezeli a gépet, parancsokat tud fogadni, tartoznak hozzá eszközök, állományok, katalógusok, ezekben lehet manipulálni, stb.

De ha definiálni kell az operációs rendszert, akkor gondban vannak.Ennek a bizonytalanságnak az az oka, hogy az operációs rendszerek alapvetően két, egymástól független funkciót valósítanak meg, két, egymástól független nézőpontból szemlélhetők, két szempontból definiálható lényegük, és rendszerint nem tisztázzák a definíció során, hogy melyik nézőpontból történik a definíció, vagy az operációs rendszer fogalom meghatározásakor éppen keveredik a két nézőpont.

Az operációs rendszer hasonlít egy kormányhoz, azaz maga nem teljesít valódi funkciót, de lehetőséget ad az alkalmazások hasznos tevékenységéhez. Van erőforrás kiosztó és vezérlő szerepköre. Néha úgy szemléljük az operációs rendszert, hogy az azon programok gyűjteménye, amit a számítógéprendszer szállító a géphez szállított. Máskor: azon programok, amik mindig futnak a számítógépünkön.Egy jó módszer az operációs rendszer definiálására, ha megragadjuk a kettős természetét: az operációs rendszer egyrészt virtuális gép, másrészt erőforrás menedszer (válaszoló gép).

Az OS mint kiterjesztett gép (Extended Machine, Virtual Machine)

Az operációs rendszer - mint kiterjesztett gép - magasabb absztrakciós szintet biztosít a felhasználó számára. Az eszközöket és állományokat szimbolikus neveken engedi kezelni, ezekben magasabb szintű operációkat biztosít (p1. open, read, write rendszerhívásokat (system calls)), sőt, az operációs rendekhez kötődő parancsértelmezőkkel még magasabb szintű parancsokat (p1. copy, move, stb.). Úgy is mondhatjuk, ebből a szempontból nézve az operációs rendszer elrejti a részleteket a felhasználó elől, levesz bizonyos felelősséget a felhasználó válláról, akár különböző architektúrákon is biztosítja helyettesíthetőségét, egységességet biztosít a hasonló de részleteikben nagyban különböző eszközök (p1.: floppy diszkek és hard diszkek) kezelésére. Ez egy felülről-lefelé (top-down) megközelítése a problémának. A virtuális gépet, amit az operációs rendszer biztosít, könnyebb programozni, mint az alatta létező hardvert. Ha úgy tetszik, ebből a szempontból kényelmessé teszi az operációs rendszer a hardver használatot.

Az OS mint erőforrás menedzser (Resource Manager)

Egy másik - valójában alulról-felfelé való (bottom-up) megközelítésben az operációs rendszer azért van, hogy egy összetett rendszer részeit menedzselje.

Milyen erőforrásokat kell menedzselnie az operációs rendszereknek?

A hardver erőforrásokat (processzorok, elsődleges és másodlagos tárak, eszközök stb.), a szoftver erőforrásokat (alkalmazások, adatbázisok stb.) és az emberi erőforrást) felhasználók, operátorok, rendszermenedzserek stb.).

A menedzselési feladatkörbe az erőforrás kiosztás mellett természetesen beleértjük az erőforrás védelmet (kölcsönös kizárást kritikus esetekben) a konfliktusok feloldását az erőforrások használatának számbavételét (statisztikák készítését, számlázásokat is). Olyan fogalmak merülnek itt fel, mint a hatékonyság, a teljesítmény, a védelem és biztonság, a megbízhatóság stb. Ha úgy tetszik, ebből a szempontból az operációs rendszer hatékonnyá teszi (efficiency) a hardver használatát.

-2-


2. Operációs rendszerek szolgáltatásai (szolgáltatások szerinti komponensek)

Több szempont szerint is osztályozhatjuk az operációs rendszereket.A legfontosabb osztályozási szempontok:

Az operációs rendszer alatti hardver „mérete” szerinti osztályozás szerint:

1. mikroszámítógépek operációs rendszerei

2. kisszámítógépek(esetleg munkaállomások) operációs rendszerei

3. nagygépek operációs rendszerei

A kapcsolattartás típusa szerinti osztályozás szerint:

1. kötegelt feldolgozású operációs rendszerek, vezérlőkártyás kapcsolattartással

2. interaktív operációs rendszerek

A következő osztályozási szempontok még fontosabbak, ezeket ezért részletezzük is:

cél szerinti osztályozás

a processz kezelés, a felhasználók száma szerinti, a CPU idő kiosztása szerinti osztályozás

a memória kezelés megoldása szerinti osztályozás

az I/O koncepciók, a fájl rendszer kialakítása szerinti osztályozás

Operációs rendszerek osztályai cél szerint:

Megkülönböztethetünk általános célú és speciális célú operációs rendszereket. Az általános célú operációs rendszerek több célúak: egyidejűleg használjuk azokat program- fejlesztésre, alkalmazások futtatására, adatbázisok lekérdezésére, kommunikációra stb. A speciális célú rendszerek osztálya igen gazdag lehet: vannak folyamatvezérlésre beállított, vannak tranzakció feldolgozásra implementált stb. rendszerek, közös jellemzőjük, hogy egyetlen célt szolgálnak.

Processz kezelés, időkiosztás, felhasználó szám szerinti osztályok:

A több, változó feladatszétosztású processzorral rendelkező gépeket az operációs rendszerükkel együtt multi processing rendszereknek szokás nevezni.

Az egy processzoros gépek működtető rendszere lehet single tasking (egyidőben egy processz lehetséges), vagy multi tasking rendszer (kvázi párhuzamosságban több processz fut).

Az egyidejű felhasználók száma szerint beszélhetünk egyfelhasználós (single user) rendszerekről és többfelhasználós (multi user) rendszerekről. Az utóbbiak mindenképp multi tasking vagy multi processing rendszerek kellenek, hogy legyenek, az egyfelhasználós rendszer lehet single tasking is.

A CPU időkiosztása lehet szekvenciális (egy processz teljes feldolgozása után kapcsol a másikra), kooperatív-event polling rendszerű, megszakítás vezérelt (interrupt driven), vagy beavatkozó-megszakításvezérelt (preemptiv-interrupt driven).

Az event polling rendszer már lehet többfelhasználós/többfeladatos rendszer. Az a processz lesz aktív, amelyik eseményt kap, és addig aktív, amíg új esemény aktivvá nem tesz egy másik processzt. A megszakítás vezérelt rendszerekben minden I/O megszakítás bekövetkezésekor újraértékelik a processzek prioritási állapotait, és a legmagasabb prioritású kapja a CPU-t. A beavatkozó rendszerű időkiosztásnál elveszik a CPU-t a futó processztől akkor is, ha az továbbra is futásra kész állapotban van, ha találnak nála magasabb prioritásút. Az időkiosztási algoritmus szerint e rendszeren belül megkülönböztethetünk klasszikus időosztásos (time sharing) és valós idejű (real time) rendszereket, az utóbbiak az igéretvezérelt időosztású rendszerek egy alrendszerét képezik.

-3-


Memória menedzselés szerinti osztályozás

Megkülönböztetünk valós címzésű és virtuális címzésű rendszereket. A valós címzésű rendszereken belül a fix, vagy változó partíciókra osztott memóriakezelés lehetséges.A virtuális címzésű rendszerek alosztályai a klasszikus ki/be söprő rendszerek, a klasszikus igény szerinti ki/be lapozó) rendszerek és a ki/be söprő és lapozó rendszerek.

Az I/O koncepciók, a fájlrendszer megvalósítása szerinti osztályozás

1. Hogyan rendelik az OS-ek a fájlnévhez a fájl blokkjait ?Már nem használt megoldás a folyamatos allokáció. Használatos viszont az indextáblás hozzárendelés. A Unix-ok jellegzetes módszere az ún. i-listás hozzárendelés. Egyes fájlrendszerekben kiterjedéseket -- rendelnek a fájlnevekhez

2. Hogyan kezelik az OS-ek a szabad blokkokat?Használatos megoldás a bit-térképek vagyfoglaltsági térképek alkalmazása. Szintén gyakori implementációban láncolt listán tartják nyilván a szabad blokkokat.

Védelmi komponensekHálózatkezelő komponensekFelhasználói felület(nem feltétlenül OS komponens)

-4-


3. Operációs rendszerek implementációs szerkezetei (Monolitikus kernel, réteges kernel, mikrokernel struktúra)

Milyen az operációs rendszer belülről? Milyen szempontok szerint nézhetjük a struktúrákat?A nézőpontok:

1. Milyen szolgáltatásokat biztosít az OS? Milyen funkcionális részei vannak?

2. Milyen felületeket (interface) ad a felhasználóknak, a programozóknak?

3. Komponenseit hogy állítják elő, köztük milyen interfészek vannak?

A szolgáltatások szerinti komponensek (funkcionális struktúra)

Processz (taszk, fonál) menedzsment komponensek: A kreációt és terminálódást biztosító funkciók processz kontroll és ütemezési funkciók

állapot-nyilvántartás, CPU ütemezés, szinkronizációs mechanizmusok, beleértve e kölcsönös kizárási mechanizmusokat is, processzközti kommunikációs mechanizmusok.

Memória menedzselő komponensek: Memóriahasználat nyilvántartása, Memória allokálás/felszabadítás, Címleképzés (mapping) segítése,

közben ki/besöprés vagy lapozás.Másodlagos tároló menedzsmentje:

szabad terület menedzselése blokk allokáció diszk blokk scheduling

I/O menedzsment komponensei: bufferezés, device driver interface elemek, speciális driver-ek

Fájlrendszert megvalósító és menedzselő komponensek: Jegyzékstruktúra megvalósítás (directory implementáció, fáj! attribútumok rögzítése) Blokk-hozzárendelési módszerek, Fájlok jegyzékek kreálása, törlése, írása, olvasása, Fájlrendszert létrehozó, használatba vevő, helyreállító segédprogramok mentések és visszaállítások segédprogramjai.

Védelmi komponensek (néha “beépítve” az egyéb funkciókba, néha megkülönböztethető komponensként szerepel) Networking, hálózatkezelő komponensek (néha beleértik az I/O menedzsmentbe) Felhasználói kapcsolattartó rendszer (CLIs) (némely esetben nem is része a kernelnek)

Parancsértelmező GUI.

-5-


Interfészek a felhasználóknak, programozóknak

Ez a struktúra a funkcionális struktúrához közeli. Itt is azt nézzük, milyen szolgáltatásokat biztosít a kemel, de oly módon, hogy milyen a felület a szolgáltatás kérelemhez. A szolgáltatási felületeknek három nagy csoportja van:

Rendszerhívások osztályai, rendszerhívásokA programozó felhasználó milyen API hívásokat programozhat

Rendszerprogramok, segédprogramok (utilities) osztályai

Kapcsolattartók (CLIs).

Implementációs struktúrák:

Egyszerű, monolitikus rendszer;

Réteges rendszer

Virtuális gépek

Kliens-szerver modell

Vegyes szerkezetek

Monolitikus rendszer

Az a struktúra, mikor nincs is struktúra. A monolitikus rendszer magja névvel ellátott szolgáltató eljárások (service rutins) gyűjteménye, melyek hívhatók rutinból:

a felhasználói programból (processzből) úgynevezett rendszer hívással (kernel call, system call), vagy

egy másik szolgáltató rutinból (call).

A két hívási mód megkülönböztetésének vannak okai:

A kernel call kívülről egyszerű függvény- vagy eljáráshívásnak tűnik: megadjuk a szolgáltató rutin nevét ás aktuális paramétereit. Valójában ez nemcsak egyszerű függvény vagy eljárás hívás paraméter átadással, hanem egyben trap: a processzor felhasználói módból kernel módra vált. A monolitikus rendszer rutinjait assembly, esetleg magas szintű nyelven írják. Ezeket lefordítják (compile) és összeszerkesztik (linkelik) egyetlen betölthető programba, lementik egy fájlba. Ez a fájl a rendszerindításkor betöltődik és a kernel ott áll szolgáltatásra készen.

Réteges struktúrájú OS-ek

Tipikus példa erre a Dijkstra professzor ás hallgatói által készített THE nevű operációs rendszer (1968). A THE egyszerű kötegelt feldolgozási rendszerű operációs rendszer volt.Mi is a rétegezés lényeges előnye? Egy réteg magasabb szintű operációkat biztosít a felette lévő számára és elrejti az alatta lévő részleteket. Ugyanakkor jól meghatározott interfészek vannak közöttük.

Virtuális gépek (Virtual Machines)

Azon az egyszerű elgondoláson alapult, hogy egy időosztásos rendszertől elvárjuk:

biztosítsa a multiprogramozást,

biztosítson egy kiterjesztett gépet, aminek kényelmesebb a kezelés, mint egy valós gépnek.

A két követelményt a VM1370 rendszer teljesen szétválasztva biztosítja. A rendszer lelke a Virtual Machine Monitor, ez fut a puszta hardveren, úgy biztosítja a multiprogramozást, hogy több virtuális gépet emulál a felette lévő réteg számára. Az emulált gépek azonban nem egyszerű kiterjesztett gépek, hanem pontos másolatuk valódi gépeknek. Minden emulált gép bit szinten azonos az igazi hardverrel, ezért aztán futtatható rajta bármely olyan operációs rendszer, ami az igazi gépen futtaható.

-6-


A kliens-szerver modell

Modern operációs rendszerek fejlesztési trendje, hogy minél kisebb legyen a kernel, hogy az operációs rendszer minél több funkcióját tegyük magasabb rétegekbe. Lehetőleg minél több OS funkció kerüljön a felhasználói módú, legfelső rétegbe. A törekvés a kliens-szerver architektúrával közelíthető. Az elgondolás lényege, hogy a felhaszná1ói processzek- üzenetküldéssel igényeljenek szolgáltatást a processzektől. A szolgáltató processzek programjai önállóan linkelhetők, betöltődhetnek a rendszer egész életére, vagy ideiglenesen (daemon processzek), futhatnak kernel, de akár felhasználói módban is. A szolgáltatók, miután elkészültek a munkájukkal, üzenetküldéssel válaszoljanak. Itt a kernel csak a kommunikációt biztosítja.

-7-


4. Az operációs rendszerbeli folyamat (processz) fogalom. Folyamat kontextus.A fonál fogalom.

A folyamat fogalom, A fonál fogalom.

Szinte minden operációs rendszer kulcsfontosságú fogalma a folyamat fogalom. A folyamat kifejezést a köznyelv és más szakterületek is használják. A folyamaton általában tevékenységek sorozatának végrehajtását értjük, ahol a tevékenységeknek van kezdete és vége.

Az operációs rendszerek tárgyalása során is használjuk a folyamat (angolul process) kifejezést. Elfogadhatjuk a magyaros kiejtésű processz nevet is. Kapcsolatos kifejezések lesznek a munka (job), a feladat (task), vagy magyaros kiejtéssel a taszk, a fonál, vagy szál (thread) kifejezések is. Most fogadjuk el a következő definíciót a folyamat fogalomra: a processz egy végrehajtási példánya egy párhuzamosságot nem tartalmazó végrehajtható programnak. A processz egy futó program-példány.

Láthatóan megkülönböztetjük a processz fogalmat a végrehajtható program (executable program/image, loadable program/image) fogalomtól! A processz más entitás, mint a program! Egy program lehet szövegszerkesztővel készült forrás program. Lefordítva a forrás programot tárgyprogramot kapunk. Tárgyprogramokat futásra kész állapotba hozhatunk összeszerkesztő (linker, task builder) eszközök segítségével, az eredmény a futásra kész, végrehajtható, betölthető program: eddig a program kifejezéshez mindig kapcsolódhatott a fájl fogalom. A programoknak helyfoglalásuk van. Valamilyen tömegtárolón fájlok formájában tároljuk őket, hosszméretük van, statikusak.

Egy processz születik. Születése során, vagy születése után egy végrehajtható program betöltődik a memóriába és fut. A processz vetélkedik az erőforrásokért, “él”, időt használ, viselkedése dinamikus. Végül a processz megszűnik (exitál, terminálódik). Pongyola, de nagyon szemléletes fogalmazás a következő: a processzben fut a program. Érezzük, hogy a processzhez hozzátartozik a végrehajtható program, hozzátartoznak annak kód és adat szegmensei, de további információk is tartoznak a processzekhez, melyek a „program állapotban” még nem létezhettek. A processznek van például veremtára (a függvényei, eljárásai paramétereinek cseréjéhez). A folyamathoz hozzátartoznak a CPU regiszterek pillanatnyi értékei is. Hozzátartoznak még bizonyos adminisztrációs információk is: vagyis mindazon információk, melyek szükségesek, hogy a processz futni tudjon.

Egy multirogramozású rendszerben (multitasking, multiprocessing) egy időben több folyamat él. Folyamatok születnek, vetélkednek, együttműködnek, kommunikálnak, végül megszűnnek.

A mostani — klasszikus - folyamat fogalom használatánál kikötjük még, hogy a folyamatok szekvenciálisak. Ez azt jelenti nekünk, hogy egy kijelölt processzoron futnak (sequential process: one execution on a dedicated CPU), egy processzhez egy dedikált programszámláló regiszter (PC, Program Counter) tartozik, ami egyetlen helyre tud mutatni a program szövegben. A klasszikus processz egy szálon fut, a „benne futó” végrehajtható program nem tartalmaz párhuzamosságokat. Egy konkurrens nyelven irt program futás közben több végrehajtási fonállal rendelkezhet. Párhuzamos programozási környezetben ezért a konkurrens program futásközben neve sokszor a taszk név, a végrehajtási menet neve a fonál, vagy szál (thread), vagy éppen a „könnyűsúlyű” processz. A klasszikus elképzelésben a független processzekhez független processzorok, ezzel független programszámláló regiszterek tartoznak. Egy-egy processz vezérlési menete közvetlenül nem befolyásolja a többi menetét. Közvetetten persze a processzek az erőforrásokért való vetélkedéssel, a processzek közötti kommunikációs mechanizmusok segítségével befolyásolhatj ák egymást! Az egyik legfontosabb erőforrás, amiért a processzek vetélkednek, éppen a processzor lehet! Multiprogramozott rendszerben több processz létezhet egyidőben mint ahány processzor van: éppen az operációs rendszer feladata, hogy biztosítson a processzek számára „saját logikai processzort”, ütemezze számukra a valódi processzor idejét, „kapcsolja” számukra a valódi processzort, gondoskodjon az elválasztott logikai processzorok” állapotának megtartásáról. A klasszikus processz a dedikált logikai processzoron szekvenciálisan fut. A processz szemszögéből tekintett szekvencialitás a valóságban nem az.Miután a klasszikus processz koncepció szerint minden processznek van dedikált, saját processzora (ezt az illúziót biztosítja számára a processzor ütemezés), e processzor futási módja nevezhető a processz futási módjának is. A futási mód koncepció a processzorhoz tartozik valójában, de ezzel az áttétellel

-8-


processzek futási módjáról is szoktunk beszélni. Nyilvánvaló, hogy a processzek a „saját kódjukat” felhasználói módban hajtják végre, a rendszerhívások kiszolgáló kódok, az események kezelőinek (handlerek) kódjai Viszont kernel módban futnak.

Folyamat kontextus

Nehéz lefordítani a process context kifejezést. Folyamat környezet fordítás nem jó, mert ezt a process environment fogalomra használtuk (azaz az sh burok környezeti változóinak defmnícióit tartalmazó szövegsorokból álló információkra). A folyamat tartalom, esetleg folyamat szövegkörnyezet használható kifejezések. Míg nem találunk jobbat, használjuk a magyarosan is kiejthető, írható processz kontextus kifejezést. (Megjegyezzük még, hogy egyes szerzők a process environment kifejezés alatt is a processz kontextust értik, azaz nem szűkítik le az environment-et környezeti változók definíciós tábláira.).

A folyamat kontextus definíciója: adatstruktúrákba rendezve minden olyan információ, ami a folyamat futásához szükséges. Más fogalmazásban: minden olyan információ, ami a rendszer számára szükséges, hogy a CPU-t a folyamatok között kapcsolja, a folyamatok szekvencialitásának illúzióját biztosítva. Intuitíve érezzük is, melyek ezek az információk:

a program (image) kódszegmense(i), (szekciói)

a program adatszekciói

a processz veremtára(i) (stack, heap), az argumentumátadáshoz, bizonyos változók futásideji helyfoglalásához stb.

a folyamat menedzselési információk (néha nevezik attribútumoknak):

a kód aktuális instrukciója, ami éppen fut, vagy következik (PC) azonosítási információk (pid, ppid, pname stb.) tulajdonossági, családtagi információk (uid, gid stb.) állapot információk (memória menedzseléshez, időkiosztáshoz stb.) prioritások, limitek, quóták (memória menedzseléshez, időkiosztáshoz stb.) I/O menedzsment információk mutatók a szekciókhoz stb.

Ezek az információk azonosítják a processz által használt erőforrásokat és azt az instrukciót, amelynél a processz éppen fut.A processz kontextus többféle módon szemlélhető:

Egyik szemléletmódban beszélhetünk:

hardver kontextusról (a regiszterek pillanatnyi értékeiről, mint menedzselési információkról)

szoftver kontextusról (kódszegmensek, adatszegmensek, egyéb menedzselési információk stb.)

Egy másik szemléletmódban ugyanaz a kontextus lehet:

felhasználói szintű kontextus (user level context), ami a felhasználói címtartományban (user address space) van, vagy

rendszer szintű kontextus (system level context). Ennek lehet:

statikus része (static part) (főleg a menedzselési információk tartoznak ide), és lebegő (dinamikus) része (dinamic or volatile part), amihez a regiszter állapotok tartoznak

(register context).

Dinamikusnak, lebegőnek (volatile) nevezzük ezt a részt, mert a regiszterek értékeit időnként maguk a regiszterek hordozzák, időnként azonban le vannak mentve valamilyen verembe. Kérdéses, hogy a lebegő kontextust rendszer szintűnek tekintsük-e, vagy sem! Bizonyos regisztereket felhasználói módban használhatunk, ezekre a felhasználói módban futó instrukciók használhatják, de vannak regiszterek, amiket felhasználói módban nem programozhatunk, illetve vannak, melyeket a CPU ugyan használ, de egyáltalán nem programozhatók. Akár a processzek, akár a kernel szolgáltatások által használt memória címek ún. virtuális címek. Egy processz egy instrukciója nem hivatkozik közvetlenül fizikai memória

-9-


címre. Egy processznek az az „elképzelése”, hogy van egy meglehetősen nagy virtuális címtartománya (vagy akár több címtartomány szakasza) és e címtartomány elemekhez a hardver MMU (Memory Management Unit) és az OS kernel együtt biztosít memória rekeszeket is. Az MMU és az OS közösen, a processz számára „észrevehetetlenül” (transzparensen) „leképzi” a virtuális címeket fizikai címekre, és biztosítja, hogy a címzett fizikai rekeszben ott is legyen az érvényes (valid) információ (instrukció vagy adat). Az MMU bizonyos regiszter(ek)ben tárolja az éppen futó processz (current process) „leképzési táblá(i)nak” kezdő címé(i)t. Amikor az éppen futó processz „elveszti” a processzort ss egy másik processz „megkapja” azt (ezt nevezzük processz kontextus kapcsolásnak, Process Context Switch), a „nyertes” processz lebegő (volatile) kontextusának a regiszterekbe való betöltésével Az MMU regiszterek a nyertes címleképző tábláinak címeit tartalmazza. Beláthatjuk, hogy egy processz címtartományának egy részét a felhasználói szintű kontextusát tartalmazó cellák címzésére használja (címtartományának egy része felhasználói szintű címtartomány), de egy másik része a kernel kódjait és adatait tartalmazó rekeszeket címez. Ezt a részt nevezik kernel (rendszer) címtartománynak. Beláthatjuk, hogy ez utóbbi tartományhoz tartozó címre csakis kernel módban hivatkozhatunk. Viszont csak egyetlen kernel „fut” a rendszerben, vagyis minden processz a saját kernel címtartományát ugyanarra az egyetlen kernel címtartományra képzi le. A kernel közvetlenül elérheti az éppen futó processz címtartományához tartozó címeket (miután az MMU regiszterek a processz „leképzési tábláit” címzik), szükség esetén közvetve más processzek címtartományait is kezelheti. Azt beláthatjuk, hogy egy processz címtartománya kiterjed a felhasználói címtartományra (e mögött vannak a kódszegmensei, az adatai, a vermei stb., azaz a tartalom szerinti kontextusának egy része) és a kernel címtartományra (e mögött vannak adminisztrációs információi legalább, mint a kontextusának részei). Vita merülhet fel viszont azon a kérdésen, hogy Vajon a kemel szolgáltatások kódjai és adatai hozzátartoznak-e processz kontextushoz? Ezeknek saját kontextusuk van, abban futnak. Rendszerint tisztán kernel módú a futásuk. A legtöbb kernel szolgáltatást azonban kernel rutinok biztosítanak (még az önálló processzben megvalósított szolgáltatáshoz is kell processz közti kommunikációs rendszerhívás, kell hozzá kernel rutin). Nos, többféle szemlélet létezhet. Egy egyszerűbb, a figgetlen processz modellből levezethető tárgyalásmódban a kernel rutinok — akár rendszerhívás szolgáltatások, akár esemény kezelők — nem részei egyetlen processz kontextusának sem. E szerint a fogalmazás szerint ezek rendszerint egy-egy processz kontextusa fölött futnak (természetesen kernel módban). Tudomásul vesszük, hogy ezzel a tárgyalásmóddal együtt jár az, hogy egyes szolgáltatások a futó processz javára, más szolgáltatások nem a javára „dolgoznak” a processz kontextus felett. A figgetlen processz modellben a kernel dedikált virtuális gépet biztosít minden processznek. Egy másik tárgyalásmód szerint a rendszer-hívás szolgáltatások és a kivételkezelők hozzátartoznak a processz kontextushoz (annak ellenére, hogy ezeket nem a felhasználó programozta), míg a megszakítás kezelők (melyek szolgáltatásai nem mindig köthetők egy bizonyos processzhez) nem. Ez a tárgyalásmód bevezethet egy új fogalmat: a rendszer kontextus fogalmat. E szerint a tárgyalás szerint a CPU vagy egy processz kontextusában fut, vagy a rendszer kontextusban. A processz kontextusban fut a CPU, amikor egy processz kódja hajtódik végre, mikor egy rendszerhívás szolgáltató rutin fut, mikor egy kivételes esemény szolgálódik ki. Rendszer kontextusban fut a processzor megszakítás kiszolgálása esetén. Ez a tárgyalásmód ismeri a processz kontextus váltás fogalmat és egy processz kontextusról rendszer kontextisra való váltást is.

-10-


5. A processz állapotok, állapotváltások, processz futási módok. Taszk és fonál állapotok, állapotátmenetek.

Processz állapotok, állapotváltások, futásai módok

Láttuk, minden processz önálló entitás a saját programszámlálójával és kontextusával. Lehet közöttük együttműködési kapcsolat, a legegyszerűbb példa: egyik processz készít valamilyen kimenetet, ami a másik processz input-ja. A két processz futásának relatív sebességétől függően előfordulhat, hogy a második processznek várnia kell, amíg az első az output-ját elkészíti. A második blokkolt, amíg az inputja elkészül. Kérdés merülhet fel, hogyan “billen” ki ebből az állapotból a blokkolt processz. Másrészt az is előfordulhat, hogy egy processz ugyan nem vár semmire, tehát futhatna, de az operációs rendszer egy másik processznek adja át a CPU-t: ekkor is “vár” a processzünk, most a CPU-ra, ezt az állapotát feltétlenül meg akarjuk különböztetni az input-ra való várakozástól. Azt mondhatjuk, hogy a processzek - életük során - különböző állapotokba (state) lehetnek, az állapotok között különböző állapotátmenetek lehetségesek. A legegyszerűbb és legáltalánosabb állapot és állapotámenet diagram:

Processz állapotok ahol az ellipszisekkel jelöltek az állapotok:

running - futó állapot, a processzé a CPU

blocked - blokkolt, alvó (sleeping) állapot, mikor a processz egy esemény bekövetkezésére vár

ready - futásra kész (computable) állapot, mikor a processz futhatna, ha megkapná a CPU-t.

Az ábrán nyilakkal jelöltük az állapotátmeneteket:

wait/sleep/request - várakozz (blokkolódj) eseményen állapotátmenet

signal!respond - jelzés az esemény bekövetkezésére

preempt - a CPU elvétele a processztől

sehedule - A CPU kiosztása a processznek.

Kérdés merülhet fel, mi váltja ki az állapotátmeneteket a folyamat szemszögéből nézve?

A válasz: egyedül a wait/sleep/request állapotátmenetet kezdeményezi maga a processz (Pl. egy diszk blokk behozatalának kérelmével), az összes többi átmenetet a processz szemszögéből nézve külső entitás váltja ki (a signal-t p1. a diszkvezérlő megszakítása, a preempt-schedule átmeneteket a kernel időkiosztó alrendszere stb.).

Itt már megérthető a folyamat környezet kapcsolás (Process Context Switch) fogalom: ez egy-egy átmenet két processz számára, mikor is az egyiktől elvevődik (preempt/wait/sleep/request), a másiknak kiosztódik (schedule) a CPU.

-11-


Még mindig egy általános - egyetlen konkrét rendszerhez sem kötött - állapot diagram az alábbi:

zombie állapot: exitálódott processz állapota, amíg a szülő processz tudomásul nem veszi az exitálódást.

Non-existent állapot: a processz még nem létezik.

Suspended állapotok: felfüggesztett állapotok.A processzek ebben az állapotban nem képesek az erőforrásokért vetélkedni, sem a memóriáért, sem a CPU- ért nem jelenthetnek be igényt. Az ilyen állapotú processzek esélyesek a “kisöprésre”. Egy processzt csakis egy másik processz “figgeszthet fel”, természetesen a védelmi eszközöket figyelembe véve. Altalában a rendszermenedzser (az ő processze) figgeszthet fel processzeket, ha azokat ki akarja zárni az erőforrásokért való vetélkedésből.

A futási módok alapvetően a CPU jellemzői:

Felhasználói (normál, user) mód

Kernel (privilegizált, védett) mód: ebben

Szélesebb címtartomány Bővebb utasításkészlet

Mivel a CPU regiszterek is hozzátartoznak a processz kontextushoz (dinamikus/volatile kontextus), mondhatjuk: a processzeknek is van futási módjuk. Különböztessük meg az állapotot a futási módtól.

Taszk és fonál állapotok, állapotátmenetek.

Fonál(thread): a CPU használat alapegysége, egy szekvenciálisan futó instrukciósorozat, van dinamikus kontextusa (regiszterkészlete, verme). Osztozik más fonalakkal egy taszk statikus kontextusán. A fonalak valódi vagy pszeudó párhuzamosságban futhatnak.

Taszk: van statikus kontextusa(címkészlete, erőforrásai). Fonál nélkül egy taszk passzív entitás.Egy taszk egyetlen fonállal: klasszikus processz.

További egységek programozói szemmel: rutinok, utasítások, instrukciók.

-12-


-13-


6. Hiba és eseménykezelés: esemény, állapot, jelzés fogalmak. Kivételes esemény és megszakítás összevetése.

Hiba és eseménykezelés: esemény, állapot, jelzés fogalmak:

Az esemény legáltalánosabban: folyamatok (taszkok, processzek, fonalak, rutinok, utasítások, instrukciók) futását befolyásoló, váratlan időpontban bekövetkező történés. Az esemény bekövetkezése esetén reagálni kell rá: le kell kezelni. A lekezelés megváltoztatja az instrukció- folyam normális menetét.

Az eseményt a hardver vagy szoftver generálja és detektálja.

Az esemény változás valamilyen entitás állapotán. Egy információs állapot előállása: egy állapottér állapotvektora. Fogalmazhatunk úgy, hogy egy esemény bekövetkezése azt jelenti, hogy előáll a neki megfelelő állapot, vagy fordítva, ha előállt az állapot, akkor bekövetkezett az esemény. Ezért az állapotot sokszor feltétel állapotnak (condition, error condition, exeption condition), vagy röviden feltételnek szokták nevezni.

Ha a feltétel előáll (bekövetkezett az esemény), akkor az valahogyan jelződik. Más fogalmazással: jelzés keletkezik. Ismét más fogalmazással: valamilyen entitás jelzést küld valamilyen entitásnak. A jelződés, alapja a lekezelhetőségnek, ami kapja a jelzést, az lekezelheti az eseményt.

A lekezelés megváltoztatja a futás menetét:

a normális futás menetét abba kell hagyni

reagálni, kezelni a helyzetet: kezelő instrukciófolyammal, rutinnal, processzel.

dönteni kell arról, hogy lekezelés után visszaadhatjuk-e a futást az abbahagyott vagy az operációs rendszernek adjuk a vezérlést.

Az események osztályaiEgy processz szemszögéből lehet

belső esemény: amit a processz állít elő;

külső esemény: valami, a processzen kívüli entitás állítja elő (pl.: perifériavezérlő interrupt).

Az előállító entitás szerint lehet

hardver által generált és detektált (megszakítások, hibák, anomáliák);

szoftver által generált és detektált (szoftver által generált megszakítások, szoftver által generált és emulált kivételes feltétel állapotok, a szűkebb értelemben vett események).

A legalacsonyabb szintű események a megszakítások (interrupts). A processz szemszögéből nézve külső esemény.(Ha a processz saját magának küld szoftver megszakítást, akkor tekinthető belső eseménynek is). Előállítója rendszerint a hardver (eszközvezérlők), de lehet szoftver is. Jelzése a CPU-nak szól. Lekezelői az operációs rendszer kernel IT kezelő (IT-handler) rutinjai. Kezelésének módja: az aktuális instrukció befejeződik, a kontextus dinamikus része lementődik (rendszerint részben hardveresen!), a lekezelő rutin fut, visszatérve a dinamikus kontextus felvevődik és a soron következő instrukció futhat. Az IT prioritási szinteknek megfelelően IT kezelést megszakíthat megszakítás. A bekövetkezett, de még le nem kezelt megszakítások hardveres sorokon várnak lekezelésre.

-14-


A megszakítások és a hibaállapotok hasonlósága, különbségei

Mindkettő átadja a vezérlést egy kiszolgáló rutinra (handler). A kiszolgálások megszakítás, vagy hibaállapot specifikusak, bár nagyon sokban hasonlóak.

A megszakítás (IT) aszinkron a kurrens instrukciófolyam végrehajtásában. Kiszolgálása két instrukció között történik.

Az exeption condition -bár váratlan -szinkron jelleggel fordul elő, mint direkt hatás egy instrukció végrehajtása során. Kiszolgálása az instrukció végrehajtása közben történik, azaz a kérdéses instrukció végrehajtása folytatódik, vagy éppen megismétlődik.

A megszakítás rendszerint nem kapcsolódik a futó processzhez. Kiszolgálása ugyan történhet a kurrens processz kontextusa fölött, de nem valószínű, hogy a futó processz javára.

Az exeption condition általában a kurrens, futó processz része: kiszolgálása a futó processz instrukciófolyamának kiterjesztése, kapcsolódik a kurrens processzhez, a futó processz javára történik.

A megszakítások kiszolgálásának rendje összefügg a megszakítási prioritási szintekkel (Interrupt Priority Level). Kiszolgálásuk letiltható (lemaszkolható) az IPL (Interrupt Priority Level) szint állításával, de egy megszakítás kiszolgálását magasabb prioritású megszakítás blokkolhatja. Befutott, de nem kiszolgálható megszakítások sorba állva várnak kiszolgálásra (pending interrupts). Rendszerint hardveres a sorképzés.

A kivételes események kiszolgálása nem blokkolódhat. A kivételes események kiszolgálási rendje rendszerint független az IPL szintektől, kivételes eseményt másik kivételes esemény "nem szakíthat meg".

Némely rendszernél a megszakítások kiszolgálására közös rendszer vermet használnak (system wide stack), mivel a megszakítások "system wide" jellegűek. A kivételes események kiszolgálására minden rendszernél processzenkénti kernel verem használatos.

Jelzés (signal): esemény bekövetkezésekor - vagyis a feltétel állapot előállásakor - jelzés (signal) keletkezik, szoktuk mondani. Jelzések keletkeznek normál futás közben események hatására. Jelzések értesítik a CPU-t, vagy egy-egy processzt az eseményekről. Úgy is fogalmazhatunk: a CPU, vagy egy processz jelzést kap, kézbesítenek neki egy jelzést. Az események jelződnek. Ebben az értelemben az esemény és a jelzése lehet még szinkron vagy aszinkron is.

Egyszerűsítve:

van egy jelzés készlet;

jelzés keletkezhet hardver vagy szoftver eredetből

a keletkezett jelzés kikézbesítődik egy processznek, vagy a CPU-nak. A kikézbesített jelzések sorokba rendeződhetnek, várva, hogy lekezeljék őket.

A kikézbesített jelzéseket a lekezelő rutin (handler) lekezeli.

A jelzéseknek van egy készlete. Minden jelzéshez hozzárendelt egy kezelő (handler). Jelzést kézbesít ki a rendszer, amikor detektál egy hardver eseményt, illetve processzek küldhetnek szignált más processzeknek. Ez a szignál fogalom tágabb értelmezése, azt hangsúlyozza, hogy az események jelződnek.

-15-


7. Processzor idő ütemezése (scheduling). Kívánalmak, technikai alapok. Ütemezési döntési helyzetek. Ütemezés prioritási

algoritmusok.Erőforrásokért vetélkedő processzeknél alapvető feladata az erőforrások igénybevételének ütemezése. El kell dönteni, melyik processz kapja meg az erőforrást.

Ilyenkor meg kell különböztetnünk e tématerületen belül három feladatot.

Erőforrás hosszú távú hozzárendelése (allocation),

Erőforrás ütemezés (scheduling)

Erőforrás kiosztása (dispatching), az ütemezés után az a technika, amivel az erőforrást hozzárendelik a processzhez

Valójában bármilyen erőforrás ütemezéséről és kiosztásáról beszélhetünk az ütemezési algoritmusok, a módszerek és eljárások hasonlók lehetnek. Beszélhetünk így CPU ütemezésről, diszkütemezésről stb. Kiemelkedő fontosságú ezek közül a CPU ütemezés és kiosztás.

A hosszú távú hozzárendelés során történik döntés, hogy egy processz melyik CPU-n fusson egyáltalán. Tulajdonképpen csak többprocesszoros rendszeren értelmezhető ez a mozzanat. Egyprocesszoros rendszerekben nincs ez a feladat. A processzhez így hozzárendelt CPU-t maga a processz "pszeudo párhuzamosságban" használja más processzekkel. Időnként ún. "döntési helyzetek" vannak, melyben el kell dönteni, hogy a következőkben melyik processz legyen a "nyertes", a CPU használó. Ez tulajdonképpen az ütemezés (scheduling). Az ütemezés valójában optimálás: a "legjobb" processz lesz a nyertes processz. Nyilvánvaló, hogy csakis a futásra kész állapotú processzek vesznek rész ebben az optimálásban.

A kernel egyik fő feladata a futásra kész processzek közül egy számára a CPU kiosztása. El kell döntenie, melyik futásra kész állapotú processz kapja meg a CPU-t. Scheduler-nek, ütemezőnek hívják a kernelnek azt a részét, amelyik ezzel a döntéssel foglalkozik.A két különböző feladat tehát:

az ütemezés döntés arról, melyik processz kapja meg a CPU-t (scheduler algoritmusok, technikák)

a CPU kiosztás, ami maga a CPU átkapcsolása egyik processzről a másikra (Process Context Switch)

Be kell látnunk, hogy az időkiosztás (és algoritmusa) független magától az átkapcsolási algoritmustól.A régi, kötegelt rendszerekben az ütemezés és időkiosztás egyszerű volt, legtöbbször a first come, first served (a munkák felmerülési sorrendjében szolgáljuk ki őket) ütemezéssel a run-to-completion (fuss, míg befejeződik) módszer volt az általános.

Mit várunk el a CPU ütemező (scheduling) algoritmusoktól?

A kielégítendő kritériumok1.) Pártatlanság: minden folyamat (processz, taszk, job) korrekt módon (nem feltétlenül

egyenrangúan) kapjon CPU-t.

2.) Hatékonyság: a CPU lehetőleg a legnagyobb százalékban legyen kihasználva.

3.) Válaszidő: az interaktív felhasználóknak a válaszidőt minimalizálják

4.) Fordulási idő (turnaround time): a kötegelt munkák (job) fordulási idejét minimalizálni kell.

5.) Teljesítmény: az időegységre eső job-feldolgozás, interaktív munka maximalizálása

-16-


Láthatók bizonyos ellentmondások a kritériumok között. A válaszidő minimalizálása eredményezheti a fordulási idő növekedését! Vagy: a számításigényes munkák korlátozás nélküli előnyben részesítése javítja a hatékonyságot, de nem biztosítja a korrektséget, és az összevont teljesítmény is csorbulhat.

Komplikációt jelent, hogy a processzek, taszkok egyediek és nehezen jósolható viselkedésük. Mégis, van lehetőség elfogadható ütemező algoritmusokat találni, hiszen a processzek gyakran blokkoltak, várnak valamire, ez lehetőséget biztosít a többi futására. Technikai alapot nyújt, hogy a korszerű rendszerekben mindig van óraeszköz, ami periódikusan megszakítást generál, és ezzel lehetőséget biztosít, hogy

az időt szeletekre (time slice, quantum) bontsuk

az erőforrás (pl.: CPU) felhasználás idejét (processzenként) mérjük

bizonyos időnként az állapotokat kiértékeljük, és processzek közti kapcsolást valósítsunk meg.

Az ütemező (scheduler) döntési stratégiája -mely futásra kész processz kapja a CPU-t - alapvetően a következők egyike lehet:

Nem beavatkozó stratégia (non-preemptive). Ez továbbá lehet:

o run-to-completion jellegű: a processz, ha megkapta a CPU-t, addig használja, míg a (rész) feladatát el nem végzi,

o együttműködő (cooperative) jellegű: a processz, ha megkapta a CPU-t, saját döntése szerint lemondhat róla.

Szelektív beavatkozó (selective preemptive) stratégia: bizonyos processzek futásába nem lehet beavatkozni (rendszerint a rendszer processzeknél), más processzektől elveszik a CPU-t, még ha nem is mondana le róla.

Beavatkozó (preemptive) stratégia: bár a folyamatok nem mondanának le a CPU használatáról, beavatkozva elveszik tőlük bizonyos körülmények között. Azokat az operációs rendszereket tartjuk valódi időosztásos rendszereknek, melyeknél létezik a beavatkozás (preemption) lehetőség.

Ütemezési döntési helyzetek a következő esetekben léphetnek fel

1. Amikor egy processz futó állapotból blokkolt állapotba megy (wait/sleep/request állapotátmenet), pl.: I/O kérés vagy gyermek processzre való várakozás miatt

2. Amikor egy processz futó állapotból futásra kész állapotba megy (preemption állapotátmenet), pl.: egy megszakítás bekövetkezés miatt.

3. Amikor egy processz blokkolt állapotból futásra kész állapotba megy (signal/respond állapotátmenet), pl.: egy I/O befejeződése.

4. Amikor egy processz terminálódik

Az 1. és 4. esetekben az érintett processz szempontjából nincs is ütemezési döntési helyzet: másik processzt kell kiválasztani a futásra kész processzek sorából (ha az a sor nem üres).Van "helyzet" viszont a 2. és 3. esetben.

Ha ütemezési döntések csakis az 1. és 4. helyzetekben lépnek fel, akkor mondhatjuk, az ütemezés nem beavatkozó. Ha a 2. és 3. helyzetekben is lehet döntés, az ütemezés beavatkozó.

Az ütemezési algoritmusok vizsgálatához szükségünk van a processzek életének bizonyos szempontú jellemzésére. Megfigyelések szerint a processzek élete során vannak ún. CPU-lázas (CPU burst) és I/O-lázas (I/O burst) életszakaszok. Egy processz a CPU burst időszakában a CPU-t kívánja használni, az I/O burst szakaszában elsősorban az I/O csatornákat használná, ilyenkor a CPU szempontjából blokkolt. A processzek futása CPU-lázas szakasszal kezdődik, azt követheti I/O igényes futási rész, majd újabb "számolásigényes" életszakasz. Az egyes processzek jellemezhetők a "lázas" szakaszaik számával, hosszával.

-17-


A nagyon "számolásigényes"(CPU bound) processzeknek rendszerint kevés, de nagyon hosszú CPU burst periódusból állnak.

Az I/O igényes (I/O bound) processzeknél rendszerint rövidek a CPU-lázas szakaszok, ezek főleg az I/O csatornákat használják.

Ütemezési algoritmusok: FCFS, SJF, és a prioritásos algoritmusok

Igénybejelentési sorrend szerinti kiszolgálás (Fist Come -First Served)Nagyon egyszerű, könnyen megvalósítható algoritmus. A processz készletben (process pool, job pool) létező processzek a beérkezésük sorrendjében kapnak kiszolgálást: ha egy előbb érkezett processz futásra késszé válik (pl.: CPU-lázas szakaszában van), akkor ő kapja meg a CPU-t. Egyszerű, de nagy hátránya, hogy hosszú ideig várakozhatnak processzek, amíg egy CPU igényes processz a CPU lázas szakaszaival végez.

A legkisebb igényű először (Shortest Job First) algoritmusRégi, nagyon egyszerű időkiosztási algoritmus. Ma is használják ezt az algoritmust, pl. a printer spooling sorok kiszolgálására: itt persze könnyebb a dolog, a legrövidebb nyomtatandó fájl nyomtatása valószínűleg a legrövidebb időigényű, azt pedig könnyű megállapítani. De a régebbi kötegelt feldolgozásoknál a CPU kiosztására is alkalmazták, miután bizonyítható, hogy az átlagos fordulási idő (avarage turnaround time) így a legkisebb.

A CPU kiosztás vezérlésénél egyetlen gond, hogyan lehet megmondani előre, hogy az egyes munkák mennyi időt fognak igényelni. Erre a válasz.

A régi kötegelt rendszerekben tapasztalati adatokból jól lehetett ezt becsülni. A Job Control Language nyelven adott vezérlő kártyákon fel is kellett tüntetni a várható, becsült fordulási idő értéket. Az idősorozatokkal jellemezhető munkák várható idejének becslésére jó szokott lenni az öregedés (aging) becslési algoritmus.

Aging lényege:Valamely munka (szakasz) várható ideje a korábbi időiből becsülhető, a korábbi idők súlyozott

összegéből vett átlaggal. A súlyozással azt befolyásoljuk, hogy milyen arányban vegyük figyelembe az egyre régebbi értékeket. Az öregedés lényege: a régebbi idők egyre kisebb súllyal befolyásoljanak, egyre jobban felejtse el a rendszer a régebbi értékeket, "korosodjon"

Prioritásos algoritmusok

Ha úgy tetszik, a FC-FS illetve a SJF algoritmus egy-egy speciális esete volt a prioritásos algoritmusoknak. Az elsőnél a "korábban érkezés", a másodiknál a "rövidebb becsült időszakaszom következik" jelenti a magasabb prioritást.

A prioritás a processzek fontossága. Léteznie kell egy prioritási függvénynek, ami a processzek fontosságát jelzik. A prioritás -a fontosság - sok mindentől függhet: a processz memóriaigényétől, a processz eddigi CPU használati idejétől, a processz (várható) összes CPU használati idejétől, a processznek a rendszerben eltöltött idejétől, külsőleg adott prioritási értéktől, a processz időszerűségétől (timeliness),a rendszer terhelésétől (system load) stb.

A FC-FS algoritmusban a prioritás a processzek érkezési sorrendje volt. A SJF algoritmus prioritása a processzek várható futásideje. Másik, szintén egyszerű prioritás függvény lehet a külső prioritásérték, a processz életében ez statikus, nem változik: egy magas statikus prioritású processz megakadályozhatja, hogy más processzek CPU-t kapjanak. Ezért elvárjuk, hogy a prioritásértékek korrekt módon változzanak a processzek élete során.

-18-


Ütemezési algoritmusok: ígéretvezérelt, Round Robin, többszintes, visszacsatolásos

Ígéretvezérelt időkiosztás (Policy Driven Scheduling)

Interaktív rendszereknél jól használható algoritmus. Alapja, hogy mérhető a processzek rendszerben

eltöltött eddigi ideje: az élet-idő, illetve

azeddig felhasznált CPU ideje: a cpu-idő.

A filozófia: reális ígéret, hogy n számú processz esetén egy processz a CPU 1/n-ed részét kapja.

Ehhez kiszámítandó az ún. jogosultsági-idő :

Amelyik processznél a cpu-idő /jogosultsági-idő arány a legkisebb, annak magasabb a prioritása, az kapja meg a CPU-t.

Az ígéret vezérelt időosztás speciális esete a valós idejű (Real-Time) időkiosztás. Itt az egyes processzek kapnak egy garanciát, melyen belül biztosan megkapják a CPU-t, ha igényt jelentenek be rá. A garantált idő kiszámítása előzetesen megtörténik, és persze, a garanciával rendelkező processzek száma korlátozott.

Roud-Robin scheduling

Egyszerű, korrekt, széles körben használható, könnyen megvalósítható, elég régi algoritmus. Alapja az óra eszköz: segítségével időszeletekre való osztás.

Módszere: ha valamely processz megkapta a CPU-t, addig futhat, amíg a hozzá rendelt időszelet (quantum) tart (Ha közben blokkolódik, akkor persze eddig sem). Ha letelik az ideje, a scheduler elveszi tőle a CPU-t (preempt), és átadja egy másik processznek: ez a processz kapcsolás (Context Switch). A scheduler a futásra kész processzeket egy listán tartja nyilván. CPU kapcsolás esetén a CPU-ról lekapcsolt (preempted process) a lista végére kerül, míg a lista elején álló processz megkapja a CPU-t (scheduled process). A listán a processzek "körben járnak". A lista elején álló processznek legmagasabb a prioritása.

Többszintes prioritás-sorokon alapuló scheduling (Multilevel Feedback Queue Scheduling)

A klasszikus Round Robin azt feltételezi, minden processz egyforma fontosságú. Ez persze nem egészen így van! Vannak fontosabb személyek, akiknek a processzei előnyt kell élvezzenek, valahogy figyelembe kell venni a külső prioritásokat is. Persze, a nagy külső prioritású processzek nem akadályozhatják meg, hogy a kevésbé fontos processzek egyáltalán ne kapjanak CPU-t, a scheduler által biztosított, processzekhez rendelt belső prioritásoknak dinamikusan változniuk kell.

A belső prioritásokat a scheduler egy prioritási függvény szerint dinamikusan állítja elő, amely függvénynek csak egyik paraméter a külső prioritás. Azzal, hogy a processzek belső prioritása dinamikusan állítandó, biztosítható a korrektség, és egyéb célok is elérhetők. A dinamikus prioritásszámítással figyelembe vehető a processzek memóriaigénye is, a processzek eddig felhasznált CPU ideje, az élet idejük, az időszerűségük stb. is.

Az elgondolás ezek után a következő: ha a futó processz időszelete lejárt, történjen meg a dinamikus prioritás értékek meghatározása, és a maximális dinamikus prioritással rendelkező processz kapja a CPU-t. Egyenlő prioritások esetén képezzünk listákat, és a lista elején álló processz legyen a kiválasztott.

-19-


8. Processzek közti kommunikáció: alapfogalmak (szinkronitás, aszinkronitás, névhasználat, pufferezés, primitív

mechanizmusok). Direkt és indirekt kommunikáció.Több folyamatból összetevődő alkalmazás esetén alapvető mechanizmus az IPC. Multiprogramozású rendszerekben abszolút természetes eszköz. Kooperáló processzek kommunikálnak, szinkronizálják futásukat. Több kommunikációs mechanizmus létezik, ezeket akár együttesen is alkalmazhatjuk.Az absztrakt probléma kiindulási megfogalmazása a következő: processz legyen képes üzenetet küldeni processznek, processz legyen képes üzenetet fogadni más processztől.A kiindulási megoldás: legyen send(message) és receive(message) rendszerhívás. A processzek között épüljön fel kommunikációs kapcsolat (link).

Ezzel kapcsolatos kérdések

Hogy lehet kommunikációs kapcsolatot létesíteni?

Az összeköttetés (link) több mint két processz között is lehetséges?

Hány kommunikációs kapcsolat lehet egy processz-pár között?

Mi a link kapacitása? Változó vagy fix méretűek lehetnek az üzenetek?

A kapcsolat egy, vagy kétirányú? És ez az irányítottság hogy van, ha több mint két processz van a kapcsolaton?

Az elvi megoldások a következők

1. direkt vagy indirekt kommunikáció. Ki a közvetítő entitás tulajdonosa (kihez kötődik az entitás)?

2. szimmetrikus vagy aszimmetrikus kommunikáció

3. automatikus vagy explicit bufferelés

4. adatküldés (send by copy) vagy adathivatkozás küldés (send by reference)

5. fix vagy változó méretű üzenetek

Direkt kommunikáció.

Alapeset:

Az ilyen típusú IPC-ben a kommunikálni kívánó processzek explicite ismerik egymás azonosítóit (p1. neveit). A szükséges rendszerhívások ekkor:

send(receiver—name, message)

receive (sender—name, message)

vagy ehhez hasonlók.

A kommunikációs kapcsolat jellemzői:

A link automatikusan megvalósul minden kommunikációs pár között.A processzeknek csak egymás azonosítóit kell ismerni a kapcsolat létesítéshez. Mindíg két procesz között valósul meg a kapcsolat, és rendszerint csakis egy link létezik köztük.Általában egyirányú, de lehet kétirányú is a kapcsolat (a kapcsolat szimmetrikus)

-20-


Indirekt kommunikáció

Az üzeneteket mailbox, vagy port mechanizmusokon keresztül közvetetik. A mailbox (postaláda) absztrakt objektum, amibe a processz üzeneteket tehet, processz abból üzeneteket vehet ki. A mailbox-oknak van azonosítójuk. Ha két processz osztozik közös postaládán (mailbox-on, port- on) akkor azon át válthatnak üzeneteket.

A szükséges rendszerhívások1. create(mailbox)2. destroy(mailbox)3. share(mailbox)4. send(mailbox, message)5. receive(mailbox,message)

Indirekt kommunikáció jellemzői

Link valósul meg processzek között, ha van közös postaládájuk

A link több mint kér processz között is lehetséges. Változatok:

o csak egy fogadó kapja meg a betett üzenetet, az, aki a versenyben előbb éri el;o akár több fogadó is megkaphat egy üzenetet;o címezhető, melyik fogadónak szól az üzenet.

Több link is lehet processzek között. A link lehet egyirányú, vagy kétirányú is.

Változatok a postaláda kötődésére (binding)

1. A mailbox egy processzhez kötődik, úgy is mondhatjuk, a processz tulajdona. Ilyenkor rendszerint a tulajdonos processz a fogadó processz. A feladó processzek a postaláda használói. A share hívással válnak használóvá, send hívásokkal tesznek üzeneteket a ládába. Ha a tulajdonos exitál, a postaláda megszűnik. Erről a használóknak értesülniük kell.

2. A mailbox az operációs rendszer tulajdonában van, az operációs rendszerhez kötődik. Ilyenkor a create hívást kiadó processz (kreátor processz) nem válik tulajdonossá (exitálásával nem szűnik meg a postaláda), de destroy+receive+send hozzáférési jogokat (privilégiumokat) kaphat. Alapértelmezés szerint a kreátor processz beállíthatja a privilégiumait. Bármelyik tehet be üzenetet, bármelyik kiolvashat üzenetet.

-21-


9. Kölcsönös kizárási és pecedencia szabályozási mechanizmusok. Alapfogalmak (Kölcsönös kizárás, kritikus szakasz, belépési

szakasz kilépési szakasz stb. fogalmak), követelmények (biztonsági, előrehaladási, korlátozott várakozási, platform).

A processzek közötti kapcsolat lehet együttműködés jellegű, ez processzközti kommunikációs kapcsolatokat (IPCs) kíván. Ha a kapcsolat konfliktusmentes erőforrás-megosztás, akkor az erőforrásra olvashatóság jellegű hozzáférést kell biztosítani. A vetélkedés erőforrás kizárólagos használatára kölcsönös kizárást, a szinkronizálás ütemezést kíván.

Arról van szó, hogy közös erőforrásokért vetélkedő, együttműködő processzeknek lehetnek kódrészei, melyek futása alatt kizárólagosságot kell biztosítani, vagy amikre ütemezést kell megvalósítani.

A kölcsönös kizárás (Mutual Exclusion) fogalma: a közös erőforrásokért vetélkedő processzek közül egy és csakis egy kapja meg a jogot az erőforrás használatra.

A kritikus szakasz (Critical Section) a folyamaton belüli kódrész, melyen belül a kölcsönös kizárást meg kell valósítani, vagy amire az ütemezést meg kell valósítani.

A belépési szakasz (entry section) a folyamaton belül az a kódrész, ahol kéri az engedélyt a kritikus szakaszba való belépésre, míg a kilépési szakasz (leave section) az a kódrész, ahol elhagyja a processz a kritikus szakaszt. A folyamatoknak természetesen lehetnek nem kritikus szakaszaik is.

A holtpont (deadlock) az az állapot, amely akkor következhet be, amikor két (vagy több) folyamat egyidejűleg verseng erőforrásokért, és egymást kölcsönösen blokkolják.

Kívánalmak a probléma megoldásához

1. Biztonsági (safety) kívánalom: Valósuljon meg a kölcsönös kizárás: ha egy processz kritikus szakaszában fut, más processz ne léphessen be kritikus szakaszába.(Egyidőben csakis egy kritikus szakasz futhat.). Természetesen, ezalatt más processzek a belépési szakaszukat végrehajthatják.

2. Előrehaladási (progress) kívánalom: általában nem kritikus szakaszban és nem belépési szakaszban futó processz ne befolyásolja mások belépését. Ha egyetlen folyamat sincs kritikus szakaszában és vannak processzek a belépési szakaszukban, akkor csakis ezek vegyenek részt abban a döntésben, hogy melyik fog végül belépni. Ráadásul ez a döntés nem halasztható végtelenségig.

3. Korlátozott várakozási (bounded waiting) kívánalom: ha egy processz bejelentette igényét a belépésre, de még nem léphet be, korlátozzuk ésszerűen azt, hogy egy másik processz hányszor léphet be. Egy processz se várakozzon a végtelenségig belépésre azért, mert egy másik újból bejelentve az igényét megint megelőzi.

4. Hardver és platform kívánalom: ne legyenek előfeltételeink a hardverre, a processzek számára, relatív sebességükre, az operációs rendszer ütemezésére stb.

Az absztrakt probléma felfogható, mint egy termelő-fogyasztó (producer-consumer) probléma

Vannak termelő folyamatok, melyek terméket állítanak elő és behelyezik egy raktárba.

Vannak fogyasztó folyamatok, melyek a termékeket kiveszik a raktárból és felhasználják.

Van egy korlátozott termék-raktár. A korlátozás vonatkozhat a raktár méretére A korlátozás vonatkozhat a raktár használatára. A korlátozás a raktárhoz való hozzáférésre kölcsönös kizárási probléma.

A termelő-fogyasztó problémának ismertek a változatai.

-22-


10. Kölcsönös kizárási mechanizmus: a szemafor. Dijkstra szemafora, használata klasszikus problémákon. A spinlock szemafor. Szemaforok:

Dijkstra szemaformechanizmusa1965 körül Dijkstra javasolta a szemafor mechanizmust a kölcsönös kizárások megoldására. kifejezést.

A klasszikus szemafor egy pozitív egészt tartalmazó változó és egy hozzá tartozó várakozási sor (melyen processzek blokkolódhatnak).

A szemaforon - kivéve az inicializációját - két operáció hajtható végre. Az operációk atomiak. Ez két dolgot jelent:

Egyik: garantált, hogyha egy operáció elindult, más processz nem férhet a szemaforhoz, míg az operáció be nem fejeződött, vagy a hívója blokkolódott.

Másik: a szemaforra várakozó, blokkolódott processz "felébredve" végre kell tudja hajtani azt az operációt, amelyikre blokkolódott.

A két operáció:

DOWN operáció: ezen blokkolódhat a hívója,UP operáció: ez szignáloz, hogy felébredjen egy blokkolódott

Dijkstra professzor a szemafor megvalósításáról (implementációjáról) nem rendelkezett. Nem mondta ki, hogyan kell megvalósítani a várakozási sort, mit jelent a blokkolódás stb. Így az várakozás lehet tevékeny várakozás is, a szignálozás az ebből való kibillentés (spinlock szemafor), de a várakozás lehet az operációs rendszer által biztosított valódi blokkolódás is (sleep rendszerszolgáltatással), a szignálozás a kernel által biztosított wakeup hívással (blokkoló szemafor).

A Dijkstra féle szemafor úgynevezett számlálós (counting) szemafor, de implementálhatunk bináris szemafort is.

Szemafor implementációk (bináris és számlálós spinlock, blokkoló számláló)

Bináris spinlock szemafor megvalósítás

Ez a szemafor false és true értékeket vehet csak fel, és tevékeny várakozással oldja meg a "blokkolódást". typedef enum{true, false} binaris_szemafor;binaris_szemafor szemafor1;

DOWN( binaris_szemafor szemafor1 ){

while( szemafor1 = = false );

szemafor1 = false;

}

UP( binaris_szemafor szemafor1){

szemafor1 = true;}

-23-

Tevékeny várakozású számlálós szemafor

A számlálós szemafor jól használható szinkronizációra.typedef unsigned szemafor;szemafor szemafor1;DOWN( szemafor szemafor1 ){

while( szemafor1 = = 0 );szemafor1--;

}UP( szemafor szemafor1){

szemafor1++;}Blokkolós számláló szemaforA Dijkstra féle két operációt egy harmadikkal van kiegészítve, az ncount operációval. Ez nagyon hasznos operáció, a szemaforhoz rendelt várakozási soron blokkolt processzek pillanatnyi számát adja vissza.typedef struct{

int ertek;list_of_procs lista;

} szemafor;

szemafor szemafor1;DOWN( szemafor szemafor1 ){

if( --szemafor1.ertek < 0 ){

add a processzt a szemafor1.lista-hoz

blokkolodj, de felébredve folytasd

}szemafor1--;

}

UP( szemafor szemafor1 ){ if( ++szemafor1.ertek < 1 )

{vedd le a processzt a

szemafor1.lista-rólébredj fel

}}int ncount( szemafor szemafor1 ){

if ( szemafor1.ertek < 0 ){ return abs(szemafor1.ertek); }

11. A memória menedzselés feladatai (memória allokálás, címleképzés segítés). Miért lehet szükség címleképzésre?

A memória igen fontos erőforrás. Bár a gépek egyre nagyobb központi memóriával rendelkeznek, a memóriával mindenképp gazdálkodni kell, mert az alkalmazások is egyre nagyobb memóriát igényelnek.

A memória címekkel rendelkező bájtok, szavak készlete. A gépi instrukciók a memóriából vevődnek a programszámláló regiszter (PC) pillanatnyi értéke szerint, másrészt az instrukciók címrésze hivatkozhat a memóriára (az instrukció operandusa a memóriában van). Lássuk be: az instrukciókban a memória cellák címei szerepelnek, és az instrukció "nem tudja", hogyan generálódik az a cím ami végül is a buszra kerül, hogy a memória cella tartalma a processzorba jusson (vagy fordítva).

Programjaink több lépcsőn mennek át fejlesztésük során, ebből következően több címkötődési eset lehetséges. A lépcsők: a fordítás (compilation), a taszképítés (link), a betöltés (load) és a végrehajtás (run), bármelyikben történhet a címkötődés.

Kötődés a fordítás során: abszolút cím generálódik már a tárgymodulokban. Ha itt nincs kötődés, akkor a tárgymodulokban relatív címek generálódnak.

Kötődés a taszképítés során: abszolút címek generálódnak a végrehajtható modulokban, különben azokban relatív címek vannak. Ha relatív címek vannak, akkor a program áthelyezhető (relokálható).

Kötődés a betöltés során: a végrehajtható programfájlban relokálható címek a betöltés során "átíródnak", és abszolút címekké válnak. Ha nincs kötődés a betöltés során, akkor a processz kódszegmensének címei még mindig relatív címek (pl.: virtuális címek).

Kötődés a futás során, dinamikus a kötődés: A processz kódjában az instrukciók ún. logikai címeket tartalmaznak. A logikai cím lehet relatív cím, virtuális cím.

Az instrukciókban szereplő címek készlete a logikai címtartomány. Ez nem feltétlenül folytonos, még ha egy dimenziós is!

A fizikai tárnak is van valós címtartománya. Ez sem folytonos feltétlenül, olyan értelemben, hogy lehetnek olyan címek, amik mögött nincs memória-cella! Ráadásul itt még átfedések is lehetnek: ugyanazon címhez több memória rekesz is tartozhat.

Az operációs rendszerek magjának fontos része a memóriamenedzselő alrendszer, amelyik szorosan együttműködik a hardverrel: az MMU -val (Memory Management Unit).

Különböző memóriamenedzselő sémák lehetségesek, ezek együtt fejlődtek a hardver és szoftver fejlődéssel.

Egyik osztályozás szerint vannak olyam memóriamenedzselő rendszerek, melyek

mozgatják a processzek kontextusát (vagy annak egy részét) a fő memória és a másodlagos memória között: o ki-belapozó rendszerek;

o ki-besöprő rendszerek;

nem mozgatják a kontextusokat.

További osztályozás szerint lehetnek:1. valós címzésű rendszerek, ezen belül

monoprogramozású, multiprogramozású rendszerek, ezen belül

o fix partíciós,o változó partíciós rendszerek;

2. virtuális címzésű rendszerek, ezen belül lapozós (paging) rendszerek, szegmens-leképző, ki-besöprő rendszerek, szegmentáló, ki-besöprő és ugyanakkor lapozó rendszerek.

12. A virtuális memória menedzselés koncepció.A koncepció kialakításának kiváltó oka az volt, hogy egyre nagyobb programokat írtak a programozók, nagyobbakat, mint a rendelkezésre álló fizikai memória. Eleinte a megoldás az átfedés (overlay) technika volt. Átfedésekkel a valós címzésű rendszerekben is lehetett nagy programokat futtatni.

Az overlay lényegeA programokat rendszerint szubrutinokból (eljárásokból, függvényekből) állítjuk össze, és valószínű, hogy egy-egy adott időben nem hívunk meg minden lehetséges rutint. Azaz, előre összeállíthatjuk a rutinok hívási fáját: ezen ágak az egy időben egymást hívó rutinok.

Ma, a virtuális címzések kialakulásával nincs szükség az overlay-ezésre. A koncepció szerint minden processznek igen nagy címtartománya van, a processzhez tartozó memória vagy a központi memóriára, vagy valamilyen másodlagos memóriára, tárterületre van leképezve. A processz szükség esetén bekerül a központi memóriába. Van tehát adatmozgatás a központi memória és a háttértárak között, de ezt a processzek számára a memóriamenedzser biztosítja.

A virtuális címzés koncepció szerint működő rendszerekben a fordító-linker virtuális címeket generál. Az előállítható címek tartománya a virtuális címtartomány: V. Az egyes gépeken a fizikai memória mérete kötött. A fizikai címtartomány az R. Így igaz az, hogy V >>R (V jóval nagyobb, mint R).

A futó processzek szövegében szintén a virtuális címek szerepelnek. Az instrukció végrehajtása során a V-beli virtuális címet le kell képeznie R-beli fizikai címre, és a leképzett cím adható ki a buszra. Ez a címleképzés dinamikus! Fontos, hogy gyors legyen a leképzés, végrehajtásában a memóriamenedzselő kernel szoftvert segíti a hardver: az MMU (Memory Management Modul).

Mivel a V >>R még egy processzre is, ráadásul több processzt is kezelhet a rendszer, előfordulhat, hogy a leképzett R-beli címen éppen nem az adott processz kontextusához tartozó információk vannak. A V-beli címhez tartozó információ ez esetben a másodlagos tárolón van. Gondoskodni kell tehát arról, hogy a másodlagos tárolóról az információ bekerüljön a fő memóriába. Hogy beférjen, esetleg onnan valamit ki is kell írni. Tehát van adatmozgatás is a dinamikus leképzésen kívül.

Két dolog segíti ezt. Az egyik: a programok lokalítása. Nem szükséges, hogy a teljes címtartományhoz tarozó kontextus egy időben benn legyen, akkor is tud futni a processz. A másik: bár a lehetséges címtartomány igen nagy, valójában a processzek virtuális címtartománya ennél kisebb szokott lenni.

13. Lapozós virtuális memória menedzselésben a címleképzés folyamata. A laptábla és szerepe. Laptábla méret kezelés. A lapozó rendszerek (Paging Systems)

A lapozós rendszerekben a virtuális címtartomány "egydimenziós". A V egyforma méretű lapokra (page) van felosztva.

Egy virtuális cím: v =(p,o) formájú, ahol p a lap címe, o (offset) eltolás a lapon belül.

Az R ugyanolyan méretű lapkeretekre (page frame) van felosztva.

A valós cím: r =(p',o) formájú, ahol p'a lapkeret címe/.

Minden processz számára biztosítandó egy laptábla. Ennek kezdő címét a processz dinamikus kontextusában egy regiszter tartalmazza. A laptábla egy-egy bejegyzést tartalmaz egy-egy laphoz: tehát olyan hosszú, hogy a processz minden lapjához lesz egy bejegyzése.

A laptábla egy bejegyzése rögzít: egy jelzést (hogy a laphoz van-e lapkeret rögzítve), védelmi maszkot, módosítás jelzőt, a lapkeret címét.

Laptábla méret kezelés

A laptábla méretét a processz mérete és a lapméret meghatározza. Természetesen írhatnánk kisebb programokat is, de most nem ez a fontos.

A jól megválasztott lapméret természetesen egy jó lehetőség. Sajnos, néha ebben a hardver korlátoz, néha a hardver nem engedi, hogy a rendszergazda nagyobb lapméretet válasszon, ezzel a laptábla méretét csökkentse.

Egy megoldás lehet a többszintű laptáblák alkalmazása.

Képezzük a 32 bites virtuális cím lapcímrészét két 10 bites mezőből, és 12 bites eltolásból. Egy bejegyzésében mutató van a második szintű laptáblák kezdőcímére. A második szintű laptáblákat a p2 cím-mező indexeli: a p2 és az első szintű laptábla pointerének összege a második szintű laptábla egy bejegyzésére mutat. A második szintű laptáblák bejegyzéseiben vannak a lapkeret címek: ezek összeadva az eredeti virtuális cím 12 bites offset mezejével a valós címet adják.

Másik megoldás az invertált laptáblák alkalmazása a laptábla-méret csökkentésére.

Az elgondolás az, hogy a címzés bitszélesség növekedésével nem tud versenyt tartani a laptábla csökkentés, hiszen már vannak 64 bites címszélességű, sőt, 128 bites címszélességű rendszerek. A fizikai memória mérete viszont nem növekszik ilyen gyorsan (sajnos), ezért jobb kiindulni a lapkertektől.

Az invertált laptáblákban lapkeretenként vannak bejegyzések: méretük akkora, hogy minden lapkeretnek legyen egy bejegyzése.

14. A laphiba és kezelése. A laphiba gyakoriság és szerepe a munkakészlet modellben. Lehetséges kilapozási

stratégiák.A laphiba (Page Fault)A dinamikus címleképzés során a laptábla p-edik bejegyzésében a valid/present-absent bit azt jelzi, hogy a kérdéses laphoz nincs lapkeret hozzárendelve, azaz kivételes esemény, laphiba következik be.

A laphiba lekezelő rutin a másodlagos tárolóról "belapozza" (paging in) a kérdéses lapot. Ehhez keres egy szabad lapkeretet, és oda lapozza be. Ha nem talál szabad lapkeretet, akkor kiválaszt valamilyen, különben érvényes lapkeretet, az kilapozza és a felszabadult lapkeretbe most már belapozhatja a lapot, egyben érvényessé is teszi. A laphiba kezelő ezután visszatérhet: a laphibát okozó instrukció most újból végrehajtva már hiba nélkül leképezheti a címet.

Kilapozási algoritmusok (Page Replacement Algorithms)

Tulajdonképpen két problémával kellene foglalkozni:

meg lehetne-e mondani előre, mely lapokra lesz a közeljövőben szükség;

mely lapokat lapozzuk ki, ha a lapkeretek "elfogytak".

Sajnos, az első probléma megoldhatatlan. Voltak ugyan kísérletek, de használható megoldás nem születhetett. Általános célú rendszereknél az optimálás teljesség lehetetlen. A probléma megoldását hagyták az igény szerinti lapozási, majd a munkakészlet koncepció stratégiákra.Azon viszont érdemes gondolkodni, mik legyenek a kilapozandó lapkertek. Azok a lapok, melyek nem írhatók, vagy ha írhatók is, nem módosítottak, kezelhetők külön a kilapozás során. Ezeket valójában nem szükséges kilapozni, mert tartalmuk nem változott, elegendő őket "elereszteni".

A FIFO kilapozási algoritmus

A belapozási sorrend a meghatározó; minél régebben lapoztak be egy lapot, annál esélyesebb a kilapozásra. Az operációs rendszer ehhez az algoritmushoz a lapokat láncolt listán tartja, a lista elején a régebben belapozott lapokat, a végén a legfrissebben belapozott lapot. Kilapozni mindig a lista elejéről választ lapot. A mögöttes elgondolás az, hogy a "régi" lapokra már nincs szükség.Amellett, hogy a listatárolás elég erőforrás-igényes, az elgondolás is téves. Egyáltalán nem biztos az, hogy a régen belapozott lapra nincs a következőkben szükség.

Második esélyes FIFO

Tartsuk a lapokat körkörösen láncolt listán, az egyszerű soros lista helyett, és tartsunk nyilván a lapokra egy hivatkozás bitet, valamint egy "óramutatót", ami a listán körbejárhat.A hivatkozás bit billen, ha tényleges hivatkozás volt a lapra. Amikor kilapozásra van szükség, vizsgáljuk azt a lapot, amire a körkörös listán az óramutató éppen mutat. Ha ennek a lapnak a hivatkozás bitje bebillentett állapotú, ne lapozzuk ki, hanem töröljük a hivatkozás bitjét. Ezzel tulajdonképpen adtunk neki egy második esélyt: ha az óramutató a körön körbejárva újra rámutat, és közben nem volt hivatkozás a lapra, akkor ki fog lapozódni. Ha a mutatott lap hivatkozás bitje törölt, akkor viszont ki fog lapozódni. Az óramutató mindenképp továbblép a körön.

Mostanában nem használatos lapok (Not Recently Used pages) NRU (Least Recently Used) LRU

A programok lokalitásának elvéből kiindulva azok a lapok lehetnek kilapozásra esélyesek, melyeket mostanában nem használtak. Valamilyen módon nyilván kell tartani, hogy mikor használták legutóbb a lapot. Azt rögzítjük tehát, hogy mikor hivatkoztak rá, esetleg azt is, mikor módosítottak a lapon legutóbb. Az NRU lapok kilapozódhatnak, az LRU lapok lehetőleg nem: az NRU és LRU algoritmusok igen közeli rokonok, majdhogynem ugyanazok.

Nem egyszerű és nem is olcsó a megvalósítás! Minden lap használatának (és módosításának) időbélyege tárterület-igényes, a "rendezés", vagyis a régen használt lapok kikeresése nem könnyű!

Az igazi megoldáshoz kétszeresen láncolt listán tartják nyilván a lapokat, a lista elején a legutóbb használtat. A lista végéről lapoznak ki szükség esetén. A lista közepén szereplő lapot, ha hivatkoznak rá, mozdítani kell a lista elejére.

Mostanában legkevésbé használt (Least Frequently Used) LFU algoritmus (Not Frequently Used) NFU

Az alapgondolat: az utóbbi időkben gyakrabban használt lapoknak legyen nagyobb esélyük a bennmaradásra. Nem a lapok hivatkozási ideje, sorrendje, hanem a hivatkozási frekvencia a rendezőelv. Nagyon jó a gondolat, csak elég drága lehet a megvalósítása. Lehetne pl.: láncolt listán tartani a lapokat, elején azt, amire leggyakrabban hivatkoztak, de nagyon időigényes volna a lista karbantartása!

Más megoldás is szóba jöhet persze, pl.: minden lapra nyilvántartunk egy számlálómezőt, amit növelünk, ha a lapra hivatkozás történt. A kilapozásra esélyesek azok a lapok, melyeknél a számlálómező kicsi.

Rögtön jelentkezik két gond:

Egyik: elég nagy számlálómezőt kell biztosítani.

A másik a processzek időszerűségének változásával függ össze: lehetnek lapok, melyeket gyakran használtunk a múltban, mostanában viszont nem használatosak. Amíg a többi lap számlálója "felnövekszik" erre a szintre, addig nem tudnak becsületesen versenyezni! Ha kilapozódnak, belapozódnak, újra kezdik a számlálást. Lehetnek anomáliák ebből.

A tiszta LFU, NFU ezért nem is használatos.

A számlálómezős megoldást lehet azonban alkalmazni, ha ráteszünk még egy "öregedés" (aging) algoritmust. Növekszik a számlálómező minden laphivatkozással, az óraintervallumokban azonban célszerű aging konstanssal beszorozva öregbítjük. Így az időszerűségüket elvesztő lapok számlálómezeje csökken, esélyt adva a frissebb lapoknak a versenyre.

15. Eszköz driver-ek funkciói, felépítésük. Eszköz osztályok.

Az eszközök a buszra csatlakozó

vezérlőből, és az ezekhez csatlakozó

fizikai eszközökből állnak.

Ezekkel a device driver-eknek és bennük az interrupt handler-eknek van közvetlen kapcsolatuk.

Az eszközöket csoportosítása, osztályozása

Karakterorientált, vagy más néven strukturálatlan eszközök. Ilyenek a terminálok, soros vonalak, nyomtató portok, analog/digital átalakítók stb. Strukturálatlannak mondjuk ezeket, ami tulajdonképpen azt jelenti, hogy ezek az eszközök képesek fogadni/adni egy strukturálatlan karakter/bájt sorozatot.

Blokkorientált, vagy strukturált eszközök képezik. Tipikus példájuk a diszk eszközök. Mit jelent itt a blokkorientáltság? Az ilyen eszközöknél blokknyi egységekben történik az adattovábbítás, blokk egységben történik az adatrögzítés. Egy-egy blokk feldolgozása "random" jellegű is lehet. Minden blokknak van címe. Ez adja a blokk-struktúrát, ezért mondjuk ezeket strukturált eszközöknek.

Az eszközmeghajtók (Device drivers)

Az I/O alrendszer legalsó részét, az eszköz drivereket egy rutinkészlet, táblázatok és pufferek alkotják. Mivel a kernel részei: a rendszer címtartományához tartoznak.

Legfontosabb feladatuk az adatmozgatás a központi memória és a vezérlő buffere között, továbbá parancskiadás a kontroller számára, hogy az működjön. További fontos feladatuk olyan események kezelése, melyeket egy-egy kontroller kelt, amivel jelzi, hogy kész van a kapott feladatával. Az eszköz driver-ek rutingyűjteményt képeznek, jól meghatározott struktúrával.

Alapvetően három részből állnak

1. Autókonfigurációs és inicializáló rutinokból, melyek egyszer hívódnak, a driver

2. betöltésekor, indulásakor. Felülről, call jelleggel hívódnak

3. Második rutincsoportot az I/O kérelmeket kiszolgáló rutinok alkotják. Felülről, call jelleggel hívódnak 3. A harmadik csoportot a megszakítás kiszolgáló rutinok alkotják, Ezek "alulról" hívódnak, aszinkron módon.(Ezek az alsó réteghez tartoznak).

Az OS I/O alrendszere tehát feltétlenül tartalmaz device-driver komponenseket, minden konkrét eszközfajtához saját drivert. A rendszergazdáknak kell gondoskodnia arról, hogy minden konkrét eszköznek meglegyen a drivere, mindegyik inicializálódjon a normál használat előtt.

16. Fájlrendszer megvalósítási feladatok. Jegyzékszerkezetek. Szabad blokk menedzselési

lehetőségek. Fájl attribútum rögzítési lehetőségek (ezen belül fájl testet képező blokkok rögzítési lehetőségei).

Blokk-strukturált eszközökre (logikai diszkekre - partíciókra) szervezhetünk fájlrendszer-t.

Tulajdonképpen három dolgot kell megoldani

hogyan rögzítsük, hogy egy adott fájlhoz mely blokkok és milyen sorrendben tartoznak,

hogyan tartsuk nyilván a logikai diszken a szabad blokkokat, hogyan keressünk ezekből, ha foglalni akarunk, vagyis hogyan menedzseljük a blokkokat a partíción,

végül, hogyan rögzítsük a fájl-attribútumokat, főképpen milyen legyen a jegyzék szerkezet.

A fájl: valamilyen szempontból összetartozó adatok névvel ellátva. Vannak névkonvenciók.Fájl struktúrák, fájl-organizáció

Három általános struktúra lehetséges:

A fájl bájtok sora. Tulajdonképpen nincs strukturáltság, illetve a processzek strukturálhatnak, ha akarnak.

A fájl rekordok sora. A rekordok lehetnek állandó, vagy változó hosszúságúak, ezen belül ún. blokkoltak. A rekord-strukturáltság a diszken, partíción, szalagon rögzített, nem a processzek strukturálnak, hanem az OS I/O alrendszere.

Indexelt szervezésű rekordokból áll a fájl. A rekordok nem feltétlenül egyforma hosszúságúak, van bennük egy vagy több kulcsmező -rögzített pozíción -, amik segítségével gyors kikeresésük lehetséges.

Unix-ban az első, MS-DOS-ban az első és a második, VAX/VMS alatt mindhárom organizáció lehetséges.

A fájl elérések: Általánosan kétféle lehet

szekvenciális vagyis soros elérés, ami mindhárom organizációnál lehetséges. Ez tulajdonképpen azt jelenti, hogy ha egy bájtot, vagy rekordot el akarunk érni, az előtte álló bájtokat, rekordokat végig kell olvasni, vagy legalább is át kell lépni.

Random, vagyis véletlenszerű elérés, ami azt jelenti, hogy egy byte vagy rekord elérése független a többi bájttól, rekordtól. A Unix ezt a seek rendszerhívással biztosítja. Más operációs rendszerek a fix hosszúságú szekvenciálisan szervezett rekordokhoz, ill. az indexelt szervezésű rekordokhoz a közvetlen -random- elérést biztosítják.

Fájl típusok

Osztályozhatjuk a fájlokat a tartalmuk szerint is. Így lehetnek:

közönséges (regular) fájlok, amik tovább is osztályozhatók (text fájlok, binary fájlok stb.)

jegyzékek (directories), amik bejegyzéseket tartalmaznak további fájlokról.

bizonyos operációs rendszerekben FIFO jellegű fájlok, mailbox-ok,

a Unix-ban ún. speciális fájlok, amik tulajdonképpen eszközöket azonosítanak.

könyvtárak (libraries), melyek tagokat (members) tartalmaznak, amik maguk lehetnek szövegek, tárgy-modulok, végrehajtható programok stb.

Fájl attribútumokA fájloknak nemcsak nevük és adataik vannak, hanem további kapcsolódó információik: pl.: készítési dátumuk, utolsó módosítási vagy elérési dátumuk, tulajdonosuk, csoporttulajdonosuk, védelmi maszkjuk, írás/olvasási engedélyük stb. is jellemzik őket. Ezeket nevezhetjük az attribútumaiknak.

Jegyzék implementációk

A jegyzék maga is egy fájl, ami bejegyzéseket tartalmaz más fájlokról. A bejegyzésekben a fájlok attribútumait tárolhatjuk.

Miután a jegyzék is fájl, blokkok tartoznak hozzá is. Blokkjain belül vannak a bejegyzések, ezek lehetnek állandó, vagy változó hosszúságúak, az implementációtól függően. A bejegyzésekben az attribútumok között a legfontosabb a fájlnév. Sokszor van keresés a név alapján. A bejegyzések struktúrája befolyásolja a keresést. Ez lehet:

lineáris,o nem rendezett bejegyzéseken, amik között nem foglalt bejegyzések is lehetnek

(a törölt fájlokra);o rendezett, "hézagok" nélküli bejegyzéseken, ahol is gyorsabb keresési

módszerek is megvalósíthatók; hash táblás: a szokásos szekvenciális bejegyzések mellett egy hash táblát is

implementálnak, ami a gyorsabb keresést segíti.

A szabad diszkterület menedzselési lehetőségei

A fájlrendszer implementációkat tervezők másik gondja, hogyan menedzseljék a szabad diszkterületet, hogyan tartsák nyilván a szabad és a foglalt blokkokat, hogyan igényelhet rendszerhívás blokkokat, fájltörlésnél hogyan adható vissza blokk a szabad blokkok mezejébe.Alapvetően két megoldás szokásos!

Bit vagy mező térkép a szabad, illetve foglalt blokkokrólA partíció meghatározott (konvencionális helyén található) területe a bit/mező térkép. Bit/mező bejegyzések vannak a térképen, éppen annyi, ahány blokk található a partíción. Egy az egy megfeleltetés van a bitek/mezők és a diszk blokkjai között: az i-edik blokkhoz az i-edik bit/mező tartozik. A szabadság vagy foglaltság jelzésére a megfelelő bit 0 vagy 1 értékű, a megfelelő mező 0, vagy a foglaltságot jelző egész bejegyzésű. A bit-térkép -gyorsítási célokból- in-core memória másolattal kezelhető. Nagy diszkeken egy-egy bithez/mezőhöz cluster rendelhető. Gyakorlatilag ezt a módszert használja a VAX/VMS, a HPFS, az NTFS és az MS-DOS FAT fájlrendszere is.

Láncolt lista a szabad blokkokrólFix helyen lévő blokk tartalmaz bejegyzéseket szabad blokkokról, annyiról, amennyit képes egy blokk nyilvántartani, továbbá ugyanez a blokk egy következő blokk pointerét is tartalmazza, ami további szabadblokkokat tart nyilván és így tovább. Gyakorlatilag ezt a módszert használja a Unix, azzal a kiegészítéssel, hogy maguk a szabad blokkok használatosak a láncolt lista tárolására.

Fájlokhoz való blokk-hozzárendelési technikák

Folyamatos allokáció

Egyszerű séma, egymás utáni blokkokat foglalunk a fájl számára, annyit, amennyit az el fog foglalni. A fájl tartalom keresése során csak a kezdő blokk címét kell megadni pl.: a fájl nevét tartalmazó jegyzékben. Nyilvántartják ilyenkor a hosszat, vagyis az utolsó blokk címét is.Gond: fájl allokáció során elegendő összefüggő területet kell találni, fregmentálódik a diszk (compaction kell, a gap-ek nem használhatók ki), nehézkes a hozzáfűzés (append). Korszerű operációs rendszerekben nem használják már.

Láncolt lista allokáció

Minden fájl "tartalma" a diszk blokkok láncolt listája. Így nem lesz fregmentáció. A fájl nevét tartalmazó jegyzék bejegyzésébe az első blokk mutatója, esetleg a fájl hossza bejegyzendő, az első blokkban megtalálható a következő blokk címe (mutatója) és így tovább, az utolsó blokkban a mutató NULL pointerként jelzi, hogy nincs tovább.Gond: soros olvasás még elfogadható, de random keresés nagyon lassú lehet, mert mindenképp végig kell menni a láncolt listán. Másrészt a blokkokból elvesznek egy kicsit a pointerek, márpedig mi szeretjük a kettő hatványai méretű adat blokkokat.Nem szokásos ez a módszer.

Láncolt lista allokáció index-táblával

Emeljük ki a blokk-mutatókat egy indextábla mezőibe. Az indextábla a partíció kötött (megegyezés szerinti) helyén található tábla, annyi bejegyzéssel, ahány blokk van a partíción. Egy az egy megfeleltetés van a táblamezők (pointermezők) és a blokkok között: az i-edik táblabejegyzés az i-edik blokkhoz tartozik. Ha egy fájl kezdődik az i. blokkon, folytatódik a j.,k.stb. blokkokon, akkor: a jegyzékben a neve mellett szerepeljen i, az i. pointermezőben szerepeljen j, a j. pointermezőben a k, stb.Az indextábla egy bejegyzése (pl.: az i. mezőbe írt j érték) kettős információt hordoz:

maga az index (i) azt mondja, hogy az i-edik blokk a fájl blokkja. a mező tartalom (a k) pedig azt mondja, hogy a soron következő blokk a k-

adik blokk.Jó, ha az indextábla egészéről, vagy legalább részletéről in-core másolat van a memóriában (gyorsítás).Tulajdonképpen az MS-DOS és végső soron a VAX/VMS is ezt a módszert használja. Gond: nagy blokkszámú diszkek igen nagy indextáblát igényelnek. Javítható ez, ha néhány blokkot csoportba (ún. cluster-ba) foglalunk, és a cluster-ek láncolt listájával dolgozunk. Ilyenkor persze romlik a diszk blokkok kihasználtsága, mivel nem valószínű, hogy a fájljaink mérete cluster-ek szorzata.

I-bögök, f-bögök alkalmazása

A Unix fájlrendszer tervezésénél kialakított koncepció szerint minden fájlhoz tartozik egy bög (node), egy adatstruktúra, ami a különböző fájl attribútumok mellett a fájl egymás utáni blokkjainak elhelyezkedését is rögzíti. A Unix i-bögök a partíció meghatározott helyén találhatók, együttesen alkotják az i-listát. A jegyzék bejegyzésben megadva az i-bög indexét (az i indexet) megragadható az i-bög, ezzel az egész fájl. Más operációs rendszerekben kissé hasonló koncepcióval f-bögök segítségével kezelhetők a fájlok blokkjai (HPFS és NTFS fájlrendszerek).

OBJEKTUM ORIENTÁLT PROGRAMOZÁSJAVA NYELVEN

vizsgatételek

1. Az objektumorientált programozás szemlélete, az objektum fogalma2. Az objektumorientált programozás alapelvei3. A Java nyelv története, alapvető tulajdonságai4. Mi kell egy Java program fejlesztéséhez, illetve kész program futtatásához?5. A Java program (alkalmazás), a Java applet és a JavaScript fogalma6. A Java alapelemei: karakterkészlet, azonosító, megjegyzés, egyszerű típusok7. A Java alapelemei: lokális változó, tömb, vezérlő utasítások8. Osztálydefiníció, adattag, metódus fogalma. Példányosítás9. Hivatkozás típusú változó (referencia) fogalma, az egyszerű típusú és az osztály

típusú változók közötti különbség. Hivatkozás objektum elemeire.10. Hozzáférési kategóriák és jelentésük. Használatukra vonatkozó konvenciók.11. A this pszeudó változó és szerepe12. Metódusnév túlterhelés (overloading)13. Konstruktor fogalma, definíciójának és használatának szabályai. Az implicit

konstruktor.14. Objektumok megszűnése. A szemétgyűjtő mechanizmus, A finalize metódus.15. Java csomagok és fordítási egységek. Minősített (teljes) hivatkozás. Az import

direktíva.16. Osztályváltozó és osztálymetódus17. A final minősítésű adattag és metódusok18. Az öröklődés fogalma, szintaktikai szabályai. Statikus és dinamikus típus

fogalma.19. Konstruktorok az öröklődés során20. Felüldefiniált metódusok: a definiálásra és a hívásra vonatkozó szabályok.

Használatának célja.21. Absztrakt metódus és absztrakt osztály22. A Java interface fogalma, a definíció szintaktikája. Interface implementálása.23. A kivétel fogalma és a kivételkezelés utasításai a Java nyelvben. Kivétel

keletkezése.24. Kivétel elkapása és lekezelése. A finally blokk szerepe25. Előre definiált és saját kivétel osztályok26. Az ellenőrzött és nem ellenőrzött kivétel fogalma. Kivételek specifikálása27. Beágyazott osztályok28. Az osztály interface fogalma és a jól tervezett osztály interface jellemzői29. Az általánosítás/pontosítás (is-a) és a tartalmazás (has-a) kapcsolat

implementálási lehetőségei a Java nyelvi eszközökkel.

1. TÉTELAz objektumorientált programozás szemlélete, az objektum fogalma

OOP szemlélete: a programkészítés egy absztrakciós folyamat, amelyben a valós világban létező jelenséget valamilyen programozási eszköz absztrakciós szintjén képezünk le.A munka nehézsége függ:

A leképezendő jelenség/folyamat bonyolultságától A valóság és a programozási eszköz absztrakciós szintjének különbözőségétől A programozás egy másik megközelítése a program, amely a valós világ egy

szeletének működő modellje. Ebben a szemléletben a valós világ egy absztrakt modelljét kell leképezni egy programozási eszközre. Ezt a folyamatot megkönnyíti, ha az analízis modell elemei könnyen leképezhetők nyelvi elemekre. Az analízis modell elkészítése során a valóságot objektumok halmazaként tekintjük. Ezen objektumok egymással kapcsolatban vannak és együttműködnek.

Az objektum: egyediséggel rendelkező diszkrét entitás.Jellemzők:

Attribútum: objektum állapot, ennek időbeli változása az objektum viselkedése Műveletek: ezek modellezik az objektum viselkedését.

Objektumtól objektumig1. szint: Tanulmányozzuk a valós objektumokat és megkeressük azoknak a probléma megoldása szempontjából fontos adatait és viselkedésmintáit. Ezután megkeressük azon objektumcsoportokat, amelyek azonos adatokkal és viselkedésmintákkal rendelkeznek, és elnevezzük ezt a csoportot.2. szint: Az előzőleg definiált fogalom leképezése egy programozási eszközre. Ez valójában egy minta a program működéséhez szükséges objektumok létrehozására.3. szint: Akkor és annyi objektumot kell létrehozni a program futása során, amelyek együttműködve képesek a valóságot modellezni.

2. TÉTELAz objektumorientált programozás alapelvei

Az objektumorientált programozás alapelvei:1. Osztály2. Objektum3. Egységbezárás4. Információ rejtés5. Üzenet6. Öröklődés7. Polimorfizmus

Osztály: amelynek részei az adatok (az attribútumok modellezésére) és a módszerek (a műveletek modellezésére). Objektumok közös tulajdonságait definiálja. Programozás technika szempontból egy típus.Objektum: Egy osztály egy működőképes példánya. Egy adott osztályban definiált tulajdonságokkal tetszőleges számú objektum példányosítható. Minden objektum természeténél foga különbözik az összes többitől. Egy adott osztályból példányosított valamennyi objektumnak ugyanolyan lehetséges viselkedés módjai vannak, de saját állapotuk van.Egységbezárás: Az osztály az adatait és a módszereket egy egységgé teszi. Az adatok lokálisak, a módszerek hozzáférhetnek az adatokhoz.Információ rejtés: Egy objektum adatait a külvilág számára hozzáférhetetlenek. Egy objektum a külvilággal csak az interface-én keresztül tarthatja a kapcsolatot. (Interface: a külvilág számára elérhető módszerek együttese.) A módszerek implementációja rejtett.Üzenet: Az objektummal való kommunikáció módja. A módszerek aktivizálását jelenti.Öröklődés: Hierarchikus kapcsolat. A leszármazott osztály örökli az ősosztály adatait és módszereit. Az öröklött módszereket felüldefiniálhatja a maga számára. Új adatokat és módszereket definiálhat. Egy leszármazott osztály csak bővítheti, pontosíthatja az őst, de nem utasíthat el örökölt adatokat vagy módszereket.Polimorfizmus(többalakúság): Bizonyos elemek viselkedése attól a környezettől függ, amelyben alkalmazzuk. A gyakorlatban ez azt jelenti, hogy egy nyelvi elem attúl függően, hogy hol alkalmazzuk, más-más működést eredményezhet.

3. TÉTELA Java nyelv története, alapvető tulajdonságai

Történet:1990-es évek eleje:A SUN belső projectje James Gosling vezetésével -> platform-független technológia szükségessége. Egyik akkora nyelv sem volt megfelelő, ezért terveztek egy újat. A projekt aztán lassan elhalt,1990-es évek közepe: az Internet rohamos terjedése újra felvetette a platform-független technológia szükségességét. Újraéledt a project, de általánosabb célkitűzéssel. Eredménye a Java nyelv első verziója lett.1995: Java 1 platform1999: Java 2 platformJelenleg J2SE 1.6 (Java 6 platform)A Java egyszerre programozási nyelv és platform.

Alapvető tulajdonságok: Magas szintű programozási nyelv Platform-független Általános célú Teljesen objektumorientált Egyszerű Interpretált (de speciális módon) Elosztott Robosztus (nem okoz kárt figyelmetlenségi hiba esetén) Biztonságos Hordozható Többszálú A C++ ismeretében született, annak formalizmusát tekintette mintának A C++ hátrányait igyekezett kiküszöbölni

4. TÉTELMi kell egy Java program fejlesztéséhez, illetve kész program futtatásához?

Valamennyi Java szabvány, és a SUN által implementált alapvető fejlesztőeszközök nyílt forrásúak és ingyenesek. Ezen kívül számtalan nyílt forrású, ingyenes; zárt forrású, de ingyenes; kereskedelmi termék kaphatóA minimális fejlesztőkörnyezet:

J2SDk vagy újabban JDK(Java Development Kit) Tetszőleges szövegszerkesztő

Kényelmesebb fejlesztő környezetek: NetBeans Eclipse Mindkét fejlesztőeszköz maga is Java-ban íródott, tehát sokféle platformon futtatható.

JDK legfontosabb elemei: A Java API-t implementáló könyvtárak Ségedprogramok:

Javac: java fordító Java: a JVM (futtatáshoz) Javadoc: automatikus dokumentáció generáláshoz a forrás szöveg és a benne

található speciális kommentek alapján Jdb: debugger

Minimális futtató környezet:JRE (Java Runtime Environment)Ha egy gépen csak JRE van, bármely más gépen fejlesztett Java program futtatható, ha ugyanolyan vagy korábbi verziójú JDK segítségével készült.

5. TÉTELA Java program (alkalmazás), a Java applet és a JavaScript fogalma

Java program: Java-fordítóval készült önálló alkalmazás. Az adott architektúrán futó JVm hajtja végre. Mindazon jogokkal rendelkezik, mint bármely más alkalmazás.A java program osztályok halmaza. Végrehajtható kód csak osztály metódusában fordulhat elő. Egy alkalmazás belépési pontja egy olyan osztály, amelyben van egy public static minősítésű main nevű metódus.Applet: HTML oldalból elérhető, végrehajtható bít kód, ami Java forrásból készült. A HTML kódba csak egy hivatkozás kerül, az applet maga bárhonnan letöltődhet. A HTML oldal ételmezője hajtja végre (a böngésző valósítja meg a JVM-et). Korlátozott jogokkal rendelkezik biztonsági okok miatt.JavaScript: Eredetileg LiveScript néven a Netscape-nél kifejlesztett script nyelv (tehát nem bináris kód). Célja weboldalak dinamikussá tétele. A (szöveges) kód része a HTML oldalnak. A Java-hoz hasonló C++ szintakszisához hasoló formalizmus. Nem objektumorientált, csak objektum alapú. Bár ezt is a böngésző értelmezi, semmi köze a Java-platformhoz.

6. TÉTELA Java alapelemei: karakterkészlet, azonosító, megjegyzés, egyszerű típusok

A Java az Unicode karakterkészletet használja, tehát akár ékezetes azonosítókat is használhatunk.Azonosító: betűvel kezdődő és betűvel vagy számmal folytatódó karaktersorozat

Az _ és a $ is a betűk közé sorolandó A betűk bármely karakterkészletből származhatnak Az azonosító hossza tetszőleges A Java a kis- és nagybetű érzékeny Kulcsszavak, valamint a const, goto, null, true, false savak nem lehetnek azonosítók

Megjegyzések:1. Mint a C-ben:

/* valami*/2. Egysoros:

// sor végéig komment3. Dokumentációs:

/** tetszőleges szöveg*/Egyszerű típusok:Hasonlóak, mint a C-ben, de pontosan definiált helyfoglalással és ábrázolási móddal. Nincs unsigned minősítő. Konstans változó final minősítővel deklarálható.típusnév Jelentésboolean Logikai típus (true vagy false értékkel)char 16 bites Unicode karakterbyte 8 bites előjeles egészshort 16 bites előjeles egészint 32 bites előjeles egészlong 64 bites előjeles egészfloat 32 bites lebegőpontos szám (IEEE 754 szerint)double 64 bites lebegőpontos szám (IEEE 754 szerint)

Konstansok (literálok):Logikai értékek: true vagy falseA C-vel teljesen egyező módon használandók:

Egész konstans Lebegőpontos konstans Karakter konstans Szöveg konstans

A szöveg konstanst a fordító automatikusan String típusként kezeli.

7. TÉTELA Java alapelemei: lokális változó, tömb, vezérlő utasítások

Lokális változók: definíciója csak metóduson belül. Nincs globális változó! Formája mint a C-ben, beleértve a kezdő értékadást is. Egyszerű típusú lokális változó definíciója egyben helyfoglalást is jelent. Változó definíciója egy metóduson belül bárhol lehet. Természetesen a változó csak a definíció után használható.

Egydimenziós tömb:Definíciója1. Tömb típus deklarációja

Típusnév azonosító[]; vagy típusnév[] azonosító;2. Helyfoglalás a tömb elemeinek:

Azonosító = new típusnév[elemek száma]A két lépés egy utasításban összevonva:

Típusnév azonosító[] = new típusnév[elemek száma]Az elemekre való hivatkozás már ugyanaz, mint a C-ben. A Java-ban többdimenziós tömbök is definiálhatók, amelyek nem feltétlenül négyzetesek. Bár nincs előre definiált osztálya, de osztályhoz tartozóként kezeli a Java. Minden tömbhöz tartozik egy length konstans, amely az elemek számát adja meg. Használata: azonosító.lengthOperátorokA C majdnem minden operátorát ismeri a Java (kiv mutatókhoz kapcsolódó) Az operátorok jelentése az egyszerű típusokra ugyanaz. Különbségek:

Négy új operátor (>>>, >>>=, instanceof, new) Nincs vessző operátor

A kifejezések kiértékelési sorrendje meghatározott. Kifejezések kiértékelődési sorrendje: Zárójelezés Operandusok prioritása Azonos prioritás esetén balról-jobbra szabály, kivétel az értékadás, amely jobbról-

balra értékelődik ki.A kifejezésekben a metódushívások sorrendje is a kiértékelés sorrendét követi.Utasítás, blokkUtasítás lehet: kifejezés utasítás, deklarációs utasítás. Az utasításokat pontosvessző zárja.Kifejezés utasítás csak a következő lehet:

Értékadás ++ és – operátorokkal képzett kifejezések Metódushívás Példányosítás

A deklarációs és kifejezés utasítások tetszőleges sorrendben követhetik egymást. Az utasítások sorozata {} jelek közé zárva a blokk. Utasítás helyére mindig írható blokk.Vezérlő utasítások:Lényegében megegyeznek a C utasításaival.Különbségek:

Az if, while, do utasításokban a feltétel csak logikai kifejezés lehet. A for utasításban a második kifejezés csak logikai kifejezés lehet A switch utasításban a szelektor csak egész kifejezés lehet Nincs goto utasítás

8. TÉTELOsztálydefiníció, adattag, metódus fogalma. Példányosítás

Osztálydefiníció: az Java program osztályok halmaza. Egy osztálydefiníció egyben egy teljes fordítási egység (de általában nem teljes program). Az osztály és a definícióját tartalmazó file neve meg kell egyezzen. Osztályok csomagokba rendezhetők, ezzel lehet modulokat képezni. Egy csomag tetszőleges számú osztályt tartalmazhat, de egy osztály csak egy csomagban lehet. Az osztálydefiníció fejlécből és a {} zárójelpárral határolt törzsből áll.A fejléc formája: [módosítók] class osztályneve [egyebek]Az osztály neve egy azonosító. A törzsben adattagok és metódusok és további elemek definíciói állhatnak.Adattagok:Definíciója: [módosítók] típusnév azonosítólistaA típusnév valamelyik egyszerű típus, tömb típus, vagy osztálynév lehet. A névlista elemeit vesszővel választjuk el. Formájuk: azonosító[=inicializáló kifejezés].Az inicializáló kifejezésben csak előtte már deklarált adattagok használhatók. Az inicializáló kifejezés minden példányosítás esetén kiértékelődik. Nem inicializált adattag az alábbi default értékkel inicializálódik:

Boolean: false Char: ’\0000’ Minden egész típus: 0 Minden lebegőpontos típus: 0.0 Osztály típus: null

Metódusok:Formája: [módosítók] típus név(paraméterlista) […]A metódus osztályon belül definiált függvény. Osztályon kívül definiált függvény nincs.Osztály hatáskör: Az egységbe zárás alapelvének implementálása: minden osztály saját hatáskörrel rendelkezik. Egy osztály minden eleme tehát lokális az osztályra nézve. Következmények:

Különböző osztályokban használhatjuk ugyanazt az azonosítót eltérő értelemben Az osztályon belül az elemek egymásra nevükkel hivatkozhatnak A metódusok használhatják az adattagokat és a többi metódust.

Példányosítás: az osztály objektumok létrehozásához használható mintaként tekinthető. A Java programban az osztálynév típusként használható. Az objektum létrehozásának folyamata a példányosítás. Egy osztályból tetszőleges számú objektum példányosítható. A legegyszerűbb mód egy osztály típusú változó definiálása: Formája:[módosítók] osztálynév azonosító = new osztálynév([paraméterek])A () zárójelpár a paraméterek hiányában is kötelezőA folyamat:

Lefoglalódik az objektumnak szükséges hely Inicializálódik az objektum A lefoglalt memóriaterületre való hivatkozás kerül a változóba

9. TÉTELHivatkozás típusú változó (referencia) fogalma, az egyszerű típusú és az osztály

típusú változók közötti különbség. Hivatkozás objektum elemeire.

Hivatkozás: a Java-ban kulcsfontosságú fogalom. Osztály típusú változó mindig hivatkozás, nem objektum!Hivatkozás típusú változó:

Értéke cím, amely egy objektumot címez meg, vagy null Használata indirekció nélkül magát az objektumot jelenti a kifejezésekben Az értéke a programozó számára hozzáférhetetlen

Következmény: objektum csak futás közben, dinamikusan hozható létre.Hivatkozással végezhető műveletek:

Definíció Értékének beállítása objektum létrehozásával Értékadás hivatkozások között Értékének beállítása a null konstansra Két hivatkozás összehasonlítása ( a == művelettel) Használható objektum elemére való hivatkozásban

Egyszerű típusú változó: a deklarációja egyben definíció is, hely foglalódik a memóriában, és a továbbiakban a változó az ott tárolt értéket képviseli.Osztály típusú változó: deklarációja hatására csak egy cím számára foglalódik memória. Ezt a címet egy példányosított objektum címére kell beállítani. Ezután a változó az általa hivatkozott objektumot fogja képviselniObjektum elemeire való hivatkozás: Osztályon belül névvel. Minden más esetben az objektum nevével minősítve a . (pont) operátorral. Metódusra való hivatkozásnál aktuális paramétereket is kell adni, és a hivatkozás a metódus aktivizálását jelenti.

10. TÉTELHozzáférési kategóriák és jelentésük. Használatukra vonatkozó konvenciók.

A [módosítók] szintaktikai elem egyik feladata a hozzáférési kategóriák megadása

módosító Hozzáférési kategóriaNincs Félnyilvános: csak az azonos csomagban

levő osztályok érthetik elpublic Nyilvános, bármely csomagban lévő bármely

osztályból elérhetőprivate Privát: más osztályból nem, de az adott

osztály összes példánya számára elérhetőprotected A félnyilvános kategória kiterjesztése. Az

azonos csomagban levő osztályok, egy másik csomagban definiált leszármazott osztály, ha minősítés nélkül hivatkozik rá, vagy saját, vagy leszármazottja típusának megfelelő minősítéssel hivatkozik rá

Osztály csak nyilvános vagy félnyilvános lehet. Adattag és metódus bármelyik kategóriába tartozhat.Használata: az információrejtés alapelvének betartása érdekében minden elem kapja a lehető legszűkebb kategóriát. Szokásos konvenciók:

Egy osztály csak akkor legyen public, ha általános használatra szántuk Az adattagok private (esetleg protected) minősítést kapjanak. Ha szükséges,

metódusokon keresztül legyenek elérhetők. A public adattag hiba!!! A metódusok közül csak a „külvilág” számára szükségesek (az osztály interface-ét

jelentők) legyenek public minősítésűek.

11. TÉTELA this pszeudó változó és szerepe

Minden objektumhoz: Saját adattag-készlet tartozik Az osztály összes objektumára közös a tagfüggvény-készlet.

Hogyan tud a tagfüggvény az aktuális objektum adattagjaira hivatkozni?Megoldás: minden objektumhoz létezik az előredefiniált this pszeudó változó, amely az adott objektumra hivatkozik. Ezen keresztül éri el az adattagot a tagfüggvény. A this pszeudó változó explicite is használható.

12. TÉTELMetódusnév túlterhelés (overloading)

Egy osztályhoz több metódus is tartozhat azonos névvel, de különböző paraméterszignatúrával (a formális paraméterek száma és típus-sorrendje). A visszatérési érték típusa ebből a szempontból közömbös. A polimorfizmus egyik implementációs formája.A függvény hívásakor a fordítóprogram az aktuális paraméterek szignatúráját sorban egyezteti az összes azonos nevű definíció formális paramétereinek szignatúráival. Ennek az egyeztetésnek az alábbi eredményei lehetnek:

Pontosan egy illeszkedőt talál: ilyenkor az ennek megfelelő függvény hívását fordítja le.

Egetlen illeszkedőt sem talál: hibajelzést ad Több egyformán illeszkedőt talál: hibajelzést kap

Korai kötés ???

Az egy osztályhoz több azonos nevű metódus is tartozhat pontosabb jelentése az alábbi: Egy osztályban definiálhatók azonos nevű metódusok Ezen felül ugyanilyen nevű metódusokat örökölhet is az osztály

A saját és örökölt metódusok együttesére érvényes a metódus overloading szabályrendszere.

13. TÉTELKonstruktor fogalma, definíciójának és használatának szabályai. Az implicit

konstruktor.

Konstruktor: egy objektum adattagjai a létrehozáskor a default értékkel inicializálódnak. Ez nem mindig felel meg a programozónak. Ezen lehet változtatni például egy metódussal, amellyel a létrejött objektum adattagjai a szükséges értékekre állíthatók be. Ez azonban nem mindig a legjobb. Problémák:

Ha egy ilyen metódust elfelejtünk meghívni, az objektum nem a megfelelő kezdőállapotban kezdi az életciklusát.

Egy objektum működésének kezdetén az adattagjai értékének inicializálásán kívól más tevékenységekre is szükség lehet.

Ezeket a problémákat lehet megoldani egy automatikusan meghívódó kódrészlettel, a konstruktorral.A konstruktor majdnem olyan mint egy metódus, az alábbi korlátozásokkal:

Neve egyezik az osztály nevével Nem lehet visszatérési értéke (még void sem) Legfeljebb „üres” return utasítást tartalmazhat Már létező objektumra nem hívható meg közvetlenül Nem öröklődik Módosító csak hozzáférést szabályozó kulcsszó lehet.

A konstruktor legtöbbször public minősítésű.Példányosítás konstruktorral:Minden példányosítás esetén az alábbi folyamat zajlik le:

Helyfoglalás az adattagoknak Az adattagok inicializálása (default értékkel, vagy az inicializáló kifejezésnek

megfelelően) A konstruktor meghívódása a példányosításban megadott aktuális paraméterlistával

A konstruktornak szóló paraméterek a példányosítás során az osztálynév után, () zárójelpárban, vesszővel elválasztva adhatók meg. A konstruktor felhasználhatja az osztályban deklarált valamennyi adattagot. Az adattagok kezdőértéke a konstruktor számára az előzetes inicializálásnak megfelelő lesz. A konstruktor az osztály bármely metódusát használhatja. A metódusnév túlterhelés szabályainak betartásával egy osztályban tetszőleges számú konstruktor definiálható.A példányosítás utáni első metódushívás feltételezheti, hogy valamelyik konstruktor már lefutott. Egy metódus nem tudja megállapítani, hogy melyik konstruktor inicializálta az objektumot.Egy konstruktor első utasítása lehet ugyanazon osztály vagy az ősosztály egy másik konstruktorának meghívása

Másik konstruktor meghívása: This(aktuális paraméterlista)

Ősosztály konstruktorának megívása: Super(aktuális paraméterlista)

Implicit konstruktor: egy ősosztálynak mindig van legalább egy konstruktora. Ha a programozó definiál legalább egy konstruktort, akkor azok lesznek a konstruktorok. Ha a programozó egyet sem ír, akkor az osztályhoz a fordító hozzárendeli az impilict konstruktort. Ez public, paraméter nélküli és a törzse üres.Ha egy osztálynak nincs explicite definiált konstruktora, csak paraméter nélküli példányosítás lehetséges. Ha egy osztálynak van legalább egy explicit konstruktora, akkor paraméter nélküli példányosítás csak akkor lehetséges, ha a programozó definiált paraméter nélküli konstruktort. Az implicit konstruktor ilyenkor nem rendelődik hozzá az osztályhoz.

14. TÉTELObjektumok megszűnése. A szemétgyűjtő mechanizmus, A finalize metódus.

Objektum megszűnése: A C programozási nyelvben a futás közben dinamikusan lefoglalt memória területek helyes felszabadításáért a programozó a felelős. A Java-ban csak dinamikusan lehet objektumot létrehozni, de nem kell megszüntetni (nem is lehet). Az objektumok automatikus megszüntetése a szemétgyűjtő mechanizmus feladata.Szemétgyűjtő mechanizmus: számon tartja, hogy egy objektumra hány referencia hivatkozik. Ha már nincs érvényes referencia, az objektum haszontalanná válik. Egy külön szálban futó szemétgyűjtő felszabadítja a felesleges objektumhoz tartozó memória területet. Hogy ez pontosan mikor történik meg, nem tudjuk. Egy objektumra hivatkozó referencia megszűnik például, ha megszűnik maga a változó, megváltozik a változó értéke, a változónak a null értéket adjuk.Finalize metódus: minden osztályhoz definiálható egy

Protected void finalize() throws Throwablemetódus. A szemétgyűjtő hívja meg, még az objektum tárterületének megszüntetése előtt. Feladata minden olyan mellékhatás megszüntetése, amelyet az objektum az élete során okozott.

15. TÉTELJava csomagok és fordítási egységek. Minősített (teljes) hivatkozás. Az import

direktíva.

A Java-ban a programok tagolásának eszköze a csomag (package). (összetartozó típusok egysége). Minden csomagnak saját névtere van. Elkerülhető az egyező típusnevekből adódó problémák. A csomagok a hozzáférési kategóriák használatának eszközei.A Java-ban a csomagokban lehetnek adatcsomagok, a csomagszerkezet fastruktúrát alkot. A csomag tartalmát a fordítási egységek adják meg. A fordítási egységekben találhatók a csomaghoz tartozó kódok, azaz típusok (osztályok és interface-ek) definíciói.A csomagokra hierarchikus szerkezetű azonosítóval hivatkozhatunk. Az A csomag B alcsomagjában lévő C alcsomag: A.B:CAz egyes csomagokban található típusokra teljesen analóg módon hivatkozhatunk. Például a fenti csomagban definiált T típus: A.B.C.TCsomagok és fordítási egységek összerendelése: leképzés az operációs rendszer file-rendszerére vagy tárolás adatbázisban. A fordítási egységek file-ok .java kiterjesztéssel, a csomag-alcsomag nevek pedig katalógus nevek, amelyből útvonal generálódik. A fenti példában említett A.B.C csomag T típusának megkeresése a következőképpen történik:

Egy előre kijelölt katalógus A alkatalógusának B alkatalógusában a Java fordító a T.java file-t keresi.

A lefordított byte-kódot ugyanoda T.class néven helyezi el.A csomagszerkezetnek több kiinduló katalógusa is lehet. A fordító a CLASSPATH környezeti változó, vagy a –classpath kapcsoló alapján keresi meg a csomagok helyét a file rendszerben. A Java API előre definiált típusai is csomagokban találhatók.Egy fordítási egység az alábbi részekből áll

Csomagdeklaráció Importdeklaráció Típusdeklarációk (osztály vagy interface deklarációk)

Csomagdeklaráció: csomagnév megadása: package csomagnévA csomagnév teljes hivatkozás kell legyen. A fordítási egység elején szerepelhet és csak egy ilyen deklaráció lehet. Minden fordítási egység csak egy csomaghoz tartozhat. Ha elmarad, a fordítási egység egy névtelen csomaghoz fog tartozni. Egy csomag szabadon bővíthető.Import deklarációk: egy másik csomagban deklarált publikus típust a teljes azonosítójával kell megnevezni. Ezt rövidíthetjük az adott típus importálásával: import A.B.C.TEzután a fordítási egységben elég a T típusnév megadása. A fordító mindig a teljes azonosítót használja a munkája során. Egy csomag valamennyi típusát is importálhatjuk az alábbi formában: import A.B.C.*. Minden fordítási egységbe automatikusan importálódik a java.lang csomag összes típusa. Szerepe nem azonos a C #include direktívájával, mert nem másolódik be hatására semmi, csak a hivatkozást egyszerűsíti.Csomagok és hozzáférési kategóriák: ebből a szempontból minden csomag egyenrangú. Az A csomag B alcsomagja az A csomag szempontjából ugyanolyan idegen, mint az összes többi.

16. TÉTELOsztályváltozó és osztálymetódus

Példányváltozó: az eddig megismert adattagokból minden objektumnak saját készlete van. Ezeket ezért szokás példányváltozónak is nevezni. Az adattagok deklarációja elé kitehető a static minősítő.Osztályváltozó: a statikus adattag az osztály valamennyi objektuma számára egy példányban létezik, azok osztottan használják. Miután az osztály egészére vonatkoznak, szokás osztályváltozóknak is hívni. Nem a this pszeudó változó segítségével történik az elérése. Az objektumok előtt kell létrejönnie.Inicializálása az osztály inicializálás során történik. (A JVM akkor inicializál egy osztályt, amikor először történik rá aktív hivatkozás.) Az osztályon belül a nevével hivatkozhatunk. Hivatkozhatunk rá bármely objektum példányával. Az osztály bármely metódusa használhatja. Mivel egyetlen példány létrehozása nélkül is létezik, a hivatkozásban osztálynevet is használhatunk.Osztálymetódus: bár az eddigi metódusok csak egy példányban léteznek minden példány számára, de működésükhöz egy aktuális példány szükséges. Ezeket hívhattuk volna példánymetódusoknak is. Metódus is kaphat static minősítést: osztálymetódus. Az ilyen metódus a példányváltozókhoz és a this pszeudó változóhoz nem férhet hozzá. Következmény: csak osztályváltozókat és más osztálymetódusokat használhat.Akkor is végrehajtható, ha az osztálynak nem léteznek példányaiHivatkozás:

Osztályon belül nevével Minősített hivatkozásnál bármely példány vagy az osztály nevével

Egy program indulásakor nincs, ami példányt hozzon létre, ezért a main metódusnak static minősítésűnek kell lennie.

17. TÉTELA final minősítésű adattag és metódusok

A final minősítő többféle célra is használható a Java nyelvben. Jelentése mindig „valami olyasmi, ami később nem változtatható meg”. Final adattagok: deklaráció: final típus azonosító=inicializáló kifejezésAz inicializáló kifejezés csak olyan elemeket tartalmazhat, amelyek az addigi deklarációk ismeretében feldolgozhatók. Miden példányosítás során végrehajtódik, tehát a változó értéke objektumként egyedi lehet. Egyetlen metódus sem változtathatja meg az értékét.Static final adattagok: deklaráció: static final típus azonosító=inicializáló kifejezés. Az inicializáló kifejezések csak konstansokat és olyan static adattagokat tartalmazhat, amelyek már deklaráltak. Csak egyszer, az osztály inicializálása során hajtódik végre, tehát a változó értéke az osztály miden példánya számára ugyanaz. Egyetlen metódus sem változtathatja meg az értékét.

Az egyszerű típusú final adattagok egy konstans értéket képviselnek. Az osztálytípusú final adattagok egy konstans referenciát képviselnek:

Nem változtatható meg az értéke, hogy egy másik példányra hivatkozzon Semmi sem akadályozza azonban azt, hogy a hivatkozott objektumot megváltoztassuk A Java-ban egy objektum nem deklarálható konstansnak

Kezdőérték nélküli final adattag: másik elnevezése üres konstans. A deklarációból az inicializáló kifejezés elhagyható (az = jellel együtt). Az adattag az első használata előtt inicializálandó. Veszélyes lehet, ezért ne használjuk, vagy ha mégis, akkor minden konstruktor állítsa be az értékét.

Final metódus: egy metódus kaphat final minősítést. A final minősítésű metódust nem definiálhatja felül egyetlen leszármazott osztály sem. Szerepe, hogy megakadályozza bizonyos viselkedés formák megváltoztatását, ha az veszélyezteti a helyes működését.

18. TÉTELAz öröklődés fogalma, szintaktikai szabályai. Statikus és dinamikus típus

fogalma.

Egy osztály deklarálható valamely más osztály leszármazottjaként. A leszármazott osztály rendelkezik:

A szülő osztály tagjaival A saját tagjaival

Az ős osztály elemeinek az elérése a leszármazott osztályból nem feltétlenül garantált. Az öröklődési hierarchia tetszőleges lehet. Egyetlen korlátozás: egy osztály még közvetett módon sem lehet saját maga őse.Az ős osztály továbbra is használható önmagában is. Ha egy Java osztálynak nincs megadva őse, automatikusan az Object osztály leszármazottja lesz. Minden osztálynak van tehát egy közös őse.Szintaktika:[módosító] class név extends ősosztály{// a saját tagok deklarációja}Hivatkozás a leszármazottra: mivel egy leszármazott az őse minden tulajdonságával rendelekzik, bármikor használható ős típusú objektumként is. Ezért egy ős típusú hivatkozás használható leszármazott típusú objektumhoz is. Következmény: bármely objektumra hivatkozhatunk Object típusú hivatkozással.Egy változónak van statikus és dinamikus típusa.Statikus és dinamikus típus: egy változó statikus típusa az, amelyet a deklarációjában megadtunk. Ez a változó teljes élete alatt változatlan.Egy változó dinamikus típusa az általa éppen hivatkozott objektum tényleges típusa. Ez a program futása során bármikor változhat. A változó dinamikus típusa csak a statikus típus vagy annak leszármazottja lehet.Hozzáférés a leszármazottból: a leszármazott osztály az ős osztályból örökölt tagokra hozzáférés szempontjából ugyanolyan jogokkal rendelkezik, mint bármely más osztály. Például az örökölt private adattagot nem érheti el közvetlenül. Mivel azonban az örökölt adattagok a részét képezik, az örökölt public metóduson keresztül használhatják. A leszármazottra vonatkozó speciális minősítő a protected.

19. TÉTELKonstruktorok az öröklődés során

A konstruktor nem öröklődik. Mind az s osztály, mind a leszármazott osztály rendelkezhet konstruktorral (akár többel is). Egy leszármazott objektum példányosításánál tisztázni kell:

A konstruktorok végrehajtási sorrendjét Azt, hogy hogyan választhatjuk ki az ősosztály konstruktorai közül a végrehajtandót

Végrehajtási sorrend: először mindig az ősosztály, majd a leszármazott osztály konstruktora hajtódik végre. A pontos sorrend:

Az ős osztály adattagjainak inicializálása Az ős osztály konstruktorának végrehajtódása A gyermek osztály adattagjainak inicalizálása A gyermek osztály konstruktorának végrehajtódása

Ős osztály konstruktorának kijelölése:A gyermek osztály első sorában szerepelhet egy super(paraméterek) konstruktorhívás. A paraméterlistának az ős osztály valamelyik konstruktorára illeszkednie kell. Ha ilyen hívás nem szerepel a gyermek osztály konstruktorában, akkor egy implicit super() hívással kezdődik a konstruktor végrehajtása. Következmények: ha a gyermek osztálynak van olyan konstruktora, amelyben nincs explicit ős konstruktor hívás, a szülő osztálynak kell legyen paraméter nélküli konstruktora. Ha a gyermek osztálynak csak implicit konstruktora van, az is, az ős osztály paraméter nélküli konstruktorát hívja meg. A szabályok megsértésénél hibajelzés.

20. TÉTELFelüldefiniált metódusok: a definiálásra és a hívásra vonatkozó szabályok.

Használatának célja.

Metódusnév túlterhelés: a már ismert mechanizmus: egy osztályon belül azonos nevű függvények, eltérő paraméter szignatúrával. A saját és az örökölt függvények együttesen tekintendők.Korai kötés: a fordítóprogram az aktuális paraméterek statikus típusa alapján dönteni tudPolimorfizmus, mert a név nem egyedi, további információkat kell felhasználni.Metódus felüldefiniálás:

Az előzőnél még hatékonyabb implementációs forma A leszármazott osztály az ős osztálytól örökölt metódust felüldefiniálhatja Egy ilyen metódus hívásánál dönteni kell, hogy az örökölt vagy a saját változat

hívódjon meg – polimorfizmus A döntés alapja a hivatkozás dinamikus típusa Mivel a dinamikus típus fordítási időben nem ismert, a felüldefiniált metódusok

közötti választást futásidőre kell halasztani – késői kötés.Egy ős osztálybeli metódus felüldefiniálásához a következő feltételeknek kell teljesülnie:

A felüldefiniálandó metódus visszatérési típusának, nevének, és paraméter szignatúrájának meg kell egyeznie az ős osztálybeli metóduséval

A felüldefiniálandó metódus hozzáférési kategóriája nem lehet szűkebb az eredeti metódusénál

A felüldefiniálandó metódus csak olyan ellenőrzött kivételeket válthat ki, amilyeneket az eredeti is kiválthat

Felüldefiniálandó metódus hívása: a hívásban szereplő valamennyi információ illik minden metódus változatra – ez alapján nem lehet dönteni. A döntés alapja a hivatkozás dinamikus típusa. A döntés csak futás időben történhet. A felüldefiniálandó metódus az ős osztály metódusát elérheti a super.metódusnév(…) formájú hivatkozással.Késői kötés használata: a leszármaztatás lehetőséget teremt, hogy viselkedésformákat örököljön egy osztály. Bizonyos esetekben a változatlanul öröklődő viselkedés nem felel meg a leszármazottnak. A felüldefiniálás lehetősége ezt a problémát tudja megoldani. A késői kötés automatizmusa a használatot kényelmessé teszi.Metódus felüldefiniálási további szabályok: nem kötelező a leszármazás minden szintjén felüldefiniálni a metódust. Egy osztály örökölheti a felüldefiniált metódust. Statikus metódus nem definiálható felül. Ugyanolyan nevű statikus metódus a leszármazott osztályban elfedi az ős osztály metódusát.

21. TÉTELAbsztrakt metódus és absztrakt osztály

Gyakran előfordul a tervezés során, hogy egy osztály szintjén tudjuk, hogy valamilyen metódus szükséges lesz a leszármazottakban, de még nem lehet megadni az implementációját. Ezért a Java nyelv megengedi törzs nélküli metódus definiálását. Az ilyen metódust az abstract minősítővel kell ellátni. Ha az osztály tartalmaz absztrakt metódust, az osztályt is az abtract minősítővel kell ellátni.Formai szabályok:

Absztrakt egy metódus, ha nincs törzse, megvalósítást, csak a felüldefiniálás során kap.

Absztrakt metódusnak nem lehet azonosítója a private, final, static hiszen az ilyen metódusokat nem lehet felüldefiniálni.

Absztrakt egy osztály, ha van legalább egy absztrakt metódusa Absztrakt osztályt nem lehet példányosítani Egy absztrakt osztály arra szolgál, hogy ős osztálya legyen további osztályoknak A leszármazott osztály(ok) feladata az absztrakt metódusok felüldefiniálása Absztrakt osztály gyermeke lehet absztrakt, ha nem minden absztrakt metódust valósít

meg Az absztrakt osztály is használható referencia statikus típusaként

Az absztrakt metódusok szerepe: rögzít egy tervezési döntést (szüksége metódusok halmaza), kényszeríti a leszármazott osztály(ok) programozóját meghatározott metódusok definálására.Hibalehetőségek: törzs nélküli metódus, abstract minősítő nélkül, absztrakt metódust tartalmazó osztály abstract minősítő nélkül.

22. TÉTELA Java interface fogalma, a definíció szintaktikája. Interface implementálása.

Egy osztály interfészén a nyilvános elemeinek összességét értjük, ami a használatához szükséges. Az információ rejtés elve miatt, általában csak metódusokból áll. Specifikáció, tervezés során készül. Kényszeríti az osztály késztőjét a megfelelő elemek implementálására. Protokollok az objektumok között.Interfészek a Java-ban: mivel nincs globális változó, konstans, ezért lehetnek adat részei is. Szintaktikája hasonló az osztályhoz, de a class kulcsszó helyett interface. Kiterjeszthet más interfészeket (extends), létezik többszörös interfész öröklés. Az interfész nem tartalmaz végrehajtható kódot, azt a megvalósító osztályban (implements) kell megadni. Megállapoidás, hogy „I”-vel kezdődik a neve.Szintaktika:[módosító] interface Iazonosító [extends Ios1[,Ios2]]{

[elemek deklarációja]}Módosító lehet: public vagy abstractInterfészek kiterjesztése: minden interfész kiterjeszthet egy vagy több interfészt. Fontos, hogy önmagát nem terjesztheti ki sem közvetve, sem közvetlen. Nem alakulhat ki körkörös lánc.Interfészek láthatósága:

Public: nyilvános: ebben az esetben az interfész azonos nevű fájlba kell írni, 1 interfész w fájl

-: csomagszintű: ilyenkor csak abban a csomagban lehet használni, de több is lehet egy forrájsfájlban

Interfész implementálása:[módosító] class osztálynév [extends ősosztály] [implements Iint1[,Iint2[,…]]]Szabályok:

Ha egy osztály implementál egy interfészt, akkor köteles annak minden metódusát implementálni

Az implementált elemeket nem módosíthatja Metódusok esetében a fejlécnek teljesen egyeznie kell Azonos nevű elemet az öröklődés során és az implementálás során nem kaphat meg

Interfész használata: egy interfész új referencia típust vezet be -> mindenhol használható, ahol egy osztály. Változó deklarációban szerepelhet. Bármelyik osztállyal helyettesíthető, amely implementálja.

23. TÉTELA kivétel fogalma és a kivételkezelés utasításai a Java nyelvben. Kivétel

keletkezése.

Kivételes helyzetek a jól megírt programokban is előfordulnak (pl: erőforrsáhiány, valamilyen funkció hibás vagy hiányos adatok miatt nem hajtható végre). Ezeket a szituációkat kezelni kell. A szükséges teendők elvégzése után általában a program folytatni tudja a munkát. Kivétel: futás idejű hiba, nem normális eset. Általában valamiyel hibához kötődik. Számos beépítést igényel. Saját kivétel definiálható. A Java szemléletében a kivétel egy objektum, ami a kivétel bekövetkezésekor jön létre. Saját kivétel kiváltása: throw objektum.

A kivétel keletkezésekor szokásos teendők: Értesíteni a felhasználót, vagy naplózni Valamilyen plusz művlete után folytatni az alkalmazást, esetleg kilépni, súlyos hiba

esetén. Ellenőrzött kilépés lehetséges A kivétel objektum tartalmazhat információkat a kivétel keletkezéséről, amelyet

felhasználhatunkKivételkezelés utasításai:

try: védett kód kijelölése throw: kivétel dobása, generálása catch: kivétel elkapása, a blokkban definiált utasítások végrehajtása finally: végül, akár volt kivétel, akár nem, lefut.

Try blokk: a védett kód try blokkban helyezzük elTry {utasítások}

A blokkban keletkezett kivételt mi kezelhetjük le. A blokkok egymásba ágyazhatók. Érdemes minél kisebb blokkot definiálni. Kivétel keletkezik, ha a try blokkban egy throw utasításra fut a vezérlés.Formája: throw new kivételTípus(konstruktor paraméterek)A throw paramétere nem maradhat elKivétel keletkezése:

Implicit módon: a JAVA rendszerből indul ki, azaz valamely utasítás vagy API elem végrehajtása során keletkezik

A programozó kódjában keletkezik, közvetlenül egy throw utasítás végrehajtásával Aszinkron kivétel, amely a program egy másik szálán lépett fel. A kivétel keletkezése esetén: Az első kivételt kiváltó utasítással befejeződik a try blokk végrehajtása. Kilép a blokkból a vezérlés, rendcsinálással, verem visszaállítása, lokális objektumok

megszüntetése, védett változók megszüntetése Létrejön a throw utasításban megjelölt objektum egy példánya

24. TÉTELKivétel elkapása és lekezelése. A finally blokk szerepe

Kivétel elkapása és lekezelése: a kivétel objektumot minden esetben a virtuális gép hozza létre. A kivétel lekezelését szolgáló utasítások catch blok(ok)ban helyezkednek el. Formája: catch(típus paraméterek) {utasítások}. A catch minden esetben a try blokkot követi, nem lehet közöttük más utasítás. Egy try blokkhoz tartozhat több catch is. A virtuális gép megkeresi a sorrendben első „illeszkedő” blokkot, és annak végrehajtásával folytatódik a program. Az illeszkedés feltétele: a kivétel objektum típusa megegyezik a catch blokk fejében megadott típussal, vagy annak leszármazottja. A kiválasztott blokk végrehajtása során a paramétere úgy használható, mint a függvények esetén a formális paraméter. Így lehet felhasználni a kivétel objektumban tárolt információkat. A futás az utolsó catch utáni sorral folytatódik. Minden ellenőrzött kivételt kezelni kell. Ha a catch blokk végrehajtása során újabb kivétel keletkezik, az eredeti kivétel kezelése megszakad, és az új kivétel lekezelése kezdődik el. Ha egyetlen catch blokk sem illeszkedik kivételre, a keresés a beágyazó try blokk catch blokkjaival folytatódik, amíg sikeres nem lesz. Ha a keresés belülről kifelé minden try blokkot megvizsgált, és nem talált egyezést, a program terminálódik, és kiíródik a kivétel stack (lekezeletlen kivétel).Finally blokk: nem kötelező. A catch(ek) után szerepelhet. Az utolsó catch blokk és a finally blokk között nem lehet más utasítás. Nem lehet paramétere. Minden esetben lefut. Ha kivétel keletkezett a try blokkban, egy catch blokk végrehajtása után. Ha nem volt kivétel, a try blokk uzolsó utasítása után. Alkalmas például fájlok, adatbázis kapcsolatok lezárására.

25. TÉTELElőre definiált és saját kivétel osztályok

Kivétel objektum: mivel objektum, valamely definiált osztály példánya kell legyen. Minden kivétel osztály a Java.lang.Throwable osztály leszármazottja kell legyen, de ez általában közvetve valósul meg. A Java.lang.Throwable osztálynak van számos előre definiált leszármazottja.Kivétel osztályok: az Error és a RunTimeException osztályú kivételek nem ellenőrzött kivételek. Az összes többi ellenőrzött kivétel. Ajánlott minden programozó által definiált kivétel az Exception osztályból származzon. Valamennyi ilyen kivétel ellenőrzött kivétel, kötelező lekezelni. Konvenció: minden kivételosztály neve: ValamiException legyen, ahol a valami a kivétel jellegére utal.Az Exception osztály: van egy String paraméterű konstruktora, amellyel egy leírás definiálható a kivételhez. Számos hasznos metódust definiál, amely öröklődik és szükség esetén felüldefiniálható:

String toString(): visszaad egy sztringet, amely az osztály azonosítójából és a konstruktorban megadott sztringből áll

String getMessage(): visszaadja a konstruktorban megadott sztringet printStack(): kiírja a keletkezett kivételeket, a keletkezésük sorrendjében és megadja a

keletkezésük helyét (hasznos lehet hibakezeléshez, paraméter nélkül a standard hibacsatornára ír, de paraméterben megadható, hogy hova írjon)

Saját kivétel osztály: az Exception osztály leszármazottja legyen. Fontos a névkonvenció. A konstruktorának a paraméterei között legyen egy String, amivel az ős osztály konstruktorát hívja meg. A további paraméterek a hibára jellemző adatokat fogadhatnak. A metódusai a catch blokkban használhatók a kivétel lekezelése során. A kivételek csoportosítására célszerű leszármazási hierarchiát létrehozni a saját kivételosztályok között is.

26. TÉTELAz ellenőrzött és nem ellenőrzött kivétel fogalma. Kivételek specifikálása

Nem ellenőrzött kivételek: az Error és a RunTimeException osztályból származó kivételekError: rendszerszintű hiba a JVM működésébenRunTimeException: a program számos pontján keletkezhetnek, ezért nem célszerű kötelezővé tenni a lekezelésüket.A programozó, ha akarja, lekezelheti. Lekezeletlen kivétel esetén a program terminálódik, és kiíródik a kivétel stack.Ellenőrzött kivételek: a fordítóprogram hibát jelez, ha nincs lekezelve. A kivétel keletkezésének módjai:

A try blokk után valamelyik catch blokk elkapja, és teljes mértékben lekezeli. A metódus futása folytatódik a catch blokkok utáni első utasítással.

A try blokk utána valamelyik catch blokk lekapja, és részben lekezeli. A lekezleés egy olyan throw utasítással fejeződik be, amely a paraméterül kapott kivétel objektumot tartalmazza. A metódus futása befejeződik. A metódus fejlécében ezt a kivételt specifikálni kell.

A metódus nem kezeli le a kivételt, de specifikálja azt a fejlécében. A metódus futása befejeződik. Ez akkor szükséges, amikor az adott metódus nem, csak a hívó tudja értelmesen lekezelni a kivételt. A hívó is tovább adhatja a kivétele lekezelését, így a kivétel tetszőleges hívási mélységből is eljuthat oda, ahol lekezelhető.

Kivételek specifikálása: ha egy metóduson belül kivétel keletkezhet, de nem tartalmaz catch utasításokat annak kezelésére. Ilyenkor a metódus hívójának kell azokat lekezelni. Erre számítani kell, ezért az ilyen kivételeket a metódus fejlécében specifikálni kell.Formája: metódusnév([paraméterlista]) [throws kivetelosztály1 [, kivetelosztaly2, …] ]

27. TÉTELBeágyazott osztályok

Osztálydefiníció a programon belül:a Java-ban egymás mellé rendelt osztály és interface definíciókon kívül lehetőség van definíciók beágyazására:

Osztály hatáskörbe (tagosztályok) Utasításblokkba (lokális osztályok) Egy utasításba (névtelen osztályok)

Tagosztály: osztálydefiníció egy osztály hatáskörében. A befoglaló és a tagosztály kölcsönösen hozzáférnek egymás tagjaihoz (a private tagokhoz is). A nevek minősítése nem szükséges. A tagosztályok is öröklődnek. A befoglaló osztályon kívüli hozzáférés a tagosztály hozzáférési kategóriájának megfelelően lehetséges. A tagosztály tagjaira való hivatkozáshoz a nevet minősíteni kell.Statikus tagosztály: static módosítóval. Emellett még public, protected, private módosítója lehet. A program csomagon belüli tagolásához: egy típus, amely a befoglaló osztály hatáskörében van. Használható a befoglaló osztályon belül típusként. Ha nem private, a programban ugyanúgy használható, mint bármely más osztály.Alkalmazási területei:

Egy segédosztályt el akarunk rejteni a külvilág elől Egy osztály megvalósításakor egy olyan segédosztályra van szükség, amelynek hozzá

kell férnie az osztály privát tagjaihoz Ki akarjuk fejezni, hogy egy osztály vagy interface egy másiknak logikai alárendeltje.

Nem statikus tagosztály: a befoglaló és a tagosztály példányainak kapcsolatát implementálhatjuk vele. A tagosztály egy adott példányához a befoglaló osztály pontosan egy példánya tartozik. Ellenkező irányban: a befoglaló osztály egy példányához a tagosztály tetszőleges számú példánya tartozhat (nulla is). A fenti kapcsolat automatikusan rögzítődik és fennáll mindaddig, amíg a befoglaló osztály példánya él. Ha például egy külső osztály egy metódusa példányosít egy beágyazott típusú objektumot, az a befoglaló objektumhoz kapcsolódik, és túléli a metódust.

28. TÉTELAz osztály interface fogalma és a jól tervezett osztály interface jellemzői

Osztály interface: A public metódusok összessége: ezeket el kell ismernie az osztály használójának.

Használatukhoz nem szükséges ismerni az osztály implementációs részleteit Protected metódusok és adattagok: kibővíti az interface-t a leszármazott osztályok

számára. Használata veszélyeket rejt magában, mert implementációs függést hoz létre az ős és a leszármazott osztály között.

Technika iszempontból az interface részét képezik az esetleges public minődítésű adattagok is, de használatuk nem ajánlott. Ellentmond az információrejtésnek.

A jó osztály interface:Teljes:

Minden funkciót tartalmaz, ami az osztálytól elvárható Nem az adott alkalmazás szempontjai határozzák meg Újrafelhasználható egységet alkot az osztály

Minimális: Nem tartalmaz a felhasználó számára érdektelen elemeket Belső felhasználású funkciók private vagy prtoected minősítésűek A belső áttervezés nincs rá hatással

Kezelhető méretű: Általában legfeljebb néhány metódus A sok funkció között nagyobb valószínűséggel lesznek hasonlóak A terjedelmes interface általában tervezési hibára utal: az interface része belső funkció

is. Az osztály határait nem jól állapítottuk meg, és túl sok feladatot akarunk rábízni. A helyes architektúra kialakítása érdekében az eredetileg tervezett osztályt több osztályra kell bontani, és ezek között leszármaztatással vagy más mechanizmussal megteremteni a kapcsolatot

Az osztály interface részei: Kezelő tagok és metódusok: konstruktorok, örökölt „kész” metódusok. Sokszor nem is

a programozós, hanem a program implicite hívja meg Elérési függvények: az adattagok értékének elérésére vagy azok értékének

módosítására Munkavégző függvények: az osztály lényegi funkcióit aktivizál függvények

29. TÉTELAz általánosítás/pontosítás (is-a) és a tartalmazás (has-a) kapcsolat

implementálási lehetőségei a Java nyelvi eszközökkel.

Osztályok közötti kacsolatok: Általánosítás/pontosítás (is-a) Tartalmazás (has-a) Használat (use)

Az általánodítás/pontosítás implementációja: Leszármaztatási mechanizmus (öröklődés) segítségével. A leszármazott osztály objektuma egyben ős objektum is

Tartalmazás implementálása: Aggregáció: a rész az egészhez tartozik, de önállóan is létező entitás Kompozíció: a rész önmagában nem létezhet, csak valaminek a részeként.

Aggregáció: A tag objektum referenciája a tartalmazó osztályban Ez adattag, tehát általában private Az egy –több kapcsolat megvalósítása különböző adatszerkezetekkel lehetséges

(tömb, vektor stb.) A referenciák beállítása általában a befoglaló osztály konstruktorának feladata, már

létező objektumok referenciáinak felhasználásával.Kompozíció:

A tartalmazó osztályban osztálydefiníció a tartalmazott számára, private hozzáférési kategóriával

A tartalmazó osztály konstruktorának vagy valamelyik metódusának a feladata a „rész” példányosítása (Kívülről nem lehet a private minősítés miatt)

Öröklődés vagy tartalmazés?Mindkét esetben egy objektum más objektumot tartalmaz. Az öröklődés esetén ez implicit módon történik.Technikai különbségek:

A leszármazott objektum pontosan egy ősobjektumot tartalmaz Tagobjektumok tetszőleges számú típussal, típusonként tetszőleges számmal

definiálhatókTervezési különbségek:

Más logikai kapcsolatot fejeznek ki(is-a, has-a) Az öröklés az interface újrafelhasználása: a leszármazott osztály interface-ének része

lesz az ősosztály interface-e. A private tag objektumnak az osztályának a funkcióit használjuk fel a befoglaló

osztály implementációjához. A tagosztály interface.e nem képezi részét a befoglaló osztály interface-ének.

A public tag objektummal a befoglaló osztály interface-ét kiegészítjük a tag objektumok osztályainak interface-eivel. Nem mindig szerencsés megoldás: rontja a program áttekinthetőségét. Erős függőséget hoz létre az osztályok között.

A teljes OOP kidolgozás Galán Mihály munkája

Lehetséges írásbeli kérdések a Szoftvertechnológa tárgy anyagából

1. A software technológia fogalma. A software fejlesztés folyamata, fázisai és kiegészítõ munkafolyamatai.

2. Szoftver életciklus modellek.

3. Az objektum orientált software fejlesztés alapelvei, elõnyei. absztrakciós eszközei.

4. A modellalkotás alapproblémái. Az inkremetáció és a nézetrendszer a modellalkotásban.

5. A követelmény analízis fázis feladata. Követelmény fogalma és osztályozása. Nagy rendszerek analízise.

6. A funkcionális, a nem funkcionális és a szakterületi, illetve a felhasználói és a rendszerkövetelmények.

7. A tervezési fázis feladata, szintjei. A külsõ tervezés feladatai.

8. Az UML története, fogalma, fõ tervezési célkitûzései, elemei (diagram típusai).

9. A use case diagram szerepe, fõ elemei. (UML)

10. Az osztály diagram feladata, fõ elemei. (UML)

11. A szekvencia diagram feladata, fõ elemei. (UML)

12. Az állapot diagram feladata, fõ elemei. (UML)

13. Az aktivitás diagram feladata, fõ elemei. (UML)

14. A Rational Unified Process (a továbbiakban RUP) története, fogalma, legfontosabb tulajdonságai.

15. A fázisok, iterációk és munkafolyamatok összefüggése a Rational Unified Process-ben.

16. Az egyes fázisok és fõ feladatuk a Rational Unified Process-ben.

17. A személy, tevékenység, termék és munkafolyamat fogalma és szerepe a Rational Unified Process-ben.

1. A software technológia fogalma. A software fejlesztés folyamata, fázisai és kiegészítõ munkafolyamatai.

A software technológia fogalmaA software technológia egy egyszerű definíciója:

Eszközök és módszerek a szoftver termékszerű előállítására.A klasszikus definíció (Boehm, 1976):

Tudományos ismeretek gyakorlati alkalmazása számítógépes programok és a fejlesztésükhöz, használatukhoz és karbantartásukhoz szükséges dokumentációk tervezésében és előállításában.

A hivatalos definíció (IEEE, 1983):Technológiai és vezetési alapelvek, amelyek lehetővé teszik programok termékszerű gyártását és karbantartását a költség- és határidő korlátok betartásával.

A software fejlesztés folyamata, fázisai és kiegészítő munkafolyamatok:

1. Követelmény analízisMit is kellene csinálni?Mikorra, és mennyiért?Kikkel?

2. SpecifikációMit kell csinálni?

3. TervezésHogyan kell megcsinálni?

4. ImplementációNa, akkor csináljuk!!

5. Installáció és tesztelésMit műveltünk?

6. KarbantartásHa elszúrtad, javítsd is ki!Aki elszúrta, azóta már főnök - TE javítsd ki!Ha pedig a rendszer hibátlan(nak látszik) - AzÚr (a felhasználó) szava :

igazából nem is ez kellene, hanem ....azt pedig nem úgy értettem, hanem...ha már ezt tudja, tudhatná azt is, hogy...újabban ezt már nem is így kell csinálni, hanem...

Azaz: ismétlés onnan, hogy ...

Kiegészítő munkafolyamatok

Projekt menedzsment Verzió kezelés / verzió követés Erőforrás management Minőségbiztosítás Terméktámogatás Projekt értékelés, fejlesztési folyamat továbbfejlesztése

2. Szoftver életciklus modellek.

Klasszikus “waterfall” vízesés modell

Jellemzői:– Technikai problémának tekinti a fejlesztést.– Nem foglalkozik a kommunikációs csatornákkal.– Visszacsatolás túl későn lehetséges. Gyakorlatilag csak a teljes rendszer elkészülte után van rá mód.

Diagram:

Gyors prototípus “rapid prototyping” modell

Jellemzői:–Elősegíti a fejlesztő és a felhasználó kommunikációját ellentétben a waterfall modellhez képest.– Föleg kis csoportok számára javasolt a tapasztalatok szerint.

Diagram:

Evolúciós “inkrementálsi” modell

Jellemzői:–Az eredeti célhoz egyre közelebb álló rendszerek sorozata.– Minden egyes rendszer átmegy legalább a tervezés, az implementálás és a tesztelés fázisán.

Diagram:

Újrafelhasználási modell

Jellemzői:

–Alulról felfelé építkező modell.– Gyors módszer, ha van elég “építőanyag”. Azaz elegendő újra hasznosítható elemünk.– Hatékonyság a szükséges helyeken utólag javítható.Újrahasználható elemek:

Implementáció– algoritmusok– függvény könyvtárak– osztály és objektum könyvtárakszoftver komponensek– korábban fejlesztett, hasonló rendszerekTervezés– tervezési minták– bevált architekturális megoldásokAnalízis, specifikáció– leginkább az előző fejlesztések tapasztalatai

Diagram:

Very High Level Languages

Nem-procedurális nyelvek, alkalmazás-generátorok.

Jellemzői:

A fejlesztő eszköz számára le kell írni, hogy mit csináljon. A többi az eszköz dolga. Általában jól körülhatárolt területekre javasolt, mint például Oracle, FOCUS, Magic-

AB alkalmazások. Esetleg hatékonysági problémák léphetnek föl.

Diagram:

Spirál-modellBoehm 1988-s modellje. Újdonság a korábbi modellekhez képest a kockázat

kezelés.Jellemzői:

A fejlesztés iterációs lépések sorozata. Az egyes iterációkban kitűzött célok folyamatosan fejlődnek. Valamennyi fázis ciklikusan változik. Ezt ábrázolva kapjuk meg a spirálhoz hasonlatos

alakzatot. Minden rész megoldását, részmegoldást ki kell értékelni. Elemezni kell az adott megoldás kockázatát.

Ha a kockázat kisebb, mint a várható haszon akkor következhet a következő ciklus.

3. Az objektum orientált software fejlesztés alapelvei, előnyei. absztrakciós eszközei.

Út az objektum orientált szemléletig 1.Klasszikus módszerek:

program = adatszerkezetek + algoritmusok

Alapkérdés: mi legyen a strukturálás alapja?

1. Processz alapú módszerek (top-down)A struktúrálás alapja a függvény.Példa: strukturált analízis és tervezés, SADTHiányosságai:

nem veszi figyelembe a software "fejlődő" természetét feltételezi, hogy van "top" (eseményvezérelt rendszer?) háttérbe szorul a program adatszerkezete nem "termel" újrafelhasználható elemeket. Jó a kis-közepes rendszerek esetén illetve a tervezés tanulása során.

2. Adat alapú tervezési módszerekA struktúra alapja az adatszerkezet.Példa: Jackson módszer, SSADMSajátosságai:

rugalmasabb, inkább biztosít újrafelhasználható elemeket jobban segíti a program módosítását.

3. Hibrid módszerekPélda: strukturált programozás (Dijsktra)Megpróbálja párhuzamosan finomítani az adat és függvénystruktúrát.Hátrány: ez is top-down módszer.

Objektum orientált fejlesztés alapelve

Az adatalapú fejlesztési módszerekből nőtt ki.Program: egymással kommunikáló objektumok halmaza.Struktúra: az osztályok közötti relációViselkedés: az objektumok közötti üzenetváltásokA programkészítés folyamatát modellkészítésnek tekintjük.Bertrand Meyer-től származó definíció:

Software rendszerek felépítése absztrakt adattípusok implementációinak strukturált együtteséből.

Az OO modell előnyei

áttekinthetőség nem kell informatikusnak lennie az olvasónak, így alkalmas a megrendelővel történő

egyeztetésre könnyen módosítható, átstrukturálható, kiegészíthető az elvi modell könnyen transzformálható implementációs modellé

Az OO szemlélet absztrakciós eszköz

Az objektum: egyediséggel rendelkező diszkrét entitásjellemzői: attribútumok, műveletekattribútum együttes: objektum állapot, ennek időbeli változása az objektum

viselkedéseműveletek(operations): implementálva módszernek (method) hívjukobjektumok közötti interakciók: (message passing, event generating)

üzenet(message), esemény (event) (lehet szintén objektum!) csak biztosított interface-en keresztül történhet. a műveletek valósítják meg

OO absztrakció (folytatás)PéldányosításÁltalánosítás és pontosítás

OO absztrakció (folytatás)Polimorfizmus

Absztrakt osztály (csak interfészt specifikál)Paraméterezett osztály (osztályok mintája)

OO szemlélet absztrakciós eszközei

4. A modellalkotás alapproblémái. Az inkremetáció és a nézetrendszer a modellalkotásban.

A modellalkotás alapproblémáiA fejlesztés alapvető problémái:

A fejlesztendő rendszer komplex, tehát a modellje is az. Biztosítani (és ellenőrizni) kell, hogy a modell valóban a megoldandó feladatot reprezentálja.

Megoldási lehetőségek: Inkrementális és iteratív fejlesztés Modell nézetek

Inkrementum, iteráció

Nem egyszerre építjük fel a teljes modellt (inkrementális életciklus modell) Ha szükséges, még az inkrementumok felépítését is részekre (iterációkra) osztjuk.

Előnyök: Egyszerre viszonylag egyszerű feladatot kell megoldani Gyakori részeredmény, amely ellenőrizhető

Nézetrendszer

Nem egy modellt készítünk el, hanem a rendszer különböző nézőpontú modelljeitElőnyök:

A rendszer egyszerűbben átlátható, ha egyszerre csak egy adott nézőpontból kell vizsgálni.

A különböző nézőpontból készített modellek összevethetők, és a modell helyességének ellenőrzésére használhatók fel.

Nézőpontok:Problématér

Használati nézetMegoldási tér

Strukturális, statikus nézet Dinamikus nézet Implementációs nézet Környezeti nézet Használati nézet

Használati nézet: A rendszer a felhasználó nézőpontjából Ezt a modellt a követelmény analízis és a specifikációs fázis állítja elő Ez tekinthető a problématér modelljének

Strukturális, statikus nézeturális, statikus nézet

A rendszer egységei és azok kapcsolata A megoldási tér osztályai, objektumai

Dinamikus nézetA rendszer egyes részeinek (objektumainak) viselkedése a működés során.

A részek lehetséges állapotai Milyen események következtében megy egyik állapotból a másikba Az üzenetküldések sorozata (időben) Egy adott állapotban végrehajtandó tevékenységsor

Implementációs nézet

A megoldáshoz szükséges szoftver elemek, és azok kapcsolataiKörnyezeti nézet

A rendszer működéséhez szükséges hardware és software erőforrások, és ezek kapcsolatai

5. A követelmény analízis fázis feladata. Követelmény fogalma és osztályozása. Nagy rendszerek analízise.

A követelmény analízis fázis célja

A projekttel szemben támasztott követelmények meghatározása felhasználó igényei elérendő célok és haszon emberi, gépi erőforrások időszükséglet költségek szervezeti követelmények

Az analízis fázis feladata

A rendszerre vonatkozó összes információt összegyűjteni megérteni Ehhez szükséges elemezni a meglévő, jelenleg működő és a tervezett, leendő rendszert

Az analízis fázis szemlélete

A legfontosabb szempontok: teljesség egyértelműség dokumentáltság A cél tehát a harácsolás!

A meglévő rendszer vizsgálata

Legfontosabb kérdések hogyan működik a jelenlegi rendszer melyek az tevékenységhez szükséges adatok milyen jelentések / összesítések készülnek hogyan használják az emberek a rendszert

ki milyen funkciókat használki milyen adatokat használ vagy termel

a rendszer kapcsolatai (input/output)szervezeten belüli és külső

A leendő rendszer vizsgálata

Legfontosabb kérdések hogyan fog a rendszer működni milyen adatok lesznek szükségesek milyen jelentések /összesítések lesznek hogyan változtatja meg az emberek munkáját továbbfejlesztési igények a szervezet jövőbeli

fejlődésestratégiája szempontjából

Alapvető nézőpontok

Melyek a célok megvalósításához szükséges feldolgozások (processzek)

az adatmozgás és feldolgozás lépései a rendszeren belülaz adatmozgás és adatfeldolgozás logikája, szabályai

adatok (a feldolgozásoktól független módon)struktúrajelentés (szemantika)mennyiség

Használható módszerek

a felhasználói munkafolyamat megfigyelése gyakorlat az adott területen interjúk kérdőívek az alkalmazás elméletének és gyakorlatának kutatása analógia más rendszerekkel meglévő dokumentációk tanulmányozása

eljárási szabályokbizonylatokjelentések, összesítésekszervezeti felépítésmunkaköri leírásokhatáskörök szabályozásavonatkozó külső előírásoktörvények, előírásokszerződések, megállapodások, vállalt kötelezettségek

CASE eszközökdokumentációs technikákteljesség és konzisztencia vizsgálata további fázisokban felhasználható formaadatszótár (repository)

prototípus készítésjobb kommunikáció a felhasználóval

a felhasználó időben felismerheti az igényei teljesíthetetlenségét vagy pontatlanságáta fejlesztő jobban megértheti a felhasználó munkamódszerét

Nagy rendszerek analízise

Az analízis fázis költséges és időigényes, ezért több lépcsőben végzendő megvalósíthatósági tanulmány

döntési pont projekt terv

döntési pont:átdolgozás / célok szűkítéseátütemezés

részletes analízisdöntési pont

megoldási alternatíva kiválasztásabefejezés – ez itt már költséges döntés!

Az egyes részfázisok csak a döntéshez szükséges mennyiségű és részletességű információt tartalmazzák.

6. A funkcionális, a nem funkcionális és a szakterületi, illetve a felhasználói és a rendszerkövetelmények.

A követelmény fogalma

Három absztrakciós szint: Felhasználói követelmények Rendszerkövetelmények Software terv specifikációja (a mi felosztásunk szerint ennek elkészítése a

specifikációs fázis feladata)

A követelmények osztályozása

Szokásos felosztás: Funkcionális követelmények (functional requirements) Nem funkcionális követelmények (nonfunctional requirements) Szakterületi követelmények (domain requirements)

Funkcionális követelmények

A rendszertől várt funkciók és szolgáltatások leírása Különböző részletezettséggel adhatók meg A felhasználó vagy a fejlesztő szempontjából is megfogalmazhatók Elvben teljesnek és ellentmondás mentesnek kell lennie A későbbi munkafolyamatok során felfedezett hiányosságok javítandók, így a

fejlesztés során egyre pontosabb leírást állítunk elő.

Nem funkcionális követelmények

Nem közvetlenül a rendszer szolgáltatásaira vonatkozó követelmények Általános rendszertulajdonságok, például megbízhatósági, biztonsági szint válaszidő,

kapacitás igények, minőségi jellemzők Környezettel való kapcsolat, például más rendszerekkel való kapcsolattartás, hardware

és software adottságok, abból adódó korlátozások szervezeti szabályok, törvényi előírások

A fejlesztési folyamatra vonatkozó előírásokhasználandó módszertanelőírt minőségbiztosítási modellelőírt (elvárt) fejlesztőeszköz

ProblémákNem mindig könnyű eldönteni, hogy egy követelmény funkcionális, vagy nem funkcionálisEgy nem funkcionális követelmény teljesítése új funkcionális követelmény megjelenését jelentheti (pl. adott biztonsági szinthez a felhasználó azonosítása szükséges)

Szakterületi követelmények

Nem közvetlenül felhasználói igényekből, hanem az alkalmazás által kiszolgált szakma követelményeiből adódik

Adhat újabb funkcionális vagy nem funkcionális követelményt Jelenthet korlátozást már megfogalmazott követelményhez Előírhatja egy adott rendszer funkció végrehajtásának módját

Problémák: A fejlesztők számára nehezen érthetők (szaknyelv!) Gyakran hiányosak, mert bizonyos szabályok a szakmai szakértők számára

nyilvánvalóak.

A követelmény fogalma

Három absztrakciós szint Felhasználói követelmények Rendszerkövetelmények Software terv specifikációja (a mi felosztásunk szerint ennek elkészítése a

specifikációs fázis feladata)

Felhasználói követelmények

A rendszer külső viselkedése a felhasználó fogalmaivalEszközei:

természetes nyelv közismert ábrázolási módok, táblázatok use-case modell (UML)

Problémák: egyértelműség hiánya követelmények keveredése követelmények összeolvadása

Célszerű elkülöníteni a technikai jellegű rendszerkövetelmény leírástólTippek:

használjunk egységes formátumot használjunk kiemeléseket ha szükséges, a mindennapi szavak jelentésében is egyezzünk meg (a "vagy" kizáró,

vagy megengedő vagy?) szótár!!!!

Rendszerkövetelmények

A felhasználói követelmények részletezése A rendszer teljes és konzisztens leírása A felhasználónak: alap a megbízási szerződéshez A fejlesztőknek: alap a rendszer specifikáció és a rendszer tevének elkészítéséhez Általában már tartalmaz formális modelleket (pl. osztálydiagram, stb)

7. A tervezési fázis feladata, szintjei. A külső tervezés feladatai.

A tervezési fázis célja

Válasz a HOGYAN kérdésre.Alapvető:

kreativitás gyakorlat

Itt kell először figyelembe venni a célkörnyezet hardware és software adottságait.

A célkörnyezet adottságai

Hardware adottságok:kapacitás (korlátok)hálózatspeciális eszközökarchitektúra

Software adottságok:fejlesztő környezetadatbáziskezelőoperációs rendszer

A tervezés szintjei

külső (interface) tervezés architekturális tervezés részletes tervezés

Külső tervezés

A software külvilággal való kapcsolatának megtervezése

Kapcsolatok:

"Csak" technikai kérdés: a más software-ekkel hardware elemekkel

való kapcsolat.

A felhasználói felület tervezése kulcskérdés, mert ez jeleníti meg a program funkcionalitását a felhasználó felé nem csak technikai szempontok vannak!

Kapcsolódó fogalom: HCI (Human-Computer Interface)Prototípus készítés hasznos lehet

Időben elhúzódó is lehet:

Architekturális tervezés

a rendszer struktúrájának megtervezése több lépéses folyamat a lépések száma a mérettől függ egy alacsonyabb szint a felette levő dekompozíciójával vagy az absztrakciós szint

csökkentésével jön létre bármely szinten álló struktúra modulok és a közöttük levő interface-ek rendszere

Strukturális tervezés

A tervezés végét jelzi, ha a modulok belső komplexitása és az interface-ek komplexitása

hasonló.Objektum-orientált megközelítésnél a modul az objektum!

8. Az UML története, fogalma, fõ tervezési célkitűzései, elemei (diagram típusai).

Szükségessége

Az objektum orientált fejlesztési módszerek a rendszer különböző nézőpontú modelljeit készítik el

A modellek dokumentálására megfelelő technikára van szükség A technikának szabványosnak kell lennie, mert ez

– segíti a fejlesztők közötti kommunikációt (közös nyelv),– lehetővé teszi a technikát támogató eszközök ("tool"- ok) készítését

Az UML története

Az 1990-es évek közepe - vezető módszertanok: Booch'93 (Booch): erős a tervezés fázisában, népszerű az engineering-intenzív

alkalmazásoknál. OMT2 (Rumbaugh) : erős az analízis fázis során, népszerű az adat-intenzív

alkalmazásoknál. OOSE (Jacobson) : kiváló támogatást ad a "business engineering"-hez, és igazan csak

ez támogatja a követelmény analízist. 1991-ben Grady Booch és Jim Rumbaugh (Rational Software Corporation) 1995 október: UML 0.8 1995-ben Ivar Jacobson is csatlakozott 1996. október: UML 0.91 1997. január 17.: UML 1.0 (OMG-nek!) 1997. szeptember: UML 1.1 (szabvány!) az utolsó teljes szabványos verzió az UML 1.5 (elfogadva 2003. március) Részben elfogadva: UML 2.0 (2006. március.)ok) készítését

Az UML fő célkitűzései

Kifejező vizuális modellező nyelv biztosítása– fejlesztés támogatása– kommunikáció támogatása

Lehetőség az alap koncepció bővítésére és specializálására– Alkalmazkodni tudjon a különböző fejlesztések szükségleteihez

Szokásos fejlesztés: elegendő legyen hozzá az alap eszköztárÚj elképzelésekkel az alapok módosítása nélkül legyen kiegészíthető (kiterjesztési mechanizmus)Egy adott alkalmazásterület speciális igényei szerint testre szabható legyen

Programozási nyelvtől és módszertantól független legyen Biztosítson formális alapot a modellező nyelv megértéséhez

– Precíz definíciók szükségesek az eszköz készítők számára– Érthető (nem túl formális) definíciók szükségesek a felhasználók számára– Megoldás: metamodell osztály diagrammok segítségével

Támogatja az objektum orientált eszközök fejlesztését– Számos felhasználó által ismert és használt, szabványos eszköz

Az eddigi gyakorlati tapasztalatok ("best practices") integrálása A magas szintű fejlesztési koncepciók támogatása: komponensek, keretrendszerek,

minták (patterns) stb.

A modell leíró nyelv elemei

A továbbiakban szereplő elemek az 1.5 verzió szerinti állapotnak megfelelőek. use case diagramm osztály diagramm viselkedés diagrammok :

– állapot diagramm (state diagram)– aktivitás diagramm (activity diagram)– sorrend diagramm (sequence diagram)– együttműködési diagramm (collaboration diagram)

implementációs diagrammok:– komponens diagramm (component diagram)– telepítési diagramm (deployment diagram)

kiterjesztési mechanizmusok– kiegészítő jelölések, amelyek több diagramtípus által is használhatók

Az UML tehát nem módszertan!

Kiterjesztési mechanizmusok

Az UML kiegészítő jelölései. Feladatai:– a szabványos jelölésrendszer "testre szabása"– a szabványos elemekkel nem leírható modell tulajdonságok rögzítése

Fajtái:– sztereotípia (stereotype): új modell elemek jelölésére– megszorítás (constraint): az UML más jelöléseivel meg nem adható tulajdonságok– kulcsszavas értékek (tagged values): modell elemek speciális jellemzőinek megadására– megjegyzések

Megjegyzések

Kapcsolható egy elemhez:

Sztereotípia

Formája:« megnevezés »

A minősített név előtt vagy fölött kell megadni. Ikon is rendelhető hozzá. Az egyes ábratípusoknál speciális sztereotípiák jelennek meg.

Megszorítások

Formája:{ megszorítás leírása }

A leírás lehet szöveges vagy formális. A formális leírásra egy ajánlat: OCL (Object Constraint Language, IBM) Megadható: minősített elem után vagy alatt kapcsolt megjegyzésben

Kulcsszavas értékek

Formálisan ez is megszorítás Adott névhez értéket rendel Érték önállóan is szerepelhet A fejlesztéssel kapcsolatos információkat is így rögzíthetjük Példák: { persistent }, {author="Ficsor", version=0.9.9, date=00.01.01}

9. A use case diagram szerepe, fõ elemei. (UML)

Use case diagram

Jacobson "hozománya"Use Case (használati eset):

interakció a felhasználó és az alkalmazás között a felhasználó által látható funkciót ír le konkrét felhasználói cél elérését rögzíti

A rendszer határait jelölhetjük ki.Lényeges szerepe van a követelmény analízis során

Aktor:

A felhasználó egy szerepe a rendszerben. Több felhasználó - egy aktor Egy felhasználó - több aktor Aktor lehet külső rendszer is

Use case:

Egy jól meghatározott funkció, amelynek végrehajtása a rendszer és egy külső entitás közötti üzenetváltást kíván. Jele:

A rendszer, egy alrendszer vagy egy osztály objektumai által végrehajtott funkció-együttes.Pontos leírása is szükséges (szöveges vagy egyéb diagram)

Példa

Fizetés a kasszánál:A vevő a kasszához megy a kiválasztott árukkal, a pénztáros leolvassa a vonalkódokat, a rendszer elkészíti a blokkot, a vevő fizet, a pénztáros elveszi az összeget.

Aktorok: vevő, pénztárosA rendszer válaszai: egységár a vonalkódokraUse-case-ek: vásárlás, blokkolás, fizetésÁbra:

kapcsolatok

Aktor és use case között: asszociáció (jelölhető a számossága is)Use case-ek között:

<<include>>: A1 use case magában foglalja A2- őt (részletezés, vagy ismétlődés kezelése)

<<extend>>: A1 use case működését A2 kiegészíti (többlet funkciók vagy speciális esetek)

Aktorok vagy use case-ek között: általánosítás (generalization)Ábra:

10. Az osztály diagram feladata, fő elemei. (UML)

Osztálydiagram

Osztályok és összefüggéseik ábrázolásáraA rendszer statikus strukturális modelljeHárom szint:

koncepcionális specifikációs implementációs - általában túl sok részlet, de

– dokumentáció– kódgenerálás

Rajzolható objektum diagram is, az osztályok példányainak felhasználásávalosztály szimbóluma:

objektum szimbóluma Egy konkrét objektum

Egy osztály tetszőleges objektuma

Megadhatók konkrét attribútum értékek is

Megjegyzés: az aláhúzás része a jelölésnek!

AttribútumokFormája:

láthatóság név : típus = alapértékA láthatóság jelölése:szabványos:+ public# protected- privatekoncepcionális szint:

az osztálynak van ilyen adata (pl. a vásárlónak van neve)specifikációs szint:

az osztálynak van adott típusú adata, amelyen meghatározott operációk hajthatók végre (pl. a vásárló neve beállítható, lekérdezhető)

implementációs szint: az osztály adott típusú mezője és az azokat kezelő módszerei

Operációk

Formája:láthatóság név(param) : típus{comment}

típus a visszatérési érték típusa param a paraméterlista (vesszővel elv.)

– azonosító : típus = alapértékKözöttük lehetnek az alábbi sztereotípusok:

– <<constructor>>– <<query>>– <<update>>– <<getting method>> vagy <<setting method>>

koncepcionális szint:a viselkedés lényegi elemei

specifikációs szint:az osztály publikus módszerei

implementációs szint:az osztály módszerei

Kapcsolat az egyes osztályok között: Asszociáció (általános kapcsolat) Nevesített kapcsolatok:

– általánosítás– tartalmazás (aggregáció és kompozíció)– beágyazott (osztály hatáskörben definiált) osztály, elsősorban az implementációs szintű diagrammokon

asszociáció

Jele vonal, tulajdonságai: kapcsolat neve, szerepkör (mindkét irányban), irányítása (egy-vagy kétirányú vagy nincs), a szerepkörök számossága

– n..m vagy n-m vagy n,m, ...,k– n,m stb lehet 0 vagy * (végtelen)– * magában a 0..* -ot jelenti.

A szerep kötött sorrendje is előírható. Az asszociáció minősítője is előírható. Az asszociációhoz a tulajdonságait leíró osztály is rendelhető

koncepcionális szint:viszony a fogalmak között

specifikációs szint:felelősségek

implementációs szint:az elérhetőség megvalósítása (pl. pointer, kulcs)

asszociáció (szerep)

A szerep lehet sorrendiségi, azaz jelölhetjük, hogy az objektumok kötött sorrendben vesznek részt az asszociációbanJelölése az {ordered} megszorítássalPélda:

Két osztály közötti asszociációhoz tartozhat több szerep isIlyenkor minden szerephez egy vonalPélda:

asszociáció (minősítő)

A minősítő konkrét értékei az asszociáció többes oldalán az objektumok egy példányát vagy egy részhalmazát jelölik ki.Jele:

asszociáció (tulajdonság)

Olyan tulajdonságokat, amelyek inkább az asszociációhoz, mint valamelyik osztályhoz rendelhetők, összefoglalhatunk egy harmadik osztályba, amelyet a kapcsolathoz rendelünk.Jelölés:

Asszociáció (többes)

Több osztály között fennálló asszociáció jelölése:

Általánosítás

Speciális (közvetett) viszony két osztály közöttkoncepcionális szint:

típus - altípus viszonyspecifikációs szint:

az alosztály interface-e rendelkezik az ősosztály interfac-ének minden elemévelimplementációs szint:

öröklődés (származtatás)

aggregáció és kompozíció

Kétféle egész - rész viszony: aggregáció: a rész az egészhez tartozik, de önállóan is létező entitás kompozíció: a rész önmagában nem létezhet, csak valaminek a részeként.

parametrizált osztály

interface

Az <<interface>> sztereotípiával, vagy egy körrel jelöljük Csak a metódusoknak van hely Interface-ek közötti lehetséges asszociáció: általánosítás Interface és osztály közötti lehetséges asszociáció:

implementálás, realizálás. Jele a példán.

11. A szekvencia diagram feladata, fõ elemei. (UML)

Eredete, feladata:

Időben lezajló, objektumok közötti üzenetváltások.Jelölhetjük:

Konkurens folyamatok működése Valós idejű folyamatok időhatárai Objektum létrehozása, lebontása Elágazás

Értelmezés:

Példaobjektumok egymás mellett az életvonalak tetején. Az idő fentről lefelé múlik.

Elemei:

Példaobjektumok Életvonal (lifeline) Vezérlési fókusz Aktivitási szakasz Üzenetek (stimulus) Megjegyzések az ábrától balra

Példaobjektumok

:osztály az osztály tetszőleges objektuma, nem fontos mi a neveobj:osztaly az obj nevű osztály típusú objektum (előtte, vagy felette), fontos a név (lehet, hogy több van belőle)Sávokba (swimlanes) csoportosíthatóak, pl. csomagok miatt

Üzenetküldés

(message passing) Kuldőtől a fogadóig nyíl, fontos a nyílhegy. Életvonaltól, életvonalig tart. Általában vízszintes. Sorszámozható. Címkézhető. Küldhető önmagának is.

Üzenetküldes fajtái

Szinkron (call)Aszinkron (send)Visszatérési (return) szaggatott vonalLétrehozó, lebontó (sztereotípiák)

Életvonal – vezérlési fókusz:

Ahol életvonal van, az objektum vagy passzív (léteznek az attribútumai), vagy várakozó (léteznek az attribútumai, csak feldolgozásra vár)Ahol vezérlési fókusz van, ott téglalap az objektum aktívvezérléssel rendelkezik, üzenetet küldhet.

Üzenet fajták

12. Az állapot diagram feladata, fõ elemei. (UML)

Állapot diagram (Statechart diagram):

Eredete, feladata: Időben lezajló állapotok, azok átmeneteinek - változások passzív módon -

szemléltetése Külső hatások reakciójának Az osztály bármely 1db objektumának állapotait ábrázolja Időbeli változások követése A reakció általában átmenet

Elemei: Alapelem az állapot (state) Átmenet (transition) Kezdő állapot (initial state) Végállapot (final state)

Állapot: Egy adott időpillanatban az objektum állapota. (adatainak, paramétereinek összessége) Időtartamot is jelenet: 2 időpillanat belépés, kilépés pillanata, közben idő telik el. Félbeszakadhat (pl. esemény hatására) Jele ívelt oldalú, kerekített sarkú téglalap

Átmenet: Időben lezajló változás elemi egysége, amikor egyik állapotból a másikba vált. Atomi, „időpillanat” alatt zajlik le Bekövetkezhet egy esemény hatására, ilyenkor ez lesz a címke. Mérföldkövek az objektum változásaiban. 2 egymás utáni átmenet (2 mérföldkő) meghatároz 1 állapotot

Példa: golyó viselkedése

Esemény: Olyan lényegi (significant) történés, amelynek adott helye és időpontja van. Objektumok megváltozását eredményezi. Nincs időtartama. Lehetnek paraméterei.

Fajtai:_ Üzenetek:_ Hívas-esemény (call event) szinkron, küldi vár_ Jelzés, vagy szignál aszinkron, a küldő nem várt objektumkent valositjuk meg, <<signal>> sztereotipiaIdő-esemény – timeout, ha lejárt, akkor átmegy a következő állapotba „after” kulcsszó utánVáltozás esemény adott időpillanat bekövetkezés „when” kulcsszó után

Esemény - átmenet Eseményhez őrszem is kapcsolható (condition, guard), akkor engedélyezi az

átmenetet, ha a feltétel teljesül. „[”, „]” jelek között. Átmenetekhez műveletek is csatolhatóak (ezek nem atomiak, és időtartammal

rendelkeznek) (action, effect), ezeket a „/” jel utan kell felsorolni pl.: szignalkuldesÁllapotok részletezése

Állapot neve vonal felett Vonal alatt lehetnek:

Bemeneti akció „entry/”Tevékenységek „do/”Kimeneti akció „exit/”

13. Az aktivitás diagram feladata, fõ elemei. (UML)Eredete, feladata:

Az alkalmazás dinamikája Időben lezajló változás (aktív oldal) Alapja a munkafolyamat diagram és a folyamatábra Szoros kapcsolat az UML állapotátmenet diagrammal, amely a passzív oldalról

közelít. Nem csak egymás utáni, hanem egymás melletti tevékenységek

Elemei:

Alapelem az aktivitás (activity) Átmenet (transition) Szinkronizációs vonal (synchronization bar) Döntési pont (decision) Kezdő állapot (initial state) Végállapot (final state)

Aktivitás

Tevékenység, amelyet meg kell csinálni Egy osztály 1 tagfüggvénye, annak 1 v. több utasítása (fontos

algoritmus) jele ívelt oldalú téglalap Végrehajtása időt vesz igénybe

Átmenet

Végrehajtandó tevékenységének időbeli sorrendje A nyíl hegye a tevékenység befejezése utáni következő tevékenységre mutat Jele a nyílhegyben végződő vonal Időpillanat szerű

Szinkronizácios vonal

Ha nem lényeges a sorrend, egymás melletti, vagy konkurens folyamatok jelölése ES KAPCSOLAT Szálakra bontja a vezérlést A szálak nem feltétlenül párhuzamos végrehajtásúak, csupán logikailag függetlenek. Ha nem szükséges a párhuzamosítás, akkor tetszőleges sorrendben egymás utáni

végrehajtás Jele egy vastag vízszintes vonal A szinkronizáció jelölése (ahol a párhuzamos részek találkoznak) Itt megvárjuk a szálak befejezését. A következő tevékenység, minden ág sikeres végrehajtása után következhet. Ha az elágazásnál volt, de a csatlakozásnál nincs, akkor az első befejezett szál

megszakítja a többit.

Döntés

Alternatív tevékenységcsoportok közötti választás, elágazás VAGY KAPCSOLAT A döntés kivezető éleit őrszemekkel címezhetjük Több kimenő éle is lehet

Kezdő-, végállapot:

Az alkalmazás kezdetét, végét jelölik. Pszeudo állapotoknak is nevezik. Nem kötelező használni. Végallapotból több is lehet.

Kezdő állapot Végállapot

Példa:

14. A Rational Unified Process (a továbbiakban RUP) története, fogalma, legfontosabb tulajdonságai.

Történet:

Feltételek:

Egyre nagyobb, komplex rendszerek Újrahasználhatóság, áttelepíthetőség Gyorsaság Team modell Modern algoritmusok Növekvő hardver erőforrások(előny/hátrány)

Általános séma:

Definiálja ki, mikor, mit, hogyan fog elkészíteni, hogy a kész rendszer a megfelelő célt szolgálja.

RUP definició

Keretrendszer, amely : Egységesített fejlesztési módszertan Adott elvek és módszerek alapján Meghatározott tevékenységsorozattal Előírja a fejlesztési folyamat lépéseit

Üzleti modell

Probléma: a menedzserek nem értik a programozói leírást. A RUP megoldotta a problémát: business Use-Case Jelölésrendszere megegyezik a Use Case-ével, de a cég üzleti folyamatait írja le, üzleti

ciklusokra bontva.

Unified Process tulajdonságai:

Keret rendszer Komponens alapú. Modellszemléletű Jól definiált interfészeken keresztül kapcsolódik. Az UML jelölésrendszerét használja. Használati-eset vezérelt (Use - Case Driven) Architektúra központú (Architecture Centric) Iteratív és inkrementáló (Iterative and Incremental)

Használati-eset vezérelt:

HASZNÁLATI ESET (USE CASE)A rendszer funkcionalitását fejezi ki: Megmutatja az adott feladat végrehajtásának az eredményét Megfogalmazza a felhasználónak a rendszerrel szemben támasztott elvárásait

Architectúra-központú

Az architektúra egy rendszer elemeinek és működési folyamatainak egyfajta strukturális nézete, amelyben kifejezésre jut, hogy az egyes részek hogyan működnek együtt, és hogyan kommunikálnak egymással.Az architektúra:

Elősegíti a statikus, dinamikus elemek modellezését A rendszert interfészeken keresztül kapcsolódó komponensek rendszereként

modellezi. Az architektúra a megbízó üzleti elvárásaiból ered

Szintjei: Üzleti – követelmény architektúra Logikai - koncepcionális (építőelemek, funkciók, szolgáltatások, együttműködés) Fizikai: technikai, technológiai megoldások (hardver, szoftver, komponens, kódok,

fájlok)

Réteg (layer): jól elhatárolható rész, elemei azonos jellemzőkkel, interfész típusokkalRétegei:

Felhasználói-specifikus alkalmazási Általános alkalmazási Középréteg (middleware) Rendszer – szoftver

A modellek felépítik, megjelenítik, dokumentálják az architektúrát:

Inkrementális

Előnyei:

Ha rossz útra tévedtünk, akkor csak az utolsó lépés eredménytelen. Kisebb a rizikó, a problémák hamarabb a felszínre kerülnek. Gyorsabb fejlesztés (tisztább, rövid részek). Minden lépés után "átadható" a rendszer. Könnyebben változtatható. Jobban újrahasználható. Jobb minőség.

15. A fázisok, iterációk és munkafolyamatok összefüggése a Rational Unified Process-ben.

Iteráció:

Elsőként csak a felhasználó-kritikus komponensekKésőbb a gyakorlati hasznosság szerint fokozatosan bővül

Létrehozni és ellenőrizni az architektúrát Definiálni a teszt feltételeket és a folyamatot Iterakciót megtervezni Felhasználói dokumentációt elkészíteni Telepíteni a rendszert begyűjteni a felhasználói reakciókat Szinkronizálni a modelleket

H. E. -al a rendszer funkcióit, az architectúrával a sikeres terméket szimbolizáljukAz architectúra egy durva becslést ad a nem specifikus H. E. kimeneteireH. E. alapján készül az alrendszer- és komponens- architectúraA H. E. specifikációk egyre világosabbá teszik az architectúrát.Előnyei:

Felhasználó nyugodt, igényei folyamatosan beépülnek Fejlesztő nyugodt, munkavégzés hatékonysága nő Kisebb a ráfordítási kockázat, hiba esetén csak egy iteráció költségei buknak Kisebb a sikertelenség kockázata, teszteléskor kiderülnek a problémák

Iterációk és munkafolyamatok / 1

"Mérföldkövek"

Minden fázisban 1 vagy több iteráció!

Ciklusok, fázisok, iterációk:

Statikus struktúra (elsődleges modell elemek)

Szerepkör (role)

A szerepkör a munkában résztvevő személy vagy személyek egy csoportjának viselkedését és felelősségi körét definiálja.

Viselkedés: a szerepkörhöz rendelt tevékenységek Felelősségi kör: azok a termékek, amiket létrehoz, módosít. Személy (resource): konkrét élő személyek pl.: Lajos, Dénes, Gyuri, Miki, ... Szerepkör: designer, design reviewer, architect, use case author stb. Szerepkör : Személy = n : m Egy személy akár egy munkanapon belül is betölthet több szerepkört. A szerepkörök és a személyek közötti leképezés megtervezése a projekt menedzser

feladata.

Tevékenység (activity)

A munka egy egysége, amelyet egy a személynek egy adott szerepkörben kell elvégeznie.

A projekt szempontjából szükséges eredménye vanÁltalában egy termék létrehozása, vagy frissítése (modell, osztály, terv)

Minden tevékenység egy adott szerepkörhöz rendelt. Általában néhány órát, max. néhány napot vesz igénybe. Általában egy személy végzi, és kevés személyre van hatása Egy adott tevékenység a projekt során többször ismétlődhet, ugyan ahhoz a

szerepkörhöz, de nem feltétlenül ugyan ahhoz a személyhez rendelve.Példák:

Execute performance test (Performance Tester) Plan an iteration (Project Manager) Review the design (Design Reviewer)

Termék (artifact)

Egy része az információnak, amelyet használ, módosít vagy eredményez a fejlesztési folyamat.

Egy szerepkör egy tevékenységének bemenete és/vagy eredménye. Példák: modell, forrás kód, bináris kód, dokumentum Egy termék más termékekből állhat össze. (Például egy tervezési modell számos

osztály tervét tartalmazza.)

Munkafolyamat (workflow)

Tevékenységek sorozata, melynek eredménye van, vagy kapcsolat a személyek között.

A magyar szóhasználat kialakulatlansága miatt a "munkafolyamat" kifejezést két értelembenis szokás használni:

workflow (javaslatom: munkafolyamat) discipline (javaslatom: résztevékenység)

Vegyes nyelven (de ezáltal pontosabban) fogalmazva: Egy discipline végrehajtási módját egy hozzá rendelt core workflow definiálja.

16. Az egyes fázisok és fő feladatuk a Rational Unified Process-ben.

Kezdeti fázis, felmérés (Inception)

Tárgya A projekt hatáskörének meghatározása Minden külső tényező meghatározása Azonosítása minden H.E.-nek, a kritikusak kidolgozása (max 20 %) Alap rizikó becslése Nagyvonalú projekt terv elkészítése: iterációkra, fázisokra bontás

Alapvető termékek Egy "vision" dokumentum Use case modell, amely felsorolja mindazokat az aktorokat és use case-eket, amelyek

ebben a fázisban azonosíthatók. Kezdeti szójegyzék (Glossary). Kezdeti kockázat lista. Projekt terv (fázisok, iterációk). Gyakran egy kezdeti prototípus.

Kidolgozási fázis (Elaboration)

Tárgya A problématér (problem domain) analízise. A projekt terv részletes kidolgozása A legfontosabb nem funkcionális követelmények definiálása H. E. m. legalább 80 %-os kidolgozása (minden H. E. , és aktor definiált)

Alapvető termékek Use case modell (min. 80%-os készültségben) Kiegészítő (nem funkcionális, illetve use casehez nem köthető) követelmények Szoftver architektúra leírás Végrehajtható architekturális prototípus Továbbfejlesztett kockázati lista Részletes projekt terv Részletes projekt terv

Kivitelezési fázis (Construction)

Végleges felhasználói kézikönyv Kész szoftver termék Teljes leírása a terméknek Általában ezen fázis végén jön létre a béta Verzió

Átalakulási (átadási) fázis (Transition)

Béta teszt Dokumentációk frisssítése, ha szükséges Végleges telepítés, konfigurálás Felhasználók oktatása Gratulációk fogadása

Üzleti modellezés

Feladata: a szervezet céljainak és struktúrájának feltárása feltárni a szervezet aktuális problémáit meggyőződni arról, hogy a felhasználók és a fejlesztők ugyanazt látják a rendszer követelményeinek levezetése a szervezet igényeiből

Követelményfeltárás:

Ötletek begyűjtése (rövid név - rövid leírás) Státusz Becsült implementálási költség Prioritás Rizikószint Eredménye: tulajdonság lista

A rendszer tartalmának megértése Azonosítani, elnevezni az objektumokat Eredménye: Business vagy domain modell

Funkcionális szükségletek begyűjtése. Használati-eset modellek elkészítése.(A H.E. a rendszer használatának egy lehetséges

módja) Eredménye: H. E. modell

Nem funkcionális szükségletek begyűjtése. Környezeti, implementálási kényszer (pl.: max 1000 sor), teljesítmény, biztonsági

követelmény Eredménye: doksi, esetleg H.E.

Használati-eset modell

Analízis

Szükségletek mélyebb megértése, javítása,részletezése A rendszer belsejének meghatározása Külső rendszer nézet -> belső - | | - Eredménye: analízis modell, kontroll osztályok

Tervezés

Megérteni teljes mélységében: UI topológiát, DB technológiát, Szétbontani a feladatot több menedzselhető részre. (Team modell.) Definiálni a fő interfészeket a részrendszerek között. Vizuálisan ábrázolni amit lehet Elkészíteni egy absztrakt rendszer implementációt Termék: design model, design class, interface, architecture description

Analízis, tervezési model

Implementálás

A rendszert teljesen kidolgozni Szétosztani a rendszert több futtatható komponensre Elkészíteni a forrásfájlokat, szkripteket. Komponens teszt, előállítani a futtatható bináris állomány(oka)t Eredmény: komponens (forrás, bináris, könyvtár, tábla, doksi, csomag, ...), interfész

Telepítési és megvalósítási modell

Teszt

Vázolni a tesztet, minden iterációban integrációs, legutolsóban rendszer teszt Megtervezni, implementálni a tesztet. Elkészíteni a teszt osztályt, meghatározni mit

fog tesztelni Szisztematikusan mérni a teszt eredményeket, és azok teljesítményét Eredmény: teszt modell

Teszt model

17. A személy, tevékenység, termék és munkafolyamat fogalma és szerepe a Rational Unified Process-ben.

Szerepkör (role)

A szerepkör a munkában résztvevő személy vagy személyek egy csoportjának viselkedését és felelősségi körét definiálja.

Viselkedés: a szerepkörhöz rendelt tevékenységek Felelősségi kör: azok a termékek, amiket létrehoz, módosít. Személy (resource): konkrét élő személyek pl.: Lajos, Dénes, Gyuri, Miki, ... Szerepkör: designer, design reviewer, architect, use case author stb. Szerepkör : Személy = n : m Egy személy akár egy munkanapon belül is betölthet több szerepkört. A szerepkörök és a személyek közötti leképezés megtervezése a projekt menedzser

feladata.

Tevékenység (activity)

A munka egy egysége, amelyet egy a személynek egy adott szerepkörben kell elvégeznie.

A projekt szempontjából szükséges eredménye vanÁltalában egy termék létrehozása, vagy frissítése (modell, osztály, terv)

Minden tevékenység egy adott szerepkörhöz rendelt. Általában néhány órát, max. néhány napot vesz igénybe. Általában egy személy végzi, és kevés személyre van hatása Egy adott tevékenység a projekt során többször ismétlődhet, ugyan ahhoz a

szerepkörhöz, de nem feltétlenül ugyan ahhoz a személyhez rendelve.Példák:

Execute performance test (Performance Tester) Plan an iteration (Project Manager) Review the design (Design Reviewer)

Termék (artifact)

Egy része az információnak, amelyet használ, módosít vagy eredményez a fejlesztési folyamat.

Egy szerepkör egy tevékenységének bemenete és/vagy eredménye. Példák: modell, forrás kód, bináris kód, dokumentum Egy termék más

termékekből állhat össze. (Például egy tervezési modell számos osztály tervét tartalmazza.)

Munkafolyamat (workflow)

Tevékenységek sorozata, melynek eredménye van, vagy kapcsolat a személyek között.

Lehetséges írásbeli kérdések a Számítógép hálózatok tantárgy tananyagából

1. Számítógép-hálózatokhoz kötődő alapfogalmak és az ISO-OSI hivatkozási modell

1.a Számítógép-hálózatokhoz kötődő alapfogalmakA számítógép-hálózat fogalma, funkciói, jellemzői, topológia és méret szerinti osztályozásuk.1.b A számítógép-hálózatok kapcsolástechnika szerinti osztályozásaA vonalkapcsolás, üzenetkapcsolás, csomagkapcsolás és virtuális vonalkapcsolás, főbb jellemzői, összevetésük.1.c A számítógép-hálózatok ISO-OSI hivatkozási modelljeAz ISO-OSI hivatkozási modell szerkezete, rétegei és azok főbb funkciói. A réteg, interfész, funkcionális elem, protokoll és hálózati architektúra fogalma.

2. A számítógép-hálózatok ISO-OSI hivatkozási modelljének fizikai rétege

2.a Alapfogalmak és elméleti sebesség korlátokA számítógép-hálózatok fizikai rétegének funkciói, az átviteli közegekkel kapcsolatos elvárások, közeg osztályok, főbb típusok, közeg összevetési szempontok. A csatorna adatátviteli és jelzési sebessége sávszélesség, zajmentes (H. Nyquist) és véletlen zajjal terhelt (Claude Shannon) sávkorlátozott csatornán elérhető maximális adatátviteli sebesség.2.b Fémes vezetők átviteli közegA sodrott érpár és koaxiális kábel átviteli közegek, felépítésük, főbb típusaik, alkalmazásuk, főbb jellemzőik és összevetésük.2.c Fényvezetők átviteli közegA multi- és monomódusú optikai kábelek, felépítésük, főbb típusaik, alkalmazásuk, főbb jellemzőik (veszteség típusok) és összevetésük.2.d. Vezetéknélküli átviteli közegeFőbb vezetéknélküli átviteli módszerek, alkalmazási területeik, főbb jellemzőik és összevetésük.2.e. Jelkódolási és modulációs módszerekJelkódolás és moduláció, alapfogalmak, néhány konkrét jelkódolási és modulációs módszer.

3. A számítógép-hálózatok ISO-OSI hivatkozási modell adatkapcsolati rétegének közeghozzáférési alrétege

3.a Csatorna-megosztási módszer osztályokA főbb csatorna-megosztási osztályok (statikus - dinamikus, dinamikus versengő - determinisztikus) bemutatása és azok összevetése.3.b Statikus csatorna-megosztási módszerekNéhány módszer bemutatása és azok összevetése.3.c Dinamikus versengő (ütközéses) csatorna-megosztási módszerekNéhány módszer bemutatása és azok összevetése.3.d Dinamikus determinisztikus (ütközésmentes) csatorna-megosztási módszerekNéhány módszer bemutatása és azok összevetése.3.e. Az "ALOHA" csatorna-megosztási módszer áteresztőképességének becslése a csatornaterhelés függvényébenA becslés főbb lépései "tiszta"és "réselt" ALOHA esetén.

4. A számítógép-hálózatok ISO-OSI hivatkozási modell adatkapcsolati réteg – az IEEE 802 LAN szabványcsalád

4.a Az IEEE 802.3 (CSMA/CD) - támogatott közegek és sebességekTámogatott közegek és sebességek bemutatása, működés duplex csatorna esetén.4.b Az IEEE 802.3 (CSMA/CD) - keretformátum, MAC címekA 802.3 és az Ethernet keretformátum, MAC címek.

4.c Az IEEE 802.11 (Wireless LAN) – struktúraAz IEEE 802.11 WLAN általános felépításe,az Access Point (AP) főbb funciói.4.d Az IEEE 802.11 (Wireless LAN) – fizikai közeg, modulációs módokTámogatott fizikai közegek és szórt spektrumú moduláciás módok4.e Az IEEE 802.11 (Wireless LAN) – közeghozzáférés vezérlésKeretformátum, az alkalmazott közeghozzáférési módszer (CSMA/CA), Distributed Coordination Function (DCF) és Point Coordination Function (PCF)üzemmódok.

5. A számítógép-hálózatok ISO-OSI hivatkozási modelljének adatkapcsolati rétege - keretképzés és felismerés

5.a Keretképzés és felismerésA keretképzés és felismeréscélja; a karakter-számlálásos, a karakter-beszúrásos, a bitbeszúrásos és az érvénytelen kódmintás keretezési módszer bemutatása.5.b Közvetett és közvetlen hibavédelem, kódolásA közvetett és közvetlen hibavédelem; alapfogalmak; hibajelző és hibajavító kódolás; néhány tipikus hibajelző kódolási módszer bemutatása.5.c Elemi adatkapcsolati protokollokAz elemi adatkapcsolati protokollok általános funkciói (közvetett hibavédelem, adatfolyam vezérlés), korlátozás nélküli szimplex (utópia), szimplex megáll és vár protokoll, szimplex protokollok zajos csatornára, forgóablakos protokollok.

6. A számítógép-hálózatok ISO-OSI hivatkozási modelljének hálózati rétege – funkciói, szervezése

6.a Funkciói, szervezéseA hálózati réteg funkciói, virtuális áramkörön alapuló és összeköttetés mentes hálózat-szervezés.6.b ForgalomirányításKövetelmények, forgalomirányítási módszerek, információgyűjtési és döntési módszerek, egyutas, többutas és táblázat nélküli módszerek.6.c Torlódás vezérlésA torlódásvezérlés célja; pufferek előrefoglalása, csomageldobás, lefojtó-csomagok módszere, izaritmikus és forgalomszabályozásos torlódásvezérlés.6.d A hálózatközi együttműködés – heterogén hálózatok kialakításának eszközeiA hálózatközi együttműködés eszközei (ismétlő, híd, forgalomirányító), jellemzőik, működésük.

7. A TCP/IP protokoll szövet és az Internet

7.a A TCP/IP protokoll szövet struktúrájaAz Internet hivatkozási modell (DoD) és az ISO-OSI hivatkozási modell összevetése. A TCP/IP protokoll szövet főbb részei (ARP, RARP, IP, ICMP, TCP, UDP) és azok funkcióik.7.b Az Internet címzés és címosztályokIP címosztályok, maszk, subnet, supernet, osztály nélküli címzés (CIDR Classless Inter-Domain Routing), és a változó alhálózat méretek(VLSM Variable Length Subnet Mask); címek kiosztása, lokális címek és a címfordítás (NAT).7.c Az IP csomagformátumAz IP csomagformátum főbb mezői és azok funkciói.7.d Az IP csomagok továbbításaHelyi és távoli kézbesítés, forgalomirányító, enkapszuláció.7.e Az UDP datagram és a TCP szegmens felépítéseAz UDP datagram fej és a TCP szegmens fej főbb mezői és azok funkciói.7.f Az IPv6

Az IPv6 címek, IPv6 cím típusok (unicast, multicast, anycast; link local, site local, global scope), azIPv4 és IPv6 keretformátumok összevetése.

1. Számítógép-hálózatokhoz kötődő alapfogalmak és az ISO-OSI hivatkozási modell

1.a Számítógép-hálózatokhoz kötődő alapfogalmakA számítógép-hálózat fogalma, funkciói, jellemzői, topológia és méret szerinti osztályozásuk.

Számítógép hálózat: Autonóm számítógépek összekapcsolt hálózata. Nem alárendelt kapcsolat (pl. számítógép periféria). Tetszőleges kommunikációs alrendszer kötheti össze őket (elektronikus információcsere)Elosztott rendszer: Egyetlen virtuális rendszer, aminek elemei együttműködnek egy feladat megvalósítása érdekében, ahol a felhasználónak nem kell azonosítania a gépeket, szolgáltatásokat, nem kell ismernie azok helyét. Elosztott rendszert implementálható számítógép hálózatra. Az egyes elemek konkrét helye, funkciói el vannak rejtve

A gazdagépeket összekötő kommunikációs hálózat (Communication Network) (ez maga a hálózat) elemei és célja: Elemei:

1. Átviteli vonalak: csatornák (channels). 2.Kapcsolóelemek: Interface Message Processor (IPM), vagy csomag (vonal) kapcsoló csomópont, vagy csomópont (Node) amivel egy gazdagép egy vonalra kapcsolódik.3.Kapcsológépek: Olyan számítógép, ami több átviteli vonalhoz kapcsolódik és feladata (üzenet)csomagok továbbítása, átviteli vonalai közötti forgalomirányítás.

Célja:Hosztok közötti üzenettovábbítás

A hálózat célja Erőforrás összevonás/megosztás

Minden erőforrás a fizikai helyétől függetlenül bárki számára elérhető legyen Megbízhatóság növelés

Több azonos funkciójú erőforrás, redundancia, adatbiztonság, Gazdaságosság növelés

Pl. egy drága szupergép helyett több, kisebb, olcsóbb – GRID computing Új (speciális) szolgáltatások: a kommunikáció

Pl. e-mail, chat

Kiterjedés (méret) szerinti osztályozásuk Lokális számítógép-hálózat (LAN- Local Metropolitan Area Network)

≈ 0-1 km, szoba-épületcsoport, kis távolság, nagy sebesség Városi számítógép-hálózat (MAN – Metropolitan Area Network)

<10 km, közepes táv, közepes sebesség Nagytávolságú-hálózat (WAN – Wide Area Network):

kontinensekre, nagytáv, közepes vagy kis sebesség Összekapcsolt nagytávolságú hálózat bolygóra kiterjedő

A sebességhatárok elmosódnak! LAN-MAN –WAN, ma már mind Gbps nagyságrendű

Hálózatok csoportosítása:

1.Pont-pont közötti kapcsolatokból felépülő: Egy csatornán mindig két csomópont kommunikál. Az (üzenet)csomagokat a csomópontok tárolják és továbbítják a kívánt irányba (store and forward). Topológiák: csillag, gyűrű, fa, teljes, szabálytalan. Általában WAN, MAN, ma már LAN is (UTP)

2.Üzenetszórásos csatornára épülő hálózat(broadcast channel): Egyetlen csatornán az összes csomópont osztozik. Egy csomópont által feladott (üzenet)csomagot az összes többi veszi, de a csomagbeli címzésből tudják, kinek szól (a többi eldobja). Címmezőkben a feladó és a címzett címe. Vannak speciális címek (valamennyi gépnek szóló-broadcast, csoport cím-multicast) Topológiák: sín, gyűrű, műholdas v. rádiós. Tipikusan LAN vagy rádiós hálózat.Gond: Egyszerre csak egy állomás adhat, csatorna kiosztási probléma.A csatornakiosztás lehet:

Statikus: pl. ciklikus multiplexálás (kiválasztás), (pl.: round robin)Gond: ha nincs adnivaló akkor kihasználatlan csatorna.

Dinamikus: csak azok versenyeznek, akik adni akarnak (jobb csatornakihasználtság).Lehet:

centralizált (központosított): egy arbitrációs (ütemező) egység dönti el, hogy ki a következő.decentralizált (elosztott): minden állomás maga dönt, hogy adhat-e (elosztott algoritmus)

1.b A számítógép-hálózatok kapcsolástechnika szerinti osztályozásaA vonalkapcsolás, üzenetkapcsolás, csomagkapcsolás és virtuális vonalkapcsolás, főbb

jellemzői, összevetésük.

Vonalkapcsolt hálózat Kapcsolat felépítés (connection) a végpontok között, időigényes lehet a dedikált vonalon kommunikáció a végpontok között ( elöny: nincs torlódás), végül

kapcsolat bontás. Impulzusszerű (burst-ös) forgalom esetén nem kedvező. Kihasználatlanság léphet fel Pl. a nyilvános kapcsolt telefonhálózat ilyen.

Üzenetkapcsolt hálózat Teljes üzenet feladása megtörténik, a csomópontok tárolják, majd továbbítják (store-

and-forward) az üzenetet. Nincs korlát az üzenet méretére. Tetszőlegesen nagy késleltetés (nem valós idejű), prioritások kialakíthatók Tetszőlegesen nagy tárolókapacitás igény a csomópontokon A torlódás kontrollálható, jól kihasználja a médiát

Csomagkapcsolt hálózat Felülről korlátos méretű csomagokat állítanak elő az üzenetek feldarabolásával A csomópontok között kapcsolaton (link-en)dinamikusan osztoznak a csomagok Korlátos tárolókapacitás igény a csomópontokon, kisebb késleltetés lehetséges

(interaktív kommunikációra is alkalmas) Nagyobb lehet az átbocsátó képesség. ( Lehetőség van az átlapolt működésre, azaz

hosszabb üzenet első csomagjait már feldogozzák, mikor a többit még csak adják )

Virtuális vonalkapcsolás Csomagkapcsolás, de

logikai útvonal alakul ki a végpontok között,a csomagok ugyanazt az útvonalat használják (ezért feladási sorrendjükben érkeznek).Hasonlít a vonalkapcsoláshoz, de az útvonal nem dedikált (más csomagok is osztoznak egyes linkeken).A logikai útvonal létesítéséhez kapcsolat felépítés kell

Szembesítve a datagram kapcsolással:ennél minden csomag függetlenül továbbítódik,sorrend “felborulhat” (rendező protokoll kell),nem kell kapcsolat felépítés.

1.c A számítógép-hálózatok ISO-OSI hivatkozási modelljeAz ISO-OSI hivatkozási modell szerkezete, rétegei és azok főbb funkciói. A réteg, interfész,

funkcionális elem, protokoll és hálózati architektúra fogalma.

Hálózati architektúraRéteg:

Jól definiált szolgáltatásokat nyújt a felette lévő rétegnek Elrejti a szolgáltatások megvalósításának részleteit („fekete dobozos” tervezés)

Interface: Az alsóbb réteg által a felsőnek nyújtott elemi műveletek és szolgálatok definíciója Az interfészen keresztül (le és fel) vezérlő információk és adatok adódnak át

Funkcionális elem (entity): Az adott réteg funkcióinak megvalósítása A funkcionális elem a réteg alatt és felett lévő szolgáltatásokat köti össze.

Protokoll: A kommunikáció során használt szabályok és konvenciók összessége.

Hálózati architektúra: Rétegek és protokollok halmaza Elegendő információ az implementáláshoz Nem része sem a részletes implementáció, sem az interfészek specifikációja

Társelemek (peer entities): A különböző gépeken egymásnak megfelelő rétegben lévő funkcionális elemek.

Virtuális kommunikáció: A társelemek kommunikációja

Fizikai kommunikáció:A rétegek közötti interfészeken keresztül lefelé, ill. felfelé adat és vezérlő információk átadása. Ha az egyik gép n. rétege egy másik gép n. rétegével kommunikál az virtuáliskommunikáció míg, a valós kommunikáció ui. a fizikai rétegben történik).

Hivatkozási (referencia modell):Megadja a rétegek ajánlott számát és a rétegek funkcióit. Nem határoz meg protokollokat, interfészeket, de a hivatkozási modell ismeretében protokollokat alkothatunk.

ISO-OSI réteg kialakítási szempontok: A rétegek különböző absztrakciós szinteketképviseljenek és jól definiált feladatokat hajtsanak végre. A feladatok megválasztása során szabványokat teremtsenek. Minimális információcsere legyen a rétegek között. A rétegek száma ne legyen túl sok (egyszerűség), de elég sok, hogy egy rétegbe kevés feladat kerüljön.

Ajánlott 7 réteg:Fizikai réteg (bitfolyam): A bitek kommunikációs csatornán való áthaladásáért felelős.

1-es bitek reprezentációja kapcsolat felépítés/bontás a közeg és csatlakozók fizikai kialakítása (hány tüske, milyen dugó) adatátviteli irányok meghatározása (szimplex, félduplex. fullduplex)

Az adatkapcsolati réteg(keretek): A hálózati réteg számára hibamentes átvitelt biztosít. keretképzés és behatárolás (fizikai rétegnek megfelelően) hibák ellenőrzése, javítása (kódolás, nyugta küldés, fogadás) adatfolyam vezérlés, forgalom szabályozás (lassú vevő, forgalom leállítás) szükség esetén csatornamegosztás( üzenetszórásos médiumhoz való hozzáférés, pl.:

LLC, MAC )A hálózati réteg(csomagok): A kommunikációs hálózat működését vezérli.

csomagok forrás- célállomás közötti útvonalak meghatározása torlódás vezérlés ( ne legyenek túlterhelt részek a hálózaton ) heterogén hálózat összekapcsolás ( a csomópont minimum 3 réteget tartalmaz)

A szállítási réteg (datagram, szegmens): A viszonyréteg üzeneteinek továbbítása, valódi forrás-cél réteg. Míg az alsóbb rétegekben társelemek nem feltétlenül a valódi forrás-cél elemek, itt azok valódiak).

üzenetek tördelése,ill. összeállítása összeköttetések létrehozása több egyirányú kérés multiplexálás; -hibakezelés, több hálózati összeköttetés számára

egy hálózati összeköttetés egy hálózati összeköttetés számára több hálózati összeköttetés, nagyobb átbocsátó

képesség adatáramlás vezérlés (lassú feldolgozás, forrást állít meg) hibakezelés összeköttetés típusok: hibamentes sorrendhelyes, hibamentes nem sorrendhelyes

Viszonyréteg(üzenetek): Különböző gépek között felhasználói viszonyok létesítése. párbeszédek szervezése szinkronizáció (nagy mennyiségű adat átvitele esetén szinkronizációs pontok, hogy

meghibásodás esetén csak onnét ismételjük az adatátvitelt) kölcsönhatás menedzselés (a két oldal egyidejűleg ne próbálkozzon ugyanazzal a

művelettel)Megjelenítési réteg(üzenetek): Az átviendő információ szintaktikájával és szemantikájával foglalkozik. Gyakori általános megoldású feladatok elvégzése.

kód konverzió titkosítás tömörítés

Alkalmazási réteg(üzenetek): Széles körben igényelt protokollokat tartalmaz. fájl és nyomtatásszolgáltatások

Fájl-átvitel (ftp), tárolás és migráció, arcíválásTávoli nyomtatás, rajzolás, fax

kommunikációs szolgáltatásokPl. elektronikus levelezés (SMTP, MIME), levelező listák, news

Directory szolgáltatásokCímek, telefonszámok, szolgáltatások, hálózati objektumok stb.lekérdezése

Alkalmazás szolgáltatásEgységes terminál-leírás: virtuális terminál, távoli géphasználat (ssh), böngészők (WWW) Adatbázis szolgáltatás

2. A számítógép-hálózatok ISO-OSI hivatkozási modelljének fizikai rétege

2.a Alapfogalmak és elméleti sebesség korlátokA számítógép-hálózatok fizikai rétegének funkciói, az átviteli közegekkel kapcsolatos elvárások, közeg osztályok, főbb típusok, közeg összevetési szempontok. A csatorna

adatátviteli és jelzési sebessége sávszélesség, zajmentes (H. Nyquist) és véletlen zajjal terhelt (Claude Shannon) sávkorlátozott csatornán elérhető maximális adatátviteli sebesség.

Fizikai réteg (bitfolyam): A bitek kommunikációs csatornán való áthaladásáért felelős. 1-es bitek reprezentációja kapcsolat felépítés/bontás a közeg és csatlakozók fizikai kialakítása (hány tüske, milyen dugó) adatátviteli irányok meghatározása (szimplex, félduplex. fullduplex)

A fizikai közegek Az átviteli közegek. Céljuk: a nyers bitfolyam szállítása Jellemzőik:

1. az elérhető adatátviteli sebesség (jel/zaj viszony alapján a Shannon tételből),2. alapsávú impulzus átvitel3. szélessávú (modulációs) átvitel.

Az jelfrissítés nélkül áthidalható maximális távolság, a zavarvédettség, megbízhatóság (mechanikai tulajdonságok), üzenetszórásra, pont-pont átvitelre, esetleg mindkettőre való alkalmasság, ár, költségek.

Az átviteli közeg Fémes vezetők (elektromos áram) (Copper)

Sodrott érpárKoaxiális kábel

Fényvezetők (fényhullámok)Üveg, műanyag (fibre optic)

Vezetéknélküli átvitel (elektromágneses hullámok)mikrohullám,műholdas,optikai infravörös, lézeres stb.

Csatorna átviteli sebessége[bps]: átvitt adatmennyiség[bit]/idő[sec].A csatorna jelzési sebessége(1 mp-re eső jelzésváltás szám)[baud]: átvitt jelzésszám[db]/idő[sec].Csatorna jelterjedési sebesség[m/sec]: Jelterjedés távolsága[m]/idő[sec].Csatorna sávszélesség: A legmagasabb és legalacsonyabb átvitt frekvenciák különbsége. Egy valóságos csatorna sávkorlátozott...(teljesítményveszteség, szűrők miatt).Zajmentes, sávkorlátozott csatornán elérhető maximális adatátviteli sebesség: Nyquist: Ha tetszőleges jelet H sávszélességű alul-áteresztő szűrőn átengedünk, akkor szűrt jelből másodpercenként 2H-szor mintát véve az eredeti jel teljesen visszaállítható. Ebből: Max adatátviteli sebesség=2*H*log2V ahol H: sávszélesség, V: a jel diszkrét értékeinek száma (jelzések száma). C. Shannon határozta meg a véletlen (termikus) zajjal terhelt csatornákra az elméleti maximális adatátviteli sebességet. Max elérhető adatátviteli sebesség= H - log2(l+S/N); ahol H: sávszélesség, S/N: a jel-zaj viszony. Decibelben: S/NdB=10*log10(S/N).

Shannon: Zajos sávkorlátozott csatornán a maximális adatátviteli sebesség független a jelszintek (jelzések) számától, a mintavételezési gyakoriságtól. Gyakorlatban a korlát megközelítése is nehéz

2.b Fémes vezetők átviteli közegA sodrott érpár és koaxiális kábel átviteli közegek, felépítésük, főbb típusaik, alkalmazásuk,

főbb jellemzőik és összevetésük.

Sodrott érpár (Árnyékolatlan):

Telefondrót: pont-pont kapcsolatra közeli központig (2-4 km), modulált átvitel néhány Mbps közepes zavarvédettség, és megbízhatóság olcsó megoldás Sodrás, nem sodrott keretantennák, a sodrott

kiegyenlítettebb

STP(Árnyékolt csavart érpár):

Árnyékolás, csökkenti az interferenciát, áthallást jó zavarvédettség és megbízhatóság 4 vezeték(adás/vétel) vastagabb kötegek 1Gbps max. 25m valamivel drágább mint a sodrott

UTP(Árnyékolatlan csavart érpár):

közepes zavarvédettség és megbízhatóság valamivel olcsóbb, könnyű szerelni 4 vezeték adás/vétel ág 100m max. alapsávi impulzus átvitel

A koaxiális kábel (1 ponton földelni)

Mind pont-pont, mind üzenetszórásra alkalmas Tipikus LAN alkalmazás(TV) Felépítés: rézmag, szigetelő dielektrikum,

fonott külső vezető, műanyag burok Tipikus hullámimpedanciák:

50: adat és rádiós kábel75: TV koaxiális kábel93: ARCNET kábel (Novell)

jó zavarvédettségű, jó megbízhatóságú. Közepesen drága (a vékony Ethernet olcsóbb, mint az UTP). Üzenetszórásos csatorna (busz) kialakítás koaxiális kábelen:

Egyetlen tápvonal, a végein hullámimpedanciával lezárva. Nagyimpedanciás csatlakozásokT dugó, vagy rászúrható, „vámpír” csatlakozás (működés közben is csatolható/bontható)

2.c Fényvezetők átviteli közegA multi- és monomódusú optikai kábelek, felépítésük, főbb típusaik, alkalmazásuk, főbb

jellemzőik (veszteség típusok) és összevetésük.

Optikai kábel

„Hajszálvékony” üveg (szilikát) szál,fényhullámokat "vezet" Kiváló zavarvédettség, jó megbízhatóság. Jelenleg kb. max. 10 Gbps 10km távolságon Tipikusan pont-pont kapcsolatokra. Magas költségek (csatlakozók, toldások)

Fénykábelek:

A fény a kritikus szög alatt visszaverődik, fölötte elnyelődik. Látható fény frekvencia: közel 108 MHZ, óriási sávszélesség A fényhullámhossz és a magátmérő viszonyától függően lehet:

MultimódusúMonomódusú

Multimódusú szál:

Magátmérő>fényhullámhossz; - A fény a határfelületeken visszaverődve halad a különböző hullámhosszú fémhullámok különböző időben érkeznek Szokásosan az adó: LED, vörös látható (hullámhossz: 850nm), a vevő

fotodióda/tranzisztor Áthidalható<10km Adatátviteli sebesség: <10 Gbps.

Monomódusú szál:

Magátmérő=fény hullámhossz hullámőrző tulajdonság: a fény „elhajlik" a szállal Az adó félvezető lézer, infravörös 1300nm hullámhossz kisebb csillapítás, nagyobb áthidalható távolság, kb. 100km Gyors, az adatátviteli sebesség<10 Gbps.

Optikai veszteségek:

Raylegh szóródás: az atomi üveghibákon Abszorpció: elnyelődés Diszperzió: szétszóródás Útkülönbségből adódó diszperzió Kondicionáló beiktatása

2.d. Vezetéknélküli átviteli közegeFőbb vezeték nélküli átviteli módszerek, alkalmazási területeik, főbb jellemzőik és

összevetésük.

Vezeték nélküli átvitel:

Elektromágneses hullámok terjedése levegőben Nagy távolságokra is.

Földi rádiós (URH):

Kis távolságú, alacsony sebességű mobil összeköttetés a bázis állomás-terminálok között

Kielégítő rendelkezésre állás, időjárás és pozíciófüggő bit-hiba arány.

Földi rádiós (WLAN):

Wirelles LAN (WLAN) pl.: IEEE 802.11b Sebesség: 1, 2, 5.5, 11 Mbps Frekvencia: 2400-2483.5 Mhz Teljesítmény 100mW Szórt sprektumú rádiós csatorna: nagyobb sávszélesség, csökkentett adó teljesítmény,

változatlan jelteljesítményDirect Sequence Spread Sprectum (DSSS): demoduláció korellátorral a Barker kód leszedéseFrequency Hopped Spread Sprektum (FHSS): Az adó frekvenciák gyors változtatása valamilyen előre definiált függvény szerint

Nincs frekvencia engedélyhez kötve

Földi mikrohullám:

Közepes vagy nagy távolságokra, a költséges kábel helyett Stabil állomások között, ahol van mikrohullámú rálátás, nagy sebesség, időjárásfüggő

Távközlési Műhold:

Mikrohullámú átvitel földi állomás és műholdak között nagy sebesség (időjárásfüggő, eső elnyeli),gond a magas terjedési késleltetés Transzponder: bizonyos spektrumot figyelnek, erősítenek és visszaadnak. Interferencia

elkerülés miatt más spektrumon, különböző polarizációval Nemzetközi egyezmények a frekvenciasávokra. Geostacionárius műholdak kb. 36000 Km magasságban.

250-300 msec késleltetés lehet3 műhold az egész földet lefedheti

Lézeres optikai

Kistávolságú, stabil telepítésű (pl. épületek között) nagy sávszélesség időjárásfüggő.

Hasonlítsuk össze:

2.e. Jelkódolási és modulációs módszerekJelkódolás és moduláció, alapfogalmak, néhány konkrét jelkódolási és modulációs módszer.

Az átviteli módok lehetnek

Alapsávú átvitel Szélessávú átvitel (telefontechnika: modulálás –digitális jelek analóg csatornán való

továbbítása)

Egyszerű bináris jelkódolás (alapsávú)

bináris értékekhez a jelszintek (feszültség vagy áram): pl. 1: 1V; 0: 0V Probléma szinkronizálásnál: pl. csupa 0 esetén nincs jelváltozás Ezen segíthet pl. a Manchester kódolás

A Manchester-kódolás

Minden bitperiódus 2 részre oszlik, a bitidő közepén mindig van átmenet (bitszinkron):

1: magas-alacsony,0: alacsony-magas átmenet.

Hátránya: kétszeres sávszélesség igény (fele olyan széles impulzusok).

Különbségi Manchester kódolás (variáns)

1: a bitidő elején hiányzó átmenet, 0: a bitidő elején jelenlévő átmenet és a bitidő közepén itt is mindig van átmenet, de a jel polaritására érzéketlen.

Jelek modulálása

Ilyen kell pl. analóg távbeszélőrendszeren való digitális jelátvitelhez Gond a digitális jelek analóg kapcsoltvonali továbbítása. Modem (modulátor

demodulátor) kell.Feladata:

kapcsolat felépítés és bontás (mint a telefon) a digitális bitfolyam modulált vivőjellé alakítása (oda és vissza).

Digitális bitfolyam modulált vivőjellé alakítása

Modulációs módszerek (szinuszos vivőhullám)amplitúdómoduláció: a vivőjel amplitúdóját változtatják;frekvenciamoduláció: a vivőjel frekvenciáját változtatják;fázismoduláció: a vivőjel fázisát változtatják;és ezek kombinációja (kombinált).

Kódolási rendszerek

Hogy lehetne kódolással az átviendő bitek számát csökkenteni? Különbségi impulzus-modulációval (differential pulse code modulation): az aktuális és

a megelőző minta különbségét viszik át Delta modulációval: csak 1 bittel jelzik, hogy a jel nő, vagy csökken (lemaradhat) Prediktív kódolással (predictive encoding): előző néhány értékből extrapolálva

megjósolják a következő értéket, majd az aktuális és a becsült érték különbségét továbbítják. (A dekódoló is ugyanezzel a módszerrel becsül.)

3. A számítógép-hálózatok ISO-OSI hivatkozási modell adatkapcsolati rétegének közeghozzáférési alrétege

3.a Csatorna-megosztási módszer osztályokA főbb csatorna-megosztási osztályok (statikus - dinamikus, dinamikus versengő -

determinisztikus) bemutatása és azok összevetése.

Az adatkapcsolati réteg:

Pont-pont kapcsolat esetén csak LLC:Keretképzés/behatárolás

Hibavédelem Kapcsolatvezérlés Adatfolyam vezérlés

Üzenetszórásos csatorna esetén (LLC+MAC)MAC:

Egyetlen üzenetszórásos csatorna megosztása több, egymással versengő állomás között

Pont-pont szerű szolgálat biztosítása az LLC alrétegnek


MAC: közeghozzáférési alréteg

Feladata: egyetlen üzenetszórásos csatorna megosztása (csatornamegosztás - csatornakiosztás)

több egymással versengő felhasználó (állomás) között

Csatornamegosztási módszerek:

Statikus csatornamegosztás, dinamikus csatornamegosztás:

Ütközéses (versengő),Ütközésmentes (determinisztikus).

Elemzés, összehasonlítás: (pl. átbocsátóképesség a terhelés függvényében)

A MAC alréteg feladatai

Egyetlen üzenetszórásos csatorna megosztása több egymással versengő felhasználó (állomás) között.

„Pont-pont” szerű szolgálat biztosítása az LLC alrétegnek „Csatornamegosztás” („Csatornakiosztás”)

129


Csatornamegosztási módszerek vizsgálatának szempontjai

Különböző jellegű és nagyságú forgalom esetén az átlagos késleltetés és a csatornakihasználtság.

A forgalom jellege lehet folytonos átvitel: hosszú időn át jól meghatározott sávszélességet igénylő (pl beszéd), löketszerű átvitel (burst-ös): véletlenszerű, aránylag rövid, löketszerű igény.

A forgalom nagyságával kapcsolatos jellemzők: csatorna foglaltság: az átviteli kapacitás hány %-a foglalt; kihasználtság: az átviteli kapacitásból a „hasznos” adatátvitelre használt átlagos rész; átlagos késleltetés: a keret készenléttől a hibátlan átvitelig telt átlagos idő.

A csatornamegosztási módszerek lehetnek:

Statikus Fix felhasználószám, a csatornából mindenki egyformán részesül akkor is, ha arra

valamely időpontban ténylegesen nincs is szüksége.Dinamikus

Azon felhasználók között oszlik meg a csatorna, akiknek arra éppen szükségük van. Vezérlés szempontjából lehet:

centralizált: egy kijelölt (esetleg speciális) állomás rendelkezik a csatorna kiosztásárólelosztott: elosztott algoritmus dönt (nincs kijelölt állomás).

A hozzáférési eljárás lehetversengő (ütközéses)determinisztikus (ütközésmentes)

130


3.b Statikus csatorna-megosztási módszerekNéhány módszer bemutatása és azok összevetése.

FDM (Frequency Division Multiplexing) frekvenciaosztásos nyalábolás:

n számú állomásnál a sávszélesség n egyenlő részre oszlik, minden állomás kap egy részt.

Mindenkinek külön frekvencia-sávja van és a sávok között "védősávok", így nincs interferencia

Egyszerű, bizonyos esetekben jó hatásfok; változó állomásszám esetén, ha egyes állomások alacsony intenzitással használják sávszélességüket, másoknak esetleg nem jut csatorna; veszteségek a védősávok

TDM (Time Division Multiplexing) időosztásos nyalábolás:

Van n állomás. A ciklusidőt n egyenlő részre osztjuk, és minden állomáshoz statikusan 1 időrést

rendelünk. Az i-ik résben az i-ik állomás a teljes sávszélességet használhatja. A ciklusuk és a rések előállítása központi szinkronizációt igényel. Kihasználatlan időrések lehetnek.

Közös jellemzők:

kötött állomásszámot feltételeznek a keretek átlagos késleltetése n szerese annak, mintha az egész csatorna egy állomásé

lenneFDM - nél kisebb (n-ed része) a sávszélesség,TDM – nél nagyobb várakozási idő van (a ciklusidő n-ed része csak az övé)

A keretek késleltetése állandó A csatornakihasználtság:

rossz kis és nem egyenletes forgalom esetén (ha a foglalt csatorna üres, más akkor sem veheti át)jó folytonos, egyenletes terheléskor főleg kis-és rögzített állomásszám mellett (kevés felhasználó, nagy egyenletes terhelés, pl.: telefonközponti trönk)

131


3.c Dinamikus versengő (ütközéses) csatorna-megosztási módszerekNéhány módszer bemutatása és azok összevetése.

Dinamikus csatornamegosztási módszerek

Azon felhasználók között oszlik meg a csatorna, akiknek arra éppen szükségük van.Vezérlés szempontjából lehet:

centralizált: egy kijelölt (esetleg speciális) állomás rendelkezik a csatorna kiosztásáról; elosztott: elosztott algoritmus dönt (nincs kijelölt állomás).

A hozzáférési eljárás lehet: versengő (ütközéses) determinisztikus (ütközésmentes)

Előfeltevések a későbbi vizsgálatokhoz: Egy állomás egy időben csak 1 keretet küld. A keretek korlátozott méretűek. Egyetlen csatorna áll rendelkezésre. Akár 1 bites ütközés is megsemmisítő.

Az ALOHA protokoll (egyszerű)

Hawai Egyetem, 1970 körül, URH rádiós hálózat Alapgondolat:

Rögzített, azonos hosszúságú keretek (nemcsak korlátozott méretűek);Az állomások bármikor adhatnak (azonnal, mihelyt elkészül egy kerete);Az adást követően nyugtára várnak (pozitív nyugta, illetve a válasz hiánya mint negatív nyugta);Ha az állomás észleli, hogy a kerete ütközött (nincs nyugta), véletlenszerű ideig vár, majd újraadja

Csatornafigyelés nélküli többszörös hozzáférés.Az ALOHA áteresztőképessége:Az elküldött keretek hányad része érkezik meg sikeresen (éli túl az ütközéseket)?

Tételezzük fel:N: az állomásszám (populáció);T: a keretidő (keret-hossza/bitsebesség);Si annak valószínűsége, hogy az i. állomás által küldött keret jut át sikeresen a keretidőben;Gi annak valószínűsége, hogy az i. állomás ad a keretidőben.

N db egyenrangú (egyforma) állomás eseténSi = S/N; ahol S: az egy keretidőben sikeresen átjutott keretek száma ≡ áteresztőképesség [keret/keretidő]Gi = G/N; aholG: egy keretidőben összesen elküldeni kívánt keretek száma ≡ez a terhelés [keret/keretidő] – a felajánlott forgalomS ≤ G mindig

132


Mikor jut át az i. állomás által küldött keret sikeresen a keretidőben Si = ?Ha a 2T hosszúságú kritikus időszakaszban senki más nem próbál adni (ha bárki más próbálkozna, az biztosan ütközne).Annak a valószínűsége, hogy j. állomás ad egy keretidőben: Gj, annak, hogy nem ad (1 - Gj)annak, hogy két keretidőben nem ad: (1 - Gj)*(1 - Gj) = (1 - Gj)2Annak a valószínűsége, hogy egyik állomás sem ad két keretidőben (egymástól függetlenek):Annak a valószínűsége, hogy i. ad egy, a többi pedig nem ad két keretidőben:Az ALOHA áteresztő képessége a terhelés függvényében: S = G * e−2G

Az egyszerű ALOHA maximális csatornakihasználtsága maximum 18%

Réselt ALOHA:

1972-es módosítás: réselt (slotted) ALOHA Az időt keretidőnyi résekre osztják

külön meg kell oldani az állomások szinkronizációját, pl. egy külön állomás küld egy speciális jelet minden rés elején.

Adást csak az időrés elején lehet kezdeni! Az ütközésveszélyes kritikus időszakasz 2T-ről T-re csökken! Az áteresztőképesség: S = G * e−G

A csatornakihasználtság legfeljebb 37%

133


CSMA

Carrier Sense Multiple Access – csatornafüggő többszörös hozzáférésLényege: az adásra kész állomás

(1) belehallgat a csatornábaha nincs adás adni kezd és(2)ha van adás: megvárja a végét, akkor kezd adni és (2)

(2) Végig leadja a keretet. Ha ütközés volt: véletlen ideig vár és újraadja (1) Gond: újraadáskor nagy az ütközés valószínűsége Ez az 1 perzisztens CSMA (perzisztens=kitartás)

Nonpersistent CSMA):

Adásra kész állomás (1) Állomás belehallgat a csatornába

Ha nincs adás (a csatorna tétlen), adni kezd és (2)Ha van adás (a csatorna foglalt), nem figyeli folyamatosan a csatornát, hanem véletlen ideig vár majd (1)

(2) Végig leadja a keretet. Ha ütközés volt: véletlenszerű ideig vár, majd (1) Kevésbé mohó: nincs szinkronpont az adás végén Azonban emiatt lomha is

p-persistent CSMA

Réselt csatornát (az időt résekben, időtartamokban számolja) alkalmaz Az adásra kész állomás:

(1) Megfigyeli a csatornát, belehallgat(2) Ha tétlen a csatorna:

p valószínűséggel adni kezd(1-p) valószínűséggel nem ad, hanem megvárja a következő időrést és (1)

Ha a csatorna foglalt, megvárja, míg felszabadul (2)(3) Végig leadja a keretet. Ha ütközés volt: véletlenszerű ideig vár majd (1)

Megjegyzés: p=1 esetén 1 perzisztens Paraméterezhető perzisztencia

CSMA/CD

Adás közben ütközésérzékelés (nem mindig lehetséges). Ütközést érzékelve az ütközött állomások abbahagyják a keret adását.

(Nem adják le a teljes keretet, időt nyernek.) Ez a CSMA/CD: CSMA with Collision Detection (csatornafigyelő többszörös

hozzáférés, ütközésérzékeléssel) Az 1-perzisztens CSMA/CD:

1-perzisztens CSMA +ütközés esetén abbahagyja az adást.(Véletlenszerű ideig vár, és úgy folytatja, mint az 1-perzisztens CSMA).

A keretek elküldését versengéses periódusok előzheti meg. A versengési időrések méretét a csatorna maximális terjedési késleltetése határozza

meg!

134


Az ütközésérzékelés Analóg eszközöket igényel (vesz, miközben ad) Megfelelő bitkódolás szükséges (pl. Manchester – pl. „feszültség ablak” ellenőrzés) Nem minden fizikai közeg alkalmas rá (vagy túl bonyolult, ill. költséges megoldani)

Ha nincs lehetőség ütközés-érzékelésre ütközés elkerülés Pl. rádiós hálók – IEEE 802.11 “Miközben beszél, süket” de pl. kábelen is – Apple Macintosh LocalTalk:

egyszerű HW: vétel képességek mindenképpen kellenek, de nem kell kiépíteni az ütközésérzékelésta nyomtató portra kapcsolt interfészen keresztül, 230 Kbps

Ütközés elkerülés: CSMA/CA (Collision Avoidance )

Megoldás: Mielőtt adni kezd belehallgat a csatornába (CSMA) Ha üres egy Interframe Spacing (IFS) időn át, akkor adni kezd. Ha foglalt, akkor megvárja míg felszabadul és ezt követően véletlenszerű ideig vár

(backoff), majd újra próbálkozik. Ütközés esetén (ACK hiány) úgy veszi, mintha foglalt lenne a csatorna.

135


3.d Dinamikus determinisztikus (ütközésmentes) csatorna-megosztási módszerekNéhány módszer bemutatása és azok összevetése.

Az ütközéses protokollok

Kis forgalom esetén minimális a késleltetés Nagy forgalom esetén bedugulás, jóval az ideális alatti korlátos csatornakapacitás

(Pl. az IEEE 802.3 Ethernet szabvány CSMA/CD) A bedugulás elkerülésére: ütközésmentes protokollok

Ütközésmentes protokollok

Feltételezések: N állomás van és mindegyik rendelkezik egy egyedi címmel

pl. 0 - (N-1)(mindegyik ismeri a saját címét „behuzalozottan”).

Tárgyaljuk az „alap bittérképes” módszert, „üzenetszórás felismerés változó prioritással” módszert a „vezérjeles” (Token) eljárásokat:

vezérjeles sínt,vezérjeles gyűrűt.

Basic Bit Map Method

Alap bittérképes módszer Bejelentési időszak:

pontosan N db (állomásszám) résből áll,minden állomáshoz 1 bites rést rendelünk.az adásra kész állomások a bejelentési időszakban 1-be állítják saját bitjüket (van küldendő keretük).

A bejelentkezési időszak után sorrendben leadják kereteiket a bejelentkezett állomások A megelőző bejelentési időszak alapján mindenki tudja, hogy ki mikor következik és

hogy mikor lesz a következő bejelentési időszak.Jellemzői:

Kis forgalom esetén aránylag nagy késleltetés (mindig van bejelentkezési időszak N réssel, bár ezek rövidek).

Ha d adatbitet forgalmazunk, akkor a kihasználtság: d/(d+N). (Jobb, ha d N-hez képest nagy.)

Az alacsonyabb című állomások hátrányban vannak!Már a bejelentkezési időszak elején kell jelentkezniük.1. A kis sorszámúaknak üres csatorna esetén is átlag pl. az első: (N/2)+N

bejelentkezési rést kell várniuk, míg adhatnak.2. A nagy sorszámúaknak átlag csak pl. az utolsó: N/2 rést kell várniuk.

Nagy forgalom (mindenki adna) esetén az „overhead” kicsi:az N bites bejelentési periódus Ndb dK keret között oszlik meg:a kihasználtság: dK/(dK+1) ≈ 1, ha dK>>1 (TDM szerű)

136


Broadcast Recognition with Alternating Priorities (BRAP)

Üzenetszórás felismerés változó prioritással Módosított bit-map úgy, hogy

a magasabb sorszámúak előnyét kompenzáljuk,de a kis terhelés nagy overhead-je megmarad.

Működése: Ha egy állomás adási szándékot jelent be, akkor a bejelentkezési időszak

felfüggesztődik, és azonnal adhat az állomás. Amikor az adás befejeződik, a bejelentkezés a következő állomással folytatódik.

A bejelentkezési időszak végén mindig 1 van (adási szándék bejelentés)Jellemzői:

mint a bit-map, de az állomások sorszámától független, kiegyenlített a közeghozzáférés. (Egy állomásnak N/2 rést kell átlagban várnia.)

Vezérjeles (Token) eljárások

Jellemzőik: Az állomások (logikai) gyűrűt alkotnak, speciális vezérlőkeret (token) jár körbe, hordozva az adásjogot.

Adás Az az állomás adhat, aki a tokent (vezérjelet) birtokolja Nem kötött a keretméret, de a token-tartási idő (token holding time) igen!

(ha van rá idő - akár több keretet is elküldhet) Az adás végeztével továbbadja a tokent a gyűrűben a logikai szomszédjának. A gyűrűben csak 1 token van, egyszerre csak 1 állomás adhat!

Token Bus (vezérjeles sín)

Az állomások üzenetszórásos sínhez kapcsolódnak. Logikai gyűrűt formálnak: tudják, ki kit követ.

Token Ring (vezérjeles gyűrű)

Fizikai gyűrű Ha egy állomás tokent kap,

„felvágja” a gyűrűt ésad (esetleg több keretet),„leveszi” a saját keretét miután az körbeért,továbbadja a tokent ha

nincs több adnivalója, vagy halejárt a token-tartási idő.

Ha egy állomásnál nincs token,ismétel (a kapott kereteket továbbadja);figyeli a neki címzett forgalmat.

137


A vezérjeles eljárások jellemzői

Kis forgalom esetén jelentős a késleltetés (meg kell várni a tokent). Állomásszámtól függ az overhead. Nagy forgalom esetén hasonló a TDM-hez.

A kapacitás az állomásszám arányában oszlik, az állomások között mindenkinek egyformán.

A közeghozzáférési eljárások összevetése

138


3.e. Az "ALOHA" csatorna-megosztási módszer áteresztőképességének becslése a csatornaterhelés függvényében A becslés főbb lépései "tiszta"és "réselt" ALOHA esetén.

Az ALOHA áteresztőképessége:

Az elküldött keretek hányad része érkezik meg sikeresen (éli túl az ütközéseket)? Tételezzük fel:

N: az állomásszám (populáció);T: a keretidő (keret-hossza/bitsebesség);Si annak valószínűsége, hogy az i. állomás által küldött keret jut át sikeresen a keretidőben;Gi annak valószínűsége, hogy az i. állomás ad a keretidőben.

N db egyenrangú (egyforma) állomás eseténSi = S/N; ahol S: az egy keretidőben sikeresen átjutott keretek száma ≡ áteresztőképesség [keret/keretidő]Gi = G/N; aholG: egy keretidőben összesen elküldeni kívánt keretek száma ≡ez a terhelés [keret/keretidő] – a felajánlott forgalomS ≤ G mindig

Mikor jut át az i. állomás által küldött keret sikeresen a keretidőben Si = ?

Ha a 2T hosszúságú kritikus időszakaszban senki más nem próbál adni (ha bárki más próbálkozna, az biztosan ütközne).Annak a valószínűsége, hogy j. állomás ad egy keretidőben: Gj, annak, hogy nem ad (1 - Gj)annak, hogy két keretidőben nem ad: (1 - Gj)*(1 - Gj) = (1 - Gj)2Annak a valószínűsége, hogy egyik állomás sem ad két keretidőben (egymástól függetlenek):Annak a valószínűsége, hogy i. ad egy, a többi pedig nem ad két keretidőben:

Az ALOHA áteresztő képessége a terhelés függvényében: S = G * e−2G

Az egyszerű ALOHA maximális csatornakihasználtsága maximum 18%

139


Réselt ALOHA esetén:

Az áteresztőképesség: S = G * e−G

A csatornakihasználtság legfeljebb 37%

140


4. A számítógép-hálózatok ISO-OSI hivatkozási modell adatkapcsolati réteg – az IEEE 802 LAN szabványcsalád

4.a Az IEEE 802.3 (CSMA/CD) - támogatott közegek és sebességekTámogatott közegek és sebességek bemutatása, működés duplex csatorna esetén.

Az IEEE 802

IEEE: Istitute of Electrical and Electronics Engineer – Villamosmérnökök intézete

IEEE 802.3 specifikációk, jelölések

A jelölésrendszer a 802.3-ban10Base5 -- thickwire coaxial, 500m10Base2 -- thinwire coaxial or cheapernet, 185m10BaseT -- twisted pair: UTP/STP, pont-pont, 100 m (most widely used today)10BaseF -- fiber optics, pont-pont, multimódusú: 2 Km; monomódusú: 3-10 Km10Broad36 -- broadband (only 802.3 standard 1/2” coax, 1800m)

Fast Ethernet (802.3u)100BaseTX (CAT5), 100BaseT4 (CAT3), 100BaseFX

Gigabit Ethernet 1000 Mbps1000BaseSX, 1000BaseLX, 1000BaseCX (802.3z)1000BaseT (802.3ab)

10 Gigabit Ethernet 10000 Mbps (802.3ae)10GBase-S (850nm, 50μ multi – 65m),10GBase-LX4 (1310nm, 62.5μ multi – 300m, 9.0μ mono – 10km),10GBase-L (1310nm, 9.0μ mono – 10km),10GBase-E (1550nm, 9.0μ mono – 40km)

A 802.3 MAC technika

Carrier Sense Multiple Access/Collision Detection: CSMA/CD Az állomás mielőtt adna, megfigyeli a csatornát (CS), és megállapítja,

hogy a csatorna tétlen, nincs adás (idle): ekkor adni kezd.vagy a csatorna foglalt, van adás (busy). Ekkor folytatja a figyelést, míg a csatorna tétlen nem lesz: és ekkor kezd adni.

A topológia biztosítja a többszörös hozzáférést (a csatornafigyelésnél) (MA) CD: képes arra, hogy ütközést érzékeljen már miközben ad (listen while you talk).

Ütközés lép fel, ha több állomás ad szimultán. Ha ütközést detektál (adás közben), – a vett feszültségszint alapján

Minden ütközést detektáló állomás abbahagyja az adást, és helyette értelmetlen jelet (jamming signal) küld, hogy mindenki biztosan észrevegye az ütközést.Ezután véletlen ideig vár (helyettes exponenciális visszatartási), majd újrapróbálkozik.

10BaseT - 10Mbps

min. keret 64 byte = 512 bit; 2τ = 51,2 µsec Manchester kódolás

100BaseT Fast Ethernet (802.u) - 100Mbps

min. keret 64 byte = 512 bit; 2τ = 5,12 µsec 4B/5B + MLT-3 kódolás

141


Pont-pont kapcsolatok

Half-Duplex – CSMA/CD Full-Duplex – flow control 802.3x „pause frame”

„pause frame” vétele esetén egy időre beszünteti az adást

802.3z: Gigabit Ethernet:

legelterjedtebb hálózati technológia; kompatibilis a régebbi Ethernet rendszerekkel. CSMA/CD full és half duplex támogatással; réz, single- és multimode optikai kábel támogatás.

10GBASE Ethernet (802.3ae):

csak a Duplex üzemmódot támogatja nincs definiálva repeater a keretformátum nem változik ( 64 byte→1518 byte) komplex soros bitfolyam

142


4.b Az IEEE 802.3 (CSMA/CD) - keretformátum, MAC címekA 802.3 és az Ethernet keretformátum, MAC címek.

802.3/Ethernet keret szerkezet:

PA: Előtag (Preamble) SFD: Keretkezdet határoló (Start of Frame delimiter) DA: Célcím (Destination Address) SA: Forrás (Source Address) LEN: Adatmező hossz (Length) -- bájtokban mért hosszType: a magasabb szintű protokoll LLC PDU+Pad: Adat+töltelék -- minimum 46 bytes, maximum 1500FCS: Ellenőrző öszeg (Frame Check Sequence) -- CRC-32Pad szerepe: a min keretméret - a célcímtől a keret végéig.

Ha az adatmező 46 bájtnál rövidebb, töltelék egészíti ki 46 bájtig! (Min. kerethossz)

MAC címek:

A Célcím (DA) és a Forráscím (SA) a szabvány szerint 2 vagy 6 bájtosak lehetnek, de 10 Mbps esetén csak 6 bájtosak.

Csupa 1: valamennyi állomásnak szóló cím. Ha a legfelső (47) bit=1: csoportcím

1. a többi bit a csoportot határozza meg;2. a keretet a csoport összes tagja veszi.

Ha a legfelső (47) bit=0: közönséges cím. A 46. bit speciális szerepű: a helyi (1) és a globális (0) címek megkülönböztetésére

van. A helyi címet a hálózatmenedzser konfigurálja, a globális címet az IEEE osztja ki,

mely a világon egyedi. (minden gépnek “automatikusan” egyedi MAC címe van, pl. a kártyán ROM-ba égetve).

143


4.c Az IEEE 802.11 (Wireless LAN) – struktúraAz IEEE 802.11 WLAN általános felépítése,az Access Point (AP) főbb funciói.

IEEE 802.11 PHY

Sebesség: 1, 2, 5.5, 11Mbps (IEEE 802.11b) Frekvencia 2400-2483.5 MHz Teljesítmény: 100 mW Hatótávolság 1Mbps (tipikus):

460m nyílt terepen,300m kézi berendezésnél,90m irodában

Hatótávolság 11Mbps (tipikus):120m nyílt terepen,90m kézi berendezésnél,30m irodában

Szórt spektrumú rádiós csatornaDirect Sequence Spread Spectrum (DSSS), vagyFrequency Hopped Spread Spectrum (FHSS), vagyOrthogonal Frequency Division Multiplexing (OFDM)

Nincs frekvencia-engedélyhez kötve Cellákra épülő struktúra

BSS (Basic Service Set) – egy cellaAP (Access Point) – az egyes cellákat irányító bázisállomásokDS (Distribution System) – a cellákat összekötő hálózat (lehet akár drótnélküli az is)ESS (Extended Service Set ) – a teljes hálózat (több összekötött cella együtt – lehet mozogni is közöttük „roaming”)

Eredetileg 1997-es IEEE szabvány (WLAN), melyet 1999-ben felülvizsgáltak (802.11b).

Az IEEE 802.11 szabvány a MAC alréteget, a MAC menedzsment protokollt, szolgálatokat és három lehetséges fizikai közeget definiál.

IR at baseband with 1-2 Mbps,FHSS at 2.4GHz with 1-2 Mbps,DSSS at 2.4GHz with 1-2 Mbps.

A WLAN celluláris architektúrára épül, a GSM-rendszerekhez hasonlóan cellákra van osztva

A cellákat irányító bázisállomások (hozzáférési pont – Access Point – AP), amik a vezetékes és vezeték nélküli hálózatok között teremtenek kapcsolatot

Vezeték nélküli csatolóval ellátott számítógépek: kliensek Vezetékes gerinchálózat, elosztórendszer (Distribution System – DS), amin keresztül

az AP-k kapcsolódnak egymáshoz, azaz bridge-ként is funkcionál Több BSS-t összefoglaló elem: ESS – Extended Service Set

144


Új állomás belépése a BSS-be:

Szinkronizálnia kell magát a BSS Access Point-jához. Passive Scanning – addig vár, míg meg nem hallja az AP Beacon Frame-jét. Active Scanning – Request Frame-t küld és vár az AP kötelező Probe Response válaszára. A belépni szándékozó állomás ezek után azonosítja magát az AP-nál és kapcsolódik.

Szinkronizáció:

Az AP periódikusan (Beacon Interval) Beacon kereteket küld. A CSMA miatt ez változhat (nem az előző ténylegeshez méri a következőt, hanem az ideálishoz). A Beacon időbélyegén rajta van a feladás időpontja.

145


4.d Az IEEE 802.11 (Wireless LAN) – fizikai közeg, modulációs módokTámogatott fizikai közegek és szórt spektrumú modulációs módok

Fizikai közegek:

Az IEEE 802.11 szabvány a MAC alréteget, a MAC menedzsment protokollt, szolgálatokat és három lehetséges fizikai közeget definiál.

IR at baseband with 1-2 Mbps,FHSS at 2.4GHz with 1-2 Mbps,DSSS at 2.4GHz with 1-2 Mbps.

IEEE 802.11 PHY DSSS

Szórt spektrumú rádiós csatorna - Direct Sequence Spread Spectrum Nagyobb sávszélesség: csökkentett adóteljesítmény, változatlan jelteljesítmény 13 x 22 MHz széles egymást fedő csatorna Ebből max. három egymást nem fedő (diszjunkt) csatorna (időben stabil) 1, 6, 11, vagy 2, 7, 12, vagy 3, 9, 13 Max. három berendezés egy adott területen

Modulációk: Binary Phase Shift Keyed (BPSK) Quadrature Phase Shift Keying (QPSK) Complementary Code Keying (CCK)

IEEE 802.11 PHY FHSS

Frequency Hopped Spread Spectrum (FHSS) Az adó frekvenciák gyors változtatása valamilyen előre definiált függvény (frequency

hopping sequence) szerint – amit a vevő követ (802.11: 79 csatorna egymástól 1MHz-re 2.4 – 2.483 MHz – es sávban) hatékony keskenysávú zajok ellen

IEEE 802.11 PHY OFDM

Orthogonal Frequency Division Multiplexing (OFDM) - (IEEE 802.11a 5GHz) A nagysebességű bitfolyamot több alacsonyabb sebességűre (52db - 802.11a) bontja

és azzal modulál több párhuzamos kisebb sávszélességű csatornát.

IEEE 802.11 PHY DSSS - FHSS

Frequency Hopped Spread Spectrum (FHSS) immunis a többszörös utakkal (multipath) szemben

Direct Sequence Spread Spectrum (DSSS) nagyobb adatátviteli képesség jobb hatótávolság

146


Összehasonlítás

Magasabb adatátviteli sebesség → rövidebb hatótávolság Magasabb kimenő-teljesítmény → nő a hatótávolság de csökken a telep élettartama

(ha mobil) Magasabb rádió frekvencia → magasabb adatátviteli sebesség, de rövidebb

hatótávolság

147


4.e Az IEEE 802.11 (Wireless LAN) – közeghozzáférés vezérlésKeretformátum, az alkalmazott közeghozzáférési módszer (CSMA/CA), Distributed Coordination Function (DCF) és Point Coordination Function (PCF)üzemmódok.

IEEE 802.11 MAC

Két eltérő MAC hozzáférési forma: Distributed Coordination Function (DCF)

versengéses CSMA/CA. Point Coordination Function (PCF)

centralizált, ütközésmentes

802.11 keretformátum:

Preamble (mindig 1Mbps sebességgel): Sync:128 bit; SFD:16 bit Start Frame Delimiter; PLCP Header (mindig 1Mbps sebességgel): Signaling Field: a keret további részének bitsebessége;Length Word: a MAC data byte-jainak száma; Header Error Check Field: 16 Bit CRCMAC Data:

Duration/ID: Power-Save Poll esetén az állomás azonosító. Egyéb esetekben a NAV számításához szükséges időtartam Sequence Control: Az ugyanazon kerethez tartozó részeket és azok sorszámát jelzi. Fragment Number (melyik keret része 12bit) és Sequence Number (hanyadik 4b)CRC: 32 bit Cyclic Redundancy CheckAddress-1: mindig a fogadó címe a BSS állomás, vagy ToDS esetén az AP címe (Receiver)Address-2: mindig a küldő címe a BSS állomás, vagy FromDS esetén az AP címe (Target)Address-3: FromDS esetén az eredeti Source Address, ToDS esetén az eredeti Destination Address.Address-4: Wireless Distribution System esetén használják, amikor két AP között küldik a keretet

DCF (Distributed Coordination Function):

versengéses CSMA/CA Az állomás mielőtt adni kezd, belehallgat a csatornába. Ha üres egy DIFS (Distributed Interframe Space) időn át, akkor adni kezd. Ha foglalt, akkor megvárja, míg felszabadul és ezt követően véletlenszerű ideig vár

(Binary Exponential Backoff), majd újrapróbálkozik. Hiba esetén új Backoff időt sorsol. Hiba felismerését a pozitív nyugta hiánya adja. Ha egy állomás neki címzett hibátlan üzenetet vesz, akkor egy SIFS (Short Interframe

Space) eltelte után pozitív nyugtát küld a feladónak. (SIFS+Slot=PIFS, PIFS+Slot=DIFS)

A feladó a nyugtából tudja, hogy sikeres volt a küldése

148


PCF (Point Coordination Function):

Centralizált, ütközésmentes közeghozzáférés vezérlés. A PCF-t a Point Coordinator irányítja. Az állomások kérhetik, hogy kerüljenek rá a PC Polling Listájára. Rendszeres időnként a PC a DCF versengés során magasabb prioritást kap. (A DIFS-

nél rövidebb PIFS-Point Coordination IFS). A többi állomást megelőzve foglalja le a csatornát, a többiek egy DIFS-et várnak, mielőtt versengeni kezdenének.

Miután megszerezte a csatornát, az Access Point állomás Polling Requests keretekkel szólítja meg a kiválasztott állomásokat, hogy küldjék el adataikat (versengés nélküli időszak).

A versengéses és versengés nélküli időszakok váltakoznak. A PC a Beacon keret Duration mezőjével állítja fel a DCF (versengéses) időszakot. A versengés nélküli periódus hossza változhat – mind a PCF, mind a DCF alatti

foglaltság késleltetheti a másikat. Annak érdekében, hogy a versengő DCF forgalom is életben maradjon a Point

Coordinator-nak időt kell hagynia a DCF-re a rendszeresen ismétlődő PCF-ek között. (Kötelező minimum: egy max. keretméretnyi idő annak nyugtájával együtt)

A PC PIFS-et használ így nem zavarják a DIFS-et használó DCF állomások

149


5. A számítógép-hálózatok ISO-OSI hivatkozási modelljének adatkapcsolati rétege - keretképzés és felismerés

5.a Keretképzés és felismerésA keretképzés és felismerés célja; a karakter-számlálásos, a karakter-beszúrásos, a

bitbeszúrásos és az érvénytelen kódmintás keretezési módszer bemutatása.

A keretképzés és behatárolás

Az adatkapcsolati réteg szokásos működése: A hálózati rétegből kapott bitfolyamot diszkrét keretekké alakítja, melyeket ellenőrző

összeggel lát el; majd továbbítja a kereteket → bitfolyamból jelfolyam; a kapott jelfolyam bitfolyammá alakítása: a kereteket behatárolása, az ellenőrző összeg

visszaellenőrzése; a bitfolyamot továbbítja a hálózati rétegnek.

Keretképzés és behatárolás ≡ kerethatárok jelezése és ezen jelzések felismerése (a fölöttes hálózati réteg számára transzparensen)

A keretképzés indokai

Egyes MAC protokollok korlátos méretű (min., max.), esetleg fix méretű kerteket igényelnek

A fizikai átvitel késleltetése csökkenthető, ha a keretek rövidebbek Egy keret meghibásodási valószínűsége csökkenthető, ha a keretek rövidebbek A folytonos bitfolyamon végzett hibafelismeréshez, behatároláshoz elengedhetetlenül

szükséges

Keretképzési módszerek

A négy vizsgált módszer: A karakter-számlálásos keretezési módszer A karakter-beszúrásos keretezési módszer A bitbeszúrásos keretezési módszer Az érvénytelen kódmintás keretezési módszer

A karakter-számlálásos keretezés

A keret-fejrész egy mezőjében megadjuk a keret karaktereinek számát (a keret hosszát)

Feltétel: léteznie kell karakterszinkronnak, fel kell tudni ismerni az egyes karaktereket Gond: nagyon sérülékeny: ha kiesik a szinkronból, félreértelmezi a kereteket

ha bit elcsúszás, esetleg karaktereket is félreértelmezhet Hiba esetén nincs újbóli szinkronizálási lehetőség

150


A karakter-beszúrásos keretezés (Character stuffing)

A keretek elejét és végét speciális karakter-szekvenciák jelzik. (Ez is csak karakterorientált módszer)

Hiba esetén a keretszinkron könnyen helyreállítható (csak a keret eleje szekvenciát kell keresni).

Keret eleje: DLE, STX Keret vége: DLE, ETX

DLE: Data Link EscapeSTX: Start of TextETX: End of Text

Általában terminál kapcsolatoknál alkalmazzák Gond a transzparens átvitel:

az adatok között ne legyen DLE, STX, vagy DLE, ETX Megoldás: a kerethatárok elhelyezése előtt az adatok közötti valamennyi DLE-t meg

kell kettőzni:DLE+STX v. ETX párok a kerethatárokat jelezik,a DLE+DLE pedig DLE a szövegben.

Gond: Karakter-orientált

A bitbeszúrásos keretezés(Bit stuffing)

Bit-orientált, nem kötődik karakterekhez Minden keret speciális bitmintával (flag) kezdődik és végződik Gond: a bitfolyamban nem lehet ilyen bitminta „Transzparenssé” alakítás:

A kerethatárok elhelyezése előtt az adó az adat bitfolyamba minden egymás utáni 5 db 1-es bit után beszúr 1db. 0-át;a vevő a kerethatárok felismerése és levétele után minden egymás utáni 5 db 1-es bit után kivesz 1db. 0-át.Így a 6 bites 1-es sorozat biztosan csak a kertet eleje, vagy vége lehet.

Az érvénytelen kódmintás keretezés

A keretek elejét és végét az adatbitektől eltérő módon kódolt jelekkel jelzik. „Kódolás sértéssel”.

Előnye: Transzparens, hatékonyA keret elejét és végét jelző kódok nem fordulhatnak elő az adatok között (nem kell még biteket sem beszúrni)

Hátránya: Nem lehet mindig megcsinálni (kódolás)

Kombinált

Sokszor a karakter-számlálásos módszert kombináljákA kerethossz megadás esetleg gyorsíthatja a feldolgozást;Egy másik módszer pedig megoldhatja a keretszinkron helyreállítását

151


5.b Közvetett és közvetlen hibavédelem, kódolásA közvetett és közvetlen hibavédelem; alapfogalmak; hibajelző és hibajavító kódolás; néhány

tipikus hibajelző kódolási módszer bemutatása.

A hibavédelem lehet közvetlen

hibajavító, hibajelző kódolás esetén a vett szóból. Alapvetően a redundanciára épül: a tényleges (hasznos) információknál több

információt kell átvinni Mindig véges adategységekre vonatkozik

és lehet közvetett

hibajelző kódolás esetén nyugtázás útján.

A vevő

hibajavító kódolás esetén közvetlenül javíthatja is a hibát, hibajelző kódolás esetén csak érzékeli, de saját maga nem javíthatja: közvetettség (az

adó segítsége)

Az adó

Nem javítható hiba esetén (visszacsatolás a nyugtázási módszeren keresztül) újra kell adnia a keretet.

Hamming távolság

Kódszavak Hamming távolsága (Hamming 1950): Két kódszóban az egymástól eltérő bitek száma (két kódszó kizáró-vagy

kapcsolatában az 1-ek száma). Ha két kódszó H távolsága d, akkor d db 1 bites hibával konvertálhatók át egymásba,

vagy érvényes kódszóból d számú 1 bites hibával érvényes kódszó adódhat.

Kód Hamming távolsága: A kód kódszavai közötti legkisebb H távolság. (A kód az érvényes kódszavak

összessége.)

Tételek

Tétel 1:Valamely kód alkalmas d darab hiba felismerésére, a kód Hamming távolsága d + 1Tetszőleges d darab egyedi hiba csak érvénytelen kódszót eredményezhet.

Tétel 2: Egy kód alkalmas d darab hiba javítására, a kód Hamming távolsága 2d + 1Tetszőleges d hiba esetén is „közelebb állunk” az eredeti kódszóhoz, mint bármi más kódszóhoz.

Tétel 3: A hibajavító kód egyben hibafelismerő kód is.A d hibát javítani képes kód 2d hibát képes felismerni.

Tétel 4: Tökéletes (közvetlen) hibavédelem,hibajavító kód valamennyi bitre nem létezik.

Legyen n bites kódszó, valamennyi bitre hibajavító. Ekkor a kód H-távolsága 2 . n + 1 kellene legyen. Ez lehetetlen, hiszen 2 . n + 1 > n

152


Megjegyzés Belátható, hogy a hibajavító kódok alkalmazása nagy redundanciát igényel. Ez

csökkenti a hatékonyságot (növeli az overhead-et). Adatátvitel esetén (ahol viszonylag alacsony a hibaarány) hatékonyabb a kevésbé

redundáns hibajelző kódot alkalmazni, és újraadni a hibás kódokat (adategységeket)!

Hibajelző kódok

Paritásos kód Blokkonként paritás Ciklikus redundancia kód (CRC)

Paritásos kód

Az adatok végére egyetlen paritásbitet (parity bit) illeszt. Ennek értékét úgy kell választani, hogy

Páros paritás (even parity) esetén a kódszóban az 1-esek száma páros (even) legyen (párosra egészít ki), vagyPáratlan paritás (odd parity) esetén a kódszóban az1-esek száma páratlan (odd) legyen.

A paritásos kód a kód H-távolságát 1-ről 2-re növeli, ezzel 1 egyedi hibát észlelhetünk.

Gond: csoportos hibák esetén 0,5 a hibajelzés valószínűsége (csoportos hiba: több egymásmelletti bit sérül)

Blokkonkénti paritásbit

Egymástól távoli biteket vizsgál és azokból képez paritásbitet (csoportos hibák észlelése)

Képzési módszer:az adatbitekből „mátrixot” alkotunk;és a paritást oszloponként képzi;majd a kapott paritásbiteket a mátrix utolsó sorának teszi;a biteket soronként küldjük el.

Ciklikus redundancia kód

Cyclic Redundancy Check (CRC) Más néven: polinom-kód (polinomial code) A bitfüzéreket 0 és 1 együtthatójú polinomoknak tekinti. Ellenőrző összeg: checksum

153


5.c Elemi adatkapcsolati protokollokAz elemi adatkapcsolati protokollok általános funkciói (közvetett hibavédelem, adatfolyam vezérlés), korlátozás nélküli szimplex (utópia), szimplex megáll és vár protokoll, szimplex

protokollok zajos csatornára, forgóablakos protokollok.

Elemi adatkapcsolati protokollok

Adatkapcsolati rétegek közötti protokoll Az adatkapcsolati réteg funkciói:

Keretképzés és behatárolásHibavédelem:

1. Közvetlen (hiba észlelő, javító kódolás)2. Közvetett (nyugta)

Adatfolyam vezérlésKapcsolat menedzselés

Közvetett hibavédelmet és adatfolyam vezérlést (forrás-vevő szinkronizálást) valósítanak meg.

Építenek a keretképzésre és a közvetlen hibaészlelésre.

A vizsgált protokollok

• Korlátozás nélküli szimplex (utópia) protokoll• Szimplex megáll és vár protokoll• Szimplex protokollok zajos csatornára• Forgóablakos protokollok

Korlátozás nélküli szimplex (utópia) protokoll

További előfeltevésekvégtelenek a bufferek (a vevő sohasem telik be)hibamentes a csatorna

Működés:Az adó folyamatosan ada vevő folyamatosan vesz

Egyirányú, nincs adó-vevő szinkronizálás(Utópisztikus nincs szükség sem hibajavításra, sem adatfolyam vezérlésre)

Szimplex megáll és vár protokoll

További előfeltevések:Véges bufferek (a vevő betelhet, szükséges a forgalomszabályozás);Hibamentes a csatorna.

Működés:(1) adó ad egy keretet, majd várakozik;vevő veszi a keretet, majd nyugtát küld;adó veszi a nyugtát, majd folytatja az (1) ponttól

Az adónak meg kell várnia a vevő nyugtáját visszacsatolás szinkronizálja az adó sebességét a vevő sebességéhez forgalomszabályozás

Gond: Nem jó zajos csatornára (a nyugtavesztésen elakad) előfeltevés a hibamentesség

154


Szimplex protokoll zajos csatornára

PAR: Positive Acknowledgement with Retransmission További előfeltevések:

véges bufferek,zajos csatorna.

Működés(A1) az adó ad egy keretet, majd(A2) beállít egy időzítőt és várakozik(A3) az adó az időzítő lejárta esetén újraadja a keretet, majd megy (A2)-re(A4) az adó nyugta vétele esetén megy az (A1)-re(V1) a vevő érvényes keret vétele esetén továbbítja az a felettes rétegnek, majd nyugtát küld.(V2) a vevő érvénytelen keret vétele esetén vár

A PAR protokollForgalomszabályozást éshibavédelmet biztosít (hiba esetén újraküldéssel)Gond:

nyugta sérülés esetén ugyanazt a keretet az adó többször is elküldiEzért az egymás utáni kereteket meg kell tudni különböztetniElég 1 bit az adott keretek „megszámozására”

Forgóablakos protokoll

További előfeltevések:végesek a bufferek,zajos a csatorna.

Megoldandó probléma még:Nagy átviteli késleltetés esetén túl hosszú kivárni a „körülfordulási időt” (amíg a nyugta visszaér az újabb keret elküldése előtt).

Megoldás: több nyugtázatlan keret elküldését kell lehetővé tenni, ugyanakkor sorrendhelyes keretátvitelt kell biztosítani.

Az elküldött kereteket „ciklikusan” sorszámozzuk Az adó „ablakot” képez, melybe az elküldött, de még nyugtázatlan keretek sorszámai

kerülnek. A vevő „ablakot” képez, mely azokat a sorszámokat tartalmazza, mely sorszámú

kereteket hajlandó fogadni.

155


6. A számítógép-hálózatok ISO-OSI hivatkozási modelljének hálózati rétege – funkciói, szervezése

6.a Funkciói, szervezéseA hálózati réteg funkciói, virtuális áramkörön alapuló és összeköttetésmentes hálózat-

szervezés.

A hálózati réteg(csomagok):

A kommunikációs hálózat működését vezérli.Csomagok forráscsomóponttól célcsomópontig való eljuttatása

Az adatkapcsolati réteg: csak egyetlen „vonal” (single link) két vége közötti keretmozgatást végzi, pl. hibajavítás, sorrendezés, forgalomszabályozás

A szállítási réteg: valódi vég-vég (end-to-end) alapú (valódi forrás-cél kapcsolat) A hálózati réteg két végpont közötti (end-to-end) átvitellel mikéntjével foglakozik

(ismernie kell a hálózatot, topológia stb.) Általánosan:

jól meghatározott szolgáltatások a szállítási rétegfelé, azaza szállítási funkcionális elemtől NSAP-on át (Network Services Access Point) kapott és megcímzett (hálózati célcím, forráscím) adategységet (csomagot) a cím szerinti NSAP-hoz (a funkcionális társelemhez) (és sehová máshová) eljuttatni.

A hálózati réteg funkciói

Forgalomirányítása csomag célba juttatása.ismerni kell a topológiátterhelésmegosztás (alternatív utak)

TorlódásvezérlésNe legyenek a hálózat egyes részei túlterheltekHasonló a forgalomszabályozáshoz, de ez nem csak két pont (adó-vevő) közötti, hanem a hálózat egészére vonatkozik.

Hálózatközi együttműködésEz az első réteg, ahol különböző hálózatok összekapcsolhatók (heterogén hálózatok kialakítása)

A szállítási rétegnek nyújtott szolgálatok

Lehetnek: Összeköttetés alapú (virtuális áramkör) Összeköttetés-mentes (datagram)

Üzenetkapcsolásos (Message Switching)Csomagkapcsolásos (Packet Switching)Virtuális vonalkapcsolás

A virtuális áramkör szervezés kedvező, ha: Elsődlegesen összeköttetés alapú szolgálatot biztosít Ne legyen minden egyes csomagra forgalomirányítás

156


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.

A 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 virtuális áramkörön

(VC) haladnak (mindkét irányban). A kommunikáció befejeztével a virtuális áramkört fel kell szabadítani Az egyes csatornákon több virtuális áramkör is lehet (számuk maximált).

Címzés: Csak a hívásfelépítés során van szükség a teljes forrás, célcímre

Ezt követően már elegendő a virtuális áramkör jelzéseMinden csomagban mező a virtuális áramkör jelzésére(Az egyes csatornákon több virtuális áramkör is lehet (számuk maximált)).

Hívásfelépítéskor: A csomópont kiválasztja a megfelelő irányú csatornát (útvonalat) és azon virtuális

áramkört foglal le (pl. a legkisebb szabad sorszámút) Ha nincs szabad áramkör, másik útvonalat választ. Ha ez sincs, a hívásfelépítés

sikertelen. Ez ismétlődik az útvonalat érintő valamennyi csomópontra

Minden csomópontban táblázat a nyitott virtuális áramkörökről:melyik vonal melyik áramköre melyik vonal melyik áramköréhez kapcsolódik

Datagram alapú alhálózat szervezés

Minden csomag teljes cél, forráscímet tartalmazCím = állomás cím + NSAP cím (az állomás cím lehet hálózat + hoszt cím)

Az egyes csomagok egymástól függetlenül haladnak, minden csomagra külön-külön van forgalomirányítás(mehetnek más-más úton is)

A virtuális áramkör és a datagram alapú alhálózat-szervezés összehasonlítása

157


6.b ForgalomirányításKövetelmények, forgalomirányítási módszerek, információgyűjtési és döntési módszerek,

egyutas, többutas és táblázat nélküli módszerek.

A forgalomirányító algoritmus (routing alg.) dönti el, hogy a beérkező csomagot melyik kimenő vonalon kell továbbítani

Datagram alapú alhálózat esetén: minden csomagra külön-külön, Virtuális áramkör alapú alhálózat esetén: csak az új virtuális áramkör létrehozásakor

(hívásfelépítés)

Alapkövetelmények, tervezési szempontok

Egyszerűség, megbízhatóság Helyesség (azt tegye, ami a dolga, egy 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 pillanatnyi

körülményekhez Stabilitás: indulástól véges idő alatt stabil állapotba kerüljön Optimalitás: pl. költség, késletetés, min. ugrásszám szempontjából

Az útvonalválsztás lépései

Döntések: a (router) csomópontok hozzák, merre továbbítsák a vett csomagot. Információgyűjtés: a döntésekhez szükséges információk megszerzése.

Forgalomirányítási módszerek

Valamennyi célcím táblázatba gyűjtése eseténtúl nagy táblák (túl sok szolgálati kommunikáció) (nagy hálózatok esetén)

Megoldás:Hierarchikus forgalomirányítás: a teljes hálózat alhálózatokra, al-alhálózatokra stb. bomlik

Az alhálózatokra bontás szempontjai:földrajzi elhelyezkedés;funkcionális összetartozás (pl. közös cél);fizikai közeghatárok, adatkapcsolati protokollok szerint

Elég az egyes alhálózatok elérési irányát és csak a saját alhálózat cél cím szerinti irányait tartalmaznia a táblázatnak

Forgalomirányítási döntési módszerek

Lehetnek: Egyutas, vagy többutas; Táblázat alapú, vagy táblázat nélküli módszerek.

Egyutas forgalomirányítás

Minden címhez egy továbbítási irányt tárol (táblázat) Előnye:

egyszerűségoptimális lehet (ha a tárolt irányok optimálisak)

Hátránya:nem robosztus (nem hibatűrő).

158


Többutas forgalomirányítás

Minden címhez több, súlyozott továbbítási irány, melyek közül pl. súlyozott sorsolással választhat.

Az irányok közüli választás szempontjai (sorsolási súlyok):előre megadott (fix) súlyok;prioritás (a csomagok prioritás határozza meg);a kommunikáció típusa: a forgalmi osztályok szerint (pl. gyors választ, vagy nagy sávszélességet igényel)a helyi sorok mérete (kifelé menő vonalak terheltsége) szerint (terhelésmegosztás)

Előny:több szempont figyelembevételére alkalmas;robosztus;adaptív.

Hátrány:Bonyolultabb (több feldolgozási időt

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

szabadulhasson tőle) Előny:

Nem kell információt gyűjteni,egyszerű, robosztus.

Hátrány:Rossz vonali kihasználtság,a késleltetési idő nem korlátos.

Az „elárasztásos” (flooding) módszer: minden csomagot minden irányba továbbít, kivéve ahonnan jött. Nagyszámú

többszörözött csomagot eredményez. Fékezési mechanizmusok:

Ugrásszámlálással (csomag fejlécben mező, melyet minden csomópont állít): Egy bizonyos ugrásszám után minden csomópontok eldobja őket.Csomagok sorszámozása: Az adó sorszámozza a csomagokat. Ha egy csomópont ugyanattól a feladótól ugyanolyan sorszámú csomagot kap, mint amilyet már korábban kapott, eldobja azt, mint másodpéldánytSzelektív elárasztás: A topológia ismeretében előre meghozza a forgalomirányítási döntéseket

Előny:Egyszerű, robosztus,optimális késleltetés.

Hátrány:Rossz vonalkihasználtság.

A „véletlen séta” módszer: A bejövő csomagot valamely véletlen irányba továbbítja Rossz vonalkihasználtság, de egyszerű és robosztus

159


Információgyűjtési módszerek

Lehetnek: Statikus, vagy dinamikus; Centralizált, vagy elosztott módszerek

Statikus: A hálózat üzemeltetője tölti ki a csomópontok táblázatait Bemeneti paraméterek (a kitöltő számára) Pl. Legrövidebb út algoritmus, ahol állandó a kiindulási állomás

Dinamikus: Ilyenek a táblázatnélküli módszerek és a „fordított tanulás” (backward learning) módszer

Centralizált: Működése:

központ (nagy kapacitású) begyűjti az összes információt a csomópontokról (topológia, forgalmi irányok, terhelés)ebből kiszámítja az optimális utakatletölti azokat a csomópontok tábláiba.

Elosztott forgalomirányítás Működés:

A szomszédok időnként átadják egymásnak aktuális tábláikat (ismereteiket a hálózatról)A táblázatok tartalmazzák

1. az egyes célok elérési irányait2. az illető cél távolságának (ugrásszám, vagy elérési idő) becsült értékét

A táblákat kapó állomás hozzáadja a távolság értékekhez a táblát küldő becsült távolságát és ez alapján frissíti a saját táblázatát.

Előny:közel lehet az optimumhoz, (Pl. IP routing)adaptív, robosztus.

Hátrány:szolgálati kommunikációSzámításigényes feldolgozás

160


6.c Torlódás vezérlésA torlódásvezérlés célja; pufferek előrefoglalása, csomageldobás, lefojtó-csomagok

módszere, izaritmikus és forgalomszabályozásos 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.

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

Pufferek előrefoglalása

Minden átvinni kívánt csomagnak előre foglal puffert Virtuális áramkör alapú hálózatokban használható, a hívásfelépítés során rendel a

virtuális áramkörhöz pufferterületet - a hívásfelépítő csomag nemcsak táblabejegyzéseket generál, hanem puffereket is foglal.

Elutasítás lehetséges, amennyiben nem áll rendelkezésre az igényelt erőforrás Hátrány:

nem gazdaságos (fölösleges pufferkapacitást foglal le) (sőt elutasíthat emiatt más hívásfelépítést).Megoldás pl: a sokáig tétlen puffereket felszabadítja.

Csomageldobás

First-Come-First-Served módon használja a puffereket ha betelnek, eldobja az újabbakat

Módosításai:A bemenetekre legalább 1db puffert le kell foglalni és szabadon kell hagyni (ne váljon süketté)Pl: szolgálati üzenetek: ha egyéb, eldobja, ha speciális üzenet feldolgozza nem lesz „süket”.

Pufferek felosztása a kimenetek közöttkorlátozza a kimeneti puffer-sorok maximális hosszaitugyanakkor minimális pufferszámot is előír a kimenetekre (a „kiéhezés” ellen)A max pufferszám a forgalom függvénye.Pl: „Ökölszabály” a kimeneti pufferek max számára : ahol

p: a pufferek össz száma;

k: a kimenetek száma;

m: a max hossz egy kimenetre. Eldobási szempontok (prioritások)

pl. prioritási osztályok szerint, vagypl. az ugrások számát nézik, és azt dobják el, amelyik kevesebbet utazott(valószínűleg kisebb erőforrás-igényű ennek a megismétlése)

161


Lefojtó-csomagok módszere

A források fojtása (még mielőtt a torlódás beállna) Csomópont figyeli a kimenő vonalainak telítettségét, és ha az egy küszöbértéket túllép

lefojtó-csomagot küld a feladónak de az eredeti csomagot továbbítja. Az eredeti (továbbított) csomagot meg is jelölheti: ez a csomag már váltott ki fojtóüzenetet

A küldő adaptivitása:az első lefojtó-csomag vétele után csökkenti a forgalmát, majdegy időzítés ideig nem fogad újabb fojtó csomagotEnnek leteltével újabb időzítés:

ha ezalatt újabb fojtócsomag érkezik:tovább csökkenti forgalmát,ha nem érkezik :visszanöveli az adott célirányú forgalmát.

Izaritmikus torlódásvezérlés

Korlátozza a hálózatban egyidejűleg bentlévő csomagok számát Engedélyező csomagokat (permit) használ

csak akkor adhat, ha engedélyező csomagot kapottmajd utána újabb engedélyező csomagot generál

Az engedélyező csomagok körbejárnak a hálózaton. Módosítása: Engedélyező központ, akitől lehet engedélyt kérni. Gond:Engedélyező csomagok megsemmisülése

Forgalomszabályozásos torlódásvezérlés

A forgalomszabályozás:adó ne árasszon el vevőt (két állomás viszonyára)

A fogadóállomások a forgalomszabályozást nem a kapacitásuk függvényében alkalmazzák, hanem valamilyen abszolút korlátozást vesznek figyelembe

Ha a korlátok megfelelőek biztos, hogy jó ha egy kicsit nagyobbak lehet, hogy nem egyenletes terhelés esetén egyes pontokon torlódások alakulnak ki.

Gond: alacsony korlátok esetén nagy késleltetések.

162


6.d A hálózatközi együttműködés – heterogén hálózatok kialakításának eszközeiA hálózatközi együttműködés eszközei (ismétlő, híd, forgalomirányító), jellemzőik, működésük.

Hálózatközi együttműködés

Általában a hálózatok összekötése több rétegben is lehetséges (az összekötött hálózatok lehetnek azonos típusúak is.)

Hálózatok összekötésének általános céljaa hálózat kiterjesztése Az összekötés eszközei a rétegek szerint csoportosíthatók:

Hálózatközi együttműködés – az eszközök feladatai

Technológiai korlátok kiterjesztése(pl: max. kapcsolódó állomásszám növelése)

Nagyobb távolság áthidalása(hálózat méretének kiterjesztése)

Forgalom szeparálás(terhelés leválasztás (üzenetszórás))

Heterogenitás leküzdése(különböző típusú hálózatok összekötése)

Biztonsági megfontolások(forgalom leválasztás, forgalom szűrés, tűzfal (Proxy))

Repeater (ismétlő, media konverter, aktív hub):

Funkciói:Az átviteli közeg csillapításából adódó korlátozások leküzdése. Több pont-pont összeköttetés egy üzenetszórásos csatornává alakítása (pl. Ethernet UTP-n).

Működése:A vett kereteket (bitfolyam) jelfrissítés után az összes kimeneten továbbítja (kivéve ahonnan jött). Protokolláris, közeg-hozzáférési funkciót nem lát el (kivéve, a CSMA/CD esetén az ütközés továbbítása). Kettő vagy több hálózatot köthet össze. Alkalmas különböző fizikai közegek összekötésére (lásd mint „média konverter”). Jellemzői: Különböző fizikai közegeket köthet össze, de csak azonos MAC (Media Access Control) eljárású hálózatokat köthet össze. A felsőbb protokollokra nézve transzparens.

Speciális funkciók:Pont-pont kapcsolatok üzenetszórások közeggé alakítása (pl.UTP). Fizikai közeg típusváltás (média konverter). Speciális biztonsági funkciók egyes ismétlőknél pl.: - portjaihoz általában 1-1 állomás kapcsolódik. - Egy adott port csak attól fogad el keretet (kapcsoló állomás), akinek a MAC-címét (6 byte) adminisztratív eszközökkel beállították. - Az ismert cél című keretet csak a cél MAC-című állomásnak továbbítja eredeti formájában, a többi kapcsolódó állomásnak csak a kerettel azonos hosszúságú véletlen jelet továbbít.

163


Bridge (híd):

Funkciói:Közeg-hozzáférési eljárások késleltetési korlátját küzdi le. Közeg-hozzáférési szempontból (MAC) független hálózatokat köt össze. Működése: Két vagy több hálózatot köthet össze. Mindegyik hálózaton önálló állomásként van jelen. Valamely hozzá kapcsolódó hálózaton vett keretet a többi (vagy egyik) hálózatra továbbítja. Típusai: Transzparens hidak (transparent) vagy feszítőfás hidak (spanning tree); Forrás által forgalomirányított hidak (source routing).

Bridge – Előnyök :Egyszerű installálhatóság; Transzparens, bárhova tehető. Hálózati protokoll független. A pusztán hidakkal/ismétlőkkel összekötött hálózat egy logikai hálózatnak tűnik. Jó ár/teljesítmény viszony.

Bridge – Hátrányok:Nem képesek terhelésmegosztásra a redundáns utak között. Bizonyos helyzetekben nagy forgalomtorlódást okozhatnak. Az egyes hálózati részek forgalma részben keveredik, nehéz a forgalmat kézben tartani, hibát (támadást) keresni. A hálózat forgalmának bármely része lehallgatható

Router - forgalomirányító - útvonal-irányító:

Funkciója:Szeparált hálózatokat össze. Működése: Forgalomirányítás (csomagok forgalomirányítása) router táblázatok alapján. A hálózati rétegben működik, ezért hálózati-protokoll függő.

Típusai:Egy protokollt kezelő routerek; - Multiprotocol router: (több protokoll csomagformáját ismeri, párhuzamosan köt össze különböző protokollok szerint); - Brouter (bridge router): ha felismerhető a protokoll, router; ha nem felismerhető a protokoll, bridge-ként működik.

Gond:az olyan hosszúságú csomagok kezelése, amely meghaladja valamely köztes alhálózat maximális csomagméretét. Kezelése: a továbbítás megtagadása, vagy a csomag feldarabolása (fragmentation). A feldarabolás lehet transzparens (a routerek össze is rakják) vagy nem transzparens (csak a célállomás rakja össze).

Jellemzői:Különböző MAC hálózatokat köthet össze. Protokollfüggő eszköz. Teljes forgalomszeparálásra képes. Alkalmas nagy távol További funkciók lehetnek: Adat-/hálózatvédelem – csomagszűrő tűzfal. Felhasználó menedzsment – hozzáférés engedélyezés/tiltás. Kapcsolat és útvonal menedzsment – kapcsolat engedélyezése/tiltása, útvonalak megválasztása ság áthidalására. A hálózat méretére, állomásszámára nincs elvi korlát.

Router – Előnyök:Teljes forgalom szeparáció. Alternatív utak közötti terhelésmegosztás. Rugalmas konfigurációs lehetőségek, forgalomirányítási szabályok, „csomagszűrő” tűzfal.

Router – Hátrányok:Konfigurálni kell. Protokollfüggő. Valamivel lassabb a Bridge-nél. Nem route-olható protokoll esetén ő is csak bridge-ként működik.

164


7. A TCP/IP protokoll szövet és az Internet

7.a A TCP/IP protokoll szövet struktúrájaAz Internet hivatkozási modell (DoD) és az ISO-OSI hivatkozási modell összevetése. A

TCP/IP protokoll szövet főbb részei (ARP, RARP, IP, ICMP, TCP, UDP) és azok funkcióik.

Internet: TCP/IP protocol stack

Hierarchikus címzés is lehetséges Világméretű hálózat alakítható ki belőle Újabb elnevezések:

Internet: „külső” hálózat (WAN)Intranet: „belső” hálózat (LAN)

Általános hálózati kommunikációs szolgálatok készletét biztosítja A szolgálatok szabványosítottak, és ma már szinte valamennyi OS-re implementálták Internet testületeket, szabványosítás

Protocol Status Levels

Valamennyi TCP/IP protokoll az alábbi öt állapot valamelyikében van: Required – szükséges Recommended – ajánlott Elective – választható Limited use – részlegesen használható Not recommended – nem ajánlott

Az Internet hivatkozási modell (DoD)

165


Az ISO/OSI és a DoD modellek

A TCP/IP protokol stack

Szállítási réteg:TCP:

Transmission Control Protocol (Telnet, Rlogin, FTP, SMTP) megbízható adattovábbítás (összeköttetés alapú szolgálat)

UDP: User Datagram Protocol (TFTP, SNMP, DNS (TCP is)) összeköttetés-mentes datagram szolgálat

Hálózati réteg:IP: Internet Protocol

összeköttetés-mentes datagram szolgálat változó méretű csomagokra → Best effort delivery (a telhető legjobb): változó késleltetés, hiba, adatvesztés → kapcsolódhat hozzá alkalmazói program közvetlenül, de ritka

ICMP: Internet Control Message Protocol → a hálózati réteggel kapcsolatos üzenetek (pl.

Router csomageldobás esetén visszaüzen) → lehet közvetlen alkalmazói program kapcsolat (pl. ping –echo request/reply)

IGMP: Internet Group Management protocol → multicasting (többes címzés)-el kapcsolatos

üzenetek

166


Adatkapcsolati réteg:Hardware interface:

megbízható csatorna kialakítása → keretképzés, hibavédelem, adatfolyam vezérlés, kapcsolat menedzsment

ARP: Address Resolution Protocol

RARP: Reverse Address Resolution Protocol → Ethernet Broadcast → MAC címek ↔ IP

címek közötti kétirányú megfeleltetés

Az ARP (RFC 826)

Feladat: host vagy router IP címének leképzése MAC címmé Fogalmak, alapok:

IP cím: hálózat + host cím, a subnet maszk segít a szétválasztásbanDefault router: egy hálózathoz tartozó router és annak IP címeHelyi kommunikáció: egy hálózaton belül

Ua a hálózati cím (ua a subnet-mask)Távoli kommunikáció: hálózaton kívüli

más a hálózati cím Fogalmak:

Címzési szabályok:minden hosztnak (legalább egy) egyedi IP címe vanaz egy hálózaton lévőknek közös a hálózati címe (netid) és a szubnet maszkja

A hálózat itt azonos a „Broadcast Domain”-nel!A hálózat azon része, melyről „Local Broadcast Packet” használatával információt nyerhetek

ismétlők, hidak továbbítják a Local BroadcastPacket-et,routerek nem!

A szegmensen belül helyi kommunikáció, „Direct Delivery” (közvetlen kézbesítés) van.

A MAC címek nyerhetők:Local Broadcast ARP_REQUEST küldése után a válaszokból ARP_REPLY (amiket azonnal cache-elni lehet)Majd a későbbiekben a cache-ből (IP - MAC párok)

A továbbiakhoz tegyük fel, hogy megvan a cél IP címe (Pl. DNS-ből)

A RARP

Saját IP cím lekérdezése (pl. boot) a saját MAC cím alapjánRARP_REQUEST Broadcast-alA szerver táblázat alapján válaszol RARP_REPLY

További protokollok

Boot Protocol (RFC 1542)MAC és IP cím statikus összerendeléseKliens-szerver-relay_agent konfigurációUDP csomagokban request-reply

Dynamic Host Configuration Protocol (RFC 1541)MAC és IP cím dinamikus összerendelése,címtartományok kijelölhetők,címhasználat időben korlátozódhat,kérheti a korábbi címét,

167


hasznos erőforrások (pl. DNS) jelezhető,BOOTP-vel felülről kompatibilis.

Az ICMP

Internet Control Message Protocol Az alapvetően a hálózati réteggel kapcsolatos üzenetek továbbítására Az ICMP enkapszuláció ICMP message Típusok:

hibaüzenetek,információk,diagnosztikai üzenetek.

Az ICMP hibaüzenetek mindig tartalmazzák annak az IP datagram-nak a fejrészét (20 byte) és első 8 bájtját, ami a hibát okozta.

Így a fogadó ICMP modul meghatározhatja a protokollt és a user processzt, amihez a hiba tartozik.

168


7.b Az Internet címzés és címosztályokIP címosztályok, maszk, subnet, supernet, osztály nélküli címzés (CIDR Classless Inter-Domain Routing), és a változó alhálózat méretek(VLSM Variable Length Subnet Mask);

címek kiosztása, lokális címek és a címfordítás (NAT).

Internet címek

32 bit, 4 byte Pontok közötti decimális alak

(Dotted decimal notation - egészen jól olvasható)164.107.134.510100100.01101011.10000110.00000101 (bin)A4:6B:86:05 (hexa)

Max címszám: 232 = 4 milliárd csomópont Class A Networks = 15 millió csomópont Class B Networks = 64K csomópont Class C Networks = 250 csomópont.

IP címosztályok

Hierarchia: hálózat cím + hoszt cím (netid+hostid) Class A

0.0.0.0 - 127.255.255.255 Class B

128.0.0.0 - 191.255.255.255 Class C

192.0.0.0 - 223.255.255.255 Class D (többes címzés)

224.0.0.0 - 239.255.255.255 Class E

240.0.0.0 - 247.255.255.255 multicast: többes címzés az üzenet a multicast csoport minden tagjának szól

(broadast → mindenkinek szól)

IP címtér

169


Speciális címek és jelentésük

Klasszikus címzés összefoglaló

A cím egyértelműen két részre bonthatóaz első bitek megmondják, hol a határugyanakkor merev bit-határokbroadcast cím egyértelműen számítható (a host id. csupa 1-es)

Igény a címzési hierarchia bővítéséreIntézményi hálózatok fejlődésea pazarló A és B osztályok elfogytakpont-pont kapcsolatokra teljes C osztály

Alhálózat (subnet) bevezetése

Az eredeti felosztás

A subnet maszkkal azértékes biteket kijelöljük

170


Alhálózat címzések

A (sub)net maszk (RFC 950) A kiterjesztett hálózati azonosító hosszabb lehet, mint a címosztály hálózati

azonosítója! C osztályú címnél a default maszk: 255.255.255.0 A prefix jelölés:

193.6.5.0/24193.6.5.0255.255.255.0

A subnetting eredménye

A címező jobb kihasználásapont-pont kapcsolatok 2 biten elférnektöbb LAN befér egy IP hálózatba

A cím nem tartalmazza a hálózat-azonosítótA maszkot is jól kell konfigurálni

a broadcast cím nem található ki az IP címbőlA maszkot is kell továbbítani (plussz 4 byte az útvonal-választási információkban)De az útvonalválasztás egyszerűsödhet (pl. hálózatok összefogása „szupernetting”)

Alhálózat címkiosztási példa

Adott 193.6.5.0/24; és bontsuk öt egyforma méretű alhálózatra! 22 < 5 < 23 → 3 subnet bit kell → /27 a prefixes (255.255.255.224) jelölés →

valójában 8 alhálózatra osztunk A Subnet 4-et osszuk ki

Csak 30 gépet tudunk azonosítani, mertegyet elvisz a subnet azonosító,egyet pedig a subnet broadcast cím ...

Változó alhálózat méretek

Variable Length Subnet Mask (VLSM) (RFC 1009) Különböző alhálózatok létrehozása

hatékonyabb címfelhasználás A routing-nak támogatnia kell (RIP-1 nem jó!)

a kiterjesztett prefixet (subnet maszkot) is át kell adni (terjeszteni kell)Minden router a leghosszabb prefix egyezése elvén továbbítsa a csomagokatAz aggregációhoz a címkiosztásnak követnie kell a topológiai feltételeket

A többszintű hierarchia előnyealhálózatokat tovább tudunk bontaniaz aggregáció miatt ez kívülről nem látszik

171


Az osztály nélküli címzés

Classless Inter-Domain Routing (CIDR) (RFC 1517-1520) A maszk rövidebb is lehet, mint a hálózat-azonosító (superneting) pl:193.6.0.0-193.6.15.0 16db C osztály → 255.255.240.0 (/20) → 193.6.0.0 /20 Több hagyományos A,B,C osztály összefogása laza bithatárok: /4 … /30 szükségtelenné válik az osztályok használata a routing nem az első bitek szerint dönt a címtér sokkal jobban kihasználható A CIDR együtt élhet a klasszikus routinggal, de a régebbi eszközök nem mindig

kezelik

A VLSM és a CIDR

Mindkettő támogatja egy A, B, C hálózatonflexibilis alhálózat-rendszer kialakításátbelsejének elrejtését (aggregáció)

A CIDR azonban lehetővé teszitöbb bitszomszédos hálózatok összefogását (supernetting) és ezen belül tetszőleges hierarchia kialakításáttöbb szomszédos A, B, C hálózat összevont útvonalválasztási bejegyzését

Címfoglalási szabályok

A globális Interneten minden IP cím egyedia globális IP címeket engedélyeztetni kell (IANA, EU: RIPE)

Internettől elszigetelt magánhálózatontetszőleges kiosztást készíthetünk, de így akésőbbi esetleges csatlakozás gondot okozhat.Lokális címtartományok (IANA) (RFC 1918)

10.0.0.0./8172.16.0.0./12192.168.0.0./16

Magánhálózat csatlakoztatása az internetre

Ha bejegyzett címtartományokat használtunk, nincs gond. A lokális címtartományú magánhálózatot tűzfallal leválasztjuk (se ki, se be) nincs

gond, de nem használható az Internet közvetlenül Lokális címtartományú magánhálózatról bejegyzett címtartományra kívánunk áttérni

átszámozás (elég költséges),címfordítás NAT (Network Address Translation) (RFC 1631) lehetséges.

Címfordítás, NAT (IP masquerade)

A belső és a külső IP címek összerendeléseCímfordítási táblázat (ötlet ua. Protokoll – több port):

Egyetlen külső cím esetén:

172


Kicseréli a belső forrás címet a külső címre Megnézi, hogy az eredeti forrás port szabad-e a külső oldalon. Ha szabad, akkor azt választja. Ha foglalt, akkor a szabad (választható) portok közül választ egyet. Ha nincs szabad port, akkor eldobja a csomagot. Bejegyzi egy táblázatba a fordítást a visszafelé jövő, illetve a további csomagok

érdekében.Több külső cím esetén:

Ha nincs szabad port, akkor veszi a következő külső címet és azon keres szabad portot. (Ugyanúgy mint egy cím esetén.)

A NAT transzparens mindazon protokollokra melyeknem használnak IP címeket a csomag belsejében,nem használnak előre megbeszélt, vagy magasabbszinten egyeztetett címet.

A NAT amennyiben felismeri (és ismeri) a magasabb szintű protokollokat, úgy a csomag belsejében is elvégezheti a címváltoztatást.

Pl: FTP (a behívó kliens mondja meg a szervernek, hogy hova hívjon vissza a szerver –

aktív FTP, (passzívnál a behívó hív újra)). embedded IP Addresses in DNS "A and PTR" records. NAT will translate the

address(es) which appear in DNS responses to name lookups (A queries) and inverse lookups (PTR queries).

173


7.c Az IP csomagformátumAz IP csomagformátum főbb mezői és azok funkciói.

IP csomagformátum:

Verzió: 4 (IPv4) IHL: Header length (a header hossza az opciókkal együtt)

32 bites szavakban 4 bit a header max 60 byte hosszú lehet TOS: Type of Services, csak 3+4 bitet használ:

3 bit a prioritásra (7 a magas, 0 az alacsony) + 4 bit:D bit: Minimize delay (Pl. telnet)T: Maximize throughput (Pl. Ftp data) egyszerre csak 1 bit lehetR: Maximize reability (pl SNMP)Minimize monetary cost(Nem minden implementáció használja (pl. OSPF dönthet ez alapján))

Total length: az IP datagram teljes mérete bájtokban16 bit IP datagram max. 65535 byte

Identification: a datagram egyedi azonosítója, amit a küldő hoszt állít be (pl fregmentáció esetén azonosítja az egyes darabokat)Flags (3 bit):

1 bit nem használt 1 bit (DF): "don't fragment" bit: ha 1, a csomag nem fregmentálható.

Ha mégis kellene: ICMP error "fragmantation needed but don't fragment bit is set" 1 bit (MF): fregmentálás esetén 1, ha van még további darab; 0, ha ez az utolsó

Fragment offset (13 bit): fregmentáció esetén a data melyik része (milyen az eltolás 8 byte-okban számolva). Az első darab esetén = 0. Az összes darab hossza csak 8 egész többszöröse byte lehet (kivéve az utolsó darabot).

174


Time to Live (TTL, 8 bit):Minden ugrás esetén a router annyival csökkenti, ahány sec-ot állt nála (de legalább 1-gyel).Régebben 32 v. 64, manapság 128 kezdeti értékkelHa eléri a 0-át,

a router eldobja ésICMP "time exceeded" error a feladónak.

Protocol: az IP csomagot előállító protokollt (pl TCP, UDP, ICMP, IGMP) azonosítja Header cheksum: az IP fejrészre vonatkozó 1 komplemens 16 bites összeg. Mivel a

TTL változik, mindig újraszámítandó (Hop). Hiba esetén eldobják a csomagot. (A vevő az egészre számol 1 komplemens összeget → ha jó, csupa 1)

SA, DA (IP címek) Opciók és adatok

175


7.d Az IP csomagok továbbításaHelyi és távoli kézbesítés, forgalomirányító, enkapszuláció.

Az IP csomagok továbbítása

Megvizsgálja a cél IP címet, az „helyi”, vagy „távoli”A saját subnet maszkkal leválasztja a hálózati címrészt, és összeveti a sajátjával: ha egyezik: helyi, ha nem: távoli.

Ha helyi, akkor (Direct Delivery)Nézi a cache-ében, van-e hozzá MAC cím. Igen: a MAC szinten elküldi a címzettnek.Nincs: Local Broadcast kezdeményezéssel választ kér, és így megkapja a cél MAC címet. Mindjárt cache-eli, és MAC szinten elküldi a címzettnek.

Ha a cél cím „távoli”, akkor (Indirect Delivery) Nézi saját forgalomirányító tábláját (route table), van-e speciális út a célhoz, ha van,

keresi a cache-ében, ismeri-e az úthoz rendelt router MAC cím. Igen: MAC elküldi annak.Nincs: Local Broadcast kezdeményezéssel választ kér, és így megkapja a router MAC címet. Mindjárt cache-eli, és MAC szinten elküldi neki

Ha nincs speciális út (esetleg nincs is forgalomirányító tábla) – a default router-nek küldi:

Nézi a cache-ében, van-e a default router-hez MAC cím. Igen: MAC elküldi annak.Nincs: Local Broadcast kezdeményezéssel választ kér, és így megkapja a default router MAC címet. Mindjárt cache-eli, és MAC szinten elküldi neki

Az IP routing

Az útvonalválasztó az eredeti datagram-on a következőket változtatja meg:Dekrementálja a Time-to-Live mezőt (amiből eldönthető, hány sec-ig, vagy ugrásig maradhat meg a datagram).Újraszámítja a checksum-ot.

IP routing tábla

Egy router a routing tábláját nézi végig, hogy melyik portjára (melyik interfészére) küldje a datagramot.

A keresési kulcs a cél IP hálózati címe.A kereséshez kell a szubnet maszk is.

A csomagtovábbítása leghosszabb illeszkedő prefix (longest prefix match),hop-by-hop (azaz minden router maga dönt),nem megfelelő router választása esetén (a router ugyanazon interfészén visszaküldi a csomagot) ICMP Redirect a küldőnek.

176


Az enkapszuláció

177


7.e Az UDP datagram és a TCP szegmens felépítéseAz UDP datagram fej és a TCP szegmens fej főbb mezői és azok funkciói.

UDP: User Datagram Protocol

Egyszerű, ÖK mentes (datagram), nem megbízható szolgálat. Minden továbbítandó üzenet 1 UDP datagram (amit egy IP datagam-ként, csomagként

továbbítanak)

UDP Header

16 bit a forrás és cél szolgálat elérési port szám 16 bit UDP length: a teljes UDP csomag hossza byteban

16 bit → min 8 (header): max 216 – 8byte (UDP header) (az IP csomag 216 – 20byte IP header és abba is bele kell férnie) (implementációfüggően ált. kevesebb)

16 bit UDP checksum az UDP header+UDP data-n (biztonság növelésére az IP header egy részére is kiterjed, hasonlóan a TCP checksum-hoz), a feladó generálja (opcionális), a vevő ellenőrzi: 1 komplemens 16 bit összeg (ha a vett CS=0 → az adó nem használja )

UDP pszeudo fej a checksum számításhoz

Ha a Checksum = 0 lenne → 65535 (-0, 1-komplemenst) továbbít A Checksum = 0 a checksum hiányát jelzi (az adó nem használja)

TCP Transmission Control Protocol

Bonyolultabb, ÖK alapú (sorrendhelyes), megbízható (hibamentes), duplex (kétirányú) szolgálatot biztosít. Meghatározza az IP felé az optimális csomagméretet „TCP szegmens”: az IP felé továbbított adategység „Byte stream service”: ha a kapcsolat felépült, a forrás byte-okat küld, a cél byte-okat

fogad folyamatosan (virtuális áramkör byte-okra)

TCP = Transmission Control Protocol

178


Connection-oriented OP Transport RFCs

RFC 793 defines TCPRFC 1122 – bug fixes and clarificationRFC 1323 – extensions

TCP segmentOne IP datagram

MTU = Maximum transfer unit

TCP Service Model

Well-known ports = 0-1023 Inetd = super server can handle requests for multiple services

Port Protocol Use21 FTP File transfer23 Telnet Remote login25 SMTP E-mail69 TFTP Trivial File Transfer Protocol79 Finger Lookup info about a user80 HTTP World Wide Web110 POP-3 Remote e-mail access119 NNTP USENET news

TCP Header

Socketpair:Client IP, Client Port, Server IP, Server Port négyes azonosítja a kapcsolatot.

A flag-ekSYN: új kapcsolat megnyitásakor (ezt jelzi) → „szinkronizáció”, → a sequence number ilyenkor: ISN (Initial SN) – kezdeti értékACK: a nyugta sorszáma érvényes (nyugta)URG: Urgent pointer érvényes: az a sürgős üzenet végére mutat (pl. megszakítás kérelem, előzze meg a többit)PSH: a vevő a lehető leggyorsabban továbbítsa az adatokat az alkalmazás feléRST: Reset Connection (azonnali kapcsolatbontás, bármely fél kezdheti, RST a válasz rá)FIN: a küldő befejezte az adatok küldését

OpciókPl. MSS: Maximum Sized Segment

A kapcsolat felépítésekor (SYN) mindkét oldal maghatározhatja a számára maximális szegmensméretet

179


7.f Az IPv6Az IPv6 címek, IPv6 cím típusok (unicast, multicast, anycast; link local, site local, global

scope), azIPv4 és IPv6 keretformátumok összevetése.

IPv6 – Címzés: Jelölés

Preferred form (16 byte):FEDC:BA98:7654:3210:FEDC:BA98:7654:32101080:0:0:0:0:8:800:200C:417A

Compressed form:1080::8:800:200C:417A0:0:0:0:0:0:0:1 ==> ::1 (Unicast Loopback address)FF01:0:0:0:0:0:0:42 ==> FF01::42 (Multicast address)0:0:0:0:0:0:0:0 ==> :: (The unspecified address)

IPv6 – Címzés: Kompatibilis címek

IPv4-kompatibilis cím0:0:0:0:0:0:193.6.5.73 ==> ::193.6.5.730:0:0:0:0:0:w.x.y.z ==> ::w.x.y.zCsak akkor, ha IPv4/IPv6 dual stack.Ha IPv4-kompatibilis címet adnak meg úgy, mint egy IPv6 cél címet, akkor az IPv6 forgalom automatikusan IPv4 fejrészt kap és az IPv4 hálózaton küldik a cél felé.

IPv4-mapped address0:0:0:0:0:FFFF:193.6.5.73 ==> ::FFFF:193.6.5.73Csak belső reprezentáció, senki sem küld ilyet.Az IPv6 node jelöli így a csak IPv4 node-ot

6to4 cím2002::/16 cím 32 bites publikus IPv4 node címmel, egy 48-bites prefixet alkot.Pl: 193.6.5.73 esetén (Hexában: C1.6.5.49) 2002:C106:0549::/48Két IPv4 és IPv6 dual stack node között használják, ha azok IPv4 routing infrastruktúra felett kommunikálnak.A 6to4 egy RFC 3056 szerinti tunnel technika.

Az IPv6 nem használ maszkot, csak prefixet.

IPv6 – Címzés: Cím típusok

Unicast: egy – egy kommunikáció Multicast: egy – több kommunikció Anycast: egy – legközelebbi kommunikáció

IPv6 – Címzés: Unicast címek

Aggregatable global unicast addresses Link-local addresses Site-local addresses Special addresses

(loopback, unspecified compatible)

IPv6 – Link-Local unicast addresses

A link-local címek a Neighbor Discovery eljáráshoz kellenek és mindig automatikusan konfigurálódnak, még akkor is, ha semmilyen más unicast cím sem létezik.

A link-local címek prefix-e mindig FE80::/64

180


IPv6 – Site-Local unicast addresses

A link-local címekkel ellentétben, a site-local címek nem automatikusan konfigurálódnak, hanem vagy állapotmentes (stateless), vagy állapot alapú (stateful) cím konfigurációval kell megadni azokat.

A site-local címek esetén az első 48-bit mindig ugyanazzal a FEC0::/48 címmel kezdődik.

A fix 48 bitet követi a 16-bites subnet identifier(Subnet ID field).

IPv6 előnyök:

Az IPv6 címek 128 bitesek (könnyű subnet-eket kialakítani; nem kell NAT). Az IPv6 címek nem hoszt/node címek (mint IPv4), hanem „interfész” címek. Egy hosztnak lehet több interfésze (címe). IPv6 címek esetében vannak különböző hatáskörök (scope). Unicast (one-to-one communication), multicast (one-to-may communication), anycast (one-to-nearest communication) is lehet. Ugyanakkor nincs „broadcast”. Új header format. Nagy címhely. Állapotmentes (stateles) és állapot alapú (stateful) automatikus cím konfiguráció.

Link-local addresses:

A link-local címek a Neighbor Discovery eljáráshoz kellenek és mindig automatikusan konfigurálódnak, még akkor is, ha semmilyen más unicast cím sem létezik. A link-local címek prefix-e mindig FE80::/64Site-local addresses: A link-local címekkel ellentétben, a site-local címek nem automatikusan konfigurálódnak, hanem vagy állapotmentes (stateless), vagy állapot alapú (stateful) cím konfigurációval kell megadni azokat. A site-local címek esetén az első 48-bit mindig ugyanazzal a FEC0::/48 címmel kezdődik. A fix 48 bitet követi a 16-bites subnet identifier (Subnet ID field)

181

lehetséges írásbeli szigorlati kérdések az...

Documents