Zagreb

12/20/93

Mehanizmi razmjene poruka ostvareni pozivima udaljenih funkcija

Sadržaj:

Razmotriti načine komunikacije između procesa razmjenom poruka. Odabrati skup osnovnih

operacija te pripadne strukture podataka. Predložiti ostvarenje tog skupa operacija u

okruženju zasnovanom na pozivima udaljenih funkcija. Posebice istražiti metode susreta i

poš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 ocjenu

ispravnosti ostvarenja.

0.Uvod

Ostvarivanje distribuiranih sustava ovisi o međuprocesnoj komunikaciji i sinkronizaciji

procesa koji čine distribuirani sustav. Osnova metoda ostvarivanja međuprocesne

komunikacije je razmjena poruka između procesa. Usklađivanje procesa i složenih sustava

razmjenom poruka naročito dolazi do izražaja u umreženim sustavima u kojima prijenos

podataka i komunikacija u drugim formama gotovo i nisu moguće.

Efikasnim ostvarivanjem mehanizama za prijenos poruka između procesa na umreženim

sustavima dobiva se osnova za ostvarivanje distribuiranog operacijskog sustava i može se

postić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 sredstvima

pogodnim za izgradnju distribuiranih sustava potrebno je koristiti najpogodnija sredstva koja

omogućuju maksimalno poopćavanje svojstava platforme. U slučaju da se distribuirani sustav

gradi na osnovi specifičnih računala ili vrlo specifičnog operacijskog sustava potrebno je do

maksimuma prilagoditi se mogućnostima tog sustava (primjer operacijskog sustava QNX za

rad u stvarnom vremenu koji posjeduje mehanizme za mrežni prijenos poruka kao dio

operacijskog sustava /KOLN89/). U slučaju da se distribuirani sustav planira koristiti u širem

okruženju potrebno je prilagoditi se postojećim preporukama i standardima, stoga je potrebno

uvažiti pravila i preporuke za izgradnju otvorenih sustava. Isto tako potrebno je uvažiti građu

te način funkcioniranja ciljnog operacijskog sustava. Kao primjer za potrebe prilagođavanja

ciljnom operacijskom sustavu može se navesti operacijski sustav UNIX i izvedba mrežne

podrške na njemu /STE90/. U slučaju UNIX-a pristup mrežnom sklopovlju odvija se kroz

jezgru sustava, dok se više funkcije upravljanja ostvaruju nizom autonomnih nadzornih

procesa (engl. deamon) /AND90/, /STE90/.

Slika 0: Model protokolskog sloga otvorenog sustava

Prema standardnom modelu protokolskog sloga otvorenog sustava /KONG90/, /TANN89/

(slika 0) distribuirana aplikacija i distribuirani sustav se funkcionalno ostvaruju u sedmom

sloju modela, dok ostali niži slojevi modela pružaju usluge podrške radu aplikacije. Prema

tome, u skladu s filozofijom otvorenih sustava mehanizme međuprocesne komunikacije i

sinkronizacije treba ili koristiti kao usluge nižih slojeva modela ili ih treba razvijati u što

višim slojevima kao specifične usluge ili aplikacije. Takav pristup na prvi pogled ne daje

dovoljnu slobodu pri razvoju, ali omogućava kompatibilnost s postojećim sustavima. Pri tome

je sva komunikacija, obrada grešaka, transformacije formata i adresa, te pristup mreži

odvojena od elemenata distribuiranih procesa. Svi elementi distribuiranog procesa surađuju

kroz mehanizam komunikacije i sinkronizacije koji se realizira kao usluga nižih slojeva

modela i prenosivi su na razne platforme na stupnju prenosivosti jezika kojima su ostvareni, te

alata koji su pri tome korišteni.

Na standardnim operacijskim sustavima postoje mehanizmi prijenosa poruka ili mehanizmi

koji dozvoljavaju emulaciju prijenosa poruka između procesa. Ti mehanizmi obično imaju niz

prilagođenja za rad postojećeg okruženja pa je često potrebno izvesti značajne izmjene na

njima. Jedan takav mehanizam koji omogućuje prijenos poruka između procesa je upotreba

poziva udaljenih procedura (engl. Remote Procedure Calls, RPC) koji omogućuje atomarno

prenošenje argumenata i rezultata između izvršioca klijenta i uslužitelja. Pri tome je za

procese transparentno postojanje mreže računala. /RFC57/, /SUN01/, /SUN02/, /SUN03/,

/SCO1/, /SCO2/, /SCO3/, /SHC92/.

Mehanizam poziva udaljenih procedura se gradi na osnovi komunikacije putem pristupnih

točaka (engl. sockets) kao osnovnog sloja komunikacije u domeni jednog računala i u

mrežnoj domeni.

Ostvarivanje osnovnih operacija za prijenos poruka između procesa može se izvesti pomoću

poziva udaljenih procedura čime se postiže dodatna ugradnja sigurnosti i efikasnosti u sustav

prijenosa 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šenjem

poruka. Tu se definiraju procesi koji sudjeluju u prijenosu poruka, te osnovna građa samih

poruka, uz prikazivanje odnosa tih procesa, operacijskog sustava i mrežne podrške tog

operacijskog sustava. Osnovne metode prijenosa poruka i osnovne operacije definiraju se u

drugom 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 i

raspoloživi alati prikazuju se u trećem poglavlju rada. Detaljan prikaz sustava poziva

udaljenih procedura dan je u četvrtom poglavlju. Tu se razmatra model mrežne usluge i

pripadni procesi koji sudjeluju u ostvarivanju te usluge, zajedno s problemima povezivanja

procesa, upravljanja uslugom, povezivanja više usluga, ostvarivanja sigurnosti sustava i

drugim problemima vezanim na izgradnju usluga i računalnih sustava osnovanih na takvim

uslugama. Najjednostavniji način prijenosa poruka između procesa i njihove sinkronizacije

metodom susreta razmatra se u petom poglavlju. Složenije situacije metoda susreta sa i bez

povratnog poziva razmatraju se u šestom poglavlju, a u sedmom poglavlju se razmatra

ostvarivanje prijenosa poruka metodom poštanskog sandučića. Napomene o ciljnim

računalnim sustavima na kojima su isprobane navedene usluge prijenosa poruka i zaključak

su navedeni u zaključnom poglavlju. Izvorni kod i specifikacije dane su u dodacima.

1. Međuprocesna komunikacija prijenosom

poruka

1.1. Osnovni cilj prijenosa poruke između procesa

Prijenos poruka je osnovna metoda komunikacije i sinkronizacije procesa koji surađuju u

mrežnoj domeni. Postoji više metoda prijenosa poruke između procesa čija primjena ovisi o

zahtjevima 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 razmjenjuju

podatke;

sinkronizaciju procesa, što znači da se dva procesa usklađuju vremenski u određenim

toč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 ne

utječe na prijenos. U stvarnoj izvedbi prijenosa poruka u sebi može nositi i dodatne

informacije za ostale entitete koji sudjeluju u razmjeni poruka.

1.2.Procesi koji sudjeluju u prijenosu poruka

U 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ži

uslugama operacijskog sustava i niza uslužnih procesa koji omogućuju prijenos poruka.

Uslužni procesi koji sudjeluju posredno ili neposredno u prijenosu poruka (engl. agent

process) mogu biti vrlo raznovrsni po funkcijama. Oni ovise o operacijskom sustavu, politici

međusobnog imenovanja procesa u sustavu, politici nadzora i verifikacije sustava.

Pojednostavljeni ili poopćeni prijenos poruke podrazumijeva idealni prijenos poruke u kojem

primač i pošiljač poruke direktno razmjenjuju poruke. To je idealizacija stvarnog načina

prijenosa koji je ovisan o operacijskom sustavu i mreži.

Pri upotrebi poziva udaljenih procedura može se postići visok stupanj nezavisnosti kod

prijenosa poruka, pošto sve usluge pristupa mreži, transporta poruke, imenovanja procesa,

verifikacije i kontrole greške daje sustav poziva udaljenih procedura. U najjednostavnijem

obliku poruka se prijenosi putem osnovne operacije za zadani tip poruke između procesa

primač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 poruke

Poruka koja se prijenosi se razmatra kao atomarni objekt čija građa u osnovi nije bitna. Ipak

za stvarne izvedbe poruka postoje određeni zahtjevi na njenu građu /KOLN89/, /RFC14/. Da

bi se što efikasnije radilo s porukama, poruka koja se stvarno prijenosi definira se kao unija

svih mogućih tipova poruka koji se mogu prenijeti između dva procesa (slika 1.2). Takav

pristup građi poruke omogućuje jednostavno proširivanje komunikacije novim tipovima

poruka, 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 konvencijama

prema 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

sustavu

Ovisno o sloju u kome se gleda poruka njena građa može varirati zbog dodavanja ili

modificiranja kontrolnih elemenata koji se dodaju poruci. Isto tako može doći do

segmentacije osnovne poruke u niz podporuka, no sve te pojave su transparentne za poopćeni

prijenos poruke.

struktura poruka_1 //pojedine moguće poruke

