SSKKRRIIPPTTA

Autor: Boidar Kovai..

Rijeka, 2012..

SADRAJ

1.

UVOD .............................................................................................................................. 3

1.1.

Hardware.............................................................................................................................................. 7

1.2.

SOFTVER ............................................................................................................................................. 10

1.3.

Klijent-server model .......................................................................................................................... 16

2.

KOMUNIKACIJA ............................................................................................................ 19

2.1.

Protokoli slojeva za komunikaciju ..................................................................................................... 19

2.2.

Poziv procedure na udaljenom raunalu RPC ................................................................................ 22

2.3.

Poziv metode na udaljenom raunalu RMI .................................................................................... 26

2.4.

Meusloj usmjeren prijenosu poruka ............................................................................................... 27

2.5.

Primjena toka (stream) ...................................................................................................................... 29

3.

SINHRONIZACIJA U DISTRIBUIRANIM OPERACIJSKIM SUSTAVIMA ........................... 33

3.1.

Sinkronizacija sata ............................................................................................................................. 33

3.2.

Algoritmi za odabir ............................................................................................................................ 36

3.3.

Mutual Excluison................................................................................................................................ 38

3.4.

Atominost ......................................................................................................................................... 40

4.

PROCESI ........................................................................................................................ 43

4.1.

Procesne niti (thread) ........................................................................................................................ 43

4.2.

Klijenti ................................................................................................................................................ 46

4.3.

Serveri ................................................................................................................................................ 47

4.4.

Migracija koda.................................................................................................................................... 48

4.5.

Softverski agenti ................................................................................................................................ 50

5.

IMENOVANJE ................................................................................................................ 51

6.

KONZISTENTNOST I REPLIKE ........................................................................................ 55

6.1.

Distribuirani protokoli ....................................................................................................................... 57

6.2.

Protokoli konzistentnosti .................................................................................................................. 58

7.

TOLERANCIJA NA GREKE ............................................................................................ 62

7.1.

Greke u distribuiranim sustavima.................................................................................................... 62

7.2.

Atominost ......................................................................................................................................... 68

7.3.

Opravak .............................................................................................................................................. 69

8.

SIGURNOST ................................................................................................................... 71

8.1.

Sigurnosna politika i sigurnosni mehanizmi .................................................................................. 71

8.2.

Sigurnosni kanali ................................................................................................................................ 75

8.3.

Integritet poruka i pouzdanost ........................................................................................................ 77

8.4.

Kontrola pristupa ............................................................................................................................. 79

8.5.

Sigurnost mobilnog koda ................................................................................................................. 81

1. UVOD
Distribuirani sustavi (DS) omoguuje izvoenje obrade podataka koritenjem svih
raspoloivih resursa mree raunala. Za razliku od mrenih sustava koji omoguuju
kontrolirani pristup drugim raunalima i prijenos podataka izmeu raunala, DS
omoguuje izvoenje obrade na vie raunala. Korisnik uporabom DS-a moe pristupati
svim resursima mree kao resursima lokalnog raunala.
DS je skup neovisnih raunala prezentiran korisniku kao jedan koherentan sustav.
Slika 1. prikazuje smjetaj DS-a kao meusloja (middleware) u mrenoj strukturi raunala.

Slika 1. Organizacija distribuiranog sustava

Prednosti upotrebe DS-a u odnosu na mrene sustave su:

1. Ubrzanje obrade obrade se izvodi na vie raunala istovremeno pa je ukupno
vrijeme obrade krae u odnosu na obradu na jednom raunalu.
2. Vea pouzdanost u sluaju nekorektne obrade izvodi se ponavljanje obrade na
raunalu na kome je greka nastala, dok se obrade izvedene na ostalim raunalima
ne ponavljaju; u sluaju izvoenja svih obrade na jednom raunalu nuno je
ponavljanje svih obrada.
3. Ravnomjerno optereenje raunalne mree optereena raunala se rastereuju
prijenosom obrade na raunala sa manjim optereenjem.

4. Smanjeni zahtjevi za hardverom dovoljno je imati nekoliko raunala sa

nadprosjeno kvalitetnih hardverskim osobinama, a zatim se sve hardverski
zahtjevnije obrade preusmjeravaju na ta raunala.
5. Smanjene zahtjeva za softverom skupi softverski proizvodi instaliraju se na
nekoliko raunala, a zatim se sve potrebne obrade preusmjeravaju na jedno od tih
raunala; na taj nain se smanjuje potreban broj licenci i cijena uporabe softvera.

Ciljevi razvoja DS-a:

1. Povezivanje korisnika i resursa.
2. Transparentnost.
3. Otvorenost.
4. Mjerljivost (scalability).

Povezivanje korisnika i resursa omoguuje korisniku pristup resursima svih raunala u

mrei i njihova upotreba kao lokalnih resursa raunala na koje je korisnik spojen.

DS-i koji se mogu korisniku i aplikacijama prikazati u formi jednog sustava su

transparentni. Transparentnost u DS-ima se moe prikazati u obliku:
1. Transparentnosti pristupa (access) prikrivanje razlike u prikazu podataka (razliite
hardverske osnove raunala koriste razliite formate u prikazu podataka) i naina
koritenja resursa.
2. Transparentnost lokacije (location) -

korisnik nije upoznat sa fizikom lokacijom

resursa koji sadri podatke koje korisnik upotrebljava.

3. Transparentnost migracije (migration) promjena fizike lokacije resursa ne utjee
na nain pristupa resursima.
4. Transparentnost relokacije (realocation) ukoliko je omoguena promjena lokacije
resursa u trenutku kada se resurs koristi.
5. Transparentnost replikacije (replication) mogunost postojanja vie kopija
originalnih podataka sa im korisnik ne mora biti upoznat.

6. Transparentnost konkurentnosti (concurrency) mogunost koritenja skupa

podataka za vie korisnika istovremeno pri emu to korisnici ne opaaju.
7. Transparentnost pogreke (failure) korisnici ne opaaju nefunkcionalnost
odreenog resursa kao ni postupak oporavka sustava u sluaju kvara.
8. Transparentnost postojanosti (persistance) korisnik nije upoznat sa trenutnom
lokacijom podataka koji koristi (npr. podaci na kojima se izvodi manipulacija u bazi
podataka kopiraju se u glavnu memoriju, obrauju i rezultat se pohranjuje u bazu
podataka dok korisnik taj postupak vidi kao izravnu operaciju u bazi podataka).

Otvoreni DS omoguuje izvoenje usluga prema prihvaenim standardima. Standardi za

DS-e sadrani su u interfejsu (interface) koji se opisuje sa jezikom za definiranje interfejsa
(Interface Definition Languge IDL). IDL sadri imena funkcija sa popisom parametara,
rezultata izvoenja, moguih iznimki itd. Popis svih funkcija ini specifikaciju. Osobine
dobre specifikacije su kompletnost i neutralnost. Kompletnost znai da je sve to je nuno
potrebno za implementaciju ve ukljueno u specifikaciju. Neutralnost znai da
specifikacija ne propisuje nain implementacije funkcija.

Scalability je svojstvo koje se primjenjuje na tri naina:

1. Prema veliini mogunost dodavanja novih korisnika i resursa.
2. Prema lokaciji odvojenost korisnika i resursa podataka.
3. Prema administriranju mjera jednostavnosti upravljanja sustavom iako se sustav
sastoji od mnogo neovisnih administrativnih organizacija.
Ukoliko elimo poveati kvalitetu sustava nailazimo na niz ogranienja. Pri porastu broja
korisnika ogranienja se mogu prikazati tabelom 1.
Tabela 1. Ogranienja poveanju broja korisnika
Koncept

Primjer

Centralizirani server

Jedan server za sve korisnike

Centralizirani podaci

Jedan on-line telefonski imenik

Centralizirani algoritmi

Izvoenje routinga zasnovanog na kompletnim informacijama

Primjena centraliziranog servera za sve korisnike uvjetuje veliki stupanj optereenja

servera, ali u nekim situacijama nije opravdana upotreba vie servera iste namjene (jedan
od razloga je sigurnost).
Pristup centralizirani podacima je problematian ako je u pitanju velika koliina podataka
jer dolazi do velikog optereenja servera na kome su podaci pohranjeni. Ukoliko se koristi
vie raunala mora se osigurati jednakost podataka na svim serverima.
Primjena centraliziranih algoritama nije dobro rjeenje jer se komunikacija izvodi slanjem i
primanjem velikog broja poruka pa je poeljno koristiti razliite mrene linije u cilju
ubrzanja izvoenja algoritma. Za to je potrebno imati informacije o raspoloivim
putanjama i odabrati najpovoljniju putanju za prijenos poruka.
Tehnike za realizaciju scalability-a su:
1. Asinhrona komunikacija nakon slanja poruke aplikacija pokree druge aktivnosti,
odnosno ne eka na primitak odgovora od servera, a kada odgovor stigne on se
prekidom dojavljuje aplikaciji te poseban proces (handler) izvodi obradu pristiglog
odgovora. U nekim sluajevima je bolje veinu obrade izvesti na klijent strani kako
bi se rasteretio server (Slika 2. prikazuje moguu primjenu obrade podataka formu
za unos podataka na klijent strani (b))
2. Distribucija - znai slanje odreene komponente podijeljene na manje dijelove i
njihova distribucija putem mree kako bi se na odreditu svi dijelovi ponovo spojili
u cjelinu. Primjer je rad DNS servera (slika 3.) gdje se primjenom zona izvodi usluga
dodjele imena (naming service) primjenom vie decentraliziranih servera.
3. Caching to je specijalna forma kopije (replike) podataka, a njena upotreba
definirana je potrebama klijenta i servera koji ima originalnu verziju podataka.

Slika 2. Primjer obrade na klijent strani

Slika 3. Primjena zona za rad DNS servera.

1.1. Hardware
DS-i mogu se koristiti za razliite vrste raunala spojenih u raunalnu mreu. Razliitosti
raunala uvjetuju razinu sloenosti DS-a. Razlikujemo:
1. Multiprocesorske raunalne sustave
2. Multiraunale raunalne sustave.

Multiprocesorski sustavi imaju jedan memorijski adresni prostor koji koristi vie procesora,
dok za multiraunalni sustavi svaki procesor koristi svoj zasebni adresni prostor (slika 4.).
Arhitektura sustava moe se zasnivati na sabirnicama (bus) i na prekidaima (switch).
Multiraunalni sustavi mogu bit homogeni i heterogeni. Homogeni sustavi imaju skup
raunala istih karakteristika jer koriste iste procesore (struktura procesora je identina) i
imaju jednu mrenu tehnologiju. Heterogeni sustavi sastoje se od velikog broja razliitih
raunala koja su spojena na razliite mree.

Multiprocesori

Svi procesori koriste jedan adresni prostor. Ukoliko se promjena vrijednosti memorijske
lokacije od jednog procesora moe u 1 mikrosekundi prikazati na drugom procesoru
kaemo da imamo koherentan sustav. Primjena ovog sustava dovodi do optereenja
sabirnica i smanjenja performansi sustava. Zato se koristi cache memorija. Svaki proces
ima malu brzu cache memoriju za pohranu vrijednosti koje trenutno obrauje (slika 5.).
Cache memorijom se rastereuje sabirnica, ali se pojavljuje problem auriranja vrijednosti
cache memorije ukoliko dva procesora obrauju vrijednost na istoj memorijskoj lokaciji.

Slika 4. Razlika multiprocesorskih i multiraunalnih sustava

Slika 5. Primjena cache memorije

Primjena velikog broja procesora uvjetovat e podjelu memorije u module kako bi se
poboljala svojstva sustava. Pri radu sa memorijom svaki procesor moe pristupati
memorijskim modulima koritenjem prekidaa. Prekidai mogu biti crossbar i omega.
Crossbar prekidai omoguuju izravno spajanje svakog procesora sa svakim memorijskim
modulom, pruaju veliku brzinu spajanja ali uvjetuju velik broj prekidaa. Manji broj
prekidaa postie se upotrebom omega prekidaa gdje se upotrebom odabira putanja
pristupa memorijskim modulima (slika 6.).

