Informatika | Tanulmányok, esszék » Csizmazia Balázs - Kliens-szerver modellen alapuló operációs rendszerek a Mach mikrokernelen

Kliens-szerver modellen alapul
o oper
aci
os rendszerek a Mach mikrokernelen TDK - Tanulm
any Szerz}o: Csizmazia Balazs Budapest, 1996 - ELTE Tartalom 1 Az osztott rendszerekr}ol altalaban 1.1 1.2 1.3 1.4 Architektura Osztott rendszerek alaptulajdonsagai Interfeszek szerepe az osztott rendszerekben Globalis alaptulajdonsagok megvalostasa 1.41 Nevek rendszere 1.42 Hozzaferesi modell 1.43 Biztonsagossagi modell 1.44 Menedzselesi modell 1.45 Elerhet}osegi modell 1.5 Processzek kommunikacioja osztott rendszerekben 1.51 Az OSI referenciamodell retegei 1.52 Osztott rendszerek kommunikacios protokolljai 1.53 Osztott rendszerek szerkezete 1.54 A tavoli eljarashvas 1.55 Csoportkommunikacio 1.56 Csoportkommunikacio uzenetsorrendtartasa 7 : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 2 A Mach 3.0 mikrokernel attekintese 2.1 2.2 2.3 2.4 2.5 A Mach kernel absztrakcioi Taszkok es threadek Memoriakezeles Taszkok kozotti kommunikacio A Mach alatti hardver : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 3 Architektura modell 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 3.16 A virtualis kornyezet elemei Threadek Taszkok Biztonsagi port Ledgerek Portok U zenetek U zenetek sora Port hozzaferesi jogok Portnevek

rendszere Porthalmazok Virtualis cmtartomany Absztrakt memoria objektumok Memoriaobjektum reprezentatva Memoria cache objektum Processzorok 28 29 30 31 32 33 36 : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : 2 7 10 12 12 12 13 14 15 16 16 17 18 20 20 23 25 36 40 41 42 43 43 44 44 44 45 46 47 48 48 49 49 3.17 3.18 3.19 3.20 3.21 Processzorhalmazok Host objektumok Csomopontok O ra objektumok Kernel periferiak : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 4 A Mach feletti szerverek 4.1 Nev-szolgaltatok szerepe 4.2 Objektum-orientalt szerverek kesztese 4.3 Pelda egy Mach szerverre 4.31 A peldaszerver specikacioja 4.32 A peldaszerver szolgaltatasai 4.33 A MIG altal generalt fajlok 4.34 A szerverunk kornyezete 4.35 Egy kliens a szerverunkhoz 53 : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 5 POSIX 1003.1 emulacio a Machon 5.1 A tortenelem 5.2 A rendszerstruktura (egy vagy tobb szerver) 5.3 A POSIX emulacio eszkozei 5.31 POSIX 10031-konformitas a C konyvtarban 5.32 POSIX 10031-konformitas elerese Mach szerverekkel 5.33 Az alkalmazas es a POSIX szerverek kapcsolata 5.4 Biztonsagossagi kerdesek 5.41 Exhibicionista kliensek 5.42 Az eszkozmeghajtok problemaja 5.43 Er}oforrasfalo taszkok 5.44 Szerverek elarasztasa 5.5 A POSIX fajleleresi szemantika 5.6 A buer cache szerep(te)vesztese : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : 6 Mach feletti POSIX szerverek attekintese 6.1 A POE operacios kornyezet szerver 6.11 A POE emulatora 6.12 A POE szerver 6.13 A POE inicializalo programja 6.2 Az OSF/1 operacios rendszer csalad 6.3 Az OSF/1 MK szerver 6.4 Az OSF/1 AD szerver 6.41 Tervezesi celok 6.42 Architektura 6.43 Megvalostas { POSIX konformitas 6.5 A jbss szerver 6.51 A jbss szerver lehet}osegei 55 55 56 56 59 59 66 68 71 : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 71 73 74 75 77 79 82 83 83 83 84 84 86 90 : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 3 50 50 51 51 51 90 91 91 92 92 92 93 93 94 94 95 96 6.52 A szerver installalasa 6.53 A szerver szerkezete : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 7 Osszefoglalas 8 Irodalomjegyzek 96 97 100 101 4 Temale
ras Regebben az operacios rendszereket altalaban ugy terveztek, hogy az operacios rendszer magjat egyetlen monolitikus egyseg alkotta, amely az osszes rendszerszolgaltatas biztostasaert felel}os volt. Az ilyen modon megrt operacios rendszerek karbantartasa a forrasanyaguk nagy merete (akar tobb millio C nyelv}u forrassor) miatt nagyon nehezkes es a gyakorlatban nehezkesnek bizonyul az ilyen feleptes}u rendszerek tovabbfejlesztese is, mert a monolitikus rendszerek tervez}oi altalaban nincsenek arra kenyszertve, hogy a programjaikat modszeresen { a modulok kozott jol denialt interfeszekkel

ellatva { tervezzek meg. Ebben a dolgozatban egy ujfajta operacios rendszer tervezesi modot fogok bemutatni, ahol az operacios rendszer a kliens-szerver modell szerint van megkonstrualva: e modellben az operacios rendszer funkcionalitast szerver(ek) biztostjak, es e szerverek kommunikaciojat valamilyen "minimalis" kommunikacio-orientalt szoftver szervezi meg (e szoftvert gyakran nevezik mikrokernelnek). Tobb ilyen mikrokernel is letezik, ezek kozul a dolgozatban a Mach 30 mikrokernelt fogom bemutatni es hasznalni egyreszt a legnagyobb mertek}u elterjedtsege miatt, masreszt pedig azert, mert ezen nemcsak kutatasi celu, hanem produktiv kornyezetben futo operacios rendszerek is vannak { a technologiaja ennek a rendszernek a legkiforrottabb. A dolgozatban a POSIX 1003.1 (ld IEEE90]) operacios rendszer szemantika Mach 30 mikrokernel feletti megvalosthatosagat vizsgalom ramutatok az eddig elkeszult hasonlo celu

szoftverek problemaira, a legtobb helyen egy helyes megoldast javasolva az egyes { megoldatlan, vagy az eddigiekben helytelenul megoldott { problemakra. A dolgozatban el}oszor az osztott rendszerekkel tamasztott alapvet}o igenyeket targyalom (a POSIX 1003.1 szemantika biztostasanak vizsgalatakor altalaban az itt kozolt alapelveket fogom olyan iranyelveknek tekinteni, amikre a megoldas megadasakor gyelemmel kell lenni) majd bemutatom a Mach mikrokernelt, vegul szo lesz a UNIX-szer}u POSIX szabvany szerinti alkalmazoi programozoi interfesz Mach feletti kliens-szerver modellben valo eleresenek a lehet}osegeir}ol (attekintve a jelenleg m}ukod}o es hozzaferhet}o POSIX-konform Mach alapu operacios rendszer szerver szoftvereket, azok hibait, es a dolgozatban megoldast adok nehany eddig { tudtommal { megoldatlan problemara). A kit}uz
ott feladat teljestesenek merteke Ebben a pontban attekintem azt, hogy a diplomamunka-tema

bejelent}oben kit}uzott celokat milyen mertekben tudtam teljesteni. A dolgozat tartalmazza a Mach mikrokernel 3.0-as valtozata altal nyujtott absztrakciok ismerteteset, es az egyes { kliens-szerver modell megszervezesere 5 is hasznalt { absztrakcios eszkozok hasznalati modjanak a lerasat (attekintve a Mach alapjaul szolgalo tipikus hardware architekturat, a NORMA MPP architekturat a rajta vegzett optimalizalt { csokkentett kontextuscserevel zajlo { uzenetadatasi es memoriakezelesi NORMA es XMM alrendszereket). Bemutatasra kerulnek az eddig elkeszult, es szabadon forraskodban is hozzaferhet}o POSIX-szer}u Mach feletti rendszerek, valamint az OSF altal elkesztett OSF/1 szervercsalad { a dolgozatban lev}o tobbi fejezetben bemutatott szempontok alapjan (szerkezeti, hatekonysagi es biztonsagossagi szempontok alapjan). A dolgozatban ezen kvul megvizsgalom a Mach alapu osztott rendszerek tervez}oi el}ott allo

tipikus valasztasi helyzeteket/okokat (peldaul az egyszerveres vagy tobbszerveres POSIX szerver implementacio kerdeset, valamint a transzparens emulacios konyvtar alkalmazasanak a kerdeset is), es bemutatom az egyes valasztasi alternatvak mellett es ellen szolo erveket.  Osszess egeben veve azt mondhatom, hogy a diplomamunka-tema bejelent}olapon kit}uzott feladatot teljes mertekben megoldottam az ott megfogalmazottaknak maradektalanul eleget tev}o modon. Az elkesz
ult program A dolgozat kereteben elkeszult egy program, amelyen { a kesztese kozben { ki tudtam probalni a Mach egyes absztrakcios eszkozeit, azok m}ukodeset es hasznalati modjat. Termeszetesen nem ezt a programot tekintem a dolgozat f}o eredmenyenek (a temabejelent}oben a konyvtarra vonatkozoan tett megjegyzes alapjan ez nem is volt cel), hanem az egyes problemakorok elemzeset es a gyelemfelhvast es megoldaskeresest a felmerult

problemakra, ezert a dolgozat nem tartalmaz reszletes programlistat (a program mereter}ol megjegyzem, hogy kicsit kevesebb, mint 6000 C nyelv}u sor). Az elkeszult program a dolgozathoz csatolt oppy-diszken megtalalhato UNIX tar formatumban. 6 1 Az osztott rendszerekr}ol altalaban Ebben a fejezetben osszefoglalom az osztott rendszerek gyakorlati alkalmazasanak lehet}osegeit, jelenlegi helyzetet. A kes}obbi fejezetekben az itt felmerult szempontokat fogom vizsgalni az ismertetett osztott rendszereknel. 1.1 Architektura Manapsag a szamtogepes halozatok orasi utemben fejl}odnek { a nagysebesseg}u halozatok egyre olcsobbak lesznek (peldaul a 100 megabit/sec atviteli sebesseg}u Ethernet mar sok helyen felvaltja az eddig alkalmazott 10 megabit/sec-es Ethernetet, es egyre tobb helyen alkalmaznak (mikro)processzorok adatvonalainak kozvetlen osszekapcsolasan alapulo halozati adatatviteli technologiat), es ezzel parhuzamosan egyre

olcsobban egyre gyorsabb mikroprocesszorokat fejlesztenek ki a hardverfejleszt}ok laboratoriumaiban. Ennek a fejl}odesnek egy nagyon fontos kovetkezmenye az, hogy mod van nagyteljestmeny}u mikroprocesszorok nagysebesseg}u halozaton keresztul torten}o osszekotesere (ezzel un. osztott rendszerek letrehozasara). De n
ci
o: osztott rendszeren egy olyan tobbprocesszoros rendszert ertunk, amely tobb (akar kozos memoriaval nem rendelkez}o) szamtogep egyuttesen m}ukodik, de a rendszer felhasznaloja megis ugy latja, mintha az egesz rendszer egyetlen nagyteljestmeny}u szamtogep lenne. (Itt a felhasznalo elnevezes alatt nemcsak a klasszikus ertelemben vett felhasznalokat ertem (akik a rendszerre kesztett alkalmazoi programokat hasznaljak), hanem azokat a programozokat is, akik a rendszerre uj programokat fejlesztenek.) Egy osztott rendszer a kovetkez}o alapvet}o jellemz}okkel rendelkezik: Tobb szamtogepb}ol van

osszerakva. A rendszert alkoto szamtogepek kepesek kommunikalni egymassal. A szamtogepek egyuttm}ukodnek valamilyen globalis allapot kezeleseben: egyes rendszerjellemz}ok csak valamilyen globalis invarians segtsegevel rhatok le, es ezen invariansok teljesuleseert a rendszert alkoto elemek egyuttm}ukodese szukseges. Ma mar kialaktottak tobb(tz)ezer mikroprocesszorbol allo szamtogepes rendszereket, de ezek kozul nem mindegyik viselheti magan az osztott rendszer nevet, mivel az alapszoftvere nem biztostja a felhasznalo fele a kell}o mertek}u transzparenciat, vagyis a felhasznalo akarva-akaratlanul is szembetalalkozik olyan { peldaul folyamatok szinkronizaciojaval kapcsolatos { problemakkal, amelyeket az okoz, hogy a rendszer nem egyetlen processzoron van implementalva. Manapsag az osztott rendszerek alkalmazasanak szamos el}onye van, es (a jelenleg m}ukod}o megvalostasok problemai miatt) szamos

hatranya is akad. Az osztott rendszerek alkalmazasa mellett szolnak az alabbi tenyez}ok: 7 Gazdasagossaguk (peldaul a hasonlo teljestmeny}u szuperszamtogepekkel szemben) A veluk elerhet}o tenyleges feldolgozasi kapacitas oriasi merteke (sok mai modern rendszer teljestmenye a bekapcsolt processzorok szamanak kozelt}oleg linearis fuggvenye) Az egesz rendszer megbzhatosaganak, elerhet}osegenek novekedese Ahogyan az osztott rendszerek mellett talaltunk szamos okot arra, hogy alkalmazasukat barkinek ajanlhassuk, ugy talalhatunk tobb olyan tenyez}ot is, ami a jelenlegi osztott-rendszer technologia alkalmazasa ellen szol: A megfelel}o (ill. a kenyelmes szoftverfejleszteshez szukseges) transzparencia hianya A rendszer komponensei kozti kapcsolatot biztosto adatatviteli kozeg (vagyis a halozat ) megbzhatosaga nagyban befolyasolja a rendszer alkalmazhatosagat1 Az egyes komponens-szamtogepek biztonsagat

(ertsd ezalatt a rajtuk letrehozott es kezelt adatok biztonsagat is!) sokkal nehezebb egy osztott rendszerben garantalni, mintha a gepeket egymastol izolalva uzemeltetnenk. Egy osztott rendszer er}oforras-adminisztracioja (itt nem a rendszergazda feladatok ellatasara gondolok, hanem az operacios rendszer altal a futo programoknak nyujtott er}oforrasok adminisztraciojara es az ezzel jaro feladatok elvegzesere) sokkal er}oforrasigenyesebb az egyes komponensek izolalt allapotbeli adminisztraciojanal. Az osztott rendszerek hardware komponenseit kepez}o szamtogepeket szokas multicomputer illetve multiprocesszor csoportokra felbontani aszerint, hogy a processzoraik rendelkeznek-e kozos hasznalatu memoriaval (az el}obbieket nevezik lazan kapcsolt hardver architekturajuaknak, mg az utobbiakat szorosan kapcsoltaknak). A szoftver tekinteteben pedig szokas beszelni lazan kapcsolt rendszerekr}ol illetve szorosan kapcsolt

rendszerekr}ol (az el}obbiekben csak egyegy rendszerkomponens van elosztva a halozaton { ilyen peldaul a halozati fajlrendszer, az NFS, amelyben csak a fajlrendszer elosztott, es a rendszer tobbi komponense egymastol teljesen fuggetlenul m}ukodik, mg a szorosan ::: 1 Az Ethernet halozatokban peldaul nem lehet id} o tekinteteben veges fels}o korlatot adni arra, hogy egy adatcsomagot egy szamtogep mikor tud a droton tovabbtani (annak ellenere, hogy mernokok valoszn}uleg be tudjak bizonytani, hogy annak a valoszn}usege 1 vagy egy ahhoz nagyon kozeli szam, hogy egy adatcsomagot egy szamtogep korlatos id}on belul el tud kuldeni), ezert az Ethernet altalaban nem hasznalhato valos idej}u elosztott rendszerek kesztesere. 8 kapcsolt rendszerekben nagyon keves az egymastol fuggetlenul m}ukod}o komponens). A szorosan kapcsolt szoftverek tervezesekor a legnagyobb nehezseget az okozza, hogy a rendszerben senki sem ismer globalis informaciokat a

rendszer allapotarol egy adott csomoponton mindig csak a teljes rendszer allapotanak egy reszer}ol (esetleg csak par tzezer szamtogepr}ol egy millio szamtogepet tartalmazo halozatban) vannak reszletes informaciok. Ha egy szamtogepes rendszert tobb egymastol fuggetlen komponensb}ol akarunk felepteni, akkor a kovetkez}o tenyez}oket nagyon fontos gyelembe venni a rendszer szerkezetenek illetve viselkedesenek a kialaktasakor: A rendszert alkoto szamtogepek egymastol fuggetlentul is tonkremehetnek, kieshetnek. Mivel az egyes szamtogepek egymastol fuggetlenul is m}ukodhetnek, ezert sok gyelmet kell fordtani olyan rendszerstrukturak kialaktasara, amelyekben nehany szamtogep kiesese nem okozza az egesz rendszer osszeomlasat. U gyelni kell az egyes szamtogepeket osszekot}o kommunikacios reteg (mind a hardver mind pedig a szoftver retegek) megbzhatatlansagabol szarmazo problemakra

is: a kommunikacios reteg valamilyen { itt most nem reszletezett { oknal fogva elerhetetlenne valhat, vagy valamilyen oknal fogva a rabzott uzeneteket elvesztheti, megrongalhatja vagy akar meg is duplazhatja Egy osszetett rendszerben abbol, hogy egy szamtogep nem tudja elerni a masikat, meg nem kovetkezik az, hogy a masik szamtogep hibas: el}ofordulhat az is, hogy a kettejuk kozott kialaktott kommunikacios reteg hibaja akadalyozza a kommunikaciot. A szamtogepeket osszekot}o kommunikacios csatorna nem mindig biztonsagos: bizonyos esetekben szamolni kell uzenetek lehallgatasara illetve modostasara (ami egyebkent torvenytelen, de a lehet}oseget nem szabad kizarni { csak bizonyos sz}uk korben, kulonlegesen jol ellen}orzott rendszerek eseteben). A szamtogepek kozti kommunikacio lenyegesen koltsegesebb: a nagyobb tavolsagu kommunikacio szamara a rendelkezesre allo savszelesseg lenyegesen

kisebb, mint amennyi az egy szamtogepen belul parhuzamosan futo folyamatok szamara rendelkezesre all. ::: Megjegyezzuk, hogy peldaul egy id}oosztasos UNIX rendszeren belul is foglalkozni lehet az els}o harom pontban lertakkal { gy egy ilyen rendszeren is bizonyos mertekben szemleltethet}o ezeknek a problemaknak a lenyege. Peldaul egy ilyen UNIX-szer}u rendszerben a parhuzamosan futo folyamatok kozul egyegy leallhat valamilyen reszleges rendszerhiba vagy mas ok(ok) miatt. 9 1.2 Osztott rendszerek alaptulajdonsagai Az osztott rendszer dencio magaban foglalja az olyan heterogen hardverb}ol es szoftverb}ol allo rendszereket is, amelyeknek a merete es a foldrajzi kiterjedese a nagyon kicsit}ol a nagyon nagyig egyarant terjedhet es a dencio kovetkezmenye az, hogy a valamilyen modon { mondjuk egy halozattal { osszekotott szamtogepek rendszerenek minden komponensen ugyanazokat a szolgaltatasokat kell nyujtani,

fuggetlenul attol, hogy melyik gepen veszik a szolgaltatasokat igenybe (ez az, amiert itt egy rendszerr}ol beszelhetunk, nem pedig csak egymas melle helyezett, adatcserere kepes szamtogepekr}ol). A kovetkez}okben osszefoglaljuk, hogy milyen "globalis" (vagyis minden komponensr}ol azonos modon elerhet}o) modon nyujtott szolgaltatasok szuksegesek egy osztott rendszerben a kenyelmes szoftvertervezes tamogatasahoz. Glob
alis
erv
eny}u nevek az egesz rendszerben, minden egyes komponensen. A gepeknek, a felhasznaloknak, a fajloknak, a szolgaltatasoknak (es minden mas objektumnak) a neve legyen olyan, hogy egyertelm}uen lehessen vele egy-egy rendszerbeli objektumot azonostani (megnevezni) { fuggetlenul attol, hogy a nevet melyik rendszerkomponensen akarjuk hasznalni. Az egyes rendszerfunkcionalit
asok glob
alis el
erhet}os
ege is meghatarozo tenyez}o, es az is elvarhato, hogy az egyes rendszerfunkcionalitasok minden

szamtogepr}ol nagy hatekonysaggal legyenek elerhet}oek. A glob
alis biztons
agoss
ag elerese is nagyon fontos az osztott rendszereknel: mindenhol ugyanaz a felhasznalo-azonostasi mod legyen elerhet}o, a rendszerbeli objektumokhoz valo hozzaferes jogosultsaganak elbralasa minden gepen egyforman kell, hogy tortenjen. Szukseges az egyes szamtogepek kozti adatatvitel biztonsagossaganak biztostasa is: azok, akik a zikai atviteli eszkozhoz hozzafernek, ne tudjanak az atviteli eszkoz lehallgatasaval illetektelenul olyan informaciokhoz jutni, amikhez nincs semmi kozuk valamint nem szabad, hogy barkinek is lehet}osege legyen a szamtogepek kozt aramlo adatok barminem}u modostasara. A rendszer glob
alis menedzsel
ese is egy megoldando feladat az osztott rendszerek tervez}oi szamara: egyetlen szemelynek is legyen meg a lehet}osege arra, hogy az egesz rendszert adminisztralja, karbantartsa. Nyilvan erre nagyon

ritkan van szukseg, mivel egy nagy rendszert altalaban nem egy ember szokott menedzselni, "fenntartani" viszont ennek (vagyis az egyetlen szemely altal valo menedzselhet}oseg) a lehet}oseget ett}ol fuggetlenul biztostani kell. Ilyen modon a rendszer osszes komponensenek (lenyegeben) ugyanazt az interfeszt kell biztostania a menedzsment-szoftverek fele { ez alapjaul szolgalhat egy jol m}ukod}o megoldasnak. 10 A rendszerben az egyes rendszerkomponensek altal nyujtott szolgaltatasok kozotti glob
alis "
atfed
es" (redundancia) biztostasa is szukseges lehet: a rendszerben ugyanazokat a szolgaltatasokat kell biztostani, meg olyan esetben is, amikor nehany gep { mondjuk meghibasodas miatt { kiesik a rendszerb}ol. A rendszer karbantartoinak kell eldonteniuk, hogy milyen mertek}u atfedest tartanak szuksegesnek (es megzethet}onek) a rendszer hibat}ur}o, helyes m}ukodesehez. A kovetkez}okben pedig

osszefoglaljuk az osztott rendszerek nyujtotta tipikus szolgaltatasokat: Nevek rendszerez
ese : a nev-szolgaltatasnak lehet}oseget kell nyujtania egy atfedeses (angol (elterjedtebb) neven replicated) globalis eleres}u es globalis erveny}u (nev, rendszerobjektum) adatbazis letrehozasara. Ezen adatbazisba tetsz}oleges rendszerobjektumot el kell tudni tarolni { peldaul szamtogepneveket, felhasznalok neveit, fajlneveket, ezekb}ol alkotott tetsz}oleges csoportok neveit, es szolgaltatasok neveit. T
avoli elj
ar
ash
v
as biztos
t
asa : a tavoli eljarashvas egy szabvanyosnak tekinthet}o keretet biztost a rendszeren belul szolgaltatas interfeszek denialasara es aktivalasara. A ltalaban lehet}ove teszi a szolgaltatast nyujto szerverek elereset, fuggetlenul attol, hogy azok a helyi vagy egy tavoli gepen futnak, es a tavoli eljarashvasi (al)rendszer vegzi a szolgaltato eleresehez szukseges

transzport-protokoll kivalasztasat (es mindezt az alkalmazas fele teljesen transzparens modon vegzi). Felhaszn
al
ok azonos
t
asa : erre a szolgaltatasra a rendszer felhasznaloinak azonostasa erdekeben van szukseg, es lehet}ove kell tennie az egyes felhasznalok jogainak nyilvantartasat. Az id}o kezel
es
evel kapcsolatos szolg
altat
asok : ezekre a szolgaltatasokra is szukseg van az osztott rendszerekben. A ltalaban szukseg lehet egy pontos, globalisan elerhet}o rendszerorara { igaz ez egy nagyon nehezen megvalosthato alma az osztott rendszerek tervez}oinek. Ahol egy pontos globalis orara van szukseg, ott megoldast jelent a Bureau International de lHeure (BIH) radioado altal kisugarzott 133-as ceziumizotopok segtsegevel mert Nemzetkozi Atomi Id}o (TAI) hasznalata, vagy pedig az ezt a Fold tengelykoruli forgasanak lassulasa miatt "szok}omasodpercekkel" korrigalt UTC (Universal Time Coordinated)

hasznalata. Leteznek termeszetesen mas, a rendszerora-szinkronizaciora hasznalt modszerek is (peldaul az orak egymashoz valo "gyorstasanak" illetve "lasstasanak" modszeret kihasznalo Berkeley Network Time Protocol, de ez sem nyujt tokeletes megoldast a problemara). F
ajlkezel
esi szolg
altat
asok : ezeknek a szolgaltatasoknak lehet}ove kell tenni egy atfedeses, globalis fajlrendszer letrehozasat. Fontos, hogy a 11 nevek rendszerezesen keresztul az egyes szamtogepek altal biztostott lokalis fajlhierarchiat egy globalis fajlhierarchiaba lehessen kapcsolni. Rendszerkarbantart
asi szolg
altat
asok : ezeknek a szolgaltatasoknak lehet}ove kell tenniuk a rendszer m}ukodtetesehez illetve karbantartasahoz szukseges adatok barhonnan torten}o elereset illetve manipulaciojat. 1.3 Interfeszek szerepe az osztott rendszerekben Az egyes rendszerkomponens-interfeszek kulcsfontossaguak a

rendszer kuls}o nyitottsaganak erdekeben: minden szolgaltatast a szolgaltatas interfeszevel kell (es lehet) specikalni, amely interfesz specikacio tekinthet}o egy a szolgaltato (szerver) es a szolgaltatast igenybevev}o (kliens) programok kozti szerz}odesnek is, amely specikalja a szolgaltato altal nyujtott m}uveletek neveit, a parametereit. Ezt a specikaciot altalaban valamilyen interfesz-specikacios nyelven szoktak lerni, es egy-egy interfesznek szamos implementacioja letezhet a rendszerben, de az interfeszek tekinteteben az egesz rendszer egyetlen homogen egyseget alkot. Ennek a homogenitasnak koszonhet}o az, hogy rendszerkent beszelhetunk a szamtogepeinkr}ol, nem pedig csak egy (kommunikaciora kepes) szamtogephalmaznak kell az osztott rendszerunket tekinteni. Ha egy szolgaltatas-komponens lerasara tobb specikaciot is megadnak, akkor nagyon konnyen el}ofordulhatna, hogy az egyes eljarasok

kulonfele specikacioi mas-mas modon viselkednek, ezzel pedig csokkenhet a rendszerr}ol kialakthato homogen kep konzisztenciaja. 1.4 Globalis alaptulajdonsagok megvalostasa Az eddigi kutatasok tobb olyan modellt kialaktottak, illetve alkalmazhato modelleket javasoltak (ld. Tan92]), amelyek a rendszert}ol elvart globalis modon (ld. 12) nyujtott szolgaltatasok konzisztens megvalostasanak alapjaul szolgalhatnak. Ezt fogom roviden osszefoglalni a kovetkez}o pontokban 1.41 Nevek rendszere Az osszes felhasznalo, valamint az osszes kliens alkalmazas az egesz rendszert ugyanazoknak a nevvel ellatott objektumoknak a fa szerkezet}u hierarchiajanak kell, hogy lassa. Egy globalis nev ertelmezesekor a rendszer nevertelmez}oje ennek a fanak a gyokereb}ol kiindulva a nev valamilyen szintaktikai szeparatorral elkulontett komponenseit mint elemi szelektorokat hasznalva vegigmegy a megfelel}o pontig. Minden programnak

lehet}osege kell, hogy legyen arra, hogy megtalalja e globalis nev-hierarchia gyokeret. A nev-rendszer fa szerkezet}u hierarchiaja azert szukseges, mert ez tudja biztostani a rendszer alkalmazkodokepesseget akar millios nagysagrend}u komponensszam eseten is, es a hierarchia egyes szintjein a tobbi szintt}ol fuggetlen elnevezesek hasznalhatoak. 12 Megjegyezzuk, hogy az elnevezesi rendszer modosthato nem-hierarchikus mas elemekkel is, ahol ez szukseges. Minden egyes objektumosztalyhoz letezik megfelel}o szolgaltatas objektumpeldany letrehozasara es megsz}untetesere, valamint az objektumpeldanyok bels}o allapotanak lekerdezesere es modostasara. A nevek hierarchiajat kepez}o fa fels}obb szintjeit a nev-szolgaltatast implementalo nev-szolgaltato biztostja, de a nev-hierarchiaban elhelyezhetunk olyan objektumokat is, amelyek atkapcsolast biztostanak valamely mas szolgaltato fele, peldaul a

fajlszerver fele. Egy ilyen atkapcsolasi pont a kovetkez}o informaciokat kell, hogy megnevezze: A megnevezett objektum kezelesere kepes szerver(ek)et. Valamilyen szabalyt, amely az objektum kezelesere kepes szerverek kozul a megfelel}o szerver kivalasztasat rja el}o. Egy szolgaltatas interfesz azonostot (pl. JBSS File Service Version 11) Egy esetleges parameter-objektumot (peldaul azt, hogy az el}oz}o pontokban megnevezett szerver a m}ukodesehez szukseges informaciokat honnan veheti { peldaul ha egy fajlszerverr}ol van szo, akkor azt, hogy mely zikai diszken van tarolva a kerdeses fajlrendszer). Ahhoz, hogy egy atkapcsolasi ponton keresztul ertelmezzunk egy nevet, ki kell valasztani a megfelel}o szervert, es a megfelel}o nev-ertelmezesi szolgaltatasat kell igenybevenni atadva neki a szukseges parameter-objektumokat (ld. 141) az ertelmezend}o nevvel egyutt, es ra kell bzni a nev maradek reszenek az

ertelmezeset. Az atkapcsolasi pontoknal megadott szervernevek altalaban globalis nevek. Ha a megfelel}o szervert el akarjuk erni, akkor azt valamilyen (zikai) halozati cmen keresztul tehetjuk meg a legkonnyebben, valamilyen halozatfugg}o azonostasi modot felhasznalva. Amikor egy szervert a neve alapjan kikeresunk a nev-hierarchiaban, akkor egy un. szerverlero objektumot kapunk vissza, amely tartalmazza egyreszt a szerver programot futtato szamtogep nevet, masreszt pedig tartalmazza az ezen szamtogep altal ismert kommunikacios protokollok neveit (amiken keresztul a kliensek felvehetik a szerverrel a kapcsolatot). Ezt kovet}oen a szamtogep nevet egy halozati cmme kell konvertalni, es a megfelel}o szamtogeppel a megfelel}o protokollon keresztul fel kell venni a kapcsolatot. Ez az atkapcsolasi pont mechanizmus a nev-hierarchia tobb szintjen is alkalmazhato, nagyon hatekony eszkoz kulonfele elnevezesi

mechanizmusok egyetlen nev-rendszerbe valo osszefogasara. 1.42 Hozzaferesi modell A rendszerfunkcionalitasok globalis elerhet}osege azt jelenti, hogy a programok a rendszerben barhol futhassanak (ahol a futtatashoz szukseges hardver kornyezet 13 adott, pl. a megfelel}o CPU, illetve a szukseges mennyiseg}u zikai memoria2), az eredmeny mindenutt ugyanaz lesz, esetleg a hatekonysag tekinteteben fordulhatnak el}o kulonbsegek. Igy peldaul egy program mindegy, hogy az azt elindto felhasznalo munkaallomasan fut, vagy pedig a szamtokozpont szuperszamtogepen, ez utobbi esetben ugyan valoszn}uleg gyorsabb lesz, de mindket esetben ugyanazokhoz az er}oforrasokhoz (peldaul fajlokhoz), ugyanazokon a neveken keresztul ferhet hozza. E cel elerese erdekeben lehet}ove kell tenni, hogy a program altal hasznalt barmely objektum ne csak a programot futtato szamtogepen lehessen, hanem mas tavoli szamtogepeken is,

azaz akar a a felhasznalo sajat munkaallomasan valamelyik nyilvanos eleres}u munkaallomason a futtato szamtogep sajat helyi halozatan belulr}ol valamelyik varosi meret}u halozaton is. ::: ::: ::: ::: 1.43 Biztonsagossagi modell A biztonsagossagi modell kialaktasa a kovetkez}o strategiai elemekre epul: Igazol
as : az osztott rendszer minden resztvev}ojenek un. igazolasi kotelezettsege van, ami azt jelenti, hogy minden egyes szolgaltatas igenybevetelekor a szolgaltatast nyujto szerver szamara kozolni kell a szolgaltatast igenybevev}o felhasznalo (vagy mas "egyed" { peldaul egy masik szerver) kiletet. Hozz
af
er
esi jog ellen}orz
ese : minden er}oforras minden eleresi ill. modostasi m}uveletere legyen megadhato azon egyedek halmaza, akik az adott er}oforrason az adott m}uveletet vegezhetik tovabba minden er}oforrashoz minden hozzaferesi m}uvelet vegrehajtasa el}ott ellen}orizni kell, hogy

az er}oforrashoz hozzaferni szandekozo kliens alkalmazas hozzaferesi kserlete jogos-e, es ha ez nem jogos, akkor a hozzaferesi m}uvelet elvegzeset meg kell tagadni. Napl
oz
as : minden er}oforrashoz minden hozzaferes ellen}orzotten kell, hogy vegbemenjen, es minden hozzaferesi kserletet fel kell jegyezni, hogy utolag { ha szukseges { a rendszerben lezajlott esemenyek pontosan nyomkovethet}oek legyenek. 2 Erdemes megemlteni, hogy a zikai memoria merete is lehet korlatozo tenyez} o { fuggetlenul attol, hogy mennyi a rendelkezesre allo virtualis memoria: ugyanis azoknal az I/O m}uveleteknel, amelyek kihasznaljak a hardver nyujtotta DMA lehet}osegeket, az I/O memoriateruleteket az I/O befejez}odeseig nem szabad kilapozni a hattertarra a kilapozhatatlan memoriateruletek merete egyuttesenviszont meghaladhatjaa zikai memoria meretet, ami miatt az adott programot az adott gepen nem lehet futtatni. 14 A hozzaferesi jogosultsag

