Mehanizmi razmjene poruka ostvareni preko RPCa
Upcoming SlideShare
Loading in...5
×
 

Mehanizmi razmjene poruka ostvareni preko RPCa

on

  • 390 views

 

Statistics

Views

Total Views
390
Views on SlideShare
390
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Mehanizmi razmjene poruka ostvareni preko RPCa Mehanizmi razmjene poruka ostvareni preko RPCa Document Transcript

  • Zagreb12/20/93Mehanizmi razmjene poruka ostvareni pozivima udaljenih funkcijaSadržaj:Razmotriti načine komunikacije između procesa razmjenom poruka. Odabrati skup osnovnihoperacija te pripadne strukture podataka. Predložiti ostvarenje tog skupa operacija uokruženju zasnovanom na pozivima udaljenih funkcija. Posebice istražiti metode susreta ipoštanskih7 sandučića. Predložiti načine ostvarenja nadzornog procesa poštanskih sandučića.Sačiniti opis predloženih postupaka u obliku specifikacije prikladne za vrednovanje i ocjenuispravnosti ostvarenja.0.UvodOstvarivanje distribuiranih sustava ovisi o međuprocesnoj komunikaciji i sinkronizacijiprocesa koji čine distribuirani sustav. Osnova metoda ostvarivanja međuprocesnekomunikacije je razmjena poruka između procesa. Usklađivanje procesa i složenih sustavarazmjenom poruka naročito dolazi do izražaja u umreženim sustavima u kojima prijenospodataka i komunikacija u drugim formama gotovo i nisu moguće.Efikasnim ostvarivanjem mehanizama za prijenos poruka između procesa na umreženimsustavima dobiva se osnova za ostvarivanje distribuiranog operacijskog sustava i može sepostići daleko bolji i pouzdaniji rad procesa koji čine distribuirani sustav /TAN89/,/MALA89/. /COMM89/, /COMM91/, /COMM93/, /MAEK87/.Ovisno o vrstama računalnih sustava na kojima se grade distribuirani sustavi i sredstvimapogodnim za izgradnju distribuiranih sustava potrebno je koristiti najpogodnija sredstva kojaomogućuju maksimalno poopćavanje svojstava platforme. U slučaju da se distribuirani sustavgradi na osnovi specifičnih računala ili vrlo specifičnog operacijskog sustava potrebno je domaksimuma prilagoditi se mogućnostima tog sustava (primjer operacijskog sustava QNX zarad u stvarnom vremenu koji posjeduje mehanizme za mrežni prijenos poruka kao diooperacijskog sustava /KOLN89/). U slučaju da se distribuirani sustav planira koristiti u širemokruženju potrebno je prilagoditi se postojećim preporukama i standardima, stoga je potrebnouvažiti pravila i preporuke za izgradnju otvorenih sustava. Isto tako potrebno je uvažiti građute način funkcioniranja ciljnog operacijskog sustava. Kao primjer za potrebe prilagođavanjaciljnom operacijskom sustavu može se navesti operacijski sustav UNIX i izvedba mrežnepodrške na njemu /STE90/. U slučaju UNIX-a pristup mrežnom sklopovlju odvija se krozjezgru sustava, dok se više funkcije upravljanja ostvaruju nizom autonomnih nadzornihprocesa (engl. deamon) /AND90/, /STE90/.
  • Slika 0: Model protokolskog sloga otvorenog sustavaPrema standardnom modelu protokolskog sloga otvorenog sustava /KONG90/, /TANN89/(slika 0) distribuirana aplikacija i distribuirani sustav se funkcionalno ostvaruju u sedmomsloju modela, dok ostali niži slojevi modela pružaju usluge podrške radu aplikacije. Prematome, u skladu s filozofijom otvorenih sustava mehanizme međuprocesne komunikacije isinkronizacije treba ili koristiti kao usluge nižih slojeva modela ili ih treba razvijati u štovišim slojevima kao specifične usluge ili aplikacije. Takav pristup na prvi pogled ne dajedovoljnu slobodu pri razvoju, ali omogućava kompatibilnost s postojećim sustavima. Pri tomeje sva komunikacija, obrada grešaka, transformacije formata i adresa, te pristup mrežiodvojena od elemenata distribuiranih procesa. Svi elementi distribuiranog procesa surađujukroz mehanizam komunikacije i sinkronizacije koji se realizira kao usluga nižih slojevamodela i prenosivi su na razne platforme na stupnju prenosivosti jezika kojima su ostvareni, tealata koji su pri tome korišteni.Na standardnim operacijskim sustavima postoje mehanizmi prijenosa poruka ili mehanizmikoji dozvoljavaju emulaciju prijenosa poruka između procesa. Ti mehanizmi obično imaju nizprilagođenja za rad postojećeg okruženja pa je često potrebno izvesti značajne izmjene nanjima. Jedan takav mehanizam koji omogućuje prijenos poruka između procesa je upotrebapoziva udaljenih procedura (engl. Remote Procedure Calls, RPC) koji omogućuje atomarnoprenošenje argumenata i rezultata između izvršioca klijenta i uslužitelja. Pri tome je zaprocese transparentno postojanje mreže računala. /RFC57/, /SUN01/, /SUN02/, /SUN03/,/SCO1/, /SCO2/, /SCO3/, /SHC92/.
  • Mehanizam poziva udaljenih procedura se gradi na osnovi komunikacije putem pristupnihtočaka (engl. sockets) kao osnovnog sloja komunikacije u domeni jednog računala i umrežnoj domeni.Ostvarivanje osnovnih operacija za prijenos poruka između procesa može se izvesti pomoćupoziva udaljenih procedura čime se postiže dodatna ugradnja sigurnosti i efikasnosti u sustavprijenosa poruka između procesa, te uniformnost i nezavisnost od mreže računala.U prvom poglavlju rada se općenito definira međuprocesna komunikacija prenošenjemporuka. Tu se definiraju procesi koji sudjeluju u prijenosu poruka, te osnovna građa samihporuka, uz prikazivanje odnosa tih procesa, operacijskog sustava i mrežne podrške togoperacijskog sustava. Osnovne metode prijenosa poruka i osnovne operacije definiraju se udrugom poglavlju, gdje se ujedno razmatra i ponašanje svakog od procesa u prijenosu poruka.Ostvarivanje prijenosa poruka na računalnim mrežama, te slojevita građa računalnih mreža iraspoloživi alati prikazuju se u trećem poglavlju rada. Detaljan prikaz sustava pozivaudaljenih procedura dan je u četvrtom poglavlju. Tu se razmatra model mrežne usluge ipripadni procesi koji sudjeluju u ostvarivanju te usluge, zajedno s problemima povezivanjaprocesa, upravljanja uslugom, povezivanja više usluga, ostvarivanja sigurnosti sustava idrugim problemima vezanim na izgradnju usluga i računalnih sustava osnovanih na takvimuslugama. Najjednostavniji način prijenosa poruka između procesa i njihove sinkronizacijemetodom susreta razmatra se u petom poglavlju. Složenije situacije metoda susreta sa i bezpovratnog poziva razmatraju se u šestom poglavlju, a u sedmom poglavlju se razmatraostvarivanje prijenosa poruka metodom poštanskog sandučića. Napomene o ciljnimračunalnim sustavima na kojima su isprobane navedene usluge prijenosa poruka i zaključaksu navedeni u zaključnom poglavlju. Izvorni kod i specifikacije dane su u dodacima.1. Međuprocesna komunikacija prijenosomporuka1.1. Osnovni cilj prijenosa poruke između procesaPrijenos poruka je osnovna metoda komunikacije i sinkronizacije procesa koji surađuju umrežnoj domeni. Postoji više metoda prijenosa poruke između procesa čija primjena ovisi ozahtjevima koji se postavljaju na sustav koji čine procesi.Prijenos poruka između surađujućih procesa ima dva osnovna cilja:prijenos podataka među procesima, što znači da dva procesa porukama razmjenjujupodatke;sinkronizaciju procesa, što znači da se dva procesa usklađuju vremenski u određenimtočkama izvođenja, pri tome procesi mogu i razmjenjivati podatke.Poruka koju procesi međusobno prijenose je atomarna količina podataka i njen sadržaj neutječe na prijenos. U stvarnoj izvedbi prijenosa poruka u sebi može nositi i dodatneinformacije za ostale entitete koji sudjeluju u razmjeni poruka.
  • 1.2.Procesi koji sudjeluju u prijenosu porukaU prijenosu poruka uočavaju se dvije grupe procesa, oni koji neposredno razmjenjuju poruke,te niz uslužnih procesa čije se usluge pri tome koriste.Procesi koji direktno sudjeluju u razmjeni poruka nazivaju se prema svojim funkcijama:pošiljač, pošiljaoc poruke (engl. message sender, message producer),primač, primalac poruke (engl. message receiver, message consumer).Pošiljač poruke proizvodi poruku i nastoji je prenijeti primaču poruke. Pri tome se služiuslugama operacijskog sustava i niza uslužnih procesa koji omogućuju prijenos poruka.Uslužni procesi koji sudjeluju posredno ili neposredno u prijenosu poruka (engl. agentprocess) mogu biti vrlo raznovrsni po funkcijama. Oni ovise o operacijskom sustavu, politicimeđusobnog imenovanja procesa u sustavu, politici nadzora i verifikacije sustava.Pojednostavljeni ili poopćeni prijenos poruke podrazumijeva idealni prijenos poruke u kojemprimač i pošiljač poruke direktno razmjenjuju poruke. To je idealizacija stvarnog načinaprijenosa koji je ovisan o operacijskom sustavu i mreži.Pri upotrebi poziva udaljenih procedura može se postići visok stupanj nezavisnosti kodprijenosa poruka, pošto sve usluge pristupa mreži, transporta poruke, imenovanja procesa,verifikacije i kontrole greške daje sustav poziva udaljenih procedura. U najjednostavnijemobliku poruka se prijenosi putem osnovne operacije za zadani tip poruke između procesaprimača i pošiljača, (slika 1.1).
  • Slika 1.1: Prijenos poruka između procesa (odnos procesa, mreže i operacijskog sustava).1.3. Građa porukePoruka koja se prijenosi se razmatra kao atomarni objekt čija građa u osnovi nije bitna. Ipakza stvarne izvedbe poruka postoje određeni zahtjevi na njenu građu /KOLN89/, /RFC14/. Dabi se što efikasnije radilo s porukama, poruka koja se stvarno prijenosi definira se kao unijasvih mogućih tipova poruka koji se mogu prenijeti između dva procesa (slika 1.2). Takavpristup građi poruke omogućuje jednostavno proširivanje komunikacije novim tipovimaporuka, te omogućuje izgradnju procesa na bazi modela upravljanja pojavom događaja (engl.event driven model). Uobičajeno je, da je razlikovno polje (engl. discrimination field,discrimination variable ) u poruci dugi cijeli broj, s simboličkim imenom i s konvencijamaprema tablici 1.1.Tablica 1.1: Vrijednosti razlikovnih polja poruka kod značenje 0 osnovni tip poruke -1 ostali negativni kodovi znače greške ili neispravno ponašanje 1 ostali pozitivni kodovi znače normalne radne poruke u
  • sustavuOvisno o sloju u kome se gleda poruka njena građa može varirati zbog dodavanja ilimodificiranja kontrolnih elemenata koji se dodaju poruci. Isto tako može doći dosegmentacije osnovne poruke u niz podporuka, no sve te pojave su transparentne za poopćeniprijenos poruke.struktura poruka_1 //pojedine moguće poruke početakcijeli_broj: cb; kraj.struktura poruka_2 početakpolje_znakova : cp ; kraj.struktura poruka_3 početakcijeli_broj: cb;polje_znakova: pp; kraj.razlikovna unija poruka; //prostor za porukurazlikovno polje cijeli_broj: tip //definira konkretni// tip poruke kada je tip==1poruka_1: p1; kada je tip==2poruka_2: p2; kada je tip==3poruka_3; p3; inačebez_vrijednosti kraj.Slika 1.2: Prikaz građe općenite poruke pogodne za prijenos između procesa.2. Metode prijenosa poruka2.1.Mogući postupci prijenosa porukaNa različitim sustavima definirane su različite metode prijenosa poruka. Postoje dvijeosnovne metode prijenosa poruka to su /KOLN89/:metoda susreta (engl. randevu), koja podrazumijeva direktan kontakt primača i pošiljačatako da ne postoji odlagalište za poruke koje dijele proces primač i proces pošiljač, već seporuka od jednog procesa prijenosi direktno drugom.metoda poštanskog sandučića (engl. mailbox), gdje postoji međuspremnik za odlaganjeporuka između procesa primača i procesa pošiljača. Međuspremnik može biti diooperacijskog sustava (npr. sustavi VMS firme Digital Equipment ) ili pak poseban proces koji
  • daje uslugu upravljanja međuspremnikom (npr. operacijski sustav QNX, UNIX, /AND90/,/STE90/).Prema opisu ovih metoda vidljivo je da se one mogu međusobno nadomjestiti, prijenosporuka susretom može se prikazati kao prijenos poruke putem međuspremnika dubine 1, ametoda poštanskog sandučića može se riješiti uvođenjem uslužnog nadzornog procesa(procesa administratora) za međuspremnike koji principom susreta prima i predaje poruke/RAY76/.Sve operacije koje se obavljaju pri prijenosu poruka su atomarne tj. nedjeljive u idealnomslučaju, u stvarnoj izvedbi te operacije se izvode nizom osnovnih operacija mrežnog sučelja sdobro definiranim reakcijama na pogreške. Zbog toga se te operacije i u stvarnoj izvedbimogu razmatrati kao atomarne operacije, jer svaka pojava greške u nižim slojevimaneizbježno vodi do prekidanja operacije prijenosa poruke u cjelini.2.2. Prijenos poruka metodom susretaU prijenosu poruka metodom susreta postoje osnovna dva procesa:primač poruka,pošiljač poruke,Oba procesa djeluju prema opisu iz poglavlja 1. Oni međusobno razmjenjuju poruke koje sugrađene kao razlikovna unija svih mogućih tipova poruka koje dani procesi mogurazmjenjivati.Prijenos poruka između procesa može se ostvariti putem tri osnovne operacije kojeomogućuju prijenos poruke proizvoljnom procesu. Definiraju se tri osnovne operacije/KOLN89/:šalji (identifikator_primača, poruka, povratna_poruka)primi (identifikator_posiljaoca, poruka)vrati (identifikator_posiljaoca, poruka)Kod osnovne operacije šalji proces pošiljač šalje poruku procesu primaču, proces bivablokiran do uspješnog prijema poruke ili do pojave greške, povratna poruka je opcionalniparametar za poruku koju primač može poslati pošiljaču. Povratna poruka je izuzetno važnaza sustave s modelom klijent-uslužitelj.Kod osnovne operacije primi proces primač očekuje prispijeće poruke od pošiljača, procesbiva blokiran do uspješnog prijema poruke ili do pojave greške.Kod osnovne operacije vrati proces primač vraća informaciju o prispijeću poruke procesupošiljaču, to ujedno omogućuje opcionalni prijenos dodatne poruke, te omogućujesinkronizaciju oba procesa. U momentu izvođenja vrati proces pošiljač biva vraćen upripravno stanje. Na taj način se oba procesa, primač i pošiljač nalaze u definiranim stanjima.
  • Identifikator primača i pošiljača su jedinstvene oznake načina na koji se izvršio ili će seizvršiti transfer poruke između procesa, tj definiraju postupak i objekte koji sudjeluju uprijenosu poruke (slika 2.1).Poruke koje se navode kao argumenti osnovnih operacija služe kao prostor za odlaganjestvarnih poruka koja se prijenose, pošto se poruke prijenose putem vrijednosti. To znači da sekod primača pojavljuje točna kopija poslane poruke.Slika 2.1: Redoslijed prijenosa poruke između procesaMoguće su i modifikacije navedenih osnovnih operacija tako da se mogu definirati osnovneoperacije koji prijenose poruke između procesa samo pomoću osnovnih operacija šalji i primipri čemu izvođenje primi biva točka sinkronizacije primača i pošiljača. Takva modifikacijaosnovnih operacija nije najpogodnija za upotrebu zbog toga što sinkronizacija slijedi prijeprijenosa poruke, tj. kritične sekvence koja bi trebala biti sinkronizirana. U realizacijiosnovnih operacija obavezno je definiranje maksimalnog trajanja pojedine operacije, tako dase može generirati greška isteka vremenskog ograničenja. Prema tome postoji modifikacijaosnovnih operacija s vremenskim ograničenjem 0 tj. s trenutačnom reakcijom.2.3. Prijenos poruka između procesa metodom poštanskogsandučića.
  • Metoda prijenosa poruka pomoću poštanskih sandučića podrazumijeva postojanjemeđuspremnika za poruke u koji proces pošiljač stavlja poruke, a proces primač uzimaporuke. Međuspremnik se definira do određene dubine tako da u njemu može biti zapisankonačan broj poruka. Na postojećim operacijskim sustavima moguća je i izvedba spremnika sneograničenom dubinom, upotrebom dinamičkog zauzimanja memorije, ali se ona nepreferira (slika 2.2).Slika 2.2: Prijenos poruke metodom poštanskog sandučićaMeđuspremnik se definira kao red poruka ( engl FIFO, First In First Out), tako da se onečitaju iz reda onim redom kako su u njega prispjele. Uz sinkronizaciju procesa i prijenospodataka među njima međuspremnik ima zadaću usklađivanja brzine i propusnosti procesa.Prijenos poruka se može ostvariti s dvije osnovne operacije. Te operacije omogućujukomunikaciju s poštanskim sandučićem. To su osnovne operacije za čitanje i pisanje:piši ( identifikator_spremnika, poruka )čitaj ( identifikator_spremnika, poruka )Kod osnovne operacije piši proces pošiljač pokušava zapisati poruku u red zadanidentifikatorom spremnika, pošiljač ostaje blokiran sve dok se poruka ne zapiše ili se ne desigreška.
  • Kod osnovne operacije čitaj proces primač ispituje da li u redu definiranom s identifikatoromspremnika postoji poruka, primač ostaje blokiran do pojave poruke ili do pojave greške.Ostvarenje reda poruka je standardno i ovisi o raspoloživim sredstvima operacijskog sustava,česta je izvedba višestrukih redova poruka tako da se unutar jednog fizičkog spremnika nalazeporuke za više raznih redova koji se razlikuju po dodatnom identifikatoru reda /MALA89/,/STE90/, /AND90/ jedna od mogućih jednostavnih izvedbi dana je u dodatku D.Moguće su i dodatne modifikacije osnovnih operacija tako da se uvedu osnovne operacijekoje neće čekati na istek vremenskog ograničenja. Takve osnovne operacije se dosta čestokoriste u ispitivanju stanja redova. Također se mogu definirati osnovne operacije za testiranjestanja redova, nedestruktivno čitanje poruke iz reda i sl.3. Ostvarivanje prijenosa poruka naračunalskim mrežamaOsnovna metoda prijenosa podataka između procesa na računalskim mrežama je prijenosporuka. Obzirom na slojevitu građu računalskih mreža i različite protokole komunikacije kojise danas koriste u domeni računalskih mreža može se reći da je prijenos poruka ugrađen usvaki protokol komunikacije i predstavlja osnovni način komunikacije i prijenosa podatakameđu računalskim procesima /TANN89/. Viši slojevi računalnih mreža često skrivaju tučinjenicu (slika 3.1), pošto su viši slojevi protokola okrenuti ka aplikacijskim procesima napojedinom računalu i nužno moraju biti prilagođeni konvencijama operacijskog sustavaračunala na kojem rade /TANN89/, /MALA89/.
  • Slika 3.1: Prijenos podataka kroz slojeve protokola računalske mrežeProučavajući strukturu protokola može se uočiti da se podaci koji se prijenose transformirajupo određenim pravilima u skupine podataka, da im se pri tome dodaju informacije potrebne zaprijenos i rekonstrukciju u početni oblik, te da se u najnižim slojevima mreže prevode upakete tj. samoopisive poruke. Dakle prijenos podataka putem poruka je ugrađen u samuosnovu računalskih mreža (slika 3.2).
  • Slika 3.2: Slojevitost protokola računalskih mrežaPrijenos poruka na računalskom sustavu odvija se u najvišem sloju mrežnih protokola tj. uaplikacijskom sloju. Pri tome se zbog načina ostvarivanja mrežnih protokola i mreža nerazmatraju transformacije i akcije nižih slojeva protokola. Prijenos poruka između primača ipošiljača poruke mora zbog jednostavnosti biti transparentan od medija tj. od mreže. Ta sečinjenica očituje u načinu povezivanja primača i pošiljača poruke pošto se prijenos poruke zanjih odvija na općenitoj razini. Pri ostvarivanju prijenosa poruka preporučljivo je u potpunostise oslanjati na neki od postojećih sustava mrežnog transporta i služiti se njegovim uslugama.Pri upotrebi viših slojeva mrežnih protokola za ostvarivanje prijenosa poruka uočljivo jepostojanje zalihosti (engl. overhead) pri prijenosu poruka. Ta je zalihost neophodna pošto onau sebi sadrži sve akcije mrežnih protokola i operacijskog sustava potrebne za jednoznačnoprenošenje podataka tj. poruka preko mreže. Zalihost se naročito očituje pri upotrebiautomatskih alata, koji generiraju kod optimiran za veliku učestalost prenošenja podataka.3.2. Mogućnosti ostvarenja prijenosa poruka na mrežnomsustavuZa ostvarivanje prijenosa poruka na operacijskom sustavu UNIX na raspolaganju postoji višemogućnosti ovisno o stupnju poopćenja na kojem se prijenos poruka ostvaruje /AND90/,/SUN01/, /SCO02/. To su tri osnovne metode (slika 3.3):
  • primjena pristupnih točaka (engl. sockets);primjena sučelja prema mrežnom transportnom sloju (engl. Transport Layer Interface,TLI );primjena poziva udaljenih procedura ( engl. Remote Procedure Calls, RPC);Pristupne točke čine osnovu preostala dva sustava pri čemu su oni na višem stupnjuopćenitosti. Primjena poziva udaljenih procedura se nalazi na najvišem stupnju općenitosti, tedozvoljava vrlo jednostavno ostvarivanje.Slika 3.3: Odnos aplikacije i načina pristupa mrežiPri radu s pristupnim točkama procesi primač i pošiljač moraju obaviti sve potrebne akcije zaaktiviranje pristupnih točaka, međusobnu verifikaciju i inkapsulaciju podataka u poruke.Navedene akcije se moraju ručno prevesti i predstavljaju veliki dio koda koji je ujedno vrloosjetljiv na pogreške.Upotreba poziva udaljenih procedura dozvoljava najviši stupanj općenitosti kod ostvarivanjamrežnih sustava /SAN91/. Izvedba se svodi na definiranje poruka tj. podataka koji serazmjenjuju, te osnovnih modula za manipulaciju podacima. Sve ostale akcije su riješene krozstandardizirane biblioteke. Time se omogućuje koncentriranje napora na samu funkcionalnostprijenosa i njeno optimiranje.4.Sustav poziva udaljenih procedura4.1. Uvod u sustav poziva udaljenih proceduraSustav poziva udaljenih procedura sastoji se iz dva sastavna dijela koji omogućujujednostavno kreiranje distribuiranih aplikacija. Osnovna ideja sustava poziva udaljenihprocedura je jednostavna, precizna i efikasna izgradnja distribuiranih sustava s pojedinimfunkcijama pravilno raspodijeljenim u postojećem protokolskom slogu, slika 4.1. Protokolsjedničkog sloja je RPC (engl. Remote Procedure Call) /RFC57/, omogućava međuprocesnukomunikaciju preko računalske mreže. Protokol prezentacijskog sloja XDR (engl. ExternalData Representation) daje strojno nezavisnu metodu prikaza podataka, /RFC14/.Uz ova dva protokola razvijen je i skup alata koji omogućuju razvoj procesa u aplikacijskomsloju na bazi RPC usluga sjedničkog sloja i XDR usluga prezentacijskog sloja. Na temelju tadva protokola korisnik može razviti svoj specifični sustav distribuiranih aplikacija (slika 4.1).
  • Slika 4.1: TCP/IP i RPC u protokolskom stogu OSI modelaPromatrano s stanovišta programske primjene, RPC u osnovi daje proširenje lokalnememorije sustava pošto funkcije ostvarene putem njega mogu koristiti i argumentespecificirane ne samo po vrijednosti već i prema adresi. Rezultati poziva udaljenih proceduramogu se prihvatiti i generirati na isti način kao i rezultati lokalnih funkcija. S stanovištaizvođenja programa RPC daje okruženje koje omogućuje prijenos podataka i rezultata međuudaljenim mrežnim procesima na uniformni način. Mehanizam poziva udaljenih proceduraomogućuje jedinstveno definiranje usluge tj. funkcije koja će se izvesti s specificiranimargumentima na udaljenom ili lokalnom čvoru. Način prijenosa argumenata operacija irezultata je omogućen XDR protokolom koji daje jedinstveno definiranje jednostavnih isloženih struktura podataka kao što su polja, zapisi, liste te njihove kombinacije.XDR protokol generira uniformni zapis tipa podatka na stupnju mrežne komunikacije,programe za konverziju (engl. filter) potrebne za konverziju u oblik podatka ovisan oračunalu i obratno, te rutine za zauzimanje i oslobađanje memorije na ciljnom računalu.4.2. Građa sustav poziva udaljenih proceduraOvisno o načinu ostvarenja aplikacije koja koristi pozive udaljenih procedura može serazlikovati više stupnjeva ili slojeva izvedbe. Postoje tri osnovna sloja RPC funkcija /SCO2/,/SCO1/, /SUN01/, /SUN02/, /SUN03/:
  • potpuno transparentni sloj, (najviši sloj);srednji sloj;sloj pristupnih točaka, (najniži sloj).Najviši sloj je sastavljen od skupa programa pohranjenih u biblioteci takozvanih dobropoznatih usluga koji su u potpunosti odvojeni od mrežnog sučelja, i kao rezultat vraćaju samoopće informacije korisniku (tablica 4.1). Prema drugim izvorima postoje još i finije podjelekoje uzimaju u obzir specifičnosti ostvarenja RPC-a na pojedinim operacijskim sustavima, anavedena podjela je zajednička za sva ostvarenja.Tablica 4.1: Neke dobro poznate uslugeusluga: opis usluge:rusers vraća broj korisnika na imenovanom čvoruhavedisk daje informacije o imenovanom korisniku na imenovanom čvorurstat dojavljuje da li imenovani čvor ima ili nema lokalni diskrnusers daje informacije o jezgri OS na imenovanom čvoru.Dva niža sloja RPC funkcija omogućuju korisniku veću kontrolu na izvođenjem aplikacija,srednji sloj se najviše koristi pošto je on direktno sučelje prema kreiranju usluga i prijenosupodataka te verifikaciji. Ovaj sloj omogućava i optimalnu upotrebu automatskih generatorakoda. Mogući su i ručni zahvati u kodu ovog sloja tako da se mogu postići i određeni efektikao što su uvećanje sigurnosti, kontrola trajanja operacije, izmjena uloge klijenta i uslužitelja isl.Interesantno je napomenuti da je pri razvoju standardnih komercijalnih produkata kao što jeuslužni program za NFS sustav proizvođač radio u drugom sloju uz manje modifikacije nageneriranom kodu, pa se stoga može zaključiti da je ovaj sloj najpogodniji za rad. Najviši slojse u principu koristi za potpuno transparentne akcije i za generiranje bibliotečnih pristupa.Uobičajeno je da se sustav razvije u domeni srednjeg sloja, te da ga se nakon testiranja iispitivanja prevede u najviši sloj.Najniži sloj se najrjeđe koristi pošto je najsložniji za upotrebu. Taj sloj omogućuje direktanpristup pristupnim točkama, a time i bitne promjene ponašanja aplikacije. Korištenje ovogsloja dolazi u obzir, kada je potrebno prilagoditi aplikaciju na neki vrlo specifični protokol, nomora se vrlo dobro paziti što se radi zbog narušavanja uniformnosti strukture programskogkoda, a time i ponašanja mehanizama prijenosa podataka i reakcije na mrežne događaje kodprijenosa podataka.Tablica 4.2: Osnovni funkcijski pozivi za ostvarivanje RPC funkcije
  • funkcija značenjeregisterrpc omogućuje prijavljivanje usluge tj. funkcije na mrežucallrpc zahtijeva izvođenje određene uslugeFunkcije koje pružaju RPC usluge se grupiraju u programe koji se sastoje iz grupa srodnihfunkcija (tablica 4.2), (slika 4.2). Programi imaju jedinstvene brojeve koji omogućuju izborusluge, programa i njene verzije. Argumenti poziva callrpc specificiraju uz ova tri podatkaime čvora na kojem se usluga izvodi, argumente na koji se izvodi, područje za pohranurezultata, te konverzione procedure za transformaciju podataka u mrežni oblik i natrag.if ( callrpc( argv[1], /* ime čvora */ RUSERSPROG, /* broj RPC programa */ RUSERVERS, /* broj verzije */ RUSERPROC_NUM, /* broj procedure */ xdr_void, /* filter za ulazne podatke, tip void */ NULL, /* kazaljka na ulazne podatke */ xdr_u_long, /* filter za rezultat /* &nusers) /* kazaljka na prostor za pohranu rezultata */ == 0 ) { exit(1); }Slika 4.2: Primjer pozivanja RPC funkcijeRPC usluge također obuhvaćaju definiranje automatskih parametara sigurnosti sustava,definiranje maksimalnog trajanja jedne operacije, te ostvarivanje struja podataka (engl. datastream) između kooperirajućih procesa.Svaka se RPC usluga sastoji u osnovi iz klijenta usluge (engl. client) i uslužitelja (engl.server). Njihov je odnos točno definiran s protokolom međusobne komunikacije koji opisujeporuke koje se razmjenjuju, te stanja kroz koja oba procesa prolaze. Poruke koje se prijenosedefiniraju argumente za funkcijski poziv udaljene procedure i rezultat koji se vraća uključno ikod greške koja je nastupila, te parametre sigurnosti sistema.Načelno gledano uslužitelj je proces koji je stalno aktivan i "osluškuje" na pristupnoj točkiusluge koju pruža (u UNIX terminologiji "deamon"). Pri prispijeću podataka obavlja severifikacija zahtijeva, konverzija podataka, te samo izvođenje operacije s dobivenimargumentima (slika 4.3). Kod koji izvodi operaciju mora napisati sam korisnik, dok se mrežnosučelje i rutine za konverziju i osluškivanje mogu generirati ručno, ili što je češći slučaj,putem automatskog generatora koda (program rpcgen) na temelju specifikacija strukturapodataka u XDR zapisu (slika 4.3). Rezultat se vraća obratnim redoslijedom, rezultat lokalneoperacije se putem konverzione procedure prevodi u XDR format i putem mrežnog sučeljašalje klijentu. Prije nego što proces postane uslužitelj za neku uslugu on tu uslugu moraprijaviti sistemu tako da bi ona bila dostupna na cijeloj računalnoj mreži /SCO01/,/SCO02/.
  • Slika 4.3:Tok izvođenja poziva udaljene procedureNa strani klijenta proces mora generirati pristup za klijenta do usluge i zatim zahtijevati samuuslugu, uz sve potrebne konverzije podataka u mrežni oblik (XDR format) i iz njega.Konverzioni programi i mrežna sučelja i ovdje mogu biti generirani ručno ili putemautomatskog generatora rpcgen-a. Korisnik sam mora osigurati pripremu podataka iinterpretiranje rezultata. Sve dok se izvodi RPC poziv klijent program je u blokiranom stanju,iz kojeg ga može izvesti prispijeće podataka, poruka o grešci ili istek intervala čekanja.Rezultat RPC poziva je u načelu razlikovna unija koja se sastoji iz jednog polja koje definiratip rezultata i unije svih mogućih tipova rezultata funkcije rezultata.Svaka aplikacija je namijenjena izvršavanju nekog zadatka, tj primjeni u okviru rješavanjanekog problema. Da bi se izgradila efikasna aplikacija na bazi RPC-a potrebno je izvršitianalizu i dekompoziciju problema u cjeline iz kojih se mogu stvoriti skupine objekatapogodnih za RPC izvedbu.Na temelju navedenog jasno je da je za efikasnu upotrebu sustava RPC-a potrebno problemrazložiti u međusobno surađujuće cjeline na funkcionalnoj osnovi, te definirati za svaki grupufunkcija koje čine jedan proces, sva stanja kroz koja on prolazi, te sve njihove interakcije sokolinom.4.3. Osnovni model odnosa procesa klijenta i uslužitelja
  • Realizacija RPC usluga zahtijeva definiranje procesa klijenta i uslužitelja struktura podatakatj. poruka koje oni razmjenjuju, te protokola komunikacije između njih. Isto tako je potrebnodefinirati i jedinstveni način reakcije na grešku i pružanja pomoći kao dio protokolakomunikacije.Osnovni model kooperacije procesa je model klijent-uslužitelj (engl. client-server model),koji je podržan od strane RPC sustava i samog operacijskog sustava UNIX. Prednost ovakvogmodela je višestruka:procesi uslužitelji se aktiviraju samo na zahtjev klijenta, pa je opterećenost sustava manja,može se u potpunosti pratiti aktivnost po pojedinim uslugama,mogućnost jednostavnog zamjenjivanja pojedinih segmenata sustava promjenom verzija ilibrojeva pojedinih usluga,može postojati centralni sistem praćenja grešaka kao dio protokola komunikacije,povećana otpornost na greške u smislu postojanja dva ili više čvora s aktivnim uslužiteljima.Sva višezadačna računala s RPC kompatibilnim mrežnim sučeljem mogu biti uslužitelji, takvise čvorovi ponekad nazivaju i čvorovi uslužitelji ili samo uslužitelji, što ponekad dovodi dokontradikcije s nazivima procesa uslužitelja.
  • Slika 4.4: Osnovni odnos procesa klijenta, procesa uslužitelja, te mreže.Odnos procesa klijenta i uslužitelja može se prikazati u najjednostavnijem obliku kao vezanistrojevi s konačnim brojem stanja (slika 4.4), (tablica 4.3, 4.4, 4.5, 4.6). U slučaju složenijihodnosa oba procesa mogu se upotrijebiti za modeliranje odnosa Petrijeve mreže i drugipogodni alati za prikaz ponašanja ovisnih procesa.Tablica 4.3: Opis poruka za proces uslužiteljs1 uspješno primljen zahtjev za uslugom od mrežnog sučelja;s2 predaja rezultata mrežnom sučelju;s3 nastupila greška u prijemu zahtijeva za uslugom;s4 nastupila greška u izvedbi zahtijeva;s5 predaja rezultata mrežnom sučelju;s6 poruka sistema o oporavku i prijavi greške;s7 poruka sistemu o pripravnosti za prijem novog zahtijevaTablica 4.4: Opis stanja za proces uslužiteljPrimanje zahtijeva: početno stanje, proces prima zahtjev od klijenta;Izvršavanje proces izvodi zahtjev na objektima sistema;zahtijeva:Vraćanje rezultata: proces vraća rezultat kroz mrežno sučelje;Greška: nastupila je greška bilo zbog fizičke greške, bilo zbog neispravnih podataka ili zbog nedovoljnih privilegija;Tablica 4.5:Opis poruka za klijent proces:c1 poruka greške koja se dobiva od mrežnog sučelja, označava: 1. istek vremenskog ograničenja 2. nepostojeću uslugu ili čvor 3. neispravnost mrežnog sučeljac2 poruka greške koja se dobiva ili od uslužitelja ili od
  • mrežnog sučelja 1. istek vremenskog ograničenja 2. nepostojeću uslugu ili čvor 3. neispravnost mrežnog sučeljac3 poruka uslužitelja s ponovnim zahtjevom uslugec4 poruka uslužitelja o uspješnom ispunjenju zahtijevac5 poruka mrežnog sučelja o uspješnom prekidu vezeTablica 4.6: Opis stanja klijent procesaSlanje zahtijeva: početno stanje, izvodi se kreiranje pristupne točke klijenta usluzi i aktiviranje usluge;Prijem rezultata: klijent proces prima rezultat usluge od pristupne točke;zahtjev uspješan: završno stanje, klijent proces raskida vezu s mrežnim sučeljem;Greška: završno stanje, došlo je do greške u procesu bilo zbog neispravnosti mreže, ili nekog drugog razloga;Posluživanje zahtijeva na strani uslužitelja osniva se na principu reakcije na događaj (engl.event driven model of action). Pri kreiranju usluge sistemski dio procesa uslužitelja obavljapovezivanje pristupne točke s uslugom i funkcijom koja se obavlja. zahtjev za funkcijom seposlužuje u više koraka. Pri prispijeću zahtijeva na pristupnu točku prispjeli podaci seprijenose funkciji za izbor usluge i funkcije. Ova funkcija provjerava da li se zahtijevaispravna funkcija u okviru odabrane usluge, stupanj sigurnosti, konvertira pristigle podatke ipoziva kod za izvršavanje funkcije, te konvertira rezultat i vraća ga klijentu.4.4. Ostvarivanje i definiranje usluge koja omogućujeprijenos poruka između procesa putem poziva udaljenihproceduraZa ostvarivanje prijenosa poruka putem poziva udaljenih procedura potrebno je u, skladu sterminologijom primjene RPC-a, definirati protokol prijenosa poruke, te na temelju njegadefinirati uslugu prijenosa poruka. Protokol definira način ponašanja procesa klijenta iprocesa uslužitelja za danu uslugu, a usluga definira konkretne parametre procesa.
  • 4.5. Povezivanje i prepoznavanje komunicirajući procesaputem poziva udaljenih proceduraPrepoznavanje procesa koji međusobno komuniciraju odvija se putem posebnog procesa zakontrolu i dodjelu brojeva usluga. Prepoznavanje procesa odvija se putem broja usluge, brojafunkcije i broja verzije. Sistemski uslužni proces za praćenje vezanja usluga i procesa (engl.portmaper) na temelju navedenih parametara procesu koji daje zahtjev za određenom uslugomdodjeljuje slobodnu pristupnu točku, na kojoj se nalazi proces uslužitelj te usluge, slika 4.5.Slika 4.5: Odnos procesa za praćenje vezanja i procesa koji koriste usluge.Program za praćenje vezanja usluga također u slučaju posebnog zahtijeva dodjeljuje iregistrira tvz. privremene usluge putem kojih se može izgraditi privatni komunikacijski kanalizmeđu dva procesa. Ta je metoda naročito korisna pri ostvarivanju procesa koji moraju čekatiproizvoljan period vremena da bi im se odgovorilo na zahtjev.Program za praćenje vezanja spada u sistemske uslužne programe (engl. deamon) koji činetransparentni dio podrške za bilo koji distribuirani sustav realiziran putem poziva udaljenihprocedura.
  • 4.6. Upravljanje, nadzor i građa usluge i procesa kojiostvaruju prijenos porukaDistribuirane aplikacije i distribuirani sustavi se mogu graditi na više različitih načina, ovisnoo vrstama računalnih sustava na kojima se osnivaju. Jedan od sve popularnijih načina izvedbeje upotreba poziva udaljenih procedura. Problem koji se rješava razlaže se u niz funkcija. Prirazlaganju problema u sustav takvih funkcija mora se zadovoljiti niz zahtijeva i uzeti u obzirniz elemenata koji utječu na efikasnost izvedbe sustava.Distribuirani sustav podrazumijeva sustav surađujućih procesa koji međusobno razmjenjujupodatke. Pri tome ti procesi mogu biti raspodijeljeni u domeni jednog računala ili u mrežnojdomeni. Prema ovoj definiciji možemo uočiti potrebu za postojanjem čvrsto definiranogprotokola sporazumijevanja pojedinih procesa međusobno, pri čemu protokol komunikacijedefinira građu podataka koji se razmjenjuju i način njihova zapisa. Tako definirani protokolujedno i definira potrebne konverzije tipova podataka ako su surađujući procesi smješteni naraznorodnim računalima.Uz tako definirane tipove podataka koji se razmjenjuju definiraju se i funkcije koje s timpodacima rade, te statičke i dinamičke strukture podataka u okviru procesa koje služe zapohranu i manipulaciju s podacima koji se razmjenjuju između procesa.4.6.1. Transakcijski pristup izgradnji distribuirane aplikacijePrijenos podataka među kooperirajućim procesima moguć je na više načina. Moguća supovezivanja na osnovi stalno otvorenih tokova podataka i transakcijski pristup.Prijenos podataka putem tokova podataka je osjetljiv na ispad procesa, te na greške ukomunikaciji, pošto podrazumijeva postojanje stalne veze između dva procesa. Isto tako nijega lako ostvariti putem osnovnih operacije jednostavne građe. Transakcijski pristup je pristupu kome se jedna operacija prijenosa podataka i rezultata među kooperirajućim procesimarazmatra kao zatvorena cjelina s zadanim trajanjem, pri čemu komunikacijski medij izmeđuprocesa nije vidljiv /SUN04/. Ovaj pristup je jednostavan za izvedbu putem osnovnihoperacija i omogućava jasno odjeljivanje procesa koji šalje podatke i prima rezultat odprocesa koji izvodi operaciju. Proces koji šalje podatke i prima rezultat tj. koji poziva funkcijuse naziva klijent, a proces koji prima podatke, te generira i vraća rezultat tj. sadrži kodfunkcije naziva se, uslužitelj ili nepreciznije usluga (engl. service) /SAN91/, /SUN01/,/SUN02/, slika 4.6.
  • Slika 4.6: Distribuirani sustav kao skup usluga ostvarenih putem funkcija4.6.2.Dekompozicija problema u sustav funkcija i tipova podatakaProblem koji distribuirana aplikacija ili sustav rješava treba razložiti u niz funkcija i tipovapodataka koji su argumenti i rezultati tih funkcija. Svaka od funkcija mora biti najpovoljnijerješenje za jedan određeni dio problema i može predstavljati jednostavan strukturirani kod zamanipulaciju argumentima /KONG90/. Ovako definirane funkcije i njihovi argumenti moguse jednostavno realizirati pozivanjem udaljenih procedura.Dekompoziciju problema u funkcije treba obaviti kao da se gradi objektno orijentirani sustav,pošto se jedna usluga može razmatrati kao jedan objekt, a funkcije koje on zna izvesti kaometode koje pripadaju tom objektu /KONG90/.4.6.3. Grupiranje funkcija u surađujuće procesePojedine funkcije potrebno je grupirati u grupe prema međusobnoj zavisnosti. Takva skupinafunkcija čini jedan proces tj. u RPC terminologiji jednu uslugu. U okviru jedne usluge moguse razlikovati dvije osnovne skupine funkcija:funkcije za izvedbu distribuirane operacije, tefunkcije za nadzor i kontrolu usluge.
  • Prva grupa funkcija kao što joj ime kaže rješava zahtjeve same distribuirane aplikacije. Drugagrupa funkcija služi za nadzor i upravljanje nad procesom. Sam sustav za rad s pozivimaudaljenih procedura automatski predviđa jednu funkciju koja služi samo za testiranjepostojanja usluge u okviru koje se ta funkcija nalazi /SUN02/, /SUN04/.O rasporedu funkcija u usluge tj. surađujuće procese ovisi efikasnost distribuiranog sustava ibrzina njegova odziva. Grupiranje funkcije u usluge tj. izgradnja funkcionalnosti jednogobjekta mora zadovoljavati više različitih zahtijeva koji mogu biti i međusobnokontradiktorni. zahtjevi se mogu podijeliti u nekoliko skupina:-paralelnost operacija, što znači da se operacije koje se mogu odvijati paralelno, ne stavljajukao funkcije u okviru iste usluge, ako postoji vjerojatnost da će se one možda istovremenozahtijevati;-sklopovska ovisnost, što znači da se funkcije koje pristupaju vrlo specifičnom sklopovljumoraju biti u okviru iste usluge zbog jednostavnije izvedbe upravljačkih programa zasklopovlje, posebno kontrole jedinstvenog pristupa sklopovlju;-srodne strukture podataka, što znači da se funkcije koje koriste iste strukture podataka iliisti mehanizam sigurnosti treba ugraditi u istu uslugu;-redundancija i sigurnost, što znači da za kritične funkcije ili usluge treba predvidjeti višeod jednog uslužitelja ili postojanje iste funkcije u okviru raznih usluga, a ujedno i načinsinkronizacije tih funkcija i usluga ako je potrebno;-redoslijed funkcija u izvođenju, što znači da funkcije koje se moraju sekvencijalno izvodititreba riješiti u okviru jedne usluge ako je ikako moguće, ili predvidjeti sustav sinkronizacijeako nisu u okviru jedne usluge, sustav sinkronizacije se obično rješava uvođenjemsinkronizacijskog primitiva tj. funkcije;-strategija nadzora sustava, što znači da funkcije koje imaju iste nadzorne strukture i istemehanizme nadzora treba riješiti u okviru jedne usluge;-strategija dohvata alternativnih uslužitelja, što znači da se za svaku funkciju u okviruoporavka od pogreške definira načIn traženja alternativnih uslužitelja ako je potrebno.Navedene skupine zahtijeva su međusobno kontradiktorne pošto se npr. redundancije isigurnost sukobljavaju s sklopovskom ovisnošću ili paralelnošću rada. Efikasan distribuiranisustav je kompromis između navedenih zahtijeva.4.6.4.Nadzor i upravljanje aplikacijom i uslugamaSvaka aplikacija zahtijeva postojanje nadzornog sustava koji omogućuje praćenje događanja usustavu i njenih aktivnosti. Mogu se razlikovati dva načina praćenja rada aplikacije:stalni nadzor aktivnosti tj. generiranje kontrolnih ispita,promjene stanja aplikacije putem funkcija za kontrolu i nadzor.
  • Potrebno je da postoji tvz. kontrolno sučelje za davanje nadzornih naredbi aplikaciji ilipojedinoj usluzi i metoda generiranja kontrolnih ispisa.Nadzor rada distribuiranog sustava svodi se na sistematski nadzor svih usluga koje činesustav. Tako se može reći da postoji nadzor sustava kao cjeline (skupa usluga) i pojedinihusluga. Na razini sustava kao cjeline postoji dakle posebna usluga koja služi za koordinacijunadzora i upravljanja, a na razini svake usluge postoji niz funkcija za kontrolu i nadzor sameusluge, tvz kontrolno sučelje usluge. Nadzorna usluga dakle omogućuje nadzor i praćenjecijelog sustava.Kontrolno sučelje usluge je skup funkcija u okviru pojedine usluge koje omogućuju dohvat ipromjenu stanja procesa koji čini pojedinu uslugu, npr. definira se niz osnovnih operacija kojidosižu interne statičke i dinamičke strukture podataka pojedinog procesa tj. usluge. Za svakuse uslugu definira i stupanj praćenja aktivnosti (engl. activity log, debbuging level) kojidefinira kontrolne ispise. Razina praćenja aktivnosti se obično mijenja putem kontrolnogsučelja usluge.Postoji više različitih pristupa izgradnji sustava kontrolnih ispisa. Metoda koja se koristi kodstandardnih aplikacija razvijenih na bazi poziva udaljenih procedura obično koristi 4 stupnjapraćenja aktivnosti /SCO01/, /SCO02/, /SCO03/, /SUN04/, koji se međusobno obuhvaćaju:razina 0: normalno odvijanje procesa, ispisuju se samo kritične neoporavljive greške,razina 1: ispisuju se sve greške koje se događaju u okviru usluge;razina 2: ispisuju se svi pristupi usluzi koji se događaju i sve greške;razina 3: ispisuju se sve aktivnosti i svi događaji u okviru usluge, svi pristupi usluzi, tegreške.Kod razvoja nekih specifičnih aplikacija koje se sastoje iz dobro definiranih funkcijskihslojeva, što je tipično pri razvijanju distribuirane verzije neke standardne aplikacije, koristi semetoda dubinskih ispisa /SUN04/. U tom slučaju se svakom funkcijskom sloju dodjeljuju dvastupnja kontrolnog ispisa (n), (n+1), tablica 4.7.Tablica 4.7: Značenje razine kontrolnih ispisa razina značenje (n) za dani funkcijski sloj se ispisuje poruka o ulasku u pojedinu funkciju, te o izlasku iz funkcije (n+1) za dani funkcijski sloj se ispisuju i podaci tj. ulazne i izlazne vrijednosti i sl.Promjene razine praćenja aktivnosti, te stanja pojedinih usluga treba izvesti kroz kontrolnuuslugu sustava, tako da stanje sustava uvijek bude konzistentno. Prema tome je očigledno dakontrolna usluga sustava mora imati u sebi detaljno definiranu strategiju upravljanja sustavom
  • usluga tj. aplikacijom Definiranje te strategije nije jednostavno i ovisi o prirodi samogproblema, te paralelnosti i međusobnoj zavisnosti procesa koji čine aplikaciju.Ova metoda pokazala se veoma efikasna u postupku testiranja i ispravljanja prijenosa porukaputem poštanskog sandučića, jer omogućuje jednostavno izdvajanje i testiranje pojedinihslojeva usluge u okviru procesa.4.6.5.Definiranje i pohrana upravljačkih parametara sustavaDa bi sustav ispravno funkcionirao mora imati definirana stanja i parametre tih stanja. Pripokretanju sustava ti se parametri unose u sustav i to u pojedine usluge čime se omogućujenjihova međusobna suradnja i konzistentnost sustava. Postoji više metoda trajne pohranenavedenih podataka i njihovog unošenja u sustav. Uobičajeno je postojanje konfiguracijskihdatoteka u kojima su ti podaci zapisani, a iz kojih pojedine usluge dohvaćaju vrijednosti/RFC94/, /SCO01/,/SCO02/,/SCO03/. Uobičajeno da se u okviru upravljačkih funkcija uslugedefinira jedna koja dohvaća parametre iz konfiguracijske datoteke i druga koja zapisujeparametre u konfiguracijsku datoteku.Moguće su i druge metode, npr. da usluga pri aktiviranju čita podatke, tako da je za promjenupodataka potrebno izvršiti gašenje i ponovo aktiviranje pojedine usluge.Operacijski sustavi poput UNIX-a, (preporuka POSIX) predviđaju da su konfiguracijskedatoteke u tekstualnom formatu u obliku komandi koje pojedini procesi znaju izvoditi, kaoprimjer se može uzeti NFS sustav realiziran putem RPC-a /RFC94/ i njegove konfiguracijskedatoteke, slika 4.7, pa je preporučljivo koristiti taj format za izradu konfiguracijskih datoteka.# place share(1M) commands here for automatic execution# on entering init state 3.# share [-F fstype] [ -o options] [-d "<text>"] <pathname> [resource]# share -F nfs -o rw=engineering -d "home dirs" /export/home2share -F nfs /dos/vanshare -F nfs /cdromshare -F nfs /hinashare -F nfs /usr#end of dfstabSlika 4.7: Popis sustava datoteka koji se eksportiraju ostalim čvorovima na mreži, primjer za operacijskisustav SOLARIS 2.14.6.6. Model uslugePojedina usluga se realizira kao jedan računalski proces tj. program u izvođenju /TANN89/. Sstanovišta samog procesa mogu se uočiti tri faze aktivnosti procesa:1. Aktiviranje procesa2. Stanje normalne aktivnosti3. Deaktiviranje procesa.
  • Svaka od tih faza ima pojedine specifičnosti. Aktiviranje procesa znači uključivanje usluge udistribuiranu aplikaciju. To je prikupljanje inicijalnih parametara, prijavljivanje usluge, teprelaz u stanje normalne aktivnosti. Tu je uključeno i inicijalizirane parametara unutar sameaplikacije. Obzirom na specifičnu prirodu aplikacija pisanih za pozive udaljenih procedurapreporuča se kod procesa koji je uslužitelj postojanje nadzorne zastavice koja pokazuje da lije izvršena inicijalizacija podataka ili ne. Takav pristup je naročito pogodan za kod koji sadržidijelove generirane automatskim generatorom rpcgen koda, a u okviru računalskog procesapostoje globalna stanja.Stanje normalne aktivnosti je ono stanje u kojem usluga reagira na zahtjeve klijenata ipristupa drugim uslugama sustava, već prema tome kakva joj je uloga u sustavu. Tu dolazi iispunjavanje zahtijeva vezanih uz nadzor i upravljanje uslugom.Deaktiviranje usluge je vrlo delikatna faza pošto sustav tj. aplikacija u okviru koje uslugadjeluje mora ostati konzistentna. To podrazumijeva obavještavanje svih ostalih usluga, anaročito nadzorne usluge o nastupajućem deaktiviranju procesa, te usklađivanje i promjenakonfiguracijskih datoteka i podataka ako je potrebno. Deaktiviranje usluge tj. nadzornogprocesa usluge obično zahtijeva period vremena u kome se mora sve dovesti u konzistentnostanje i tek nakon toga prekinuti rad. Način deaktiviranja ovisi o prirodi usluge. Za nadzorneprocese kakav je proces koji nadzire poštanske sandučiće pogodno je deaktiviranje nakonzadanog isteka vremena. Period proces dobiva kao argument poziva kontrolne funkcije i samsebi postavlja alarm signal i funkciju za prekid rada, slika 4.8.funkcija onalarm()početak prekini_radkrajfunkcija deaktiviranjeargumenti vrijeme dtpočetak poveži_signal ( alarm, onalarm) pokreni_alarm_za ( dt )krajSlika 4.8: Nacrt programa za kontrolnu uslugu deaktiviranjaRazmatranje distribuirane aplikacije kao sustava surađujućih procesa otkriva određeneprobleme vezane uz ostvarenje takvog sustava procesa. Pokazuje se da je protokolsporazumijevanja među surađujućim procesima izuzetno važan i da on predstavlja osnovusustava. Isto tako se može uočiti da je zbog prirode distribuirane aplikacije izuzetno važnosagledati načine nadzora i upravljanja tom aplikacijom, te zadavanje konfiguracijskihparametara aplikacije.4.7. Pitanja sigurnosti sustava razmjene porukaPri korištenju poziva udaljenih procedura za realizaciju prijenosa poruka moguće je ugraditimehanizme prepoznavanja i zaštite procesa. Za realizaciju sustava zaštite postoji ugrađeni
  • mehanizam u okviru poziva udaljenih procedura, s mogućnošću izbora između mogućihmetoda prepoznavanja i zaštite.Mehanizam prepoznavanja i zaštite zasniva se na činjenici da se korisnik usluge tj. proces kojipoziva udaljenu procedura mora verificirati na sustavu na kojem se ta funkcija izvodi. Tako ses podacima koji su argumenti funkcije prijenose podaci o procesu koji zahtijeva izvođenjefunkcije i o njegovom vlasniku i pravima. Ovaj mehanizam je ugrađen u sustav uslužnihprograma koji omogućuju izvođenje poziva udaljene procedura tako da ga je nemogućenamjerno suspendirati bez velikih zahvata u sistemskom dijelu koda.Postoje tri stupnja prepoznavanja i verifikacije korisnika /SCO1/, /SUN02/:bez verifikacije, kada se ne prijenose nikakvi podaci i kada nema provjera;UNIX način verifikacije, kada se prijenose podaci koji odgovaraju stupnju sigurnostioperacijskog sustava UNIX;korisnički protokol sigurnosti, kada korisnik definira svoj specifični protokol sigurnosti kojimože uključivati i dodatne provjere podataka koji se prijenose, prevođenje i dekodiranje, tedruge proizvoljne zahvate.Verifikacija može biti definirana kao dinamički ili statički parametar sustava. Kao dinamičkiparametar ona se može mijenjati u skladu s komandama koje dobiva od upravljačke usluge iliputem nekog drugog mehanizma. Kao statički parametar ona se zadaje jedanput za cijelotrajanje rada sustava. Zadavanje stupnja verifikacije ne smije biti dostupno procesu koji izvodiosnovne operacije za prijenos poruka.Treba spomenuti da veći stupanj verifikacije usporava odziv sustava. Prema najnovijimpodacima, tj. prema /SUN02/ na operacijskom sustavu Solaris 2.1 postoji pet razinaprepoznavanja u koja su uklopljena postojeća tri. Takvo stanje zna dovesti donekompatibilnosti aplikacija.5. Ostvarivanje metode susreta zanajjednostavniji slučaj prijenosa porukeizmeđu procesaNajjednostavniji slučaj metode susreta je ujedno i primjer za najjednostavnije ostvarivanjepozivanja udaljene procedure pa može poslužiti za praktičnu demonstraciju. Dokumentiraniprogramski kod, specifikacija u XDR jeziku, te potrebne komandne datoteke potrebne zaprevođenje na ciljnom računalnom sustavu nalaze se u dodatku A. Procesi primač i pošiljač sunajjednostavnije građe i neposredno su ostvareni putem automatskog generatora koda rpcgen.Proces primač je u ovom slučaju uslužitelj za prijenos poruke, a proces pošiljač je klijent zaprijenos poruke. Primač je zbog jednostavnosti ostvaren kao pravi proces uslužitelj koji seodvija u beskonačnoj petlji. Oba procesa se sinkroniziraju pri prijenosu poruke (slika 5.1). Priprijemu poruke proces primač pamti poruku i vrača cijeli broj koji je kod uspješnosti
  • prijenosa poruke. Poruka koja se prijenosi krajnje je jednostavna, a sastoji se iz niza znakovazadane dužine.Slika 5.1: Redoslijed prijenosa poruke između procesa primača i pošiljačaZbog jednostavnih zahtijeva na prijenos i ponašanje procesa standardnu građu procesaprimača je moguće znatno pojednostavniti. Pošto je to standardni proces uslužitelj za njega jedovoljno samo jednom prijaviti uslugu prijenosa poruke na mrežni sustav, a pošto ne postojinikakva specifična akcija vezana uz prijem poruke moguće je osnovne operacije primi i vratispojiti u jednu operaciju i sam prijem poruka obaviti kroz osnovne operacije RPC sučelja.Program pošiljač varijabla poruka p; //poruka koja se šalje varijabla idproc id; //identifikator primača varijabla povratna q; //povratna poruka varijabla status st; //slanje uspjelo ili nepočetak pripremi poruku( p ); //generiranje poruke ocisti_povratno( q ); //priprema prostora za povratnu poruku odaberi_primaoc( id ); //pristup usluzi tj. primaocu st = šalji(id, p,q); //osnovna operacija ako je (st == USPJELO )
  • tada ispis_poruka (q); kraj inače greska(st); //ispis greške i razloga neuspjeha krajkraj.Slika 5.2: Nacrt programa za proces pošiljač porukeNa strani pošiljača postoji osnovna operacija šalji, koja nije modificirana (slika 5.2), a nastrani primača poruke osnovne operacije primi i vrati su stopljene u jednu osnovnu operacijutj. jest u kod za ostvarivanje usluge (slika 5.3).funkcija send_1 varijabla poruka p; //poruka koja se prima preko RPC sustavapočetak //nema nikakvih operacija s porukom samo se vrača kod uspješnostiu RPC sustav vrati ( 0 );kraj.Slika 5.3: Nacrt programa za proces osnovne operacije primi i vratiOsnovni cilj ostvarivanja ovakvog prijenosa poruka je demonstracija primjene sustava pozivaudaljenih procedura s namjerom da se prikaže jednostavnost upotrebe. Za detaljno objašnjenjepostupka kodiranja i specificiranja sustava osnovanog na pozivanju udaljenih procedura možese proučiti literatura /SUN02/, /SUN03/, a za osnovno razumijevanje specifikacije u XDRjeziku, a time i protokola komunikacije između procesa klijenta i uslužitelja može poslužitislika 5.4 na kojoj se nalazi XDR specifikacija najjednostavnijeg prijenosa poruka izmeđuprocesa.Slika 5.4: Specifikacija programa u XDR jeziku za osnovne operacije primi i vrati
  • 6. Ostvarivanje metode susreta pozivanjemudaljenih procedura6.1. Mogući postupci ostvarivanja metode susretaMetoda susreta podrazumijeva u idealnim uslovima direktnu blokirajuću komunikacijuprocesa pošiljača poruke i procesa primača poruke. Da bi se metoda susreta ostvarila putempoziva udaljenih procedura potrebno je osnovne operacija šalji, primi, vrati realizirati putempoziva udaljenih procedura. Moguća je izvedba na više načina od koji su odabrana dvanajkarakterističnija:ostvarenje bez primjene povratnog poziva,ostvarenje s primjenom povratnog poziva.Ovi načini su odabrani zato što dozvoljavaju primjenu automatskih alata za generiranjeprogramskog koda na temelju specifikacije, te zato što omogućuju jednostavno razdvajanjeprogramskog koda u nezavisne module.6.2. Primjena metode neposrednog povezivanja pošiljača iprimačaMetoda susreta se može relativno jednostavno izvesti pozivanjem udaljenih procedura, sasvim osnovnim operacijama. Za realnu izvedbu moguće je poslužiti se standardnimgeneratorom koda, s time da se strana primača poruke mora modificirati. Modifikacija se uosnovi svodi na to da primač poruke može biti uslužitelj za RPC uslugu primanja poruke i dane mora biti trajni uslužitelj.Funkcija svc_run(k) argument cijeli broj k; //koliko se puta smije obaviti usluga globalna varijabla cijeli broj svc_fds; //broj pristupne točke globalna varijabla cijeli broj cnt; //brojač koliko se puta obavilausluga varijabla cijeli broj i; //pomoćna varijablapočetak//petlja se odvija sve dok se ne detektira da//je operacija obavljena dovoljan broj puta ponavljaj sve dok ne bude (cnt=k) početak i=čitaj_pristupnu_točku( svc_fds )//čekanje na pristupnoj točki pridruženoj usluzi ovisno o ( i ) kada je -1: tada vrati 0;
  • kada je 0: tada nastavi; inače: pokreni_rpc_uslužnu_proceduru( svc_fds ); kraj vrati cnt;kraj.Slika 6.1: Nacrt programa za funkciju svc-runNa strani pošiljača poruke nikakve modifikacije nisu potrebne pa se programski kod zaosnovnu operaciju šalji ne mora modificirati (slika 6.2). Modifikacija pošiljača predstavljaodstupanje od standardne građe procesa uslužitelja i na granici je primjene automatskoggeneratora koda. Uz pomoć detaljne analize koda koji se koristi za ostvarivanje srednjeg slojasustava pozivanja udaljenih procedura /SUN04/, /STE90/ mogu se uočiti zahvati koji supotrebni na programskom kodu tako da se ne naruši stabilnost i pouzdanost procesauslužitelja, a da se ispravno ostvare osnovne operacije primi i vrati (slika 6.3). Potrebnamodifikacija se svodi na definiranje bloka programskog koda koji je u stanju na temeljudetektiranih vanjskih uslova (prispijeće poruke kroz RPC sustav) prihvatiti poruku, prekinutistanje čekanja na prijem poruka, obaviti potrebne operacije na poruci i vratiti povratnu porukuprocesu pošiljaču. Navedeni programski kod riješen je gniježđenjem funkcija tako da bi seizbjegla manipulacija se osjetljivim sistemskim strukturama podataka koje obavljaju prihvatporuka u RPC sučeljima, te modifikacijom jedne standardne funkcije RPC sustava. To jestandardna funkcija svc_run koja predstavlja proceduru za prihvat poruke od RPC sučelja injeno ispravno prosljeđivanje rutini za transformaciju i izračunavanje, u osnovi to jeprocedura za prosljeđivanje događaja (engl. event dispatching routine). U različitoj literaturi/SUN01/, /SUN02/, /SUN04/,/SCO03/, ona je riješena na razne načine. Na temeljuzajedničkih elementa izvedena je modifikacija njenog programskog koda, u skladu spreporukom /RFC57/, tako da standardni proces uslužitelj usluge postaje sposoban mijenjatisvoje stanje (slika 6.1, dodatak B1, datoteka svc_run.c).Program pošiljačvarijabla poruka p; //poruka koja se šaljevarijabla idproc id; //identifikator primačavarijabla povratna q; //povratna porukavarijabla status st; //slanje uspjelo ili ne početakpripremi poruku( p ); //generiranje poruke ocisti_povratno( q ); //priprema prostora za povratnu porukust = šalji(id, p,q) ako je (st == USPJELO ) tada ispis_poruka (q); kraj inače greška(st); //ispisgreške i razloga neuspjeha krajkraj.Slika 6.2: Nacrt programa za proces pošiljač porukeZbog prirode građe sustava poziva udaljenih procedura koji je osnovan na modelu ponašanjaupravljanog pojavom događaja, potrebno je također i dodati posebne globalne varijable zaprijenos i pamćenje vrijednosti poruka kod procesa primača.Međusobno prepoznavanje uslužitelja i klijenta ne mora se modificirati i ono ostajestandardno. Apstraktna adresa primača i pošiljača poruke je u ovom slučaju identifikator
  • usluge primanja i pošiljanja poruka. Na taj način je jedinstveno ostvareno prepoznavanjeprocesa u okviru pozivanja udaljenih procedura i uklopljneo u standardni sustav pozivanjaudaljenih procedura na ciljnom računalnom sustavu.Program primačvarijabla poruka p; //poruka koja se prima, argumentvarijabla poruka q; //poruka koja se vraća, rezultatvarijabla idproc id; //id. pošiljača porukepočetakprijavi_primanje(); //prijava primača, tj. usluge na mrežuprimi(id,p); //primi poruku// proces je stanju RPC uslužitelja//usluga je još uvijek aktivna na mrežitransformiraj_poruku(p,q);//izračunaj rezultat//proces je napustio stanje RPC//uslužiteljavrati(id,q);//vrati rezultat, proces se vratio u stanje//uslužitelja//završni dio funkcionalnosti uslužiteljaodjavi_primanje(); //odjava primanja porukakraj.Slika 6.3: Nacrt programa za proces primač porukeStrukture podataka koje se koriste u izvedbi su standardne i vezane su na građu poruka koje serazmjenjuju. U skladu s zahtjevima na građu poruka, poruka koja se šalje sastoji se iz unije
  • mogućih poruka. Povratna poruka ima istu građu s time da je prema preporuci dodan i praznitip (engl. void) koji dogovorno znači pogrešku.Kontrola trajanja stanja oba procesa definirana je standardnim metodama tj. postavljanjemvremenskog ograničenja /SUN02/,/SUN01/,/SUN04/. Ako vremensko ograničenje istekneproces pošiljač dobiva poruku o grešci od RPC sučelja prema nižem RPC sloju. Ta se porukainterpretira kao greška.Na temelju ponašanja procesa primača i pošiljača može se reći da ova metoda efikasnouslužuje prijenos poruka između dva procesa koji samo povremeno izmjenjuju poruke, te kojipri tome imaju čvrsto definirano maksimalno trajanje operacije prijenosa poruke. Razlozi zatakav zaključak su obimne operacije na strani procesa primača pri prijavi i odjavi usluge, tepostojanje maksimalne granice za trajanje jednog poziva udaljene procedure.Potpuni programski kod, komandne procedure te specifikacija u XDR jeziku nalaze se udodatku B1.6.3. Primjena metode privremene uslugeNedostaci metode neposrednog povezivanja pošiljača i primača nalaze se u teškoćama pripostavljanju granice vremenskog ograničenja pri čemu je proces pošiljač blokiran pri čekanjuodgovora na jednu specifičnu uslugu, tj na povratnu poruku. Trajanje takvog vremenskogograničenja ne treba biti konačno posebno ako se ima na umu da se prijenos poruka možeupotrijebiti u za sinkronizaciju procesa /MAE87/, /AND90/, /STE90/. Da bi se izbjeglo daproces pošiljač dobiva poruke o isteku vremenskog ograničenja, tj. da mrežni računalni sustavprekida prijenos poruka, potrebno je dozvoliti procesu pošiljaču da postane privremeniuslužitelj tj. da može proizvoljno dugo biti u stanju čekanja. Takav pristup ima više prednostiproces pošiljač je u stanju proizvoljno dugo čekati na odgovorproces pošiljač može primiti upravljačke zahtjeve bez prekida rada, pošto je on sadastandardni uslužitelj.Za postizanje takvog ponašanja procesa primača i pošiljača potrebno je modificirati osnovneoperacije za primanje i slanje poruke, te građu same poruke na takav način da se kao dodatniargument poruke koristi indentifikator privremene usluge. Program pošiljač generiraprivremenu uslugu, te njen identifikator prijenosi kao dodatni argument kod slanja poruke. Priostvarivanju postupka generiranja privremene usluge mora se striktno paziti na postupakdobivanja usluge od procesa za kontrolu vezanja usluga i pristupnih točaka (engl. portmaper).Identifikator privremene usluge se nalazi u rasponu brojeva usluga 0x40000000 - 0x5fffffff utvz. privremenom području /SUN02/. Nakon slanja poruke pošiljač postaje uslužitelj zaprivremenu uslugu gdje čeka na povratnu poruku generiranu od primača putem osnovneoperacije vrati (slika 6.4).funkcija šalji (p,q)
  • argument poruka p; //poruka koja se šaljeargument poruka q; //povratna porukapočetakprijavi_privremenu_uslugu(p);//dobiva se broj privremene usluge i upisuje u//poruku pako je privremena_usluga_uspjela(p)tadaprenesi_RPC_poruku(p);//poziv RPC sučelja za aktiviranje usluge i//prijenos porukepostani_uslužitelj();//povezivanje privremene usluge sa//funkcijom za prihvat poruke, te//te pokretanje modificirane SVC_RUN//funkcijeodjavi_uslugu(p);//odjava privremen usluge//broj usluge se oslobađaako je uspješno_primljen_i_ispunjena(q)vrati qinačevrati greškukraj.Slika 6.4: Nacrt programa za funkciju šalji s generiranjem privremene usluge
  • Modifikacije procesa u sebi sadrže ranije modifikacije koje su bile potrebne za ostvarivanjemetode susreta bez povratnog poziva, pošto se i tu mora koristiti modificirana funkcijasvc_run, pošto pošiljač i primač moraju mijenjati stanje iz klijenta jedne usluge u uslužiteljadruge.Proces pošiljač poruke prima poruku od pošiljača putem osnovne operacije primi (slika 6.5),te nakon toga postaje klijent za privremenu uslugu i putem nje vraća povratnu porukupošiljaocu putem osnovne operacije vrati (slika 6.6). Obično se uzima da je rezultataprivremene usluge bez vrijednosti (engl. void), koji u ovom slučaju nema dogovorno značenjegreške.funkcija primi (p)argument poruka p; //poruka koja se šaljepočetakprijavi_uslugu_prijenosa_poruke();//prijava usluge za prijenos poruka//poruku pako je prijava_uspjela()tadapostani_uslužitelj();//povezivanje usluge sa//funkcijom za prihvat poruke, te//te pokretanje modificirane SVC_RUN//funkcije, tu je stvarni prijem poruke od//primačaodjavi_uslugu();//odjava usluge//broj usluge se oslobađaako je uspješno_primljen_i_ispunjena(q)
  • vrati qinačevrati greškukraj.Slika 6.5: Nacrt programa za funkciju primi s generiranjem privremene uslugePošto ne postoji standardna funkcija za generiranje brojeva privremenih usluga bilo jepotrebno ostvariti tu funkciju. Prema preporukama za imenovanje funkcija, funkcija zageneriranje brojeva privremenih usluga je nazvana gettransient. U različitoj literaturi/SUN01/, /SUN02/, /SUN04/,/SCO03/, ona je riješena na razne načine. Na temeljuzajedničkih elementa izvedena je modifikacija njenog programskog koda, u skladu spreporukom /RFC57/, tako da je pristup sistemskom procesu uslužitelju standardan nasvakom ciljnom računalnom sustavu (dodatak B2, datoteka get.c).funkcija vrati (q)argument poruka q; //povratna porukapočetakako je privremena_usluga_uspjela(p)tadaprenesi_RPC_poruku(q);//poziv RPC sučelja za aktiviranje usluge i//prijenos poruke preko privremene usluge// to je sada klijent stranaako je uspješno_preneseno(q)vrati qinačevrati greškukraj.
  • Slika 6.6: Nacrt programa za funkciju vrati s generiranjem privremene uslugeDa bi se omogućila jednostavna povezivanja usluge tj. programskog koda koji opslužujeprispijeće poruke kroz RPC sučelje (od nižih slojeva) potrebno je i modificirati postupakvezanja RPC sučelja s tim programskim kodom. Za te svrhe je razvijena posebna funkcijabecameserver koja omogućuje jednostavno vezanje broja usluge, verzije usluge teprogramskog koda (ostvarenog kao funkcija u programskom jeziku C). Funkcija je ostvarenau skladu preporukama /RFC57/, (dodatak B2, datoteka become.c)S stanovišta izvedbe operacije šalji, primi i vrati ova metoda omogućuje pisanje urednijegkoda kod koga su intervencije programera u kodu prirodnije nego u slučaju metodeneposrednog povezivanja pošiljača i primača. Ovakvo ostvarenje prijenosa poruka je pogodnoza procese koji povremeno komuniciraju prijenosom poruka, ali kod kojih vremenskoograničenje trajanja prijenosa ne postoji.Usprkos tome što procesi primač i pošiljač mijenjaju stanja i što se pojavljuju periodi vremenakada usluga prijenosa poruka nije aktivna (trenuci kada se usluga prijavljuje ili odjavljuje) obaprocesa su kvalitetno surađivala bez pogrešaka.Potpuni programski kod, komandne procedure te specifikacija u XDR jeziku nalaze se udodatku B2.7. Ostvarivanje metode poštanskogsandučića7.1.Mogući postupci ostvarivanja metode poštanskogsandučićaMetoda poštanskog sandučića zahtijeva postojanje uslužnog procesa koji nadzire poštanskesandučiće za odlaganje poruka. To odmah zahtijeva definiranje načina upravljanja i nadzoratog procesa, te politike sigurnosti za poruke koje su pohranjene u poštanskim sandučićima.Pošto postoji samo jedan proces koji se treba nadzirati nije neophodno kreirati cijelu nadzornuuslugu i njoj pripadne nadzorne strukture podataka, dovoljno je samo uvesti nadzorne funkcijeza taj proces i pripadne klijente za pristup tim uslugama.Za uslužni proces koji nadzire poštanske sandučiće potrebno je definirati i politiku sigurnosti.Politika sigurnosti se može pojednostavniti na osnovni stupanj, tj samo na poznavanjeidentifikatora poštanskog sandučića bez drugih provjera. Proces je verificiran ako poznajebroj tj. identifikator poštanskog sandučića.Za ostvarivanje metode poštanskog sandučića odabrane su dva načinaprimjena metode neposrednog povezivanja pošiljača i primača,primjena metode privremene usluge.
  • To su uobičajeni postupci koji su korišteni i u ostvarivanju metode susreta, pa se razvijenemodifikacije RPC funkcija mogu koristiti i u ostvarivanju metoda poštanskog sandučića.7.2. Građa uslužnog procesaUslužni proces je građen na temelju standardnog uslužnog procesa za sustav poziva udaljenihprocedura. Njegov zadatak je da upravlja strukturama poštanskih sandučića, provodi politikusigurnosti, ispunjava zahtjeve klijenata za čitanje i pisanje, te da ispunjava zahtjeveupravljačkog klijenta. Nadzorni proces zbog toga mora biti ostvaren s "pamćenjem" tj. ne kaouslužitelj bez stanja. U okviru uslužnog procesa postoje globalne strukture podataka za:realizaciju usluge, to su poštanski sandučići ostvareni kao redovi poruka;nadzor i upravljanje.Za nadzor i upravljanje definiraju se posebne funkcije za neposredni nadzor pojedinogpoštanskog sandučića. prema tablici 7.1. Njihov je zadatak da omoguće potpuno interaktivnoupravljanje nadzornim procesom za poštanske sandučiće.Tablica 7.1: Nadzorne funkcije uslužnog procesa poštanskog sandučićadozvoli dozvoli pristup odabranom reduzabrani zabrani pristup odabranom reduočisti očisti sve poruke iz odabranog redastatus dohvati i ispiši status odabranog redapostavi promijeni razinu praćenja (debug level)dojavi vrati tekuću razinu praćenja (debug level)Pojedine nadzorne usluge ugrađuju se u jednog nadzornog klijenta koji obavlja komunikacijus nadzornim uslugama. Za ispis stanja pojedinih usluga korištena je metoda /KONG90/ sdefiniranjem dva stupnja kontrole ispisa po jednom stupnju gniježđenja funkcija, jer sefunkcije grupiraju u biblioteke na osnovi istog stupnja općenitosti. Prva kontrolna razinaispisuje samo pojavu događaja, a druga kontrolna razina ispisuje i parametara (ulazne iizlazne argumente) događaja. Navedena metoda je modifikacija preporučenog postupkapraćenja procesa. Nadzorni proces također ima ugrađenu mogućnost prekida rada tj.isključivanja samog sebe.Sama manipulacija s poštanskim sandučićima riješena je putem redova poruka. Sustavfunkcija za manipulaciju redovima poruka i potrebne strukture podataka dane su u dodatku D.
  • 7.3.Modifikacije općenitih operacija i potrebne strukturepodatakaIzvedba metode poštanskog sandučića putem poziva udaljenih procedura omogućujeneposrednu upotrebu nemodificiranog koda na temelju specifikacije usluge poštanskogsandučića. Osnovne operacije piši i čitaj mogu se neposredno izvesti putem generatora koda.struktura sandučićpočetakcijeli_broj: zastavice; //zastavice stanja sandučićared: poruke;red: zahtjevi_za_pisanje;red: zahtjevi_za_čitanje;kraj.Slika 7.1: Struktura poštanskog sandučićaFunkcionalnost nadzornog procesa također se može direktno generirati putem generatorakoda. Dodatni zahtjevi postaju potrebni kod primjene metode privremene usluge kada jepotrebno da se u okviru osnovnih operacija piši i čitaj izvede privremena usluga, a koduslužnog programa konzistentno mijenjanje stanje iz uslužitelja u klijenta, te nezavisnoopsluživanje nadzornih usluga.Uslužni proces poslužuje polje poštanskih sandučića proizvoljne veličine, građa poštanskihsandučića je standardna (slika 7.1) i omogućuje brzu manipulaciju porukama.Sandučić se sastoji iz redova poruka, te iz redova blokiranih procesa. Zbog prirode sustava inačina na koji je riješen sam prijenos poruka između procesa provedena su nekapojednostavljena koja su objašnjena s metodama u kojima su primijenjena.7.4. Primjena metode neposrednog povezivanja pošiljača iprimačaPri neposrednom povezivanju procesa koji čita ili piše u poštanski sandučić primijenjeno jedirektno neposredno povezivanje pozivom udaljene procedure. Zbog jednostavnosti izvedbedefinirano je neblokirajuće čekanje tj. ako se operacija na poštanskom sandučiću ne možeobaviti tada proces koji je operaciju zahtijevao biva odmah obaviješten o tome prikladnimkodom greške. Ovakva izvedba zadovoljava jednostavno posluživanje poštanskog sandučića.
  • Procesi klijenti su pri tome ostvareni u skladu sa sličnim rješenjima kakva su potrebna za NFSsustav koji je opisan u /RFC94/.Prijenos poruka je riješen na standardni način za pozive udaljene procedure, tako da su klijentiodvojeni u posebne procese. Upravljačka usluga je odvojena u posebni upravljački programkoji omogućuje pristup upravljačkim funkcijama neovisno o tekućem radu procesa uslužitelja.Kod ostvarivanja usluge prijenosa poruke u ovom slučaju potrebno je samo prevestispecifikaciju u XDR jeziku i tako dobiveni programski kod vezati s sustavom za manipulacijuredovima.Potpuni programski kod, komandne procedure, te specifikacija u XDR jeziku nalaze se udodatku C1.7.5. Primjena metode privremene uslugePrimjena metode privremene usluge omogućuje da se u potpunosti ostvari blokirajuće čekanjeizmeđu klijenata i uslužnog procesa. Na taj način je ostvarena bolja i preciznijaimplementacija standardnog sustava poštanskih sandučića.Za ostvarivanje privremene usluge korištene su potrebne modifikacije koje su opisane upoglavlju 6, a koje omogućuju jednostavno i efikasno umetanje i upotrebu privremenih uslugai promjene stanja klijenata i uslužitelja.Privremena usluga je sada parametar koji označava da se zahtjev za pisanje ili čitanje nijemogao ispuniti pa je morao biti suspendiran i zapisan u red čekanja. Postupak ostvarivanjaprivremene usluge je isti kao i onaj opisan u poglavlju 6.Pri opsluživanju zahtijeva za dohvat poruke iz poštanskog sandučića ili za stavljanje poruke upoštanski sandučić nadzorni program provjerava stanje redova blokiranih procesa i rješavasve one ranije zahtjeve koje može izvršiti. Izvršavanje ranijih zahtijeva riješeno je u okviruposluživanja suprotnog zahtijeva, pa se time postiže potpuna sinkronizacija nadzornogprocesa i procesa koji komuniciraju s njim.funkcija čitaj (msg, id)argumentiporuka msg //poruka u koju se čita iz redaidentifikator_reda id //identifikator reda iz kog se čitavarijablepoštanski sandučić mb //postanski sandučićred_poruka ms //red poruka u mb
  • red_poruka ps //red blokiranih pisanjempočetakmb=uzmi_mbox(id)ako ne postoji mb // provjera postojanja mbox-atadavrati greskuinačems=uzmi_red_poruka(mb)ako je neprazan(ms)tada//poruka se može pročitatimsg=uzmi_poruku(ms);ps=uzmi_red_blokiranih_pisanjem( mb )//budi fer prema svim procesima koji čekaju od prije //ispuni njihove zahtjevedok je ( (ms nije pun) i (ima blokiranih u ps ))činipiši_u_red(ms, uzmi_poruku(ps))vrati u_reduinače//ne može se čitati proces mora čekatipiši_u_red_blokiranih_citanjem(mb,msg)vrati blokiranokrajSlika 7.2: Nacrt programa za čitanje iz poštanskog sandučića
  • funkcija piši (msg, id)argumentiporuka msg //poruka u koju se čita iz redaidentifikator_reda id //identifikator reda iz kog se čitavarijablepoštanski sandučić mb //postanski sandučićred_poruka ms //red poruka u mbred_poruka ps //red blokiranih pisanjempočetakmb=uzmi_mbox(id)ako ne postoji mbtadavrati greškuinačems=uzmi_red_poruka(mb)ako nije pun(ms)tadapiši_u_red_poruka(ms,msg)ps=uzmi_red_blokiranih_citanjem( mb )dok je ( (ms nije prazan) i (ima blokiranih u ps ))činičitaj_iz_red(ms, uzmi_poruku(ps))vrati u_reduinače
  • piši_u_red_blokiranih_pisanjem(mb,msg)vrati blokiranokrajSlika 7.3: Nacrt programa za pisanje u poštanski sandučićPri izvedbi poštanskog sandučića postupak posluživanja zahtijeva koji čekaju blokirani morase modificirati na način koji odgovara filozofiji izvršavanja zahtijeva udaljenih procedura.Modifikacija se sastoji u tome da se nagomilani zahtjevi blokirani zbog nedostatka resursa upoštanskom sandučiću opslužuju prije nego što proces koji je omogućio njihovo oslobađanjedobije povratnu informaciju tj. rezultat svoje akcije (slika 7.2 i 7.3), na taj način se ubrzavaodziv sustava, a svi zahtjevi imaju približno isto trajanje pa ne dolazi do izgladnjivanjaprocesa. Takvo rješenje ima nedostatak jer se u dijelu programskog koda koji opslužujezahtjev i koji je uslužitelj, gnijezde pozivi udaljenih procedura (povratni pozivi blokiranimklijentima). To nije u skladu s principima gradnje poziva udaljenih funkcija, gdje se preporučaizbjegavanje takvih gniježđenja /RFC57/, /SAN91/.funkcija operacija( msg )argumentiporuka msg //poruka u koju se čita ili piševarijablebroj rez //rezultat rpc pozivabroj tmp //privremena uslugapočetaktmp=generiraj_tmp_uslugu(); //generiranje privremene uslugeako je tmp=greškatadavrati greskaprijavi_uslugu(tmp, usluzna_funkcija)msg.tmp_usluga=tmp; //broj privremene usluge ide u argument rpc-a//poziv operacije koja može biti blokirana
  • rez=poziv_rpc_funkcije(čitaj/piši,verzija,čvor, ....., msg)ovisno o rezkada je greska:tada //poziv nije uspioodjavi_uslugu(tmp);objasni_gresku(stat);vrati greskakada je blokiranotada //poziv je blokiran ćekaj!cekaj_na_uslugu();odjavi_uslugu(tmp)vrati uspjehostalotada //poziv je uspioodjavi_uslugu(tmp)vrati uspjehkrajSlika 7.4: Općenita građa funkcije koja piše ili čita iz poštanskog sandučićaDa bi se pojednostavilo ponašanje uslužitelja i smanjilo opterećenje računalnog sustava,proces koji pokušava čitati ili pisati u red poruka privremenu uslugu koristi samo u slučaju dadobiva informaciju od nadzornog procesa da je njegov zahtjev blokiran (slika 7.4). Na tajnačin navedeni proces privremenu uslugu koristi samo ako je doveden u stanje čekanja, pa sedopunski zahvati oko manipulacije privremenom uslugom obavljaju samo onda kada suneophodni što poboljšava učinak sustava.8. ZaključakIzvedba prijenosa poruka razrađena u okviru ovog rada omogućava prijenos poruka nastvarnim umreženim sustavima podržanim TPC/IP mrežama. Razvijeni kod i postupcinadgledanja ostvareni su na računalima pod raznim operacijskim sustavima i isprobani su udomeni jednog računala, te u mrežnoj domeni (tablica 8.1). Suradnja procesa koji su slali i
  • primali poruke jednako je dobro funkcionirala na svim računalima ako se uzmu u obzirograničenja pojedinih operacijskih sustava kao što je npr. DOS koji zbog svoje prirode nemože biti efikasan uslužilac.Tablica 8.1: Ciljna računala i operacijski sustaviRačunalo Operacijski Princip susreta Poštanski sandučić sustavPC386 SCO UNIX za sve navedene za sva navedene izvedbe izvedbePC386 DOS 5.0, za izvedbe bez za izvedbe bez SUN PCNFS 4.0a privremene usluge privremene usluge zbog svoje za proces pošiljač za sve funkcije prirode DOS ne poruke osim za nadzorni može biti proces efikasan uslužiteljmico VAX VMS 5.2 nije funkcionirao nije funkcionirao RPC paket RPC paketSUN 10/30 Solaris 2.1 za sve navedene za sve navedene izvedbe izvedbeUpotrjebljene metode omogućuju razvoj nadzornih procesa i uniformnu transparentnukomunikaciju prijenosom poruka za distribuirane sustave upotrebom poziva udaljenihprocedura. Primjena prijenosa poruka u aplikacijskom sloju omogućuje povezivanje potrebnihprocesa distribuirane aplikacije na raznorodnim računalnim sustavima i raznorodnimprotokolima uz maksimalno poopćavanje protokola prijenosa poruke.Ovako ostvareni postupci prijenosa poruka se mogu upotrijebiti za daljnji razvoj distribuiranihsustava. Za takvu primjenu naročito su pogodni postupci koji ne koriste povratne usluge,pošto se bolje uklapaju u filozofiju rada operacijskog sustava i generalne ideje upotrebesustava udaljenih funkcija. Takav zaključak može se donijeti na temelju analize dostupnihspecifikacija naročito specifikacija /RFC94/,/RFC57/,/RFC14/, posebno iz premisa koje sukorištene pri razvoju NFS sustava /RFC94/, te preporučene metodologije izvedbe mrežnihsustava na operacijskom sustavu UNIX /STE90/. Pozivi udaljenih procedura su specificiranitako da preferiraju sustave osnovane na uslužiteljima i uslugama koji obavljaju jednostavne iatomarne poslove s unutrašnjom građom čija složenost ne prelazi strojeve s konačnim brojemstanja, prema premisama autora NFS preporučuju se uslužitelji bez vlastitih stanja (engl.stateles server).Ovako ostvareni postupci prijenosa poruka predstavljaju proširenje osnovne ideje pozivaudaljenih procedura, pošto pozivanje udaljenih procedura u sebi ugrađuju prijenos podataka uobliku "sirovih" poruka na razini pristupnih točaka, što se može uočiti analizom izvornogkoda sustava SUN RPC /SUN04/, te /STE90/. Zbog toga se prijenos poruka u aplikacijskomsloju može promatrati kao poopćeno proširenje osnovnog sustava prijenosa poruka koji činisam sustav poziva udaljenih procedura. Time se postiže da se mogu ostvariti i ispitati neki
  • specifični postupci suradnje i sinkronizacije računalskih procesa koji se osnivaju na prijenosuporuka, a koji bi zahtijevali svaki posebno ostvarenje sustava prijenosa poruka izmeđuprocesa.9. Literatura/AND90/ P.K.Andleigh:"UNIX System Arhitecture", Prentice Hall Englewood Cliffs,NY, 1990/COMM89/ D.E.Commer,D.L.Stevens:"Internetworking with TCP/IP VolumeI",Prentice Hall Englewood Cliffs, NY, 1989./COMM91/ D.E.Commer,D.L.Stevens:"Internetworking with TCP/IP VolumeII",Prentice Hall Englewood Cliffs, NY, 1991./COMM93/ D.E.Commer,D.L.Stevens:"Internetworking with TCP/IP VolumeIII",Prentice Hall Englewood Cliffs, NY, 1993./KOLN89/ F.Kolnick:"The QNX Operating System", Basis Computer Systems Inc,Wilowdale, Ontario, Canada, 1989/KONG90/ M.Kong:"Network Computing System Reference Manual",Prentice HallEnglewood Cliffs, NY, 1990./MAEK87/ M.Maekava,A.E.Olendorft,R.R.Olendorft:"Operating Systems AdvancedConcepts", The Benjamin Cummings Publishing Co. Inc, 1987/MALA89/ Carl Malamund: "DEC Networks and ARCHITECTURES", IntertextPublicatiuons, Mc Graw-Hill Book Company, 1221 Avenue of the America, New York,1989./RAY76/ R.T.Yeh: "Applied Computation Theory, Analysys, Design, Modeling",Prentice Hall Englewood Cliffs, NY, 1976./RFC14/ "Reguest for commnets XDR External Data Representation Standard", SUNMicrosystems Inc, 2550 Garcia Avenue, Mountain View,CA 94043, USA, March 1989./RFC57/ "Reguest for commnets 1057: RPC Remote Procedure Call Protocolspecification" SUN Microsystems Inc, 2550 Garcia Avenue,Mountain View, CA 94043,USA, March 1989./RFC94/ "Reguest for commnets 1094: NFS Network File Systen ProtokolSpecification",SUN Microsystems Inc, 2550 Garcia Avenue, Mountain View, CA 94043,USA, March 1989./SAN91/ M.Santifaller:"TCP/IP and NFS Internetworking in a UNIX Enviroment",Adison Wessley Publishing Company, 1991
  • /SCO1/ "SCO Network File System (NFS) System Administartors Guide", Santa CruzOperations Inc., 12 March 1991./SCO2/ "SCO Network File System (NFS), Programmerss Guide", Santa CruzOperations Inc., 12 March 1991./SCO3/ "SCO Network File System (NFS) Reference Guide, ", Santa Cruz OperationsInc., 12 March 1991./SHC92/ A.Schill "Remote Procedure Call: Fortegeschrittene Konzepte und Systems -ein Uberlink", Informatik-Spektrum, Springer Verlag 1992./STE90/ W.R.Stevens:"UNIX Network Programming",Prentice Hall Englewood Cliffs,NY, 1990./SUN01/ "PC-NFS, Programmers toolkit, Programming Guide Version4.0", SUNMicrosystems Inc, 2550 Garcia Avenue, Mountain View, CA94043, USA, Part No: 800-6982-10, Revision A, May 1992./SUN02/ "Network Programming Guide, For Solaris 2.1",SUN Microsystems Inc, 2550Garcia Avenue, Mountain View, CA94043, USA, Part No: 800-6982-10, Revision A, May1992./SUN03/ "Network Programming Guide, For SunOS 4.01",SUN Microsystems Inc, 2550Garcia Avenue, Mountain View, CA94043, USA, Part No: 800-6982-10, Revision A, May1992./SUN04/ "Sun RPC", SUN Microsystems Inc, 2550 Garcia Avenue, Mountain View,CA94043, USA, Part No: 800-6982-10, Revision A, May 1992./TANN89/ A.S.Tannenbaum:"Computer Networks, Second Edition",Prentice HallEnglewood Cliffs, NY, 1989.