Slika 6. Upotreba crossbar i omega prekidaa

Homogeni multiraunalni sustavi

Kako sva raunala imaju istu strukturu jednostavnija je njihova upotreba u DS-u. Ostaje
jedino problem naina povezivanja i komunikacije raunala. Pri povezivanju raunala
mogua je upotreba strukture reetke (grid) ili hiperkocke (hypercube) to prezentira slika
7.

Slika 7. Struktura a) reetke b) hiperkocke

Hetrogeni raunalni sustavi

Sastoje se od veeg broja razliitih raunala spojenih na mreu putem razliitih mrenih
struktura. Primjenom DS-a generira se sloj (middleware) neovisan o hardveru raunala
koje je spojeno na mreu i komunikacija se izvodi primjenom tog sloja. Na taj nain se
izbjegavaju problemi koji nastaju zbog razliitosti raunala.

1.2. SOFTVER
Pri analizi softvera razlikujemo mrena raunala koja koriste OS koji ima kontrolu nad svim
resursima mree (tightly-coupled system) i OS koji kontroliraju resurse lokalnog raunala
(loosely-coupled system). Za prva grupa sustava koristi se DS, a za drugu mreni operativni
sustavi. Tabela 2 prikazuje razlike izmeu OS-a.
Tabela 2. Razlika izmeu OS-a
Sistem
DOS
NOS
Middleware

Opis
Tightly-couped sustavi; primjena za
vieprocesorske i homogene sustave
Loosely-couped sistemi; primjena za
heterogene sustave
dodani sloj na NOS za implementaciju
usluga ope namjene

Ciljevi
prikrivaju nain uporabe
resursa
pruaju lokalne usluge za
udaljene klijente
osigurava transparentnost

10

DISTRIBUIRANI SUSTAVI DS

Razlikujemo multiprocesorske DS i multiraunalne DS. Analiza primjene mikrokernela u

dizajnu OS jednog rauna zasnovanog na klijent-server strukturi (slika 8.) omoguiti e
bolju razumljivost rada DS-a.

Slika 8. Primjena mikrokernela

Multiprocesorski DS omoguuju poveanje performansi sustava upotrebom vie CPU-a.
Aplikacije koje pokreemo ne uoavaju upotrebu vie CPU pri njihovom izvoenju.
Komunikacija u vieprocesorskom sustavu ostvaruje se manipulacijom podataka izmeu
dijeljenih memorijskih lokacija za vie procesora, a jedini uvjet koji mora biti zadovoljen je
onemoguavanje istovremenog pristupa jednoj memorijskoj lokacija dva ili vie CPU
istovremeno. To je omogueno primjenom semafora, monitora i uvjetnih varijabli (vidi
Operacijski sustavi, skripta).

Multiraunalni DS omoguuju rad potpuno razliitih raunalnih sustava, pa je i njihova

kompleksnost znatno vea u odnosu na multiprocesorske DS-e. DS za multiraunalne
sustave se zasniva na slanju poruka (slika 9.).

11

Slika 9. Opa struktura multiraunalnih operativnih sustava

Za prijenos poruka bitna je usklaenost poiljaoca i primatelja pri slanju poruka, a pri tome
je korisna upotreba buffera.

Distribuirani sustavi sa dijeljenom memorijom zasnivaju svoj rad na dijeljenju globalnog

memorijskog prostora raunalne mree. Adresni prostor je podijeljen na stranice (veliine
4 KB ili 8 KB). Princip je da svako raunalo koristi stranice u svojoj memoriji, a kada je
potrebno izvoditi stranicu koja nije u lokalnoj memoriji generira se zahtjev za uitavanjem
traene stranice. Princip je slian klasinom stranienju ali se za virtualnu memoriju ne
koristi vanjska memorija nego RAM memorija drugih raunala u mrei. Slika 10. prikazuje
princip rada dijeljene memorije. Pri radu sa dijeljenjem memorije javljaju se problemi
uzrokovani obradom podataka unutar jedne stranice koja se izvodi na razliitim
procesorima. U tom sluaju promjena varijable u jednoj stranici nije vidljiva u drugoj
stranici i moe doi do greke (false sharing) to prikazuje slika 11. Istovremene promjene
neovisnih varijabli rezultirati e gubitkom promjena za jedan od procesa.

12

Slika 10. Dijeljenje memorije a) poetno stanje b) CPU 1 referencira stranicu 10

c) stanje nakon uporabe replike stranice 10

Slika 11. Primjer greke pri obadi varijabli u stranici

koja se izvodi na dva procesora.
Mreni operacijski sustavi se prilagoavaju operativnom sustavu svakog raunala i ne
stvaraju sliku jedinstvenog sustava kao kod DS-a. Mreni operativni sustavi svako raunalo
vide posebno i pruaju mrene servise operativnom sustavu na svakom mrenom
raunalu. Slika 12 prikazuje ulogu mrenih operativnih sustava u radu distribuiranih
aplikacija.
13

Slika 12. Opa struktura mrenih operativnih sustava

Komunikacija u mrenim operativnim sustavima usmjerena je na prijenos poruka izmeu
klijent raunala i raunala namijenjenih pruanju usluga drugim raunalima (npr. data
server). Slika 13. prikazuje komunikaciju klijent i server raunala u mrenim operacijskim
sustavima.

Slika 12. Komunikacija klijent-server

Middleware je dodatni sloj softvera koji se pozicionira izmeu distribuiranih aplikacija i

mrenih operativnih sustava. Middleware je namijenjen usklaivanju razliitosti izmeu
mrenih operativnih sustava. Slika 13. Prikazuje opu strukturu middleware sustava.
Middleware se primjenjuje u distribuiranom datotenom sustavu, zatim pri izvedbi poziva
na udaljenom raunalu (Remote Procedure Call RPC) ili za rad distribuiranih objekata.
Usluge middleware-a su:
1. Komunikacijske usluge maskiranje prijenosa podataka niske razine.
2. Imenovanje omoguavanje pristupa i dijeljenje resursa.
3. Postojanost podataka.

14

4. Distribuirane transakcije izvoenje vie zasebnih operacije koje se moraju

kompletno izvesti da bi se zavrila distribuirana transakcija.
5. Sigurnost.

Slika 13. Opa struktura midleware-a

Tabela 3. prikazuje usporedbu multiprocesorski, multiraunalnih, mrenih i middleware

zasnovanih distribuiranih sustava prema stupnju transparentnosti, razliitosti OS za
raunala u mrei, broju kopija OS, komunikacijskoj osnovi, upravljanju resursima,
proirivosti i otvorenosti..

Tabela 3. Usporedba distribuiranih sustava

15

1.3. Klijent-server model

Bolja razumljivost naina izvedbe procesa u distribuiranim sustavima postie se analizom
klijent-server modela. Procesi u distribuiranim sustavima su podijeljeni u dvije grupe:
1. Serveri procesi namijenjeni pruanju posebnih usluga.
2. Klijenti proces koji trai uslugu od servera.
Slika 14 prikazuje opi sluaj interakcije izmeu klijenta i servera. Vidljivo je da klijent eka
na odgovor od servera.

Slika 14. Opi sluaj interakcije izmeu klijenta i servera

Struktura klijent server aplikacija uglavnom ukljuuje tri sloja:

1. Sloj korisnikog suelja program koji omoguuje interakciju sa korisnikom,
postavljanje upita korisnika i prezentiranje rezultata upita korisnika.
2. Sloj obrade podataka sadri logiku obrade podataka i pravila za izvoenje upita
korisnika.
3. Sloj podataka konkretna pohrana i izravna manipulacija podacima.

Slika 15. prikazuje troslojnu strukturu Internet aplikacije za pretraivanje (search engine).
Aplikacija prihvata upit, generira upit za bazu podataka (Query), pristupa bazi podataka,
obrauje rezultat upita iz baze podataka i prosljeuje odgovor korisniku.

16

Slika 15. Prikaz troslojne strukture Internet aplikacije za pretraivanje

Arhitektura klijent-server sustava moe biti:

1. korisniko suelje je na klijent strani, a ostatak aplikacije na server strani.
2. arhitektura sa vie nivoa primjena posebnog sloja izmeu korisnikog suelja i
baze podataka (slika 16. prikazuje mogue situacije); slika 17 prikazuje troslojnu
strukturu pri izvoenju upita klijent raunala.
3. Moderna arhitektura prevladava horizontalna distribucija, klijent i server su na
istoj razini (ne primjenjuje se vertikalna distribucija) ali je svako raunalo
odgovorno za izvoenje operacija unutar svojih domena.

Slika 16. Mogue klijent-server organizacije

17

Slika 17. Prikaz troslojne arhitekture pri izvoenju zahtjeva korisnika

Slika 18. Primjer horizontalne distribucije Web usluga

18

2. KOMUNIKACIJA

Komunikacije su kljuni element DS-a. Osnovna razlika distribuiranih sustava i lokalnog

sustava je komunikacija meu procesima. Zasniva se na primjeni poruka niskog nivoa
(bliskom hardver raunala) koritenjem postojee mrene strukture. Komunikacija dva
raunala izvodi se primjenom strukture slojeva. Svaki sloj izvodi set aktivnosti i ini osnovu
za primjenu vieg sloja. Nii slojevi usmjereni su prema hardveru, a vii prema
aplikacijama. Primjenjujemo sljedee modele komuniciranja:
1. Poziv procedure na udaljenom raunalu (Remote Procedure Call RPC)
2. Poziv metode na udaljenom raunalu (Remote Method Invocation RMI)
3. Meusloj usmjeren prijenosu poruka (Message-Oriented Middleware MOM)
4. Primjena toka (Stream).

2.1. Protokoli slojeva za komunikaciju

Protokoli imaju kljunu vanost u komunikaciji. Razlikujemo sljedee modele:

Modele zasnovane na slojevima (layers):

o OSI model
o ATM

Klijent-server model.

OSI model
Pri komunikaciji dva raunala koristi se vie slojeva za prijenos podataka. Slojevi se mogu
razliito definirati u skladu sa njihovim funkcionalnostima. Ope prihvaeni prijedlog
strukture slojeva predloen je od International Standard Organization (ISO) pa je i
predloeni

model strukture slojeva nazvan OSI model. OSI model omoguuje

komunikaciju otvorenih sustava (sustavi koji koriste propisane standarde pravila,

formate, sadraj i znaenje poruka koje se alju i primaju). Pravila za otvorene sustave su

19

formalizirana u protokolima. Protokoli mogu biti connection-oriented (potrebna je

uspostava veze prije slanja i primanja podataka) i connectionless (veza ne mora biti
uspostavljena da bi se poruke mogle slati i primati upotreba mailbox-a). Slika 19.
prikazuje slojeve u OSI modelu. Koristi se 7 slojeva. Kada proces jednog raunala alje
poruku drugom raunalu aplikacijski sloj generira poruku i prosljeuje prezentacijskom
sloju koji poruku prosljeuje niem nivou. Pri tom svaki sloj dodaje header na poetak
poruke. Izgled poruke prije prijenosa mreom prikazuje slika 20. Primljena poruka se
pomou headera poruka moe prenijeti do procesa kojem je namijenjena.

Slika 19. Slojevi OSI-modela

Slika 20. Primjer poruke sa header-ima

Protokole potrebne za rad OSI modela dijelimo na:
1. protokole niskog nivoa (low-level)
a. fiziki sloj (physical layer) sloja za prijenos 0 i 1 putem fizike veze

20