elbralasahoz a szervernek meg kell gy}oz}odnie, hogy tenyleg jogos-e a kerelem, es arrol is, hogy a kerelmet tartalmazo halozati csomagot nem modostotta-e valaki mialatt a halozatban a celja fele vandorolt. Ezt leggyakrabban a csomag tartalmanak titkostasaval szokas megtenni. A kerelmez}o szemelyet pedig ugy szoktak azonostani (vagyis azt eldonteni, hogy a kerelmez}o valoban az-e, akinek kiadja magat), hogy megkerdeznek t}ole valami olyan informaciot, amit csak }o es az igazolast vegz}o alrendszer ismer (peldaul egy jelszot), es ellen}orzik, hogy helyes-e ez az informacio es ha ez helyes, akkor a felhasznalo (vagy mas egyed) azonostasa sikeresnek min}osthet}o, vagyis a kerelmez}o valoban az, akinek "kiadja magat". A rendszer biztonsagossagi alrendszerenek biztostania kell valahogyan "absztrakt egyedek" jogainak kezeleset is { ehhez persze a nevek rendszerebe valamilyen modon letre kell tudni

hozni felhasznalok egy csoportjat azonosto egyedneveket is. Ehhez a nevek rendszeret kezel}o szolgaltatasok ilyen cellal kialaktott lehet}osegeire van szukseg. 1.44 Menedzselesi modell A rendszer menedzselese alatt altalaban azt ertik, hogy egy ember (a rendszergazda) beavatkozhat a rendszer m}ukodesebe a rendszer bels}o allapotanak megvaltoztatasaval. Erre altalaban olyan folyamatok eseten van szukseg, amikor a problema nem algoritmizalhato konnyen, gy a megoldas soran szukseg lehet az emberi tel}okepessegre. Egy nagy rendszer globalis menedzselesenek megoldasara meg nincsenek jol alkalmazhato konzisztens modszerek, viszont a jelenleg hasznalt (es elfogadott) megoldasoknak vannak kozos jellemz}oi, amelyeket ebben a pontban roviden ossze fogok foglalni. Az osztott rendszereket menedzsment szempontbol un. domainekre szoktak osztani: egy osztott rendszer minden egyes komponense hozza van rendelve egyegy domainhez.

Minden egyes domainnek megvan a sajat rendszergazdaja, aki az adott domain m}ukodteteseert felel}os. E rdemes megtekinteni, hogy mi minden kerulhet egy-egy domainbe: Kozos feladaton dolgozo egyenek altal hasznalt eszkozok. Olyan rendszerkomponensek, amelyek m}ukodeset egy-egy bizonyos felhasznaloi csoport feltetelezi. Egy adott helyi halozaton lev}o eszkozok osszessege. A mai osztott rendszerekben minden egyes rendszerkomponenst}ol elvarhato, hogy a menedzselesehez szukseges m}uveleteket a rendszerben szabvanyosnak tekinthet}o tavoli eljarashvasi feluleten keresztul az erdekl}od}ok szamara elerhet}ove tegye ("erdekeltnek" min}osulnek peldaul a rendszergazda munkajat segt}o adminisztracios segedprogramok). 15 1.45 Elerhet}osegi modell Egy szolgaltatas nagymertek}u elerhet}oseget altalaban ugy biztosthatjuk, hogy megnoveljuk az adott szolgaltatast nyujto szerverek szamat. Amennyiben ezek a

szolgaltatok (szerverek) egymastol teljesen fuggetlenul hibasodhatnak meg, es egymastol teljesen fuggetlenul kepesek m}ukodni, akkor a szolgaltatas elerhet}osegenek merteke3 tetsz}olegesen novelhet}o. Ilyen "duplazasra" ketfele elterjedt modszer letezik: az egyik az els}odleges/m
asolat p
eld
any kezelesenek a modszere, a masik pedig az aktiv m
asolatok kezelesenek modszere. Az els}o esetben az egyes m}uveleteket az un els}odleges peldanyt tarolo szerveren kell vegezni, a masolatpeldanyokat inkabb csak az els}odleges peldanyt kezel}o szerver hibajakor hasznaljak mg az utobbi esetben a klienseknek egyszerre tobb szerveren is el kell vegezniuk a megfelel}o m}uveleteket. 1.5 Processzek kommunikacioja osztott rendszerekben Mivel az osztott rendszerek tobb, egymastol fuggetlenul is m}ukodni kepes szamtogepb}ol allnak, ezert valamilyen modon meg kell szervezni az egyes komponensek egymassal valo

megbzhato kommunikaciojat: nem fogadhato el a kommunikacionak egy olyan megoldasa, amelyben az egyik kommunikalo fel meghibasodasa maga utan vonja a kommunikacios partnerenek m}ukodeskeptelenne valasat. A kommunikacios eszkoznek transzparensnek is kell lennie abban az ertelemben, hogy a helyi szamtogepen/processzen beluli kommunikaciora ugyanazt a kommunikacios programozoi interfeszt kell biztostania a kommunikalni kvano folyamatoknak, mint amit a tavoli folyamatok fele biztost. A transzparenciat olyan tekintetben is el kell erni, hogy a kommunikacios utvonalak megbzhatosaga a tavoli gepekkel torten}o kommunikacio eseten is ugyanazokat a megbzhatosagi jellemz}oket viselje magan, mint ami az altalaban megbzhato helyi kommunikaciot jellemzi (ennek az elereset peldaul Tan90] reszletesen elemzi). A rendszer komponensei kozti kommunikacio szigoru szabalyok szerint zajlik. Szabalyok szuksegesek a

kommunikaciora hasznalt periferiak hardver jellemz}oire, az atviteli hibaval kuldott/kapott csomagok felismeresere, a hosszu uzenetb}ol kisebb csomagok kepzesere, . Nyilvanvalo, hogy sok szabaly szukseges a teljes kozlesfolyamat lerasara a szabalyok nagy szama miatt az osszes szabaly attekintese sem lenne egyszer}u feladat, ezert az OSI kidolgozott egy keretrendszert a kommunikacios protokollok tervezesere es implementalasara, amely a kommunikacios szoftvert egymasra epul}o retegekkent modellezi, a retegeken felfele haladva egyre tobb kommunikacios szolgaltatast nyujtva a kommunikalni szandekozoknak. Ez a kere::: Egy szolgaltatas elerhet}osegenek a merteket tekinthetjuk annak a valoszn}usegnek, mely megadja, hogy mennyi a valoszn}usege annak, hogy egy adott id}opillanatban legalabb egy { az adott szolgaltatast nyujto { szerver m}ukodik. 3 16 trendszer (reszletes ismerteteset ld. Tan90]-ben) az egyes retegekben

a kommunikaciot (kozlesfolyamatot) mind kulonboz}o szempontokbol targyalja, es a kommunikacionak az OSI4 -fele referenciamodelljenek nevezik. 1.51 Az OSI referenciamodell retegei Az egyes biteknek az egyik gepr}ol a masikra valo atvitelevel foglalkozik a kommunikacio zikai retege. Ez rogzti az atvitelhez hasznalt kabel jellemz}oit, a 0 ill. 1 bitek reprezentaciojat (peldaul melyiket hany volt feszultseggel lehet reprezentalni), tovabba ez rogzti az uzenet bitjeinek az adasi sebesseget, es egyeb jellemz}oit. A zikai reteg specikacioja nem tartalmaz olyan mechanizmusokat, ami az atviteli hibak felismereset segtene. Ez a feladata a zikai retegre epul}o adatkapcsolati retegnek: az atviend}o biteket un. keretekre (csomagokra) osztjak, es e kereteket kiegesztik a keret elejet illetve a veget jelz}o bitmintaval, valamint specikalnak valamilyen ellen}orz}oosszeg szamtasi szabalyt, es a keretet a tartalma

alapjan kiszamolt ellen}orz}o osszeggel kiegesztve tovabbtjak a cmzetthez, aki az ellen}orz}o osszeg alapjan eldontheti, hogy az uzenet tartalma az atvitel soran megserult-e. Az eddig bemutatott ket reteg ket egymassal kozvetlen osszekottetesben lev}o szamtogep kommunikaciojanak megszervezeset vegezte. Mivel egy nagy halozatban nem megoldhato, hogy mindenki mindenkivel kozvetlen kapcsolatban legyen, ezert meg kell oldani a kozvetlen osszekottetessel nem rendelkez}o szamtogepek kommunikaciojat is: ez a feladata a kommunikacio halozati retegenek. Kell egy csomagutvonal-kijelol}o mechanizmust biztostani, amely egy tetsz}oleges { a halozatba bekapcsolt { szamtogepr}ol egy tetsz}oleges { szinten a halozatba kapcsolt { szamtogepre el tudja juttatni a csomagokat. A halozati reteg meg nem hasznalhato mindenhol kenyelmesen a kommunikacio megvalostasara. Ennek oka egyreszt az, hogy a halozati reteg

a szamtogepen belul altalaban csak egy cmezhet}o kommunikacios vegpontot biztost a masik ok pedig a halozati reteg megbzhatatlansaga: a halozatokat osszekot}o varosi kommunikacios vonalak gyakran vesztenek ill. duplaznak csomagokat. Mivel az alkalmazasok keszt}oi nem szeretnek a kommunikacios hibakkal foglalkozni: szamukra egy megbzhato kommunikacios reteg biztostasa szukseges, mely nem veszt adatokat, ved az atvitt adatok modostasa ellen, illetve ved minden mas, a kommunikacio soran el}ofordulo atviteli hibatol. Ezeket a feladatokat kell megoldania a kommunikacio transzport retegenek. A felismert kommunikacios hibakat szukseg eseteni ujraadassal ill. id}otullepesi esemenyek bevezetesevel tudjak orvosolni, mg a tobb cmzehet}o kommunikacios vegpontot a transzportkapcsolatoknak az egy halozati kapcsolatra valo 4 OSI mozaikszo az Open Systems Interconnection kezd} obetuib}ol van osszeteve {

ez a szabvany hivatalos neve. 17 multiplexalasaval illetve demultiplexalasaval oldjak meg (a transzport reteg ilyenkor a halozati retegt}ol kapott csomagokat a bennuk lev}o valamilyen transzportvegpont azonosto alapjan szetvalogatja (demultiplexalja), es atadja a megfelel}o transzportvegpontnak { ill. adatkuldes eseten pont a fordtott folyamat jatszodik le) A transzport reteg felett elhelyezked}o viszonyreteg a tobb resztvev}os kommunikacio osszehangolasara szolgalo eszkozoket biztost (kepes nyilvantartani, hogy egy adott id}opillanatban mely resztvev}ok kommunikalhatnak, es lehet}ove teszi ellen}orzesi pontoknak az uzenetfolyamba valo beiktatasat abbol a celbol, hogy egy hosszabb atvitel soran az egyik kommunikalo fel meghibasodasa eseten ne kelljen az osszes addig atvitt adatot ujra atvinnie, hanem eleg mondjuk a legutolso ellen}orzesi pont ota atkuldott adatokat ujraadni). E folott helyezkedik el a

reprezentacios reteg, amely az elkuldott adatok reprezentaciojaval { esetleg titkostasaval illetve tomortesevel foglalkozik. Az OSI modell legfels}o retege pedig az alkalmazasi reteg, amely kulonfele kozhasznu protokollokat tartalmaz: peldaul levelezesi, fajlatviteli, tavoli terminal es mas feladatok ellatasara. Megjegyezzuk, hogy az egyes protokollretegek jelent}osen lasstjak az informaciofeldolgozast, ezert a legtobb { helyi halozat felett implementalt { kommunikacios szoftver nem retegzett modon van implementalva, vagy az egyes retegeknek csak nagyon kis reszet hasznalja. Az OSI szabvany csak azzal foglalkozik, hogy az egyes biteket hogyan juttathatjuk el az egyik gepr}ol a masikra (illetve a fels}obb retegekben az egyes bitek jelentesevel is foglalkozik), de nem mond semmit arrol, hogy hogyan erdemes felepteni egy elosztott rendszert. 1.52 Osztott rendszerek kommunikacios protokolljai Lathattuk, hogy az

osztott rendszerek kommunikaciojanak alapot ado szamtogepes halozatrol altalaban nem tetelezhetjuk fel, hogy megbzhato, viszont amennyiben { ha nem is minden, de legalabb nehany uzenet eljut a feladotol a cmzettig, akkor ujraadassal ill. nyugtakkal kialakthato egy kommunikacios reteg Amennyiben egy kliens alkalmazas egy olyan halozaton kuld uzenetet egy tavoli szervernek, amely csomagokat veszthet, es tobb ujraadas utan sem kap valaszt a szervert}ol, akkor nem tudhatja azt, hogy mi a kommunikacio { esetleg latszolagos { sikertelensegenek az oka (a halozat sorozatos "veletlen" csomagvesztese vagy esetleg a szerver folyamat meghibasodasa). Egy kliens alkalmazas nem tudja megkulonboztetni a szerver meghibasodasat a halozati kapcsolatot tarto reteg meghibasodasatol, ami onmagaban nem lenne olyan nagy problema, de gy azt sem tudja meg, hogy a szerver egyaltalan megkapta-e az uzenetet vagy sem, es

ha megkapta, akkor elkezdte-e mar az abban kertek 18 vegrehajtasat vagy sem (es ez az igazan nagy problema). Latni kell azonban azt is, hogy az sem sokkal jobb allapot, ha a halozatrol feltetelezhetjuk azt, hogy nem hibasodhat meg, ugyanis egy, az el}obbihez hasonlo helyzetben ilyenkor sem tudnank, hogy a szerver folyamat elkezdte-e mar a keresunkre a szukseges akciokat vegrehajtani vagy sem, vagy esetleg mar a valaszuzenetet is osszealltotta a keresunkre a helyes befejez}odest visszajelezve, de a valasz elkuldese el}ott meghalt. Persze ezt a bizonytalansagot bizonyos esetekben konnyebb lehet elviselni, mint azt, amikor ennel is kevesebbet tudunk. Ezen feltetelekkel nagyon nehez egy kerest ugy eljuttatni a szerverhez, hogy az pontosan egyszer kapja meg es hajtsa vegre a szukseges valaszlepeseket. Sok esetben elegend}o az is, amit a legfeljebb egyszer vagy a legalabb egyszer szemantika nyujthat. A legalabb egyszer szemantika

eseten a kommunikacios rendszer halozati hibak kizarasa eseten minden keres pontosan egyszer jut el a szerverhez, halozati hibak eseten persze egy keres akar tobbszor is eljuthat a szerverhez (ami idempotens m}uveletek alkalmazasakor nem problema, de nagyon sok m}uvelet nem idempotens, vagyis egymas utan tobbszor vegrehajtva nem mindig ugyanazzal az eredmennyel hajtodnak vegre). A legfeljebb egyszer szemantika eseten a kommunikacios protokoll eszreveheti, hogy valami halozati hiba lephetett fel, es ez alapjan korrigalo lepeseket lehet a rendszerbe epteni. Az osztott rendszerek adatatviteli protokolljai { a kulonfele kommunikacios igenyeknek megfelel}oen { sokfelek lehetnek. Az eddigi kutatasok alapjan (ld. Tan92]-ben) alapvet}o kovetelmenynek tekinthet}oek az alabbi iranyvonalak kovetese: A protokoll a legfeljebb egyszer uzenetatadasi szemantikaval rendelkezzen. A protokoll adjon pozitv visszajelzest, amennyiben az

uzenetet el tudta kuldeni a cmzettjehez. A protokoll adjon negatv visszajelzest, amennyiben az uzenetet nem tudta elkuldeni a cmzettjehez. A protokoll adjon lehet}osegeket oriasi mennyiseg}u adat hatekony (folyamatos, gyors) atvitelere is. A "legfeljebb egyszer" szemantika elerhet}o ugy, hogy a szervernek van egy bels}o allapota, amely alapjan el tudja donteni, hogy egy adott kerest mar feldolgozott-e vagy sem. Tovabba ahhoz, hogy szukseg eseten negatv visszajelzest is tudjunk a kuld}onek visszaadni (olyan esetekben is, amikor egy keresre a valasz csak viszonylag hosszu id}o mulva erkezne meg), beiktathatunk a protokollba "fustjel" uzeneteket, amik a kliens-szerver kapcsolat tesztelesere szolgal (a szerver ezzel visszajelezheti, hogy elkezdett dolgozni a keresunkre). 19 1.53 Osztott rendszerek szerkezete Habar a korabban mar ismertetett kliens-szerver modell egy megfelel}o modell osztott rendszerek

szerkezetenek kialaktasara, van vele kapcsolatban egy eleg nagy problema: az, hogy az I/O jelleg}u adatkuld}o es adatfogado m}uveletekre epul, es mivel az I/O a centralizalt rendszerek tervezesenel sem egy kozponti fogalom, ezert osztott alkalmazasok kesztesekor sem e kore erdemes a rendszert felepteni (legalabbis akkor semmikeppen nem, ha a transzparenciat meg akarjuk tartani, vagyis hogy egy elosztott alkalmazast ugyanolyan szoftvertechnologiai eszkozokkel tervezhessunk meg, mint amiket a hagyomanyos centralizalt alkalmazasok fejlesztesere megismertunk). A tovabbiakban megismerunk ket ujabb modellt, amely hasznalhato osztott rendszerek szerkezetenek a kialaktasakor: az egyik modell a tavoli eljarashvas, a masik pedig a csoportkommunikacio. 1.54 A tavoli eljarashvas A tavoli eljarashvas alapotlete az, hogy lehet}ove teszik masik szamtogepen lev}o eljarasok meghvasat (vegrehajtasat). Ha az

egyik szamtogepen egy A folyamat meg akar hvni egy masik (mondjuk B) szamtogepen egy eljarast, akkor a hvo program futasa felfuggeszt}odik, es elindul a meghvott eljaras a B szamtogepen, majd miutan a B szamtogepen a hvott eljaras befejez}odik, a hvo (A) folyamat futasa folytatodik. Az eljaras parametereit az operacios rendszer uzenetatadasi mechanizmusaval juttathatjuk el a hvott eljarashoz illetve juttathatjuk vissza a hvo folyamathoz. Persze a programozo fele semmi nem latszik az uzenetatadasbol illetve a vegrehajtott I/O m}uveletekb}ol. A programozo csak annyit tesz, hogy meghv egy eljarast { mint azt a centralizalt alkalmazasok kesztesekor tette. A tavoli eljarashvas kenyelmes hasznalatahoz szukseges transzparenciat (vagyis azt, hogy az eljaras hvasakor a programozonak ne kelljen tor}odnie azzal, hogy a hvott eljaras valojaban egy masik szamtogepen fut) el lehet erni, de

mint azt latni fogjuk, a tavoli eljarashvassal kapcsolatban tobb gyakorlati problema is felmerulhet, amit nagyon nehez { ha nem lehetetlen { kivedeni. A tavoli eljarashvast altalaban ugy implementaljak, hogy az egyes tavoli eljarasoknak letrehozzak a helyi reprezentansait (ezek helyi kozonseges eljarasok), amiket a programbol a helyi eljarashvas szabalyai szerint hvhatunk. Ezt nevezik a kliens csonknak. A kliens csonk a kapott parameterekb}ol osszeallt egy uzenetet, amit az operacios rendszer uzenetatadasi mechanizmusaval el akar juttatni a szerver folyamatnak: tehat az osszealltott uzenetet atadja a helyi operacios rendszernek { es elkezd egy valaszuzenetre varni. A helyi operacios rendszer elkuldi a szerver programot futtato szamtogep operacios rendszerehez az uzenetet. Ott az operacios rendszer atadja az uzenetet a szerver programnak (a szerver programnak ezt a reszet nevezik gyakran szerver

csonknak), amely kipakolja a parametereket az uzenetb}ol, es ezekkel mind ar20 gumentumokkal meghvja a szerver feladatokat ellato eljarast (a tavoli gepen az ott m}ukod}o helyi eljarashvasi mechanizmusokkal). A szerver eljaras elvegzi a feladatat, es az eredmenyeket visszaadja az }ot hvo szerver csonk eljarasnak. A szerver csonk eljaras a visszakapott eredmenyeket egy uzenetbe becsomagolva atadja az operacios rendszernek, es utastja azt, hogy az eredmenyeket tartalmazo uzeneteket kuldje vissza a klienst futtato szamtogepre. A klienst futtato szamtogep operacios rendszere miutan megkapja az uzenetet (a szerver valaszat), azt atadja a valaszra varakozo kliens csonk eljarasnak, ami az uzenetb}ol kicsomagolja az eredmenyeket, es visszaadja }oket a hvonak. Lathattuk, hogy a kliens illetve a szerver csonk feladata a parameterek uzenetekbe becsomagolasa valamint az uzenetek tartalmanak a kicsomagolasa. A

csonkokba kell beepteni az egyes szamtogepek reprezentacios kulonbsegeinek az athidalasat megoldo mechanizmusokat is (hacsak nem a halozatban csupa azonos architekturaju szamtogep van, amelyek azonos bels}o adatabrazolassal dolgoznak, mivel ilyenkor az egyes szamtogepek bels}o adatabrazolasi formatumaik kozott nem kell konverziokat vegezni). A legtobb tavoli eljarashvasi konyvtar ezt a problemat ugy oldja meg, hogy specikalnak egy halozati adatabrazolasi formatumot, es az adatok halozatra kuldese el}ott az adatokat erre a kozos formatumra alaktjak (minden szamtogepet csak a sajat bels}o adatabrazolasi modjarol a halozati adatabrazolasi formara alakto eljarasokkal kell felszerelni), valamint meg kell rni a fordtott iranyu konverziot elvegz}o eljarasokat is. Megjegyezzuk, hogy a kliens illetve a szerver csonkok az eljarasok specikacioja alapjan a legtobb rendszerben

automatikusan generaltathatok (egy megfelel}o { direkt erre a celra elkesztett fordtoprogrammal, ami az eljarasok specikacioja, valamint a parameterek kuls}o reprezentacioja alapjan egyertelm}uen meghatarozott formatumu uzenetek osszealltasat es ertelmezeset ("kicsomagolasat") vegz}o eljarasok automatikus generalasat teszi lehet}ove). Egy masik problema a pointerek illetve memoriacmek parameterkent valo atadasanak a kovetkezmenye: ezeknek a parametereknek csak a kliens alkalmazason belul van jelentesuk (ugyanis a masik szamtogepen futo szerver program altalaban egy sajat cmtartomannyal rendelkezik, amely teljesen diszjunkt a kliens alkalmazas cmtartomanyaval). E problemara ket megoldas lehetseges: az egyik megoldas azon alapszik, hogy a kliens csonk az uzenetbe bepakolhatja azt a memoriareszt, amelyre a parametereben megadott pointer mutat, illetve a szervert}ol visszakapott valaszban

visszakapja az adott memoriaterulet modostott tartalmat, es a kliens alkalmazasban a megfelel}o helyre visszamasolhatja azt. A masik { kevesbe hatekony, de "transzparensebb" { megoldas a pointer-dereferenciaert felel}os programresz olyan modostasan alapszik, hogy minden egyes pointer-dereferencia eseten a hivatkozott memoriacmet visszakuldjuk a kliensnek, arra kerve, hogy kuldje vissza a szervernek a megfelel}o memoriatartalmat. Nyilvan egy olyan fajlszervernel, amely byteonkent tolti fel az adatbeolvasas soran hasznalt, pointerrel azonostott tombot, minden egyes byte beolvasasa egy-egy uzenetkuldessel fog jarni, ami adott esetben a halozatot 21 nagyon leterhelheti, viszont a transzparencia szempontjabol a megoldasunk jobb, mint az el}obb emltett masolgato modszernel (a kulonbseget leginkabb tobbszalas alkalmazasok eseten erzekelhetjuk). Mar lattuk az osztott rendszerek kommunikacios

protokolljairol szolo reszben (ld. 152) azt, hogy az osztott rendszerek kommunikacios protokolljainak a tervez}oinek milyen alapvet}o nehezsegekkel kell szembenezniuk Itt roveiden attekintjuk azokat a problemakat, amelyeket a tavoli eljarashvas megvalostasanal gyelembe kell venni, illetve ezek a tavoli eljarashvasi protokollok azon jellemz}oi, amelyeket egy osztott rendszer tervezesekor illetve implementalasakor gyelembe kell venni. A kliens alkalmazas nem talal megfelel}o szervert egy adott feladat elvegzesere. Ennek termeszetesen tobb oka is lehet { peldaul az, hogy a megfelel}o szervert futtato szamtogep ki van kapcsolva. Ennek kezelesere altalaban van lehet}oseg a hasznalt programozasi nyelv altal biztostott kivetelkezelesi eszkozokkel (vagy a signal-kezelessel ott, ahol nincs lehet}oseg kivetelkezelesre). Termeszetesen ilyen eszkozok hasznalata a transzparencia elveszteset vonja maga utan, mivel a

programozonak tudnia kell { a megfelel}o kivetelkezel}ok megrasahoz {, hogy mely eljarashvas fog helyben vegrehajtodni, es mely eljarashvas hv tavoli eljarast. A kliensnek a szerver fele elkuldott keres uzenete elveszik. Ez talan a legegyszer}ubb eset: ilyenkor a keres ujraadasaval az uzenetet eljuttathatjuk a szerverhez (illetve ha az uzenet tobbszori probalkozas utan sem tud eljutni a szerverhez, akkor meg kell vizsgalni, hogy nem az el}obbi pontban emltett esettel van-e dolgunk (vagyis a kliens nem tudja megtalalni a szamara szukseges szervert)). A szerver valaszuzenete is elveszhet. Ilyenkor a kliens a keres ujraadasaval a szervert kerheti a m}uvelet megismetlesere. Amennyiben a szerver eszreveszi, hogy a keres egyszer mar vegre lett hajtva, akkor a valaszuzenetet ujrakuldheti a keres ujboli vegrehajtasa nelkul. Azt, hogy egy uzenet vegre lett-e egyszer hajtva, eldonthet}o peldaul a kliens kernelje

altal az uzenethez "ragasztott" egyedi { monoton novekv}o { sorozatszam segtsegevel is (a szervernek csak azt kell tarolnia, hogy mely klienst}ol mely sorszamu uzenetet fogadta utoljara). Egy masik megoldas lehet ebben az esetben az idempotens m}uveletek kialaktasa. Bar ez nem jelent tokeletes megoldast, hiszen egyes m}uveletek (peldaul egy bankszamla megterhelese) eredend}oen nem idempotensek. El}ofordulhat az is, hogy a szervert futtato szamtogep tonkremegy, miutan megkapja a kliens kereset. Itt az igazan nagy problema az, hogy nem tudjuk, hogy a kereshez tartozo m}uveletet a szerver mar vegrehajtotta-e vagy sem. Ezzel kapcsolatban a korabban (ld 22 1.52) mar bemutatott legalabb egyszer, legfeljebb egyszer illetve pontosan egyszer torten}o keres-vegrehajtasi szemantika rogztese jelenthet tampontot a tavoli eljarashvasra epul}o osztott alkalmazasok tervez}oinek. Problemat jelenthet a klienst futtato

szamtogep meghibasodasa is. Ilyenkor a szerver hiaba szamol barmit is (a kerdeses kliens reszere), mivel mar nincs, akit "erdekelhetne" az eredmeny (s}ot az is problema lehet, hogy a klienst futtato szamtogep ujraindtasa utan uj kliensek/alkalmazasok indulnak, es ezek az uj alkalmazasok kapjak vissza a szervert}ol a korabban ugyanazon a cmen futo (de mar meghalt) kliens alkalmazas szamara visszakuldott valaszuzeneteket). Az osztott rendszerek tervez}oi erre a problemara az alabbi alternativak kozul valaszthatnak (ld. Nelson81]-ben) : { A kliens csonk megfelel}o naplofajlt vezethet, es a naplofajlokat a kovetkez}o ujraindtas alkalmaval elemezve ertesthetjuk a szervert arrol, hogy mely munkakat vegzi "feleslegesen". { Az is megoldast jelenthet, hogy a szamtogepek nyilvantartjak azt, hogy hanyszor bootoltak be a halozatba kapcsolt gepeket. Ahanyszor egy gep bebootol, uzenetet kuld

az osszes tobb szamtogepnek, hogy bebootolt, es utastja a szervereket futtato szamtogepeket az el}oz}o bootolas utan rajta elindtott kliensek altal elindtott RPC-k kiszolgaloinak a lealltasara. 1.55 Csoportkommunikacio A tavoli eljarashvasi rendszerek altalaban csak ket kommunikalo folyamat kommunikaciojat kepesek megszervezni. Ez olyankor elegend}o, amikor a kliens alkalmazasok egy-egy szervert kivalasztanak a feladatuk elvegzesehez, es csak azzal a szerverrel tartjak a kapcsolatot (a tavoli eljarashvasi mechanizmuson keresztul). Gyakran szukseg lehet kett}onel tobb partner kommunikaciojanak a megszervezesere is: egyreszt amikor egy adott szolgaltatast tobb szerver nyujt, akkor ezeknek a szervereknek a koordinalasa ilyen eszkozoket igenyel, masreszt pedig gyakran terveznek olyan osztott rendszereket, ahol a kliens nem egy konkret szerver folyamattal tartja a kapcsolatot, hanem egy

"szolgaltatassal" (ilyenkor rejtve marad el}ole, hogy egy adott szolgaltatast esetleg tobb szerver nyujt, es nincs is lehet}osege egy adott szerver folyamat megcmzesere, csak a szerverek egyutteset mint az adott szolgaltatast vegz}o folyamatok osszesseget kepes megcmzeni { a szerverekre hagyva ezzel a szolgaltatasuk iranti kerelmek bels}o elosztasanak a feladatat). A csoport fogalmat ugy denialhatjuk, mint folyamatok olyan halmaza, amelyben a folyamatok egyuttm}ukodnek valamilyen cellal. Ezt segt}oen a csoport mint cmezhet}o egyseg szamara kuldott uzenetek a csoport osszes tagjanak kezbestve lesznek. A csoportok a legtobb rendszerben dinamikus egysegek: 23 barmikor letrehozhatunk uj csoportokat, es barmikor megsz}untethetunk mar meglev}o csoportokat. Egy folyamat egyidej}uleg akar tobb csoportnak is tagja lehet. A csoportalkotas celja altalaban tehat az, hogy folyamatok csoportjat egyetlen absztrakcios

eszkozkent lehessen kezelni: egy uzenet elkuldhet}o egy csoportnak anelkul, hogy az uzenet kuld}ojenek tudomasa lenne arrol, hogy kik a csoport tagjai (gy a csoporttagok valtozasat sem kell minden folyamatnak maganak adminisztralnia es kovetnie). A csoportokat gyakran nevezik nyitottnak illetve zartnak aszerint, hogy barki kuldhet uzenetet a csoportnak fuggetlenul attol, hogy csoporttag-e vagy sem (ez a nyitott csoport) vagy pedig a csoportnak csak a csoporttagok kuldhetnek uzenetet (zart csoportok eseten). Ha a csoportokat olyan cellal hozzuk letre, hogy a csoporttagok valamilyen munkat szinkronizaljanak maguk kozott, akkor gyakran a zart csoport absztrakcio a megfelel}o ha pedig a csoportokat olyan cellal hozzuk letre, hogy atfedeses szolgaltatokat kesztsunk a szolgaltatas globalis elerhet}osegenek javtasa erdekeben, akkor a nyitott csoportok absztrakcioja felel meg jobban a megoldasra (ui. nemcsak a szolgaltato

folyamatok vehetik igenybe szolgaltatasukat, hanem a rendszer osszes tobbi folyamata is). A csoportnak kuldott uzenetek kezbestesere tobb alternatva is van: Az is megoldhato, hogy az uzenetet a halozat uzenetszorasi mechanizmusaval juttatjuk el a cmzettekhez (a cmzettek { azaz a csoporttagok { listajat altalaban a rendszermag vagy valamilyen erre a celra kialaktott csoporttagsagi szerver tarolhatja). Amennyiben a halozat nem rendelkezik uzenetszorasi mechanizmusokkal, akkor a csoport osszes tagjanak ket pont kozotti uzenetatadassal kell az uzenetet eljuttatni. A csoport megcmzese tortenhet egy (numerikus vagy nemnumerikus) csoportazonosto hasznalataval, vagy elterjedt a predikatumcmzes is, ahol az uzenetben a cmzeshez egy predikatumot (logikai alltast) lehet elhelyezni, amely predikatum tartalmazhat a fogado szamtogepre vonatkozo alltasokat is (pl. a fogado szamtogep cmet, .), es az uzenet

fogadasa utan minden egyes folyamat kiertekeli az uzenetben kapott predikatumot, es ha a kiertekeles vegeredmenye a logikai igaz ertek, akkor az uzenetet neki (is) szantak, egyebkent pedig eldob(hat)ja. A csoportkommunikacio uzenetkuldesi m}uveletenek egy nagyon fontos jellemz}oje kell, hogy legyen az atomicitas (vagyis egy uzenetet vagy meg kell, hogy kapja az osszes csoporttag, vagy senkinek sem szabad megkapnia { es ilyen esetben az uzenetkuldesi m}uvelet a kezbestes meghiusulasanak az okat kozli a kuld}ovel). Erre egy gyakran hasznalt algoritmus a kovetkez}o: az uzenet kuld}oje elkuldi az uzenetet a csoport osszes tagjanak (a szukseges ujraadasi orak bealltasaval, hogy amennyiben valamelyik cmzett nem nyugtazza az uzenetet, akkor ujraadja). Amikor egy folyamat egy uzenetet fogad, akkor megnezi, hogy 24 megkapta-e mar valamikor az uzenetet. Ha igen, akkor egyszer}uen eldobja ha pedig meg nem latta azt az

uzenetet, akkor }o is "elkuldi" az osszes csoporttagnak. A csoportkommunikacioval szemben tamasztott masik fontos kovetelmeny az uzenetek kezbestesenek a sorrendtartasa. Err}ol rok a kovetkez}o pontban 1.56 Csoportkommunikacio uzenetsorrendtartasa Az osztott rendszer csoportkommunikaciojanak transzparenciaja mulik azon is, hogy az uzenetek elkuldesi es kezbestesi sorrendje egyforma-e minden folyamatnal. Ha ez nem egyforma, akkor a programozonak esetleg ilyen jelleg}u problemakkal is kell foglalkoznia az algoritmusanak kodolasa kozben, ami miatt sokat veszt a rendszer a transzparenciajabol. Tekintsuk erre a problemara a kovetkez}o peldat: tegyuk fel, hogy van ket folyamatunk, mindketten tagjai ugyanannak a csoportnak. Tovabba tegyuk fel, hogy az }oket osszekot}o halozati reteg nem megbzhato, vagyis csomagvesztes el}ofordulhat. Tegyuk fel, hogy egyszerre ket kulonboz}o folyamat is kuld egy-egy uzenetet

e csoportnak (annak a csoportnak, amelynek tagja e ket folyamat is). El}ofordulhat, hogy az egyik uzenet eljut az egyik csoporttaghoz, a masiknal elveszik a masik uzenet a masik csoporttaghoz jut el, az el}obbi csoporttagnal pedig elveszik. Miutan az elveszett uzenet ujra lesz adva, az a szorny}u eset fog el}ofordulni, hogy igaz ugyan, hogy mindket uzenet eljutott a csoporttagokhoz, de nem ugyanabban a sorrendben: ha az uzenetek (tartalmilag) egymastol nem fuggetlenek, akkor el}ofordulhat, hogy az egyes csoporttagok bels}o allapota kulonboz}okeppen fog alakulni, amire a programozo nem lehet minden esetben felkeszulve (ez nagyon konnyen okozhat programhibakat!). E problema megoldasara tobb modszert is kidolgoztak { eredetileg az ISIS nev}u, osztott rendszerek kesztesere hasznalt toolkitben, amely modszerek az altaluk garantalt kezbestesi sorrend szemantikaban kulonboznek. Most ezen uzenetkuldesi szemantikak rovid lerasa