početak

cijeli_broj: cb;

kraj.

struktura poruka_2

početak

polje_znakova : cp ;

kraj.

struktura poruka_3

početak

cijeli_broj: cb;

polje_znakova: pp;

kraj.

razlikovna unija poruka; //prostor za poruku

razlikovno polje cijeli_broj: tip //definira konkretni

// tip poruke

kada je tip==1

poruka_1: p1;

kada je tip==2

poruka_2: p2;

kada je tip==3

poruka_3; p3;

inače

bez_vrijednosti

kraj.

Slika 1.2: Prikaz građe općenite poruke pogodne za prijenos između procesa.

2. Metode prijenosa poruka

2.1.Mogući postupci prijenosa poruka

Na različitim sustavima definirane su različite metode prijenosa poruka. Postoje dvije

osnovne metode prijenosa poruka to su /KOLN89/:

metoda susreta (engl. randevu), koja podrazumijeva direktan kontakt primača i pošiljača

tako da ne postoji odlagalište za poruke koje dijele proces primač i proces pošiljač, već se

poruka od jednog procesa prijenosi direktno drugom.

metoda poštanskog sandučića (engl. mailbox), gdje postoji međuspremnik za odlaganje

poruka između procesa primača i procesa pošiljača. Međuspremnik može biti dio

operacijskog 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, prijenos

poruka susretom može se prikazati kao prijenos poruke putem međuspremnika dubine 1, a

metoda 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 idealnom

slučaju, u stvarnoj izvedbi te operacije se izvode nizom osnovnih operacija mrežnog sučelja s

dobro definiranim reakcijama na pogreške. Zbog toga se te operacije i u stvarnoj izvedbi

mogu razmatrati kao atomarne operacije, jer svaka pojava greške u nižim slojevima

neizbježno vodi do prekidanja operacije prijenosa poruke u cjelini.

2.2. Prijenos poruka metodom susreta

U 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 su

građene kao razlikovna unija svih mogućih tipova poruka koje dani procesi mogu

razmjenjivati.

Prijenos poruka između procesa može se ostvariti putem tri osnovne operacije koje

omoguć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 biva

blokiran do uspješnog prijema poruke ili do pojave greške, povratna poruka je opcionalni

parametar za poruku koju primač može poslati pošiljaču. Povratna poruka je izuzetno važna

za sustave s modelom klijent-uslužitelj.

Kod osnovne operacije primi proces primač očekuje prispijeće poruke od pošiljača, proces

biva blokiran do uspješnog prijema poruke ili do pojave greške.

Kod osnovne operacije vrati proces primač vraća informaciju o prispijeću poruke procesu

pošiljaču, to ujedno omogućuje opcionalni prijenos dodatne poruke, te omogućuje

sinkronizaciju oba procesa. U momentu izvođenja vrati proces pošiljač biva vraćen u

pripravno 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 se

izvršiti transfer poruke između procesa, tj definiraju postupak i objekte koji sudjeluju u

prijenosu poruke (slika 2.1).

Poruke koje se navode kao argumenti osnovnih operacija služe kao prostor za odlaganje

stvarnih poruka koja se prijenose, pošto se poruke prijenose putem vrijednosti. To znači da se

kod primača pojavljuje točna kopija poslane poruke.

Slika 2.1: Redoslijed prijenosa poruke između procesa

Moguće su i modifikacije navedenih osnovnih operacija tako da se mogu definirati osnovne

operacije koji prijenose poruke između procesa samo pomoću osnovnih operacija šalji i primi

pri čemu izvođenje primi biva točka sinkronizacije primača i pošiljača. Takva modifikacija

osnovnih operacija nije najpogodnija za upotrebu zbog toga što sinkronizacija slijedi prije

prijenosa poruke, tj. kritične sekvence koja bi trebala biti sinkronizirana. U realizaciji

osnovnih operacija obavezno je definiranje maksimalnog trajanja pojedine operacije, tako da

se može generirati greška isteka vremenskog ograničenja. Prema tome postoji modifikacija

osnovnih operacija s vremenskim ograničenjem 0 tj. s trenutačnom reakcijom.

2.3. Prijenos poruka između procesa metodom poštanskog

sandučića.

Metoda prijenosa poruka pomoću poštanskih sandučića podrazumijeva postojanje

međuspremnika za poruke u koji proces pošiljač stavlja poruke, a proces primač uzima

poruke. Međuspremnik se definira do određene dubine tako da u njemu može biti zapisan

konačan broj poruka. Na postojećim operacijskim sustavima moguća je i izvedba spremnika s

neograničenom dubinom, upotrebom dinamičkog zauzimanja memorije, ali se ona ne

preferira (slika 2.2).

Slika 2.2: Prijenos poruke metodom poštanskog sandučića

Međ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 prijenos

podataka 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ćuju

komunikaciju 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 zadan

identifikatorom spremnika, pošiljač ostaje blokiran sve dok se poruka ne zapiše ili se ne desi

greška.

Kod osnovne operacije čitaj proces primač ispituje da li u redu definiranom s identifikatorom

spremnika 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 nalaze

poruke 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 operacije

koje neće čekati na istek vremenskog ograničenja. Takve osnovne operacije se dosta često

koriste u ispitivanju stanja redova. Također se mogu definirati osnovne operacije za testiranje

stanja redova, nedestruktivno čitanje poruke iz reda i sl.

3. Ostvarivanje prijenosa poruka na

računalskim mrežama

Osnovna metoda prijenosa podataka između procesa na računalskim mrežama je prijenos

poruka. Obzirom na slojevitu građu računalskih mreža i različite protokole komunikacije koji

se danas koriste u domeni računalskih mreža može se reći da je prijenos poruka ugrađen u

svaki protokol komunikacije i predstavlja osnovni način komunikacije i prijenosa podataka

međ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 na

pojedinom računalu i nužno moraju biti prilagođeni konvencijama operacijskog sustava

računala na kojem rade /TANN89/, /MALA89/.

Slika 3.1: Prijenos podataka kroz slojeve protokola računalske mreže

Proučavajući strukturu protokola može se uočiti da se podaci koji se prijenose transformiraju

po određenim pravilima u skupine podataka, da im se pri tome dodaju informacije potrebne za

prijenos i rekonstrukciju u početni oblik, te da se u najnižim slojevima mreže prevode u

pakete tj. samoopisive poruke. Dakle prijenos podataka putem poruka je ugrađen u samu

osnovu računalskih mreža (slika 3.2).

Slika 3.2: Slojevitost protokola računalskih mreža

Prijenos poruka na računalskom sustavu odvija se u najvišem sloju mrežnih protokola tj. u

aplikacijskom sloju. Pri tome se zbog načina ostvarivanja mrežnih protokola i mreža ne

razmatraju transformacije i akcije nižih slojeva protokola. Prijenos poruka između primača i

poš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 za

njih odvija na općenitoj razini. Pri ostvarivanju prijenosa poruka preporučljivo je u potpunosti

se 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 je

postojanje zalihosti (engl. overhead) pri prijenosu poruka. Ta je zalihost neophodna pošto ona

u sebi sadrži sve akcije mrežnih protokola i operacijskog sustava potrebne za jednoznačno

prenošenje podataka tj. poruka preko mreže. Zalihost se naročito očituje pri upotrebi

automatskih alata, koji generiraju kod optimiran za veliku učestalost prenošenja podataka.

3.2. Mogućnosti ostvarenja prijenosa poruka na mrežnom

sustavu

Za ostvarivanje prijenosa poruka na operacijskom sustavu UNIX na raspolaganju postoji više

moguć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 stupnju

općenitosti. Primjena poziva udaljenih procedura se nalazi na najvišem stupnju općenitosti, te

dozvoljava vrlo jednostavno ostvarivanje.

Slika 3.3: Odnos aplikacije i načina pristupa mreži

Pri radu s pristupnim točkama procesi primač i pošiljač moraju obaviti sve potrebne akcije za

aktiviranje 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 vrlo

osjetljiv na pogreške.

Upotreba poziva udaljenih procedura dozvoljava najviši stupanj općenitosti kod ostvarivanja

mrežnih sustava /SAN91/. Izvedba se svodi na definiranje poruka tj. podataka koji se

razmjenjuju, te osnovnih modula za manipulaciju podacima. Sve ostale akcije su riješene kroz

standardizirane biblioteke. Time se omogućuje koncentriranje napora na samu funkcionalnost

prijenosa i njeno optimiranje.

4.Sustav poziva udaljenih procedura

4.1. Uvod u sustav poziva udaljenih procedura

Sustav poziva udaljenih procedura sastoji se iz dva sastavna dijela koji omogućuju

jednostavno kreiranje distribuiranih aplikacija. Osnovna ideja sustava poziva udaljenih

procedura je jednostavna, precizna i efikasna izgradnja distribuiranih sustava s pojedinim

funkcijama pravilno raspodijeljenim u postojećem protokolskom slogu, slika 4.1. Protokol

sjedničkog sloja je RPC (engl. Remote Procedure Call) /RFC57/, omogućava međuprocesnu