b. Sloj prijenosa podataka (data link layer) grupiranje bitova u vee cjeline ili
pakete frame i provjera ispravnosti prijenosa frame-ova primjenom
postupka za provjeru (checksum); slika 21 prikazuje provjeru podataka.
c. Mreni sloj (network layer) odabir putanje za slanje paketa mreom;
najee koriteni protokol je IP (Internet Protokol); pri brim vezama
(ATM) koriste se virtualni kanali koji povezuju vie komunikacijskih vorova
u jednu cjelinu
2. Transportne protokole funkcija protokola je dijeljenje poruke za prijenos na
manje dijelove, dodjela brojeva dijelovima i njihovo slanje; najee koriten
protokol je TCP (Transmission Control Protokol), zatim UDP (Universal Datagram
Protokol, to je proirenje IP protokola), za real-time prijenos se koristi RTP (Realtime Transport Protocol). Primjena transportnih protokola esta je u klijent-server
interakciji u distribuiranim sustavima primjenom TSP i UDP protokola, pri tome
komunikacija moe biti standardna (normal) ili transakcijska (slika 22.)
3. protokole visoke razine (high-level)
a. protokol sesije nadogradnja transportnog sloja sa funkcijama izvoenja
dijaloga sa niim slojem i sinhronizacije uz mogunost definiranja kontrolnih
toaka za nastavak komunikacije u sluaju neuspjelog prijenosa poruke
b. prezentacijski protokol orijentiran je sadraju poruka pa omoguuje
povezivanje podataka poruke sa formatom prijenosa poruke (poruke mogu
sadravati imena, adrese, novane iznose i sl. pa je prikladno odrediti
strukturu poruke kako bi se jednostavnije manipuliralo porukama).
c. Aplikacijski protokoli orijentiran radu sa aplikacijama sa karakteristikama
protokola ope namjene. Primjeri su FTP (File Transport Protocol), HTTP
(HyperText Transfer Protocol).
d. Middleware protokoli protokoli sadrani u aplikacijskom sloju sa
izvoenje posebnih usluga (protokoli za provjeru autentinosti, protokoli za
implementaciju atominosti izvoenje vie procesa kao jedna nedjeljiva
cjelina)

21

Slika 21. Postupak provjere prijenosa poruka

Slika 22. a) standardni TSP b) Transakcijski TCP

2.2. Poziv procedure na udaljenom raunalu RPC

Poziv procedure na udaljenom raunalu omoguuje prijenos obrade na drugo raunalo

pokretanjem odgovarajue procedure. Za vrijeme izvoenje procedure na drugom
22

raunalu proces koji je inicirao poziv je suspendiran i eka rezultat izvoenja procedure
(slika 23). Kada pozvana procedura vrati rezultat rada procedure proces na lokalnom
raunalu nastavlja izvoenje, pri emu je cijeli postupak nevidljiv za programera.

Slika 23. Prikaz RPC poziva izmeu klijenta i servera

Primjenom RPC poziva nastoji se pozvana procedura na udaljenom raunalu izvesti na

nain kao da lokalni proces izvodi proceduru na lokalnom raunalu. To se ostvaruje
upotrebom posebnog tipa zapisa procedura (client stub) u stack dio memorije procesa.
Kada udaljeno raunalo primi poruku sa pozivom procedure prosljeuje je posebnom
zapisu (server stub) u stack memoriji. Kada se procedura izvede slijedi prijenos rezultata
klijentu i nastavak izvoenja procesa na klijent raunalu. Koraci za izvoenje RPC poziva su
(slika 24.):
1. klijent proces poziva proceduru i generira klijent stub,
2. klijent stub generira poruku i prosljeuje je lokalnom OS,
3. klijent OS alje poruku udaljenom raunalu (serveru),
4. server OS prima poruku i prosljeuje je server stubu,
5. server stub raspakira analizira parametre poruke i generira sistemski poziv na
serveru,
6. server izvodi poziv i vraa rezultat server stubu,
7. server stub pakira poruku i prosljeuje je server OS,
8. server OS alje poruku klijent raunalu,
9. klijent OS poruku prosljeuje klijent stubu,
10. klijent stub raspakira poruku i prosljeuje rezultat klijent procesu.

23

Slika 24. Izvoenje RPC poziva

Pri tome je nuno uskladiti formate za prijenos podataka ukoliko klijent i server koriste
drugaiji zapis podataka (npr. Pentium i SPARC arhitektura). Slika 25. prikazuje postupak
prevoenja poruka u drugaiji format (koritenje drugaijih kodova za karaktere, formate
brojeva itd.). Pri generiranju poruke prema serveru nuno je poznavanje servisa koji se eli
koristiti (razliiti servisi imaju razliite portove). Klijent potreban port moe dobiti
statikim nainom kada server svim klijent raunalima poalje oznake portova (to je
nepraktino u sluaju promjene oznaka portova jer se podaci o promjeni portova moraju
slati svim raunalima). Drugi nain je dinamiki: klijent alje serveru upit za oznakom porta
za traenu uslugu, a zatim dobivenu informaciju ugrauje u poruku prema serveru.

Slika 25. Prevoenje formata podataka a) Intel b) SPARC c) invertirana poruka

24

Proirenje RPC modela

Ukoliko je potrebno koristiti poziv RPC poziva na jednom raunalu koristi se posebna vrsta
procedure ekvivalentna RPC pozivu a zove se door. Door procedura mora biti podrana u
OS raunala. Postupak izvoenja je identian RPC pozivu osim komunikacije putem mree
jer se poziv izvodi na istom raunalu. Slika 26. prikazuje izvedbu door procedure.

Asinhroni RPC poziv omoguuje klijent procesu nastavak izvoenja aktivnosti koje se ne
odnose na rezultat RPC poziva, pa klijent ne mora biti suspendiran za vrijeme izvoenja
RPC poziva (slika 27.). Slika 28. prikazuje izvoenje dva RPC poziva (deffered synhronous
RPC)

Slika 26. Izvoenje door procedure

25

Slika 27. a) standardni RPC b) asinhroni RPC

Slika 28. Klijent i server izvode dva asinhrona RPC poziva

2.3. Poziv metode na udaljenom raunalu RMI

Rad se zasniva na primjeni distribuiranih objekata opisanih podacima koje sadre (state) i
operacijama na podacima (method). Metode su DStupne primjenom suelje (interface).
Distribuirani sustavi dozvoljavaju smjetaj interface-a na jedno raunalo i objekta na drugo
raunalo (slika 29.).

26

Slika 29. Primjer organizacije objekta na udaljenom raunalu

Klijent poziva udaljenog objekta putem interface-a (proxy), koji zahtjev prosljeuje na
server gdje se primjenom interface-a (skeleton) prosljeuje objektu. Nakon to klijent
pristupi objektu on pokree izvoenje metode na objektu. Koriteni interface-i mogu biti
definirani u trenutku izrade aplikacije na klijentu pa se takav nain upotrebe interface-a
zove static invocation. Ukoliko interface nije unaprijed poznat koristi se dinamic
invocation. U tom sluaju aplikacija odabire eljenu metodu te se dinamiki odreuje
potreban interface za selektiranu metodu.

2.4. Meusloj usmjeren prijenosu poruka

Porukama se izbjegava ogranienje blokiranja klijent procesa pri RPC ili RMI pozivu na
serveru. Primjer primjene poruka je slanje elektronike pote (slika 30.). Aplikacija
generira poruku koja se prosljeuje putem lokalne mree prema komunikacijskom serveru
(mail serveru). Komunikacijski server prosljeuje poruku drugom komunikacijskom
serveru koji prihvaa poruku i prosljeuje aplikaciji korisnika u trenutku kada se korisnik
prikljui na komunikacijski server.

27

Slika 30. Princip rada elektronike pote primjenom prijenosa poruka.

Elektronika pota je primjer kontinuirane komunikacije (persistant communication) gdje

se poruka pohranjuje na serveru sve dok se ne steknu uvjeti za njen daljnji prijenos na
drugi server. Slika 31 prikazuje persistant communication na primjeru Pony Express slube.

Slika 31. Primjer kontinuirane komunikacije

Nasuprot persistant communication je transient communication gdje se poruka zadrava
samo za vrijeme izvoenje aplikacija za slanje i primanje poruka. Komunikacija porukama
moe biti sinhrona i asinhrona. Kod asinhrone komunikacije poiljalac nastavlja izvoenje
nakon slanja poruke, a kod sinhrone poiljalac je blokiran sve dok poruka nije spremljena u
bufffer primalaca ili je primalac nije primio. Slika 32. prikazuje 6 naina komunikacije.

28

Slika 32. Naini komunikacije: a) kontinuirana asinhrona b) kontinuirna sinhrona

c) transient asinhrona d) receipt-based transient sinhrona e) delivery-based transient
sinhrona f) response-based transient sinhrona

2.5. Primjena toka (stream)

Tok (stream) se koristi u radu sa multimedijalnim dokumentima gdje je vrlo vana
usklaenost izmeu sadraja i naina interpretacije sadraja. Razlikujemo kontinuirane i
diskretne medije. Za prikaz kontinuiranih medija vana je brzina prijenosa podataka dok za
29

diskretne medije brzina nema kljunu vanost. Za implementaciju kontinuiranih medija u

distribuiranim sustavima koristi se tok podataka (data stream). Za asinhroni transmisijski
nain prenoenja podaci se prenose jedan za drugim i koriste kada je prijenos zavren
(prijenos fotografija). Za sinkroni transmisijski nain prenoenja podaci se prenose jedan
za drugim i moraju se prenijeti prije odreenog intervala vremena. Za isohrone
transmisijske naine prenoenja podaci se prenose jedan za drugim ali imaju tono
odreen vremenski interval prijenosa te se ne smije podataka prenijeti poslije, ali ni prije
dozvoljenog intervala vremena. Tok moe biti:
1. jednostavan jedan niz podataka
2. sloen nekoliko nizova podataka (kombinacija slike i zvuka).
Tok moe biti izveden koritenjem dva procesa, a moe biti realiziran i direktno (slika 33.).

Slika 33. Primjena toka a) pomou dva procesa b) direktno

Kvaliteta toka definira se specifikacijama za prijenos podataka sa podacima o brzini

prijenosa, odgodama pri prijenosu itd. Primjer poboljanja kvalitete toka je Token bucket
algoritam (slika 34.). Aplikacija generira podatke za tok u nepravilnim vremenskim
intervalima, a filtar koritenjem brojaa vremena T alje podatke u tonim vremenskim
intervalima.

30

Slika 34. Primjena token bucket algoritma

Postavljanje toka podataka izvodi se primjenom Reosurse reSerVation Protocol-a (RSVP)
kao kontrolnog protokola smjetenog u

transportni sloj. RSVP sadri sve podatke

potrebne za realizaciju toka podataka i preuzima kontrolu nad tokom podataka (slika 35.).

Slika 35. Primjena RSVP-a u kontroli toka podataka

Za toka podataka bitna je sinhronizacija, pa je nuno koristiti sinhronizacijski mehanizam.

Zadatak mehanizma je prihvat dolaznog toka podataka i vremensko usklaivanje toka
podataka koji se prosljeuje prema konkretnom primatelju.

31

Kontrolni mehanizam moe biti:

1. jednostavan kontrola prihvata podataka i sihronizacija pri prosljeivanju
podataka primatelju (slika 36.)
2. sloena koristi se poseban program (aplikacija) namjena kontroli toka podataka
(slika 37).

Slika 36. Primjer jednostavnog mehanizma za sinhronizaciju

Slika 37. Primjer sloenog mehanizma za sinhronizaciju

32

3. SINHRONIZACIJA U DISTRIBUIRANIM OPERACIJSKIM

SUSTAVIMA

Sinhronizacija je kljuna za rad DS-a. Raunalna mrea ukljuuje niz raunala sa vremenski
usklaenim satovima. Uskladivost vremena na svim raunalima ne moe se potpuno
postii to stvara probleme pri izvoenju operacija (procesa) na razliitim raunalima koji
se moraju izvesti tono odreenim reDSlijedom. Primjer na slici 46. prezentira situaciju pri
kopajliranju datoteke. Na jednom raunalu editiramo datoteku, a na drugom je
kompajliramo. Kompajler prije kompajliranja provjerava vrijeme zadnje promjene
datoteke i ako je to vrijeme manje od zadnjeg procesa kompajliranja ne izvodi postupak
kompajliranja. Zadnje vrijeme kompajliranja je 2144 na prvom raunalu. Poslije tog
trenutka na drugom raunalu se promijeni datoteka i zapamti vrijeme 2143 (sat na
drugom raunalu zaostaje za satom na prvom raunalu). Kompajler pri usporeivanju
utvruje da je promjena datoteke izvedena prije zadnjeg kompajliranja (2134 promjena,
2144 zadnje kopajliranje) i nee kompajlirati datoteku. Jasno je da se ovakve situacije
moraju izbjei.