kovetkezik { reszletesebben err}ol lasd Birman87]-t. Az ISIS rendszernek igaz ugyan, hogy nem POSIX-konform a felulete (gy onmagaban a dolgozat temajatol egy kicsit messzebb all), viszont az altala feltetelezett operacios rendszer interfesz POSIX-konform,gy barmely mas POSIX-konform operacios rendszerre ratelepthet}o (az ISIS ujabb valtozatait mar a Mach 3.0 mikrokernelre is atvittek, amivel bebizonythattak, hogy az ISIS kommunikacios rendszere nemcsak POSIX alapokon kepes m}ukodni { s}ot az alacsonyabb szint}u eszkozokkel torten}o implementacio jelent}osen hatekonyabb, mint az eredeti { POSIX-re epul}o { ISIS toolkit a komponensek5 kozti draga 5 A POSIX szabvanyra ep ul}o ISIS implementacio tobb komponensb}ol all, mint az azonos feladatokat ellato nem POSIX-ra { hanem peldaul a Mach 3.0-ra { epul}o valtozat Ennek legf}obb oka az, hogy a POSIX szegenyes eszkozoket biztost a rendszerobjektumokhoz valo hozzaferesek engedelyezesenek

kezelesere (az rwx-biteket), mg a modern mikrokernel alapu operacios rendszerek ennel nomabb hozzaferes-ellen}orzesi mechanizmusok implementalasat is lehet}ove teszik, amit POSIX alapokon nehez megvalostani. Egy masik ok pedig az, hogy nehany modern mikrokernel alapu rendszereken lehet}oseget adnak operacios rendszer sz- 25 kontextuscserek idejenek megsporolasa miatt). Az ISIS rendszer a segtsegevel feleptett osztott rendszerek tervez}oinek a sokszn}u csoportkommunikacios lehet}osegeivel nyujt nagy segtseget. A legalapvet}obb absztrakcioja a szinkronitas: egy szinkron rendszerben az egyes esemenyek (peldaul akar egy uzenetszorasi m}uvelet) szigoruan egymas utan kovetkeznek be. Az ISIS szemleleteben egy id}opillanatban csak egy esemeny kovetkezhet be az egesz rendszerben, es egy esemeny "pontszer}u" { abban az ertelemben, hogy barmely esemeny gyakorlatilag nulla id}o alatt befejez}odik (vagyis a rendszer m}ukodese diszkret

esemenyek sorozatakent modellezhet}o, ahol ket esemeny id}oben sosem fedheti at egymast { ha egy folyamat valamilyen csoportkommunikacios eszkozzel uzenetet kuld masik ket folyamatnak, akkor a cmzettek kozvetlenul az uzenetkuldes pillanataban megkapjak az uzenetet ha pedig egy masik folyamat szinten az el}obbi ket folyamatnak kuld egy-egy uzenetet, akkor a cmzettek a ket uzenetet ugyanolyan sorrendben kapjak meg, amilyen (egymashoz kepesti id}obeli) sorrendben azok el lettek kuldve). A szinkronitas biztostasa gyakorlatilag lehetetlen (gondoljunk egyreszt arra, hogy az informacio terjedesehez id}ore van szukseg, es a szamtogepek halozataban nem lehet globalis orakat kell}o pontossaggal biztostani), ezert denialtak e fogalom egy gyengtett valtozatat: a gyengtett szinkronitas fogalmat, ami viszont mar implementalhato, es a szinkronitashoz hasonloan megkonnyti az osztott rendszerek tervez}oinek az osztott

rendszerek specikalasat a kovetkez}o tulajdonsagai (ld. Birman89]) miatt: Id}obeli fels}o korlat adhato arra, amg egy uzenet el lesz juttatva a cmzettjehez, es a cmzett fogadja azt. Ismerjuk egy-egy folyamat egy-egy m}uveletenek a vegrehajtasahoz szukseges also es fels}o id}obeli korlatokat. Letezik egy konstans, mely fels}o korlatnak tekinthet}o az osszes folyamat orajanak a valos id}ot}ol valo elteresere. Ugyanitt (Birman89]-ben) talalhatunk peldakat a gyengtett szinkronitas kihasznalasara osztott rendszerekben tipikus feladatok megoldasa soran. A cikkben kozolt problemakra a cikkben megadott megoldasok a (gyengtett) szinkronitas fenti harom tulajdonsaganak azt a kovetkezmenyet hasznaljak ki, hogy lehet}oseg van id}otullepes meresere, gy lehet}oseg van egyes rendszerkomponensek hibazasanak a kivedesere. (Mivel e problemak tartalmilag messze tulmutatnek e dolgozat keretein, ezert itt nem

foglalkozunk veluk reszletesebben.) erverekneka rendszermag (mikrokernel) cmtartomanyaba agyazasara, amivel a rendszer komponensei kozotti draga kontextuscserek lenyegeben helyettesthet}ok cmtartomanyon beluli vezerlesatadassal, a komponensek kozotti adatatvitel pedig megoldhato cmtartomanyon belul torten}o memoriahozzaferessel, ami lenyegesen gyorsabb, mint ugyanez a m}uvelet mas folyamatok cmtartomanyabol. 26 Az ISIS rendszer egy masik uzenetkezbestesi szemantikat is biztost az osztott rendszerek tervez}oinek, a virtualis szinkronitasi szemantikat: e kezbestesi szemantika az uzenetek tartalmi fugg}osegen alapszik, es lenyegeben azt tudja biztostani, hogy egy (ujabb) uzenetet csak akkor kezbest a cmzettjehez, ha a cmzett mar az osszes olyan uzenetet megkapta, amelyeknek a tartalmatol fugghet ezen (ujabb) uzenet tartalma. A tartalmi fugges relaciojat a kovetkez}okeppen denialhatjuk: akkor es csak akkor mondjuk, hogy

egy e uzenett}ol tartalmilag fugghet egy f uzenet, ha a kovetkez}o harom feltetel valamelyike vagy kozuluk tobb is fennall: Ha ugyanaz a folyamat kuldi mindkett}ot, es olyan sorrendben, hogy el}oszor kuldi e-t, majd pedig f-et. Ha az e uzenetet fogado folyamat kuldi az f uzenetet az e uzenet fogadasa utan. Ha letezik egy masik m uzenet, amelyre teljesul egyreszt az, hogy m tartalmilag fugg e-t}ol masreszt pedig f tartalmilag fugg m-t}ol. 27 2 A Mach 3.0 mikrokernel attekintese Ez a fejezet bemutatja a Mach 3 kernel felhasznaloi feluletet. A Mach rendszert operacios rendszerek alapjanak terveztek, gy szeleskor}u lehet}osegekkel rendelkezik a memoriakezeles teren, biztost tobb vegrehajtasi pontot (threaded) es jo processzek (taszkok) kozti kommunikacios eszkozoket nyujt. A Mach tervezesi celjai kozul kulonosen nagy fontossaguak az alabbiak: Kihasznalhassak mind az operacios rendszerben, mind pedig a

felhasznaloi alkalmazasokban rejl}o parhuzamostasi lehet}osegeket. Nagy, nem feltetlenul osszefugg}o cmtartomany biztostasa az alkalmazasoknak, es mindez rugalmas alkalmazasok kozotti memoriamegosztasi lehet}osegekkel kiegesztve. Transzparens hozzaferesi lehet}oseg biztostasa a halozati er}oforrasokhoz. A korabbi szoftver-kornyezetekkel valo kompatibilitas biztostasa (peldaul a BSD rendszerrel). Hordozhatosag. A 2.5-os es korabbi valtozataiban a Mach rendszert osszekapcsoltak a UNIXszal6 es gy biztostottak az operacios rendszer szolgaltatasok jo reszet A 3as valtozattol kezdve a Mach mar csak alapvet}o kernel szolgaltatasokat nyujt, nem biztostja a kernelbe agyazva a korabbi valtozatokban megismert szeleskor}u operacios rendszer szolgaltatasokat (mint peldaul a fajlkezelesi operacios rendszer szolgaltatasokat). Itt az operacios rendszer funkcionalitast nem a kernelbe agyazva, hanem un.

felhasznaloi szinten lev}o szerverekkel biztostjak Eddig mar elkeszultek a BSD, SVR4, es az OSF/1 operacios rendszerek szolgaltatasait nyujto szerverek. A Mach mint kulonfele operacios rendszerek alapjat kepez}o technologia a kovetkez}o jellemz}okkel rendelkezik: Egyszer}u, kiterjeszthet}o kommunikacios lehet}osegekkel rendelkez}o kernelje van. Objektum alapu: az objektum-hivatkozasok a kommunikacios csatornakkal vannak reprezentalva. Kliens/szerver modell alapjan m}ukodik szinkron es aszinkron processzek kozotti kommunikacio biztostasaval. 6 A UNIX a Unix System Laboratories bejegyzett vedjegye. 28 Felhasznaloi taszkok latjak el a hagyomanyos operacios rendszer feladatok nagy reszet (pl. fajlrendszer funkciokat, a halozati hozzaferest) Az alapotlet tehat egy egyszer}u, kiterjeszthet}o kommunikacios lehet}osegekkel rendelkez}o kernel kifejlesztese, es a Mach projekttel kapcsolatos fejlesztesek illetve kutatasok

tovabbi celja az, hogy minel tobb funkcionalitast kivigyenek a (privilegizalt) kernelb}ol { egeszen addig, amg minden, ami kikerulhet onnan, kikerul onnan a kernel eszkozeivel kommunikalo felhasznaloi taszkokba. Termeszetesen a taszkok kommunikaciojan kvul vannak mas szolgaltatasok is, amiket a kernelnek kell biztostania { peldaul: A vegrehajtasi pontok (threadek) kezelese. Er}oforraskezeles (taszkok kezelese). A taszkok cmtartomanyanak a kezelese. Fizikai er}oforrasok (a hardver) kezelese (ide tartozik a zikai memoria, a processzorok, a periferiak es az ora kezelese is). Tehat az a cel, hogy minel tobb funkcionalitast kivigyenek a privilegizalt uzemmodban futo kernelb}ol ezzel a felhasznaloi szint}u taszkokra bzzak az er}oforraskezelesi strategiak kialaktasat es megvalostasat a kernel egyszer}uen eszkozoket biztost ezen strategiak megszervezesere /es megvalostasara. 2.1 A Mach kernel

absztrakcioi Bar a Mach kernel tervezesekor cel volt a kernel altal biztostott absztrakcios eszkozok szamanak csokkentese, nem volt cel az ezen eszkozok altal biztostott lehet}osegek sz}uken tartasa. Az egyes absztrakcios eszkozok szoros kapcsolatban allnak egymassal, ezert nagyon nehez az egyikr}ol a tobbi kozul kiragadva beszelni. A legfontosabb kernel absztrakciok a kovetkez}ok (a hozzajuk f}uzott magyarazatok tartalmaznak informalis utalasokat mas kernel absztrakciokra, de szerintem ilyen kis melysegben ez az egymasra hivatkozas meg konnyen attekinthet}o): taszk { Er}oforrasok lefoglalasara kepes egyseg (minden taszknak van egy sajat virtualis cmtartomanya, es minden taszkhoz tarolva vannak a taszk port-hozzaferesi jogosultsagai is). thread { Programvegrehajtasi pont (ez a Mach alatt egy nagyon kis er}oforrasigeny}u objektum). port { Kommunikacios csatorna vegpontja, a hozzaferes csak a megfelel}o

adatkuldesi/adatfogadasi jogon keresztul lehetseges. 29 uzenet { Adatobjektumok gy}ujtemenye (ahol egy adatobjektum lehet egy bytesorozat, port hozzaferesi jog, valamint adatobjektum lehet akar egy memoriaresz is). memoria objektum { A memoriakezeles bels}o egysege (ezeken keresztul vezerelhetik az egyes taszkok a memoria tartalmanak a kezeleset). 2.2 Taszkok es threadek A Mach kernel nem biztostja a hagyomanyos processz fogalom analogonjat a kovetkez}o okok miatt: Minden operacios rendszer nyilvantart bizonyos informaciokat a processzekr}ol, mint peldaul a futtato felhasznalo azonostojat, signalkezel}ok allapotat, . A Mach kernelnek nem celja az ilyen operacios rendszert}ol fugg}o informaciok kezelese. Sok operacios rendszer (pl. a Berkeley UNIX) egy processzhez egy programvegrehajtasi pontot rendel, mg mas rendszerek (peldaul a POSIX 1003.4a szabvany) nemcsak egyet A Mach kernel az operacios rendszerek processz

fogalmatol teljesen fuggetlen modon akarja a tobb programvegrehajtasi pont denialhatosagat biztostani ::: Helyette a Mach kernel ket absztrakcios eszkozt nyujt: a taszkot es a threadet. A thread a Mach altal biztostott programvegrehajtasi pont absztrakcio Egy taszk pedig a benne futo threadek szamara er}oforrasokat biztost Egy thread altalanossagban a kovetkez}okeppen jellemezhet}o: Egy taszkban egy programvegrehajtasi pont. Hozzaferhet az }ot tartalmazo taszk osszes er}oforrasahoz. A tobbi threaddel parhuzamosan kerul vegrehajtasra (meg az ugyanabban a taszkban lev}o threadekkel is). Minimalis allapot-informaciot hordoz a kis er}oforrasigeny elerese erdekeben. Egy taszk: Rendszerer}oforrasok gy}ujtemenye, mely er}oforrasokra a taszk { a memoria-er}oforrasok kivetelevel { portokon keresztul hivatkozhat. Ezekhez az er}oforrasokhoz mas taszkok is hozzaferhetnek, amennyiben a hozzajuk tartozo porthoz

hozzaferhetnek. Megjegyezzuk, hogy a memoriaer}oforrasokat a memoriabelicmuk alapjan erhetjuk el a megfelel}o memoriaolvaso illetve memoriaro m}uveletekkel. 30 Rendelkezik egy nem feltetlenul osszefugg}o memoriatartomannyal, melynek egyes reszeit mas taszkokkal megosztva erheti el a memoriatartomanyok oroklese vagy bizonyos kuls}o memoriakezel}ok altal biztostott memoriamegosztasi lehet}osegek miatt. Tartalmaz valahany thread-et. Megjegyezzuk, hogy egy taszknak nincs onallo elete: csak a benne lev}o threadek hajthatnak vegre gepi utastasokat. Amikor azt mondjak, hogy "egy Y taszk X-et csinal", akkor ez alatt azt ertik, hogy "egy thread az Y taszkban X-et csinal". Egy taszk { a threadekkel ellentetben { mint er}oforrasok gy}ujtemenye egy meglehet}osen koltseges egyseg. Egy taszk osszes threadje hozzafer a taszk osszes er}oforrasahoz. Ket taszknak alapertelmezes szerint nincsenek kozos

er}oforrasaik (bar lehetnek kozos er}oforrasaik, ehhez azonban a taszkoknak gondoskodniuk kell arrol, hogy a kozos hozzaferes}u er}oforrasok mindkett}ojukben elerhet}ok legyenek { ehhez a Mach kernel biztost nem tul bonyolult mechanizmusokat). Egyes er}oforrasok (peldaul egy portrol adatok fogadasi joga) nem megoszthato a taszkok kozt. Egy thread egy olcso er}oforras: kis rafordtassal letrehozhato, m}ukodesehez keves er}oforrasra van szuksege (ez azert van gy, mert a threadhez tartozo bels}o allapot minimalis { altalaban a processzor regiszterkeszlete { az altala elert er}oforrasok kezeleset pedig az }ot tartalmazo taszk vegzi). Egy tobbprocesszoros rendszerben egy taszknak egyidej}uleg tobb threadje is vegrehajtas alatt allhat. Meg olyan esetekben is, amikor a parhuzamostas nem cel, hasznos lehet tobb thread alkalmazasa, mivel ekkor minden thread megrhato szinkron uzemmodban, szinkron rendszerhvasok

hasznalataval ahelyett, hogy megprobalnank aszinkron programozasi techinkakkal (peldaul esemenyvezerelt programozasi technikaval) egy threadet tobb (esetleg egymastol teljesen fuggetlen) szolgaltatas biztostasara kialaktani. 2.3 Memoriakezeles A Mach kernel biztostja a nagy, nem feltetlenul osszefugg}o memoria kezelesehez szukseges mechanizmusokat. Minden taszk rendelkezik egy, a kernel altal manipulalt cmterkeppel, amely vezerli a virtualis memoriacmek zikai memoriacmekre torten}o lekepezeset. Mint az a virtualis memoriat biztosto rendszerek nagy reszere jellemz}o, a taszkok virtualis cmtartomanyanak mindig van egy-egy resze, amely nincs benn a zikai memoriaban egy-egy adott id}opillanatban, ezert kell valamilyen mechanizmus a zikai memorianak a taszkok virtualis cmtartomanyanak a cache-elesere valo hasznalatara. Nem ugy, mint mas virtualis memoriat kezel}o rendszerek, a Mach kernel nem

implementalja ennek a cache-elesnek az osszes reszletet, ehelyett lehet}oseget nyujt felhasznalo altal kesztett taszkok szamara arra, hogy e cache-eles egyes reszleteit megvalostsak. 31 A virtualis memoria a tobbi er}oforrastol elter}oen nem portokon keresztul erhet}o el, a memoriara csakis egy-egy taszk virtualis cmtartomanyabeli virtualis cmekkel hivatkozhatunk. Egy taszk cmtartomanyat kepez}o memoria az azt lero memoriaterkeppel egyutt egeszeben vagy reszben megoszthato mas taszkokkal a szorosan kapcsolt hardver kornyezetben es a lazan kapcsolt hardver kornyezetben egyarant. Egy taszk allokalhat uj memoriateruleteket, deallokalhat memoriateruleteket es modosthatja az egyes memoriateruletekre vonatkozo vedelmi informaciokat. Ezenkvul egy taszk meghatarozhatja az egyes memoriareszeinek az oroklesi jellemz}oit is. Egy uj taszk letrehozasakor mindig ki kell jelolni egy mar meglev}o taszkot,

amelyet az uj taszk memoriaszerkezetenek kialaktasakor az operacios rendszer mintanak fog tekinteni. Ilyenkor a meglev}o (mintakent hasznalando) taszkban lev}o egyes memoriareszek oroklesi jellemz}oi hatarozzak meg azt, hogy az ujonnan letrehozott taszkban a megfelel}o memoriaresz denialt legyen-e, illetve amennyiben azt a reszt az uj taszk orokli, akkor a szul}otaszkkal egy kozos, megosztott memoriateruletkent hasznalja azt, vagy pedig sajat peldanyt kell, hogy kapjon bel}ole. A Mach rendszerben a legtobb memoriamasolasi m}uvelet copy-on-write modszerrel van optimalizalva: a masolando memoriareszek tartalma nem lesz egyb}ol lemasolva, hanem masolas utan a haznalok a ket peldanyt "rasvedetten" ugyan, de kozosen hasznaljak tovabb. Ha barmelyik hasznalo megprobalja a kozosen hasznalt "rasvedett" memoriaresz tartalmat modostani, akkor a megfelel}o resz tenyleges lemasolasara a

modostas pillanataban kerul sor - onnan kezdve pedig mindenki a sajat peldanyat latja, hasznalhatja. Ez a kesleltetett memoriamasolas egy fontos hatekonysagnovel}o optimalizacio a Mach kernelben, es jelent}os mertekben hozzajarul a Mach kernel kommunikacios/memoriakezelesi lozoajanak az alaktasahoz. Egy memoria-kezel}o taszk biztostja a (zikai) memoriaban lev}o lapok tartalma es az ugyanehhez az informaciotartalomhoz tartozo, nem a zikai memoriaban tarolt informacio (egy un. absztrakt memoria objektum) kozti kapcsolatot, konverziot. A Mach kernel tartalmaz egy alapertelmezeskent rendelkezesre allo memoria-kezel}ot, amely olyan nem-perzisztens memoria objektumok letrehozasat biztostja, amelyek kezdetben nulla kodu ertekekkel vannak feltoltve, es a rendszer lapozasi teruletere lesznek szukseg eseten kilapozva. 2.4 Taszkok k
oz
otti kommunikacio A taszkok kozotti kommunikacio a Mach lozoajanak

egy nagyon fontos elemet alkotja. A Mach egy kliens/szerver alapu rendszerstrukturat feltetelez, ahol egyes taszkok (kliensekkent) mas taszkok (szerverek) szolgaltatasait erhetik el az }oket osszekot}o kommunikacios csatornan keresztul kuldott uzenetek segtsegevel. Mivel a Mach kernel onmagaban keves szolgaltatast nyujt (peldaul a fajlkezelesi szolgaltatas sem resze a mikrokernelnek), ezert egy "atlagos" Mach taszk sok mas taszkkal kell, hogy kommunikaljon annak erdekeben, hogy 32 hozzaferjen a szamara szukseges szolgaltatasokhoz. A taszkok kozotti kommunikacio kommunikacios csatornajat portnak nevezik Egy port egy egyiranyu csatorna, amelyen koratos mennyiseg}u uzenet tartozkodhat. Egy uzenet tartalmazhat adatokat, memoriareszeket es portok hozzaferesi jogait Egy port hozzaferesi joga egy nev, amellyel az adott taszk a porthoz valo hozzaferesi jogosultsagat azonostja (a Mach kernellel

szemben). Egy taszk csak akkor ferhet hozza egy adott porthoz, ha az adott portra vonatkozoan a megfelel}o hozzaferesi jogokkal rendelkezik. Egy adott portra vonatkozoan csak egyetlen taszknak lehet olvasasi joga (ez az adatfogadasi jog). Ez az egy taszk jogosult a portra kuldott uzenetek feldolgozasara (beolvasasara). Egyidej}uleg egy adott portra vonatkozoan tobb taszknak is lehet adatkuldesi joga, amivel lehet}oseguk van az adott portra uzenetek kuldesere. Ket taszk kommunikaciojakor a kuld}o az elkuldend}o adatokbol felept egy uzenetet, es egy uzenetkuldesi m}uveletet hajt vegre egy olyan porton, amelyre adatkuldesi joggal rendelkezik. Kes}obb az a taszk, amelynek erre a portra vonatkozoan olvasasi joga van, vegrehajt egy uzenetolvasasi m}uveletet. Megjegyezzuk, hogy ez az uzenetatvitel egy aszinkron m}uvelet. Az uzenet atmasolasa altalaban a korabban is emltett copy-on-write optimalizacios technikaval tortenik. Az

uzenetet fogado taszkban tobb aktv thread is olvashat uzeneteket ugyanarrol a portrol, de egy uzenetet csak egy thread fog leolvasni { azaz nem fordulhat el}o, hogy egy egy peldanyban elkuldott uzenetet ket { az adott portrol egyszerre { olvaso thread is megkaphat. A Mach kernel onmagaban nem egy elosztott rendszer (hacsak be nem konguraltak a kserleti multicomputer kiegesztest, ami elosztott memoriahozzaferest es elosztott uzenetkuldest biztost Mach kernelek kozott). Viszont a Mach taszkok kozti kommunikacioja lehet}oseget nyujt olyan szerver taszk kesztesere (ez a Net Message Server { a halozati uzenettovabbto szerver), amely transzparensen kepes halozaton keresztuli uzenettovabbtasra. 2.5 A Mach alatti hardver Ebben a pontban attekintjuk azt, hogy a Mach milyen hardvert feltetelez maga alatt, illetve azt, hogy milyen gyorstasok vegezhet}ok a Mach folyamatok egymas kozotti kommunikaciojan megfelel}o

hardver konguraciok eseten. A hardver keszt}ok ket dolgot tehetnek a szamtogepuk teljestmenyenek novelese erdekeben: vagy novelik a processzor sebesseget vagy pedig kihasznaljak a processzorok szamanak noveleseben rejl}o lehet}osegeket illetve az alkalmazasok parhuzamostasaban rejl}o lehet}osegeket. A hardver architekturak szoftveresek szemszogeb}ol torten}o jellemzesere es osztalyozasara mar tobb kserlet is tortent. A legelterjedtebb osztalyozasmodot Flynn alaktotta ki (ld. Flynn72]-t) a hardverek ket alapvet}o jellemz}ojet gyelembeveve: egyreszt azt, hogy egy adott hardver egyidejl}uleg hany utastas feldolgozasara kepes, masreszt pedig azt, hogy egyidej}uleg hany adatcsatornat kepes kezelni. Ezalapjan a hardvereket negy osztalyba sorolta: SISD, SIMD, 33 MISD es MIMD osztalyokba7. Az osszes hagyomanyos egyprocesszoros szamtogep (peldaul egy Sinclair Spectrum, IBM PC) az SISD

kategoriaba tartozik. Az SIMD kategoriaba keves hardver tartozik: altalaban olyan szamtogepek, amelyeknek ugyanazokat a m}uveleteket kell elvegezniuk nagymennyiseg}u adaton. Az MISD kategoriaba tartoznak egyes vektorprocesszorok. Az altalunk vizsgalt osztott rendszerek mind az MIMD kategoriaba tartoznak. Az MIMD architekturak ket csoportra bonthatok: a multicomputerekre es a multiprocesszorokra. Manapsag a legfejl}od}obb parhuzamos sokprocesszoros MIMD hardver architektura a szimmetrikus multiprocesszoros (SMP) architektura, amely onnan kapta a nevet, hogy tobb processzor parhuzamosan kepes egy ilyen szamtogepben dolgozni, es a szimmetria az elnevezesben onnan ered, hogy a processzorok egyenranguak, azaz peldaul nincs koztuk egy kituntetett, amelyiken kvul a tobbi nem kepes az operacios rendszer futtatasara. A szimmetria a memoriahozzaferesben is megmutatkozik: minden processzor ugyanazt a memoriat latja. Sajnos ezek a

rendszerek nehany tz processzornal tobbel nem b}ovthet}ok a teljestmeny drasztikus csokkenese nelkul. A parhuzamos szamtogepek egy masik csoportjat kepezik a masszivan parhuzamos (MPP) szamtogepek, mas nevukon multicomputerek. Ezek sajat processzorral ellatott csomopontok ezreit tartalmazzak (egy csomopont akar tobb processzort is tartalmazhat) nagysebesseg}u halozattal osszekotve (az osszekot}o halozat lehet FDDI, DMA, SCSI vagy mas technologiaju is { de ez most szamunkra nem lenyeges). E multicomputerekben altalaban minden processzor csak a sajat memoriajat kepes elerni, gy gyakran nevezik }oket NORMA (NO Remote Memory Access) architekturajunak. A Mach mikrokernel a NORMA multicomputer architekturakat az uzenetatadasi es a memoriakezelesi szolgaltatasainak a multicomputer komponenseit osszekot}o halozatra valo transzparens kiterjesztesevel tamogatja: a kernelbe be vannak eptve az IPC eszkozoket

a teljes multicomputerre transzparensen kiterjeszt}o mechanizmusok. Ennek lenyegeben egyszer}u kovetkezmenyekent tekinthetjuk a memoriakezeles transzparens kiterjeszteset, mivel a memoriakezel}o es a Mach kernel a NORMA IPC eszkozokkel minden problema nelkul ugyanugy tarthatja a kapcsolatot multicomputer architekturakon, mint a hagyomanyos (nem NORMA) architekturakon. Az egyetlen gond ezzel kapcsolatban az, hogy a legtobb memoriakezel}o nem tartalmazza a kezelt memoriaobjektumaira vonatkozoan a tobb kernelb}ol egyszerre torten}o konzisztens eleres biztostasahoz szukseges reszeket. Ezert kesztettek el a 7 Az SISD a Single Instruction Single Data kezd} obetuib}ol szarmazik, mg az MIMD a Multiple Instruction Multiple Data kezd}obetuib}ol. A masik ket mozaikszo hasonloan szarmaztathato, es jellemzi az adott osztalybeli hardverek utastascsatornainak szamat (az I bet} u el}otti M a tobb, az S pedig az egy utastascsatornara utal), es jellemzi az

osztalybeli hardverek adatcsatornainak szamat (ezt a jellemz}ot a D bet}u el}otti bet}u alapjan allapthatjuk meg { az el}obbiekhez hasonloan). 34 Mach mikrokernel XMM alrendszeret, amely Mach kerneleknek egy halmazat a memoriakezel}o taszkokkal szemben egy kernelkent viselked}okent alltja be (ld. err}ol reszletesebben Barrera93]-at). A Mach mikrokernel memoriakezelese optimalizalva van az SMP architekturakra olymodon, hogy amikor a folyamatok kozotti kommunikacio soran nagy, osszefugg}o memoriareszeket akar az egyik taszk a masiknak kuldeni, akkor a memoria byteonkenti masolasa helyett eleg a laptabla megfelel}o reszeit a cmzett taszk cmtartomanyaba bemasolni (es utana a korabban mar emltett copy-on-write memoriakezelesi technikaval (ld. 23 pontot) tovabbi hatekonysagnovekedeseket erhetunk el). A Mach az MPP architekturakon nem biztost tovabbi optimalizalasokat, viszont a ra epul}o szoftverek cache-elessel

lenyeges hatekonysagnovekedest tudnak elerni. 35 3 Architektura modell Mint minden operacios rendszernek, gy a Mach-nak is az egyik els}odleges fontossagu feladata a programvegrehajtasi pontok kezelese. A Mach-ban a programvegrehajtasi pontokat thread-eknek nevezik. A Mach lozoaja szerint a threadek egy virtualis kornyezetben futnak, amely all egy virtualis processzorbol (amely multiprogramozottan is lehet ugyan implementalva, de akar id}oosztassal szimulaljak, akar egy hardver processzor van mogotte, a thread a sajat processzoranak tekintheti e virtualis processzort), es ez a virtualis processzor a CPU felhasznaloi uzemmodjaban ertelmezett utastasait hajtja vegre, valamint kezdemenyezheti a specialis, a CPU supervisor modjabeli gepi utastasok vegrehajtasat is, de ezeknek a vegrehajtasat csak a Mach kernel felugyeletevel, engedelyevel vegezheti el. Ez a virtualis processzor a regiszterein kvul hozzafer egy

virtualis memoriahoz, amely ugyanugy viselkedik, mint a gep zikai memoriaja (bar valamilyen "virtualis" MMU egyseg ehhez mar nem tartozik, ugyanis egy taszk egy linearisan cmezhet}o virtualis memoriaval rendelkezik). Ebben a fejezetben roviden bemutatom a Mach-beli threadek virtualis kornyezetenek alkotoelemeit, es az ezeken az alkotoelemeken mint absztrakt adattpuson vegrehajthato tpusm}uveleteket. 3.1 A virtualis k
ornyezet elemei A Mach kernel altal a threadeknek nyujtott virtualis kornyezet a kovetkez}o elemeket tartalmazza: *thread { Egy programvegrehajtasi pont. Olcso er}oforras az }ot tartal- mazo taszk osszes er}oforrasahoz hozzafer. *taszk { Egy objektum, amely er}oforrasokra vonatkozo referenciakat tarol a rendelkezesere allo port nevekkel (ne felejtsuk el, ezek a port hozzaferesi jogok nevei), rendelkezik egy virtualis cmtartomannyal, valamint rendelkezik nehany benne m}ukod}o thread-del.

*biztonsagi objektum { Nem kimondottan kernel objektum. A privilegizalt biztonsagi port (security port { ez egy taszkonkent nyilvantartott specialis port) hasznalhato egy taszk identitasanak megvaltoztatasakor (a biztonsagi objektumot a biztonsagi port nevezi meg). *ledger { Egy er}oforrashasznalasi szamlazast vegz}o eszkoz, aminek a segtsegevel korlatozhato a felhasznalhato kernel er}oforrasok mennyisege. *port { Egy taszkok kozotti egyiranyu kommunikacios csatorna. *porthalmaz { Portok halmaza, mely egyetlen egysegnek tekinthet}o uzenetfogadas szempontjabol. 36 *port hozzaferesi jog { Egy "jogostvany", mely bizonyos m}uveletek elvegzesehez szukseges jogokat szolgaltat egy-egy adott portra vonatkozoan. *port nevek rendszere { Port neveknek egy indexelt gy}ujtemenye, melyeknek mindegyike egy-egy port hozzaferesi jogot azonost ("nevez meg"). uzenet { Adatokbol, memoriaregiokbol, port

hozzaferesi jogokbol allo rendszer, amit egy taszk valamely threadje atkuldhet egy tetsz}oleges taszk tetsz}oleges portjanak. uzenetcsatorna { Egy porthoz tartozo, a portra kuldott uzenetek sorozata. *virtualis cmtartomany { Egy nem feltetlenul osszefugg}o memoriatartomany (memoria-lapok rendszere), amit a threadek a CPU memoriahozzaferesi m}uveleteivel erhetnek el az }oket tartalmazo taszkon belul, vagy a Mach nyujtotta virtualis memoriakezelesi eszkozokkel taszkok egymas virtualis cmtartomanyait alkoto memoriateruleteket is elerhetik. A memorialapok eleresehez tetsz}oleges szemantika implementalhato a kernel es a kernelen kvuli memoriakezel}ok nyujtotta mechanizmusok segtsegevel. absztrakt memoriaobjektum { Egy absztrakt objektum, ami az objektumhoz tartozo memoriaterulet nem rezidens allapotat reprezentalja. Memoriakezel}onek nevezik azt a taszkot, amely az absztrakt memoriaobjektumokhoz tartozo szemantikat

implementalja. A Mach kernel az objektumhoz tartozo absztrakt memoriaobjektum-porton keresztul kommunikal a memoriakezel}o taszkkal. memoriaobjektum reprezentatva { A memoriakezel}onek a kliensei fele nyujtott objektumok absztrakt reprezentacioja. Ezen objektum alapjan azonosthato a megfelel}o absztrakt memoriaobjektum, es erre az objektumra vonatkozoan vannak megadva az esetleges hozzaferesi illetve vedelmi korlatozasok (ez olyan esetben lehet kulonosen erdekes, ha a kulonboz}o klienseknek mas-mas hozzaferesi jogokat kell biztostani az absztrakt memoriaobjektumhoz). *memoria cache objektum { Ez is egy memoriakezelessel kapcsolatos objektum, de ezt az objektumot a kernel kezeli. Ez az objektum tartalmazza az absztrakt memoriaobjektum kezel}oje altal biztostott memorialapok memoria-rezidens allapotat. A kernel ilyen objektumokon keresztul manipulalja a kliens taszkok virtualis cmtartomanyanak tartalmat. 37 *processzor { A

szamtogep hardver egy processzor-egysege, mely kepes gepi utastasok vegrehajtasara. *processzorhalmaz { Processzorok halmaza, mely kepes a processzorhalmazra bzott threadek vegrehajtasara. *host { Ez maga a szamtogep az osszes processzoraval es hardver periferiajaval egyutt. *csomopont { Egy multicomputerben (ld. 25 pontot) egy tetsz}oleges multiprocesszoros egyseg. *ora { Egy egesz ertek}u, az id}o mulasat reprezentalo objektum, mely az id}o mulasat rendszeres { konstans id}okozonkenti gyakorisaggal torten}o { inkrementalodasaval reprezentalja. *kernel periferia { Egy hardver periferia, melyet elerhetnek a felhasznaloi uzemmodban futo taszkok. (Egy csillag (*) karakter van azon er}oforrasok neve el}ott, amelyeket a kernel implemental, es a felhasznaloi uzemmodban futo threadeknek modjukban all az adott er}oforras manipulalasa.) A fenti fogalmak reszletesebb bemutatasa a kes}obbi pontok temaja lesz, de