komunikaciju preko računalske mreže. Protokol prezentacijskog sloja XDR (engl. External

Data Representation) daje strojno nezavisnu metodu prikaza podataka, /RFC14/.

Uz ova dva protokola razvijen je i skup alata koji omogućuju razvoj procesa u aplikacijskom

sloju na bazi RPC usluga sjedničkog sloja i XDR usluga prezentacijskog sloja. Na temelju ta

dva 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 modela

Promatrano s stanovišta programske primjene, RPC u osnovi daje proširenje lokalne

memorije sustava pošto funkcije ostvarene putem njega mogu koristiti i argumente

specificirane ne samo po vrijednosti već i prema adresi. Rezultati poziva udaljenih procedura

mogu se prihvatiti i generirati na isti način kao i rezultati lokalnih funkcija. S stanovišta

izvođenja programa RPC daje okruženje koje omogućuje prijenos podataka i rezultata među

udaljenim mrežnim procesima na uniformni način. Mehanizam poziva udaljenih procedura

omogućuje jedinstveno definiranje usluge tj. funkcije koja će se izvesti s specificiranim

argumentima na udaljenom ili lokalnom čvoru. Način prijenosa argumenata operacija i

rezultata je omogućen XDR protokolom koji daje jedinstveno definiranje jednostavnih i

slož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 o

računalu i obratno, te rutine za zauzimanje i oslobađanje memorije na ciljnom računalu.

4.2. Građa sustav poziva udaljenih procedura

Ovisno o načinu ostvarenja aplikacije koja koristi pozive udaljenih procedura može se

razlikovati 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 dobro

poznatih usluga koji su u potpunosti odvojeni od mrežnog sučelja, i kao rezultat vraćaju samo

opće informacije korisniku (tablica 4.1). Prema drugim izvorima postoje još i finije podjele

koje uzimaju u obzir specifičnosti ostvarenja RPC-a na pojedinim operacijskim sustavima, a

navedena podjela je zajednička za sva ostvarenja.

Tablica 4.1: Neke dobro poznate usluge

usluga: opis usluge:

rusers vraća broj korisnika na imenovanom čvoru

havedisk daje informacije o imenovanom korisniku na imenovanom

čvoru

rstat dojavljuje da li imenovani čvor ima ili nema lokalni

disk

rnusers 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 prijenosu

podataka te verifikaciji. Ovaj sloj omogućava i optimalnu upotrebu automatskih generatora

koda. Mogući su i ručni zahvati u kodu ovog sloja tako da se mogu postići i određeni efekti

kao što su uvećanje sigurnosti, kontrola trajanja operacije, izmjena uloge klijenta i uslužitelja i

sl.

Interesantno je napomenuti da je pri razvoju standardnih komercijalnih produkata kao što je

uslužni program za NFS sustav proizvođač radio u drugom sloju uz manje modifikacije na

generiranom kodu, pa se stoga može zaključiti da je ovaj sloj najpogodniji za rad. Najviši sloj

se 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 i

ispitivanja prevede u najviši sloj.

Najniži sloj se najrjeđe koristi pošto je najsložniji za upotrebu. Taj sloj omogućuje direktan

pristup pristupnim točkama, a time i bitne promjene ponašanja aplikacije. Korištenje ovog

sloja dolazi u obzir, kada je potrebno prilagoditi aplikaciju na neki vrlo specifični protokol, no

mora se vrlo dobro paziti što se radi zbog narušavanja uniformnosti strukture programskog

koda, a time i ponašanja mehanizama prijenosa podataka i reakcije na mrežne događaje kod

prijenosa podataka.

Tablica 4.2: Osnovni funkcijski pozivi za ostvarivanje RPC funkcije

funkcija značenje

registerrpc omogućuje prijavljivanje usluge tj.

funkcije na mrežu

callrpc zahtijeva izvođenje određene usluge

Funkcije koje pružaju RPC usluge se grupiraju u programe koji se sastoje iz grupa srodnih

funkcija (tablica 4.2), (slika 4.2). Programi imaju jedinstvene brojeve koji omogućuju izbor

usluge, programa i njene verzije. Argumenti poziva callrpc specificiraju uz ova tri podatka

ime čvora na kojem se usluga izvodi, argumente na koji se izvodi, područje za pohranu

rezultata, 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 funkcije

RPC usluge također obuhvaćaju definiranje automatskih parametara sigurnosti sustava,

definiranje maksimalnog trajanja jedne operacije, te ostvarivanje struja podataka (engl. data

stream) 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 opisuje

poruke koje se razmjenjuju, te stanja kroz koja oba procesa prolaze. Poruke koje se prijenose

definiraju argumente za funkcijski poziv udaljene procedure i rezultat koji se vraća uključno i

kod 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čki

usluge koju pruža (u UNIX terminologiji "deamon"). Pri prispijeću podataka obavlja se

verifikacija zahtijeva, konverzija podataka, te samo izvođenje operacije s dobivenim

argumentima (slika 4.3). Kod koji izvodi operaciju mora napisati sam korisnik, dok se mrežno

suč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 struktura

podataka u XDR zapisu (slika 4.3). Rezultat se vraća obratnim redoslijedom, rezultat lokalne

operacije 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 mora

prijaviti sistemu tako da bi ona bila dostupna na cijeloj računalnoj mreži /SCO01/,/SCO02/.

Slika 4.3:Tok izvođenja poziva udaljene procedure

Na strani klijenta proces mora generirati pristup za klijenta do usluge i zatim zahtijevati samu

uslugu, 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 putem

automatskog generatora rpcgen-a. Korisnik sam mora osigurati pripremu podataka i

interpretiranje 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 definira

tip rezultata i unije svih mogućih tipova rezultata funkcije rezultata.

Svaka aplikacija je namijenjena izvršavanju nekog zadatka, tj primjeni u okviru rješavanja

nekog problema. Da bi se izgradila efikasna aplikacija na bazi RPC-a potrebno je izvršiti

analizu i dekompoziciju problema u cjeline iz kojih se mogu stvoriti skupine objekata

pogodnih za RPC izvedbu.

Na temelju navedenog jasno je da je za efikasnu upotrebu sustava RPC-a potrebno problem

razložiti u međusobno surađujuće cjeline na funkcionalnoj osnovi, te definirati za svaki grupu

funkcija koje čine jedan proces, sva stanja kroz koja on prolazi, te sve njihove interakcije s

okolinom.

4.3. Osnovni model odnosa procesa klijenta i uslužitelja

Realizacija RPC usluga zahtijeva definiranje procesa klijenta i uslužitelja struktura podataka

tj. poruka koje oni razmjenjuju, te protokola komunikacije između njih. Isto tako je potrebno

definirati i jedinstveni način reakcije na grešku i pružanja pomoći kao dio protokola

komunikacije.

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 ovakvog

modela 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 ili

brojeva 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, takvi

se čvorovi ponekad nazivaju i čvorovi uslužitelji ili samo uslužitelji, što ponekad dovodi do

kontradikcije 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 vezani

strojevi s konačnim brojem stanja (slika 4.4), (tablica 4.3, 4.4, 4.5, 4.6). U slučaju složenijih

odnosa oba procesa mogu se upotrijebiti za modeliranje odnosa Petrijeve mreže i drugi

pogodni alati za prikaz ponašanja ovisnih procesa.

Tablica 4.3: Opis poruka za proces uslužitelj

s1 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 zahtijeva

Tablica 4.4: Opis stanja za proces uslužitelj

Primanje 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čelja

c2 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čelja

c3 poruka uslužitelja s ponovnim zahtjevom usluge

c4 poruka uslužitelja o uspješnom ispunjenju zahtijeva

c5 poruka mrežnog sučelja o uspješnom prekidu veze

Tablica 4.6: Opis stanja klijent procesa

Slanje 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 obavlja

povezivanje pristupne točke s uslugom i funkcijom koja se obavlja. zahtjev za funkcijom se

poslužuje u više koraka. Pri prispijeću zahtijeva na pristupnu točku prispjeli podaci se

prijenose funkciji za izbor usluge i funkcije. Ova funkcija provjerava da li se zahtijeva

ispravna funkcija u okviru odabrane usluge, stupanj sigurnosti, konvertira pristigle podatke i

poziva kod za izvršavanje funkcije, te konvertira rezultat i vraća ga klijentu.

4.4. Ostvarivanje i definiranje usluge koja omogućuje

prijenos poruka između procesa putem poziva udaljenih

procedura

Za ostvarivanje prijenosa poruka putem poziva udaljenih procedura potrebno je u, skladu s

terminologijom primjene RPC-a, definirati protokol prijenosa poruke, te na temelju njega

definirati uslugu prijenosa poruka. Protokol definira način ponašanja procesa klijenta i

procesa uslužitelja za danu uslugu, a usluga definira konkretne parametre procesa.

4.5. Povezivanje i prepoznavanje komunicirajući procesa

putem poziva udaljenih procedura

Prepoznavanje procesa koji međusobno komuniciraju odvija se putem posebnog procesa za