Slika 46. Greka pri kompajliranju datoteke

3.1. Sinkronizacija sata

Sinkronizacija sata moe se postii:
1. primjenom fizikog sata koristi se univerzalni sat prema kojem se usklauju svi
ostali satovi

33

2. algoritma za sinhronizaciju za raunala koja imaju pristup WWW-u mogue je

usklaivanje sa referentnim satom stalnim praenjem odstupanja lokalnog sata;
kada odstupanje pree dozvoljenu granicu izvodi se korekcija lokalnog sata (slika
47.); druga mogunost je upotreba time servera za usklaivanje lokalnih satova
(slika 48.); ukoliko raunala nemaju pristup WWW-u potrebno je primijeniti
Berkeley algoritam gdje se izraunava srednje vrijeme svih raunala u lokalnoj
mrei i putem time deamon procesa usklauju svi lokalni satovi sa srednjim
izraunatim vremenom (slika 49.)

Slika 47. Usklaivanje sa referentnim satom

Slika 48. Usklaivanje time serverom

slika 49. Berkeley algoritam

34

Za pojedine procese vrlo je bitno odreivanje slijeda aktivnosti izvoenje to je izvodivo

ukoliko su satovi meusobno usklaeni. Za procese kod kojih je nuno da se jedan proces
dogodio prije drugog definira se relacija happend before. Dva procesa su u relaciji happend
before ako je:
1. a dogodio prije b: C(a) < C(b)
2. a i b oznaavaju slanje i primanje poruke: C(a) < C(b)
3. za sve a i b ako je C(a) C(b).
Slika 50. prikazuje usklaivanje vremenskih satova kako bi se mogla implementirati relacija
happend before.

Slika 50. a) prikaz lokalnih satova b) prikaz usklaenih satova

Pri usklaivanju replika servera mogu se javiti sljedei problemi. Korisnik u Splitu ulae 100
kuna na raun koji trenutno na centralnom serveru u Zagrebu i kopiji servera u Splitu
iznosi 1000 kn. Istovremeno uposlenik banke u Zagrebu pokree obraun kamata na iznos
korisnika. Kako e oba zahtjeva biti proslijeena na oba servera doi e do izrauna
trenutnog iznosa od 1110 kn u Zagrebu i 1111 u Splitu (slika 51.). Ova situacija izbjegava se
blokiranjem promjena na podacima ija je izmjena u tijeku sve dok se ne dobije potvrda o
zavrenim izmjenama na svim serverima replikama.

35

Slika 51. Primjer greke pri radu sa replikama podataka.

3.2. Algoritmi za odabir

U DS-u je esto potrebno selektirati proces koordinator to se realizira upotrebom
algoritma za odabir. Algoritmi za odabir su:
1. Bully algoritam
2. Ring algoritam.

Bully algoritam radi na sljedeem principu: procesima se dodjeljuju brojevi ovisno o

vremenu nastanka (najstariji proces ima najvei broj); pri odabiru proces P alje poruku
ELECTION svim drugim procesima sa upitom za vrijednost dodijeljenog broja; ako niti
jedna poruka nema vei broj od broja koji ima P proces P je izabran; ako se pojavi poruka
sa veim brojem proces koji je poslao poruku je izabran (slika 52).

Ring algoritam koristi krug za odabir procesa. Kada koordinator nije aktivan pokree se
ELECTION poruka koja sadri broj procesa. Ako susjedni proces nije aktivan poruka se
prosljeuje sljedeem procesu u krugu. Pri svakom primitku poruke proces poveava svoj
broj pa e tako proces sa najveim brojem biti izabran. Kada poruka stigne ponovo do
procesa koji ima najvei broj on se proglaava koordinatorom i alje ostalima poruku o
tome i procesima ukljuenim u krug (slika 53.)

36

Slika 52. Bully algoritam a) proces 4 zapoinje odabir b) proces 5 i 6 odgovaraju

c) proces 5 i 6 zapoinju odabir d) proces 5 i 6 zaustavljaju odabir
e) proces 6 je odabran i informira ostale

Slika 53. Ring algoritam

37

3.3. Mutual Excluison

U DS-u je nuno implementirati mutual excluison kako bi se izbjegle greke u radu sa

djeljivim resursima . Implementacija mora ukljuiti sve resurse svih raunala ukljuenih u
DS. Implementacija mutual exclusiona ostvaruje se:
1. Centraliziranim pristupom
2. Decentraliziranim pristupom
3. Koritenjem token-a.

Centraliziran pristup znai upotrebu koordinatora sa pravima dodjele dozvole ulaska u

kritinu sekciju na djeljivom resursu. Svi procesi koordinatoru alju zahtjeve (request) za
ulaskom u kritinu sekciju. Ako je resurs slobodan koordinator dozvoljava slanje poruke
potvrde ulaska (reply) u kritinu sekciju i proces zapoinje kritinu sekciju. Ukoliko neki
drugi proces zatrai ulazak u kritinu sekciju na istom djeljivom resursu koordinator mu
nee vratiti poruku potvrde za ulazak u kritinu sekciju sve dok prvi proces ne zavri
kritinu sekciju i vrati poruku zavretka kritine sekcije koordinatoru (release). Slika 54.
prikazuje centraliziranu izvedbu mutual exclusiona. Problem nastaje kad koordinator nije
u funkcionalnom stanju, ali u tom sluaju njegovu funkciju preuzima rezervni koordinator.

Slika 54. Centralizirani pristup a) slanje upita i dozvola ulaska u kritinu sekciju
b) upit odbijen c) upit prihvaen

Decentralizirani pristup znai da nema koordinatora ve procesi meusobno dogovaraju

dozvole ulaska u kritine sekcije. Ako jedan proces eli ui u kritinu sekciju alje svim

38

ostalim procesima poruku koja sadri naziv kritine sekcije, broj procesa i trenutno
vrijeme. Ako svi procesi vrate poruku potvrde (OK) proces ulazi u kritinu sekciju. Ako bi
neki drugi proces poslao nakon toga zahtjev za ulaskom u kritinu sekciju dobio bi odgovor
od svih procesa osim od procesa koji je u kritinoj sekciji. Odgovor od procesa koji je u
kritinoj sekciji uslijediti e kada proces zavri kritinu sekciju. Problem se moe pojaviti
ako dva procesa istovremeno poalju zahtjev za ulaskom u kritinu sekciju, a rjeava se
usporeivanjem vremenskih oznaka dogaaja slanja poruke za ulazak u kritinu sekciju
(time stamps) pa se na taj nain odreuje koji proces prvi ulazi u kritinu sekciju. Problem
nastaje ako jedan proces nije funkcionalan jer tada niti jedan drugi proces ne moe dobiti
poruku potvrde za ulazak u kritinu sekciju pa je nuno detektirati takve procese i iskljuiti
iz komunikacije pri dodjeli dozvola za ulazak u kritinu sekciju. Slika 55. prikazuje rad
centraliziranog pristupa pri izvedbi mutual exclusion-a.

Slika 55. Centralizirani pristup a) slanje zahtjeva b) dobivanje odgovora

c) ulazak u kritinu sekciju

Primjena token-a znai upotreba poruke token za svaki djeljivi resurs koja putuje sustavom
od procesa do procesa. Proces koji eli ui u kritinu sekciju zadrati e token kod sebe sve
dok ne zavri kritinu sekciju i tako osigurati izvoenje mutual exclusion-a. Problem
nastaje ako se poruka token izgubi pa je potrebno provjeravati da li je poruka u sustavu i
ako nije nuno je generirati novu poruku. Slika 56. prikazuje primjenu token-a na
neorganiziranu grupu procesa koja se softverski povezuje u krunu strukturu. Tablica 4.

39

prikazuje usporedbu naina za implementaciju mutaul ecxlusiona. Tablica sadri podatke o

broju potrebnih poruka, ekanju na ulazak u kritinu sekciju izraenom putem broja
poruka za primanje i problemima svake tehnike.

Slika 56. Primjena token-a a) neorganizirana struktura

b) logiki krug konstruiran u softveru

Tabela 4. usporedba tehnika za mutual exclusion

3.4. Atominost
Atominost se odnosi na transakcije odnosno skup akcija koje se moraju izvesti kompletno
kako bi se transakcija mogla zakljuiti. Ukoliko barem jedna akcija nije kompletirana,
cijela transakcija se ponitava i vra na poetak.
Osnovne operacije za izvonenje atominih akcija:

BEGIN_TRANSACTION

END_TRANSACTION

40

ABORT_TRANSACTION

READ_TRANSACTION

WRITE_TRANSACTION

Slika 57. prikazuje izvonenje transkacije pri rezrevaciji karata na relaciji Washington- New
York Nairobi Malindi.

Slika 57. Prikaz transakcija za rezervaciju karata

Svojstva transakcija - ACID:
1. Atominost akcije se izvode kao cjelina
2. Konzistentnost ukupno stanje vrijednosti varijabli sustava prije i poslije transakcije je
konzistentno (nepromijenjeno)
3. Izoliranost akcije se mogu izvoditi paralelno ali to ne utjee na rezultat izvoenje
4. Trajnost jednom zavrena transkacija ima trajan uinak na rezultate transakcije (nije
mogue povratak promijenjenih vrijednosti u transakciji)

Slika 58. Primjer transakcija i upravljanja transakcijama

Upravljanje transakcijama mora biti izvedeno na nain koji osigurava korektnu obradu na
podacima. Slika 58.a) i 58.b) daju korektan rezultat dok 58.c)generira greku.

41

Ugnijenene transakcije su transakcije nieg hijerarhijskog nivoa, a generiraju se stvaranjem

child procesa koji izvode aktivnosti nad podacima parent procesa.
Implementacija transakcija je izvediva primjenom:

Privatni radni prostor blokovi podataka koji se mijenjaju u transakciji se kopiraju u

slobodne blokove i na njima se izvodi obrada; ukoliko se transakcija vrati na poetak,
privremeni blokovi se briu, a za kompletiranu transakciju privremeni blokovi postaju
korektni blokovi dok se prethodni blokovi proglaavaju nevaeim (slika 59.)

Writeahead log ili intention liste liste sadre popis promijenjenih vrijednosti koje se
koriste za obnavljanje poetnih vrijednosti u sluaju ponitenja transkacije (slika 60).

Slika 59. Privatni radni prostor

Slika 60. Primjer uporabe Whiteahead loga

Osnovne operacije za izvoenje atominih akcija:

BEGIN_TRANSACTION
END_TRANSACTION
ABORT_TRANSACTION
READ_TRANSACTION
WRITE_TRANSACTION

Slika 59. Privatni radni prostor

Slika 60. Primjer uporabe Whiteahead loga

42

4. PROCESI

Procesi u DS-u imaju sve znaajke procesa OS jednog raunala uz dodanu mogunost
izvoenja na vie raunala. Pri tome je mogue prenositi podatke sa drugih raunali,
prenositi obradu i prenositi procese na druga raunala. Prijenos podataka ostvaruje se
djelomino ili potpuno. Podaci se prenose kada je potrebno izvesti obradu samo jednog
manjeg segmenta podataka (npr. jedan slog u bazi podataka). Potpun prijenos je opravdan
ako se obrada izvodi na veem dijelu podataka. Ukoliko je datoteka na kojoj je potrebno
izvesti obradu velika racionalnije je prenijeti cjelokupan proces na udaljeno raunalo,
obaviti obradu i vratiti rezultat na lokalno raunalo. Prijenos obrade na drugo raunalo
ostvaruje se RPC pozivom ili generiranjem procesa na udaljenom raunalu koji obavlja
traenu obradu i vraa rezultat procesu na lokalnom raunalu.
Za analizu procesa u DS-u bitni su:
1. Procesne niti (thread)
2. Klijent procesi
3. Server procesi
4. Migracija koda
5. Softverski agenti.