mivel ezek nagyon osszetett objektumok, gy a megertesukhoz szukseges lehet egyes mas er}oforrasok bizonyos jellemz}oinek ismerete, gy el}oszor egyes kulcsfontossagu er}oforrasoknak egy informatv ismertetese kovetkezik, majd ezt koveti az er}oforrasok reszletes denitv jelleg}u bemutatasa { ami az informalis leras alapjan remelhet}oleg egy teljes, konzisztens kepet ad a Mach mikrokernel lehet}osegeir}ol. A thread a legalapvet}obb m}uveletvegz}o egyseg. Egy es csakis egy taszkhoz tartozik, amely a thread virtualis cmtartomanyat denialja. A cmtartomany szerkezetenek a modostasahoz, vagy a nem a memorian keresztul elerhet}o er}oforrasok eleresehez egy threadnek egy specialis { direkt erre a celra kijelolt { gepi utastast kell vegrehajtania, amelynek vegrehajtasa utan a kernel elvegzi a thread altal igenyelt m}uveleteket (vagy utastja a megfelel}o rendszerkomponenst a thread altal igenyelt m}uvelet

elvegzesere). A ltalanossagban tekintve: ilyen modon manipulalhatok a threadet tartalmazo taszk er}oforrasai. A kernelnek kuldhet}ok keresek er}oforrasok letrehozasara, megsz}untetesere es az er}oforrasok bels}o allapotanak modostasara. A Mach modellben a kernelt is szolgaltatasokat illetve er}oforrasokat biztosto rendszerkomponensnek lehet tekinteni. A kernelen kvul a taszkok is biztosthatnak kulonfele szolgaltatasokat A kernelnek ilyenkor a taszkok kozotti kommunikacio megszervezese a feladata: lehet}oseget kell biztostania a kliens taszkoknak a szerver taszkok szolgaltatasainak eleresere. Igy mondhatjuk azt 38 is, hogy egy taszk { mint egy, a kernel altal biztostott absztrakcios eszkoz { kett}os identitassal rendelkezik: Egyreszt egy kernel altal kezelt er}oforras. Masreszt er}oforrasokat biztosthat mas rendszerkomponenseknek, es ezeknek az er}oforrasoknak a kezeleseert kizarolagosan az }oket

biztosto taszk felel}os (a kernel csak olyan mechanizmusokat biztost, amik a taszkokat segtik feladatuk elvegzeseben). A taszkok virtualis cmtartomanyanak kivetelevel minden mas er}oforras csak kozvetetten, un. porton keresztul erhet}o el A port egy egyiranyu kommunikacios csatorna, mely csatorna altalaban egy szolgaltatast igenybe vev}o kliens es a szolgaltatast biztosto szerver taszk kozt lesz kieptve. (Ha a szolgaltatotol a szolgaltatas igenybevev}oje valaszt var, akkor egy masodik portra is szukseg van, a szervert}ol a kliens fele vezet}o kommunikacios utvonal megszervezesere.) Az igenybe vett szolgaltatas jellemz}oit a szolgaltatas biztostoja hatarozza meg a porton keresztul hozza kuldott informaciok alapjan. Nyilvanvalo, hogy a Mach kernel altal kezelt objektumok, szolgaltatasok igenybevetelere hasznalhato portokrol a kernel fogadja az oda kuldott uzeneteket a nem a kernel (hanem valamely

felhasznaloi uzemmodban futo taszk) altal biztostott szolgaltatasokat reprezentalo portokra kuldott uzeneteket pedig a szolgaltatast biztosto taszk fogja fogadni. A nem a kernel altal biztostott szolgaltatasokhoz tartozo portokrol valo olvasas joga atadhato valamely mas taszknak is, ha erre szukseg van. Egy taszk tobb porttal is rendelkezhet: egy er}oforrasnak lehet akar tobb kulonboz}o }ot reprezentalo portja is, peldaul mindegyik mas-mas hozzaferesi jogokat biztosthat ugyanahhoz az er}oforrashoz. Peldaul sok er}oforras rendelkezik n
ev- illetve vez
erl}oporttal (ez utobbit gyakran nevezik privilegizalt portnak). A vez
erl}oporthoz valo hozzaferes joga8 lehet}oseget nyujt a port altal reprezentalt er}oforras allapotanak modostasara a nev-porthoz valo hozzaferes joga csak az adott er}oforras azonostasara szolgal, inkabb informativ jelleg}u9 A rendszerben nincs egy globalis porthozzaferesi jog

tablazat: a porthozzaferesi jogok taszkonkent vannak nyilvantartva, minden thread csak azokhoz a portokhoz ferhet hozza, melyre vonatkozoan az o}t tartalmazo taszknak hozzaferesi joga van. A porthozzaferesi jog tablazat minden egyes eleme megnevez egy-egy portot es a lehetseges hozzaferesi jogokat (megjegyezzuk, Vagyis az, hogy valakinek arra van joga, hogy a portra uzenetet kuldjenek. Ennek hasznalatara tekintsuk a kovetkez}o peldat: egy szerver a kliense szamara letrehozott er}oforrast { az azonostasahoz szukseges informaciokat10 { olyan modon akarja a kliensenek atadni, hogy az azonosto ne tartalmazzon az er}oforrasrol az elhelyezkedesevel kapcsolatos informaciokat. Ilyenkor peldaul megteheti azt, hogy letrehoz egy, az er}oforrast reprezentalo portot, es azt adja at a kliensnek. Ez azert hasznos, mert szukseg eseten gy az er}oforras szabadon atkoltoztethet}o egy masik taszkba anelkul, hogy a kliens alkalmazas ebb}ol barmit is eszrevenne: a

kliensnek gy csak egy portja van, aminek a "masik vegen" lev}o uzenetfogado taszkjanak az identitasa akar valtozhat is az id}ok folyaman. 8 9 39 hogy egy bizonyos porthoz tobb porthozzaferesi jog neve is tartozhat, es ezen nevek mogott nem kell, hogy ugyanolyan hozzaferesi m}uveletek legyenek engedelyezve). A porthozzaferesi jogok kuldhet}ok a taszkok kozotti kommunikacioban hasznalatos uzenetekben is: a taszkok gy juthatnak mas taszkok altal letrehozott portokra vonatkozo jogokhoz. Egy porthozzaferesi jogot egy port nevvel nevezhetunk meg, ami egy, a kernel altal a port letrehozasakor valasztott egesz szam, es jelentessel csak az adott taszkon belul br (ui. a porthozzaferesi jog tablazat taszkonkent van nyilvantartva). A Mach-alapu rendszerekben a legtobb szolgaltatast a megfelel}o szerver fele torten}o uzenetkuldessel vehetjuk igenybe, ahol a kuldott uzenet cmzettje egy olyan port (neve), amely a

modostani kvant objektum kezel}ojet nevezi meg. 3.2 Threadek A thread a szamtas (programvegrehajtas) alapvet}o egysege, gyakran nevezik programvegrehajtasi pontnak (PVP-nek) is. Egy thread egy es csakis egy taszkhoz tartozik, mely taszk a thread virtualis cmtartomanyat denialja. Egy thread allapotat a kovetkez}okkel jellemezhetjuk: Egy CPU-allapotot lero komponens (regiszterertekek, es egyebek), amely a thread futasa kozben allandoan modosul (a CPU regiszterek ugymond "cache"-elik ezeket az informaciokat), es ezt az allapotot modosthatjak a thread vezerl}o-portjahoz hozzaferesi joggal rendelkez}o taszkok threadjei. Nehany thread-specikus port: egyreszt a thread vezerl}o-portja, es a thread kivetelkezel}o portja (erre a portra kapja a kernelt}ol a thread a bekovetkezett kivetelekr}ol az ertesteseket). Egy felfuggesztesi szamlalo, melynek ha erteke nem nulla, akkor a thread futasa felfuggeszt}odik.

Kulonfele utemezesi parameterek. Kulonfele statisztikai adatok (peldaul arrol, hogy a thread adott id}okozonkent mely helyen futott { vagyis a programszamlalo ertekei vannak bizonyos id}okozonkent kigy}ujtve). Egy thread m}ukodese soran gepi kodu utastasokat hajt vegre. Egyes gepi kodu utastasok hatasara a vezerles a threadt}ol atadodik a kernelhez (a Mach mikrokernelhez), ami vegrehajthat bizonyos, a thread szamara szukseges (vedett) m}uveleteket. Ezen "specialis" gepi kodu utastasok kozul a legfontosabb talan a mach msg overwrite trap nev}u Mach kernel belepesi pont meghvasat eredmenyez}o m}uvelet, amely lehet}ove teszi a threadnek egy uzenet kuldeset mas taszkokbeli threadek valamint a kernel reszere. (A C programokbol altalaban a mach msg() konyvtari fuggveny segtsegevel hvhatjuk meg ezt a kernel belepesi pontot { lasd err}ol reszletesebben OSF92r]-t.) 40 A thread futasa

soran el}ofordulo kiveteles-esemenyek (mint peldaul a lebeg}opontos tulcsordulas, vagy a laphiba) egy korabban, az erre a celra kijelolt portra kuldott uzenettel lesznek a thread szamara jelezve. Egy threaden a kovetkez}o m}uveletek vegezhet}ok: Letrehozas, megsz}untetes. A thread sajat identitasanak meghatarozasa (azaz a vezerl}oportjanak a megszerzese). (Futas-)Felfuggesztes es a felfuggesztes megsz}untetese. A threadhez tartozo gepi allapot (CPU-regiszter ertekek) manipulalasa. A thread-specikus portok manipulacioja. A thread utemezesi jellemz}oinek modostasa. A thread futasarol statisztikai adatok gy}ujtese (a programszamlalo ertekenek meghatarozott id}okozonkenti gyelese utjan). 3.3 Taszkok Egy taszk tekinthet}o a threadjeit tartalmazo egysegkent, mivel meghatarozza threadjei parametereinek az alapertelmezes szerinti erteket (amik addig ervenyesek, amg a threadek a sajat jellemz}oiket nem

modostjak a rendelkezesukre allo eszkozokkel). A taszk objektum tartalmazza a threadjei szamara is lathato memoriareszeket, valamint a taszk (threadjei) altal elerhet}o portok neveit (a korabban mar emltett port nevek rendszeret). Egy taszk allapota a kovetkez}o parameterekkel jellemezhet}o: A benne lev}o threadek allapotaval. A hozza tartozo virtualis cmtartomannyal. A hozza tartozo portnevek rendszerevel. Egy biztonsagi azonostoval (security ID), amely a taszk altal kuldott uzenetekben lesz az uzenetfejlecben elkuldve. Nehany taszkspecikus port: a taszk identitasat megnevez}o port (a kernel altal a taszk manipulalasara biztostott portot), a taszk er}oforrasfelhasznalasat szabalyozo ledgerek, a threadek szamara alapertelmezes szerint kijelolt kivetelkezel}o port, valamint a taszk bootstrap portja, amin keresztul { altalaban { a taszk threadjei elerhetik a mas taszkok nyujtotta szolgaltatasokat. Egy

rendszerhvas-emulalo eljaras, amely bizonyos rendszerhvasok vegrehajtasakor lesz vegrehajtva. 41 Egy felfuggesztesi szamlalo, melynek ha erteke nem nulla, akkor a taszk osszes threadjenek felfuggeszt}odik a futasa. A taszk threadjeire vonatkozoan nyilvantartott kulonfele utemezesi parameterek alapertelmezes szerinti erteke. Kulonfele statisztikai adatok (peldaul arrol, hogy a threadjei adott id}okozonkent a program mely pontjan futottak { vagyis a programszamlalo bizonyos id}okozonkenti ertekei vannak kigy}ujtve). Egy uj taszk letrehozasakor mindig meg kell adni egy minta-taszkot, amelynek a helye alapjan a rendszer meg tudja hatarozni, hogy az uj taszkot mely hoston kell letrehoznia, es amelynek bizonyos jellemz}oit az ujonnan letrehozott taszk orokolheti. Egy taszkon a kovetkez}o m}uveletek vegezhet}ok: Letrehozas, megsz}untetes. A biztonsagi azonostojanak megvaltoztatasa. A taszk sajat

identitasanak meghatarozasa. (Futas-)Felfuggesztes es a felfuggesztett allapot megsz}untetese. A taszk-specikus portok manipulacioja. A taszk altal tartalmazott threadek manipulalasa. A taszk altal tartalmazott threadek es a taszk globalis utemezesi jellemz}oinek modostasa. A taszk altal tartalmazott threadek futasarol statisztikai adatok gy}ujtese (a threadek programszamlalo-ertekenek meghatarozott id}okozonkenti gyelese es kigy}ujtese utjan). 3.4 Biztonsagi port A taszkokhoz a Mach kernel nyilvantart egy-egy biztonsagi azonostot, amely egy { a kernel szemszogeb}ol { atlatszatlan azonosto, amely a taszk identitasanak es egyeb biztonsagossagi attributumainak jellemzesere hasznalhato. Ez a biztonsagi azonosto belekerul a taszk altal kuldott osszes uzenetbe, es ezt a szerverek tetszesuk szerint hasznalhatjak a taszk identitasanak meghatarozasara er}oforrashozzaferesi jogosultsagi kerdesek

eldontesekor. Egy taszk orokli a szul}ojenek a biztonsagi azonostojat. Ennek az azonostonak a modostasahoz { az azonosto jellegenel fogva { specialis privilegiumok szuksegesek. Ezek a privilegiumok a rendszer (a host) biztons
agi portj
anak birtoklasa mellett adottak egy taszk szamara. A KERNEL SECURITY ID foglalt ertek a Mach kernelt azonostja biztonsagi szempontbol (ezt az erteket tartalmazzak a kernel altal kuldott uzenetek). 42 3.5 Ledgerek Egy ledger egy er}oforrashasznalasi szamlazast vegz}o eszkoz, amely szamlazza es korlatozhatja az egyes objektumok altal felhasznalhato kernel er}oforrasok mennyiseget. Minden, portokkal megnevezett, kernel altal kezelt objektumhoz (a thread objektumokat kiveve, mivel ezek csak az }oket tartalmazo taszkon belul azonosthatok egy-egy porttal) nyilvan van tartva egy-egy ledger objektum, amely azokat a kernel er}oforrasokat reprezentalja, amelyekb}ol az objektum szamara

szukseges er}oforrasok lesznek fedezve (valamilyen er}oforrasfugg}o modon). A ledger objektumokon vegrehajthato m}uveletek a kovetkez}ok: Egy alarendelt ledger objektum letrehozasa. Az uj alarendelt ledger objektum a letrehozojanak a szamlajara szamlazza a rajta keresztul letrehozott er}oforrasokat (viszont a korlatokat megszorthatja). A ledger hasznalata mint er}oforrasbiztosto objektum egy uj kernel altal kezelt objektum letrehozasakor. Er}oforrasfelhasznalasi korlatok atvitele szul}o- es gyermek ledger objektumok kozott. A ledger objektum megsz}untetese, amelynek hatasara megsz}unik az osszes, a megsz}untetett ledger objektum szamlajara letrehozott, kernel altal kezelt objektum. 3.6 Portok Egy port egy egyiranyu kommunikacios csatorna egy szolgaltatast igenybevev}o kliens es egy szolgaltatast nyujto szerver kozott. Egy portnak egy fogadoja es tobb potencialis kuld}oje (olyan taszkok, akiknek joga van a

portra uzenetet kuldeni) lehet. Egy port allapota a kovetkez}o parameterekkel jellemezhet}o: A hozza tartozo (hozza kuldott) uzenetek sora. A ra vonatkozo hivatkozasok (port jogok) szamlaloja. Egy beallthato korlat, mely meghatarozhatja a portra kuldhet}o uzenetekben tarolhato memoria maximalis meretet, a kuldhet}o port hozzaferesi jogok maximalis mennyiseget, valamint a portra kuldhet}o adatok maximalis mennyiseget. A kernel biztost m}uveleteket portok allokalasara. A rendszerben lev}o osszes objektum (kiveve a virtualis memoria egyes regioi) portokkal vannak azonostva, gy ezen objektumok letrehozasakor automatikusan letrejon az }oket azonosto port is. 43 A kernel { igeny szerint { biztost egy, a port megsz}uneset jelz}o uzenetet, az azt igenyl}o taszkok szamara.
3.7 Uzenetek Egy uzenet adatok, memoriaregiok es port hozzaferesi jogok rendszere, amit aktiv entitasok (taszkok threadjei) kuldhetnek

egymas kozott. Egy uzenet onmagaban nem kernel objektum, de mivel az uzenetek egy sorba lesznek felf}uzve a feldolgozasukig, mas objektumok bels}o allapotat is tartalmazzak (vagy tartalmazhatnak arra vonatkozo referenciat), ezert tartalmazhat kernel objektumokat. Egy uzenet allapota a kovetkez}o parameterekkel jellemezhet}o: A benne kuldott adatok. A benne kuldott adatokhoz kapcsolt memoriaregio-masolatok. A benne kuldott port hozzaferesi jogok. A kernel altal az uzenethez kapcsolt adatokbol (az uzenetfejlecb}ol, ami tartalmazza peldaul az uzenetet kuld}o taszk biztonsagi azonostojat). A tovabbiakban ahol ez nem okoz felreertest { a felesleges szoismetlesek elkerulese vegett {, az uzenet szo helyett hasznalni fogom az adat szot is (pl. uzenetfogadas helyett adatfogadast rok).
3.8 Uzenetek sora Egy port lenyegeben (a ra kuldott) uzeneteknek egy sorat tartalmazza. Ez az uzenet-sor a portra uzenetet kuld}o es

onnan uzenetet olvaso (mach msg() nev}u) Mach kernel hvassal manipulalhato. Egy uzenetsor allapotat a kovetkez}o parameterek jellemzik: A hozza tartozo portra kuldott uzenetek rendezett sorozata. A hozza tartozo portra kuldhet}o uzenetek maximalis szama (vagyis a portra kuldott, es meg fel nem dolgozott uzenetek szama ilyen modon korlatozhato). 3.9 Port hozzaferesi jogok Egy porthoz csak a ra vonatkozo hozzaferesi jogon keresztul ferhetunk hozza. Egy port hozzaferesi jog egy port bizonyos tpusu manipulaciojara valo jogosultsagot reprezental. Haromfele port hozzaferesi jogosultsagrol beszelhetunk: Adatfogadasi jog : az e joggal rendelkez}o taszknak (pontosabban a taszk threadjeinek) joga van a portra kuldott uzenetek fogadasara. 44 Adatkuldesi jog : az e joggal rendelkez}o taszknak (pontosabban a taszk threadjeinek) joga van a portra uzeneteket kuldeni. Egyszeri adatkuldesi jog : az e joggal rendelkez}o

taszknak (pontosabban a taszk threadjeinek) joga van a portra egyetlen alkalommal uzenetet kuldeni. E jog az uzenetkuldes megtortentevel megsz}unik A port hozzaferesi jogok masolhatok es tovabbadhatok taszkon belul es taszkok kozott egyarant a mach msg() Mach kernel hvas kulonfele lehet}osegei segtsegevel, valamint leteznek e hozzaferesi jog tovabbadasara mas lehet}osegek is (port hozzaferesi jogot tovabbadhatunk masoknak akar uzenetkuldes nelkul is a cmzett taszk portnev-rendszerenek kozvetlen manipulalasaval { ld. a 310 pontot). A port hozzaferesi jogokat csak egy bizonyos port nevek rendszerebe agyazva manipulalhatjuk (mondjuk egy taszk portnev-rendszereben). Port hozzaferesi jogok jonnek letre portok letrehozasakor is, valamint mas { portokkal azonostott { kernel-objektumok letrehozasakor is. A kernel { a portra vonatkozo adatfogadasi jog birtokosanak, ha az korabban kerte { tud gyelmeztet}o

uzenetet kuldeni olyan esetben, ha a portra vonatkozoan mar senkinek sincs adatkuldesi joga. Hasonloan lehet}oseg van a kernelt}ol egyszeri adatkuldesi jog uzenetkuldes nelkul torten}o megsz}untetese eseten gyelmeztet}o uzenet kuldeset kerni (ez azert hasznos, mert a port tulajdonosa { altalaban }o az adatfogadasi jog birtokosa { nyilvantarthatja, hogy van-e meg potencialis adatkuld}o vagy ilyen taszk mar egyaltalan nem letezik a rendszerben). 3.10 Portnevek rendszere A port hozzaferesi jogoknak nincs egy, az egesz rendszerben globalisan hasznalhato neve (pontosabban: a Mach taszkoknak nem all rendelkezesere egy ilyen azonosto a port hozzaferesi jogok azonostasara illetve manipulalasara). A portokat csak a hozzaferesi jogokon keresztul manipulalhatjuk, es a port hozzaferesi jogokat mindig csak egy portnev rendszeren keresztul lehet elerni. Egy port hozzaferesi jogot egy portnev azonost, amely egy (egesz

tpusu) index, es mindig csak egy adott portnev rendszeren belul van ertelme (vagyis a portnev a portnak nem egy globalisan, esetleg akar taszkok kozott is atadhatoan, hasznalhato megnevezese). Minden taszk rendelkezik pontosan egy portnev rendszerrel. A portnev rendszer tabla egy-egy eleme a kovetkez}o ertekek valamelyiket veheti fel: MACH PORT NULL { Ezen a n even (ezzel az indexszel) nem rendelkezunk hozzaferesi joggal egyetlen porthoz sem. MACH PORT DEAD { Ezen a n even a taszk rendelkezett egy porthoz valamilyen tpusu hozzaferesi joggal, de a port, amelyre a hozzaferesi jog vonatkozott, id}okozben megsz}unt. 45 egy port hozzaferesi jog { Egy adatfogadasi vagy adatkuldesi vagy egyszeri adatkuldesi jog valamely portra vonatkozoan. egy porthalmaz { Egy nev, mely barhol hasznalhato, ahol adatfogadasi jogot kell megnevezni, de akar az egy m}uvelettel egyszerre tobb portrol valo adatfogadast is lehet}ove teszi. Egy adott

portra vonatkozoan az osszes adatfogadasi illetve adatkuldesi jog neve ugyanaz egy adott portnev rendszeren belul. Emellett az osszes { akar ugyanarra a portra vonatkozo { egyszeri adatkuldesi jognak egyedi neve lesz, mely nev meg a portra vonatkozo adatkuldesi illetve adatfogadasi jogokat megnevez}o nevt}ol is kulonbozni fog. A port hozzaferesi jogok manipulalasa mellett lehet}oseg van a port nevek manipulalasara is. A portneveken a kovetkez}o m}uveleteket vegezhetjuk: U j nevet hozhatunk letre (egy uj hozzaferesi jog letrehozasaval). Egy mar meglev}o portnevet megsz}untethetunk. Egy portot atnevezhetunk (nevenek megvaltoztatasaval) Lehet}oseg van annak lekerdezesere, hogy egy portnev mogott milyen tpusu hozzaferesi joggal rendelkezik a taszk. A kernel { a portra vonatkozo tetsz}oleges jog birtokosanak, ha az korabban kerte { tud gyelmeztet}o uzenetet kuldeni olyan esetben, ha a nev valamilyen oknal fogva

"hasznalhatatlanna valik" (peldaul azert, mert az adott portot atneveztek). Mivel a portnevek rendszere egy taszkhoz kotott er}oforras, ezert ezeket csak a tartalmazo taszkkal egyutt hozhatjuk letre, illetve szuntethetjuk meg. 3.11 Porthalmazok A porthalmaz portoknak egy olyan halmaza, ami uzenetfogadas tekinteteben egy egysegkent viselkedik. Egy uzenetfogado mach msg() m}uveletet kiadhatunk vagy egy adatfogadasi jogot megnevez}o portnevre vonatkozoan, vagy pedig egy porthalmazt megnevez}o nevre vonatkozoan. Egy porthalmaz portokra vonatkozo adatfogadasi tpusu hozzaferesi jogokat tartalmaz: ha egy porthalmazra vonatkozoan hajtunk vegre egy adatfogadasi m}uveletet, akkor a porthalmaz valamely portjarol fogunk egy uzenetet fogadni, es a fogadott uzenet fejleceb}ol tudhatjuk meg azt, hogy a porthalmaz melyik elemer}ol olvastuk be az adott uzenetet. Nem megengedett olyan portrol kozvetlenul uzenetet olvasni, amely port benne

van egy porthalmazban. A porthalmaz elemeinek nem lehet uzenetfogadasi tekintetben prioritast adni (vagyis a kernel teljesen szabadon valaszthatja ki azt, hogy a porthalmaz mely elemer}ol olvas be egy uzenetet). A porthalmazokon a kovetkez}o m}uveleteket vegezhetjuk: 46 Letrehozas es megszuntetes. Elemeinek modostasa (port porthalmazba rakasa illetve onnan torten}o kivetele) valamint a benne lev}o portokrol informacio kerese. 3.12 Virtualis cmtartomany Egy taszk virtualis cmtartomanya hatarozza meg azon virtualis cmek halmazat, amelyekre az adott virtualis cmtartomanyt birtoklo taszkban lev}o threadek hivatkozhatnak. Egy virtualis cmtartomanyra az }ot tartalmazo taszk nevevel hivatkozhatunk. A virtualis cmtartomany memorialapok veges szamu megsorszamozott halmazabol all. Az egyes lapok attributumai tetszes szerint modosthatoak, es a kernel a hatekonyabb eleres erdekeben a memoriaban egymast kovet}o

azonos attributumu memorialapokat un. memoriaregiokba szervezi A kernel szabadon osszekapcsolhat illetve szetbonthat memoriaregiokat a memoriahozzafereseket altalaban nem zavarja az, ha egy m}uvelettel nem csak egy region belul probalunk manipulalni. Amikor egy taszk letrehoz egy uj memoriareszt a virtualis cmtartomanyaban, akkor meg kell adni egy absztrakt memoria objektumot, amely az ujonnan letrehozott memoriareszhez valo hozzaferes szemantikajat hatarozza meg (az adott szemantikat biztosto memoriakezel}o taszkkal egyutt). Egy uj virtualis cmtartomany objektumot az }ot tartalmazo taszkkal egyutt hozhatunk letre illetve sz}untethetunk meg. Az ujonnan letrehozott taszk cmtartomanyanak tartalmat az uj taszkokat letrehozo (task create() nev}u) fuggvenyhvas argumentumain keresztul hatarozhatjuk meg, valamint a taszk letrehozasakor megadott minta-taszk memoriaregioinak az oroklesi informacioi alapjan.

A virtualis cmtartomanyon vegezhet}o m}uveletek legtobbjeben egy, a cmtartomanyon belul elhelyezked}o, memoriareszt kell kijelolni. A virtualis cmtartomanyokon a kovetkez}o m}uveletek vegezhet}ok: Egy memoriaregio letrehozasa es megsz}untetese. Egy memoriaregio masolasa. Bizonyos attributumok bealltasa (tobbek kozt ilyen attributum a lap zikai memoriaba "drotozasa", mellyel meg lehet akadalyozni a lap kilapozasat). Memoriavedelmi attributumok bealltasa. Memoriaregiok { ujonnan letrehozott taszkokba valo { oroklesi jellemz}oinek bealltasa. 47 Memoriaregiok kozvetlen olvasasa es rasa. Memoriaregioknak a memoriakezel}o altal a hattertarra valo visszarasa. Egy adott memoriaresz lefoglalasa (ezzel az adott memoriaregion beluli { veletlenszer}u, a Mach kernel altal "talalomra" torten}o { lefoglalasokat sz}untethetjuk meg). 3.13 Absztrakt memoria objektumok A Mach

kernel lehet}ove teszi felhasznaloi uzemmodban futo taszkok szamara, hogy memoriareszekre valo hivatkozasok szemantikajat biztostsak. Ezt ugy teszi lehet}ove, hogy denialtat egy absztrakt memoria objektumot (az azt megnevez}o portot), amely a megfelel}o memoriaresz nem rezidens allapotat reprezentalja. Az e memoria objektumot szolgaltato taszkot nevezik memoriakezel}onek (vagyis azt a taszkot, amely az absztrakt memoria objektum portjara kuldott uzeneteket feldolgozza, es megteszi a szukseges valaszlepeseket). A kernel a kozponti memoriat (ami RAM CHIP-ek formajaban a gepbe van eptve) a kulonfele memoriaobjektumok tartalmanak cache-jekent kezeli. A kernel a memoriakezel}okkel egy aszinkron kommunikacios kapcsolatban van e cache kezelese erdekeben { szukseg eseten behoz es kivisz lapokat a cache-b}ol az absztrakt memoria objektumot megnevez}o portra kuldott uzenetek segtsegevel. Az absztrakt memoria objektumokon

a kovetkez}o m}uveletek vegezhet}oek: Inicializalas. Lap beolvasasa az absztrakt memoreia objektum mogotti hattertarrol a memoria cache-be. Lap kirasa. Lapok tartalmanak szinkronizalasa a hattertaron valo aktualizalassal. Engedely kerese egy lap eleresere. Megsz}untetes. 3.14 Memoriaobjektum reprezentatva A kernel az absztrakt memoria objektum porton keresztul manipulalhatja a memoria objektum mogott lev}o adatokat. E kernel es a memoriakezel}o kozott folyo parbeszed altalaban nem nyilvanos: az absztrakt memoria objektum portjahoz a kernelen kvul mas taszknak nem biztostjak a hozzaferest. Ehelyett a tobbi taszk egy un memoria objektum reprezentatvat kap A memoria objektum reprezentatva a memoria objektumot a kliensek fele reprezentalo objektum. Egyetlen m}uvelet megengedett rajta: a mogotte lev}o 48 memoriaobjektumnak a kliens taszk virtualis cmtartomanyaba agyazasa. Egy ilyen m}uvelet

vegrehajtasanak hatasara a kliens taszkot futtato host kernelje inicializaltatja az absztrakt memoria objektumot az absztrakt memoria objektum porton keresztul (ennek hatasara egy tobblepeses m}uveletsorozat kezd}odik, melynek a "koreograaja" (a kernel-memoriakezel}o kapcsolatot lero protokoll) a Mach kernel referencia kezikonyveben van dokumentalva). 3.15 Memoria cache objektum A kozponti memorianak azt a reszet, amely az absztrakt memoria objektumok rezidens allapotat tartalmazza, memoria cache objektumnak nevezik. Egy memoria objektum memoria kezel}o taszkja uzenetkuldesi joggal rendelkezik a kernel megfelel}o memoria cache objektumahoz. A memoriakezel}o aszinkron kommunikacios kapcsolatban van a Mach kernellel, hogy az absztrakt memoria objektum absztrakcioit biztostsa a megfelel}o memoria cache objektumnak kuldott uzenetek segtsegevel. A memoria cache objektumokon vegezhet}o m}uveletek a kovetkez}ok:

Kulonfele m}ukodesi attributumok bealltasa es modostasa. Kulonfele attributumertekek lekerdezese. A szukseges memorialapok biztostasa a kernelnek. Annak jelzese, hogy a kernel altal igenyelt memorialapok nem allnak rendelkezesre. Annak kerese, hogy a kernel altal igenyelt memorialapok a kernel alapertelmezes szerinti memoriakezel}oje altal denialt modon tolt}odjenek fel. Az objektum kesleltetett masolasanak azonnali vegrehajtasanak kerese. Annak jelzese, hogy a memoriakezel}onek visszakuldott lapokat a kernel "eldobta", azaz a kernel nem rendelkezik bel}oluk sajat peldannyal. Memorialapokhoz valo hozzaferes korlatozasa. A memoriakezel}o futasanak lealltasa. 3.16 Processzorok Minden processzor, mely kepes threadek futtatasara, egy un. processzor vezerl}o porttal azonosthato (illetve nevezhet}o meg). Igaz, hogy a processzorok vegzik a gepi kodu utastasok vegrehajtasat, de a

processzorok onmagukban nem olyan lenyeges absztrakcios eszkozok a Mach modelljeben, altalaban csak processzorhalmazok elemeikent szoktuk kezelni }oket. A processzorhalmaz az az objektum, amely processzorok halmazabol all, es ez vegzi a processzorhalmazra bzott 49 threadek vegrehajtasat, es rajuk vonatkozoan kulonfele utemezesi attributumok allthatoak be. A processzorokon ertelmezett m}uveletek a kovetkez}ok: Egy processzorhalmazba valo berakas. A gep vezerlese (pl. elindtasa es lealltasa) 3.17 Processzorhalmazok A processzorok processzorhalmazokba vannak szervezve. A processzorhalmaz elemei felel}osek a processzorhalmazra bzott threadek vegrehajtasaert, es ez az absztrakcio teszi lehet}ove gepi thread-utemezesi jellemz}ok bealltasat. A processzorhalmazokon a kovetkez}o m}uveletek vegezhet}oek: Processzorhalmaz letrehozasa es megsz}untetese. Processzorok bevitele egy processzorhalmazba. Threadek es taszkok

processzorhalmazhoz torten}o hozzarendelese. U temezes vezerlese. 3.18 Host objektumok A hostokat { vagyis az egyes szamtogepeket { egy un. hostnev porttal azonosthatjuk, amely nem hasznalhato a host egyes attributumainak manipulalasara, gy a terjeszteset nem szokas korlatozni. Ezenkvul van egy hostvezerl}o port, amely a mogotte lev}o host manipulaciojat is lehet}ove teszi, gy altalaban csak bizonyos privilegizalt taszkok rendelkeznek vele (persze tetsz}oleges taszk elhet a hostvezerl}o port nyujtotta lehet}osegekkel, ha valamely mas taszktol hozzajut a hostvezerl}o portra vonatkozo adatkuldes jogahoz). A host objektumon a kovetkez}o m}uveleteket vegezhetjuk: Porthozzaferesi jogokat szerezhetunk az ora objektumokhoz. Rendszerstatisztikai informaciokat nyerhetunk bel}oluk. Rendszerujraindtast vegezhetunk. Beallthatjuk az alapertelmezes szerint hasznalando memoriakezel}ot. Hozzajuthatunk a processzorok