kontrolu i dodjelu brojeva usluga. Prepoznavanje procesa odvija se putem broja usluge, broja

funkcije 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 uslugom

dodjeljuje 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 i

registrira tvz. privremene usluge putem kojih se može izgraditi privatni komunikacijski kanal

između dva procesa. Ta je metoda naročito korisna pri ostvarivanju procesa koji moraju čekati

proizvoljan period vremena da bi im se odgovorilo na zahtjev.

Program za praćenje vezanja spada u sistemske uslužne programe (engl. deamon) koji čine

transparentni dio podrške za bilo koji distribuirani sustav realiziran putem poziva udaljenih

procedura.

4.6. Upravljanje, nadzor i građa usluge i procesa koji

ostvaruju prijenos poruka

Distribuirane aplikacije i distribuirani sustavi se mogu graditi na više različitih načina, ovisno

o vrstama računalnih sustava na kojima se osnivaju. Jedan od sve popularnijih načina izvedbe

je upotreba poziva udaljenih procedura. Problem koji se rješava razlaže se u niz funkcija. Pri

razlaganju problema u sustav takvih funkcija mora se zadovoljiti niz zahtijeva i uzeti u obzir

niz elemenata koji utječu na efikasnost izvedbe sustava.

Distribuirani sustav podrazumijeva sustav surađujućih procesa koji međusobno razmjenjuju

podatke. Pri tome ti procesi mogu biti raspodijeljeni u domeni jednog računala ili u mrežnoj

domeni. Prema ovoj definiciji možemo uočiti potrebu za postojanjem čvrsto definiranog

protokola sporazumijevanja pojedinih procesa međusobno, pri čemu protokol komunikacije

definira građu podataka koji se razmjenjuju i način njihova zapisa. Tako definirani protokol

ujedno i definira potrebne konverzije tipova podataka ako su surađujući procesi smješteni na

raznorodnim računalima.

Uz tako definirane tipove podataka koji se razmjenjuju definiraju se i funkcije koje s tim

podacima rade, te statičke i dinamičke strukture podataka u okviru procesa koje služe za

pohranu i manipulaciju s podacima koji se razmjenjuju između procesa.

4.6.1. Transakcijski pristup izgradnji distribuirane aplikacije

Prijenos podataka među kooperirajućim procesima moguć je na više načina. Moguća su

povezivanja na osnovi stalno otvorenih tokova podataka i transakcijski pristup.

Prijenos podataka putem tokova podataka je osjetljiv na ispad procesa, te na greške u

komunikaciji, pošto podrazumijeva postojanje stalne veze između dva procesa. Isto tako nije

ga lako ostvariti putem osnovnih operacije jednostavne građe. Transakcijski pristup je pristup

u kome se jedna operacija prijenosa podataka i rezultata među kooperirajućim procesima

razmatra kao zatvorena cjelina s zadanim trajanjem, pri čemu komunikacijski medij između

procesa nije vidljiv /SUN04/. Ovaj pristup je jednostavan za izvedbu putem osnovnih

operacija i omogućava jasno odjeljivanje procesa koji šalje podatke i prima rezultat od

procesa koji izvodi operaciju. Proces koji šalje podatke i prima rezultat tj. koji poziva funkciju

se naziva klijent, a proces koji prima podatke, te generira i vraća rezultat tj. sadrži kod

funkcije 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 funkcija

4.6.2.Dekompozicija problema u sustav funkcija i tipova podataka

Problem koji distribuirana aplikacija ili sustav rješava treba razložiti u niz funkcija i tipova

podataka koji su argumenti i rezultati tih funkcija. Svaka od funkcija mora biti najpovoljnije

rješenje za jedan određeni dio problema i može predstavljati jednostavan strukturirani kod za

manipulaciju argumentima /KONG90/. Ovako definirane funkcije i njihovi argumenti mogu

se 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 kao

metode koje pripadaju tom objektu /KONG90/.

4.6.3. Grupiranje funkcija u surađujuće procese

Pojedine funkcije potrebno je grupirati u grupe prema međusobnoj zavisnosti. Takva skupina

funkcija čini jedan proces tj. u RPC terminologiji jednu uslugu. U okviru jedne usluge mogu

se razlikovati dvije osnovne skupine funkcija:

funkcije za izvedbu distribuirane operacije, te

funkcije za nadzor i kontrolu usluge.

Prva grupa funkcija kao što joj ime kaže rješava zahtjeve same distribuirane aplikacije. Druga

grupa funkcija služi za nadzor i upravljanje nad procesom. Sam sustav za rad s pozivima

udaljenih procedura automatski predviđa jednu funkciju koja služi samo za testiranje

postojanja usluge u okviru koje se ta funkcija nalazi /SUN02/, /SUN04/.

O rasporedu funkcija u usluge tj. surađujuće procese ovisi efikasnost distribuiranog sustava i

brzina njegova odziva. Grupiranje funkcije u usluge tj. izgradnja funkcionalnosti jednog

objekta mora zadovoljavati više različitih zahtijeva koji mogu biti i međusobno

kontradiktorni. zahtjevi se mogu podijeliti u nekoliko skupina:

-paralelnost operacija, što znači da se operacije koje se mogu odvijati paralelno, ne stavljaju

kao funkcije u okviru iste usluge, ako postoji vjerojatnost da će se one možda istovremeno

zahtijevati;

-sklopovska ovisnost, što znači da se funkcije koje pristupaju vrlo specifičnom sklopovlju

moraju biti u okviru iste usluge zbog jednostavnije izvedbe upravljačkih programa za

sklopovlje, posebno kontrole jedinstvenog pristupa sklopovlju;

-srodne strukture podataka, što znači da se funkcije koje koriste iste strukture podataka ili

isti mehanizam sigurnosti treba ugraditi u istu uslugu;

-redundancija i sigurnost, što znači da za kritične funkcije ili usluge treba predvidjeti više

od jednog uslužitelja ili postojanje iste funkcije u okviru raznih usluga, a ujedno i način

sinkronizacije tih funkcija i usluga ako je potrebno;

-redoslijed funkcija u izvođenju, što znači da funkcije koje se moraju sekvencijalno izvoditi

treba riješiti u okviru jedne usluge ako je ikako moguće, ili predvidjeti sustav sinkronizacije

ako nisu u okviru jedne usluge, sustav sinkronizacije se obično rješava uvođenjem

sinkronizacijskog primitiva tj. funkcije;

-strategija nadzora sustava, što znači da funkcije koje imaju iste nadzorne strukture i iste

mehanizme nadzora treba riješiti u okviru jedne usluge;

-strategija dohvata alternativnih uslužitelja, što znači da se za svaku funkciju u okviru

oporavka 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 i

sigurnost sukobljavaju s sklopovskom ovisnošću ili paralelnošću rada. Efikasan distribuirani

sustav je kompromis između navedenih zahtijeva.

4.6.4.Nadzor i upravljanje aplikacijom i uslugama

Svaka aplikacija zahtijeva postojanje nadzornog sustava koji omogućuje praćenje događanja u

sustavu 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 ili

pojedinoj usluzi i metoda generiranja kontrolnih ispisa.

Nadzor rada distribuiranog sustava svodi se na sistematski nadzor svih usluga koje čine

sustav. Tako se može reći da postoji nadzor sustava kao cjeline (skupa usluga) i pojedinih

usluga. Na razini sustava kao cjeline postoji dakle posebna usluga koja služi za koordinaciju

nadzora i upravljanja, a na razini svake usluge postoji niz funkcija za kontrolu i nadzor same

usluge, tvz kontrolno sučelje usluge. Nadzorna usluga dakle omogućuje nadzor i praćenje

cijelog sustava.

Kontrolno sučelje usluge je skup funkcija u okviru pojedine usluge koje omogućuju dohvat i

promjenu stanja procesa koji čini pojedinu uslugu, npr. definira se niz osnovnih operacija koji

dosižu interne statičke i dinamičke strukture podataka pojedinog procesa tj. usluge. Za svaku

se uslugu definira i stupanj praćenja aktivnosti (engl. activity log, debbuging level) koji

definira kontrolne ispise. Razina praćenja aktivnosti se obično mijenja putem kontrolnog

sučelja usluge.

Postoji više različitih pristupa izgradnji sustava kontrolnih ispisa. Metoda koja se koristi kod

standardnih aplikacija razvijenih na bazi poziva udaljenih procedura obično koristi 4 stupnja

prać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, te

greške.

Kod razvoja nekih specifičnih aplikacija koje se sastoje iz dobro definiranih funkcijskih

slojeva, što je tipično pri razvijanju distribuirane verzije neke standardne aplikacije, koristi se

metoda dubinskih ispisa /SUN04/. U tom slučaju se svakom funkcijskom sloju dodjeljuju dva

stupnja 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 kontrolnu

uslugu sustava, tako da stanje sustava uvijek bude konzistentno. Prema tome je očigledno da

kontrolna usluga sustava mora imati u sebi detaljno definiranu strategiju upravljanja sustavom

usluga tj. aplikacijom Definiranje te strategije nije jednostavno i ovisi o prirodi samog