4.1. Procesne niti (thread)

Koncept procesnih niti susreemo u OS jednog raunala (Operacijski sustavi skripta).
Implementacija procesnih niti moe biti izvedena primjenom:
1. korisnikog nivoa (user-level) problem se pojavljuje u trenutku kada jedna
procesna nit prelazi u blokirano stanje to uvjetuje blokiranje procesa i
nemogunost izvoenja ostalih procesnih niti procesa.

43

2. kernel nivoa blokiranje jedne procesne niti nee onemoguiti izvoenje ostalih
procesnih niti procesa, ali e svako pokretanje druge niti traiti pohranu stanja niti
koja je zaustavljena i uitavanje stanja niti koja se pokree.
3. lightweight processes (LWT) izvode se u kernel modu i sadre sve podatke
potrebne za izvoenje procesnih niti pa nije potrebna pohrana stanja i uitavanje
novih stanja za procesne niti; preusmjeravanje izvoenja na druge procesne niti
izvodi se bez znanja kernela to ubrzava izvoenje niti. Ukoliko se LWT vie ne
moe izvoditi zbog blokiranog stanja procesnih niti selektira se drugi LWT.

Procesne niti u DS-ima se koriste za:

1. prijenos podataka koji se moe obaviti paralelno (uitavanje Web stranice)
2. pristup replikama servera (mogunost istovremenog itanja podataka sa vie
lokacija)
3. izbjegavanje nefunkcionalnosti usluga (koriste se replike servera)

Procesne niti se koriste na serverima. Primjer upotrebe je prikazan slikom 38. Procesna nit
prihvaa zahtjev za itanjem podataka sa vanjske memorije, a zatim se paralelno pokree
vie procesnih niti koje paralelno pokreu zahtjeve za itanjem podataka na vanjskoj
memoriji. Procesne niti se blokiraju dok podaci nisu proitani sa vanjske memorije, a zatim
se putem prekida prevode u ready stanje i izvode kako bi zavrile traeni zahtjev.

Slika 66. Primjena procesnih niti na serveru

44

Procesne niti niti posve neovisne jer dijele adresni prostor procesa, otvorene datoteke,
child procese, timere, semafore i dr.
Implementacija procesnih niti moe biti izvedene u korisnikom prostoru ili u kernel
prostoru te kombinirana (dijelom u korisnikom i kernel prostoru).
Implementaciju u korisnikom karakterizira:
Kernel nije upoznat sa postojanjem procesnih niti
Upravljanje nitima izvodi se neovisno o sheduleru kernela
Problem blokiranja procesnih niti uporaba jacket
Problem upravljanje izmeu procesnih niti
Implementaciju u kernel prostoru karakterizira:

Svaki proces ima svoju tabelu s podacima o pokrenutim procsnim nitima

Izbjegnuto blokiranje procesa u sluaju nemogunosti izvoenja jedne procesne niti

Pokretanje i unitavanje procesnih niti traje due

Implementacija dijelom u korisnikom i kernel prostoru objedinjuje dobre osobine

implementacije u kernel i korisnikom prostoru (slika 67.). Takve procesne niti se zovu
Lihtweight procesi (LWP) a karakterizira ih brzo pokretanje i izbjegavanje blokiranje
izvoenja procesa u sluaju blokiranja jedne procesne niti.

Slika 67. Primjena procesnih niti u korisnikom i kernel prostoru

45

4.2. Klijenti
Glavna namjena klijenta je interakcija sa korisnicima i serverima. Slika 68. prezentira
primjer X klijenta koji je odgovoran za kontrolu monitora, te prihvat korisnikih naredbi
putem tipkovnice i mia. Upravljanje monitorom realizira se window managerom koji
upravlja promjenama ekrana (promjena boje prozora, preklapanje prozora itd).
Komunikacija X klijenta sa serverima ostvaruje se primjenom X protokola, pa terminale
zasnovane na ovim postavkama zovemo X terminalima.

Slika 68. Primjena procesnih niti na serveru

Naprednije primjena klijenata omoguuje operacije Drag-and-drop (prijenos datoteke u
Recycle bin rezultira brisanjem datoteke iz trenutnog direktorija) i in-place editiranje
(promjene u dokumentu uvjetuju automatsko auriranje dokumenta, npr. Umetanjem
slike aurira se sadraj dokumenta od mjesta umetanja do kraja dokumenta). Jedna od
primjena klijenata u distribuiranim sustavima je implementacija transparentnosti replika
rjeenjem na klijentu (slika 70.). Klijent Proxy prikuplja odgvoro na upit od svih replika i
klijentu prosljeuje konani odgovor.

Slika 70. Primjena procesnih niti na serveru

46

4.3. Serveri
Server je proces koji implementira odreenu uslugu za potrebe klijenta. Server procesi
mogu biti organizirani kao:
1. Iterativni (Iterative) server samostalno izvodi zahtjev i prosljeuje odgovor
klijentu (ovisno o prirodi zahtjeva)
2. Konkurentni (concurrent) ne izvodi zahtjev samostalno ve prosljeuje zahtjev
drugim procesima i eka na odgovor procesa.
Klijenti komuniciraju sa serverima putem krajnjih toak (endpoint) ili portova. Procesi prije
komunikacije sa serverom moraju poznavati port na kojem server prua traena usluga.
Dobivanje informacije o portu je mogue slanjem upita DCE demonu ili slanjem upita
superserveru. DCE demon vraa klijentu oznaku porta, dok superserver prosljeuje zahtjev
izravno server procesu (slika 71.).

Slika 71. a) primjena DCE demona b) primjena superservera

Serveri nisu obvezni uvati informacije o klijentima (stateless server) npr. Web server.
Serveri u nekim sluajevima uvaju podatke o klijentima statefull serveri (primjer je
auriranje lokalnih kopija datoteka).

47

Implementacija rada objekta postie se objekt serverima koji prihvaaju zahtjev za rad sa
odreenim objektima i prosljeuju taj zahtjev do traenog objekta. Kontrola koritenja
objekata ostvaruje se upotrebom adaptera objekata (object adapter ili object wrapper)
prikazanog na slici 71.

Slika 70. Primjena adaptera objekata

4.4. Migracija koda

Migracija koda povezana je sa migracijom procesa. Primjer migracije koda prikazuje slika
72. Klijent preuzima potreban kod iz skladita koda (repository code) i izvodi obradu.
Klijent je dinamiki konfiguriran pa nije potrebno da klijent ima preinstaliran softver za
izvoenje odreene obrade ve samo protokole za preuzimanje koda sa skladita.

Slika 71. Primjena adaptera objekata

48

Modeli za migraciju koda mogu biti:

1. Model slabe mobilnosti (weak mobility) prenosi se samo kod i eventualno
inicijalni podaci. Program se uvijek pokree iz poetka. Prednost je jednostavna
implementacija.
2. Model snane mobilnosti (strong mobility) prenosi se process u cijelosti (segment
koda, segment resursa i izvrni segment) to omoguuje zaustavljanje izvoenja
procesa, prijenos procesa na drugo raunalo i nastavak izvoenja.
Migracija koda moe biti inicirana:
1. Putem raunala na kojem se trenutno nalazi kod sender initiated (prijenos
datoteka na server)
2. Putem raunala na kojem se treba izvoditi kod receiver-initated (primjer su Java
apleti)

Mogue kombinacije navedenih pristupa u implementaciji koda prikazuje slika 72.

Slika 72. Primjena adaptera objekata

49

4.5. Softverski agenti

Softverski agenti su autonomni procesi sposobni da reagiraju sa okruenjem i iniciraju
promjene u svom okruenju i po mogunosti surauju sa drugim agentima.

Agente dijelimo na:

1. Kolaborativne (collaborative) postizanje cilja putem suradnje (organiziranje
sastanka)
2. Mobilni (mobile) ima
3. Interfejs (interface) pomo krajnjim korisnicima u radu sa jednom ili vie
aplikacija
4. Informativni (inforamtive) upravljanje informacijama iz razliitih izvora.
Generalni model za razvoj agenata razvijen je od Fondation for Intelligent Physical Agents
(FIPA), i ukljuuje upravljaku komponentu, servisom direktorija (directory service) i
kanalom za komunikaciju agenata (slika 73.). Upravljaka komponenta aurira podatke o
trenutno aktivnim agentima, te omoguuje njihovo stvaranje i brisanje, komunikaciju
putem endpoint-a te usluge imenovanja. Directory service sadri informacije o osobinama
svih agenata pridruenih platformi (putem pohrane atributa o agentima) kao i podatke o
agentima pridruenim drugim platformama. ACC se koristi za komunikaciju izmeu
agenata putem prijenosa poruka.

Slika 73. Opi model platforme agenata

50

5. IMENOVANJE
Veliki broj razliitih entiteta u distribuiranim sustavima ukazuje na iznimnu vanost
imenovanja. Ime u distribuiranim sustavima je skup stringova koji oznaavaju entitet. Pod
entitetima podrazumijevamo resurse (pisae, diskove, datoteke, nositelje) i procesi
(korisnici, mailbox-ovi, novinske grupe, web stranice, grafiki prozori, poruke, mrene veze
itd). Pristup entitetima se ostvaruje putem pristupne toke (access point) koju zovemo
adresa. Ukoliko su imena entiteta neovisna o njihovoj adresi govorimo o lokacijskim
neovisnim (location independent) imenima. Oznaka istinskog identifikatora (true identifier)
koristi se za imena sa sljedeim svojstvima:
1. Identifikator se odnosi na najvie jedan entitet
2. Jedan entitet je referiran (definiran) samo sa jednim identifikatorom
3. Identifikator se uvijek odnosi na jedan entitet.
Vrsta imena uvedena sa namjerom pojednostavljenja koritenja raunala su humanfriendly imena definirana nizom stringova razumljivim ljudima (imena server).
Sustav imenovanja koristi strukturu direktorija. Na vrhu se nalazi root vor (node), a na
niim razinama se nalaze direktorij vorovi. vorovi koji prezentiraju entitet i njegova
svojstva i nemaju odlaznih vorova su zavrni vorovi (leaf node). Slika 74. Prikazuje graf
imenovanja sa jednim root vorom.

Slika 74. Opi model platforme agenata

Staza do imena ukljuuje vorove koji sadre bitne informacije za pristup entitetu, a mogu
biti apsolutne (poinju sa root vorom) i relativne (poinju od trenutno aktivnog vora).
Ukoliko je ime entiteta poznato neovisno o mjestu uporabe imena govorimo o globalnim
imenima. Lokalna imena su ovisna o mjestu upotrebe.

51

Za odreivanje imena entiteta pokree se postupak koji se zove name resolution. Za

uspjeno odreivanje imena entiteta potrebno je poznavanje poetnog vora za
pretraivanje to se osigurava posebnim mehanizmom (closure mechanism).
Implementacija sustava imena omoguuje korisnicima i procesima, dodavanja,
brisanje i pretraivanje imena entiteta. Organizacija sustava imena u distribuiranim
sustavima je hijerarhijski organizirana (slika 74.a):
1. Globalni sloj ukljuuje root vorove i direktorij vorove bliske root voru; stabilni
su i rijetko se mijenjaju, a prezentiraju organizacije i grupe organizacija
2. Administrativni sloj direktorij vorovi kojima se upravlja unutar jedne
organizacije; prezentira grupu entiteta koji pripadaju jednoj organizaciji ili
administrativnoj cjelini (odjel u organizaciji); relativno su stabilni, ali mogu biti
ee mijenjani nego vorovi globalnog nivoa
3. Upravljaki sloj (managerial) sadri direktorij vorove koji se esto mijenjaju
(korisniki direktoriji, dijeljenje biblioteke datoteka); za razliku od globalnog i
administrativnog sloja u kojem izmjene izvode iskljuivo administratora sustava,
izmjene se dozvoljavaju i krajnjim korisnicima.

Slika 74.a Organizacija sustava imena u distribuiranim sustavima

52

Implementacije pretraivanja imena (name resoulition) ostvaruje se pristupom name