ill. a processzorhalmazok listajahoz 50 3.19 Csomopontok A ltalaban a Mach kernel egyetlen { esetleg tobbprocesszoros { szamtogepen fut. Ezek a hostok kulonfele felhasznaloi uzemmodban futo taszkokon keresztul kommunikalhatnak egymassal. A Mach kernel legujabb kserleti valtozataiban mar kernel szinten lehet}oseg van osztott eleres}u memoriaval nem rendelkez}o gepek transzparens osszekapcsolasara. Ilyenkor minden egyes host kulon csomopont objektumnak tekintend}o, es kulon-kulon csomopontazonostoval rendelkezik. A Mach multicomputer kiegesztese transzparens elosztott memoriat (DSM, distributed shared memory) biztost az egyes csomopontok kozott, es a rendszer a kommunikacios portok transzparenciajat is kepes biztostani akar tobb csomopont kozott is. A csomopontokon egyetlen m}uvelet megengedett: nehany csomopontspecikus port bealltasa es lekerdezese. 3.20 O ra objektumok Egy ora az id}o

mulasat reprezentalja olymodon, hogy allando id}okozonkent inkremental egy-egy szamlalot. Minden host (multicomputereken minden csomopont) a sajat hardver adottsagainak megfelel}o orakat implemental, valamint implementalnia kell nehany absztrakt orat (amely mogott termeszetesen lehet valamilyen hardver uton biztostott ora is). A rendelkezesre allo ora objektumok szamat a rendszer konguralasakor kell rogzteni. Minden orahoz ket port tartozik: egy oranev port, valamint egy oravezerl}o port. Az oravezerl}o port segtsegevel allthatjuk be egy-egy ora parametereit (felbontasat es aktualis allasat). Az oranev porttal a kovetkez}o m}uveletek vegezhet}ok: Lekerdezhet}o az ora allasa es felbontasa. Generalhato egy absztrakt memoria objektum, melynek aktualis erteket (az ora pillanatnyi allasat) beagyazhatjuk a processz memoriacmtartomanyaba. Egy processz passzivan varakozhat egy bizonyos id}opontig.

Figyelmeztetes kerhet}o egy megadott id}o eltelte utan. 3.21 Kernel periferiak A Mach kernel egy nagyon egyszer}u interfeszt biztost a periferiakat kezel}o device driverek fele: rendszerindtas (rendszerbetoltes) utan a kernel inicializalo lepeseinek reszekent felept egy periferia-tablazatot, melyben az osszes, a rendszerbe kapcsolt periferia fel van sorolva. Egyetlen portot, az un device master portot hoz nyilvanossagra (melyhez csak privilegizalt taszkok ferhetnek 51 hozza). E portra kuldott uzenetek segtsegevel allokalhatunk periferiakat, nyerhetunk hozzaferesi jogot periferiakhoz Az a taszk, amely adatkuldesi joggal rendelkezik e portra vonatkozoan, kerheti a kernelt}ol egy tetsz}oleges periferia "megnyitasat", mely kerelemre valaszul a kernel visszaad egy portot, melyen keresztul az adott periferiahoz hozzaferhetunk, amg azt valaki le nem zarja. A periferiakon a kovetkez}o m}uveletek

vegezhet}ok: Tartalmanak olvasasa es rasa. A periferia allapotanak lekerdezese es bealltasa. Specialis celu (eszkozfugg}o) m}uveletek vegrehajtasa. Egy felhasznaloi taszk es a periferia kezel}o kernel modul altal kozosen hasznalt memoriaresz letrehozasa a hatekonyabb periferiaeleres erdekeben. Megjegyezzuk, hogy ilyen esetekben a Mach kernel nem gondoskodik a memoriaterulet bedrotozasarol, vagyis ezek a lapok kilapozhatok, ha nem gondoskodunk az ellenkez}ojer}ol. 52 4 A Mach feletti szerverek Ebben a fejezetben roviden lerom azokat az ismereteket, amikre egy Machalapu szerver elkesztesekor szukseg lehet (illetve szukseg lehet barmilyen Mach kernel szolgaltatasokat hasznalo taszk megrasakor { fuggetlenul attol, hogy az adott taszk nyujt-e szolgaltatasokat a tobbi taszk vagy a Mach kernel szamara11 vagy sem). A Mach kernel es a ra epul}o rendszerek strukturaja a kliens-szerver modell elveit

koveti: biztostja a taszk objektumok letrehozasat, valamint azokban kulonfele mas er}oforrasok letrehozasat, valamint a szamtogep hardver elemeihez valo ellen}orzott hozzaferest ezen kvul pedig lehet}ove teszi a taszkok egymas kozti, valamint a Mach kernellel torten}o kommunikaciojat. A Mach kernel altal biztostott kommunikacios rendszer lehet}ove teszi mind a szinkron, mind pedig az aszinkron kommunikaciot barmely ket resztvev}o kozott, gy lehet}oseg van a tavoli eljarashvas hatekony implementalasara, es a Mach kommunikacios rendszerenek ugyes alkalmazasavala szerverek konnyen konstrualhatok az objektumorientalt programozas lozoajat kovet}o elvek szerint. Az objektum-orientalt elvek alapjan m}ukod}o szerverek kesztesere a Mach kernel alabbi ket fontos lehet}oseget lehet kihasznalni: Egy adott porthoz a ra vonatkozo adatkuldesi jogokat illetve adatolvasasi jogokat azonos neven nevezi a

rendszer (legalabbis egy adott taszkon belul). Tobb kulonboz}o portra vonatkozo olvasasi jog egy olvasasi jogok halmazakent is kezelhet}o, es egy ilyen osszetett objektumrol egy uzenetet beolvasva megtudhato az, hogy melyik komponensre (melyik objektumra) vonatkozoan kuldtek az adott uzenetet. A masodik lehet}oseget kihasznalva a port hozzaferesi jogok neve hasznalhato a szerver altal kezelt objektumok megnevezesere { peldaul a port neve lehet a "mogotte lev}o" (vagyis az altala megnevezett) objektum memoriabeli cme, es ekkor a Mach kernel a fenti lehet}osegevel automatikusan biztostja a szervernek a kezelt objektumai es az objektum mamoriabeli cme kozti kolcsonosen egyertelm}u megfeleltetest. Az els}o lehet}oseget kihasznalva pedig objektumreferenciak adhatok at akar taszkok kozott is A Mach ezen kvul hatekony adatatvitelt biztost ugyes memoriakezelesi technikakkal (a korabban mar emltett

copy-on-write optimalizalassal { ld. 23 pontot). Ezenkvul meg kell emlteni azt is, hogy a Mach kommunikacios rendszere altal nyujtott mechanizmusok halozat-transzparensek, konnyen kiterjeszthet}ok felhasznaloi uzemmodban futo taszkok segtsegevel akar egy sok szamtogepb}ol allo halozatra is. 11 Emlekezz unk ra, hogy a Mach kernel szamara is nyujthatnak bizonyos kuls}o memoriakezel}o taszkok szolgaltatasokat. 53 A kommunikaciot vegz}o Mach rendszerhvasokat kozvetlenul persze nagyon ritkan hasznaljak a programozok: ehelyett a Mach kornyezet biztost egy tavoli eljarashvasi konyvtarcsomagot, amiben elkesztve a tavoli eljarasok specikaciojat, egy MIG (Mach Interface Generator) nev}u programmal lehet a kommunikacioert felel}os programreszeket automatikusan generaltatni. A MIG egy szerver altal biztostott m}uveletek osszessegenek specikaciojabol (beleertve az egyes m}uveletek argumentum-tpusainak

specikalasat is) generalja a C nyelv}u Mach kommunikacios fuggvenyeket a MIG nem biztostja az osszes olyan szolgaltatast, amiket mas tavoli eljarashvasi csomagoknal esetleg megszokhattunk (mint peldaul interfesz tobbfele programozasi nyelvhez, vagy a visszahvast is tamogato tavoli eljarashvast { ld. ODRI93],ODARPCS94]) Ennek az az oka, hogy a MIG kornyezetnek nincs egy olyan segedprogramja, amely ezeknek a feladatoknak a megoldasaban a rendszert segtene, es a generalt C programok sem tartalmaznak csatlakozast hasonlo celu kuls}o eljarasok fele. A Mach feletti szerverek altalaban egy vegtelen-ciklus kore epulnek: ciklusban beolvasnak (fogadnak) egy-egy uzenetet, es feldolgozzak azt, majd valaszolnak az uzenet kuld}ojenek (ha ez szukseges). A MIG-gel az uzenetek beolvasasat es a valasz elkuldeset vegz}o eljarasok elkesztese automatizalhato, az uzenetek feldolgozasat vegz}o eljarast a

programozonak kell megrnia. Egy szerver elkesztesehez tehat a kovetkez}o lepeseket kell megtenni: Specikalni kell a szerver altal nyujtott m}uveleteket (ezzel egyben specikaljuk a szerver szamara kuldhet}o uzenetek formatumat), es e specikaciokat felhasznalva a MIG-gel el kell keszttetni a kommunikaciot megvalosto eljarasokat (vagy "kezzel" kell }oket kodolni). Implementalni kell a szolgaltatasokat tenylegesen megvalosto eljarasokat (amik a MIG altal generalt eljarasokbol lesznek meghvva). Meg kell rni a szerver inicializalasat vegz}o kodreszeket, letre kell hozni bennuk az alapertelmezes szerint allandoan elerhet}o eljarasokat, es meg kell rni az uzenetfeldolgozo ciklust. Ahhoz, hogy egy szervert a kliens taszkok elerjenek, valamilyen modon informalni kell a klienst arrol, hogy a szerver hogyan erhet}o el. Erre valo a n
ev-szolg
altat
o (Name Server), aminek a m}ukodeser}ol rovidesen

szo lesz. Egy szerver elkeszthet}o ugy is, hogy egyidej}uleg csak egy klienst kepes kiszolgalni, illetve ugy is, hogy egyidej}uleg tobb klienst is kepes legyen kiszolgalni { ez utobbi esetben az egyes kliensek kiszolgalasara kulon-kulon egy-egy programvegrehajtasi pontot (threadet) szokas igenybe venni, vagy keszthet}o akar egy esemenyvezerelt m}ukodes}u, egyetlen threadet hasznalo, de egyidej}uleg akar tobb kliens kiszolgalasara is kepes szerver program (ez utobbi esetben azonban ugyelni kell arra, hogy ne specikaljunk olyan esemenyeket, amelyek kiszolgalasa tulsagosan hosszu id}ot vehet igenybe, mert akkor akar egyetlen kliens is monopolizalhatna a szervert, kizarva a tobbi klienst). 54 4.1 Nev-szolgaltatok szerepe A Mach mikrokernelen futo taszkok altal elerhet}o portok szama a taszk elindulasakor nagyon keves. Egy taszk indulasakor lekerdezheti a sajat magat mint objektumot reprezentalo port nevet, a

threadjeinek mint objektumoknak az azonosto portjait, a szamtogepet reprezentalo host objektumot reprezentalo portot. Ezenkvul egy Mach taszk hozzafer nehany specialis celu porthoz (ezek a bootstrap port valamint a kivetelkezel}o port, ahol az el}obbit altalaban a taszk m}ukodeset felugyel}o szerverrel valo kapcsolattartas celjabol hasznaljak { mar amennyiben van ilyen szerver, mg az utobbit a taszkkal kapcsolatos kiveteles esemenyek kezelesere hasznalhatjuk). Ezeken kvul egy taszk eleri indulasakor az un. regisztralt portjait, amelyek egyeb szolgaltatasokat nyujto szerverek neveit tartalmazhatjak (altalaban egy szervert a neki valo adatkuldesi jog "nevez meg"). Ezek kozott a regisztralt portok kozott nagyon fontos a nev-szolgaltato (Name Server) szervert megnevez}o port. Ez a szerver biztostja a szervernevek alapjan a megfelel}o szerverhez valo uzenetkuldesi jog elereset a taszk szamara. A

Mach kernelhez sokfele nev-szolgaltato keszthet}o, sokfele nev-szolgaltatot kesztettek ilyen tekintetben nincs elfogadott szabvany. A nev-szolgaltatokat gyakran az altaluk tamogatott operacios rendszer igenyeinek megfelel}oen alaktjak ki. Termeszetesen tobb nev-szolgaltato is lehet a rendszerben, es altalaban minden egyes operacios rendszer szerver a sajat szuksegeinek megfelel}o nevszolgaltatot hasznalhat. A nev-szolgaltatok leggyakoribb alkalmazasa a Mach kernel feletti operacios rendszer szervereknel a rendszer objektumainak es az }oket reprezentalo portok osszekapcsolasat tartalmazo adatbazisban nyilvantartasi feladatainak az ellatasa. A kovetkez}o pontban arrol rok reszletesebben, hogy a 4. pontban emltett, Mach folyamatok kozotti kommunikaciojanak az alapelveit kihasznalva hogyan lehet objektum-orientalt szemlelet}u szervereket keszteni. 4.2 Objektum-orientalt szerverek kesztese A Mach

folyamatok kozotti kommunikacios eszkozei lehet}ove teszik elosztott rendszerek objektum-orientalt tervezeset es implementalasat a port hozzaferesi jogok kovetkez}okeppen torten}o hasznalataval: egy-egy objektumot egy-egy port reprezentalhat, az objektumnak kuldott uzeneteket pedig az objektumot reprezentalo portnak kuldott uzenetek modellezhetik. A 4 pontban emltett alapelveket kihasznalva az objektumot reprezentalo portokra vonatkozo adatkuldesi jog hasznalhato a kliens alkalmazasokban (valamint erteket "otletesen megvalasztva" magaban a szerverben is) objektum-hivatkozaskent. Az otletes megvalasztason peldaul azt ertem, hogy a port nevet az altala reprezentalt objektum memoriabeli cmere alltva a szerver a kapott port hozzaferesi jog alapjan egyszer}uen (a portnev alapjan) meghatarozhatja a port 55 altal reprezentalt objektum memoriabeli helyet. Az objektumokat reprezentalo portokra erkezett

uzeneteket egy-egy, a portrol kereseket fogado thread dolgozhatja fel amennyiben a threadek szamat minimalizalni kell, akkor { lenyegeben hatekonysag-csokkenes nelkul { az objektumot reprezentalo portokat porthalmazba szervezve csak a port-halmazokrol olvaso joval kevesebb (akar egy is eleg) threadet kell letrehozni es kezelni. Mivel az objektum-hivatkozasokat port hozzaferesi jogkent taroljuk { legalabbis ebben a modellben {, es mert a Mach nyilvantartja azt, hogy van-e meg el}o adatkuldesi jog egy adott portra vonatkozoan, ezert a szemetgy}ujtes (a mar nem hasznalt objektumok es a reprezentalo portjuk "kitakartasa") a Mach eszkozeivel konnyen megvalosthato. 4.3 Pelda egy Mach szerverre Ebben az alfejezetben bemutatom egy Mach alapu szerver szerkezetet, felepteset. A szerver egy egyszer}u nev-szolgaltato feladatat kepes ellatni: numerikus egesz konstansokhoz kepes egy-egy port hozzaferesi jogot

asszocialni ket szolgaltatasa van: az egyik az asszociacios tablazatanak egy uj asszociacioval valo b}ovtese, valamintegy egesz konstanshoz asszocialt port hozzaferesi joganak a lekerdezese. Ez a nev-szolgaltato nem vegez semmifele lekerdezes-jogosultsag ellen}orzest: ez arra hasznalhato, hogy az alkalmazasok hozzaferhessenek mas szerverek azon portjaihoz, amelyen keresztul az adott szerverrel fel tudja venni a kapcsolatot (a kliens es a kivalasztott szerver kapcsolatanak protokollja mar a kett}ojuk belugyenek tekinthet}o). E szerver masik haszna az, hogy egyszer}usege miatt tanulmanyozhatjuk rajta a Mach altal biztostott szerverkesztesi eszkozoket. 4.31 A peldaszerver specikacioja A peldaszerver neve machid legyen { a Mach operacios rendszerben lev}o hasonlo celu szerver alapjan. A szerver specikaciojat a MIG szerverspecikacios nyelv segtsegevel kell megadni (a MIG nyelv reszletes specikaciojat,

nyelvtanat lasd OSF92]-ben vagy a mig(1) online referencia kezikonyv lapon azokon a helyeken, ahol ez megvan { itt csak a peldaprogram m}ukodesenek a megertesehez szukseges informaciokat fogom lerni ezek alapjan az informaciok alapjan, valamint az el}obb emltett referencia-kezikonyvekkel a MIG hasznalata nem okozhat problemat). Egy szerver MIG specikacios fajlja a kovetkez}o f}o reszekb}ol all: A szerver altal biztostott alrendszer nevenek megadasa. A szerver demultiplexalo eljaras nevenek a specikacioja (ez elhagyhato, ha az alapertelmezes szerinti, a MIG altal generalt neven lev}o eljaras megfelel a celjainknak). 56 Tpusspecikaciok (ha a szerver szolgaltatasainak a specikalasanal szuksegunk van ujabb, nem a C-b}ol szarmazo adattpusokra). A szerver altal nyujtott szolgaltatasok specikacioja. A szerver altal biztostott alrendszer nevenek megadasa a MIG nyelv nev}u utastasaval12

tortenhet. Ennek szintaxisa a kovetkez}o: subsystem subsystem sys message-base-id Ahol sys a szerver altal biztostott alrendszer neve. Ez a nev a MIG altal generalt C nyelv}u fuggvenyek nevenek az elejare lesz rakva prexkent. Megjegyezzuk, hogy amennyiben a generalt kliens illetve szerver csonkban nem ezt a nevet akarjuk eljarasnev prexkent hasznalni, akkor rendelkezesre allnak a serverprefix illetve a userprefix utast asok (egyetlen argumentummal, a prex nevevel) a generalt szerver illetve a kliens csonk eljarasainak a neve ele rt prexek kijelolesere. A message-base-id pedig egy 32-bites egesz szam kell legyen. A MIG altal generalt szerver szolgaltatasai egy Mach portra egy megfelel}o uzenet elkuldesevel lesznek elerhet}oek, amely uzenet kell, hogy tartalmazza az igenybeveend}o szolgaltatas azonostojat (ami egy egesz szam lehet). Az itt megadott szammal kezd}od}oen lesznek a szerver szolgaltatasok (ezek a MIG

specikacioban specikalt eljarasok) megsorszamozva, az eljarassorszamok egyesevel novekednek. Ennek a szamnak tobb gyakorlati jelent}osege nincs. A szerver demultiplexalo eljaras nevenek a specikacioja a kovetkez}o utastassal tortenhet: serverdemux id Ahol id a MIG altal generalt uzenet-demultiplexalo eljarasnak a neve. Ez az az eljaras, amelyet majd kes}obb a mach msg server eljarasnak meg kell adni mint a kapott uzenetek feldolgozasaert felel}os eljarast: ennek az eljarasnak a feladata lesz a bejov}o uzenet alapjan a megfelel}o (meghvando) szerver eljaras kivalasztva. A tpusspecikacios utastas alakja a kovetkez}o: type typename = type description Ahol typename az uj (az utastasban denialt) tpus neve, az egyenl}oseg utan pedig a tpus felepteset kell megadni. A tpusfeleptes specikaciojanak szintaxisa a C nyelvehez hasonlo, ezzel reszletesebben nem foglalkozom itt (ld. 12 A MIG nyelvben

az utastasok lezarasara a pontosvessz} o karaktert kell hasznalni, tovabba a MIG speci kacios fajl tartalmazhat C nyelv}u preprocesszor direktivakat is a C-ben megismert szemantikaval. 57 OSF92]-t vagy mig(1)-et a reszletekr}ol). Megjegyezzuk, hogy egy nem szabvanyos C tpusokbol felepul}o adattpus MIG tpusspecikacioja mellett meg kell adni a tpus C nyelv}u specikaciojat is a szokasos C deklaracios szintaxissal (es ezeket a C deklaraciokat a #include-dal megegyez}o szintaxisu import utastassal jelolhetjuk ki). A szerver altal nyujtott szolgaltatasokat azok szignaturajanak specikaciojaval kell megadni: a spcikacios routine kulcsszo utan C-szer}u szintaxissal. Az eljarasok bemen}o parametereinek a neve ele kirhatjuk az in szocskat (de ez az alapertelmezes), a kimen}o parameterek ele ki kell rni az out szocskat a be- es kimen}o parameterek neve ele pedig az in out szocskat. Ezek alapjan mar megnezhetjuk a

machid szerverunk specikaciojat: subsystem machid 4375300 userprefix machid  serverprefix do  #include "mach/std types.defs" #include "machid types.defs" routine register( server : mach port t port : mach port t=MACH MSG TYPE PORT SEND out name: mach id t ) routine lookup( server name out port ) : mach port t : mach id t : mach port t=MACH MSG TYPE COPY SEND Az els}o harom sor szerepe nyilvanvalo. A kovetkez}o ket sor egy-egy C preprocesszor direktiva Az els}o beolvasott fajl a Mach mikrokenel API-janak az alaptpusainak a specikacioit tartalmazza (ez nincs a MIG-be eptve, mivel gepfugg}o). A kovetkez}o sor pedig a machid asszociaciojanak az egesz tpusu ertekenek a tpusat tartalmazo fajlt tolti be, aminek a tartalma a kovetkez}o: #ifndef MACHID TYPES DEFS #define MACHID TYPES DEFS type mach id t=unsigned import "machid types.h" #endif MACHID TYPES DEFS Itt egyreszt specikaltuk a mach id t

tpust el}ojel nelkuli egeszkent, masreszt pedig utastjuk a MIG fordtot, hogy a machid types.h fajlt f}uzze 58 hozza a generalt kliens illetve szerver csonkokhoz { ebben a fajlban C deklaraciok talalhatoak azokhoz az adattpusokhoz, amelyeket az eljarasok szignaturajanak specikalasakor hasznaltunk. A machid szerverunknel e fajl tartalma a kovetkez}o: #ifndef MACHID TYPES H #define MACHID TYPES H typedef unsigned int mach id t #endif MACHID TYPES H A fent bemutatott specikacio tartalmazza meg a machid szerver szolgaltatasainak a szignaturajat, amit a kovetkez}o alpontban ismertetek. 4.32 A peldaszerver szolgaltatasai A peldaszerverunknek ket szolgaltatasa van: a register nev}u, valamint a lookup nev}u. Az el}obbi szolgal egy azonosto-porthozzaferesi jog asszociacio letestesere13  az utobbi szolgal egy azonostohoz tartozo porthoz valo adatkuldesi jog keresere. A register szolgaltatas

specikaciojanak az els}o argumentuma maganak a machid szervernek a kliensek fel e atadott szolgaltatas-hozzaferesi portja lesz (a kliensek ehhez peldaul a regisztralt portokon vagy a Mach mikrokernel altal a taszkok szamara biztostott specialis portokon keresztul ferhetnek hozza), tehat az els}o argumentumban kell megadni egy adatkuldesi jog azonostot a machid szerver portjara. A masodik argumentum egy port hozzaferesi jog, amit egy szamhoz akarunk asszocialni. A harmadik argumentumban adja majd vissza a szerver a masodik argumentumban megadott port hozzaferesi joghoz asszocialt sorszamot. A lookup szolgaltatas els}o argumentuma a machid szerver portjahoz egy adatkuldesi jog kell legyen, a masodik argumentum egy sorszam. A harmadik argumentumban visszakapjuk a masodik argumentumban megadott sorszamhoz asszocialt port hozzaferesi jog egy masolatat. 4.33 A MIG altal generalt fajlok A MIG generator a fenti specikacio