problema, te paralelnosti i međusobnoj zavisnosti procesa koji čine aplikaciju.

Ova metoda pokazala se veoma efikasna u postupku testiranja i ispravljanja prijenosa poruka

putem poštanskog sandučića, jer omogućuje jednostavno izdvajanje i testiranje pojedinih

slojeva usluge u okviru procesa.

4.6.5.Definiranje i pohrana upravljačkih parametara sustava

Da bi sustav ispravno funkcionirao mora imati definirana stanja i parametre tih stanja. Pri

pokretanju sustava ti se parametri unose u sustav i to u pojedine usluge čime se omogućuje

njihova međusobna suradnja i konzistentnost sustava. Postoji više metoda trajne pohrane

navedenih podataka i njihovog unošenja u sustav. Uobičajeno je postojanje konfiguracijskih

datoteka 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 usluge

definira jedna koja dohvaća parametre iz konfiguracijske datoteke i druga koja zapisuje

parametre u konfiguracijsku datoteku.

Moguće su i druge metode, npr. da usluga pri aktiviranju čita podatke, tako da je za promjenu

podataka potrebno izvršiti gašenje i ponovo aktiviranje pojedine usluge.

Operacijski sustavi poput UNIX-a, (preporuka POSIX) predviđaju da su konfiguracijske

datoteke u tekstualnom formatu u obliku komandi koje pojedini procesi znaju izvoditi, kao

primjer se može uzeti NFS sustav realiziran putem RPC-a /RFC94/ i njegove konfiguracijske

datoteke, 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/home2

share -F nfs /dos/van

share -F nfs /cdrom

share -F nfs /hina

share -F nfs /usr

#end of dfstab

Slika 4.7: Popis sustava datoteka koji se eksportiraju ostalim čvorovima na mreži, primjer za operacijski

sustav SOLARIS 2.1

4.6.6. Model usluge

Pojedina usluga se realizira kao jedan računalski proces tj. program u izvođenju /TANN89/. S

stanovišta samog procesa mogu se uočiti tri faze aktivnosti procesa:

1. Aktiviranje procesa

2. Stanje normalne aktivnosti

3. Deaktiviranje procesa.

Svaka od tih faza ima pojedine specifičnosti. Aktiviranje procesa znači uključivanje usluge u

distribuiranu aplikaciju. To je prikupljanje inicijalnih parametara, prijavljivanje usluge, te

prelaz u stanje normalne aktivnosti. Tu je uključeno i inicijalizirane parametara unutar same

aplikacije. Obzirom na specifičnu prirodu aplikacija pisanih za pozive udaljenih procedura

preporuča se kod procesa koji je uslužitelj postojanje nadzorne zastavice koja pokazuje da li

je izvršena inicijalizacija podataka ili ne. Takav pristup je naročito pogodan za kod koji sadrži

dijelove generirane automatskim generatorom rpcgen koda, a u okviru računalskog procesa

postoje globalna stanja.

Stanje normalne aktivnosti je ono stanje u kojem usluga reagira na zahtjeve klijenata i

pristupa drugim uslugama sustava, već prema tome kakva joj je uloga u sustavu. Tu dolazi i

ispunjavanje zahtijeva vezanih uz nadzor i upravljanje uslugom.

Deaktiviranje usluge je vrlo delikatna faza pošto sustav tj. aplikacija u okviru koje usluga

djeluje mora ostati konzistentna. To podrazumijeva obavještavanje svih ostalih usluga, a

naročito nadzorne usluge o nastupajućem deaktiviranju procesa, te usklađivanje i promjena

konfiguracijskih datoteka i podataka ako je potrebno. Deaktiviranje usluge tj. nadzornog

procesa usluge obično zahtijeva period vremena u kome se mora sve dovesti u konzistentno

stanje i tek nakon toga prekinuti rad. Način deaktiviranja ovisi o prirodi usluge. Za nadzorne

procese kakav je proces koji nadzire poštanske sandučiće pogodno je deaktiviranje nakon

zadanog isteka vremena. Period proces dobiva kao argument poziva kontrolne funkcije i sam

sebi postavlja alarm signal i funkciju za prekid rada, slika 4.8.

funkcija onalarm()

početak

prekini_rad

kraj

funkcija deaktiviranje

argumenti

vrijeme dt

početak

poveži_signal ( alarm, onalarm)

pokreni_alarm_za ( dt )

kraj

Slika 4.8: Nacrt programa za kontrolnu uslugu deaktiviranja

Razmatranje distribuirane aplikacije kao sustava surađujućih procesa otkriva određene

probleme vezane uz ostvarenje takvog sustava procesa. Pokazuje se da je protokol

sporazumijevanja među surađujućim procesima izuzetno važan i da on predstavlja osnovu

sustava. Isto tako se može uočiti da je zbog prirode distribuirane aplikacije izuzetno važno

sagledati načine nadzora i upravljanja tom aplikacijom, te zadavanje konfiguracijskih

parametara aplikacije.

4.7. Pitanja sigurnosti sustava razmjene poruka

Pri korištenju poziva udaljenih procedura za realizaciju prijenosa poruka moguće je ugraditi

mehanizme 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ćih

metoda prepoznavanja i zaštite.

Mehanizam prepoznavanja i zaštite zasniva se na činjenici da se korisnik usluge tj. proces koji

poziva udaljenu procedura mora verificirati na sustavu na kojem se ta funkcija izvodi. Tako se

s podacima koji su argumenti funkcije prijenose podaci o procesu koji zahtijeva izvođenje

funkcije i o njegovom vlasniku i pravima. Ovaj mehanizam je ugrađen u sustav uslužnih

programa koji omogućuju izvođenje poziva udaljene procedura tako da ga je nemoguće

namjerno 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 sigurnosti

operacijskog sustava UNIX;

korisnički protokol sigurnosti, kada korisnik definira svoj specifični protokol sigurnosti koji

može uključivati i dodatne provjere podataka koji se prijenose, prevođenje i dekodiranje, te

druge proizvoljne zahvate.

Verifikacija može biti definirana kao dinamički ili statički parametar sustava. Kao dinamički

parametar ona se može mijenjati u skladu s komandama koje dobiva od upravljačke usluge ili

putem nekog drugog mehanizma. Kao statički parametar ona se zadaje jedanput za cijelo

trajanje rada sustava. Zadavanje stupnja verifikacije ne smije biti dostupno procesu koji izvodi

osnovne operacije za prijenos poruka.

Treba spomenuti da veći stupanj verifikacije usporava odziv sustava. Prema najnovijim

podacima, tj. prema /SUN02/ na operacijskom sustavu Solaris 2.1 postoji pet razina

prepoznavanja u koja su uklopljena postojeća tri. Takvo stanje zna dovesti do

nekompatibilnosti aplikacija.

5. Ostvarivanje metode susreta za

najjednostavniji slučaj prijenosa poruke

između procesa

Najjednostavniji slučaj metode susreta je ujedno i primjer za najjednostavnije ostvarivanje

pozivanja udaljene procedure pa može poslužiti za praktičnu demonstraciju. Dokumentirani

programski kod, specifikacija u XDR jeziku, te potrebne komandne datoteke potrebne za

prevođenje na ciljnom računalnom sustavu nalaze se u dodatku A. Procesi primač i pošiljač su

najjednostavnije 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 za

prijenos poruke. Primač je zbog jednostavnosti ostvaren kao pravi proces uslužitelj koji se

odvija u beskonačnoj petlji. Oba procesa se sinkroniziraju pri prijenosu poruke (slika 5.1). Pri

prijemu 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 znakova

zadane dužine.

Slika 5.1: Redoslijed prijenosa poruke između procesa primača i pošiljača

Zbog jednostavnih zahtijeva na prijenos i ponašanje procesa standardnu građu procesa

primača je moguće znatno pojednostavniti. Pošto je to standardni proces uslužitelj za njega je

dovoljno samo jednom prijaviti uslugu prijenosa poruke na mrežni sustav, a pošto ne postoji

nikakva specifična akcija vezana uz prijem poruke moguće je osnovne operacije primi i vrati

spojiti 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 ne

poč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

kraj

kraj.

Slika 5.2: Nacrt programa za proces pošiljač poruke

Na strani pošiljača postoji osnovna operacija šalji, koja nije modificirana (slika 5.2), a na

strani primača poruke osnovne operacije primi i vrati su stopljene u jednu osnovnu operaciju

tj. jest u kod za ostvarivanje usluge (slika 5.3).

funkcija send_1

varijabla poruka p; //poruka koja se prima preko RPC sustava

početak � //nema nikakvih operacija s porukom samo se vrača kod uspješnosti

u RPC sustav

vrati ( 0 );

kraj.

Slika 5.3: Nacrt programa za proces osnovne operacije primi i vrati

Osnovni cilj ostvarivanja ovakvog prijenosa poruka je demonstracija primjene sustava poziva

udaljenih procedura s namjerom da se prikaže jednostavnost upotrebe. Za detaljno objašnjenje