resolveru koji je pridruen svakom klijentu, a namijenjen je odreivanju imena za traeni
entitet.
Postoje dva naina za provoenje postupka odreivanja imena:
1. Iterativni name resolver alje upit root voru za traeni entitet; root vor
prosljeuje traenu informaciju ako je entitet pridruen root voru ili prosljeuje
oznaku sljedeeg direktorij vora; name resolution prima odgovor i prosljeuje upit
direktorij voru (ako entitet nije u root voru) te se postupak nastavlja sve dok se
ne pronae ime traenog entiteta; implementacija je jednostavnija ali je mreni
promet intenzivniji nego za rekurzivni postupak (slika 75.)
2. Rekurzivni name resolution prosljeuje upit root voru koji vraa ime entiteta
ako je entitet pridruen root voru ili prosljeuje upit prvom sljedeem direktorij
voru za imenom entiteta; postupak se ponavlja sve dok se ne odredi ime entiteta
(slika 76.)

Slika 75. Iterativni postupak odreivanja imena entiteta (root.nl.cs.ftp)

53

Slika 76. Rekurzivni postupak odreivanja imena entiteta (root.nl.cs.ftp)

54

6. KONZISTENTNOST I REPLIKE

Replike su kopije originalnih podataka namijenjene poboljanju performansi rada sa

podacima i poveanju pouzdanosti koritenja podataka. Koritenje viestrukih kopija
podataka dovodi do problema konzistentnosti, odnosno auriranosti svih kopija podataka i
originalnih podataka. Nakon svake promijene originala ili bilo koje kopije podataka
potrebno je aurirati promjene na sve preostale kopije. Uspjenost postupka auriranja
podataka izravno odreuje cijenu uvoenja replika.
Uporaba replika prikladna je pri radu sa objektima (objedinjeni podaci i operacije na
podacima). Slika 76. prikazuje primjer koritenja objekta od strane vie korisnika.

Slika 76. Organizacija distribuiranih objekata dijeljenih izmeu dva klijenta

Osnovni problem pri radu sa replikama podataka je zatita objekata od istovremenog

pristupa to se postie na dva naina (slika 77.):
1. objekt kontrolira izvoenje zahtjeva korisnika primjenom metode sinkronizacije
(na primjer koritenjem monitora)
2. server kontrolira pristup objektima koritenjem objekt adaptera.

55

Slika 77. a) objekt kontrolira pristup klijenata b) pristup klijenata

kontrolira object adapter
Slijed izvoenja zahtijeva korisnika mora biti usklaen sa svim kopijama objekata, to se
postie (slika 78.):
1. Informiranjem objekta o postojanju replika
2. Distribuirani sustav je odgovoran za konzistentnost replika objekata

Slika 78. a) objekti informirani o replikama b) auriranje replika putem

distribuiranog sustava
Konzistentnost se razmatra u kontekstu operacija itanja i pisanja na podacima koji su
replicirani i dostupni putem djeljive memorije, distribuiranih baza podataka ili
distribuiranog datotenog sustava (slika 79.). Za operacije itanja i pisanja na repliciranim
podacima koristimo termin pohrana podataka (data store). Model konzistentnosti je

56

ugovor izmeu procesa i pohrane podataka kojim se procesi obvezuju na primjenu

odreenih pravila ponaanja pri radu sa podacima, a pohrana podataka garantira
ispravnost na podacima.
Pohrana podataka (data store) je opi naziv za operacije pohrane, itanja i pisanja na
podacima koji se nalaze u djeljivim memorijama, djeljivim datotenim sustavima ili
djeljivim bazama podataka (slika 79.). Model konzistentnosti je ugovor izmeu procesa i
data store-a o korektnom nainu upotrebe podataka.

Slika 79. Organizacija data store-a

6.1. Distribuirani protokoli

Distribuirani protokoli se odnose na propagacije replika i njihovo auriranje. Dizajn
distribuirana pohrane podataka (data store) odreen je odlukama kad, gdje i kome se
distribuiraju replike podataka. Slika 80. Prezentira logiku organizaciju razliitih vrsta
replika.

Slika 80. Vrste replika

57

Razlikujemo tri vrste kopija:

1.

Stalne replike (permanent) odreen broj replika koje su distribuirane u sustavu

(primjer je kopija website-a, odnosno primjena mirroringa)

2. Server inicirana replika replike iji nastanak inicira server koji ima originalne
podatke (kopiranje podataka na server raunalo na kojem se pojavljuje veliki broj
zahtjeva slika 81.); replike se mogu stvarati i brisati ovisno o nastalim potrebama
odnosno korisnikim zahtjevima
3. Klijent inicirane replike klijent koristi replike kako bi se smanjilo vrijeme
uitavanja podataka pri sljedeem zahtjevu za uporabom podataka (ei naziv za
replike nastale temeljem zahtjeva korisnika je cache).

Slika 81. Brojanje zahtijeva korisnika na odreenom serveru

6.2. Protokoli konzistentnosti

Protokoli konzistentnosti implementiraju model konzistentnosti, odnosno ugovor izmeu
procesa i pohrane podataka.
Razlikujemo:
1. Primary-based protokole svaka element podataka X ima pridruen primary
zaduen za provoenje operacija pisanja na X-u. Razlikujemo:
a. Remote-write protokole operacije itanja i pisanja se provode na
podacima pohranjenim na jednom serveru (slika 82.); mogua je

58

modifikacija u kojoj se podaci pohranjuju i na backu-up serveru (slika 83).

Nakon zahtjeva za promjenom vrijednosti X-a, mijenja se vrijednost na
serveru nakon eg slijedi poruka o potvrdi promjene vrijednosti i poruka o
auriranju vrijednosti.

Slika 82. Primary-based remote-write protokol

Slika 83. Primary backup protokol

b. Local-write protokoli nakon zahtjeva za promjenom vrijednosti X-a, X se
prenosi na raunalo koje je iniciralo zahtjev te ono postaje trenutni server
za vrijednost X, zatim se mijenja vrijednost i alje poruka za auriranje nove
vrijednosti i poruka o uspjenoj promjeni vrijednosti X-a (slika 84.);
rjeenjem sa uporabom primary-backup protokola prezentirano je slikom
85.

59

Slika 84. Primary-based local-write protocol

Slika 85. Primary backup protokol

2. Replicated-write protokole operacije pisanja se izvode na vie replika; problem u

radu sa repliciranim objektima pojavljuje se u situacijama kada objekt poziva drugi
objekt jer se poziv upuuje od svake replike objekta (slika 86.).; problem se rjeava
uvoenjem centralnog koordinatora sequencer koji alje samo jedan zahtjev a
ostale replike objekta informira o poslanom zahtjevu (slika 87.a.), a istovjetan
postupak se primjenjuje pri prihvatu odgovora od pozvanog objekta (slika 87.b.).

60

Slika 86. Problem viestrukog pozivanja objekta

Slika 87. Upotreba sequencer-a

61

7. Tolerancija na greke
Rad distribuiranih sustava ovisan je o toleranciji na greke. Povezanost velikog broja
raunala u koherentnu cjelinu odreuje znaaj greaka jednog ili vie raunala na rad
cjelokupnog sustava. Anuliranje posljedica pojava greaka od kljune je vanosti za rad
cjelovitog sustava. Tolerantnost na greke je usko povezana sa svojstvima zavisnih sustava
(dependable systems).

Najvaniji korisniki zahtjevi za rad distribuiranih sustava u pogledu zavisnosti su:

Dostupnost svojstvo spremnosti sustava na trenutno koritenje; sustav je

operativno dostupan u bilo kom trenutku i funkcionira na optimalan nain za
korisnika.

Pouzdanost sustav radi kontinuirano bez greaka; mjeri se u prosjenom

vremenu izmeu pojava greaka; pouzdan sustava ne mora biti i raspoloiv (sustav
koji trenutno nije u funkciji nema kvarova ali nije dostupan) dok dostupan sustav
ne mora biti pouzdan (pojava greke svake milisekunde u toku jednog sata daje
veliku dostupnost ali ne i veliku pouzdanost).

Sigurnost odnosi se na situacije nastanka privremenih greaka koje se ne

reflektiraju katastrofalnim posljedicama; pojava greke kompenzira se radom
ostalih dijelova sustava.

Odrivost odreuje mjeru lakoe oporavka sustava u situacijama kada nastane

greka.

7.1. Greke u distribuiranim sustavima

Neuspjean rad sustava (fail) nastaje kada sustav ne ispunjava obeana oekivanja
korisniku. Kvar (error) je dio stanja sustava koje moe uzrokovati pogreku (failure) u radu
sustava. Greka (fault) je definirana uzrokom nastanka kvara (error). Tolerantnost na
greke omoguuje izvoenje usluga sustava i za vrijeme pojave greaka.

62

Greka u sustavu se definira disfunkcionalnost uzrokovana:

grekom pri dizajniranju nerazumijevanje korisnikih zahtjeva, te nepotpune

korisnike specifikacije,

proizvodnom grekom uzrokovane dizajniranjem pogrene specifikacije ugrauju

se u konani proizvod (hardveski sklop),

programiranjem pogreke u dizajnu ugrauju se u kod aplikacije ili programer

pogreno interpretira korektno definirane specifikacije zasnovane na ispravnom
dizajnu,

fizikim oteenjem kvar na mediju za pohranu podataka ili komunikacijskim

vezama,

neoekivanim unosom pogreke korisnika tijekom unosa podataka.

Greke mogu biti:

Transient jednokratne uvjetovane pogrekom pri prijenosu podataka ili pri

itanju podataka; ponavljanjem zahtjeva greka se ne ponavlja.

Intermittent povremene uzrokovane ureajima koji povremeno uzrokuju greku

(npr. neadekvatan spoj konektora); teke su za otkrivanje zbog nepredvidivog
ponaanja ureaja ili sklopa koji uzrokuje kvar:

Permanent trajne uzrokovane nefunkcionalnou komponente i otklanjaju se

samo zamjenom neispravne komponente ispravnom.

Vanije vrste greaka u distribuiranim sustavima su:

prestanak rada servera - server radi korektno do pojave nefunkcionalnosti
proputanje zahtjeva (omission failure) klijenta server ne odgovara na zahtjev
klijenta
receive omission server nije primio dolaznu poruku
send omission server nije poslao poruku
vremenska greka server nije poslao odgovor u predvienom vremenu
izostanak odgovora servera (response failure) odgovor servera nije ispravan
value failure vraena vrijednost na traeni zahtjev je neispravna

63

 state transition failure sever odstupa od previenog naina odziva na

zahtjeve klijenta,
proizvoljne greke (arbitrary failure) sever generira proizvoljne odgovore
neovisno o vremenu i zahtjevima klijenata.

Sistemske greke odnose se na rad jedne ili vie komponenti sustava. Primjenom
tolerancije na greke nastoji se osigurati funkcionalnost distribuiranog sustava u sluaju
greke jedne ili vie njegovih komponenti.
Sistemske greke mogu biti:

Fail-silent prestanak rada procesora (fail-stop faults) koja drugi procesi lako
otkrivaju slanjem poruka provjere aktivnosti procesa

Byzantine nastavak rada uz generiranje netonih odgovora. Obrada greaka je

znatno tea.

Pojavom sistemskih greaka mora se omoguiti pruanje usluga sustava to je omogueno

oporavkom na greke koja se izvodi primjenom redundancije:

Redundancija informacija ponavljanje neuspjelog prijenosa podatka, odnosi se na

fiziku

redundanciju

(npr.

detektiranje

pogreke

pri

prijenosu

bita

komunikacijskom kanalu).

Redundancija vremena ponavljanje operacija koje su generirale greke (npr.

ponitavanje transakcija u sluaju neuspjenog izvoenja jedne ili vie aktivnosti).

Fizika redundancija koritenje dodatne opreme za kompenziranje rada

neispravnih komponenti.

Tolerantnost na greke primjenom fizike redundancije realizira se primjenom:

Aktivna zamjene

Backup-a.

Kvaliteta primjene fizike redundancije odreuje se:

stupnjem replikacije (broja dodatnih komponenti sustava),