alapjan harom fajlt hoz letre a kovetkez}o tartalommal: machid.h : A kliens  es a szerver csonkok eljarasainak a prototpusat tartalmazzak a szukseges tpusdeklaraciokkal egyutt. 13 A szerver az azonostokat egyesevel osztja ki, gy azt nem adhatja meg a kliens, hogy az altala regisztralando port milyen azonostohoz legyen asszocialva { egyszer}uen azert, mert ott, ahol egy ilyen primitv nev-szolgaltatot hasznalnak, gyakran meg a szamok kiosztasanak koordinaciojara sincs lehet}oseg 59 : A specikalt szolgaltatas kliens csonkjanak az implementaciojat tartalmazza. machidServer.c : A specik alt szolgaltatas szerver csonkjanak az implementaciojat tartalmazza. machidUser.c Fontos, hogy kezzel ne szerkesszuk ezeket az eljarasokat, ha meg ujra akarjuk generaltatni }oket a MIG-gel, mert a kezzel utolag vegzett modostasok elvesznek. A machid.h fajl szerkezete a kovetkez}o (itt egy fajlkivonatot fogok bemutatni a szamunkra erdekes

reszekkel): . header-fajlok extern kern return t machid register ( mach port t server, mach port t port, mach msg type name t portPoly, mach id t *name ) . hasonlo prototipus a machid lookup() szolgaltatashoz A kliens csonk szerkezete a kovetkez}o: . deklaraciok . header-fajlok kern return t machid register ( mach port t server, mach port t port, mach msg type name t portPoly, mach id t *name ) { /* A / typedef struct { mach msg header t Head mach msg type t portType mach port t port } Request 60 /* B / typedef struct { mach msg header t Head mach msg type t RetCodeType kern return t RetCode mach msg type t nameType mach id t name } Reply /* C / union { Request In Reply Out } Mess register Request *InP = &Mess.In register Reply *OutP = &Mess.Out mach msg return t msg result boolean t msgh simple = TRUE /* D / static const mach msg type t portType = { /* msgt name = / -1, /* msgt size = / 32, /* msgt number = / 1, /* msgt inline = / TRUE, /* msgt

longform = / FALSE, /* msgt deallocate = / FALSE, /* msgt unused = / 0 } /* E / InP->portType = portType InP->port = port if (MACH MSG TYPE PORT ANY(portPoly)) msgh simple = FALSE InP->portType.msgt name = portPoly InP->Head.msgh bits = msgh simple ? MACH MSGH BITS(19, MACH MSG TYPE MAKE SEND ONCE) : 61 (MACH MSGH BITS COMPLEX| MACH MSGH BITS(19, MACH MSG TYPE MAKE SEND ONCE)) InP->Head.msgh request port = server InP->Head.msgh reply port = mig get reply port() InP->Head.msgh seqno = 0 InP->Head.msgh id = 4375300 /* F / msg result = mach msg(&InP->Head, MACH SEND MSG|MACH RCV MSG| MACH MSG OPTION NONE, 32, sizeof(Reply), InP->Head.msgh reply port, MACH MSG TIMEOUT NONE, MACH PORT NULL) if (msg result != MACH MSG SUCCESS) { if ((msg result == MACH SEND INVALID REPLY) || (msg result == MACH SEND INVALID MEMORY) || (msg result == MACH SEND INVALID RIGHT) || (msg result == MACH SEND INVALID TYPE) || (msg result == MACH SEND MSG TOO SMALL)

|| (msg result == MACH RCV INVALID NAME)) mig dealloc reply port(InP->Head.msgh reply port) else mig put reply port(InP->Head.msgh reply port) return msg result } mig put reply port(InP->Head.msgh reply port) /* G / if (OutP->Head.msgh id != 4375400) { if (OutP->Head.msgh id == MACH NOTIFY SEND ONCE) return MIG SERVER DIED else return MIG REPLY MISMATCH } /* H / *name = OutP->name return KERN SUCCESS } . hasonlo eljaras a machid lookup() szolgaltatashoz A fenti kliens csonk eljaras tobb lepesben vegzi el a feladatat. Most attekintjuk az egyes lepeseket (a kodban kommentekkel specikalt helyekre hi62 vatkozva): : A szervernek kuldott keres uzenet szerkezetet deklaralja. B : A szervert} ol vart valasz uzenet szerkezetet deklaralja. C : Deni al egy adattpust a keres es a valasz uzenet tpusanak uniojakent, es deklaral ket valtozot: az egyiket az elkuldend}o uzenet tarolasara, a masikat a fogadott uzenet

tarolasara. D : A szervernek k uldend}o uzenetben elkuldend}o port abrazolasi formatumat deklaralja (ld. OSF92r]-t) E : A szervernek k uldend}o uzenetet belerakja az elkuldend}o uzenetet tartalmazo valtozoba (ld. OSF92r]-t), megjelolve azt is, hogy mely sorszamu (a peldaban ez 4375300) szerver-szolgaltatast akarja igenybe venni. F : A szervernek elk uldi az uzenetet. G : Ellen} orzi, hogy a kapott uzenet a valaszuzenet-e vagy sem. H : A hv o szamara elerhet}ove teszi az eredmenyeket, majd visszater a hvohoz. A A szerver csonk szerkezete a kovetkez}o: . deklaraciok . header-fajlok void Xregister (mach msg header t *InHeadP, mach msg header t OutHeadP) { /* A / typedef struct { mach msg header t Head mach msg type t portType mach port t port } Request typedef struct { mach msg header t Head mach msg type t RetCodeType kern return t RetCode mach msg type t nameType mach id t name } Reply 63 register Request *In0P = (Request

) InHeadP register Reply *OutP = (Reply ) OutHeadP /* B / extern kern return t do register (mach port t server, mach port t port, mach id t *name) static const mach msg type t nameType = { /* msgt name = / 2, /* msgt size = / 32, /* msgt number = / 1, /* msgt inline = / TRUE, /* msgt longform = / FALSE, /* msgt deallocate = / FALSE, /* msgt unused = / 0 } /* C / OutP->RetCode = do register(In0P->Head.msgh request port, In0P->port, &OutP->name) if (OutP->RetCode != KERN SUCCESS) return OutP->Head.msgh size = 40 OutP->nameType = nameType } . hasonlo eljaras a lookup szolgaltatashoz /* D / static mig routine t machid server routines] = { Xregister, Xlookup, } mig routine t machid server routine (const mach msg header t *InHeadP) { register int msgh id 64 msgh id = InHeadP->msgh id - 4375300 if ((msgh id > 1) || (msgh id < 0)) return 0 /* E / return machid server routinesmsgh id] } boolean t machid server (mach msg header t

*InHeadP, mach msg header t OutHeadP) { register mach msg header t *InP = InHeadP register mig reply header t *OutP = (mig reply header t ) OutHeadP /* F / static const mach msg type t RetCodeType = { /* msgt name = / MACH MSG TYPE INTEGER 32, /* msgt size = / 32, /* msgt number = / 1, /* msgt inline = / TRUE, /* msgt longform = / FALSE, /* msgt deallocate = / FALSE, /* msgt unused = / 0 } register mig routine t routine OutP->Head.msgh bits = MACH MSGH BITS( MACH MSGH BITS REPLY(InP->msgh bits), 0) OutP->Head.msgh size = sizeof *OutP OutP->Head.msgh remote port = InP->msgh reply port OutP->Head.msgh local port = MACH PORT NULL OutP->Head.msgh seqno = 0 OutP->Head.msgh id = InP->msgh id + 100 OutP->RetCodeType = RetCodeType /* G / if ((InP->msgh id > 4375301) || (InP->msgh id < 4375300) || ((routine = machid server routinesInP->msgh id - 4375300]) == 0)) { return FALSE } /* H / 65 (*routine) (InP, &OutP->Head) return

TRUE } A fenti szerver csonk eljarasok tobb lepesben vegzik el a feladatukat. Most attekintjuk az egyes eljarasokat, es az azok altal elvegzett lenyegesebb lepeseket (a felsorolasban a kodban kommentekkel jelolt helyekre hivatkozva): : A szervernek kuldott keres es a szervet}ol vart valaszuzenet szerkezetet specikalja. B : deklar alja a szerver csonk altal meghvando felhasznaloi eljaras prototpusat (ez az eljaras fogja elvegezni a tenyleges szerver feladatokat). C : Meghvjuk a felhaszn alo altal kijelolt, szerver feladatokat ellato eljarast. D : Az u zenetfeldolgozo eljaras eloszto-tablazataul szolgalo vektort deklaraljuk (ez alapjan hvja meg az uzenetet fogado eljaras a szerver csonkokat). E : A szerver a kapott u zenetben lev}o szolgaltatas-igeny sorszam alapjan itt adja vissza a szolgaltatast nyujto szerver csonk eljaras cmet. F : Itt t ortenik meg a valaszuzenet fejlecenek a

feltoltese. G : Megszerezz unk a kapott uzenet feldolgozasat vegz}o szerver csonk cmet. H : Meghvjuk az u zenet feldolgozasat vegz}o szerver csonkot az uzenettel es a kitoltend}o valasszal mint argumentumokkal. A 4.34 A szerverunk kornyezete Ha azt akarjuk, hogy a szerverunket el tudjak erni a taszkok, akkor a potencialis kliensek szamara elerhet}ove kell tenni a szerverunk portjat { hogy adatot tudjanak ra kuldeni. A szerverunkhoz hozzaferest biztosto portot betesszuk a taszkunk regisztralt portjai koze, gy a kliens taszkok ezeken keresztul hozza tudnak ferni. Az ezt megvalosto kodreszlet a kovetkez}o: kern return t register ports() { kern return t mach port array t u int kret ports ports cnt kret=mach port allocate(mach task self(),MACH PORT RIGHT RECEIVE, &SERVICE PORT) 66 if (kret != KERN SUCCESS) { printf("register ports: Cannot allocate a port. ") printf("register ports: %s ",mach error

string(kret)) return kret } kret=mach port insert right(mach task self(),SERVICE PORT, SERVICE PORT,MACH MSG TYPE MAKE SEND) if (kret!=KERN SUCCESS) { printf("register ports: Cannot acquire send right. ") printf("register ports: %s ",mach error string(kret)) return kret } kret=mach ports lookup(mach task self(),&ports,&ports cnt) if (kret!=KERN SUCCESS) { printf("register ports: Cannot lookup standard ports. ") printf("register ports: %s ",mach error string(kret)) return kret } portsNETNAME SLOT]=SERVICE PORT kret=mach ports register(mach task self(),ports,ports cnt) if (kret!=KERN SUCCESS) { printf("register ports: Cannot register standard ports. ") printf("register ports: %s ",mach error string(kret)) return kret } return kret } A fenti eljaras el}oszor allokal egy portot, amelyen keresztul a kliensek kereseit fogja fogadni, majd az adatfogadasi jog mellett letrehoz hozza egy adatkuldesi

jogot, amin keresztul a kliensek a kereseiket kuldhetik. Ezutan a mach ports lookup() eljarassal lekerdezi a taszk a sajat regisztralt portjainak a halmazat, majd miutan ez megvan, az ujonnan letrehozott portot berakja a regisztralt portok koze a NETNAME SLOT pozciora14, ami a halozat nev-szolgaltatojanak szokott fenntartva lenni (vagyis most ez lesz a halozat nev-szolgaltatoja), majd ezutan modostja a regisztralt portok nyilvantartasat a kernel fele is (csak ezutan oroklik a gyermek-taszkok ezt a portot mint halozati nev-szolgaltato portot). A szerver ezutan vegtelen ciklusban var egy uzenetre es feldolgozza azt. Ezt a kovetkez}okeppen implementalhatjuk: 14 A Mach kornyezete de nialja ezt a konstanst. 67 int rc . rc=mach msg server(machid server,MAX MSG SIZE,SERVICE PORT) A fenti utastas hatasara a szerver csonkot tartalmazo (machidServer.c nev}u) fajl machid server() eljarasa vegtelen ciklusban meg lesz

hvva. A SERVICE PORT portr ol fogja fogadni a kliensekt}ol erkez}o kerelmeket, es minden kerelmet feldolgoz. A masodik argumentum a maximalisan megengedett uzenetmeretet tartalmazza (ld. OSF92r]-t a mach msg server() fuggveny parametereir}ol). Megjegyezzuk, hogy a fenti peldak a kes}obb bemutatasra kerul}o (altalamrt) szerverb}ol szarmaznak. Az ebben az alpontban lev}o kodreszletek a jbss bootstrap reszeb}ol szarmaznak: ez a folyamat tolti be es indtja el a jbss tobbi komponenset (ezert az ez altal elindtott osszes jbss komponens hozzaferhet a halozati nev-szolgaltato porton keresztul a machid szolgaltatashoz). jbss 4.35 Egy kliens a szerverunkhoz A szerverunket hasznalo kliensek ketfele keressel fordulhatnak a szerverhez: egyreszt egy port hozzaferesi jog regisztralasat kerhetik t}ole (ezzel a kerdeses port hozzaferesi jog masok szamara is elerhet}o lesz), masreszt pedig kerhetik egy adott sorszamhoz

asszocialt porthoz valo hozzaferesi jog egy "masolatat". Itt bemutatok egy port regisztralasi eljarast: azt, hogy egy szerver (peldaul egy UNIX-szer}u szerver) hogyan tudja azt a portot regisztraltatni a machid programmal, amely porton keresztul a szolgaltatasait nyujtja. /* A / mach port t SERVICE PORT kern return t register ux task(void) { kern return t rc mach port array t ports int ports count mach port t name port int name /* B / rc=mach port allocate(mach task self(),MACH PORT RIGHT RECEIVE, &SERVICE PORT) if (rc != KERN SUCCESS) { printf("register ux task: Cannot allocate U*X service port. ") 68 printf("register ux task: %s ",mach error string(rc)) return rc } /* C / rc=mach port insert right(mach task self(),SERVICE PORT, SERVICE PORT,MACH MSG TYPE MAKE SEND) if (rc!=KERN SUCCESS) { printf("register ux task: %s ",mach error string(rc)) (void) mach port destroy(mach task self(),SERVICE PORT) return

rc } /* D / rc=mach ports lookup(mach task self(),&ports,&ports count) if (rc!=KERN SUCCESS) { printf("register ux task: BAD port id-s ") (void) mach port destroy(mach task self(),SERVICE PORT) return rc } /* E / name port=portsNETNAME SLOT] /* F / rc=machid register(name port,SERVICE PORT,MACH MSG TYPE MAKE SEND, &name) return rc } A fenti programreszlet a feladatat tobb lepesben oldja meg a kovetkez}okben attekintem ezeket a lepeseket: : Deklaralunk egy port tpusu valtozot, amely valtozo majd azt a portot fogja azonostani, amelyen keresztul a szerver varja a kliensek kereseit. B : Allok aljuk azt a portot, amelyen keresztul a szerver a kliensek kereseit fogja varni. C : L etrehozunk egy adatkuldesi jogot is a portunkra vonatkozoan { hiszen a leend}o klienseinknek ezt kell (es lehet) atadni, ezen keresztul tudjak elerni a szerverunket. D : Lek erdezzuk a taszkunk regisztralt portjait. E : Lek erdezzuk a

regisztralt portok kozul a halozati nev-szolgaltato port nevet (emlekezzunk vissza: ezen keresztul erhetjuk el a machid szervert). A 69 : A machid szervernel regisztraltatunk egy, az el}obb allokalt portunkra vonatkozo adatkuldesi port hozzaferesi jogot, es a name valtozoban visszakapjuk a porthoz asszocialt szamot. Megjegyezzuk, hogy a name valtozo erre az eljarasra nezve lokalis valtozo, ezert tartalma az eljarasbol valo kilepes utan elveszik. Erre a tovabbiakban ezert nincs szukseg { a jbss szerverben {, mert ez a legels}onek regisztralt szerver, gy allandoan a legels}o szabad machid sorszamot, a nullat fogja a machid szerver hozzaasszocialni. Termeszetesen bonyolultabb esetekben erre az informaciora kes}obb meg szukseg lehet, gy meg kell gondolni ennek az eltarolasat. F 70 5 POSIX 1003.1 emulacio a Machon Ebben a fejezetben rok a POSIX 1003.1-konformitas Mach mikrokernel alapu operacios

rendszereken valo megvalosthatosagarol. 5.1 A t
ortenelem A 80-as evekben az operacios rendszerek fejlesztesenek nagyon fontos sznhelyei voltak a kaliforniai Berkeley egyetem (UCB) valamint a pittsburghi Carnegie Mellon University (CMU). A Berkeley egyetemen 1978 elejen kezdtek meg az AT&T Bell Laboratoriumabol szarmazo UNIX V6/V7 operacios rendszerenek a tovabbfejleszteset, melynek eredmenyekeppen letrejott a UNIX Berkeley valtozata a BSD (Berkeley Software Distribution). A Berkeley UNIX fejlesztesere az ARPA (Advanced Research Project Agency) valamint az US DoD (Department of Defense) nagyon sok penzt aldozott egeszen a 4.3BSD kifejleszteseig, amely valtozat ennek az operacios rendszernek talan a legelterjedtebb es legismertebb valtozata. A tamogatast nem kis mertekben annak koszonhette, hogy mindig jol ki tudta hasznalni az akkori csucstechnologiaju eszkozok nyujtotta lehet}osegeket: a sorozatgyartasban

keszul}o, gy nagy peldanyszamban beszerezhet}o VAX-okon ez az operacios rendszer rendelkezett el}oszor lapozasos virtualis memoriakezel}ovel, valamint ez volt az els}o olcso nagy mertekben elterjedt olyan operacios rendszer, amely tartalmazta a TCP/IP halozati kommunikacios protokoll teljes implementaciojat lenyegeben barki szamara elerhet}o modon. A 80-as evek vegen azonban a DoD-nak egy olyan operacios rendszerre volt szuksege, amely optimalisan kepes kihasznalni a (nagysebesseg}u) szamtogepes halozatok nyujtotta lehet}osegeket, es mindemellett biztostja az alkalmazoi programok keszt}oi fele a szukseges transzparenciat. U gy lattak, hogy a DoD igenyeinek a leginkabb a Carnegie Mellon University kutatoi altal kifejlesztett Mach nev}u operacios rendszer felelt meg, amely lenyegeben a Berkeley UNIXnak egy halozat-transzparens kommunikacios eszkozzel valo kib}ovtese, valamint tartalmazza a korabbi

CMU-fejlesztes}u Accent nev}u operacios rendszer fejlesztesenel felmerult jobb otleteket is (peldaul az Accent nagyon hatekony virtualis memoria kezeleset). 1989 a Mach fejleszteseben egy nagyon jelent}os merfoldk}o volt, ekkor ugyanis kiszedtek a Mach kernelb}ol a Berkeley UNIXspecikus reszeket, es a Mach (aktualis, 3.0-as valtozata) ekkor mar csak nehany alapszolgaltatast nyujtott a rajta futo programoknak: lenyegeben egy absztrakt magasszint}u hardver szintnek lehetett tekinteni, amelyen mas operacios rendszerek (viszonylag) hordozhato formaban rhatoak meg15. Ez a szetvalasztas (vagyis a Berkeley szerz}oi jogok altal vedett reszek kiszedese) tette lehet}ove azt is, hogy a Mach-ot szabadon elerhet}ove tegyek barki erdekl}od}o szamara (ami persze nem okozta a Mach tomeges elterjedeset, a hianyzo UNIX-kompatibilitas 15 Ezzel a m} uvelettel lenyegesen lecsokkent a rendszer merete (es az altala nyujtott szolgaltatasok

sokfelesege), ezert a Mach-ot innen kezdve mar mikrokernelnek tekintik. 71 miatt). 1994-ben az Open Software Foundation (OSF) ugy dontott, hogy a kifejlesztend}o operacios rendszeret, az OSF/1-et, a Mach egy korabbi { Berkeley UNIX-ot is tartalmazo { valtozatabol, a Mach 2.5-os valtozatabol fogja kifejleszteni. A Mach egy masik lelkes hve a NEXT Computers volt, ahol az ujonnan elkeszult gepek NextSTEP nev}u operacios rendszeret a Mach 2.5-os valtozatabol fejlesztettek ki. 1994-ben a CMU-n Randall W. Dean elkesztette a 43BSD UNIX operacios rendszer { akkorra mar { szabadon terjeszthet}o forraskodjabol a BSDSS operacios rendszert, ami a Berkeley UNIX-nak egy, a Mach 3.0 mikrokernelen futo szabadon elerhet}o valtozata volt Ez sem segtett a Mach tovabbi terjedesen { egyszer}uen azert, mert kevesen tudtak rola (annak ellenere, hogy az Internet halozaton barki szamara ingyenesen elerhet}o volt). Ezutan Helsinkiben, a 4.4BSD

Lite operacios rendszer megjelenese utan, Johannes Helander iranytasaval kifejlesztettek ennek az operacios rendszernek a Mach 30 mikrokernelen futo valtozatat, ami mar nagyobb mertekben is elterjedhetett, mivel a PC-ken (binarisan) kompatibilisse tettek egy masik elterjedt operacios rendszerrel, a FreeBSD-vel, es barki, aki rendelkezett egy FreeBSD operacios rendszerrel a PC-jen, egyszer}uen a Mach 3.0 mikrokernelt es a 44BSD Lite alapu uj Lites rendszert felmasolva a PC-jere egy m}ukod}o Mach-alapu kornyezethet juthatott. Ekozben az OSF is kialaktotta a maga OSF/1 MK operacios rendszeret, amely az OSF/1 operacios rendszernek a Mach 3.0-nyujtotta absztrakt hardver retegre valo raultetese volt. Az OSF/1 MK a BSDSS ill Lites rendszerekhez hasonloan UNIX-szer}u szolgaltatasokat biztostottak a rendszerben m}ukod}o tobbi taszk szamara. A POSIX 1003.1-konformitas16 tekinteteben azt mondhatjuk, hogy a fent emltett rendszerek

(Mach 2.5, Mach 30+BSDSS, Mach 30+Lites illetve Mach 3.0+OSF/1 MK) mindaddig teljes mertekben megfelelnek a szabvanynak, amg a rendszert egyetlen szamtogepen futtatjuk, es halozati szolgaltatasok tekinteteben csak a Berkeley UNIX szinten nyujtott halozati szolgaltatasokat hasznaljuk. Amint megprobalunk osszekapcsolni tobb gepet, maris elveszik a rendszer altal addig nyujtott transzparencia, mivel a rendszerobjektumok megnevezese UNIX-szinten korulmenyesse valik, valamint a UNIX szerverek viszonylagos fuggetlensege miatt megvaltozik a parhuzamos fajl-eleres szemantikaja. Tovabbi problema a rendszerrel kapcsolatban az, hogy rosszul t}uri sok gep osszekapcsolasat, ugyanis a rendszerek kozti kommunikacio hatekonysaga az alkalmazott hardver technologiak gyengesegei miatt a rendszerbe kapcsolt elemek szamanak novekedesevel egyre inkabb csokken. Ezekkel a rendszerekkel kapcsolatban mas problemak is felmerultek, amiket a

kes}obbiekben reszletesen elemezni fogok. 16 Megjegyzem, hogy a POSIX 1003.1 szabvanyaz ujabb szabvanyokk oze tartozik a POSIXkonformitason a POSIX 1003.1-nel korabban megjelent rendszerek eseteben a korabeli UNIXszal valo kompatibilitast ertem 72 5.2 A rendszerstruktura (egy vagy t
obb szerver) Egy operacios rendszer bels}o szerkezete tobbfele lehet a leggyakoribb rendszerstrukturak a kovetkez}ok: monolitikus, retegzett (layered), virtualis gepeken alapulo, valamint a kliens-szerver modellen alapulo (ld. Tan87]) A monolitikus operacios rendszer (mint peldaul a UNIX AT&T vagy Berkeley valtozata) magja egyetlen programbol all. Ebben a programban az eljarasok szabadon hvhatjak egymast, a koztuk lev}o kommunikacio eljarasparametereken es globalis valtozokon keresztul zajlik. A retegzett szerkezet}u operacios rendszer magja tobb modulbol all, es a modulok kozott egy export-import hierarchia gyelhet}o meg: minden modul

kizarolag a hierarchiaban alatta lev}o modul szolgaltatasait hasznalja. A virtualis gepeken alapulo operacios rendszerben kozponti reszen helyezkednek el a virtualis gepeket menedzsel}o (hypervisor) rendszerrutinok. Ez a program lehet}ove teszi a hardver er}oforrasainak (CPU, diszk, periferiak, memoria, .) tobb operacios rendszer kozotti hatekony elosztasat A hypervisor leggyakrabban a szamtogep hardveret "tobbszorozi meg" ugy, hogy a rajta futo operacios rendszerek ugy lassak, hogy ovuke az egesz gep (pedig "csak" egy virtualis gepen futnak). Ha peldaul egy megszaktas generalodik, akkor ez adja at annak a virtualis gepnek, amelyre ez tartozik (az, hogy kire tartozik egy megszaktas, tobbfelekeppen eldonthet}o: peldaul az alapjan, hogy a kerdeses I/O eszkozt ki hasznalta utoljara). Ilyen hypervisor peldaul az IBM VM/370 Az altala letrehozott es iranytott virtualis gepek az IBM

/370-es hardver "pontos masolatai", es tudnak futtatni (egymastol fuggetlenul) AIX, CMS, TSO es mas operacios rendszereket. A kliens-szerver modellen alapulo operacios rendszerek eseteben az operacios rendszer kozponti magja altalaban egy un. mikrokernel, es maga az operacios rendszer itt tobb parhuzamosan futo folyamatbol all. Mindegyik folyamat az operacios rendszer valamely jol elkulonthet}o feladatat valostja meg (peldaul lehet egy vagy akar tobb fajlszerver folyamat, egy diszkvezerl}o, egy printervezerl}o folyamat a rendszerben). Ezeknek a folyamatoknak valamilyen kommunikacios eszkozt kell biztostani, es ez a mikrokernel egyik f}o feladata (a memoriakezelesen kvul). A legtobb ma hasznalt ilyen kernel az uzenetatadast (message passing) teszi lehet}ove a parhuzamosan m}ukod}o folyamatok kozotti kommunikacio megvalostasa erdekeben. Az alacsonyszint}u uzenetatadas m}ukodhet ket teljesen

kulonboz}o host kozott is ugyanugy, mint egy hoston belul kulonboz}o folyamatok kozott, ami a kommunikacio formajat egysegesse teheti egy gepen belul es ket gep kozott (ezt a transzparenciat mas modon nagyon nehez elerni). Mg a Mach-alapu operacios rendszerek a 3.0-as valtozat el}ott mind monolitikusaknak tekinthet}ok, addig a 30-as valtozattol kezdve egyre inkabb a rendszermag altal nyujtott szolgaltatasok sokfelesegenek csokkentese lett a cel A Mach ekkor mar lenyegeben csak a kommunikacios, a virtualismemoria-kezelesi, valamint a periferia kezelesi es az utemezesi mechanizmusokat nyujtja. A 73 POSIX 1003.1 szabvany altal szuksegesnek tartott egyeb operacios rendszer szolgaltatasok biztostasat a Mach szolgaltatasait kihasznalo, nem privilegizalt modban futo un. UNIX szerver taszk(ok)ra bzzak A UNIX operacios rendszer funkcionalitast biztosto eszkozok ket lenyeges reszb}ol tev}odnek

ossze: magabol a UNIX szerverb}ol, amely egy onallo programkent van jelen a gepen, valamint az un. transzparens emul
aci
os konyvt
arb
ol, amely azon taszkok virtualis cmtartomanyaban helyezkedik el, amelyek igenybe akarjak venni a UNIX szerver kulonfele szolgaltatasait, es ezen a transzparens emulacios konyvtaron keresztul tartja a kapcsolatot az alkalmazas a POSIX 1003.1 szolgaltatasokat nyujto UNIX szerverrel. Sem a UNIX szerver, sem pedig a szolgaltatasait hasznalo alkalmazasokban elhelyezett emulator futtatasahoz nincs szukseg semmifele privilegiumokra. A UNIX szervert is tobbfelekeppen lehet felepteni. Lehet az is, hogy egyetlen szerver program biztostja az osszes UNIX-szer}u operacios rendszer funkcionalitast { ezt nevezik egyszerveres megoldasnak (single server). Egy masik megoldas az, hogy a UNIX-szer}u operacios rendszer funkcionalitast tobb szerver program egyuttm}ukodve biztostja: ilyen operacios rendszer

lesz a GNU Hurd, valamint az IBM Workplace OS17 rendszere. Ez utobbi megoldast nevezik tobbszerveres (multi-server) megoldasnak (itt altalaban egy-egy { peldaul a feladatuk alapjan kepezett { rendszerhvas-csoportot mas-mas szerver implemental, de elkepzelhet}oek mas szetbontasi szempontok is). Ma az operacios rendszer fejleszt}ok a tobbszerveres megoldast reszestik el}onyben, mivel az egyes szerverek kulon-kolon konnyen kezelhet}oek, es jo technologiak vannak ezek egybefogasara is, viszont ezeknel a rendszereknel komoly problemat jelent a megoldas gyenge hatekonysaga (vagy legalabbis az azonos funkcionalitasu egyszerveres megoldashoz kepesti altalanossagban tapasztalhato lassusag). Az egyszerveres megoldast abban az esetben erdemes hasznalni, amikor egy mar meglev}o monolitikus operacios rendszert ultetnek at a Mach-ra, mivel ilyenkor tobb a lehet}oseg a mar megrt { a monolitikus operacios rendszerb}ol szarmazo {

kodreszek ujrafelhasznalasara (ilyenkor az operacios rendszer Mach 3.0 fole teleptese lenyegeben egy ujabb { absztrakt { hardver fole valo teleptesnek tekinthet}o). 5.3 A POSIX emulacio eszk
ozei A POSIX 1003.1 szabvany lenyegeben azt specikalja, hogy az alkalmazasok milyen szolgaltatasokat vehetnek igenybe az operacios rendszert}ol azaz milyen szolgaltatasokat kell, hogy nyujtson az operacios rendszer a gepen futo programoknak. A szabvany a szolgaltatasokat C nyelven hvhato fuggvenyek pro17 Az IBM-nek nagy szerepe van a Mach 30 kodjanak szabadda ("masolhatova") teteleben, ugyanis az IBM is egy Mach-szarmazek mikrokernelretervezi ill. epti az ujabb operacios rendszereit, es a Mach 30 fejlesztese soran elert eredmenyeinek nagy reszet szabadon masolhato formaban a Mach fejleszt}oinek a rendelkezesere bocsatotta azzal a cellal, hogy a Mach 3.0 kernel licenszekkel vedett reszeit lecsereljek szabadon masolhato reszekre. 74

totpusakent es azok feladatanak lerasaval egyutt adja meg, es mindemellett a szabvany szovege ki van egesztve egy fogalmi modellel, mely specikalja azt a kornyezetet, amelyet az operacios rendszer egy futo folyamatanak nyujt. Fontos megjegyezni, hogy a POSIX szabvany nem specikalja azt, hogy a folyamatok a rendszerszolgaltatasokat milyen modon vehetik igenybe (peldaul milyen gepi utastast kell vegrehajtania egy folyamatnak ahhoz, hogy az operacios rendszert}ol valamilyen szolgaltatast vegyen igenybe). Ezzel kapcsolatban is kiadtak 18 kulonfele szabvanyokat, melyeket ABI (Application Binary Interface, gepi kodu interfesz alkalmazasok reszere) szabvanyoknak neveznek, de egy processzorhoz tobb ilyen ABI is kialakthato, aminek a kulonboz}osege az alkalmazasok binaris inkompatibilitasat okozhatja es altalaban okozza is19. A POSIX 1003.1 emulacion a fentiek alapjan ket dolgot erthetunk: A folyamatoknak a POSIX

1003.1 altal specikalt szolgaltatasok nyujtasat egy olyan C konyvtar formajaban, amelyet a programunkhoz a linkage editorunkkal hozzalinkelhetunk. Ez a programok forraskod szint}u hordozhatosagat teszi lehet}ove A folyamatoknak a POSIX 1003.1 szabvany altal specikalt szolgaltatasok nyujtasa az adott processzoron szabvanynak tekinthet}o ABI-nak megfelel}o modon. Ez a programok binaris szint}u hordozhatosagat IS biztostja { amellett, hogy az eredeti kornyezet C konyvtaraival (is) konnyen elerhet}o a forraskod szint}u hordozhatosag. Mi e dolgozatban megelegszunk ugyan az els}o ertelmezes szerinti POSIX 1003.1-konformitas eleresevel, de meg fogjuk vizsgalni a binaris kompatibilitas eleresenek lehet}osegeit is. 5.31 POSIX 10031-konformitas a C konyvtarban A POSIX 1003.1 specikacio C konyvtar formajaban torten}o megvalostasa a Mach felett egy olyan C konyvtar kialaktasat jelenti, mely tartalmazza az osszes

POSIX 1003.1 altal denialt fuggvenyt mint belepesi pontot, es azokat sajat hataskoreben (mas szerverekkel valo kapcsolat nelkul) meg tudja valostani. Itt egyb}ol felmerul tobb nagy problema is. Az egyik problemat az okozza, hogy a POSIX 1003.1 szabvany a folyamatok (processzek) viselkedeset nemcsak mint onallo egysegeket specikalja, hanem denial folyamat-csoport kepzesi modot (peldaul a hagyomanyos 18 Megjegyzem, hogy az ilyen processzorf ugg}o szabvanyokat nem a POSIX-ot kiado IEEE, hanem altalaban a CPU-k keszt}oi szoktak kiadni. 19 Az Intel 80386 processzorhoz a legelfogadottabb ABI az IBCS 2 (Intel Binary Compatibility Speci cation Issue 2., 2 Intel altal speci kalt binaris kompatibilitasi speci kacio), amit manapsag minden ezen a CPU-n futo operacios rendszer megprobal biztostani, de leteznek ett}ol elter}o ABI-k is, mint peldaul a Linux vagy a FreeBSD (ill. NetBSD) operacios rendszerek altal biztostott ABI-k. 75 processz-csoport,

valamint session fogalmakkal), es a Mach onmagaban nem biztostja ezeknek a fogalmaknak az elerhet}oseget a Mach taszk objektumokkal kapcsolatban, gy ezen fogalmak implementacioja komoly problemat jelenthet. Nyilvan ez a problema megoldhato ugy, hogy a POSIX processz-csoport fogalmaknak megfelel}oen Mach portokkal ill. szukseg eseten a folyamatok egymas kozotti kommunikaciojaval szimulaljuk a POSIX folyamat-csoport kepzesenek szemantikajat, ami a Mach taszkjainak a hierarchiajat kovetve hierarchikusan implementalhato lenne ugyan, de a hierarchiaban a kommunikacio megvalostasanak koltsege nagyon nagy lenne (emlekezzunk arra, hogy a Mach nem rendelkezik a csoport-kommunikacio tamogatasara semmilyen eszkozzel, gy a csoportkommunikaciot a Mach portoknak ket pont kozotti kommunikaciora valo hasznalataval lehetne megoldani, ami a kommunikacio koltseget tekintve lenyegeben egyenesen aranyos a folyamatok szamaval).

Ennel a megoldasnal problemakent jelentkezik a folyamatok oriasi merete, hiszen itt lenyegeben az egesz operacios rendszert magaban hordozza az osszes POSIX folyamat. Problemat jelenthet a konkurrens fajl-eleres, valamint a megosztott fajl-pozcio Tan87] implementalasa is. Nyilvan a folyamat-csoportok kepzesenel ill. annak szemantikajanak implementalasanal rt megoldasi modszerek itt is alkalmazhatoak lennenek olymodon, hogy szukseg eseten (minden megosztott fajl-pozcioval rendelkez}o fajlon vegzett fajlm}uveletnel) a folyamatok hierarchiajaban meg kell keresni az aktualis fajl-pozciot nyilvantarto folyamatot, es a fajl-pozciot aktualizaltatni kell vele, de ez is rendkvul koltseges lenne. Vegul, de nem utolsosorban meg kell emlteni ennek a megoldasnak a biztonsagossagi korlatjait. A POSIX 10031 szabvany nem denial ugyan a UNIX-ban megismert szuperfelhasznalo vagy valamilyen ahhoz hasonlo celu

fogalmat, de egyes m}uveletekhez rja azt, hogy igenybevetelukhoz specialis privilegiumok szuksegesek (ezert alakthattak ki kulonboz}o privilegiumszinteket a POSIX egyes implementaloi { a US. DoD igenyeinek kielegtese erdekeben). Mivel a Mach rendszerben a "vedett" (privilegizalt) m}uveletek vegrehajtasa specialis portok (hostvezerl}o, periferiavezerl}o portok) birtoklasahoz van kotve, gy a POSIX-fele setuid bit megvalostasahoz (vagyis egy folyamat elindtasakor lehessen az elindtohoz kepest tobb privilegiummal rendelkez}o folyamatot elindtani) az osszes folyamatnak rendelkezesere kellene bocsatani e specialis celu privilegizalt portokat, gy ezeket a folyamatokat akar rosszindulatuan mas celra is felhasznalhatnak, ami nem megengedhet}o. Ennek a megoldasnak meg egy hatranyos tulajdonsaga van: az, hogy az "operacios rendszer" teljesen a program cmtartomanyan belul helyezkedik el, gy az

alkalmazas akar veletlenul akar szandekosan atrhatja az 76 operacios rendszert { megtorve a rendszert rendszerre tev}o struktura helyes m}ukodeset. A fent vazolt problemak alapjan gondolom erthet}o, hogy egyetlen jelenlegi Mach feletti POSIX emulacios szoftver sem alkalmazza ezt a technikat. 5.32 POSIX 10031-konformitas elerese Mach szerverekkel Egy masik { sokkal sokret}ubb { megoldasi modot is knal a Mach a POSIX emulacio megvalostasara: ilyen celu szervert vagy szervereket lehet letrehozni, es ezen szerverek osszessege egyuttesen biztosthatja a POSIX 1003.1 szemantikat Az eddig elkeszult implementaciok altalaban ezt a megoldasi utat kovetik: a POSIX (UNIX) szemantikat egy vagy tobb { egymassal kommunikalo { szerverrel valostjak meg. Ilyen esetekben az alkalmazasok a POSIX szervert}ol a Mach folyamatok kozotti kommunikaciojanak eszkozeivel kerhetnek POSIX szolgaltatasokat. Az, hogy a POSIX

szemantikat egy vagy tobb szerver egyuttesen biztostja, az alkalmazas szamara kozombos, viszont egy szamtogepes halozat kialaktasaval az osztott rendszer kep elereset a tobbszerveres megoldassal konnyebben megvalosthatjuk. Itt osszefoglalom az egy- illetve tobbszerveres megvalostas el}onyeit illetve hatranyait, majd a kovetkez}o pontban megvizsgaloma POSIX folyamatokes a POSIX szerver folyamat kapcsolattartasanak a kerdeseit. Az egyszerveres megvalostas eseteben a szerver egyetlen program, amelynek tudomasa van az osszes POSIX folyamat allapotarol, gy a POSIX szerver funkcionalitas a monolitikus POSIX kernel implementaciokhoz hasonloan maradektalanul megvalosthato, a Machot mint absztrakt szamtogep hardvert alapnak tekintve. Ilyen implementaciok mar keszultek altalaban valamilyen monolitikus operacios rendszert kiindulasi alapnak hasznalva, a gepfugg}o reszt Mach rendszerhvasokkal helyettestve.

Ennek a megoldasnak nagy el}onye az, hogy a szerverre alaktando, mar meglev}o operacios rendszer forraskodjat jol fel lehet hasznalni. Ennek az egyszerveres strukturanak viszont komoly hatranya az, hogy a POSIX szerver egy centralis komponens a rendszerben (amihez a kliensei, a POSIX szolgaltatasokat igenybe venni szandekozo folyamatok a kes}obbiekben bemutatasra kerul}o eszkozokkel kapcsolodhatnak hozza), gy annak meghibasodasa az egesz rendszer megbenulasat okozza. Egy tobbszerveres megoldas eseteben az egyes komponensek onmagukban sokkal egyszer}ubb szerkezet}uek, altalaban egy jol denialt feladatot oldanak meg, viszont az egesz rendszer egyuttesenek szerkezete nagyon bonyolult es osszetett lehet. Egy tobbszerveres rendszer megrasakor sokkal kevesebb a korabbi implementaciobol ujrafelhasznalhato kod, vagy legalabbis az ujrafelhasznalas megszervezese sokkal bonyolultabb szokott lenni, mint az adott feladatot

megoldo szerver ujrarasa. Azt tobb tenyez}o is befolyasolja, hogy egy- vagy tobbszerveres modon 77 erdemes-e implementalni a POSIX funkcionalitast. Az egyszerveres megoldas mellett { mint azt mar lattuk { a mar meglev}o kod ujrafelhasznalhatosaga szol, mg a tobbszerveres megoldas mellett a rendszer komponenseinek atlathatosaga, es az egyes komponensek kulon-kulon torten}o tesztelhet}osege ill. megbzhatosagnovelesi cellal torten}o atfedesek beepthet}osege a komoly erv20 . Az eddigi kutatasi eredmenyek (ld. Rick89], JmsMUS94]) alapjan viszont azt mondhatjuk, hogy az uj { a komolyabb kodujrafelhasznalas nelkul megtervezett es megrando { rendszereket tobb szerver egyuttesekent erdemes implementalni. Tovabba megoszlanak a velemenyek arrol is, hogy a tobb szervernek kell-e egymassal kozvetlen kommunikaciot folytatnia vagy sem. A Mach-US operacios rendszert egy olyan tobbszerveres operacios

rendszerkent kesztettek el, amely egymastol fuggetlenul m}ukodni kepes altalanos operacios rendszer szolgaltatasokat biztosto szerverekb}ol epul fel, ahol az egyes szerverek nem kommunikalnak egymassal, ehelyett maga a POSIX szolgaltatasokat igenybe vev}o folyamat az, ami a szervereket egy rendszerre szervezve, megvalostja az egyes szerverek osszekapcsolasat (lasd err}ol reszletesebben JmsMUS95] cikket). Megjegyezzuk, hogy ilyen modon (altalanos operacios rendszer szolgaltatasokat nyujto szerverekkel) a kulonfele operacios rendszer szerverek kodjanak nagy resze osszevonhato, ami szinten egy, a tobbszerveres architektura mellett szolo erv. A Free Software Foundation altal megtervezett es jelenleg implementalas alatt allo GNU Hurd operacios rendszer egy szep pelda arra, hogyan lehet egy tobbszerveres Mach-feletti operacios rendszert egymassal egyuttm}ukod}o, kommunikalo szerverekkel megvalostani (vagyis

itt nemcsak a POSIX szolgaltatasokat igenybevev}o alkalmazas all a szolgaltatasokat nyujto szerverekkel egy kliens-szerver kapcsolatban, hanem egy hasonlo jelleg}u kapcsolat van a szolgaltatast nyujto szerverek kozot). Most, hogy mar lattuk az egy- illetve tobbszerveres POSIX emulacio szerkezetet, erdemes megnezni, hogy a POSIX szolgaltatasokat milyen modon erhetik el az alkalmazasok (vagyis mi van a POSIX fuggvenyek meghvasa mogott, hogyan lesz megoldva az alkalmazas-szerver kapcsolat). Ez lesz a kovetkez}o pont temaja ::: Ezeknel a tobbszerveres rendszereknel is elerhet}o a teljeskor}u POSIX 1003.1-konformitas (ahogyan azt a GNU Hurd valamint a Mach-US (ld. JmsMUS95]) operacios rendszer keszt}oi mar bebizonytottak), hiszen { igaz neha kisse primitv megoldast kapva { egy egyszerveres operacios rendszer implementaciobol kiindulva egyes reszeket kulon szerverbe teve, es az eredeti szerverhez kapcsolva tavoli eljarashvas lehet}osegevel

altalaban ugyanazt meg tudjak oldani, mint az eredeti egyszerveresstrukturaval. A tobbszerveresmegoldasokeseten a POSIX 1003.1-konformitas hatekony eleresenek kerdeset egy halozaton futtatott rendszeren is meg szoktak vizsgalni (tkp. osztott rendszereken), es itt mar az a tapasztalat, hogy nagyon nehez egy, az osztott rendszerek korabban (ld. 12 pontot) megismert alaptulajdonsagaival rendelkez}o es hatekony POSIX 10031-konform tobbszerveres operacios rendszert kialaktani, es ez nem els}osorban a Mach esetleges hianyossagai miatt van gy, hanem a POSIX 1003.1 altal speci kalt kuls}o kornyezet egyes jellemz}oi miatt. Ezt a kerdest egy kes}obbi fejezetben meg reszletesebben fogom elemezni. 20 78 5.33 Az alkalmazas es a POSIX szerverek kapcsolata Abban az esetben, amikor a POSIX funkcionalitast a (statikus vagy osztott) C konyvtaron belul implementaljak (ld. 531 pontot), az alkalmazas a POSIX szolgaltatasokat a szolgaltatasokat nyujto eljarasok

vegrehajtasaval erheti el. Ilyen esetben { mivel nincs ertelme POSIX szerverekr}ol beszelni { ezt a problemat nem kell reszletesebben megvizsgalni. Az alkalmazas es a szerverek kapcsolata alapvet}oen ketfelekeppen strukturalhato: vagy a Mach memoria kezel}o alrendszerere eptve21 vagy pedig a Mach IPC eszkozeire (portokra) eptve (legalabbis ami a POSIX funkcionalitas elereseb}ol a processzek kozotti kommunikacios reszt illeti). Az alkalmazas a POSIX szolgaltatasokat eljarashvasokon keresztul erheti el (a megfelel}o { POSIX szabvanyban rogztett { POSIX fuggveny meghvasaval, a POSIX szabvanyban kozolt modon felparameterezve azt). A tovabbiakban azt fogjuk megvizsgalni, hogy mi tortenik ezek kozott: vagyis a POSIX operacios rendszer szervernek22 torten}o uzenet elkuldese es egy { az alkalmazasban torten}o { POSIX szolgaltatas igenybevetelet ker}o fuggveny meghvasa kozott. A ltalaban az operacios

rendszer szerverek nyujtotta szolgaltatasok es a POSIX szabvany altal megkovetelt szolgaltatasok kozott nem letesthet}o egy kolcsonosen egyertelm}u megfeleltetes. Az operacios rendszer szerverek nyujtotta szolgaltatasok gyakran sokret}ubbek, mint amit a POSIX szabvanyhoz valo konformitas megkovetelne: a szerver a folyamatoknak sokkal tobb jellemz}ojehez nyujthat hozzaferest, mint amennyit a POSIX szabvany rendszerhvasain keresztul elerhetunk. Termeszetesen az alkalmazas { amennyiben szigoruan kovetni akarja a POSIX ajanlasait { nem feltetlenul kell, hogy kihasznalja ezeket a plusz lehet}osegeket, viszont adott esetben { ha erre a hordozhatosag csokkenese aran szuksege van { ezt megteheti. Ez termeszetesen szukseges is lehet, ugyanis vannak alkalmazasok, amik nem a POSIX keretein belul tevekenykednek, hanem kihasznaljak egy-egy operacios rendszer specialis lehet}osegeit { peldaul az adott operacios rendszer

thread-konyvtarat23, es ezeknek az alkalmazasoknak is meg kell teremteni valamilyen modon a Mach feletti futas lehet}oseget. Ezt altalaban ugy teszik, hogy a Mach felett futo operacios rendszerek (ill. operacios rendszer szerverek) biztostanak a szabvanyos POSIX kornyezet mellett mas un operacios rendszer szemelyisegeket, ahol az alkalmazasok altal igenybevehet}o szolgaltatasok b}ovebbek, mint a POSIX altal specikalt szolgaltatasok halmaza. Peldaul az AT&T SVR4 UNIX Mach felett implementalt szerverehez mar elkesztettek a Solaris 2.524 operacios rend21 Ezt a modszert a 55 pontban fogom a hasznalatanak tipikus alkalmazaster uleteivel egyuttesen bemutatni. 22 A tovabbiakban { amennyiben az ellenkez} ojet nem alltjuk { feltetelezzuk, hogy a POSIX szolgaltatasok erdekeben egy szerverrel kell tartani a kapcsolatot, es nem is foglalkozunk e szerver bels}o feleptesevel. 23 A thread k onyvtarak a POSIX thread-szabvany atalsaga miatt meg

nem mindig POSIX konformak { ld. peldaul a Solaris 25 operacios rendszer thread konyvtarait 24 A Solaris 2.5 operacios rendszer az AT&T SVR4 UNIX operacios rendszerb} ol szarmazik. 79 szer szemelyiseget, amely az alkalmazasoknak elerhet}ove teszi a Solaris 2.5 specialitasokat is { s}ot az osszes olyan Solaris 25 jellemz}ot is, ami esetleg nem koveti a POSIX valamely ajanlasat (a Solaris 2.5 esetleges hibaival egyutt { ui kialakulhatott a Solaris 2.5 operacios rendszeren futo alkalmazasoknak egy olyan kore, amelyek kihasznaljak a Solaris 2.5 egy-ket "hibajat" { peldaul bizonyos extremalis (a szabvanyban nem denialt) argumentum ertekek eseten torten}o viselkedeset {, amiket a Sun a tovabbi valtozatokkal kapcsolatos kompatibilitasi okok miatt mar nem fog eltavoltani a Solarisbol). Emulatornak nevezik azt a programreszt, amely megteremti a kapcsolatot az operacios rendszer szolgaltatasok alkalmazasbeli elereset

biztosto fuggvenyek es a POSIX (vagy mas operacios rendszer) szerver nyujtotta szolgaltatasok kozott. A legtobb operacios rendszer eseten az emulator egyszer}uen egy konyvtar (statikus vagy osztott), ami nehany operacios rendszer szolgaltatast onmagaban { mas szerver(ek) szolgaltatasainak igenybevetele nelkul nyujt, es a szerverekkel csak akkor veszi fel a kapcsolatot, amikor az feltetlenul szukseges. Az alkalmazas ehhez az emulatorhoz (transzparens emulacios konyvtarhoz) sokfelekeppen hozzaferhet: Amennyiben az alkalmazas forraskodban rendelkezesre all, ugy a forraskodja modosthato ugy is, hogy az emulator megfelel}o fuggvenyeit hvja meg olyankor, amikor valamilyen POSIX vagy mas operacios rendszer szolgaltatast kvan igenybe venni. Ez a { talan legtermeszetesebbnek t}un}o { megoldas nem terjedt el, mert gy lenyegeben ugyanannak a programnak egyszerre ket (vagy esetleg tobb) valtozatat kell

kezelni, ami altalaban nagyon koltseges. Az el}obbinel egy kicsit jobb megoldas az, amikor csak a program altal hasznalt rendszerkonyvtarakat rjak at: ekkor csak a konyvtarnak kell tobb valtozatat kezelni, ami adott esetben hatekonyan megoldhato. Amennyiben az alkalmazasok nem allnak rendelkezesunkre forraskodjukban, ugy nehezebb a dolgunk: gyelni kell { peldaul a Mach kivetelkezel}o mechanizmusaival { azt, hogy az alkalmazas mikor hajt vegre egy-egy rendszerhvasi utastast (amit altalaban a Mach rendszer felett futo folyamatok nem hajthatnak vegre vegrehajtasukkor egy kivetelkezel}o folyamat aktivalodik), es amikor egy alkalmazas vegrehajt egy ilyen privilegizalt utastast, akkor a kivetelkezel}o eljarasnak meg kell neznie, hogy az alkalmazas milyen cellal hajtotta vegre a kerdeses utastast, es ha rendszerhvast akart vegrehajtani, akkor a kivetelkezel}o megteheti ezt helyette. Ilyenkor azt is tehetjuk, hogy az

alkalmazas vegrehajthato kodjat atrjuk azokon a helyeken, ahol privilegizalt rendszerhvas-utastasokat hajt vegre, berva az adott utastast helyettest}o egy masik, nem privilegizalt utastast, amelyet az utastasvegrehajtast ujraindtva a kvant rendszerhvas lesz vegrehajtva. Ilyenkor a "helyettest}o" utastas altalaban egy olyan eljarashvas, amely az emulacios konyvtar megfelel}o pontjara adja 80 at a vezerlest. Ez utobbi ket esetben { amikor az alkalmazas forrasa nem all rendelkezesunkre { az emulator programot nehezen lehet az alkalmazashoz kapcsolni: a legtobb implementacio ilyenkor azt csinalja, hogy az operacios rendszer szervert modostjak ugy, hogy egy uj alkalmazas vegrehajtasa/memoriaba toltese eseten automatikusan toltse hozza egy jol meghatarozott helyre az emulator konyvtarat (altalaban az alkalmazas cmtartomanyaba). A transzparens emulacios konyvtar

hasznalatanak mar lathattuk, hogy tobb el}onye illetve hatranya25 is van. Gyakran vizsgaljak azt, hogy mennyivel hatekonyabb egy alkalmazas transzparens emulacios konyvtarat hasznalo Mach-alapu kornyezetben a nativ (nem Mach-alapu) operacios rendszeren futo valtozatahoz kepest. Erre a kerdesre (JmsMUS95] alapjan) a kovetkez}ot lehet valaszolni: egy Mach felett futo egyszerveres POSIX-konform operacios rendszer szerver egy adott hardveren altalaban lassabban fut, mint ugyanannak az operacios rendszernek a nativ (nyers hardverre epul}o) valtozata. Ez azert van, mert a Mach mikrokernelnek onmagaban is eleg nagy a m}ukodesehez szukseges er}oforrasigenye (ilyen "m}ukodesi koltsegek" vannak a nativ operacios rendszereknel is, viszont a Mach nyilvantartasi es m}ukodesi koltsegei altalaban nagyobbak ennel, mivel egy altalanosabb alapot kell szolgaltatnia, ugyanis a mikrokernel nincs egy operacios rendszerhez

sem optimalizalva). Termeszetesen sokminden attol fugg, hogy egy adott mechanizmus hogyan lett implementalva Az operacios rendszer szerver elereset lehet}ove tev}o transzparens emulacios konyvtar javthatja az alkalmazas hatekonysagat egy elosztott tobbszerveres kornyezetben, f}oleg olyankor, amikor egyes szolgaltatasok szolgaltatoi tobb peldanyban is futnak kulonboz}o szamtogepeken: ilyenkor a transzparens emulacios konyvtar { a rendelkezesere allo informaciok (pl. szerverek leterheltseger}ol) alapjan { egy adott szolgaltatas eleresehez kivalaszthat egy kevesse leterhelt szervert a potencialisan kivalaszthato szerverek kozul, ami nagyot javthat a rendszer hatekonysagan. A transzparens emulacios konyvtarak masik nagyon fontos haszna a hatekonysagnoveles szempontjabol az, hogy az emulacios konyvtar bizonyos informaciok cache-eleset elvegezheti, ezzel csokkentve a szukseges szerverhozzaferesek

szamat (ezzel csokkentve a szerver-hozzafereseknel szukseges kontextuscserek szamat is). Peldaul a POSIX szabvany denialja egy folyamat folyamat-azonostojat, ami a folyamat futasa soran nem valtozik A POSIX szabvany lehet}oseget nyujt ennek az azonostonak a lekerdezesere, amely m}uveletet a transzparens emulacios konyvtarban implementalhatjuk ugy is, hogy minden egyes meghvas alkalmaval felveszi a POSIX szerverrel a kapcsolatot, elkeri t}ole a folyamat-azonostot, es visszaadja az alkalmazasnak, de ugyanez implementalhato ugy is, hogy csak az els}o alkalommal keri el a POSIX 25 Alapvet} o hatranynaktekinthet}o az alkalmazaslassabb vegrehajtasa, de az el}onyok (binaris kompatibilitas, elosztottkornyezetkihasznalasa),amik ezaltal nyerhet}ok,messze tobbet ernek, mint az, amit ezzel vesztunk. 81 szervert}ol a folyamat-azonostot, a tovabbi lekerdezesek koltsegeinek nagy reszet megsporolhatja olymodon, hogy a

folyamat-azonostot eltarolja egy valtozoba, es a kovetkez}o folyamat-azonosto lekerdezeseket e valtozo segtsegevel elegti ki. 5.4 Biztonsagossagi kerdesek A Mach alapu operacios rendszer szerverek is { fuggetlenul attol, hogy POSIXszer}u operacios rendszer szemelyiseget implementalnak vagy sem { tartalmazhatnak kulonfele biztonsagossagi reseket: olyan hibasan megtervezett vagy implementalt lehet}osegeket, amelyek segtsegevel a rendszerben egy egyed tobb jogosultsagot kaphat egy rendszerbeli objektumra vonatkozoan, mint amennyi valojaban kijar neki { mint amire feladatanak ellatasahoz tenylegesen szuksege van (a biztonsagossaggal kapcsolatos alapfogalmakat ld. a 143 pontban) Bizonyos tekintetben ebbe a temakorbe sorolhato a rendszerben tarolt adatok biztonsaganak a problemaja is (biztonsagi masolatok kesztese, stb ). A ltalaban a problemak nagy resze ugyanolyan, mint amilyenekkel a rendszertervez}ok a

nem Mach-alapu monolitikus rendszerek tervezesekor es implementalasakor is talalkoznak: hibasan megrt vagy rosszul konguralt szoftverek es szerverek, melyek gyakran szuperfelhasznaloi privilegiumokkal futnak, es a halozaton keresztul egy-egy rossz szandeku kliens alkalmazas a szerverben lev}o hibakat kihasznalva masnak adhatja ki magat, mint aki }o valojaban (lasd err}ol reszletesebben Tan87]-et valamint Farr95]-ot). Az adatbiztonsag tekinteteben Mach alapu illetve mas elosztott rendszerekben hasznos lehet kihasznalni az operacios rendszer tamogatasat egyes szolgaltatasok megtobbszorozesere, ami a rendszer elerhet}oseget lenyegesen novelheti. A problemak masik resze altalaban abbol a tenyb}ol szarmazik, hogy a Mach mikrokernelt az alkalmazasok elerhetik a felette futo operacios rendszer szervert}ol teljesen fuggetlenul is, gy megteveszthetik ezzel az operacios rendszer szervert, ami nem rendelkezik pontos

ismerettel a szolgaltatasait kihasznalo programokrol (peldaul egy Mach alapu szerver a szolgaltatasait kihasznalo folyamatok cmtartomanyaban vegezhet bizonyos manipulaciokat (pelda erre a transzparens emulacios konyvtar szamara memoriaregio allokalasa es az emulator betoltese), ami { elvileg { a folyamat szamara transzparens modon tortenik, de a peldankat folytatva a folyamat { egy memoriaregio-terkepet kerve { deallokalhatja az emulator szamara fenntartott memoriaregiot, ezzel lehetetlenne teve az operacios rendszer szerver es a szolgaltatasait hasznalo kliens helyes m}ukodeset. Megjegyezzuk, hogy ezek a problemak reszben elkerulhet}ok lennenek a szerverek jobb megtervezesevel, de az eddig elkeszult implementaciok ezeket a problemakat egyszer}uen gyelmen kvul hagytak. A kovetkez}o pontokban az ilyen eredet}u problemakat fogjuk attekinteni. ::: 82 5.41 Exhibicionista kliensek

Exhibicionistanak nevezik azokat a Mach taszkokat, amelyek a rendelkezesukre allo port hozzaferesi jogokat illetektelenul tovabbadjak mas taszkoknak. Ilyen modon olyan taszkok is hozzajuthatnak szerverek szolgaltatasaihoz (a jogtalanul nyert port hozzaferesi jogon keresztul), akiknek nincs joga az adott szerver szolgaltatasainak igenybevetelere. Erre a problemara a megoldast a taszkok biztonsagi azonostojanak egy otletes felhasznalasi modja nyujthatna: minden egyes taszkhoz hozza van rendelve egy biztonsagi azonosto, melynek a kernel fele nincs onallo jelentese. A taszkok ezt az azonostot a szul}ojukt}ol oroklik, es csak a megfelel}o privilegiumokkal26 rendelkez}o taszkok modosthatjak mas taszkok (vagy a sajat) biztonsagi azonostojat. A Mach uzenetkuldesi mechanizmusat pedig kib}ovtettek ugy, hogy a kernel minden elkuldott uzenettel egyutt elkuldi az uzenetet kuld}o taszk biztonsagi azonostojat,

amelyet a szerverek felhasznalhatnak a szolgaltatasok igenybevetelenek a jogosultsaganak az ellen}orzesekor. 5.42 Az eszkozmeghajtok problemaja A periferiakat reprezentalo portok es a rendszerben lev}o (valos ill. virtualis) periferiak kolcsonosen egyertelm}uen egymashoz rendelhet}ok, aminek az a kovetkezmenye, hogy a periferiakra vonatkozoan a kernel nem tud korlatozott hozzaferesi jogokat kiadni: aki egyszer hozzajutott egy eszkozt reprezentalo porthoz, az korlatozas nelkul barmit csinalhat az adott eszkozzel. Erre a problemara megoldast jelenthet egy eszkoz-szerver letrehozasa, amely egyedi portokat general minden { sikeres { eszkozhozzaferesi kserlet utan, csak ezt advan vissza az eszkozt hasznalni kvano taszk szamara, es minden egyes portra vonatkozoan eltarolja azt is, hogy milyen hozzaferesi jogokat kert az adott portot birtoklo taszk, es mas hozzaferesi formakat nem fog engedelyezni az adott

eszkozhoz az adott porton keresztul. 5.43 Er}oforrasfalo taszkok Nehany Mach kernel er}oforras (pl. orak, periferiak) a rendszer inicializalasakor lesznek letrehozva, a kes}obbiekben nem lesznek uj ilyen tpusu er}oforrasok letrehozva, ezert ezekkel kapcsolatban nem all fenn annak a veszelye, hogy egyes (rosszindulatu) taszkok tul sokat hoznanak letre bel}oluk, ezzel elfogyasztva a szabad er}oforrasokat (ui. alapertelmezes szerint { az eddig implementalt szerverekben { nincs arra vonatkozoan semmi korlat, megkotes, hogy egy taszk mennyi rendszerer}oforrast fogyaszthat el). A korlatlan mennyiseg}u kernel er}oforrasok felhaszalasa oda vezethet, hogy a szerverek bizonyos letfontossagu szolgaltatasokat nem tudnak biztostani az azt igenyl}oknek. 26 A megfelel}o privilegium megletet a host biztonsagi portjara valo adatkuldesi jog jelenti. 83 Ennek a problemanak a megoldasara vezettek be a ledger kernel objektumokat, amelyekkel

korlatozni lehet egyes taszkok er}oforrasfelhasznalasat. Egy ledger objektum tartalmazza egy-egy er}oforrasra vonatkozoan az eddig elfogyasztott es meg fel nem szabadtott er}oforrasmennyiseget, tovabba tartalmazza az adott er}oforrasbol a maximalisan elfogyaszthato mennyiseget. Egy ledger a kovetkez}o kerneler}oforras-tpusokbol felhasznalt mennyisegeket korlatozhatja: A bedrotozott adatszerkezetek (pl. memorialapok, a kernel adatstrukturai, ) meretet (vagyis a nem kilapozhato lapok mennyiseget) A kilapozhato lapok mennyiseget. Minden egyes olyan kernel er}oforras, mely porttal van reprezentalva, csak ugy hozhato letre, hogy a letrehozasakor meg kell adni azt a ledger objektumot (egy ra vonatkozo uzenetkuldesi jog megadasaval), amelynek a szamlajara kell rni a letrehozott er}oforrast. A nem portokkal reprezentalt er}oforrasok (peldaul az egy portra felf}uzott uzenetek) az adott er}oforras tulajdonosa szamlajara

lesznek allokalva (a peldankban ez az a taszk, amely a kerdeses portra vonatkozoan adatfogadasi joggal rendelkezik). ::: 5.44 Szerverek elarasztasa Egyes szerver implementaciok hibasan viselkednek, ha a klienseik elarasztjak a portjaikat adatokkal, ezert valamilyen modon korlatozni kell az egy portra kuldhet}o adatok mennyiseget. Ezt sem teszik meg a legtobb eddig elkeszult operacios rendszer szerverben, ezert azok ilyen esetben furcsa dolgokra kepesek (peldaul mivel a nekik kuldott uzenetek { a meg be nem olvasottak is { elfogyaszthatjak a taszk szamara rendelkezesre allo er}oforraskeretet, gy a taszk nem tud uj er}oforrasokat letrehozni, ezzel lehetetlenne valhat a helyes m}ukodese). 5.5 A POSIX fajleleresi szemantika Egy fajlhoz torten}o parhuzamos hozzaferesek szemantikajat a POSIX szabvany (ld. IEEE90]) rogzti Ez { lenyegeben { ugy van specikalva, hogy egy fajlt egyszerre akar tobben rhatnak ill.

olvashatnak { amennyiben egyszerre tobben rnak, ugy az eredmeny nem denialt (altalaban annak a folyamatnak az outputja marad meg, amely kes}obb rta a fajlt { hiszen a POSIX csak egy zikai processzort feltetelez {, de a szabvany semmit nem mond err}ol). Termeszetesen lehet}oseg van fajlteruletek rasra vagy olvasasra torten}o lefoglalasara, es ha alkalmazzuk ezt a lehet}oseget, akkor a rendszer mar tudja garantalni a kapott eredmeny helyesseget (ami azt jelenti, hogy egyszerre vagy tobben is olvashatjak a fajlt, vagy csak egyvalaki rhatja egy ro folyamat es a tobbi ro illetve az olvaso folyamatok kozott kolcsonos kizaras all fenn). A vnode a UNIX implementacioiban a fajlrendszer objektumait lero adattpus egy reprezentans objektuma: lehet egy fajl, egy STREAMS device driver reprezentativaja, stb. (ld Rosenthal90]) 84 A fajlrendszerben tarolt fajlok (illetve valamennyi vnode-dal reprezentalt objektum)

abrazolhato a szerverben27 memoriaobjektumkent. Amikor valamelyik POSIX folyamatnak szuksege van a fajlra, akkor beagyazhatja azt vagy annak egy-egy reszet a cmtartomanyaba (termeszetesen ezt ugyanarra a fajlra vonatkozoan tobb folyamat egyszerre is megteheti, s}ot egy folyamat is beagyazhatja tobbszor ugyanazt a fajlt a cmtartomanyaba). Ennek a megoldasnak az a szepsege { a gyakori RPC-s megoldassal szemben, hogy a Mach mikrokernel vegezheti a megosztott, fajllefoglalas nelkuli fajleleres kezeleset (ugyanis egy vnode-hoz csak egy memoriaobjektum tartozik, fuggetlenul attol, hogy hanyan probalnak meg hozzaferni, es a kernel az osszes olyan taszknak, amely a fajlt beagyazta a memoriacm-tartomanyaba, egy kozos lappeldanyt biztost, amin keresztul mindenki ugyanazt a fajltartalmat lathatja). Termeszetesen a fajllefoglalas alkalmazasa eseten a fajlok (ill. vnode-ok) memoriaba agyazasa tovabbra is megoldhato,

viszont a POSIX-konformitast mar onmagaban ez a modell nem kepes nyujtani: szukseg van egy olyan rendszermodulra (peldaul egy szerverre), amely nyilvantartja es szukseg eseten koordinalja a parhuzamos fajlelerest. Mivel a Mach memoriakezelese lapozason alapszik, es a lapok merete nem lehet tetsz}oleges, ezert a POSIX szervernek illetve az alkalmazasoknak kozosen kell gondoskodniuk a fajl tenyleges meretenek a nyilvantartasarol es valtozasanak a vizsgalatarol (ui. a fajlt tartalmazo lapok kozul az utolso lapnak a nem a fajlhoz tartozo reszenek a modostasa maga utan kell, hogy vonja a fajl meretenek a megnoveleset is). A POSIX szabvany altal specikalt fajldeszkriptorok pedig megfelelhetnek egy-egy Mach memoria objektum reprezentativanak, lehet}ove teve ezzel a kulonboz}o fajlhozzaferesi modok nyilvantartasat es ennek a POSIX szerver altal torten}o betartatasat. Az els}o fejezetben alapvet}o

igenynek tekintend}onek neveztuk az osztott rendszer komponenseinek a tobbszorozhet}oseget { gy a fajlrendszeret is (ld. 12 pontban). A tobbszorozesre mutattunk egy jol bevalt modszert a szolgaltatasok atfedeses implementaciojara (ld. 155 reszt), viszont lathattuk azt is, hogy az ott bemutatott eszkoz illetve modszer a csoportkommunikaciora epult (a szolgaltatast nyujto szervereket egy csoportba kellett szervezni), de a Mach 3.0 rendszer nem biztostja a folyamatok csoportjanak az absztrakciojat (emlekezzunk ra: a porthalmaz nem adatkuldes, hanem adatfogadas celjara fog ossze portokat, vagyis ez tenyleg nem felel meg a csoportkommunikacio celjara, ahol adatkuldesi cellal hozzak letre folyamatok egy csoportjat). A Mach mikrokernelen a csoportkommunikaciot szimulalva ket pont kozotti uzenetatadassal megoldhatjuk a problemat. A tobbszorozes megvalostasara persze knalkozik egy masik ut is: a 1.41 pontban

altalanos kovetelmenynek lett megfogalmazva, hogy az egyes objektumokrol nyilvan kell tartani { altalaban a nev-szolgaltatokban { azt, hogy 27 Akar egy egyszerveres technikaval implementalt POSIX szerverben akar egy fajlszerverben. 85 az adott objektum kezeleset mely szerver kepes elvegezni. Lenyegeben ezen alapszik a kovetkez}o otlet: az operacios rendszerunk nev-szolgaltatoja (amelynek a feladata a globalis erveny}u nevek es az altaluk megcmzett objektumok osszekapcsolasa) a Mach kornyezetben a fajlkezelesnel peldaul egy-egy fajlrendszert osszekapcsolhat az }ot reprezentalo porttal vagy akar tobb }ot reprezentalo porttal, es amikor a kliens alkalmazas egy objektumnevr}ol az objektumot reprezentalo port hozzaferesi jogra akar konverziot vegezni, akkor a nev-szolgaltato az altala tarolt tobb port hozzaferesi jog kozul azt adhatja vissza, amelynek a szervere epp elerhet}o (ha tobb elerhet}o szerver is van,

akkor pedig mondjuk a legkevesbe leterhelt szerverhez ad vissza egy hozzaferesi jogot). Termeszetesen az is egy megoldas, hogy a nev-szolgaltato az osszes vagy a pillanatnyilag az osszes elerhet}o szerverhez visszaad egy-egy port hozzaferesi jogot, es a valasztast a kliens alkalmazasra bzza { mondvan, hogy a kliens alkalmazas ismerheti a szamara legjobb valasztasi strategiat, vagy az is lehetseges, hogy a nev-szolgaltato mindket megoldast biztostja. Lathato, hogy az atfedeses tarolas ilyen modon a rendszer sebessegenek csokkenesevel biztosthato, viszont ez elfogadhato, hiszen erthet}o, hogy ennek is (akar id}oben is merhet}o) ara van az egyszer}u, tobbszorozes nelkuli megoldashoz kepest. Megjegyezzuk, hogy jelenleg meg nem keszult olyan osztott, atfedeses tarolasu fajlrendszer, mely az alkalmazasok fele teljesen POSIX-konform programozoi interfeszt nyujtana, viszont ilyen iranyban ma is tortennek

kutatasok. A jelenlegi osztott fajlrendszer tervezesi elvekr}ol Tan92] tartalmaz egy osszefoglalast a kovetkez}o alapvet}o szempontokat kiemelve: Amit lehet a kliens oldali munkaallomasokon vegezzunk el, probaljuk a fajlszervereket tehermentesteni. Minel tobb informaciot cache-eljunk a halozati forgalom csokkentese erdekeben. A rovid elet}u, temporalis fajlokat ha lehet ne a szerveren taroljuk, ugyse lesz rajuk szukseg hosszabb id}on keresztul. Ne kelljen a rendszerre vonatkozoan globalis informaciokat tarolni. A teljes fajl-hierarchiat tobb szerverre is szetbonthatjuk, es megfelel}oen meg kell szervezni a fajlok tarolasaban reszt vev}o szerverek egyuttm}ukodeset az egy kozos fajl-hierarchia kialaktasa erdekeben. 5.6 A buer cache szerep(te)vesztese A memoria egy bytejahoz valo hozzafereshez szukseges id}o altalaban legfeljebb szaz nanoszekundum, mg egy diszk-blokk beolvasasara akar tobb, mint tz

ezredmasodperc id}ore is szukseg lehet. A ketfajta adathordozo eszkoz hozzaferesi ideje kozott lathato, hogy nagysagrendnyi kulonbsegek vannak. 86 Ezert a legtobb operacios rendszert { gy a POSIX-konformokat is { olyan fajlkezel}ovel szoktak ellatni, amely csokkenti a diszk-hozzaferesek szamat azon az aron, hogy egyes diszk-blokkokat id}olegesen eltarol a memoriaban, es csak akkor rja vissza a tartalmukat a diszkre, ha el}orelathatolag rovid id}on belul nem lesz rajuk szukseg (vagy ha a memoriara mas { esetleg "fontosabb" (peldaul fajlrendszer metainformacioit tartalmazo blokkok) { cache-elesere kell). A legtobb mar meglev}o POSIX-konform (vagy mas UNIX-szer}u) operacios rendszert amikor atrjak Mach mikrokernel alapura, kesztenek bel}ole egy egyszerveres POSIX szerver implementaciot, amelyben a fajlokat a 5.5 pontban lert modszerrel kezelik, akkor az a helyzet fordul el}o, hogy a fajlok

diszk-blokkjainak egy resze ketszeresen van cache-elve. Az egyik cache a Mach memoriaobjektum cache-je, a masik cache pedig a fent emltett buer cache. Mivel a Mach memoriaobjektum cache-je LRU (least recently used) strategia szerint m}ukodik, es a legtobb POSIX szerver fajlrendszere is ugyanezt a strategiat koveti, ez azt jelenti, hogy amikor a memoriaobjektum cache eldobott egy lapot, majd kes}obb vissza kellene olvasni, akkor nagyon nagy a valoszn}usege, hogy a buer cache is eldobta azt a lapot, gy az olvasast a diszkr}ol kell megtenni, ami viszont nagyon id}oigenyes. Vegyuk eszre, hogy a buer cache feladata a diszk-blokkok tarolasa, mg a memoriaobjektumokban leggyakrabban fajlok tartalmat cacheelik, gy megoldast jelenthet a problemara, ha a buer cache-t nem hasznaljuk fajlok blokkjainak a tarolasara, csak a fajlrendszer metainformacioit tartalmazo blokkokat taroljuk el benne (mivel azok nincsenek a fajlok memoria cache

objektumaiban). A buer cache-sel kapcsolatban meg meg kell emlteni azt, hogy a gyakorlatban nagyon hatekonynak bizonyult a valtozo meret}u (dinamikus meret}u) buer cache alkalmazasa az eddig nagyon elterjedt x darabszamu buereket tartalmazo buer cache-ekkel szemben (a Linux operacios rendszer tartalmazott az operacios rendszerek kozul nagyon koran egy ilyen feleptes}u buer cache-t, es a tapasztalatok szerint ilyen modon jobban kepes alkalmazkodni a kisebb es a nagyobb terhelesekhez egyarant { kisebb terheles eseten a tobb szabad memoriaban diszk-blokkokat tarolhat, majd a terheles novekedese eseten a memoriaba kerul}o ujabb es ujabb programok szamara a buer cache meretenek csokkentese aran biztost helyet, de ezzel csokkenti a rendszer m}ukodesehez szukseges virtualis memoria meretet, valamint noveli a rendszer virtualis memoriakezel}ojenek a hatekonysagat, mivel tobb a rendelkezesere allo lapkeretek

szama). Az eddigi szerver implementaciok { mivel altalaban valamelyik (legtobbszor a BSD) UNIX valtozatbol szarmaznak { nem tartalmaztak dinamikus buer cache implementaciot, hiszen az eredeti { nem Mach alapu, nativ { valtozatuk sem tartalmazott ilyent, a Mach rendszerre torten}o atteleptes soran pedig nem akartak a mar m}ukod}o rendszer lelkivilagaba belenyulni, mivel nem tudtak, hogy ez mennyibe kerulhet illetve mi az, amit egy ilyen modostason nyerhetnek. Meg kserleti jelleggel sem alatottak ki (tudtommal) dinamikus meret}u buer cache-sel rendelkez}o operacios rendszer szervereket, azzal sem foglalkoztak, hogy 87 ezt hogyan lehet implementalni. A hatekonysag noveleset megksereltek ugy, hogy a buer fejlecek mennyiseget28 nagyobbra alltottak, mondvan, hogy a Mach alapertelmezes szerint hasznalt memoria menedzsere szukseg eseten ugyis kilapozza a buereket a virtualis memoriaba { ezzel csokkentve a buer

cache memoriabol lefoglalt helyet, de ez nem jo megoldas { legalabbis a felhasznalok visszajelzesei ezt mutatjak, mivel a Mach mikrokernel egy-egy memoriaresz kilapozasakor nem tudja eldonteni, hogy melyik buert erdemes kilapozni: melyik van benn azert, mert valaki eppen hasznalja, illetve melyik van benn mar "csak" azert, mert igaz ugyan, hogy senki sem hasznalja, de meg nem volt szukseg mas diszk-blokkra, amit a helyere toltottek volna. Erre a problemara a BSD-szarmazek szervereknel29 szerintem jobb megoldast jelentene a dinamikus buer cache olyan megszervezese, hogy a buer strukturakat30 szukseg eseten lehetne allokalni, a korabbi x meret}u, buerfejleceket tartalmazo vektor helyett csak egy-egy { szukseg eseten allokalt buer fejlecre mutato { pointert tartalmazo tablazatot (vektort) kell felvenni, es e tablazat segtsegevel indexelhetjuk a buereket a tablazatbeli sorszamuk alapjan { erre a BSD

forraskodban van csak szukseg, mas rendszerekben erre nem feltetlenul van szukseg, ezt implementaciofugg}onek tekinthetjuk. A 44BSD ezen kvul a buereket egy hash-tablaba is bef}uzi, a benne tarolt diszk-blokk cme alapjan, a gyorsabb kereses erdekeben: erre tovabbra is hasznalhato a buer fejlecenek a cme. A dinamikus buer cache implementacio ugy m}ukodhet, hogy buer fejleceket egeszen addig ujat allokalhatunk, amg a rendszer nem kezdi el kilapozni a buerek adatteruletenek kijelolt memoriareszt. Ahhoz, hogy tudjuk, hogy a rendszer ezt elkezdi kilapozni, szukseges az, hogy a kilapozast ne (kozvetlenul) az alapertelmezes szerint rendelkezesre allo memoriakezel}o vegezze, hanem egy kozevetlenul erre a celra kijelolt memoriakezel}o. Amikor tehat a memoriakezel}o elkezdene a buereket kilapozni, akkor be kell alltani egy aget, amely megakadalyozza tovabbi buer-fejlecek szamara memoria allokalasat olymodon,

hogy szukseg eseten a memoriaban cache-elt, de nem hasznalt buerek kozul valaszt egy megfelel}o meret}ut, amelynek a tartalmat szukseg eseten31 visszarja a diszkre, majd az eredeti 4.4BSD-ben megszokott 28 A 4.4BSD UNIX-ban a buer fejlecek maximalis szamat a kern/vfs bioc forrasfajl (ld BSD]) tartalmazza az nbuf valtozoban, amely a rendszer indtasakor kerul inicializalasara, es az operacios rendszer m}ukodese soran nem modosul. 29 Termeszetesen ez a modszer nem csak a BSD-szarmazek rendszereknel alkalmazhato, de itt az ezeken a rendszereken szukseges modostasokat mutatom be { adott esetben a 4.4BSD forraskodjanak egyes elemeire hivatkozva, hogy a kep azok szamara is erthet}obb legyen, akik meg viszonylag keveset foglalkoztak ezzel az operacios rendszerrel. Meg a 44BSD mellett szol az is, hogy regebben egyertelm}uen a BSD-t tekintettek a kutatasok celpontjakent, egyetemeken hasznalando UNIX-oknak, es az eddig elkeszult Mach feletti POSIX szerverek majdnem mind a

BSD-b}ol szarmaznak. 30 A buer strukturan a buer fejlec-informacioit tartalmazo struct buf nev} u adattpust ertem { a deklaraciojat a include/sys/buf.h 44BSD forrasfajlban talalhatjuk meg (ld BSD]). 31 Ha a tartalma modosult, akkor kell visszarnia, ez pedig ellen} orizhet}o a buer struktura 88 modon intezkedik a buer ujrafelhasznalasarol. A buer cache merete akar csokkenthet}o is a buer fejleceknek fenntartott memoria es a buertartalomnak fenntartott memoria deallokalasaval. A rendszer lapozasi aktivitasatol fugg}oen lehet egyszer ugy donteni, hogy ujra megengedhetjuk a buer cache novekedeset, es ilyenkor ez a kor ujraindul. Egy dolog van, amire vigyazni kell: nem szabad olyan lapokat deallokalni, amelyre vonatkozoan meg egy I/O m}uvelet nem fejez}odott be, es meg kell akadalyozni azt is, nehogy a Mach alapertelmezes szerint rendelkezesre allo memoriekezel}oje kilapozzon ilyen lapokat. Az ilyen kilapozasokat a megfelel}o

lapok bedrotozasaval tehetjuk meg (ld. 312) b flags bitterkep-komponense alapjan (a B DELWRI bit bealltasa jelzi, hogy a buer tartalmat csak az ujrafelhasznalasa el}ott kell/erdemes a diszkre visszarni). 89 6 Mach feletti POSIX szerverek attekintese Ebben a fejezetben attekintjuk az eddig elkeszult Mach feletti UNIX/POSIX vagy UNIX-szer}u operacios rendszer szervereket: feleptesuket, es azt, hogy a POSIX szabvany mely reszet implementaljak. A szerverek feleptesenek targyalasakor nem targyaljuk reszletesen { sorrol sorra { a szerver forraskodjat: csak a Mach 3.0 mikrokernellel valo kapcsolatat akarjuk jellemezni ennek az az oka, hogy a legtobb szerver a BSD UNIX operacios rendszerb}ol szarmazik { annak gepfugg}o reszeit Mach szolgaltatasokat igenybevev}o eljarashvasokkal helyettestve benne, a BSD UNIX forraskodjarol pedig van egy azt reszletesen targyalo konyv (ld. 43BSDLe"er]-t a reszletekr}ol) 6.1 A POE

operacios k
ornyezet szerver A POE (Personal Operating Environment { szemelyi operacios rendszer) egy egyszer}u, inkabb egyfelhasznalos es tobbszalas operacios rendszer szerver { talan a legegyszer}ubb a Mach 3.0 mikrokernelen futo operacios rendszer szerverek kozul. Egy minimalis kieptettseg}u kornyezetet biztost mas osszetettebb, a Mach 3.0 mikrokernelre epul}o programok futtatasara alkalmas Egy transzparens emulacios konyvtarral rendszerhvasi szinten binarisan "alulrol" kompatibilis a BSD UNIX operacios rendszerrel { a POSIX szabvannyal: a legtobb POSIX szolgaltatas nincs implementalva rajta. A kovetkez}o { a POSIX szabvany altal is megkovetelt { BSD UNIX-bol is megismert szolgaltatasokat biztostja a klienseinek: 4.3 BSD UNIX UFS fajlrendszerer}ol fajlok olvasasa Karakteres eleres}u diszk-partciok rasa es olvasasa. Konzol periferia (/dev/console egyseg) biztostasa, melyre rni es arrol olvasni

egyarant lehetseges (a megfelel}o UNIX-szer}u terminal line discipline emulacioval egyutt). A rendszer teminal-vonalainak elerese rasra es olvasasra. A regi { nem megbzhato { signal szemantika. A fork() es exec() rendszerhvasok. Folyamatok kozotti kommunikacio pipe-okon keresztul. A POE szerver a fentieken kvul nem biztost mas lehet}osegeket, gy nincs lehet}oseg vele halozati kommunikaciora (a Berkeley socket rendszer hianya miatt), s}ot egy UFS fajlrendszerben uj fajl letrehozasara, vagy egy meglev}o fajl modostasara sincs lehet}oseg (ez erthet}o, hiszen a POE szervert gyakran hasznaljak mas operacios rendszer szerverek betoltesere, es gy biztonsagosan 90 elkerulhet}o az a problema, ami akkor fordulhatna el}o, ha egy operacios rendszer es a POE szerver ugyanazt a fajlrendszert egyszerre, szinkronizalatlanul modostjak). A POE a forraskodjanak szabad elerhet}osege, es a merete miatt (kb. 25000 C

nyelv}u sor) alkalmas arra, hogy rajta keresztul megismerjuk a tobbi { a POEhoz nagyon hasonlo feleptes}u { Berkeley UNIX-szarmazek operacios rendszer szerverek szerkezetet, gy { a nehezebben erthet}o struktura hjan { ennek a m}ukodeser}ol fogok nehany fontosabb momentumot lerni. A kovetkez}o alpontokban a POE szerver komponenseit fogjuk attekinteni: a transzparens emulacios konyvtarat, a POE szervert, es a szerver bootstrap kodot { amivel mas programok tolthet}ok a POE fole. 6.11 A POE emulatora Az emulator directory tartalmazza a transzparens emulacios feladatokat ellato emulator program implementaciojat. A POE szerver az els}o (poe init) processzel egyutt indtja el az emulatort, amely az osszes BSD UNIX rendszerhvast a POE szerverhez iranytja tovabbi feldolgozas celjabol. Az emulator minimalis mennyiseg}u gepfugg}o kodot tartalmaz, amely a rendszerhvas atiranytasi kodot es a regisztertartalmak

kezeleset vegzi. 6.12 A POE szerver A POE szerver a main.c fajl main() eljarasanal indul, ahol tobb adatszerkezet inicializalva lesz, a privilegizalt portokat lekerdezi a Mach kernelt}ol, majd a rendszerorat "beagyazza" a felhasznaloi folyamat memoriajaba. Ezutan inicializalva lesz a fajlrendszert kezel}o kod (ld. az ufs pagerc fajlban az ufs pager init() elj arast ez tartalmazza a fajlokat a felhasznaloi folyamatok memoriajaba "belapozo" memoriakezel}ot), illetve a "beagyazott" specialis fajlok kezeleset vegz}o memoriakezel}o threadek is el lesznek indtva (ld. az ajlban az ufs devpager init() eljarast). ufs devpager.c f Ezutan meg lesz hvva a server init() eljaras, amely inicializalja a POE szerver portjat (ez tartja a kapcsolatot a felhasznaloi folyamatokkal), es elindtja a server loop.c fajl server init() eljarasat, amely letrehozza a rendszerhvasokat feldolgozo threadeket (a jobb

hatekonysag erdekeben tobb { alapertelmezes szerint 4 { thread foglalkozik a szerver szolgaltatasok nyujtasaval). Ezutan a gyoker-directoryra ra lesz kapcsolva a gyoker-fajlrendszer, majd a szerver meghvja a bsd fork() eljarast, hogy vegrehajtsa az els}o folyamatot: betoltse az emulatort a fajlrendszerb}ol, ami inicializalja magat es vegul vegrehajtja a poe init programot. 91 6.13 A POE inicializalo programja A POE szerver/emulator inicializalasa utan ket alkalmazas lesz lefuttatva: a poe init  es a boot. Az el}obbi felel meg a BSD UNIX init programjanak: vegrehajtja a /mach servers/rc nev}u fajlban lev}o shell parancsokat (igaz a BSD UNIX e fajlt a /etc directorybol futtatja). A boot egy olyan program, amely mas szerverek betolteset, inicializalasat teszi lehet}ove: kepes elindtani mas szervereket a fajlrendszerb}ol, es ez adja at az ujonnan elindtott szervereknek a privilegizalt portokat (amit a boot program a

Mach mikrokernel alapertelmezes szerinti memoriakezel}ojet}ol kapott). 6.2 Az OSF/1 operacios rendszer csalad Az Open Software Foundation OSF/1 operacios rendszere egy, a Mach 2.5 operacios rendszer magjara epul}o operacios rendszer (ami meg a rendszermagban tartalmazza a 4.3BSD operacios rendszer kodjat), ami meg ki van egesztve szamos mas szolgaltatas nyujtasaval is, mint peldaul tobbprocesszoros osztott kozos eleres}u memoriaval rendelkez}o hardver egysegeket tamogato kodreszekkel, az Orange Book OB83] B1 szint}u biztonsagossagi kovetelmenyeinek a teljestesevel, logikai diszkek kezelesevel (ami lehet}ove teszi tobb kisebb meret}u hard diszk egyetlen, nagyobb meret}u virtualis diszkkent valo hasznalatat). Az OSF az OSF/1 operacios rendszerenek es az OSF/1 szervereinek a forraslistajat uzleti titokkent kezeli, gy ennek es a tobbi OSF/1 szervernek a szerkezetet csak a roluk rt konyvekb}ol (pl.

Oreilly91], OSF 90]) lehet megismerni Ez az operacios rendszer az osszes POSIX szolgaltatast nyujtja a magjaba integralt 4.3BSD kod segtsegevel { igaz, hogy nem a Mach mikrokernelre strukuralva. 6.3 Az OSF/1 MK szerver Az OSF/1 MK szerver ugy lett implementalva, hogy { elter}oen a korabban mar elkesztett CMU UX szervert}ol { az emulator reszet egyszer}uen kihagytak abban bzva, hogy gy hatekonyabb POSIX-konformitast tudnak elerni, es ezzel egyutt a Mach mikrokernelt is modostottak ugy, hogy a taszkok a POSIX szerver taszk kivetelevel ne tudjanak Mach rendszerhvasokat vegrehajtani { ezzel kuszoboltek ki az exhibicionista taszkok okozta problemakat. Az emulator mell}ozese uj problemakat vetett fel: mivel a copyin() es a copyout() (ld. 43BSDLe"er]) m} uveletek argumentumait a szervernek csak egesz lap meret}ure kerektve lehet atadni, nem lehetett tobbszalas programot minden esetben helyesen futtatni, mivel

el}ofordulhatott, hogy parhuzamosan vegrehajtott rendszerhvasok ugyanannak a lapnak egy-egy reszet hasznaltak egyszerre (peldaul amg az operacios rendszer szerver egy copyout() m}uveletet hajtott vegre, addig lehet, hogy egy masik szalon a program mar modostotta ugyanannak a lapnak a tartalmat). 92 Egy masik problema a Mach rendszerhvasok POSIX folyamatok el}ol torten}o letiltasa volt: ez lehetetlenne tette egyes OSF/1 operacios rendszerre rt alkalmazasok atvitelet az uj OSF/1 MK szerver kornyezetbe. 6.4 Az OSF/1 AD szerver Ebben a pontban bemutatom az OSF/1 szerver sokprocesszoros multicomputerekre keszult valtozatat: annak architekturajat es implementaciojat. Ez az egyetlen olyan szerver implementacio, mely hatekonyan ki tudja hasznalni akar a tobb tzezer processzort tartalmazo multicomputereket is, gy erdemes megtekinteni ennek az architekturajat, tervezesi szempontjait is. Err}o fog szolni a lerasnak ez a

pontja, valamint ennek alpontjai is. 6.41 Tervezesi celok Az OSF/1 AD szerver keszt}oinek a legf}obb celja az volt, hogy egy elosztott operacios rendszert kesztsenek, amely lehet}ove teszi a sokprocesszoros hardver eszkozok optimalis es b}ovthet}o kihasznalasat, megmaradva az OSF/1 es POSIX operacios rendszer szabvanyokkal valo kompatibilitasnal. Ez alapjan a kovetkez}o tervezesi szempontokat t}uztek ki maguk ele a rendszer tervez}oi: A rendszerben egyetlen fajlrendszer legyen kialaktva, mely azonos modon elerhet}o legyen az osszes komponens szamtogepr}ol, es az egesz rendszerre vonatkozoan a fajleleresek a szokasos POSIX szemantikat kell, hogy kovessek. A rendszer b}ovthet}oseget nem szabad centralizalt strukturaju komponensekkel korlatozni, gy elosztottan kell megtervezni a kovetkez}o { eddig nem gy elkesztett { rendszerkomponenseket is: { Fajlrendszer { A kulonfele halozati/kommunikacios protokollok

hierarchiajat. { Processzek kezeleset. Az elosztott rendszer osszes csomopontjan az ott futo processzeknek modjuk kell legyen a POSIX szolgaltatasainak a teljeskor}u eleresere. A mar meglev}o ipari szabvanyokkal (POSIX 1003.1, SVID, XPG/3) teljes kor}u kompatibilitast kell biztostani. Az osszes alkalmazasnak legyen lehet}osege a rendszer elosztottsagabol ered}o hasznos lehet}osegek kihasznalasara (peldaul az operacios rendszer nyujtson valamilyen automatikus terheleselosztasi lehet}oseget az egyes "kedveltebb", konnyebben hozzaferhet}o csomopontok terhelesenek csokkentesere). 93 6.42 Architektura Az OSF/1 AD operacios rendszer feleptese az alapul szolgalo hardver szerkezetet koveti: minden egyes csomoponton fut a Mach 3.0 mikrokernel egy peldanya, kommunikacios, taszk es thread-kezelesi feladatokat ellatva, es elerest biztost a kulonfele periferiakhoz. Kulonfele specialis celu,

felhasznaloi uzemmodban futo szerverek biztostjak a UNIX ill. POSIX funkcionalitast, mint peldaul a fajlkezelest, folyamatkezelest, valamint a halozat kezeleset. Az OSF/1 AD szolgaltatasait hasznalo folyamatok kezelese is elosztott modon van magvalostva. Tovabba minden egyes folyamat virtualis cmtartomanyaban van egy-egy emulator bizonyos UNIX / POSIX funkcionalitasok biztostasara, valamint ezzel alaktjak a rendszerhvasokat Mach uzenetekke, amit a megfelel}o { az adott tpusu rendszerhvas feldolgozasaert felel}os { szervernek tovabbt: a folyamatkezel}o rendszerhvasokat a folyamatot tartalmazo szamtogepen futo processz-szerverhez, mg a fajlkezelessel kapcsolatos rendszerhvasokat az adott fajlt tartalmazo fajlrendszert kezel}o fajlszerverhez iranytja. 6.43 Megvalostas { POSIX konformitas Ebben a pontban attekintem az OSF/1 AD megvalostasakor a POSIX konformitas erdekeben meghozott

donteseket. A rendszeren belul tobb csomopont is nyujthat fajlszerver szolgaltatasokat, mindegyik szerver egy vagy tobb reszfajlrendszer kezeleseert lehet felel}os a mount (fajlrendszerek osszeillesztese) m}uvelet pedig az egyetlen fajlnev-rendszer kialaktasat szolgalja. A fajlrendszer hatekonysagat a kliens oldali cache-elessel (Mach absztrakt memoria objektumokkal megvalostva) novelik a legtobb fajlkezel}o m}uvelet legfeljebb egy halozati uzenet elkuldeset ill. fogadasat eredmenyezi (amennyiben a m}uvelet elvegzesehez szukseges informaciok a kliens oldali cache-ben nem allnak rendelkezesre). A fajlszerverek az altaluk kezelt fajlrendszereket egyenkent egy-egy porttal reprezentaljak a mount m}uvelet lenyegeben ennek a { fajlrendszert reprezentalo { portnak a tovabbadasat jelenti arra a csomopontra, amely azt a directoryt tartalmazza, amelyre a tavoli fajlrendszert ra akarjak mountolni (ld. a 141 pontban az

altalanos modell lerasat). A fajlnevek feldolgozasa ugyanugy tortenhet, mint ahogyan az az OSF/1 rendszerben megy, azzal a kulonbseggel, hogy ha a fajlnev valamely komponense egy tavoli fajlrendszeren helyezkedik el, ott kell a keresest folytatni, akkor a fajlnev hatralev}o resze a fajlrendszer megfelel}o reszet tartalmazo tavoli csomopontnak kerul atadasra. A fajlkezelesi m}uveletekkel kapcsolatban az emulator tartalmazza a folyamatonkent nyilvantartott fajldeszkriptor-tablat, ami a fajldeszkriptorokat es a nekik megfelel}o fajlt reprezentalo portot tartalmazza, tartalmazza a munkadirectoryt es a gyokerdirectoryt reprezentalo portjat. A kliens oldali eljarasoknak { a POSIX-konform rendszerhvasoknak { nincs mas dolguk, mint a megfelel}o 94 (fajlt vagy directoryt reprezentalo) porthoz a megfelel}o uzenet elkuldese, es az uzenetet feldolgozo szerver valaszat visszaadjak a rendszerhvast vegrehajto programnak. A

POSIX fajl I/O, fajlmegosztasi szemantikat egy token rendszer segtsegevel implementaljak benne: minden egyes megnyitott fajlhoz tartozik egy token, amely a tobb olvaso illetve egyetlen ro folyamat hozzafereset szinkronizalja. A tokent a folyamat a fajl megnyitasakor megkapja, es hasznalhatja, amg valaki mas el nem "szedi" azt (egy read() ill. write() rendszerhvas vegrehajtasakor az emulator ellen}orzi, hogy megvan-e a fajlrasahoz szukseges token, es ha megvan, akkor elvegzi a megfelel}o m}uveletet, ha pedig nincs meg, akkor megszerzi azt a token jelenlegi tulajdonosatol, es azutan vegezheti el az adott fajlm}uveletet { azt pedig, hogy kinel van a token, a fajlszerver tudja tarolni, attol lekerdezhet}o). A kommunikacios vegpontok absztrakcioinak az implementacioja annyival modosult, hogy a 4.3BSD-ben mar meglev}o virtualis fajlrendszer mintajara bevezettek a virtualis socket rendszer reteget, amely elrejti a

tobb szamtogepes architekturat a socket manipulacios reteg el}ol (ilyen modon a socket rendszer altal implementalt halozati protokollok egyes retegei kulonboz}o szamtogepekre telepthet}o, s}ot a virtualis socket reteg a protokoll-retegek kulonboz}o hostokon futo implementacioi kozott is meg tudjak teremteni a kapcsolatot). A UNIX domain socketokkal kapcsolatban fontos megemlteni, hogy az }oket reprezentalo adatszerkezetek konnyen atkoltoztethet}ok az egyik szamtogepr}ol a masikra, ami lehet}oseg olyankor hasznos, amikor egy folyamatot atkoltoztetnek az egyik csomopontrol a masikra, mivel a UNIX domain socketjai konnyen vele koltoztethet}ok: az adatatvitel sebessege nem csokken (ui. a socket elerese nem megy keresztul koltoztetesenkent egy-egy indirekcios szinten). A folyamatkezeles elosztotta tetele a virtualis folyamat reteg bevezetesevel lett megoldva: az OSF/1 AD szerver a folyamatokat mint virtualis

folyamat objektumokat latja es kezeli az egyes folyamatok zikai elhelyezkedese csak egy un. virtualis folyamat tablazatban van eltarolva, amelynek segtsegevel a folyamatkezel}o m}uveletek a megfelel}o (megcelzott) folyamatot tartalmazo csomopontra lesznek iranytva. A folyamatkezel}o alrendszer lehet}ove teszi folyamatok letrehozasat tavoli csomopontokon, valamint lehet}ove teszi a mar futo folyamatok elkoltozteteset az egyik csomopontrol a masikra. 6.5 A jbss szerver Az utobbi ket ev folyaman a Mach lehet}osegeinek tanulmanyozasa kozben elkesztettem egy egyszer}u szervert illetve programkonyvtarat, amellyel egyszer}ubb alkalmazasok elkeszthet}ok ugy, hogy a konyvtar nehany POSIXszer}u operacios rendszer szolgaltatast kepes biztostani az alkalmazasoknak. Termeszetesen a szolgaltatasok mennyisege es "sznvonala" messze nem eri el a POSIX (ld. IEEE90]-et) igenyeit, viszont alkalmas arra, hogy a Mach

mikrokernel lehet}osegeit rajta keresztul tanulmanyozzuk 95 Szerkezetet, felepteset tekintve ez egy egyszerveres megoldas (mivel { lenyegeben { egyetlen szerver (bizonyos funkciokat pedig egy konyvtar) nyujtja az operacios rendszer szolgaltatasokat), de a kifejlesztett mechanizmusok (az operacios rendszer szervereket betolt}o bootstrap program, es a kommunikaciot megszervez}o machid szerver) ugy vannak megtervezve es implementalva, hogy modostas nelkul el tudjak latni a feladataikat tobb szerverb}ol allo operacios rendszer szoftverek eseteben is. 6.51 A jbss szerver lehet}osegei A jbss szerver rendszer a kovetkez}o POSIX-bol is ismert szolgaltatasokat biztostja a felugyelete alatt futo programoknak: MINIX fajlrendszerr}ol fajlok olvasasa es MINIX fajlrendszeren lev}o fajlok rasa. Konzol biztostasa, melyre rni es arrol olvasni egyarant lehetseges (a terminal line discipline emulacio nelkul). A fork() es

exec() rendszerhvasok. Mach szolgaltatasainak az elerese. A szerver nem biztost mas lehet}osegeket (halozati kommunikacio, POSIX folyamatok kozotti kommunikacio, terminal line discipline modulok). A szerver nem biztost binaris kompatibilitast egyetlen mar letez}o operacios rendszerrel (ui. egy POSIX-konform rendszerrel valo kompatibilitas biztostasanak nincs ertelme, mivel a programoknak keves szolgaltatast tudna nyujtani, a meglev}o programoknak csak kis szazaleka lenne hasznalhato). A jbss szerver nem hasznal transzparens emulacios konyvtarakat { abban az ertelemben, ahogyan ezt a kifejezest a korabbiakban hasznaltuk (az el}obbiek alapjan lathato, hogy a binaris kompatibilitast nincs ertelme er}oltetni), viszont egyes szolgaltatasok (kulonosen a fajlrendszer szolgaltatasok) az alkalmazashoz linkelt konyvtar reszekent vannak implementalva. 6.52 A szerver installalasa A jbss szerver fejlesztese Linux

kornyezetben, el}oszor az ext2mach, majd pedig a Mach4 Mach 3.0 mikrokernel valtozaton tortent A szerver hasznalatahoz es ujrafordtasahoz en a Mach4 szoftver installalasat javaslom (egyreszt azert, mert en is ezt hasznalom, a szabad elerhet}osege miatt az Internetben lev}o Mach4 levelezesi lista tagjai gyakorlatilag az osszes sulyos hibat kijavtottak benne, tobbfele fajlrendszert is tud hasznalni lapozasra illetve szerverbetoltesre), de semmi akadalyat nem latom annak, hogy az ext2mach kornyezetben hasznaljuk. Meg egy ok van a Mach4 hasznalatara: az, hogy az ujrafordtast vegz}o scriptek 96 erre vannak elkesztve, de a ext2mach hasznalata eseten kis rafordtassal megtalalhatjuk a szukseges konyvtarakat. A szerver hasznalatahoz el}oszor installalni kell a kvant Mach 3.0 szoftver, majd letre kell hozni egy diszk-partciot es egy fajlrendszert (olyant, amir}ol a Mach szoftverunk be tudja bootolni a

szerverunket, es tudja hasznalni a rajta lev}o lapozasi celra kijelolt fajlt { lasd err}ol reszletesebben a megfelel}o Mach disztribucios anyaghoz jaro dokumentaciokat). A letrehozott uj partciora masoljuk at a jbss forraskod mfs directoryjabol a lefordtasa utan letrejov}o startup nev}u programot oda, ahol az altalunk hasznalt Mach rendszer az els}o szervert varja (ez altalaban a /mach servers directory). A szerverunk futtatasahoz egy ures lemezen hozzunk letre egy MINIX fajlrendszert. A forrasanyag jbss directoryjaban lev}o jbss fajlt masoljuk az el}obbi lemez gyokerdirectoryjaba, es masoljuk oda init neven az elindtando els}o taszkot (UNIX-szer}u rendszereken ennek a neve konvencionalisan init). Ezutan elindthatjuk a rendszerunket, a Mach operacios rendszer mikrokernel megkerdezi a szerver helyet, es a program ezutan problemamentesen fog futni. 6.53 A szerver szerkezete Ebben a pontban roviden bemutatom a jbss

szerver szerkezetet. Nem megyek le mindenutt a forraskod szint}u ismertetes reszletezeseig, mivel az ilyen ismeretek megszerzesere hasznalhato maga a forraskod is, itt csak a fontosabb jellemz}oket fogom lerni. A betolt}oprogram A jbss szerver komponenseinek a betolteset vegz}o eljaras az mfs directoryban talalhato a forraskodban. A betolt}oprogram futasa a startupc fajlban indul: letrehozza az els}o felhasznaloi taszkot, es elindtja benne a magneslemezen32 a gyokerdirectoryban lev}o jbss fajl tartalmat, es miutan elindtotta ezt a taszkot, vegrehajtja a port hozzaferesi joghoz egy egesz szam asszociaciojat vegz}o machid szerver kiszolgalo ciklusat (err}ol reszletesebben lasd a 4.34 pontban lev}oket { a machid szerverr}ol az abban a fejezetben lev}o ismertet}o a machid szerver jbss-beli implementaciojara vonatkozik). A betolt}oprogram tartalmaz tovabba egy fajlrendszerkezel}o modult a tovabbi szerverek betoltesere,

valamint egy POSIX fork/exec rendszerhvas szemantikat biztosto modult a tovabbi szerverek elindtasara. 32 Az elkesz ult implementacioban a oppy-diszkr}ol dolgozik a rendszer { ennek az oka az, hogy a fejlesztes helyen (egy i386-os PC-n) nem volt tobb szabad partcio a program tesztelesehez (a fajlrendszer kifejlesztese utan tesztelve lett winchesteren is, es hibatlannak bizonyult). Semmi ok nincs arra, ami miatt azt mondhatnank, hogy a program nem tud egyuttm}ukodni winchesterekkel. 97 A jbss szerver elindulasa A tenyleges szerver forraskod ket directoryba van felbontva: az egyik a directory, a masik a jbss/interface directory. Az el}obbi tartalmaz fajlrendszer es folyamatkezel}o kodot, az utobbi pedig a szerver es az alkalmazasok kapcsolatat megszervez}o elemeket tartalmazza. A szerver vegrehajtasa a jbss/server/startup.c fajlban indul Ez letrehozza az els}o felhasznaloi taszkot, elindtja benne a gyokerdirectorybol betoltott init

programot, es elindtja a kliensek kereseit varo threadet (miutan a jbss/interface directory uxserv.c fajljaban lev}o register ux task() eljarasa regisztralta a szerverunk eleresi portjat a machid szervernel). A szerver egy resze (a fajlrendszerkezel}o resz, valamint az interfesz resz (ez a jbss/interface directory), valamint kliens specik aciojabol (ezt tartalmazza a jbss 1.defs fajl) keszult kliens csonk) az alkalmazoi programokkal (gy az init programmal is)  ossze lesz linkelve. A szerver { lenyegeben { az egyetlen olyan funkciot latja el, amit a konyvtar nem tud: a fork rendszerhvas feladatat. jbss/server A jbss szerver forraskodja A szerver forraskod a kovetkez}o fajlokbol all (a fajlok neve utan lertam roviden azok feladatat is): bitmap.c : A diszk-blokk illetve az i-node t ablazat foglaltsagi bitterkepet kezel}o eljarasokat tartalmazza. device.c : A Mach perif eriakkal kapcsolatot tarto eljarasokat

tartalmazza. Ez tartalmaz egy buer-menedzsert, amely a hasznalatban lev}o buereket ideiglenesen a memoriaban hagyja, es a szukseges referenciaszamlalasokat is elvegzi. dir.c : A directoryk  es a directorybejegyzesek kezeleset tartalmazo kodreszeket tartalmazza. exec.c : Az exec() POSIX rendszerhv as kezeleset megvalosto eljarasokat tartalmazza. fork.c : A fork() POSIX rendszerhv as kezeleset megvalosto eljarasokat tartalmazza. icache.c : A haszn alatban lev}o fajlok i-node-jainak az indirekt blokkjainak a memoriabeli cache-eleset vegz}o eljarasokat tartalmazo modul. inode.c : A haszn alatban lev}o fajlok i-node-jainak a memoriabeli cacheeleset vegz}o kodreszeket tartalmazza. namei.c : F ajlnevr}ol i-node sorszamra valo transzformaciot vegz}o eljarast tartalmazza. 98 : Fajlokat ro es olvaso eljarasokat tartalmazo modul. startup.c : Kor abban mar emltettem a szerepet. El}oszor betolti az els}o

felhasznaloi taszkot, majd elindtja azt, es varja a kliensekt}ol a kereseket tartalmazo uzeneteket. super.c : A f ajlrendszer szuperblokkjat (ez a 0. blokk, ld Tan87]-et) kezel}o eljarasokat tartalmazza. trunc.c : A trucate() rendszerhv ast kezel}o kodot tartalmazza. ulib.c : A felhaszn aloi konyvtarakba kerul}o eljarasokat tartalmazza. rw.c 99 7 Osszefoglalas A dolgozatban megvizsgaltam a POSIX 1003.1 operacios rendszer szabvany kliens-szerver modell keretein belul torten}o implementalhatosagat a Mach 3.0  mikrokernelen. Osszess egeben megallapthatjuk, hogy a POSIX 1003.1 megvalosthato a Mach 30 felett, azokkal a korlatokkal illetve jellemz}okkel, amit az osztott (opreacios) rendszerekkel kapcsolatban megadtunk az 1. pontban, az ott ismeretettek kozul az atfedeses tarolas (replication) kivetelevel, mivel a Mach 3.0 onmagaban nem biztost ilyen cellal hasznalhato eszkozoket Termeszetesen ez szimulalhato a Mach

felett az 5.5 pontban bemutatottak szerint Ugyanitt javaslatot tettem egy ujfajta { hatekony nev-szolgaltato mechanizmus elkesztesere, amely lehet}ove teszi az atfedeses tarolas altalanos (minden szerverre vonatkozoan alkalmazhato) megvalostasat. A dolgozatban kidolgoztam egy technikat, amivel hatekonyan implementalhatok objektum-orientalt szerverek a Mach 3.0 mikrokernel felett (ramutatva arra, hogy egyes reszletek implementalasat, mint peldaul az automatikus szemetgy}ujtes, milyen modon tamogatja a Mach). Ez azert is kulonosen hasznos, mivel az objektum-orientalt szoftvertervezes jol tamogatjaaz elosztott alkalmazasok keszteset, mivel az objektumok { mint a bels}o allapotot teljes egeszeben tartalmazo es elrejt}o egysegek { megfelel}o metodushvasi mechanizmusokkal a program eredeti strukturajat megtartva trivialisan szetoszthato egysegeknek tekinthet}ok: ezzel az objektum-orientalt modon megtervezett

alkalmazasok a legtermeszetesebb modon oszthatok szet { a megfelel}o nevszolgaltato (ld. 55 pontot) hasznalataval A dolgozatban tovabba foglalkoztam olyan kerdesekkel, mint a dinamikus buer cache megvalostasa (erre egy megoldast adtam az 5.6 pontban), es foglalkoztam az exhibicionista kliensek problemajaval, az eszkozmeghajtok kezelesenek a problemajaval es az er}oforrasfalo taszkok okozta problemakkal az 5.4 pont alpontjaiban) A dolgozatban ezen kvul reszletesen megvizsgaltam az egy- illetve tobbszerveres implementacio kerdeset (ld. 52 pontban), a transzparens emulacios konyvtar szerepevel es hasznossagaval (ld. 533, 63, 642 pontokat) Megallapthato, hogy mind az egyszerveres, mind a tobbszerveres POSIX emulacios forma mellett es ellen is szolnak ervek, de az ujabb nagyteljestmeny}u szervereket tobbszerveres atfedeses elerest is biztosto technologiaval kell elkeszteni. A dolgozat reszletesen targyalja

az alkalmazas es a POSIX szerverek kapcsolatanak a problemajat (ld. err}ol reszletesebben az 531, 532, 533 pontokat) Egyik megoldas sem tekinthet}o tokeletesnek, de a tavoli eljarashvas (Mach uzenetek kuldese) t}unik a legmegfelel}obbnek az alkalmazas es a szerver kapcsolatanak a megszervezesere, a kliens oldali (emulacios konyvtarbeli) cache-elessel a vegrehajtas gyorstasa erdekeben. 100 8 Irodalomjegyzek Barrera93] - Copying, caching and sharing in a distributed virtual memory system Joseph Barrera Ph.D tezis Carnegie-Mellon univ. 1993 Birman87] - Exploiting virtual synchrony in distributed systems Kenneth P. Birman, Thomas A Joseph Cornell University, Department of Computer Science Technical Report. TR 87-811 Febuary, 1987 Birman89] - The Role of Order in Distributed Programs Kenneth Birman, Keith Marzullo Cornell University, Department of Computer Science Technical Report. TR 89-1001 May, 1989 BSD] - Berkeley Software Distribution

4.4BSD Lite University of California, Berkeley (A 4.4BSD operacios rendszer forraskodja) (Elerhet}o anonymous FTP-n) Farr95] - Advanced UNIX and Internet Security Rik Farrow (Az 1995-os, Budapesten a HUUG szervezeseben megtartott "Internet Security" Konferencia kiadvanya.) Flynn72] { Some Computer Organizations and Their Eectiveness M. J Flynn IEEE Transactions on Computers vol. C-21 September, 1972 Horus93] - The Horus System Robbert van Renesse, Ken Birman, Robert Cooper, Brad Glade, Patrick Stephenson 101 Cornell University, Department of Computer Science Technical Report. July 28, 1993 IEEE90] - "Information Technology { Portable Operating System Inter- face (POSIX) Part 1: System Application Program Interface (API) C Language]" 1003.1-1990 IEEE December, 1990 JmsMUS94] - Client-Server Interactions in Multi-Server Operating Systems: The MachUS Approach J. Mark Stevenson, Daniel P Julin (Elerhet}o az Interneten az ftp.cscmuedu

szerverr}ol barki szamara) JmsMUS95] - Mach-US: UNIX On Generic OS Object Servers J. Mark Stevenson, Daniel P Julin (Elerhet}o az Interneten az ftp.cscmuedu szerverr}ol barki szamara) Rosenthal90] - Evolving the Vnode Interface David S. H Rosenthal USENIX Summer Conference June 11-15, 1990 4.3BSDLeer] - The Design and Implementation of the 43BSD UNIX Operating System Samuel Le"er, Marshall Kirk McKuisk, Michael J. Karels, John S Quarterman Addison-Wesley, 1989 Nelson81] - Remote Procedure Call B.J Nelson Ph.D dolgozat Carnegie-Mellon University, 1981 OB83] - Orange Book Department of Defense Trusted Computer System Evaluation Criteria 102 August 15, 1983 CSC-STD-001-83 ODRI93] - DCE RPC internals and Data Structures Revision 1.0 August, 1993 Open Software Foundation (Elerhet}o WWW-en a www.osforg szerverr}ol a bejegyzett Machfejleszt}oknek) ODARPCS94] - DCE AES Remote Procedure Call Specication Revision 1.1 October 18, 1994 Open Software Foundation

(Elerhet}o WWW-en a www.osforg szerverr}ol barki szamara) OReilly 91] - Guide to OSF/1: A Technical Synopsis OReilly & Associates, Inc. 1991 OSF 90] - The Design of the OSF/1 Operating System Open Software Foundation 1990 OSF92] - Mach 3 Server Writers Guide Szerkesztette: Keith Loepere Open Software Foundation and Carnegie Mellon University July 15, 1992 (Elerhet}o anonymous FTP-n) OSF92r] - Mach 3 Kernel Interfaces Szerkesztette: Keith Loepere Open Software Foundation and Carnegie Mellon University July 15, 1992 (Elerhet}o anonymous FTP-n) Rick89] - Mach: A foundation for open systems Richard Rashid, Robert Baron, Alessandro Forin, David Golub, Michael Jones, 103 Daniel Julin, Douglas Orr, Richard Sanzi Megjelent: "Proceedings of the Second Workshop on Workstation Operating Systems" 109-113. oldalan IEEE Comupter Society September, 1989 Tan87] - Operating Systems - Design and Implementation Andrew S. Tanenbaum Prentice-Hall, International ISBN

0-13-637331-3 1987 Tan90] - Computer-Netzwerke Andrew S. Tanenbaum Wolframs Fachverlag ISBN 3-925328-079-3 1990 Tan92] - Modern Operating Systems Andrew S. Tanenbaum Prentice-Hall, International ISBN 0-13-595752-4 1992 104