Dokument istražuje mehanizme razmjene poruka između procesa kroz pozive udaljenih funkcija, s naglaskom na osnovne operacije i strukture podataka koje podržavaju međuprocesnu komunikaciju. Razmatra se usklađivanje procesa putem metoda susreta i poštanskih sandučića, te se predlažu načini za stvaranje nadzornog procesa za upravljanje porukama. Također, dokument analizira različite metode prijenosa poruka, poput korištenja poziva udaljenih procedura, i definira osnovne ciljeve u prijenosu podataka i sinkronizaciji procesa.

1. 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/.

2. 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/.

3. 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.

4. 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).

5. 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

6. 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

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

8. 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.

9. 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.

10. 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/.

11. 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).

12. 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):

13. 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).

14. 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/:

15. 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

16. 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/.

17. 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

18. 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.

19. 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

20. 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.

21. 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.

22. 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.

23. 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.

24. 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.

25. 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

26. 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.

27. 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

28. 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

29. 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 )

30. 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

31. 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;

32. 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

33. 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

34. 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)

35. 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

36. 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)

37. 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.

38. 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.

39. 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.

40. 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.

41. 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

42. 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

43. 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

44. 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

45. 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

46. 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

47. 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

48. /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.