kvalitetom usluga u sluaju izostanka greke,

kvalitetom usluga u sluaju pojave greke.

64

Aktivna zamjena mogua je primjenom TMR (Triple Modular Redundancy) ureaja kojima
se maskira pojava greaka na radu pojedinih procesa. Vie procesora izvodi istu obradu i
prosljeuje rezultat na ulaze TMR-a. TMR daju izlaznu vrijednost koja prevladava na ulazu,
odnosno za sluaj da veina procesora radi ispravno TMR maskira neispravan rad
pojedinih procesora (slika 88. za neispravan rad jednog od procesa A, B ili C nee doi do
pojave greke u sustavu).

Slika 88. Redundancija primjenom TMR-a

Primjena backup-a odnosi se na koritenje zamjenskih komponenti koje zamjenjuju rad
primarne komponente. Zamjenska komponenta ima sve podatke kao i primarna te tako
moe preuzeti funkciju primarne komponente (slika 89.). Razlike primjene backup-a u
odnosu na aktivnu zamjenu su:

Upotreba zamjenskog servera, koji u sluaju greke zamjenjuje primarni server.

Jednostavnija implementacija u odnosu na aktivnu zamjenu.

Potrauje manji broj zamjenskih komponenti.

Oporavak od primarne greke (neispravnosti) je sloen i vremenski zahtijevan

65

Slika 89. Primjena backup-a

Tolerantnost na greke na razini procesa ostvaruje se repliciranjem procesa te

povezivanjem procesa u grupe. Poruka poslana grupi procesa prosljeuje se do svakog
procesa. Komunikacija u grupi moe biti zasnovana na flat grupi ili hijerarhijskoj grupi
(slika 90.). Praenjem ponaanja procesa mogu se izbjei greke koje nastaju neispravnim
radom jednog ili vie procesa u grupi.

Slika 90. a) komunikacija u flat grupi b) komunikacija u hijerarhijskoj grupi

Problemi zasnovani na pogrenom radu pojedinih procesa poznati su kao Byzantine
General problemi. Problem se oituje u injenici da proces generira poruke koje sadre
pogrene vrijednosti, odnosno proces je funkcionalan ali generira greke pri radu. Pri
utvrivanju rada neispravnih procesa potrebno je utvrditi sljedee:

Postoje li problemi pri isporuci poruka?

Da li je proces funkcionalan (pojava Byzantine greke)?

Postojanje sinkroni (greka se pojavljuju unutar definiranog intervala vremena) ili

asinkronog sistema?

66

Two-army problem ili Byzantine genarals problems prezentiran je na slici 91. Proces 3
konstantno generira greke koje se otkrivaju na sljedei nain. Svaki proces alje ostalima
informaciju o jakosti svojih trupa (slika 91.(a)), te svaki od njih prikuplja podatke od drugih
procesa u obliku vektora (slika 91.(b)). Nakon toga svaki proces prosljeuje svoj vektor
ostalim procesima, te konano svaki proces usporeuje vrijednosti u svakom stupcu, te
onaj stupac koji nema prevladavajuu vrijednost odreuje proces koji generira greke
(slika 91.(c)).

Slika 91. Byzantine general problem

Byzantine general problem rjeiv je ako vie od dvije treine procesora rade ispravno
(2m+1 od 3m). Slika 92. prikazuje situaciju u kojoj nije mogue otkrivanje procesa koji
generira greka jer nije mogue odrediti prevladavajuu vrijednost u stupcima.

Slika 92. Primjer nerjeivog Byzantine general problem

67

7.2. Atominost
Rad procesa u grupi, odnosno ponaanje jednog procesa i njegovih replika moe se
razmatrati u kontekstu atominosti. Kompletirana obrada nastaje jedino u sluaju
ispravnog rada svih procesa, odnosno zavretak obrade karakterizira kompletnost obrade
svih procesa (Distributed commit). Atominost se ostvaruje radom koordinatora za
kontrolu provoenja tijeka transakcija. Koordinator moe primjenjivati sljedee protokole
pri kontroli provoenja transakcija:

One-phase commit protocol slanje zahtjeva za obradu svim procesima u grupi;

jednostavna implementacija protokola, ali je uspjenost izvoenja transakcija teko
ostvariva jer procesi ne mogu dojaviti koordinatoru stanje nespremnosti za obradu.

Two-phase commit protocol koordinator alje poruka za pristupanje transakciji

(VOTE_REUEST),

procesi

odgovaraju

sa

porukama

(VOTE_ABORT

ili

VOTE_COMMIT), ako svi vrate poruku VOTE_COMMIT koordinator alje poruku

GLOBAL_COMMIT za poetak transakcije ili u suprotnom GLOBAL_ABORT za prekid
transakcije; stanja koordinatora i svakog procesa prikazana su na slici 93. Nakon
zapoete obrade svaki proces mora potvrditi kompletiranost obrade slanjem
poruke koordinatoru koji kompletira transakciju ili u suprotnom ponitava
zapoetu transakciju.

Slika 93. a) konana stanja koordinatora b) konana stanja za procese u transakciji

68

Three-phase commit protocol kompenzira nedostatak two-phase commit

protokola definiran nefunkcionalnou koordinatora; koordinator nakon primitka
poruke VOTE_COMMIT od svih procesa alje poruku PREPARE_COMMIT i nakon
primitka poruke potvrde primitka od svih procesa u transakciji koordinator alje
GLOBAL_COMMIT (slika 94.) te se time omoguuje procesima da zavre transakciju
i u situaciji kada koordinator nije funkcionalan za vrijeme izvoenja transakcije.

Slika 94. a) konana stanja koordinatora b) konana stanja za procese u transakciji

7.3. Opravak
Tolerancijom za greke sustav iz stanja postojanje greke dovodimo u stanje u kojem
nema greke to zovemo oporavkom. Oporavak je mogu na dva naina:

Opravak unatrag (backward recovery) sustav vraamo u stanje u kojem je radio

bez greke; ostvaruje se pohranjivanjem stanja sustava u odreenim trenutcima
(checkpoint) ime se omoguava povrat sustava u ispravno stanje

Oporavak unaprijed (forward recovery) sustav se dovodi u budue ispravno

stanje; ovaj pristup je tee realizirati jer nije mogue sa sigurnou odrediti vrstu
greke koja e se pojaviti.

Za povrat u prethodno stanje koriste se prethodno sigurno pohranjene informacije,

odnosno podaci koji nisu oteeni pri pojavi greke. Sigurna pohrana podataka moe
se ostvariti primjenom sigurne pohrane (stable storage), gdje se podaci zapisuju na

69

dva mjesta (slika 95.). Ukoliko proces auriranja nije izveden korektno na oba mjesta,
usporedbom blokova utvruje se ispravno zapisan podatak, nakon ega slijedi
usklaivanje vrijednosti oba bloka. Ako doe do greke pri itanju podataka sa jednog
bloka (prisutnost praine ili fiziko oteenje) podaci mogu biti preuzeti sa njegove
kopije.

Slika 95. a) stable storage b) usklaivanje auriranosti blokova c) uporaba odgovarajue

kopije bloka pri nastanku greke pri itanju
Pohrana konzistentnih stanja sustava (checkpoint) Trenutak pohrane konzistentnosti
sustava zove se distributed snapshot, a odnosi se na stanje sustava za koje vrijedi da za
svaki proces koji je zabiljeio primitak poruke postoji proces koji je zabiljeio slanje te
poruke (slika 96.). Nastankom greke procesi vraaju podatke iz prethodnih kontrolnih
toki (checkpoint) sve dok se ne uspostavi globalno konzistentno stanje sustava to se
oznaava sa recovery line.

Slika 96. Vraanje sustava u konzistentno stanje (recovery line)

70

8. Sigurnost
Sigurnost ima veliku vanost za distribuirane sustave. Koritenje mree raunala kao
koherentnog sustava omoguuje pristup hardverskim i softverskim resursima cjelokupne
mree. Zato je sigurna komunikaciji dvaju korisnika ili procesa iznimno vana to se
ostvaruje koritenjem sigurnosnih kanala. Drugi aspekt sigurnosti odnosi se na
autorizaciju, odnosno osigurava pristup procesima samo dodijeljenim objektima i njihovim
metodama.

8.1. Sigurnosna politika i sigurnosni mehanizmi

Sigurnost je od iznimne vanosti u distribuiranim sustavima jer odreuje dozvole
pristupa i naine uporabe resursa u DS-a. Analiza sigurnosti polazi od:
1. Sigurnosnih prijetnji ukljuuje:
a. Presretanje (interseption) odnose se na neautorizirani pristup uslugama ili
podacima (presretanje komunikacije, ilegalno kopiranje podataka, pristup
privatnom direktoriju korisnika).
b. Prekidanje (interruption) odnosi se na gubitak ili oteenje datoteka ili
openito na situacije u kojima su usluge ili podaci djelomino ili trajno
oteeni.
c. Izmjene (modification) neautorizirana izmjena podataka ili nastojanja
promjene naina izvoenja usluga (izmjena podataka koji se prenose,
promjena zapisa u bazi podataka).
d. Dodavanje (fabrication) dodavanje novih podataka ili usluga (unos
podataka u datoteku sa korisnikim raunima).
2. Sigurnosna politika propisuje koje aktivnosti na entitetima (korisnici, podaci,
usluge, raunala itd.) u sustavu su dozvoljene, a koje su zabranjene.
3. Sigurnosni mehanizmi koriste se provoenje sigurnosne politike i ukljuuju:

71

a. Kriptiranja

- promjenu podataka u oblik nerazumljiv neovlatenim

korisnicima.
b. Autentifikacija korisnika odreivanje identiteta korisnika, klijenta ili
servera (za korisnike je uobiajene uporaba passworda).
c. Autorizacija provjera dozvola koritenja odreene aktivnosti za
konkretnog korinika.
d. Provjeravanje (auditing) praenje aktivnosti korisika, odnosno vremena i
naina uporabe entiteta (log datoteke).

Distribuirani sustav provode sigurnost primjenom irokog raspona sigurnosnih politika.