postupka kodiranja i specificiranja sustava osnovanog na pozivanju udaljenih procedura može

se proučiti literatura /SUN02/, /SUN03/, a za osnovno razumijevanje specifikacije u XDR

jeziku, a time i protokola komunikacije između procesa klijenta i uslužitelja može poslužiti

slika 5.4 na kojoj se nalazi XDR specifikacija najjednostavnijeg prijenosa poruka između

procesa.

Slika 5.4: Specifikacija programa u XDR jeziku za osnovne operacije primi i vrati

6. Ostvarivanje metode susreta pozivanjem

udaljenih procedura

6.1. Mogući postupci ostvarivanja metode susreta

Metoda susreta podrazumijeva u idealnim uslovima direktnu blokirajuću komunikaciju

procesa pošiljača poruke i procesa primača poruke. Da bi se metoda susreta ostvarila putem

poziva udaljenih procedura potrebno je osnovne operacija šalji, primi, vrati realizirati putem

poziva udaljenih procedura. Moguća je izvedba na više načina od koji su odabrana dva

najkarakterističnija:

ostvarenje bez primjene povratnog poziva,

ostvarenje s primjenom povratnog poziva.

Ovi načini su odabrani zato što dozvoljavaju primjenu automatskih alata za generiranje

programskog koda na temelju specifikacije, te zato što omogućuju jednostavno razdvajanje

programskog koda u nezavisne module.

6.2. Primjena metode neposrednog povezivanja pošiljača i

primača

Metoda susreta se može relativno jednostavno izvesti pozivanjem udaljenih procedura, sa

svim osnovnim operacijama. Za realnu izvedbu moguće je poslužiti se standardnim

generatorom koda, s time da se strana primača poruke mora modificirati. Modifikacija se u

osnovi svodi na to da primač poruke može biti uslužitelj za RPC uslugu primanja poruke i da

ne 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 obavila

usluga

varijabla cijeli broj i; //pomoćna varijabla

poč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-run

Na strani pošiljača poruke nikakve modifikacije nisu potrebne pa se programski kod za

osnovnu operaciju šalji ne mora modificirati (slika 6.2). Modifikacija pošiljača predstavlja

odstupanje od standardne građe procesa uslužitelja i na granici je primjene automatskog

generatora koda. Uz pomoć detaljne analize koda koji se koristi za ostvarivanje srednjeg sloja

sustava pozivanja udaljenih procedura /SUN04/, /STE90/ mogu se uočiti zahvati koji su

potrebni na programskom kodu tako da se ne naruši stabilnost i pouzdanost procesa

uslužitelja, a da se ispravno ostvare osnovne operacije primi i vrati (slika 6.3). Potrebna

modifikacija se svodi na definiranje bloka programskog koda koji je u stanju na temelju

detektiranih vanjskih uslova (prispijeće poruke kroz RPC sustav) prihvatiti poruku, prekinuti

stanje čekanja na prijem poruka, obaviti potrebne operacije na poruci i vratiti povratnu poruku

procesu pošiljaču. Navedeni programski kod riješen je gniježđenjem funkcija tako da bi se

izbjegla manipulacija se osjetljivim sistemskim strukturama podataka koje obavljaju prihvat

poruka u RPC sučeljima, te modifikacijom jedne standardne funkcije RPC sustava. To je

standardna funkcija svc_run koja predstavlja proceduru za prihvat poruke od RPC sučelja i

njeno ispravno prosljeđivanje rutini za transformaciju i izračunavanje, u osnovi to je

procedura 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 temelju

zajedničkih elementa izvedena je modifikacija njenog programskog koda, u skladu s

preporukom /RFC57/, tako da standardni proces uslužitelj usluge postaje sposoban mijenjati

svoje stanje (slika 6.1, dodatak B1, datoteka svc_run.c).

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 ne početak

pripremi poruku( p ); //generiranje poruke o

cisti_povratno( q ); //priprema prostora za povratnu poruku

st = šalji(id, p,q) ako je (st == USPJELO ) tada ispis_poruka (q); kraj inače greška(st); //ispis

greške i razloga neuspjeha kraj

kraj.

Slika 6.2: Nacrt programa za proces pošiljač poruke

Zbog prirode građe sustava poziva udaljenih procedura koji je osnovan na modelu ponašanja

upravljanog pojavom događaja, potrebno je također i dodati posebne globalne varijable za

prijenos i pamćenje vrijednosti poruka kod procesa primača.

Međusobno prepoznavanje uslužitelja i klijenta ne mora se modificirati i ono ostaje

standardno. 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 prepoznavanje

procesa u okviru pozivanja udaljenih procedura i uklopljneo u standardni sustav pozivanja

udaljenih procedura na ciljnom računalnom sustavu.

Program primač

varijabla poruka p; //poruka koja se prima, argument

varijabla poruka q; //poruka koja se vraća, rezultat

varijabla idproc id; //id. pošiljača poruke

početak

prijavi_primanje(); //prijava primača, tj. usluge na mrežu

primi(id,p); //primi poruku

// proces je stanju RPC uslužitelja

//usluga je još uvijek aktivna na mreži

transformiraj_poruku(p,q);

//izračunaj rezultat

//proces je napustio stanje RPC

//uslužitelja

vrati(id,q);

//vrati rezultat, proces se vratio u stanje

//uslužitelja

//završni dio funkcionalnosti uslužitelja

odjavi_primanje(); //odjava primanja poruka

kraj.

Slika 6.3: Nacrt programa za proces primač poruke

Strukture podataka koje se koriste u izvedbi su standardne i vezane su na građu poruka koje se

razmjenjuju. 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 prazni

tip (engl. void) koji dogovorno znači pogrešku.

Kontrola trajanja stanja oba procesa definirana je standardnim metodama tj. postavljanjem

vremenskog ograničenja /SUN02/,/SUN01/,/SUN04/. Ako vremensko ograničenje istekne

proces pošiljač dobiva poruku o grešci od RPC sučelja prema nižem RPC sloju. Ta se poruka

interpretira kao greška.

Na temelju ponašanja procesa primača i pošiljača može se reći da ova metoda efikasno

uslužuje prijenos poruka između dva procesa koji samo povremeno izmjenjuju poruke, te koji

pri tome imaju čvrsto definirano maksimalno trajanje operacije prijenosa poruke. Razlozi za

takav zaključak su obimne operacije na strani procesa primača pri prijavi i odjavi usluge, te

postojanje maksimalne granice za trajanje jednog poziva udaljene procedure.

Potpuni programski kod, komandne procedure te specifikacija u XDR jeziku nalaze se u

dodatku B1.

6.3. Primjena metode privremene usluge

Nedostaci metode neposrednog povezivanja pošiljača i primača nalaze se u teškoćama pri

postavljanju granice vremenskog ograničenja pri čemu je proces pošiljač blokiran pri čekanju

odgovora na jednu specifičnu uslugu, tj na povratnu poruku. Trajanje takvog vremenskog

ograničenja ne treba biti konačno posebno ako se ima na umu da se prijenos poruka može

upotrijebiti u za sinkronizaciju procesa /MAE87/, /AND90/, /STE90/. Da bi se izbjeglo da

proces pošiljač dobiva poruke o isteku vremenskog ograničenja, tj. da mrežni računalni sustav

prekida prijenos poruka, potrebno je dozvoliti procesu pošiljaču da postane privremeni

uslužitelj tj. da može proizvoljno dugo biti u stanju čekanja. Takav pristup ima više prednosti

proces pošiljač je u stanju proizvoljno dugo čekati na odgovor

proces pošiljač može primiti upravljačke zahtjeve bez prekida rada, pošto je on sada

standardni uslužitelj.

Za postizanje takvog ponašanja procesa primača i pošiljača potrebno je modificirati osnovne

operacije za primanje i slanje poruke, te građu same poruke na takav način da se kao dodatni

argument poruke koristi indentifikator privremene usluge. Program pošiljač generira

privremenu uslugu, te njen identifikator prijenosi kao dodatni argument kod slanja poruke. Pri

ostvarivanju postupka generiranja privremene usluge mora se striktno paziti na postupak

dobivanja usluge od procesa za kontrolu vezanja usluga i pristupnih točaka (engl. portmaper).

Identifikator privremene usluge se nalazi u rasponu brojeva usluga 0x40000000 - 0x5fffffff u

tvz. privremenom području /SUN02/. Nakon slanja poruke pošiljač postaje uslužitelj za

privremenu uslugu gdje čeka na povratnu poruku generiranu od primača putem osnovne

operacije vrati (slika 6.4).

funkcija šalji (p,q)

argument poruka p; //poruka koja se šalje

argument poruka q; //povratna poruka

početak

prijavi_privremenu_uslugu(p);

//dobiva se broj privremene usluge i upisuje u

//poruku p

ako je privremena_usluga_uspjela(p)

tada

prenesi_RPC_poruku(p);

//poziv RPC sučelja za aktiviranje usluge i

//prijenos poruke

postani_uslužitelj();

//povezivanje privremene usluge sa

//funkcijom za prihvat poruke, te

//te pokretanje modificirane SVC_RUN

//funkcije

odjavi_uslugu(p);

//odjava privremen usluge

//broj usluge se oslobađa

ako je uspješno_primljen_i_ispunjena(q)

vrati q

inače

vrati grešku

kraj.

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 ostvarivanje

metode susreta bez povratnog poziva, pošto se i tu mora koristiti modificirana funkcija

svc_run, pošto pošiljač i primač moraju mijenjati stanje iz klijenta jedne usluge u uslužitelja

druge.

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 poruku

pošiljaocu putem osnovne operacije vrati (slika 6.6). Obično se uzima da je rezultata

privremene usluge bez vrijednosti (engl. void), koji u ovom slučaju nema dogovorno značenje

greške.

funkcija primi (p)

argument poruka p; //poruka koja se šalje

početak

prijavi_uslugu_prijenosa_poruke();

//prijava usluge za prijenos poruka

//poruku p

ako je prijava_uspjela()

tada

postani_uslužitelj();

//povezivanje usluge sa

//funkcijom za prihvat poruke, te

//te pokretanje modificirane SVC_RUN

//funkcije, tu je stvarni prijem poruke od

//primača

odjavi_uslugu();

//odjava usluge

//broj usluge se oslobađa

ako je uspješno_primljen_i_ispunjena(q)

vrati q

inače

vrati grešku

kraj.

Slika 6.5: Nacrt programa za funkciju primi s generiranjem privremene usluge

Pošto ne postoji standardna funkcija za generiranje brojeva privremenih usluga bilo je

potrebno ostvariti tu funkciju. Prema preporukama za imenovanje funkcija, funkcija za

generiranje brojeva privremenih usluga je nazvana gettransient. U različitoj literaturi

/SUN01/, /SUN02/, /SUN04/,/SCO03/, ona je riješena na razne načine. Na temelju

zajedničkih elementa izvedena je modifikacija njenog programskog koda, u skladu s

preporukom /RFC57/, tako da je pristup sistemskom procesu uslužitelju standardan na

svakom ciljnom računalnom sustavu (dodatak B2, datoteka get.c).

funkcija vrati (q)

argument poruka q; //povratna poruka

početak

ako je privremena_usluga_uspjela(p)

tada

prenesi_RPC_poruku(q);

//poziv RPC sučelja za aktiviranje usluge i

//prijenos poruke preko privremene usluge

// to je sada klijent strana

ako je uspješno_preneseno(q)

vrati q

inače

vrati grešku

kraj.

Slika 6.6: Nacrt programa za funkciju vrati s generiranjem privremene usluge

Da bi se omogućila jednostavna povezivanja usluge tj. programskog koda koji opslužuje

prispijeće poruke kroz RPC sučelje (od nižih slojeva) potrebno je i modificirati postupak

vezanja RPC sučelja s tim programskim kodom. Za te svrhe je razvijena posebna funkcija

becameserver koja omogućuje jednostavno vezanje broja usluge, verzije usluge te

programskog koda (ostvarenog kao funkcija u programskom jeziku C). Funkcija je ostvarena

u skladu preporukama /RFC57/, (dodatak B2, datoteka become.c)

S stanovišta izvedbe operacije šalji, primi i vrati ova metoda omogućuje pisanje urednijeg

koda kod koga su intervencije programera u kodu prirodnije nego u slučaju metode

neposrednog povezivanja pošiljača i primača. Ovakvo ostvarenje prijenosa poruka je pogodno

za procese koji povremeno komuniciraju prijenosom poruka, ali kod kojih vremensko

ograničenje trajanja prijenosa ne postoji.

Usprkos tome što procesi primač i pošiljač mijenjaju stanja i što se pojavljuju periodi vremena

kada usluga prijenosa poruka nije aktivna (trenuci kada se usluga prijavljuje ili odjavljuje) oba

procesa su kvalitetno surađivala bez pogrešaka.

Potpuni programski kod, komandne procedure te specifikacija u XDR jeziku nalaze se u

dodatku B2.

7. Ostvarivanje metode poštanskog

sandučića

7.1.Mogući postupci ostvarivanja metode poštanskog

sandučića

Metoda poštanskog sandučića zahtijeva postojanje uslužnog procesa koji nadzire poštanske

sandučiće za odlaganje poruka. To odmah zahtijeva definiranje načina upravljanja i nadzora

tog 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 nadzornu

uslugu i njoj pripadne nadzorne strukture podataka, dovoljno je samo uvesti nadzorne funkcije

za 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 poznavanje

identifikatora poštanskog sandučića bez drugih provjera. Proces je verificiran ako poznaje

broj tj. identifikator poštanskog sandučića.

Za ostvarivanje metode poštanskog sandučića odabrane su dva načina

primjena 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 razvijene

modifikacije RPC funkcija mogu koristiti i u ostvarivanju metoda poštanskog sandučića.

7.2. Građa uslužnog procesa

Uslužni proces je građen na temelju standardnog uslužnog procesa za sustav poziva udaljenih

procedura. Njegov zadatak je da upravlja strukturama poštanskih sandučića, provodi politiku

sigurnosti, ispunjava zahtjeve klijenata za čitanje i pisanje, te da ispunjava zahtjeve

upravljačkog klijenta. Nadzorni proces zbog toga mora biti ostvaren s "pamćenjem" tj. ne kao

usluž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 pojedinog

poštanskog sandučića. prema tablici 7.1. Njihov je zadatak da omoguće potpuno interaktivno

upravljanje nadzornim procesom za poštanske sandučiće.

Tablica 7.1: Nadzorne funkcije uslužnog procesa poštanskog sandučića

dozvoli dozvoli pristup odabranom redu

zabrani zabrani pristup odabranom redu

očisti očisti sve poruke iz odabranog reda

status dohvati i ispiši status odabranog

reda

postavi 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 komunikaciju

s nadzornim uslugama. Za ispis stanja pojedinih usluga korištena je metoda /KONG90/ s

definiranjem dva stupnja kontrole ispisa po jednom stupnju gniježđenja funkcija, jer se

funkcije grupiraju u biblioteke na osnovi istog stupnja općenitosti. Prva kontrolna razina

ispisuje samo pojavu događaja, a druga kontrolna razina ispisuje i parametara (ulazne i

izlazne argumente) događaja. Navedena metoda je modifikacija preporučenog postupka

prać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. Sustav

funkcija za manipulaciju redovima poruka i potrebne strukture podataka dane su u dodatku D.

7.3.Modifikacije općenitih operacija i potrebne strukture

podataka

Izvedba metode poštanskog sandučića putem poziva udaljenih procedura omogućuje

neposrednu upotrebu nemodificiranog koda na temelju specifikacije usluge poštanskog

sandučića. Osnovne operacije piši i čitaj mogu se neposredno izvesti putem generatora koda.

struktura sandučić

početak

cijeli_broj: zastavice; //zastavice stanja sandučića

red: poruke;

red: zahtjevi_za_pisanje;

red: zahtjevi_za_čitanje;

kraj.

Slika 7.1: Struktura poštanskog sandučića

Funkcionalnost nadzornog procesa također se može direktno generirati putem generatora

koda. Dodatni zahtjevi postaju potrebni kod primjene metode privremene usluge kada je

potrebno da se u okviru osnovnih operacija piši i čitaj izvede privremena usluga, a kod

uslužnog programa konzistentno mijenjanje stanje iz uslužitelja u klijenta, te nezavisno

opsluživanje nadzornih usluga.

Uslužni proces poslužuje polje poštanskih sandučića proizvoljne veličine, građa poštanskih

sanduč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 i

načina na koji je riješen sam prijenos poruka između procesa provedena su neka

pojednostavljena koja su objašnjena s metodama u kojima su primijenjena.

7.4. Primjena metode neposrednog povezivanja pošiljača i

primača

Pri neposrednom povezivanju procesa koji čita ili piše u poštanski sandučić primijenjeno je

direktno neposredno povezivanje pozivom udaljene procedure. Zbog jednostavnosti izvedbe

definirano je neblokirajuće čekanje tj. ako se operacija na poštanskom sandučiću ne može

obaviti tada proces koji je operaciju zahtijevao biva odmah obaviješten o tome prikladnim

kodom 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 NFS

sustav koji je opisan u /RFC94/.

Prijenos poruka je riješen na standardni način za pozive udaljene procedure, tako da su klijenti

odvojeni u posebne procese. Upravljačka usluga je odvojena u posebni upravljački program

koji 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 prevesti

specifikaciju u XDR jeziku i tako dobiveni programski kod vezati s sustavom za manipulaciju

redovima.

Potpuni programski kod, komandne procedure, te specifikacija u XDR jeziku nalaze se u

dodatku C1.

7.5. Primjena metode privremene usluge

Primjena metode privremene usluge omogućuje da se u potpunosti ostvari blokirajuće čekanje

između klijenata i uslužnog procesa. Na taj način je ostvarena bolja i preciznija

implementacija standardnog sustava poštanskih sandučića.

Za ostvarivanje privremene usluge korištene su potrebne modifikacije koje su opisane u