Implementacija sigurnosnih servisa ope namjene u DS-u, uvjetovana je dizajnom
sigurnosti. Pri izradi dizajna sigurnosti Najee se uvaavaju sljedei elementi:
1. Kontrola primjenjuju se tri pristupa (slika 97.)
a. Zatita podataka povezanih sa aplikacijama (npr. Zatita podataka u bazi
podataka).
b. Zatita putem kontrole pristupa operacijama na podacima (pozivanje
odreenih metoda na objektima)
c. Zatita putem kontrole dozvola korisnika za pristup aplikaciji (dodjela prava
koritenja aplikacije i dodjela uloga role)
2. Slojevitost sigurnosnih mehanizama odnosi se na odreivanje razine sloja DS-a za
primjenu odreenog sigurnosnih mehanizama (slika 98). Slika 99. prikazuje primjer
primjene sigurnosti na SMDS povezivanju lokalnih mrea gdje se kodiranje i
dekodiranje paketa izvodi izravno na ruterima. Ukoliko korisnici ele dodatnu
sigurnost mogu koristiti SSL (Secure Socket Layer).
3. Distribucija sigurnosnih mehanizama primjena TCB (Trusted Computing Base),
odnosno skupa sigurnosnih mehanizama potrebnih za provoenje sigurnosne
politike (za primjenu middleware-a TCB se odnosi na sigurnost operativnog sustava
svakog lokalnog raunala. Zatita izravnog pristupa klijenata kritinim uslugama
sustava po pitanju sigurnosti postie se primjenom RISSC-a (Reduced Interfaces for

72

Secure System Components). Zatita se provodi postavljanjem kritinih usluga na

raunala izolirana od krajnjih korisnika uporabom sigurnosnog mrenog interfejsa
niske razine (slika 100).
4. Jednostavnost

- primjena jednostavnih lako razumljivih i pouzdanih sigurnosnih

mehanizama doprinosi poveanju pouzdanosti u sigurnost sustava.

Slika 97. Kontrola pristupa entitetima

Slika 98. Logika organizacija distribuiranog sustava u slojeve

Slika 99. Primjena SMDS-a u povezivanju lokalnih mrea

73

Slika 100. Primjena RISSC-a u kontroli pristupa

Kriptiranje je postupak prevoenja originalnog dokumenta (plaintext) u kriptirani oblik
(cipertext) primjenom kljua za kriptiranje (slika 101.).
Kriptiranje: C = EK(P),
Dekriptiranje: P = DK(C).
Mogui napadi na poslane poruke mogu biti:

Presretanje poruke neitljive ako klju za kriptiranje nije poznat

Izmjena poruke nemogue bez kljua za kriptiranje

Umetanje kriptiranih poruka pokuaj slanja lane poruke kao

originalne

Kriptiranje se moe izvoditi primjenom:

Simetrini sustav za kriptiranje (Secret-key ili shared-key system) - klju za kriptiranje i

dekriptiranje je jednak

Asimetrian sustav za kriptiranje (public-key system) kljua za kriptiranje i

dekriptiranje nije jednaka, ali ine par.

Primjenom hash funkcije original se prevodi u string odreene duine primjenom

privatnog kljua: h = H(m). Svojstva Hash funkcije su:

One-way funkcija izraunavanje m iz h nije mogue

Weak collision resistance dva razliita m ne mogu dati isti rezultat

H(m) H(m')

Stronk collision resistance nije mogue iz H dobiti dva razliita m

74

Slika 101. Primjena kriptiranja poruke

8.2. Sigurnosni kanali

Sigurnosni kanali se koriste za zatitu komunikacijskih kanala tijekom komunikacije

izmeu klijenta i servera. Sigurnosni kanali omoguuju zatitu od presretanja,
modifikacije i fabriciranja poruka. Upotreba sigurnosnih kanala usko je povezana sa
postupkom autentifikacije i provjere integriteta poruka (korisnici moraju biti sigurni tko
alje poruka i da poruka nije mijenjala sadraj). Uobiajena je upotreba tajnog kljua za
enkripciju (secret-key criptografy) ili kljua sesije (session key). Klju sesije omoguuje
kriptiranje poruka radi ouvanja integriteta poruka. Klju sesije se koristi samo za vrijeme
postojanja sigurnog kanala, nakon ega se ponitava (discard).
Autentifikacija zasnovana na djeljivom tajnom kljuu prikazana je na slici 102. Alice i Bob
uspostavljaju komunikaciju primjenom sljedeih koraka:
1. Alice alje svoj identitet bobu.
2. Bob alje Alice broj za kodiranje RB (broj je sluajno odabran).
3. Alice kriptira broj RB zajednikim kljuem za kriptiranje KA,B.
4. Bob dekriptira vrijednost broja RB primjenom zajednikog kljua KA,B i usporeuje je
sa poslanom vrijednosti; u sluaju korektne vrijednosti broja RB Bob zna da
komunicira sa Alice.

75

5. Alice alje broj za kodiranje RA Bobu.

6. Bob kodira broj RA zajednikim kljuem za kodiranje i alje ga Alice, te ako se
dekodirana vrijednost broja RA poklapa sa poslanom vrijednosti Alice zna da
komunicira sa Bobom.

Slika 102. Autentifikacija zasnovana na djeljivom tajnom kljuu

Broj prenesenih poruka moe se smanjiti slanjem poruke o identifikaciji i broja za
kodiranje RA od Alice ka Bobu, zatim slanjem kodirane vrijednosti broja RA i zahtjeva za
kodiranjem broja RB od Boba ka Alice. Na kraju Alice vraa kodiranu vrijednost broja RB
(slika 103).

Slika 103. Autentifikacija zasnovana na djeljivom tajnom kljuu

primjenom tri poruke
Autentifikacija primjenom tri poruke moe biti zaobiena reflection napadom (slika 104.).
Chunk (ima ulogu napadaa) lano se predstavlja kao Alice i trai kodiranje broja RC te Bob
kodira broj RC i trai kodiranje broja RB. Nakon toga Chunk alje novu poruku za
otvaranjem novog sigurnosnog kanala predstavljajui se kao Alice i traenjem kodiranja
vrijednosti RB (to je vrijednost koju je Bob poslao Alice) od Boba. Nakon dobivanja
76

kodirane vrijednosti broja RB, Chunk alje vrijednost kodiranu vrijednost pretvarajui se
kao Alice te Bob usporedbom dobiva korektnu vrijednost i smatra da komunicira sa Alice.
Ckhunk je slanjem ponovnog zahtjeva za otvaranjem kanala i kodiranja vrijednosti RB uspio
dobiti kodiranu vrijednost te zavarati Boba.

Slika 104. Reflection napad (Chuck je napada)

Napad se moe izbjei dogovorom da Alice alje samo parne brojeve za kodiranje, a Bob
neparne. Na taj nain e Bob dobiti zahtjev za kodiranjem neparnog broja i znati e da se
radi o napadu.

8.3. Integritet poruka i pouzdanost

Sigurnosni kanali moraju osigurati Integritet i pouzdanost poruka. Integritet znai da su
poruke zatiene od modifikacije, dok pouzdanost sprjeava presretanje i itanje poruka.
Pouzdanost se postie kriptiranjem poruka prije slanja. Integritet poruka osigurava se
primjenom digitalnih potpisa kojim se poiljatelj i primatelj poruke obvezuju na
priznavanje trenutne vrijednosti sadraja poruke. Ukoliko poiljatelj ili primatelj
promijene sadraj poruka, primjenom digitalnog potpisa utvrditi e se nastala promjena
u sadraju. Digitalni potpis moe biti:
Digitalni potpis primjenom javnog kljua za kriptiranje (public-key cryptography)
Digitalni potpis primjenom hash funkcije za izraunavanje stringa za heiranje
(message digest)

77

Izrada digitalnog potpisa primjenom javnog kljua za kodiranje (slika 105.) ukljuuje
kodiranje poruke m privatnim kljuem od Alice i javnim kljuem Boba (javni kljuevi su
dostupni svim korisnicima). Bob otvara poruku primjenom svog privatnog kljua te je
dekodira primjenom javnog kljua od Alice. Ako Bob mijenja poruku mora dokazati Alice
da je promijenjena poruka potpisana od Alice, dok promjene poruke od Alice Bob
dokazuje razlikama u poslanoj poruci m od Alice i poruci koju je izveo postupkom
kodiranja.

Slika 105. Digitalni potpis primjenom javnog kljua za kriptiranje

Premda je postupak dokazivanje integriteta poruka korektan postoje odreeni problemi
(npr. potreba za uvanjem potpisanih verzija poruka, tajnost privatnog kljua uesnika,
zahtjev za promjenom privatnog kljua) pa se moe koristiti hash funkcija. Hash
funkcijom nije mogue dobiti identine izlazne vrijednosti za razliite ulazne vrijednosti,
odnosno modifikacija je lako dokaziva jer je H(m') H(m). Alice generira vrijednost hash
funkcije za poruku m te je kodira sa svojim privatnim kljuem. Bob prima originalnu
poruku m od Alice na koju primjenjuje hash funkciju da bi generirao mesagge digest te
ga usporedio sa mesagge digestom dobivenim dekodiranjem poruke primjenom javnog
kljua od Alice. Ukoliko se mesagge digest poklapaju poruke su autentine (slika 106)..

Slika 106. Digitalni potpis primjenom mesagge digest

78

8.4. Kontrola pristupa

Kontrolom pristupa osigurava se izvoenje zahtjeva klijenata na metodama objekata
samo u sluaju postojanja dozvola pristupa (access rights) klijenta na traenom objektu.
Kontrola pristupa se najee ostvaruje primjenom programa za provjeru dozvola za rad
na objektima (reference monitor, slika 107.). Reference monitor sadri informacije o
dozvolama pristupa objektima i nainima koritenja operacija na objektima za sve
klijente koji pristupaju objektu.

Slika 107. Program reference monitor

Modeliranje kontrole pristupa ostvaruje se primjenom matrica kontrola pristupa, gdje su
redci klijenti, a stupci objekti. Klijent koji ima pristup objektu sadri u matici kontrole
pristupa u presjeku pripadnog retka klijenta i stupca objekta prava za koritenje objekta.
Matrica kontrole pristupa sadri jedan redak za svakog klijenta i stupac za svaki objekt,
pa je njena veliina velika dok je veina unosa u matrici (u presjeku redaka i stupaca)
uglavnom prazno. Stoga se provodi reduciranje veliine matrice kontrole pristupa
primjenom:
Listi kontrole pristupa (Access Control List ACL) svaki objekt sadri popis
klijenata koji je dozvoljen pristup te operacije koje su im dozvoljene.
Listi mogunosti (capabilities list) svaki klijent ima popis objekata kojima moe
pristupati i operacije koje na njima moe izvoditi.
Slika 108. Prikazuje usporedbu ACL-a i listi mogunosti.

79

Slika 108. a) ACL liste b) capabilities liste

Daljnje smanjenje listi kontrole pristupa omogueno je primjenom domena zatite koje
predstavljaju parove (objekt, pravo pristupa). Zatitne domene esto koriste grupe
korisnika (slika 109.).

Slika 109. Hijerarhijska organizacija domena zatita za grupe korisnika

Reference monitor prilikom provjere prava pristupa nekom objektu provjerava grupu kojoj
pripada korisnik, a zatim provjerava ima li grupa pravo koritenja objekta te koje su
operacije na objektu dozvoljene. Rad reference monitora moe biti olakan instaliranjem
certifikata na raunala korisnika. Drugi pristup je kontrola pristupa zasnovana na ulogama,
gdje se korisnik logira u sustav, a zatim se provjerava njegova uloga u sustavu to izravno
odreuje skup objekata za pristup i operacije na objektima koje su dozvoljene.

80

Vatrozid (Firewall) je posebna vrsta reference monitora koja omoguuje odvajanje jednog
dijela distribuiranog sustava od ostatka sustava (slika 110.). Dolazni i odlazni paketi
preusmjereni su na posebno raunalo i provjereni prije dozvole za prijenos. Vatrozid je
zatien od sigurnosnih prijetnji, odnosno ne smije biti izvan funkcije. Vatrozid ima dvije
komponente:

Packet filtering router dozvoljava prijenos paketa ovisno o polaznoj i odredinoj

adresi paketa i sadraju zaglavlja paketa,

Application gateway dozvoljava prijenos paketa ovisno o sadraju dolaznih i

odlaznih poruka.

Slika 110. Primjena kriptiranja poruke

8.5. Sigurnost mobilnog koda

Distribuirana obrada omoguuje prijenos obrade na druga raunala to uvjetuje
migraciju koda izmeu raunala, a time i potencijalnu opasnost od sigurnosnih prijetnji.
Pri prijenosu koda nuno je osigurati nepromjenjivost koda pri prijenosu prema raunalu
na kojem se izvodi obrada. Koriste se tehnike provjere stanja agenta prije izvoenja na
klijentu i analiza promijene sadraja klijenta. Zatita koda agenta na klijent strani ostvaruje
se primjenom posebnih tehnika (sandbox). Tehnika sandbox dozvoljava izvoenje
unaprijed definiranih operacija na agentu i sprjeavanje nedozvoljenih aktivnosti. Slika
111. prikazuje primjer sandbox-a realiziranog programskim jezikom Java . Loader je Java
klasa namijenjena preuzimanje traenog koda sa servera i njegovo instaliranje na adresni
prostor klijenta. Prije instalacije provodi se provjera koda primjenom Class verifier-a koji
utvruje zadovoljava li preuzeta klasa sigurnosne zahtjeve sandbox-a.

81

Slika 111. Organizacija Java Sandbox-a

Mogua zatita pri migraciji koda je koritenje zasebnog dijela distribuiranog sustava
namijenjenog izvoenju mobilnog koda (playground). Playground je izdvojeno raunalo
namijenjeno izvoenju mobilnog koda koji moe koristiti lokalne resurse ali nema pristup
resursima drugih raunala u distribuiranom sustavu, odnosno mobilni kod moe koristiti
samo resurse playground-a (slika 112.)

Slika 112. a) sandbox b) playground

82