poglavlju 6, a koje omogućuju jednostavno i efikasno umetanje i upotrebu privremenih usluga

i promjene stanja klijenata i uslužitelja.

Privremena usluga je sada parametar koji označava da se zahtjev za pisanje ili čitanje nije

mogao ispuniti pa je morao biti suspendiran i zapisan u red čekanja. Postupak ostvarivanja

privremene 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 u

poštanski sandučić nadzorni program provjerava stanje redova blokiranih procesa i rješava

sve one ranije zahtjeve koje može izvršiti. Izvršavanje ranijih zahtijeva riješeno je u okviru

posluživanja suprotnog zahtijeva, pa se time postiže potpuna sinkronizacija nadzornog

procesa i procesa koji komuniciraju s njim.

funkcija čitaj (msg, id)

argumenti

poruka msg //poruka u koju se čita iz reda

identifikator_reda id //identifikator reda iz kog se čita

varijable

poštanski sandučić mb //postanski sandučić

red_poruka ms //red poruka u mb

red_poruka ps //red blokiranih pisanjem

početak

mb=uzmi_mbox(id)

ako ne postoji mb // provjera postojanja mbox-a

tada

vrati gresku

inače

ms=uzmi_red_poruka(mb)

ako je neprazan(ms)

tada

//poruka se može pročitati

msg=uzmi_poruku(ms);

ps=uzmi_red_blokiranih_pisanjem( mb )

//budi fer prema svim procesima koji čekaju od prije //ispuni njihove zahtjeve

dok je ( (ms nije pun) i (ima blokiranih u ps ))

čini

piši_u_red(ms, uzmi_poruku(ps))

vrati u_redu

inače

//ne može se čitati proces mora čekati

piši_u_red_blokiranih_citanjem(mb,msg)

vrati blokirano

kraj

Slika 7.2: Nacrt programa za čitanje iz poštanskog sandučića

funkcija piši (msg, id)

argumenti

poruka msg //poruka u koju se čita iz reda

identifikator_reda id //identifikator reda iz kog se čita

varijable

poštanski sandučić mb //postanski sandučić

red_poruka ms //red poruka u mb

red_poruka ps //red blokiranih pisanjem

početak

mb=uzmi_mbox(id)

ako ne postoji mb

tada

vrati grešku

inače

ms=uzmi_red_poruka(mb)

ako nije pun(ms)

tada

piš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_redu

inače

piši_u_red_blokiranih_pisanjem(mb,msg)

vrati blokirano

kraj

Slika 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 mora

se 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 u

poštanskom sandučiću opslužuju prije nego što proces koji je omogućio njihovo oslobađanje

dobije povratnu informaciju tj. rezultat svoje akcije (slika 7.2 i 7.3), na taj način se ubrzava

odziv sustava, a svi zahtjevi imaju približno isto trajanje pa ne dolazi do izgladnjivanja

procesa. Takvo rješenje ima nedostatak jer se u dijelu programskog koda koji opslužuje

zahtjev i koji je uslužitelj, gnijezde pozivi udaljenih procedura (povratni pozivi blokiranim

klijentima). To nije u skladu s principima gradnje poziva udaljenih funkcija, gdje se preporuča

izbjegavanje takvih gniježđenja /RFC57/, /SAN91/.

funkcija operacija( msg )

argumenti

poruka msg //poruka u koju se čita ili piše

varijable

broj rez //rezultat rpc poziva

broj tmp //privremena usluga

početak

tmp=generiraj_tmp_uslugu(); //generiranje privremene usluge

ako je tmp=greška

tada

vrati greska

prijavi_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 rez

kada je greska:

tada //poziv nije uspio

odjavi_uslugu(tmp);

objasni_gresku(stat);

vrati greska

kada je blokirano

tada //poziv je blokiran ćekaj!

cekaj_na_uslugu();

odjavi_uslugu(tmp)

vrati uspjeh

ostalo

tada //poziv je uspio

odjavi_uslugu(tmp)

vrati uspjeh

kraj

Slika 7.4: Općenita građa funkcije koja piše ili čita iz poštanskog sandučića

Da 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 da

dobiva informaciju od nadzornog procesa da je njegov zahtjev blokiran (slika 7.4). Na taj

način navedeni proces privremenu uslugu koristi samo ako je doveden u stanje čekanja, pa se

dopunski zahvati oko manipulacije privremenom uslugom obavljaju samo onda kada su

neophodni što poboljšava učinak sustava.

8. Zaključak

Izvedba prijenosa poruka razrađena u okviru ovog rada omogućava prijenos poruka na

stvarnim umreženim sustavima podržanim TPC/IP mrežama. Razvijeni kod i postupci

nadgledanja ostvareni su na računalima pod raznim operacijskim sustavima i isprobani su u

domeni 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 obzir

ograničenja pojedinih operacijskih sustava kao što je npr. DOS koji zbog svoje prirode ne

može biti efikasan uslužilac.

Tablica 8.1: Ciljna računala i operacijski sustavi

Računalo Operacijski Princip susreta Poštanski sandučić

sustav

PC386 SCO UNIX za sve navedene za sva navedene

izvedbe izvedbe

PC386 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žitelj

mico VAX VMS 5.2 nije funkcionirao nije funkcionirao

RPC paket RPC paket

SUN 10/30 Solaris 2.1 za sve navedene za sve navedene

izvedbe izvedbe

Upotrjebljene metode omogućuju razvoj nadzornih procesa i uniformnu transparentnu

komunikaciju prijenosom poruka za distribuirane sustave upotrebom poziva udaljenih

procedura. Primjena prijenosa poruka u aplikacijskom sloju omogućuje povezivanje potrebnih

procesa distribuirane aplikacije na raznorodnim računalnim sustavima i raznorodnim

protokolima uz maksimalno poopćavanje protokola prijenosa poruke.

Ovako ostvareni postupci prijenosa poruka se mogu upotrijebiti za daljnji razvoj distribuiranih

sustava. 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 upotrebe

sustava udaljenih funkcija. Takav zaključak može se donijeti na temelju analize dostupnih

specifikacija naročito specifikacija /RFC94/,/RFC57/,/RFC14/, posebno iz premisa koje su

korištene pri razvoju NFS sustava /RFC94/, te preporučene metodologije izvedbe mrežnih

sustava na operacijskom sustavu UNIX /STE90/. Pozivi udaljenih procedura su specificirani

tako da preferiraju sustave osnovane na uslužiteljima i uslugama koji obavljaju jednostavne i

atomarne poslove s unutrašnjom građom čija složenost ne prelazi strojeve s konačnim brojem

stanja, 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 poziva

udaljenih procedura, pošto pozivanje udaljenih procedura u sebi ugrađuju prijenos podataka u

obliku "sirovih" poruka na razini pristupnih točaka, što se može uočiti analizom izvornog

koda sustava SUN RPC /SUN04/, te /STE90/. Zbog toga se prijenos poruka u aplikacijskom

sloju može promatrati kao poopćeno proširenje osnovnog sustava prijenosa poruka koji čini

sam 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 prijenosu

poruka, a koji bi zahtijevali svaki posebno ostvarenje sustava prijenosa poruka između

procesa.

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 Volume

I",Prentice Hall Englewood Cliffs, NY, 1989.

/COMM91/ D.E.Commer,D.L.Stevens:"Internetworking with TCP/IP Volume

II",Prentice Hall Englewood Cliffs, NY, 1991.

/COMM93/ D.E.Commer,D.L.Stevens:"Internetworking with TCP/IP Volume

III",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 Hall

Englewood Cliffs, NY, 1990.

/MAEK87/ M.Maekava,A.E.Olendorft,R.R.Olendorft:"Operating Systems Advanced

Concepts", The Benjamin Cummings Publishing Co. Inc, 1987

/MALA89/ Carl Malamund: "DEC Networks and ARCHITECTURES", Intertext

Publicatiuons, 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", SUN

Microsystems Inc, 2550 Garcia Avenue, Mountain View,CA 94043, USA, March 1989.

/RFC57/ "Reguest for commnets 1057: RPC Remote Procedure Call Protocol

specification" SUN Microsystems Inc, 2550 Garcia Avenue,Mountain View, CA 94043,

USA, March 1989.

/RFC94/ "Reguest for commnets 1094: NFS Network File Systen Protokol

Specification",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 Administartor's Guide", Santa Cruz

Operations Inc., 12 March 1991.

/SCO2/ "SCO Network File System (NFS), Programmers's Guide", Santa Cruz

Operations Inc., 12 March 1991.

/SCO3/ "SCO Network File System (NFS) Reference Guide, ", Santa Cruz Operations

Inc., 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", SUN

Microsystems 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, 2550

Garcia Avenue, Mountain View, CA94043, USA, Part No: 800-6982-10, Revision A, May

1992.

/SUN03/ "Network Programming Guide, For SunOS 4.01",SUN Microsystems Inc, 2550

Garcia Avenue, Mountain View, CA94043, USA, Part No: 800-6982-10, Revision A, May

1992.

/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 Hall

Englewood Cliffs, NY, 1989.