VOJNA AKADEMIJA VOJSKE JUGOSLAVIJE

Smer slube informatike

Distribuirani raunarski sistemi

-skripta-

Profesor
dr Boidar Radenkovi
Fakultet Organizacionih Nauka
Beograd, 2001.

Studenti
53. klasa
Sluba informatike

Sadraj:
1.KONCEPTI OPERATIVNIH SISTEMA........................................................................................ 5
1.1.Osnove operativnih sistema.......................................................................................... 5
1.2.Razvoj operativnih sistema............................................................................................ 5
1.3.Centralizovani operativni sistemi..................................................................................5
1.4.Mreni operativni sistemi............................................................................................... 6
1.5.Distribuirani operativni sistemi......................................................................................6
1.6.Kooperativni nezavisni sistemi......................................................................................7
1.7.Standardizacija.............................................................................................................. 7
2.Koncepti distribuiranih sistema.............................................................................................. 8
2.1.Koristi od distribuiranih sistema....................................................................................8
2.2.Servisi........................................................................................................................... 8
2.3.Projektni zahtevi............................................................................................................ 8
2.4.Sistemski modeli........................................................................................................... 8
2.5.Transparentnost............................................................................................................. 9
2.6.Fleksibilnost.................................................................................................................. 9
2.7.Pouzdanost.................................................................................................................... 9
2.8.Performanse................................................................................................................ 10
2.9.Distribuirani algoritmi.................................................................................................. 10
3.Konkurentni procesi i programiranje.....................................................................................11
3.1.Konkurentni procesi..................................................................................................... 11
3.2. Korienje niti............................................................................................................. 11
3.2.1 Implementacija niti u prostoru korisnikog programa...........................................11
3.2.2 Implementacija niti u kernelu...............................................................................11
3.3 Klijent - Server model.................................................................................................. 12
3.4 Vreme u distribuiranim sistemima...............................................................................12
3.4.1 Logiki sat............................................................................................................ 12
3.4.2 Fiziki sat.............................................................................................................. 13
3.5 Konkurentno programiranje......................................................................................... 13
3.6 Sinhronizacija slanja poruka........................................................................................14
4.MEUPROCESNA KOMUNIKACIJA.......................................................................................15
4.1.Meuprocesna komunikacija.......................................................................................15
4.2.Komunikacija prenoenjem poruka..............................................................................15
4.3 Sinhronizacija i prihvatanje poruka..............................................................................16
4.4 Pipe i socket APIs..................................................................................................16
4.5.Zatitni sloj socketa..................................................................................................... 17
4.6.Komunikacija grupe i multiprenos(multicast)...............................................................18
4.6.1 Ureivanje multiprenosa.......................................................................................18
4.6.2 Uzrono ureen multiprenos.................................................................................18
4.6.3 Atomski multiprenos............................................................................................. 18
4.7 Komunikacija upit/odgovor..........................................................................................19
4.7.1 Parametar prenosa i konverzija podataka.............................................................19
4.7.2 RPC kompilacija.................................................................................................... 19
4.7.3 Povezivanje........................................................................................................... 20
4.7.4 RPC izuzeci i upravljanje otkazima........................................................................20
4.7.5 Sigurnost: Suns Secure RPC.................................................................................21
4.8 Transakciona komunikacija.......................................................................................... 21
4.8.1 Dvofazni protokol.................................................................................................. 21
4.8.2 Tok izvravanja 2PC.............................................................................................. 22
4.8.3 Oporavak.............................................................................................................. 22
4.9 Servisiranje po imenu i sadraju..................................................................................22
4.9.1 Rezolucija imena................................................................................................... 22
4.9.2 Informaciona baza sadraja..................................................................................23
5. MEUPROCESNA KOORDINACIJA......................................................................................24
5.1 Kooperativni procesi.................................................................................................... 24
5.2 Distribuirana meusobna iskljuenja...........................................................................24
5.2.1 Lamport-ovi algoritmi distribuiranih meusobnih iskljuenja................................24
5.2.2 Ricart i Agrawal-ov algoritam distribiranih meusobnih iskljuenja......................25
5.2.3 Algoritmi distribuiranih meusobnih iskljuenja zasnovani na glasanju................25

5.2.4.1 Meusobno iskljuenje prenoenjem tokena. Topologija logikog prstena.........25

5.2.4.2 Meusobno iskljuenje prenoenjem tokena. Struktura logikog stabla.............26
5.2.5 Meusobno iskljuenje prenoenjem tokena. Prenos............................................26
5.4.1 Algoritmi za izbor lidera. Potpuna topologija............................................................26
5.4.2 Algoritmi za izbor lidera.Topologija logikog prstena................................................27
6. RASPOREIVANJE DISTRIBUIRANIH PROCESA...................................................................28
6.1Strategije Rasporeivanja Distribuiranih Procesa.........................................................28
6.1 Politika Rasporeivanja Distribuiranih Procesa............................................................28
6.2.1 Strategije statinog rasporeivanja distribuiranih procesa...................................28
Prednosti Modela Procesa.................................................................................................. 29
Komunikacije Model Procesa.............................................................................................. 29
6.2.2 Strategije dinamikog rasporeivanja procesa.....................................................29
Deljenje optereenja...................................................................................................... 30
Rasporeivanje Optereenja.......................................................................................... 30
6.3 Mehanizmi Rasporeivanja Distribuiranih Procesa.......................................................30
6.3.1 Daljinsko izvravanje............................................................................................ 31
6.3.2 Prebacivanje procesa............................................................................................31
8. DISTRIBUIRANI FAJL SISTEMI............................................................................................. 32
8.1 Aspekti DFS-a.............................................................................................................. 32
8.2 Organizacija Fajl Sistema.............................................................................................32
8.3 Fajl Serveri................................................................................................................... 33
8.3.1 Fajl Serveri Sa i Bez Informacija o Postojeem Stanju (Stateful and Stateless).....34
8.4 Semantika Deljenja Fajla............................................................................................. 34
8.5 Keiranje...................................................................................................................... 35
8.6 Replikacija Fajla........................................................................................................... 35
8.6.1 Update Protokoli................................................................................................... 35
9. DISTIBUIRANA DELJENA MEMORIJA...................................................................................37
9.1 Motivacija i Principi...................................................................................................... 37
9.2 DSM Arhitektura.......................................................................................................... 37
9.2.1 Vrste DSM Sistema...............................................................................................38
9.3 Modeli Postojanosti Memorije......................................................................................38
9.3.1 Modeli postojanosti generalnog pristupa..............................................................39
9.3.2 Modeli postojanosti sinhronizovanog pristupa......................................................39
9.4 Algoritmi Memory Menadmenta.................................................................................39
10. ZATITA U DISTRIBUIRANIM RAUNARSKIM SISTEMIMA...................................................41
10.1 Zatita u raunarskim sistemima..............................................................................41
10.2 Osnove raunarske zatite........................................................................................41
10.3 Modeli kontrole diskrecionog pristupa.......................................................................42
10.4 Mandatorni modeli kontrole pristupa.........................................................................43
10.4.1 Lattice "Reetka" model......................................................................................43
10.4.2 Bell-LaPadula model...........................................................................................43
10.5 Modeli kontrole pristupa zasnovani na ulogama (RBAC)............................................43
10.6 Kriptografija............................................................................................................... 44
10.7 Kriptografski sistemi sa tajnim kljuem.....................................................................44
10.8 Kriptografski sistemi sa javnim kljuem.....................................................................45
10.9 Autentifikacija i distribucija kljueva..........................................................................45
10.9.1 Protokoli autentifikacije.......................................................................................45
10.10 Kerberos protokol.................................................................................................... 46
10.11 Prikriveni kanali....................................................................................................... 47
10.12 Mehanizam Nadzora................................................................................................ 47
11. UNIX i WINDOWS NT.......................................................................................................... 49
11.1 Istorija UNIX-a............................................................................................................ 49
11.2 Opis ciljeva "ranog" 4BSD Sistema............................................................................49
11.3 Proces adresiranja..................................................................................................... 49
11.4 Deljenje memorije u BSD Unix-u................................................................................50
11.5 IPC model.................................................................................................................. 50
11.6 Komunikaciona semantika.........................................................................................50
11.7 Tipovi soketa............................................................................................................. 51
11.7.1 Sistemski pozivi soketa.......................................................................................51
11.7.2 Nepovezani komunikacioni soket........................................................................51
11.7.3 Povezani komunikacioni soket............................................................................52
11.8 Besplatni operativni sistemi......................................................................................53

11.9 Mreni API u Windows NT..........................................................................................54

11. 10 Imenovani tokovi.................................................................................................... 54
12. MIKROKERNEL................................................................................................................. 55
12. 1 Koncept Mikrokernela............................................................................................... 55
12. 2 Monolitni operativni sistem......................................................................................55
12. 3 Mikrokernel pristup................................................................................................... 55
12.4 Upravljanje procesima............................................................................................... 56
12.5 Upravljanje memorijom.............................................................................................56
12.6 Meuprocesna komunikacija.....................................................................................57
12.7 Ulaz/izlaz................................................................................................................... 57
12.8 U235.......................................................................................................................... 57
12.8.1 Procesi i domeni.................................................................................................57
12.8.2 Meuprocesna komunikacija...............................................................................57
12.8.3 Upravljanje memorijom......................................................................................58
12.9 Proces rasporeivanja...............................................................................................58
13 CORBA.............................................................................................................................. 59
13.1 OMA (Object Managment Arhitecture).......................................................................59
13. 2 The OMA Reference Arhitecture................................................................................59
13.3 Common Object Request Broker Arhitecture (CORBA)...............................................60
13. 4 Object Request Broker.............................................................................................. 60
13. 5 Jezik za definiciju interfejsa......................................................................................61
13. 6 CORBA meuoperativnost........................................................................................61
13. 7 CORBA servis adresiranja.....................................................................................61
13. 8 Resursi arhitekture CORBA.......................................................................................62

1.KONCEPTI OPERATIVNIH SISTEMA

1.1.Osnove operativnih sistema

Glavni cilj operativnih sistema je da obezbedi apstrakciju maine (proirena ili virtuelna maina)
predstavljenu kao skup servisa. Servisi su implementirani kao skup softverskih modula koji ine interfejs
izmeu programa (alata i aplikacija) i sistemskog hardvera. Sistemski servisi mogu biti grupisani u
sledee kategorije: kontrola procesa, manipulacija datotekama, manipulacija ureajima, odravanje
informacija o statusu sistema i komunikacija.
Sistemski hardver se sastoji od procesora, memorije, U/I ureaja i komunikacionih interfejsa. Ovi resursi
trebaju biti efikasno iskorieni. Sa ove take gledita operativni sistem se mora ponaati kao upravlja
resursima. Funkcije operativnog sistema kao upravljaa resursima su sledee:
-

rasporeivanje procesa

sinhronizacija procesa i meuprocesna komunikacija.

upravljanje ureajima i komunikacijama

upravljanje memorijom

upravljanje datotekama.

1.2.Razvoj operativnih sistema

Centralizovani operativni sistemi (konvencionalni) - dobro razumljivi, koriste virtualni koncept kao virtualnu
mainu
Mreni operativni sistemi i distribuirani operativni sistemi su posledica velike ekspanzije umreavanja.
U mrenim operativnim sistemima korisnci su svesni postojanja vie maina(raunara). Koncept
saradnje meu mainama omoguava deljenje resursa ukljuujui programe i podatke. Distibuirani
operativni sistem daje svima jednosistemski pogled na viestruki raunarski sistem(raunaru spojeni u
mreu). Sistem koji realizuje ovaj cilj naziva se transparentnim.
Kooperativni nezavisni sistemi koncept koji preovladava u okruenjima otvorenih sistema. Dodatna
funkcija jednoprocesorskom operativnom sistemu koja obezbeuje saradnju meu raunarima je
sposobnost razmene informacija preko nekog spoljanjeg komunikacionog kanala. Distribuirani operativni
sistemi zahtevaju mnogo manje napora da se postigne potpuna transparentnost. Zbog toga nastaje
potreba za algoritmima distribuirane kontrole. Prava transparentnost nije uvek poeljna. Korisnici bi
moda vie voleli da budu svesni postojanja viestrukih resursa i da koriste softverske sisteme koji su
konstruisani integracijom kooperativnih nezavisnih delova softvera.

1.3.Centralizovani operativni sistemi

Sam operativni sistem je veliki program. Tradicionalno, kad se implementiraju takvi programi, oni su
struktuirani u module kojima se moe upravljati.
Dva koriena pristupa su vertikalno i horizontalno raslojavanje. Vertikalno raslojavanje, nazvano lejering
(layering : layer = sloj) razdvaja softverski sistem u hijerarhijske slojeve. Uglavnom, komunikacija je
dozvoljena samo izmeu susednih slojeva. Horizontalno raslojavanje omoguava konstrukciju modula iz
grupe slojeva. Svaki modul moe dalje biti preraen od strane bilo kog od ova dva koncepta ili njihovom
kombinacijom. Na primer, operativni sistem moe biti vertikalno raslojen na fajl podsistem i podsistem za
kontrolu procesa. Sloj fajl podsistema zaduen za kontrolore ureaja dolazi ispod sloja zaduenog za
obezbeivanje fajl servisa.

Generalno operativni sistem je sainjen iz dva sloja. Donji sloj, tik iznad hardvera, implementira
neophodne funkcije i naziva se kernel (kernel - jezgro). Struktura kernela je esto monolitna, jer je
efikasnost glavna obaveza. Vii sloj implementira funkcije visokog nivoa koje program vidi. On je esto
horizontalno raslojen.
Portabilnost operativnog sistema moe biti podrana deljenjem hardverski zavisnog koda. Hardverski
zavisan deo bi trebao biti minimiziran da bi se smanjili trokovi portabilnosti. Obino su implementirane
sledee funkcije
- multipleksiranje procesora sa multiprogramskom podrkom
- upravljanje prekidima
- drajveri za ureaje
- primitive sinhronizacije procesa
- primitive meuprocesne komunikacije
U distribuiranoj sredini, raunarska komponenta moe imati specijalizovanu funkcionalnost i ne startuje
kompletan operativni sistem ukljuujui sve sistemske servise. Fukcije koje su obino potrebne za svaku
raunarsku komponentu formiraju mikrokernel. Mikrokernel bi trebao biti smeten u sloj zaduen za
obezbeivanje proirivosti aplikacijama visokog nivoa ukljuujui i kompletan standardan operativni
sistem i u sloju hardverske apstrakcije zaduen za portabilnost.

1.4.Mreni operativni sistemi

Raunarska mrea moe biti predstavljena kao labavo povezani sistemi vie raunara gde ne postoji
direktna hardverska ili softverska kontrola jedne maine od strane druge. Generalno, raunari povezani u
raunarsku mreu rade pod razliitim operativnim sistemima. Cilj mrenog operativnog sistema je da
olaka deljenje resursa i razmenu informacija u takvom, verovatno heterogenom, okruenju.
Komunikaciona podmrea koja je odgovorna za razmenu informacija je organizovana hijerarhijski.
Transportni servisi su obezbeeni od mrenog operativnog sistema da bi se olakala komunikacija
izmeu jednakih procesa. Interfejs izmeu aplikacionih procesa i niih slojeva komunikacione podmree
je implementiran u transportnom sloju. API-ji visokog nivoa, kao socket ili RPC (RPC-Remote Procedure
Call), se koriste da olakaju transportni servis. Mrene aplikacije koje podravaju korisniku komunikaciju
i deljenje resursa su implementirani u transportnom servisu. Tipine mrene aplikacije su udaljeni login,
transfer datoteka, slanje i primanje poruka, pretraivanje mree i izvravanje na daljinu.
Funkcije mrenog operativnog sistema, gore opisane, mogu se dodati tradicionalnim operativnim
sistemima njihovim proirenjem.

1.5.Distribuirani operativni sistemi

U sutini ne postoji koordinacija kada umreeni raunari rade pod mrenim operativnim sistemom. Jedini
zahtev je da se potuje komunikacioni protokol. Proirenje deljenja resursa sa optijim formama
koopertaivnih aktivnosti, poput posedovanja jenog meuprocesnog komunikacionog mehanizma, istog
upravljanja procesima, ili isti izgled fajl sistema na svakom umreenom raunaru bi bio sledei logian
korak. Posledica je da se identian kernel izvrava na svim mainama u sistemu. Distribuirani operativni
sistem treba svuda da obezbedi istu jednomainsku sliku umreenih maina .
Kljuno pitanje projektovanja distribuiranh operativnih sistema je koncept transparentnosti. Postoje
nekoliko tipova transparentnosti:
-

lokaciona transparentnost

migraciona transparentnost

replikaciona transparentnost

konkurentna transparentnost

paralelna transparentnost

1.6.Kooperativni nezavisni sistemi

Distribuirani sistem je prirodno okruenje za podrku grupi korisnika koji zajedno rade na heterogenoj
mrei.Ovaj koncept je nazvan raunarski podran kooperativni rad (Computer Supported Co-operative
Work). Ideja o kooperativnim nezavisnim sistemima je proirenje svega toga. Drugim reima, cilj je da se
obezbedi logiki mreni domen grupi korisnika da bi mogli da startuju specifine softverske sisteme
sainjene od nezavisnih delova softvera. Kooperativni nezavisni sistemi treba da olakaju servise za
integraciju nezavisnih aplikacija.
Dok su pravi distribuirani sistemi okarakterisani dekompozicijom servisa izmeu vie raunarskih sistema,
kooperativni nezavisni sistemi se formiraju integracijom servisa.

1.7.Standardizacija
Potreba za kooperativnim nezavisnim sistemima je uslovila nekolko aktivnosti za standardizaciju
distribuiranih raunarskih sistema.

Otvoreno Distribuirano Procesiranje (ODP- Open Distributed Processing)

-

Distribuirano Raunarsko Okruenje (DCE- Distributed Computing Environment)

-

DCE je proizvod fondacije za otvoren softver (OSF). OSF je konzorcijum nekoliko

raunarskih kompanija, ukljuujui IBM, DEC i Hewlett-Pacard, sa ciljem da razviju i naprave
trite za Unix operativni sistem. DCE je integrisan paket softvera i alata za razvojn
distribuiranih aplikacija na postojeim operativnim sistemima, prvenstveno Unix-u. DCE
distribucioni model je baziran na svom RPC RPC (remote procedure call) olakanju i koristi
proceduralno orjentisan distribucioni model. U DCE-u klijent poziva proceduru, koju RPC
mapira sa odgovarjuom funkcijom na serveru.

Common Object Request Broker Architecture ( CORBA )

-

ODP standardizuje OSI komunikacioni sloj. ODP je OSI proirenje koje se odnosi na krajnje
ponaanje sistema. Cilj ODP-a je da omogui razvoj distribuiranih sistema u okruenju
veeg broja prualaca usluga.

CORBA je specifikacija za standard objektno orjentisane arhitekture za aplikacije. CORBA je

definisana od strane Objekt Menadment Grupe (OMG) u vodiu za arhitekturu upravljanja
objektima. Verziju 1.1 ove specifikacije su zajedniki razvili DEC, Hewlett-Pacard, Hyper
Desk Corporation, NCR, Object Design INC., i SunSoft Inc. a pregledana je i prihvaena od
strane svih lanova OMG-a. CORBA distribucioni model je baziran na objektima i koristi
objektno orjentisan distribucioni model. U CORBI klijent alje zahtev posredniku za objektne
zahteve, koji tada upuuje zahtev klijenta serveru koji moe izvriti traeni zadatak.

Distribuirani Komponentno Objektni Model (DCOM - Distributed Components Object Model)

-

DCOM je proirenje Microsoft-ovom Komponentno Objektnom Modelu (COM) da bi se

podrali objekti distribuirani preko mree. COM je otvorena softverska arhitektura od DEC-a i
Microsoft-a, koja dozvoljava meusobnu saradnju ObjectBrocker-a i OLE-a

2.Koncepti distribuiranih sistema

2.1.Koristi od distribuiranih sistema
Primarni cilj
distribuiranih sistema je sposobnost da se efikasnije koriste raunarski resursi. Ovo je omogueno
korienjem sledeih tehnika
-

Deljenje resursa. To moe biti od koristi usled nedovoljnih hardverskih komponenti ili
nedovoljnih podataka.

Rasporeivanje procesorskog opetereenja izmeu vie razliitih maina. To moe

dovesti do znatnog ubrzanja proraunavanja.

Reflektovanje nasleene distributivnosti nekih aplikacija. Na primer meunarodni lanac

hotela. Postoje razdvojeni lokalni racunari ali s vremena na vreme menadment zahteva globalan
pogled.

Poveanje pouzdanosti. Poslovi koji su se izvravali na krahiranoj maini mogu biti

preuzeti od strane druge maine

2.2.Servisi
Da bi se iskoristile mogunosti distrubuiranih sistema, servisi ponueni od strane konvencionalnih
operativnih sistema moraju biti proireni. Postoje dva osnovna pristupa
Prvi, nazvan monolotni kernel, baziran je na centralizovanom operativnom sistemu, npr. UNIX, bez
podrke za mrenu komunikaciju i integraciju udaljenih servisa.
Mikrokernelski pristup je baziran na ideji da se obezbede samo neophodni servisi kernela.
Generalno, ovi servisi spadaju u etiri kategorije meuprocesne komunikacije, primitivnog upravljanja
memorijom, U/I niskog nivoa, i mali deo upravljanja procesa niskog nivoa. Ostali servisi se nalaze
izvan kernela i obezbeeni su od strane sistemskih servera. Neki od tipinih servera su procesni
server, mrezni server, fajl server i autentifikacioni server. Ovi servisi su neophodni za implementaciju
distribuiranih sistema. Dodatni servisi podravaju distribuirane aplikacije i nalaze se na vrhu
sistemskih servisa. Primeri takvih servera su grupni server, mail server i web server.

2.3.Projektni zahtevi
U distribuiranim sistemima je dostupno vie procesora. Kako se procesori koriste, je glavno pitanje
projektovanja. Procesori u distribuiranom sistemu mogu biti organizovani prema modelu radne stanice,
procesorske liste ili njihovom kombinacijom.
Sledei projektni zahtev bavi se osnovnim osobinama distribuiranih sistema. To su transparentnost,
fleksibilnost, pouzdanost i performanse.
Implementacija servisa distribuiranih operativnih sistema je podrana od strane distribuiranih algoritama.
Postoji mnotvo centralizovanih algoritama, korienih od konvencionalnih operativnih sistema ani oni
moraju biti ponovo provereni za distribuirano okruenje. Distribuirani algoritmi treba da uzmu u obzir
sledee karakteristike distribuiranih sistema:
-

nedostatak globalnih informacija

nepostojanje globalnog sata

algoritam treba da je u stanju da rei situaciju kada se izgubi poruka ili krahira maina

2.4.Sistemski modeli
Osnovni model organizacije procesa u distribuiranom sistemu je model radne stanice. Ovaj model se
prosto sastoji od meusobno povezanih radnih stanica. Ako je svaka od ovih radnih stanica komletna
maina sa sposobnou da kontaktira druge maine, blii smo mrenom operativnom sistemu. Druga
mogunost je da su neke maine posveene samo odreenim servisima. Na primer, svim datotekam se
centralizovano upravlja na malom broju fajl servera. Tada se model preciznije naziva model radne stanice
- servera. Nasuprot modelu sa kompletnim mainama, neke radne stanice mogu biti bez diska, i ako se
obavlja udaljeno procesiranje te maine postaju terminali.
Reenje za nezaposlene maine je da se procesori sakupe na jednom mestu i da se dinamiki dodeljuju
korisnicima na osnovu zahteva. Ova organizacija procesora u distribuiranim sistemima naziva se model
procesorske liste. U tom modelu korisnici imaju sliku virtuelne vieprocesorske maine. Umesto radnih
stanica inteligentni terminali (poput X terminala) su na raspolaganju korisnicima da pristupe sistemu.
Dva pristupa, model radne stanice i model procesorske liste mogu biti kombinovani.
Osnovni nain njihovog kombinovanja je da se model radne stanice proiri procesorskom listom. U tom
hibridnom modelu korisnici mogu obavljati interaktivan rad na radnim stanicama, i da zahtevaju dodatnu
procesorsku snagu iz procesorske liste za komplikovane proraune.
Takoe je mogue da se procesori radnih stanica posmatraju kao oblik procesorske liste ako sistem
poseduje efikasnu implementaciju migracije procesa.

2.5.Transparentnost
Transparentnost zaklanja fiziku podeljenost objekata, njihovo upravljanje u distribuiranim sistemima, od
njihovih korisnika. U isto vreme koncept transparentnosti kreira eljenu sliku sistema. Kompletna
transparentnost je ekstremna. Ona nije uvek poeljna. Korisnik koji eli da odtampa dokument vie bi
voleo da saeka da lokalni zauzeti tampa zavri posao nego da tampa na 100 kilometara udaljenom
slobodnom tampau.
Postoji nekoliko tipova transparentnosti u distribuiranom sistemu
-

Lokaciona transparentnost znai da korisnici nisu svesni gde se objekti nalaze.

Objektima se pristupa preko njihovih logikih imena. Oni ne moraju da sadre informaciju gde se
objekti nalaze

Migraciona transparentnost znai da se objektima pristupa preko njihovih logikih

imena ak i ako se oni prebace na drugu fiziku lokaciju bez menjanja njihovog logikog imena.

Replikaciona transparentnost znai da korisnici nisu svesni postojanja viestrukih

kopija objekata u sistemu.
Konkurentna transparentnost znai da korisnici ne smetaju jedan drugom ako dele

objekte
-

Paralelna transparentnost omoguava paralelne aktivnosti bez znanja korisnika

2.6.Fleksibilnost
Fleksibilnost je jedan od glavnih projektnih zahteva u distribuiranim sistemima, zato to trebamo da
oekujemo razvoj novih tehnologija u budunosti koje moraju da budu ukljuene u trenutno projektovane
sisteme. Drugi razlog je mogua potreba za poboljanjem distribuiranih sistema, ak i sa heterogenim
komponentama. Drugim reima moramo da oslikamo mogunost da se sistem razvija u vremenu i
prostoru.
Koncept fleksibilnosti ukljuuje osobine poput modularnosti, skalabilnosti, portabilnosti i meusaradnje.

2.7.Pouzdanost

Pouzdanost je oigledno bitniji zahtev u distribuiranim sistemima nego u centralizovanim, zbog njihove
visoke kompleksnosti i geografske distribucije.
Moe se desiti da korisnicima bude onemoguen rad zbog kvarova na komunikacionim linkovima ili
udaljenim serverima. U sluaju kad je mnogo resursa potrebno da bi se izvrio zadatak, krajnja
pouzdanost je proizvod pouzdanosti komponenti.Ovo ini kvarove u distribuiranim sistemima eim, jer
je traeni servis dostupan samo ako sve komponente funkcioniu. Sa druge strane mogue je
organizovati distribuirani sistem tako da ako jedna komponenta otkae druga preuzima njene poslove.
Ova ideja poveava pouzdanost jer je servis dostupan ako bar jedna komponenta radi. Pouzdanost ima
vie aspekata. Upravo smo raspravljani o jednom koji je nazvan dostupnost.
Povrh toga, ako servise obezbeuje grupa kooperatvnih servera, i ako servis nastavlja da bude dostupan
kada jedan ili dva servera budu izgubljeni zbog nekog pada performansi sistem je otporan na greke.
Otpornost na greke je jo jedan aspekt pouzdanosti.
Dok su kvarovi na komponentama u distribuiranim sistemima nenamerni, namerni upadi, ako je
bezbednost naruena mogu izazvati ozbiljne tete. Bezbednost je novi vaan aspekt pouzdanosti.

2.8.Performanse
Posedovanje transparentnog, fleksibilnog distribuiranog sistema, sa estim preoptereenjima sistema,
gde se aplikacije sporo izvravaju bilo bi beskorisno. Nasuprot tome performanse bi trebal biti bolje ili bar
jednake izvravanju iste aplikacije na centralizovanom sistemu.
Poboljanje performansi deljenjem posla meu vie procesora zahteva slanje poruka. Poput toga,
koordinacija nekoliko servera, koja obezbeuje pouzdane servise, zahteva razmenu informacija.
Komunikaciona zadrka je injenica koja je neizbena u distribuiranim sistemima. Zbog toga
komunikacioni sistem, ukljuujui komunikacione primitive i komunikacione protokole mora biti paljivo
projektovani.

2.9.Distribuirani algoritmi
Generalno uzevi algoritmi korieni u centralizovanim sistemima ne mogu biti direktno korieni u
distribuiranim sistemima. Sledee injenice se moraju uzeti u obzir:

Na razliitim vorovima je nepotpuna i nedosledna slika sistema, zbog nepostojanja deljene memorije
i komunikacionih zadrki. Koordinacija izmeu procesa na razliitim vorovima se postie slanjem
poruka.

Ne postoji globalan sat. ak i ako postoji centralni sat u distribuiranom sistemu, vremensko kanjenje
prenoenja vremenske informacije razliitim vorovima e se razlikovati i moe varirati, na primer u
zavisnosti od mrenog saobraaja.

Distribuirani sistemi mogu imati menjajuu topologiju, na primer zbog povezivanja novog vora.
Kvarovi na komunikacionim linkovima i vorovima moe takoe izmeniti topologiju

U zavisnosti od upravljanja kontrolom, distribuirani algoritmi mogu biti potpuno centralizovani ili
decentralizovani. Kasnije, ako centalizovani kontroler doivi kvar, algoritam mora biti u stanju da ga
oporavi.

3.Konkurentni procesi i programiranje

3.1.Konkurentni procesi
Procesi su sekvencijalni programi koji se izvravaju. Sekvencijalni procesi imaju jednu nit kontrole
izvrenja i adresni prostor.
Konkurentni procesi su sekvencijalni procesi koji se simultano izvravaju. Svaki od tih procesa ima svoj
adresni prostor i oni su asinhroni. Neki od konkurentnih procesa se mogu razdvojiti i izvriti konkurentno.
Ostalima moe biti potrebna koordinacija u obliku komunikacije ili sinhronizacije.
U nekim situacijama, raunanje mora biti podeljeno u viestruke kontrolne niti koje dele iste podatke. To
dovodi do sjedinjavanja viestrukih kontrolnih niti (treads), prosto nazvanih niti, ili sitnih procesa, koji se
izvravaju u deljenom adresnom prostoru. Na taj nain drugi nivo konkurentnosti se formira konkurentnim
izvravanjem niti u procesu.

3.2. Korienje niti

Otkrie niti dozvoljava kombinovanje sekvencijelnih procesa, paralelno izvravanje i blokiranje procesa.
Tipian primer njihovog korienja su serveri, poput terminal ili fajl servera
Serverski procesi su potrebni da bi se dobili slini servisi za vie klijenata. Klijenti mogu zahtevati te
servise paralelno. Ako serverski proces ima jednu kontrolnu nit i trenutno je suspendovan ekajui neki
dogaaj, zahtevi ostalih klijenta ne mogu biti obraeni i procesi klijenata su blokirani. Kreiranjem niti za
svaki zahtev omoguava da se procesi klijenata ne blokiraju, ako je zahtevani proces suspendovan i niti u
serverskim procesima mogu deliti uobiajne podatke. Serverski proces obrauje zahteve klijenata
konkurentno, ali se svaka nit izvrava sekvencijalno.
Postoje dva osnovna pristupa implementaciji niti: u prostoru korisnikog programa i u kernelu.
Kombinacija ova dva pristupa je takoe mogua.

3.2.1 Implementacija niti u prostoru korisnikog programa

Vienitni procesi su u potpunosti u prostoru korisnikog programa, i oni operativnom sistemu izgledaju
kao obian jednonitni proces. Operatvini sistem dodeljuje procesorsko vreme procesu na uobiajen
nain.Taj dodeljeni vremenski period je razdeljen meu nitima u procesu.
Niti se izvravaju preko izvrne biblioteke, koja je kolekcija procedura koje upravljaju izvravanjem niti.
Kad nit koja se izvrava napravi blokirajui sistemski poziv, ona poziva izvrnu proceduru, koja snima
registre niti iz koje je pozvana (programski broja, registar, pokaziva na stek), odabira nit spremnu za
izvravanje i uitava vrednosti koje su uskladitene u niti u registre. Efektivno se ne pojavljuje blokiranje
procesa, izvravanje procesa se nastavlja izvravanjem odabrane niti. Menjanje niti na ovaj nain
zahteva veoma malo dodatnog optereenja.
Rasporeivanje niti se obavlja podrkom izvrnog sistema, i uglavnom je neprekidno, zbog nedostatka
vremenskih prekida u okviru procesa. To zani da ako nit pone da se izvrava, ona se izvrava dok ne
bude blokirana.

3.2.2 Implementacija niti u kernelu

Niti se stvarju i unitavaju pozivima kernela i kernel ih stvara i unitava. Niti su tretirane kao jednonitni
procesi. Kada se nit blokira kernel moe odabrati da pokrene novu nit iz istog procesa ili nit iz nekog
drugog procesa. Poto niti rasporeuje kernel, dozvoljeno je rasporeivanje sa izbacivanjem. Nizak
troak menjanja niti je izbaen.
Kombinacija implementacije u prostoru korisnikog programa i kernelu (npr. Sun-ov Solaris) zadrava
prednosti oba pristupa. Na primer na Solarisu postoji srednji nivo niti nazvan jednostavniji proces (light
weight proces), koji slue kao veza izmeu niti kernela i korisnikih niti. Light weight procese kreiraju
korisniki procesi. Korisnikie niti su razdeljene light weight procesima, a light weight procesi su razdeljeni
na procese kernela, formirajui tri nivoa konkurentnosti. Tada blokirajui poziv korisnikog procesa moe

blokirati povezani light weight proces, ali korisniki proces moe nastaviti izvravanje izvrenjem niti
povezane sa drugim light weight procesom u istom korisnikom procesu. Rasporeivanje korisnikih niti
sa izbacivanjem je mogue jer light weight procesi mogu biti izbaeni od strane kernela.

3.3 Klijent - Server model

Ideja ovog modela je da se napravi kooperacija procesa izmeu servera koji obezbeuju servise i
klijenata koji servise zahtevaju. Ova paradigma se koristi na nivou aplikacije podjednako kao i na nivou
operativnog sistema. Svaki proces u interakciji igra ili ulogu servera ili ulogu klijenta. Sa druge strane,
proces koji se ponaa kao server moe zahtevati servis od drugog servera da bi izvrio neki zadatak,
time dobijauji i ulogu klijenta. Maina moe biti jedan klijent, jedan server, vie klijenata ili servera ili
meavina klijenata i servera.
Logika komunikacija izmeu klijenata i servera je bazirana na razmeni zahteva i odgovora:
-

Klijent alje zahtev serveru i blokira se

Server prima zahtev, obavlja traeni posao, i vraa odgovor klijentu.

Klijent prima odgovor i nastavlja izvravanje

Fiziki, zahtevi i odgovori se prosleuju dotinom kernelu, i alju kroz komunikacionu mreu ciljnim
kernelima i procesima. Iz jednostavnosti ovog modela proizilazi potreba za samo dva komunikaciona
sistemska poziva kernelu: send (poalji) i receive (primi) poruku.
Vano pitanje je kako klijent locira server ako on promeni lokaciju ili postoji vie servera. Zbog
fleksibilnosti serveri se identifikuju preko imena. Serveri, nazvani vezujui serveri (binder servers) spajaju
klijente i servere. Procedura koja izvrava ovo spajanje je nazvana dinamiko povezivanje (dynamic
binding). Kada se server startuje, on alje povezivau podatke o svojoj lokaciji. Tada klijenti preko
povezivaa znaju lokaciju odgovarajueg servera. Kao dodatak, poveziva moe pomagati u
autentifikaciji klijenata za servere.

3.4 Vreme u distribuiranim sistemima

Vreme ima bitnu ulogu u raunarskim sistemima. Na primer, procesi su rasporeeni za izvravanje,
odrava se vreme pristupa fajlovima, isteci vremena se koriste u drajverima za ureaje, dogaaji, poput
backup-a sistema u pono su raporeeni. U centralizovanom sistemu, vremenski servisi su dati od strane
kernela, koji koristi prekide hardverskog sata. Na taj nain svi softverski zahtevi za vremenom,
vremenska taka ili vremenski interval, su zadovoljeni od istog izvora. tavie, ako je tano podeeno,
sistemsko vreme je priblino jednako realnom vremenu.
U distribuiranim sistemi se sreemo sa potpuno razliitom situacijom. Svaka maina poseduje svoj sat, i
nemogue je garantovati identinu brzinu svakog od njih. Postoji nepredvidivo propagaciono kanjenje
prilikom obavetavanja o vrednosti sata u distribuiranim sistemima. Zbog toga je nemogue saznati
globalno fiziko vreme.
Rasporeivanje dogaaja bi trebalo da bude bazirano na fizikom vremenu nihovog pojavljivanja. Zbog
nedostatka globalnog fizikog vremena ta metoda je nedostupna. Koncept rasporeivanja dogaaja koji
se koristi u distribuiranim sistemima je bez globalnog fizikog sata, i zove se logiki sat.

3.4.1 Logiki sat

Dogaaji u istom procesu su rasporeeni redosledom pojavljivanja. Dodeljujemo logiki sat svakom
procesu, pa ako se dogaaj a pojavi pre dogaaja b tada logiki satovi C(a) i C(b) zadovoljavaju relaciju
C(a) < C(b). Prosto gledano logiki sat je celobrojni broja koji se uvea svaki put kada nastupi dogaaj.
Sinhronizacija logikih satova se bazira na interakciji procesa slanjem poruka. S obzirom da se slanje
poruke u jednom procesu pojavljuje pre primanja te poruke u drugom procesu, moemo oekivati da
odgovarajui logiki satovi slanja i primanja zadovoljavaju relaciju C(slanje) < C(primanje). To je
osigurano ako proces koji alje doda poruci vrednost svog logikog sata, nazvanu marker vremena
(timestamp) i proces koji prima postavlja svoj logiki sat na veu vrednost izmeu svog sata i uveane
vrednosti markera vremena.

S obzirom da je relacija pojavilo se ranije, koja se tako zove desilo se ranije, tranzitivna, dodeljivanje
vrednosti logikom satu na ovaj nain odrava relaciju izmeu vremena pojavljivanja bilo koja dva
dogaaja koji sluajno utiu jedan na drugi, kao to je gore opisano. Zbog toga je uvedena totalna
ureenost izmeu takvih sluajno povezanih dogaaja.
Sa druge strane, mogu postojati dogaaji u razliitim procesima koji se mogu pojaviti pre, posle, ili
paralelno jedan sa drugim, npr dogaaji koji se pojave izmeu dve uzastopne razmene poruka u dva
procesa. Za takve dogaaje se kae da su razdvojeni ili konkurentni. Jasno je da je skup svih dogaaja
samo parcijano ureen.
Nekim distribuiranim algoritmima je potrebna potpuna ureenost svih dogaaja. To se moe reiti
dodavanjem jedinstvene vrednosti procesa u kome je dogaaj nastupio, na logiki sat dogaeja. Ako se
desi da dva dogaaja u razlitim procesima imaju isti marker vremena, prednost odreuje nii broj
procesa.
Ako su Ci(a) i Cj(b) vrednosti logikog sata dogaaja u procesima Pi i Pj , generalno se ne moe odrediti
da li je dogaaj a nastupio pre dogaaja b ako je Ci(a) < Cj(b) jer mogu biti konkurentni. Tu situaciju
reava vektorski logiki sat. Vektorski logiki sat dogaaja a u procesu Pi je vektor [TS1, TS2, ...,
Ci(a), ..., TSn] gde je n broj procesa, TSk, k=1, ...,n, ki je posladnja znana vrednost logikog sata za
proces Pk, dobijena kao vremenska marka razmenom poruka, a Ci(a) takoe oznaava TSi, vrednost
logikog sata dogaaja u procesu Pi.
Svaki proces inicijalizuje svoj vektorski sat na prazan vektor na poetku izvravanja. Vektorskim satom
dogaaja u istom procesu se pristupa kao skalarnom satu. Kada proces Pi poalje poruku (dogaaj a),
negov vektorski sat VCi(a) se doda poruci. Prihvatajui proces Pj postavlja svoj vektorski sat VCj(b) po
prijemu te poruke (dogaaj b) takav da je TSk(b), kj ureeni par najveih vrednosti prispelog
vektorskog sata VCi(a) i sopstvenog vektorskog sata, i uveava svoj logiki sat Cj.
Jasno je da ako se dogaaj a u Pi pojavi pre nego dogaaj b u Pj tada je TSk(a)TSk(b), k=1, ..., n,
kj i TSk(a)<TSk(b), to smo izrazili sa VCi(a)<VCj(b). Konkurentni dogaaji c u Pi i d u Pj ne mogu
nikad zadovoljiti VCi(c)<VCj(d) ili VCi(a)>VCj(d).

3.4.2 Fiziki sat

Tano vreme se uglavnom obezbeuje iz spoljanjih izvora Univrzalno Koordinisanog Vremena, skraeno
UTC, preko kratkotalasnih radio stanica, zemaljskih satelita ili kablovskih TV kanla. Ovim izvorima se
pristupa preko servera vremena koji auriraju najskorije podatke o satu. Klijentima su potrebni serveri
vremena zbog informacija o realnom vremenu.
Postoji propagacino kanjenje signala prilikom zahtevanja UTC od servera vremena i njegovog
odailjanja klijentima. Povrh toga postoji mreno komunikaciono kanjenje. Ta kanjenja moraju biti
kompenzovana. Propagaciono kanjenje signala se moe kompenzovati korienjem tehnikih sredstava.
Mreno kanjenje varira i uglavnom je vee nego propagaviono kanjenje. Klijent moe izmeriti vreme T1
od slanja zahteva serveru vremena i vreme T2 primanja odgovora sa UTC. Ako je poznato vreme obrade
zahteva t , tada je konano mreno kanjenje T2-T1-t. Pod pretpostavkom da je komunikacija izmeu
klijenta i stervera simetrina, UTC koji alje server mora biti ispravljena dodavanjem polovine mrenog
kanjenja.
U sistemu, servisi vremena mogu biti obezbeeni od strane vie servera. Tada razlike meu njima moraju
biti usklaene. Serveri mogu odailjati UTC periodino, i postizati koncenzus korienjem dogovorenog
kriterijuma. Kriterijum moe koristiti najveu, najmanju, srednju ili prosenu vrednost UTC-ova pokupljenih
sa servera. Statistiki indikator nazvan interval poverenja se moe koristiti da izmeri preciznost razliitih
UTC izvora.

3.5 Konkurentno programiranje

Jezik za konkurentno programiranje treba da obezbedi:
-

specifikaciju konkurentnih aktivnosti

sinhronizaciju procesa

meuprocesnu komunikaciju.

Konkurentne odvijanje aktivnosti ukljuuje nedeterministiko izvravanje procesa.

Sinhronizacija procesa je razvijena za sinhronizaciju konkurentnih procesa u centralizovanim operativnim
sistemima. Koncept deljenih promenjivih je korien za sinhronizaciju procesa, kao i za meuprocesnu
komunikaciju. Standardne metode sinhronizacije deljenih promenjivih su sledee
-

semafor

kritini region

uslovni kritini region

monitor

serijalizator (mogunost pohranjivanja podataka)

izraz putanje

Kad se distribuirani sistemi uzmu u obzir, novi zadatak je procesna komunikacija preko slanja poruka.
Slanje poruka takoe ukljuuje implicitnu sinhronizaciju zato to poruka ne moe biti primljena pre nego
to je poslata.
Centalizovane metode su jo uvek korisne u distribuiranim sistemima. Niti koriste deljenu memoriju i
sinhronizacione metode deljenih promenjivih. Ponekad je poeljno simulirati sinhronizaciju deljenih
promenjivih slanjem poruka.

3.6 Sinhronizacija slanja poruka

Slanje poruka je bazirano na dva komunikaciona servisa
-

slanje poruke

primanje poruke

Odgovarajue send i receive primitive mogu biti blokirajue ili neblokirajue. Ako je komunikaciona
primitiva neblokirajua kontrola se odmah vraa pozivaocu i proces pozivaoc moe da nastavi da se
izvrava paralelno sa primitivom. Postavlja se pitanje kako proces pozivaoc zna kad je slanje ili primanje
zavreno. To je bitnije za receive primitivu. Dodavanje wait primitive koja dozvoljava primaocu da se
blokira kad je potrebno jedno je od reenja.
Za veinu aplikacija, divoljno je pretpostaviti da je raceive blokiraje a send moe biti blokirajue i
neblokirajue. Neblokirajue send i blokirajue receive se naziva asinhrono slanje poruka, a blokirajui
send i receive sinhrono.
Asinhrono slanje poruka pretpostavlja deljeni komunikacioni kanal koji poseduje potencijalno slobodan
bafer. Asinhrono slanje poruka se moe posmatrati kao proirenje koncepta semafora. Primeri asinhronog
slanja poruka su pipe i socket
Sinhrono slanje poruka znai ekanje procesa dok se odgovarajua operacija ne pojavi. To znai da send
mora saekati da se odgovarajui receive pojavi i obratno. Taj mehanizam sinhronizaciije se naziva
sastanak (randevu). Ovaj oblik ulazno/izlaznog (send/receive) satanka je obezbeen od strane
Komunikacionog Sekvencijalnog Procesa (CSP). CSP sastanak obezbeuje blokiranje i prostu razmenu
podataka izmeu poiljaoca i primaoca. Poziv udaljene procedure (RPC) je proirenje sinhronog slanja
poruka u kome je pozivaoc blokiran dok se pozvana procedura ne izvri i rezultat prosledi pozivaocu.
RPC je komunikacija izmeu klijenta i servera. Serveri su implementirani preko seta procedura koje mogu
biti pozvane od strane udaljenih klijenata. Serveri u RPC-u ekaju da budu pozvani od strane klijenata.
Sa druge strane serveri u sastanku pokuavaju da prihvate zahteve klijenata. Primer ovog koncepta je
Ada sastanak. Procedure eksplicitno izraavaju spremnost da prihvate pozivaoca.

4.MEUPROCESNA KOMUNIKACIJA

4.1.Meuprocesna komunikacija
Prenoenje poruka je jedini metod razmene podataka u distribuiranim sistemima.
Prenoenje poruka je najnii nivo procesne komunikacije na aplikacionom nivou. Vii nivoi komunikacije
izmeu procesa, zasnovani na komunikaciji prenosenjem poruka, su upit/odgovor komunikacija i
transakciona komunikacija.
Komunikacija upit/odgovor podrava model klijent/server. Ovaj nivo se moe implementirati kao RPC
(Remote Procedure Call )
Atomske sekvence komunikacija upit/odgovor formiraju transakcije. One slue kao osnovne jedinice za
komunikaciju za aplikacije kao to su sistemi baza podataka.
Kada se zahteva tradicionalan, centralizovani koncept deljene memorije, na primer zbog jednostavnosti
programiranja, logiki podeljena memorija se moe simulirati prenoenjem poruka.

4.2.Komunikacija prenoenjem poruka

Poruke se sastoje od sistemsko zavisnih kontrolnih informacija i tela fiksne ili promenjljive veliine koje
sadri objekte podataka koje su definisali istovetni aplikacioni procesi. Sastavljene poruke se prosleuju
do transportnog servisa, koji obezbeuje njihovu isporuku. Interfejs transportnog servisa su
komunikacione osnove send (slanje) i recive (prijem).
Opte osnove komunikacije prenoenjem poruke mogu se izraziti u sledeoj formi:
-

send (destinacija, poruka)

receive (izvor, poruka).

Komunikacioni procesi specificiraju drugog uesnika komunikacije i poslatu ili primljenu poruku. Postoji
pitanje kako se komunikacioni entiteti adresiraju. Obino se koriste opcije:
-

naziv procesa

link

mailbox

port

Korienje naziva procesa (tj. idetifikatori globalnih procesa su jedinstveno sainjeni od niza identifikatora
procesa sa internet adresom domaina) obezbeuje jednu direktnu komunikacionu putanju izmeu bilo
kog para komunikacionih procesa. Kada se odgovarajui procesi, koji alju i primaju poruke, moraju
imenovati meusobno, tada je shema adresiranja simetrina. Potreba za imenovanjem drugog
komunikacionog entiteta bi zahtevala da server eksplicitno imenuje sve mogue klijente. Primanje poruka
iz nepoznatih izvora bi bila pogodnija shema. U ovom sluaju, parametar izvora receive osnove je ulazna
varijabla kojoj se dodeljuje vrednost identifikatora procesa koji je poslao poruku. Ovakva shema
adresiranja je asimetrina.
Sheme adresiranja putem naziva procesa obezbeuju komunikacione procese sa dvosmernom
komunikacionom putanjom. Da bi omoguili viestruke komunikacione putanje izmeu procesa, moramo
identifikovati komunikacione putanje u komunikacionim osnovama. Ovaj zahtev vodi do koncepta linkova,
slinom konceptu virtualnih kola u mrei raunara. Linkovima se upravlja logiki i oni su jednosmerne
komunikacione putanje.
Nazivi procesa i brojevi linkova su direktne sheme adresiranja. Ponekad je, proces koji alje poruku
zainteresovan samo za prijem poslate poruke i obrnuto, proces koji prima poruku je zainteresovan samo
za poruku kao takvu, dok identitet procesa koji alje poruku moe biti sadran u njoj. Viestruki klijenti koji

zahtevaju servise od nekih viestrukih servera je pogodan primer. Reenje je u korienju mailbox-a. Oni
omoguavaju komunikaciju vie sa vie i viestrukih putanja.
Port se moe posmatrati kao specijalan sluaj mailbox-a, koji omoguava komunikaciju vie sa jednim.
Poruke se smetaju u red koji je po principu redosleda pristizanja (first-came-first-served).
Mailbox i portovi su posredne komunikacione sheme.

4.3 Sinhronizacija i prihvatanje poruka

Kada se poruka prenosi izmeu procesa, poruka koja se alje se uzastopno prosleuje do jezgra
poiljaoca, mree komunikacije, jezgra primaoca i konano do procesa primaoca poruke. Postoje pet
opcija kada se sa send moe osloboditi proces koji alje poruku i gde je sinhronizacija transfera poruke
potrebna. Ti primeri su sledei:

kada je poruka isporuena jezgru poiljaoca

kada jezgro poiljaoca prenese poruku u komunikacionu mreu

kada poruku primi jezgro primaoca

kada je poruka isporuena prijemnom procesu

kada je primalac obradio poruku i vratio odgovor poiljaocu

Prva opcija se zove asinhroni send, obzirom da proces poiljaoc nastavlja svoje izvrenje asinhrono sa
transferom poruke, odmah nakon to je poruka kopirana u jezgro poiljaoca. Preostale opcije se nazivaju
sinhroni send. Poslednja se eksplicitno naziva komunikacija klijent-server.
Baferi se koriste da ublae raskorak izmeu brzina obrade podataka komponenata koje realizuju prenos
poruke. Poruka je zatim sadrana u baferu jezgra poiljaoca, baferu komunikacione mree i baferu jezgra
primaoca. Moemo posmatrati kombinaciju ovih bafera kao jedan globalni logiki bafer. Ukoliko je veliina
ovog bafera neograniena, asinhroni send nikada ne blokira. U suprotnom, ako komponente koje
realizuju prenos poruke imaju bafere manjih veliina nego to je to potrebno, poiljalac i primalac moraju
biti sinhronizovani. To je randevu koncept

4.4 Pipe i socket APIs

U prkos raznovrsnosti primitiva prenosa podataka, korisniki programi su u vezi sa interfejsima korisnikih
programa (application program interfaces- APIs), koji su nezavisni od postojee komunikacione platforme.
Postoje dva API-a koja se koriste i u Unix i u Windows okruenju, a to su pipe i socket.
Pipe je realizacija klasinog proizvoa-potroa problema. Kada se koristi od strane dva komunikaciona
procesa, jedan proces zapisuje podatke na rep (kraj), a drugi proces ita podatke sa glave (poetak)
pipe-a. Pipe je implementiran pomou FIFO toka bajtova konane veliine, koji obezbeuje jednosmerni
komunikacioni link.
Proces kreira pipe koristei pipe sistemski poziv, koji vraa dva pipe deskriptora, jedan koji predstavlja
glavu za itanje, i drugi koji predstavlja rep za pisanje po pipe-u. Proces se rava na procese naslednike.
Kraj itanja je odreen roditelj procesom, a kraj pisanja dete procesom. Sada je jednosmerni
komunikacioni kanal izmeu roditelja i deteta ostvaren.
Da bi se uskladili sa bit orjentisanim Unix sistemom, podaci u pipe-u nisu interpretirani. Ako se ele
strukture podataka u komunikacionom kanalu, ovaj koncept se proiruje da obuhvati poruke. Ovaj tip
meuprocesne komunikacije API se naziva message queue. Uobiajeno, komunikacioni procesi
egzistiraju istovremeno.
U sluaju razdvojenih procesa, pipe deskriptori nisu nasledivi i ne mogu se deliti. Jedno reenje je u
korienju specijalnog FIFO fajla koji je jedinstveno definisan nazivom putanje za pipe implementaciju.
Pipe sa pipe nazivom se naziva imenovan pipe (izuzev Windows platforme) i koristi uobiajenu fajl
semantiku. Komunikacioni procesi ne moraju postojati istovremeno.

Upotreba pipe-a i imenovanog pipe-a je ograniena u zavisnosti od situacije gde se strukture podataka ili
jedinstveno imenovani fajlovi (obini sistem fajlovi) mogu deliti. Da bi se obezbedile uobiajene metode
za meuprocesnu komunikaciju i dozvolila upotreba mrenog protokola, potrebno je izvrenje
interprocesne komunikacije APIs na vrhu prenosnog nivoa. Za ilustraciju ovog koncepta koristiemo
najrasprostranjeniji mehanizam, poznat kao Berkley sockets. Dve krajnje take komunikacionog kanala
su socketi, i oni su obezbeeni od strane dva komunikaciona procesa. Par socket-a ostvaruje dvosmerni
komunikacioni link.
Socket se kreira izdavanjem socket sistemskog poziva koji vraa socket deskriptor. Parametri socket
sistemskog poziva su:

komunikacioni domen u okviru koga socketi dele komunikacione pogodnosti, kao to su imenovani i
upotrebljeni komunikacioni niz (na primer: Unix ili Internet domen)

tip socketa ukazuje na tip komunikacije koja se ostvaruje preko socketa (na pr. datagram ili virtuelno
kolo, stream u Berkley-evoj terminologiji)

protokol ukazuje na protokol koji se koristi u komunikaciji (na primer TCP ili UDP)

Socket deskriptor je lokalni za proces koji je izdao odgovarajui socket sistemski poziv. Bind sistemski
poziv daje ime socket deskriptoru, na primer, adresa mree domaina i port koje specificira korisnik ili
lokalno generisane od strane prenosnog servisa za Internet domen. Za Unix domen, asocirani naziv je
naziv fajla u lokalnom sistemu fajlova. Kada su procesi koristili sockete i bind sistemske pozive, mogu
izvoditi komunikaciju bez konekcije koristei datagram socketa pomou sendto/recvfrom socket poziva.
Parametri sendto/recvfrom socket poziva sadre deskriptore lokalnih socketa i poruku. Obzirom da je
komunikacija bez konekcije, adresa destinacije u sendto i adresa izvora u recvfrom moraju biti
specificirane u dodatnom parametru.
Eksplicitna specifikacija adresa destinacija i izvora u send/receive pozivima se moe izbei korienjem
connect socket poziva. Connect socket poziv vezuje deskriptor lokalnog socketa sa nazivom deskriptora
udaljenog socketa i ostvaruje vezu za sockete virtualnih kola. Nakon connect operacije, podaci se mogu
prenositi send/recv sistemskim pozivom bez navoenja udaljenog socketa. Slino, proces moe koristiti
read/write socket sistemske pozive za sockete virtualnih kola umesto send/recv.
U sluaju klijent-server komunikacije, oekuje se da server ima dobro poznatu adresu servisa. Server e
morati da komunicira sa vie klijenata ija su imena nepoznata. Za ostvarivanje veze, server izdaje
accept poziv, koji se sastaje sa connect pozivom klijenta. Listen sistemski poziv se izdaje da bi pokazao
spremnost za prihvatanje konekcija i navodi maksimalan broj neispunjenih zahteva koji je dozvoljen da
se nakupi u jezgru. Accept pozivi se sastaju sa nizom connect poziva i vraaju novi socket deskriptor.
Server e koristiti novi socket deskriptor za komunikaciju sa konektovanim klijentom i nastavie sa
oslukivanjem na dobro poznatoj adresi. Proces servera se moe ravati na procese naslednike za svaku
vezu koristei novi socket deskriptor.

4.5.Zatitni sloj socketa

SSL Handshake protokol

randomC sluajno izabran broj koji se koristi za konano izraunavanje mastersecret-a

CipherSuites lista kriptografskih opcija oko kojih treba da se pregovara sa serverom

pre-masersecret ifrovan od strane serverovog privremenog javnog kljua

mastersecret izveden iz randomC, randomS i pre-mastersecret pomou primene jednosmerne

hash funkcije; mastersecret sadri write klju i MAC ifru
Finished poruke koje se koriste za verifikaciju kljua razmene i autentinosti.

Record Layer protokol

sve socket poruke su ifrovane odgovarujuim ifra algoritmom i tajnim write kljuem

svaka poruka sadri proveru autentinosti poruke koju je stvorila hashing poruka sa MAC ifrom

4.6.Komunikacija grupe i multiprenos(multicast)

Pojam grupe je bitan za razvoj kooperativnog softvera u distribuiranim i autonomnim sistemima.
Upravljanje grupama procesa zahteva efikasan nain slanja poruke lanovima grupe.
Postoje dva tipa scenarija primene multiprenosa:

Klijent eli da trai uslugu od bilo kog servisa svih lanova grupe best-effort multicast; sistem
samo treba da garantuje isporuku multicast poruke do dostupnog ispravnog procesa

Klijent treba da trai servis od svih lanova grupe servera - reliable multicast; multicast treba da
prime ili svi serveri ili ni jedan (sdri potrebu za privremeno uvanje poruka)

Problemi kod pouzdanog multikasta (reliable multicast):

o

otkazi prijemnih procesa

otkazi zaetnika

zahtev za prenos poruke

4.6.1 Ureivanje multiprenosa

Multiprenos redosledi u rastuem poretku striktnosti:

FIFO poredak: Multiprenosne poruke iz jednog izvora su isporuene u redosledu u kome su bile
poslate. Ovaj tip poretka je lako implementirati korienjem rednih brojeva.

Uzroni poredak: Uzrono povezane poruke iz viestrukih izvora su isporuene u svom

uzronom poretku. Dve poruke su uzrono povezane ako je jedna poruka izazvana nakon prijema
druge; uzronost moe povezati nekoliko lanova u grupi pravcem prelaznosti uzronih odnosa.

Potpuni poredak: Svi multiprenosi poruka ka grupi su isporueni svim lanovima grupe u istom
poretku. Pouzdani potpuno ureeni multiprenos se naziva atomic multicast.

4.6.2 Uzrono ureen multiprenos

Implementacija uzrono ureenog multiprenosa:

izraavanje rednog broja vektorom rednih brojeva, S = (S1, S2, , Sn). Svaki Sk predstavlja broj
poruka do sada primnjenih od lana grupe k. Kada lan i viestruko prenosi novu poruku m, on
inkrementira Si za 1 i vezuje vektor S za m. Kada primi poruku m sa rednim vektorom T=(T1, T2,
,Tn) od lana i, lan j prihvata ili odlae dostavu poruke m prema sledeim pravilima:
o

Prihvati poruku m ako je Ti=Si+1 i Tk Sk za sva k i.

Odloi poruku ako je Ti>Si+1 ili postoji kakvo k i da je Tk>Sk.

Odbaci poruku sko je Tii Si.

Protokol uzronog poretka simulira multiprenos u zatvorenoj grupi, i multiprenosi ne mogu spojiti
grupe.

4.6.3 Atomski multiprenos

Implementacija: dve faze, multiprenos potpunog poretka.
1.

Faza: Tvorac poruka emituje poruke i prikuplja potvrde sa logikim vremenskim rokom od svih
lanova grupe.

2.

Faza: Nakon to su sve potvrde prikupljene, tvorac alje commitment poruku koja nosi najvei
vremenski rok potvrde kao logiku vezu za angaovanje. lanovi grupe tada odluuju da li
angaovana poruka treba biti smetena ili isporuena bazirajui se na globalnim logikim
vremenima angaovanja multiprenosnih poruka.

4.7 Komunikacija upit/odgovor

Komunikacija upit/odgovor je servisno orjentisana i predstavlja sledei nivo komunikacije u

odnosu na prenoenje poruka.

Komunikacija upit/odgovor koja se najee koristi je daljinsko pozivanje procedura (Remote

Procedure Call- RPC), koji predstavlja jeziku apstrakciju mehanizma upit/odgovor. RPC je
istovetan lokalnom pozivu procedure, ali ima razliitu semantiku (zadravanja, prekidi u mrenoj
komunikaciji). RPC je jednostavan i elegantan nain postizanja transparentne komunikacije
pomou omota sistemskih poziva niskog nivoa, konverzije podataka i mrene komunikacije.

Primeri RPC:
o

SUN-RPC (SunSoft)

DCE-RPC (Open Group)

4.7.1 Parametar prenosa i konverzija podataka

Veina RPC implementacija koriste call-by-value i call-by-copy/restore parametre prenosa. Callby-copy/restore parametar prenosa je kombinacija call-by-copy na ulazak procedure i call-byreference na povratak, kada su rezultati prekopirani u pozivajuu proceduru.

RPC se moe javljati izmeu sistema sa razliitim arhitekturama, pa se stoga parametri i

vraene vrednosti moraju predstavljati na standardan nain. Ovo obuhvata konverziju izmeu
sintakse podataka i poruka i dovodi nas do tri jedinstvena problema:

zapisivanje podataka

predstavljanje podataka

sintaksa prenosa podataka

Abstract Syitax Notation One (ANS.1) je standard za zapisivanje i predstavljanje podataka.

Postojee RPC implementacije najvie koriste podskup ANS.1. Primeri:
o

SUN-RPC koristi XDR (eXternal Data Representation)

DCE-RPS koristi IDL (Interface Definition Language)

Parametar prenosa i data/message konverzije se esto nazivaju parametar uvoenja.

4.7.2 RPC kompilacija

RPC je jezika apstrakcija i zbog toga zahteva komilaciju, tj. prevoenje. Glavne komponente ovog
procesa su:

datoteka interfejs specifikacije koja opisuje interfejs servisima koje server obezbeuje i koje
klijent moe da pozove

RPC generator koji uzima interfejs specifikaciju kao ulaz i proizvodi klijent i server izvorni kod
stub procedure kao izlaz

Run-time biblioteka za podraavanja izvrenja RPC (obuhvata pomo za povezivanje, konverziju

podataka i komunikaciju)

4.7.3 Povezivanje
Povezivanje opisuje proces prijavljivanja servisa koje prua server i proces pronalaenja servera od
strane klijenata. Obuhvata sledee korake:

na poetku, server alje svoj program i broj verzije zajedno sa portom, koji slua, port mapper-u.
Port mapper je serverov proces, koji upravlja program/port planiranjem i ima dobro poznatu adresu
porta

pre daljinskog poziva procedure, klijent kontaktira udaljeni port mapper radi dobijanje rukovanja
udaljenim serverom

port mapper vraa broj porta eljenog servisa (ako je registrovan)

klijent tada koristi clijent handle za kasniji RPC.

Ako je serverova maina nepoznata, druga sredstva (kao server sadraja) se prvo moraju koristiti za
lociranje serverove maine.

4.7.4 RPC izuzeci i upravljanje otkazima

Upravljanje izuzecima je komplikovanije nego kod lokalnih poziva procedura. Server mora izvestiti klijenta
o statusnim informacijama, a klijent mora da poalje kontrolne informacije serveru. Signalni podaci mogu
biti:
o

poslati zajedno sa podacima

in-band signaliziranje, gde su signalni podaci unutar normalnih podataka

out-band signaliziranje, gde signalni podaci koriste poseban kanal (out-band

signaliziranje je podrano sa strane mnogih prenosnih servisa)

koristi se zasebna konekcija

izuzecima se upravlja transparentno uz pomo stub biblioteke.
Upravljanje otkazima
otkaze je teko pronai i uiniti jasnim
Mogui tipovi otkaza:
o

greka lociranja servisa njome se moe upravljati kao izuzetkom

izgubljene poruk reava se retransmisijom koja dovodi do problema viestrukih

servisnih poziva koji se moe reiti pomou:

pravljenja zahteva istog znaaja, tj. ponovljeni zahtev proizvodi iste rezultate (na primer:
itanje bloka, pisanje u bloku, ali ne dodavanje bloka datoteci)

korienjem rednih brojeva ili korienjem pouzdane konekcije transportno orjentisanog

servisa (TCP)

pad sistema klijent ne zna da li je servis izvren ili ne, a eljena semantika je da servis
bude izvren tano jednom. Ovo se mora implementirati korienjem transakcija.

krah klijenta dovodi do ostataka raunanja kod servera, koji se moe eliminisati pomou:
o

klijenta prilikom ponovnog butovanja klijent brie status servera

servera periodino proverava postojanje svojih klijenata

izdisanja'' operaciji je dat ivotni vek i klijent mora eksplicitno da trai dodatno vreme

4.7.5 Sigurnost: Suns Secure RPC

Sigurnost je vana za RPC RPC dozvoljava daljinska izvrenja i tako dovodi do ranjivosti raunarskog
sistema. RPC je osnova za klijent/server komunikaciju i to nagovetava da sve karakteristike pouzdanosti
raunarskog sistema treba da budu izgraene na vrhu pouzdanosti RPC.
Suns Secure RPC:

koristi javne kriptografske metode tokom logovanja i simetrine kriptografske metode (DES) za
komunikaciju sa kljuem etape

Secure RPC poruke mogu sadrati kao dodatk podacima: vremenski rok, sadanjost, pregled
poruka

koristi NIS+ (Network Information Service) kao mesto za smetanje korisnikovih mrenih naziva
javnih i tajnih kljueva.

4.8 Transakciona komunikacija

Kombinacija multi prenosa i upit/odgovor komunikacije formira novi nivo komunikacije koja se zove
transakciona komunikacija. Transakcija je skup asinhronih komunikacija upit/odgovor koje poseduju ACID
(atomnost, konzistentnost, izolovanost, trajnost) osobine nasuprot bazama podataka, bez prinudnog
redosleda. Komunikaciona transakcija moe implicirati multiprenos iste poruke kopiranim serverima i
razliitih zahteva podeljenim serverima.

Atomnost: ili su sve operacije izvrene ili nijedna

Konzistentnost: izvrenje interno odobrene transakcija je ekvivalentno serijskom izvrenju

transakcija po nekom redosledu. Konzistentnost se takoe naziva i serijabilnost.

Izolovanost: parcijalni rezultati nedovrene transakcije nisu dostupni drugima pre uspenog
zavretka transakcije.

Trajnost: sistem garantuje da e rezultati izvrene transakcije biti permanentni, ak iako se

dogodi otkaz nakon smetanja.

ACID svojstva se mogu postii uz pomou dvofaznog protokola (Two-phase Commit Protocol 2PC)

4.8.1 Dvofazni protokol

Dvofazni protokol je analogan shemi tajnog glasanja:
o
o

glasanje inicijalizuje koordinator transakcije

svi uesnici distribuirane transakcije moraju doi do dogovora da li izvriti ili prekinuti
transakciju i moraju ekati saoptenje odluke

pre nego to uesnik glasa za izvrenje mora biti spreman da obavi to izvrenje

transakcija se izvrava samo ukoliko su svi uesnici pristali i spremni za izvrenje.

Svaki uesnik (ukljuujui koordinatora) odrava privatni radni prostor za praenje

aururanih objekata podataka (sadri staru i novu vrednost).

Da bi savladali otkaze, aurirani podaci se smetaju log stabilne aktivnosti. Log aktivnosti se moe
koristiti za oporavak nakon otkaza za ponovno izvrenje izvrene transakcije ili za ponitavanje
neizvrene.

4.8.2 Tok izvravanja 2PC

1. Koordinator poinje pisanjem precommit zapisa na svoj log aktivnosti; koordinator mora biti spreman
da izvri transakciju
2. Zahtev za glasanje se alje svim uesnicima
3. Kada uesnik primi zahtev za glasanje, on proverava da li transakcija moe biti izvrena i ako moe
pie precommit svom logu aktivnosti i alje DA kao odgovor, u suprotnom prekida transakciju I alje
NE kao odgovor.
4. Ukoliko je koordinator u stanju da prikupi sve DA odgovore u odreenom vremenskom intervalu, on
izvrava transakciju tako to pie commit zapis na svoj log I alje commit pruku svim uesnicima.
5. Kada primi commit poruku, uesnik izvrava transakciju tako to zapisuje commit zapis u svoj log
aktivnosti i oslobaa transakcione izvore.

4.8.3 Oporavak
S obzirom da pisanje precommit i commit zapisa u log aktivnosti brie sve aurirane podatke pre ovih
sinhronizacionih taaka, odgovarajue akcije prilikom oporavka od otkaza mogu se osloniti na odgovor
loga barem do sinhronizacionih taaka. Akcije oporavka se mogu kategorizovati u tri tipa:
o

otkazi pre precommit

otkazi nakon precommit, ali pre commit

otkazi nakon commit

4.9 Servisiranje po imenu i sadraju

o

Look-up operacije dato ime ili atributi entiteta. Vie atributa je steeno

Bilo koji objektni entitet (servisi ili objekti) u sistemu moraju biti imenovani (prepoznatljivi) i lociran

Operacija lociranja servisa, resolution proces, je podeljen u dva dela:

rezolucija imena mapira imena do logikih adresa osnovna funkcija distribuiranih sistema

rezolucija adrese mapira logike adrese do mrenih putanja (fizike lokacije) ovo je domen
mrenog softvera

Primeri servisa sadraja:

o

X.500 (ITU)

DCE servis koji daje nazive

CORBA COS servis koji daje imena

4.9.1 Rezolucija imena

U kontekstu rezolucije imena zainteresovani smo za dva specijalna atributa objekta, a to su ime i adresa.
Imena su atributi sa jedinstvenom vrednou koji slue za identifikaciju. Kolekcija imena, koja je
prepoznatljiva servisu imena, sa njihovim odgovarajuim atributima i adresama, se naziva name space.

Name space velikog obima koji sadri razliite klase objekata se moe struktuirati izimajui u obzir
jedinstvene tipove.

Naziv objekta (entiteta):

o

moe biti sam atribut (flat naziv)

moe sastojati od nekoliko atributa

hijerarhijski struktuiran (olanani atributi)

structure free (kolekcija atributa)

Podela atributa za ime objekta mogu biti:

o

fizicka

organizaciona

funkcionalna

Shema rezolucije imena moe biti:

o

hijerarhijska struktura bazirana na imenima

structure free bazirana na atributima

Performanse rezolucije imena se mogu poveati pomou caching i replication.

4.9.2 Informaciona baza sadraja

Konceptualni model podataka za smetanje i predstavljanje objektnih informacija se naziva informaciona
baza podataka (Directory Information Base DIB). Servis sadraja (Directory Service DS) ITU X.500
standarda daje strukturna i sintaksna pravila za opisivanje DIB u hijerarhijskom Directory Information Tree
(DIT). Atributi koji odgovaraju ulaznom objektu predstavljaju skup atributa sa vorova korena stabla.
Atributi koji se koriste za imenovanje se nazivaju distinguished attributes (na primer: drava, organizacija,
korisnik).
Name space velikog obima (i odgovarajui DIT) moe se rastaviti na imenovane domene (samo
administrativno rukovodstvo) i imenovane kontekste (podstabla)
o

Directory Service Agents (DSA) serveri za servise imena

Directory User Agents (DUA) inicijator procesa rezolucije imena

5. MEUPROCESNA KOORDINACIJA

5.1 Kooperativni procesi

Viestruki procesi esto moraju dostii neki sporazum (na primer da bi pristupili deljenom objektu) ili neke
zakljuke o sistemu (na primer u vezi tipologije sistema).
Razmatramo tri osnovna scenarija komunikacije:
o

jednosmerana

klijent/server

ravna komunikacija

Ravna komunikacija je neophodna za postizanje pomenute koordinacione aktivnosti kooperativnih

procesa.
Dva vna problema distribuirane koordinacije su:
o

distribuirana meusobna iskljuenja

distribuirani izbor takozvanog lidera.

5.2 Distribuirana meusobna iskljuenja

Klasian problem meusobnog iskljuenja zahteva da konkurentni procesi imaju serijski pristup deljenim
resursima ili podacima.
Algoritmi koji se koriste u jednoprocesorskim sistemima baziraju se na konstruisanju sebe samih koristei
deljene podatke (na primer, semafori, monitori i slino).
U sluaju distribuiranih sistema problem se mora reiti samo korienjem ravne komunikacije.
Za reavanje problema distribuiranog meusobnog iskljuenja moe se koristiti ili pristup na bazi
argumenta ili kontrolisani pristup.
Pristup na bazi argumenta podrazumeva da se sukob oko pristupa deljenom objektu, kada se istovremeni
zahtev pojavi, reava korienjem nekog kriterijuma za prekid veze. Mogui kriterijumi koji omoguavaju
nepristrasnu odluku su (logiko) vreme zahteva (zahtevprvog procesa je odobren) ili glasanje (proces koji
je dobio najvie glasova je odobren).
Kod kontrolisanog pristupa, pravo pristupa je predstavljeno uz pomo logikog tokena, koji se proputa
na kontrolisani nain izmeu konkurentnih procesa.

5.2.1 Lamport-ovi algoritmi distribuiranih meusobnih iskljuenja

Koncept Lamport-ovog logikog sata se koristi za potpuno ureenje svih zahteva za ulazak u kritinu
oblast. Algoritam radi na sledei nain. Kada proces eli da ue u kritinu oblast, on alje vremenski
utisnutu REQUEST poruku svim ostalim procesima, ukljuujui i sebe. Kada primi REQUEST poruku,
proces stavlja u red poruku i alje REPLY poruku procesu koji je poslao zahtev. Proces moe da ue u
svoju kritinu oblast samo ako je primio sve REPLY poruke i ako njegova poruka u redu ima najkrai
vremenski rok. Kada naputa kritinu oblast, proces alje RELEASE svim ostalim procesima. Kada primi
RELEASE poruku, proces uklanja zavren zahtev iz svog reda i ako njegov ureeni zahtev ima najkrai
vremenski rok, dozvoljeno mu je da ue u svoju kritinu oblast. Oigledno, ukupan broj potrebnih poruka
po ulasku je 3*(N-1), gde je N broj procesa u sistemu.
Kompleksnost poruke Lampert-ovog algoritma su umanjili Ricart i Agrawala.

5.2.2 Ricart i Agrawal-ov algoritam distribiranih meusobnih iskljuenja

Kao i kod Lamport-ovog algoritma, kada proces eli da ue u kritinu oblast, on alje vremenski utisnutu
REQUEST poruku svm drugim procesima, ukljuujui i sebe. Kada primi REQUEST poruku, akcija koju
preduzma proces koji je primio poruku zavisi od njegovog stanja. Razlikuju se tri sluaja:
1. Ukoliko on nije u kritinoj oblasti niti eli da ue u nju, on alj natrag REPLY poruku.
2. Ukoliko je u kritinoj oblasti, on ne odgovara i stavlja poruku u red.
3. Ukoliko eli da ue u svoju kritinu obast, on uporeuje vremenski rok poruke, koju je primio, sa onim
koji se nalazi u njegovoj REQUEST poruci, koju je poslao svim drugim procesima. Ukoliko je
vremenski rok poruke koju je primio manji, primalac poruke alje nazad REPLY poruku, a u
suprotnom REQUEST poruku stavlja u red.
Prijavljenom procesu je dozvoljeno da ue u svoju kritinu oblast samo ako je prikupio REPLY poruke od
svih ostalih procesa, kao i kod Lamport-ovog algoritma. Kada naputa kritinu oblast, on alje REPLY
poruke svim procesima iz njegovog reda i uklanja ih iz reda. Kompleksnost poruka je smanjena na 2*(N1).

5.2.3 Algoritmi distribuiranih meusobnih iskljuenja zasnovani na glasanju

Kada se koristi Lampot-ov ili Ricart i Agrwala-ov algoritam, ako je jedan jedini procesor nedostupan,
proces koji trai da ue u svoju kritinu oblast ne moe prikupiti sve REPLY poruke i kao posledica toga,
on je onemoguen da pristupi kritinoj oblasti.
Ideja izbora se zasniva na dobijanju veine glasova i moe primeniti na problem distribuiranih
meusobnih iskljuenja.
Kada proces primi REQUEST poruku, on alje natrag REPLY poruku (glas) samo ako nije glasao za neki
drugi prijavljeni proces. Proces koji je sakupio veinu glasova moe da pristupi svojoj kritinoj oblasti.
Kada naputa kritinu oblast proces alje RELEASE poruku svim drugim procesima. Nakon to primi
RELEACE poruku proces moe ponovo da glasa. S obzirom da smo jedan proces moe da prikupi veinu
glasova u jednom trenutku, meusobno iskljuenje je zagarantovano.
Problem ovog algoritma je zastoj, na primer, ako je N paran broj, dva procesa mogu imati podjednak broj
glasova. Da bi se reio ovaj problem, potrebna je globalnija komunikacija.
Algoritam izgleda ovako. Vremenski rok je vezan za svaku REQUEST poruku. Ukoliko proces koji je
glasao primi REQUEST poruku koja ima manji vremenski rok u odnosu na procesa za koji je glasao,
proces pokuava da povrati glas tako to alje INQUIRE poruku procesu kome je dao glas. Kada primi
INQUIRE poruku, ukoliko proces nije uao u kritinu oblast, on vraa glas procesu koji je poslao
INQUIRE poruku tako to mu upuuje RELINQUSH poruku. U suprotnom, glas se vraa slanjem
RELEASE poruke kada proces napusti svoju kritinu oblast. Kada proces povrati svoj glas, glasa za
proces sa najmanjim vremenskim rokom.
Kompleksnost poruke po ulasku je O(N) plus poruke za izbegavanje zastoja. Dodatne poruke se mogu
umanjiti smanjenjem broja glasova koji je potreban za ulazak u kritinu oblast. Svakom procesu
pridruujemo podskup svih procesa koji nazivamo skup zahteva. Procesu treba glas od svakog procesa
iz svog skupa zahteva. Presek svaka dva skupa zahteva mora biti neprazan skup da bi se osiguralo
meusobno iskljuenje.

5.2.4.1 Meusobno iskljuenje prenoenjem tokena. Topologija logikog prstena

Trokovi poruka algoritama meusobnog iskljuenja na bazi argumenta su visoki. Specijalna vrsta
poruke, koja se predaje kao token, moe preneti doputenje za ulazak u kritinu oblast. Prosleivanje
tokena mora biti kontrolisano tako da podnosilac zahteva u svoje vreme dobije token. Algoritmi
prosleivanja tokena namee logiku topologiju procesima radi ostvarivanja ovog cilja.
Procesi formiraju logiki prsten u okviru koga token krui. Vlasnik tokena moe da ue u svoju kritinu
oblast. Kada izae iz kritine oblasti, on alje token nasledniku. Ukoliko proces ne eli da pristupi svojoj

kritinoj oblasti, on prosleuje token dalje. Tako, token krui po prstenu ak i ako ni jedan proces ne eli
da ue u svoju kritinu oblast, a rezultat su nepotrebne poruke.
Tipologija prstena koja je nametnuta procesima nije najbolji nain za dobijanje tokena, jer putanja moe
biti dugaka (na primer, ako je zahteva poslao token neposredno pre nego to je hteo da pristupi svojoj
kritinoj oblasti, putanja je za jedan korak kraa od duine celog kruga). Alternativno reenje je nametnuti
procesima tipologiju stabla.

5.2.4.2 Meusobno iskljuenje prenoenjem tokena. Struktura logikog stabla

Struktura stabla je nametnuta procesima na sledei nain. Stablo je ukorenjeno u vlasnicima tokena. Ivice
u stablu su orjentisane, tako da pokazuju prema korenu. Stoga, sledei vor koji lei na putu izmeu onog
koji trai i onog kod koga je token je vor na koji dolazea ivica pokazuje. Zahtev za tokon je poslat ovim
putem. Ukoliko je vor ve traio token, ne mora triti ponovo kada primi drugi zahtev s obzirom da e
token stii u svoje vreme. Povratna putanja tokena mora biti zabeleena na putu zahteva do korena.
Svaki vor tog puta stavlja vor koji je poslao zahtev u lokalni FIFO red. Sada, glave FIFO redova definiu
povratnu putanju. Ako posednik tokena ne koristi token, a postoji zahtevi u njegovom FIFO redu, token se
alje procesu sa poetka FIFO reda, proces se uklanja iz FIFO reda, i orjentacija odgovarajue ivice se
menja. Ako postoji jo neki nereen zahtev, vor ispraa zahtev s obzirom na izmenjen pravac ivice.
Ukoliko je sam proces na poetu FIFO reda, uklanja se iz FIFO reda i ulazi u svoju kritinu oblast.
Predstavljeni algoritam je zasluga Raymonda. Viak poruka u Raymond-ovom algoritmu je O(logn) po
ulasku u kritianu oblast.

5.2.5 Meusobno iskljuenje prenoenjem tokena. Prenos

Nametanje logike topologije procesima prozrokuje trokove, s obzirom da se topologija mora kreirati i
odravati. Token, kao specijalna vrsta poruke, moe nositi korisne globalne informacije zajedno sa
procesima. Prenos se koristi za upravljanje ovim centralno smetenim informacijama na distribuirani
nain. Suzuki/Kasami-je algoritam prenosa je sledei.
Proces trai token tako to emitiju REQUEST poruku koja sadri lokalni redni broj seq. Svaki proces
ustanovljava lokalni redni vektor S. Ulazi vektora S indeksirani brojevima procesa i sadre najvei redni
broj koji je proces ikada imao. Kada zahtevaoc req emituje REQUEST poruku njegov ulaz S[req] se
inkrementira S[req]=S[req]+1 i seq=S[req]. Nakon primanja REQUEST poruke, primalac aurira svoj
vektor S, S[req]=max(S[req].seq).
Token se sastoji od token vektora T i FIFO reda zahteva. Ulazi vektora T takoe su indeksirani brojevima
procesa i sadri broj zavretaka kritine oblasti od strane odgovarajueg procesa. Kada proces kod koga
je token primi REQUEST poruku, on preduzima sledee akcije:
1.

Aurira svoj vektor S.

2.

alje token zahtevaocu ako je S[req]=T[req]+1.

Kada proces primi token moe da prisupi svojoj kritinoj oblasti. Nakon zavretka kritine oblasti, proces
p preduzima sledee akcije:
1.

Podeava T[p]=S[p].

2.

Prikljuuje sve procese sa S[k]=T[k]+1, izuzev k=p, redu zahteva u tokenu, ako ve nisu u njemu.

3.

Ako je red zahteva prazan, zadrava token. U suprotnom, uklanja ulaz sa vrha reda zahteva i
alje token procesu koji je naznaen u uklonjenom ulazu.

5.4.1 Algoritmi za izbor lidera. Potpuna topologija

Mnogi distribuirani algoritmi zahtevaju jedan proces koji igra specijalnu ulogu (na primer, ponaa se kao
centralni kontrolor). Generalno, nije vano koji proces iz grupe procesa igra specijalnu ulogu, ali jedan
mora to da uradi. Koristiemo termin lider kao generiko ime za specijalan proces. Otkaz lidera moe
ograniiti funkcionisanje sistema. Problem se moe umanjiti biranjem novog lidera kada postojei lider
otkae. Algoritam izbora lidera pokuava da izabere lidera iz grupe procesa koji se trenutno izvravaju.
Algoritam za izbor lidera se aktivira kada se sistem inicijalizuje ili kada postojei lider otkae. Tipino,

otkrivanje otkaza je bazirano na pauzama. Slino kao kod algoritama distribuiranih meusobnih
iskljuenja, algoritmi za izbor lidera takoe zavise od topologije grupe procesa.
Prvo emo razmatrati potpunu topologiju, gde svaki proces u grupi moe dosegnuti bilo koji drugi proces
iz iste grupe u jednom skoku. Dalje pretpostavke su sledee:
1.

Svaki proces u grupi ima jedinstveni broj.

2.

Komunikacioni kanali su pouzdani.

3.

Detekcija otkaza je sigurna korienjem skupa vremenskih intervala koji su malo vei od
zbira zadravanja poruke u putu i upravljanja porukom. Proces koji je otkazao znae da je okazao
kada se oporavi.

P alje ELECTION poruku svim procesima sa viim brojevima.

Ukoliko nema odgovora, P alje svim procesima sa niim brojevima LEADER poruku pokuavajui da
postavi sebe za lidera. P potaje lider nakom to primi odgovor na LEADER poruku ili ako istekne vreme
za odgovor za svaki nie numerisan proces.
Ako postoje UP odgovori od procesa sa viim brojevima, P odustaje i proces sa viim brojem zapoinje
izbore, ako ih ve ne odrava. Na kraju, svi procesi osim jednog odustanu, i taj proces je novi lider.
Kada se oporavi proces koji je otkazao, on zapoinje izbore.

5.4.2 Algoritmi za izbor lidera.Topologija logikog prstena

Pretpostavka za algoritme koji koriste topologiju logikog prstena je da nakon to je prsten inicijalno
konstruisan, topologija se odrava na mestu otkaza vora. Ovo se ostvaruje lake ako postojea mrea
podrava prenos u hardveru. Otkazi se otkrivaju i prsten se ponovo konfigurie prikazivanjem i
emitovanjem poruka. U suprotnom, prenos se simulira point-to-point komunikacijom.
Kada bilo koji proces u prstenu primeti da lider ne funkcionie, on zapoinje izbore tako to alje svom
nasledniku ELECTION poruku koja sadri njegov id. Poruka krui u prstenu i svaki proces joj dodaje svoj
id. Kada se poruka vrati inicijatoru izbora, on bira proces sa najveim id u poruci i prenosi liderov id
ostalim procesima.
Chang i Roberts su poboljali algoritme krunih izbora na dva naina. Prvo, suvino je ako poruka, koja je
poslata du prstena, sadri najvii ulazni i primaoev id. Sada, lider je izabran ako su ulazni i primaoev
id jednaki. Drugo, proces koji ve uestvuje u izborima ne mora da alje napred poruku, osim ako je
njegov id vei od onog koji je sadran u ulaznoj poruci.

6. RASPOREIVANJE DISTRIBUIRANIH PROCESA

6.1Strategije Rasporeivanja Distribuiranih Procesa

Kod distribuiranih sistema, obino postoji veliki broj procesora slobodnih za izvravanje sekvencijalnih
procesa. Kako bi se iskoristo ovaj operativniprostor, mora se doneti odluka koji e se proces kada izvriti i
na kom procesoru. U prilog tome mora postojati nain da se procesi rasporede na bilo koji od postojeih
procesora. Gore navedeni problem je poznat kao rasporeivanje distribuiranih procesa.
Glavna svrha rasporeivanja distribuiranih procesa je dodeljivanje procesora procesima na efikasan
nain, tako da vreme izvravanja procesa minimalno ili efikasnom upotrebom resursa.
Problem rasporeivanja distribuiranih procesa moe se podeliti i prouavati na dva nezavisna nivoa:

Politika rasporeivanja distribuiranih procesa, odreuje koj prenos e se kada izvriti i na kom
raunaru. Obino strategija rasporeivanja distribuiranih procesa pokuava da distribuira
optereenje sistema izmeu raunara distribuiranog sistema

Mehanizmi rasporeivanja distribuiranih procesa, obezbeuju olakice potrebne za izvoenje

odreene strategije distribuiranja. Ovi mehanizmi se mogu obino nai na nivou operativnog
sistema.

6.1 Politika Rasporeivanja Distribuiranih Procesa

Politika rasporeivanja distribuiranih procesa je odgovorna za dodelu procesora procesima. Za ovo je
nepohodno da se odgovori na sledea pitanja:
1. Kada se proces izvrava i na kom procesoru?
2. Kada e proces biti startovan za izvravanje?
3. kada i gde e proces prei sa teko optereenog raunara?
Na osnovu vremena dobijenih iz odgovora na postavljena pitanja, politike rasporeivaanja distribuiranih
procesa mogu se podeliti na sledei nain:

STRATEGIJE STATINOG RASPOREIVANJA sve odluke rasporeivanja se donose pre

startovanja procesa za izvravanje. Nakon to je proces startovan nije dozvoljeno prelaenje na
idealan ili manje optereen raunar.

STRATEGIJE DINAMIKOG RASPOREIVANJA odluke rasporeivanja se na donose samo

pre startovanja procesa ve i u toku njegovog izvravanja.. Ova grupa strategija podstie, na
primer pojednostavljuje prelazak procesa radi izjednaavanja optereenja sistema.

6.2.1 Strategije statinog rasporeivanja distribuiranih procesa

U sluaju statinog rasporeivanja distribuiranih procesa, sve odluke se donose pre startovanja procesa
za izvravanje. Kako bi se rasporeivanje izvrilo pravilno,na bilo koji od naina, rasporeiva mora da
poseduje dobro znanje ablona komunikacije i prorauna procesa, komunikaciona kanjenja, mrenih i
proraunskih mogunosti raunara ukljuenih u distribuirano okruenje prorauna.
Informacije o komunikacionom i proraunskom ponaanju moe se nai putem programskog jezika
raunara. Informacije o komunikacionim i proraunskim trokovima mogu se dobiti merenjem.
Statino rasporeivanje procesa se ne brine o prelascima procesa niti zasniva svoje odluke na trnutnom
optereenju raunara. Tako u situaciji kada su neki raunari idealni ili manje optereeni, mogu se pojaviti
drugi teko optereeni.

Poto rasporeiva ne mora da odrava stanje trenutnog rasporeivanja optereenja, on moe biti vrlo
jednostavan i efektivan. Sdruge strane, rasporeiva je centralizovani deo distribuiranog sistema.
Prednosti Modela Procesa
Vanost veza izmeu procesa moe se opisati sa Direct Acylic Graph (DAG) u kome punktovi
predstavljaju procese sa poznatim remenom izvravanja, a granice predstavljaju vanost veza izmeu
procesa. Granice se oznaavaju sa teinom preneenih poruka izmeu postupaka u okviru granica
roditelja.
Distribuirano raunarsko okruenje moe se prilagoditi pomou neusmerenog grafa. Ovde punktovi
predstavljaju raunare a granice predstavljaju komunikacione kanale meu raunarima. Svaka granica je
oznaena sa komunikacionim kanjenjem.
Rasporeiva trai raspored procesa po procesorima tako da ukupno vreme izvravanja bude minimalno.
Komunikacija meu procesima na istom procesoru nije od velike vanosti.
Poto je problem iznalaenja optimalnog dodeljivanja procesora procesima NP zavren, ponueno je
nekoliko heuristikih algoritama:

RASPOREIVANJE LISTE procesi se dodeljuju procesorima im je to mogue.

Prekomernekomunikacije se ne uzimaju u obzir

RASPOREIVANJE ROIRENE LISTE procesi se prvo rasporeuju korienjem algoritma za

rasporeivanje a kasnije se komunikacija uzima u obzir.

PRVI NAJRANIJI PROCES najraniji proces spreman za rasporeivanje se prvi rasporeuje.

Komunikacije Model Procesa

Ukolik nam nisu poznate prednosti veza meu procesima ili vreme zavretka procesa, vanost modela
procesa nije pogodna za njihovo modeliranje. U ovom sluaju moemo koristiti model procesa
komunikacije.
Model procesa komunikacije moe se predstaviti neusmerenim grafom, u kome punktovi predstavljaju
procese a granice predstavljaju meuprocesnu komunikaciju.
Jaina procesa komunikacije je izraena sredstvima trokova komunikacije.
Svaki procesor definie funkciju trokova izvravanja procesa, koja rasporeuje svaki proces na osnovu
trokova njihovog izvrvanja na tom procesoru.
Ciljrasporeivanja procesa je minimiziranje sume vremena izvravanja procesa i vremena komunikacije
procesa. U tu svrhu, trokovi komunikacije meu procesima koji se izvravaju na istom raunaru se
smatraju jednakim nuli. Ovaj problem je identian problemu iznalaenjaa maksimalnog protokola i
minimalnog prekida na grafu.

6.2.2 Strategije dinamikog rasporeivanja procesa

Strategije statinog rasporeinanja procesa se ne mogu koristiti ako rasporeiva nema prethodnog
iskustva o komunikaciskim i propaunskim ablonima procesa. U ovom sluaju, ipak, rasporeiva moe
prikupiti informacije o trenutnom optereenju distribuiranja i rasporeivanja procesa na idealan ili
najmanje optereen raunar.
Strategije dinamikog rasporeivanja mogu se podeliti na dve grupe:

DELENJE OPTEREENJA rasporeiva procesa tei da rasporedi proces na neoptereeni ili

malo optereeni raunar. Nakon to je proces rasporeen, izvrava se na ovom procesoru dok se
na zavri.

RASPOREIVANJE OPTEREENJA rasporeia procesa tei da rasporedi proces na

neoptereen ili malo optereen raunar. Suprotno pristupu deljenja optereenja, ipak, kada se

neki raunar postane idealan ili manje optereen nego raunar na kome se proces izvrava,
rasporeiva moe prebaciti proces na taj raunar.

Dinamiko rasporeivanje procesa sastoji se od:

STRATEGIJE TRANSFERA, koja odreuje da li e se proces izvriti u lokalu ili na daljinskom

kmpjuteru

STRATEGIJA IZBORA (SELEKCIJE), odreuje koji proces treba rasporediti

STRATEGIJA LOKACIJE, odreuje na kom raunaru bi proces trebalo izvriti.

Deljenje optereenja
U sluaju deljenja optereenja, optereenje se distribuira preko distribuiranih sistema rasporeivanjem
procesa na neoptereen ili malo optereen raunar. Ovaj pristup, ipak, obezbeuje samo lokalno reenje
rasporeivanja distribuiranih procesa, na primer, unapreuje samo izvoenje na lokalnoj maini. U prilog
tome, ukupno optereenje se moe distribuirati nejednako.
Kako bi se raspodelio proces, neophodno je da rasporeiva zna informacije o trenutnom optereenju
prenosa (distribucije). Generalno, mogua su dva pristupa:

SAMOSTALNI RASPOREIVA sve odluke o dodeljivanju procesara procesima donosi sam

rasporeiva

VIE RASPOREIVAA procese kreirane na odreenom raunaru rasporeiva rasporeuje

na tom raunaru. U ovom sluaju, vie rasporeivaa rasporeuje procese na procesore tako da
se informacija o trenutnom optereenju distribuira preko sistema i rasporeiva je mora
prikupljati periodino.

Rasporeivanje Optereenja
Glavni razlog rasporeivanja optereenja je izjednaavanje optereenja svih raunara u distribuiranom
sistemu. Ovaj cilj se moe postii prebacivanjem procesa sa veoma optereenih raunara na
neoptereene ili malo optereene raunare.
Na osnovu vremena kada rasporeiva inicira premetanje procesa, algoritmi rasporeivanja optereenja
mogu se podeliti na sledee grupe:

ALGORITMI SA NAGLASKOM NA POILJAOCA prebacivanje procesa zapoinje kada duina

rasporeivaevog reda prevazie odreeni prag. Rasporeiva tada bira malo optereen raunar
(strategija lokacije) i proces koji e prei (strategija izbora). Ovaj algoritam se dobro primanjuje
kod malo optereenih distribuiranih sistema.

ALGORITMI SA NAGLASKOM NA PRIMAOCA prebacivanje procesa zapoinje kada duina

rasporeivaevog reda prevazie odreeni prag. Rasporeiva tada bira malo optereen raunar
(strategija lokacije) sa kog e proces prei. Proces koji e prei na eljeni raunar se bira od
strane rasporeivaa (strategija izbora). Ova shema se dobro primenjuje kod veoma optereenih
distribuiranih okruenja.

Premetanje procesa mora bititransparentno sa prebaenim procesom i svim procesima sa kojima

komunicira.

6.3 Mehanizmi Rasporeivanja Distribuiranih Procesa

Rasporeivau procesa trebaju jednostavni i moni mehanizmi ijim korienjem moe sprovesti
strategije rasporeivanja. Dve takve mogunosti su:
-

daljinsko izvravanje i

prebacivanje procesa

Mogunost daljinskog izvravanja dozvoljava rasporeivau da zapone proces na daljinskom raunaru.

Jednom kad se proces zapone, nije dozvoljeno premetanje na drugi raunar.
Vie upotena ali i skuplja mogunost je prebacivanje procesa. Ovo omoguava rasporeivau da ukine
jedan od njegovih procesa i iznova zapone njegovo izvravanje na drugom, manje optereenom.
Oba mehanizma mogu biti implementirana na razliitim nivoima abstrakcije:
nivo operativnog sistema

LOCUS, CHARLOTTE
nivo programskog jezika

SR, PVM

nivo aplikacije

rexec

rlogin

6.3.1 Daljinsko izvravanje

Mogunost daljinskog izvravanja je neophodna za impementaciju strategija i dinamikog rasporeivanja
distribuiranog procesa. To je alat koji rasporeiva moe koristiti da rasporedi proces da se izvrava na
daljinskoj maini.
Daljinsko izvravanje se sprovodi kroz sledee korake:
-

rasporeiva bira raunar na kom e sproces biti izvren

rasporeiva se povezuje na daljinski izvrni server izabranog raunara i trai da izvri
odabrani proces
daljinski izvrni server gradi okruenje za novi proces
rasporeiva alje potpuno proraunsko stanje procesa (program, poetne podatke,
stack) na daljinski izvrni server

daljinski izvrni server inicijalizuje okruenje i zapoinje proces

rasporeiva unitava staro okruenje procesa

6.3.2 Prebacivanje procesa

Mogucnost premetanja procesa se koristi za implementaciju klase rasporeivanja optereenja strategije
rasporeivanja. Dozvoljava rasporeivau da ukine proces izvravanja na lokalnom raunaru i da ga
iznova zapone na daljinskom.
Kada se proces premesti na daljinski raunar, oba njegova stanja, komunikacijsko i propraunsko, moraju
se premestiti. Proraunsko stanje se sastoji od programa, podataka, stack-a i vrednosti registara.
Komunikacisko stanje sadri komunikacijske linkove, primljene poruke i poruke u prenosu.
Postoji nekoliko naina kako da se nosimo sa porukama primljenim nakom to je proces prebaen:
-

Prosleivanje poruka, kada raunar na kome se proces izvravao primi poruku za taj
proces, on jednostavno prosleuje poruku novoj procesorskoj lokaciji.

Preventiva protiv gubljenja poruke, pre nego to se proces premesti, svi procesi sa
kojima taj proces komunicira su obaveteni o novoj procesorskoj lokaciji.

Povrratak izgubljene poruke, nakon to je proces premeten na novi raunar, ponovo

uspostavlja sve komunikacione kanale i inicijalizuje protokol povratka izgubljene poruke.

8. DISTRIBUIRANI FAJL SISTEMI

Fajl (Datoteka) sistem je kljuna komponenta svakog distribuiranog sistema. Uloga fajl sistema je da
skladiti postojane imenovane objekte podataka zvane fajlovi, i da omoguci da budu dostupni kad je to
potrebno. Fajl sistem je dakle odgovoran za kreiranje, brisanje, povraaj, izmene i zatitu fajlova.
Distribuirani fajl sistem (DFS) predstavlja implementaciju fajl sistema u disribuiranom sistemskom
okruenju koje se sastoji od fiziki razdvojenih (distribuiranih u smislu lokacije) skladita podataka ali koji
obezbeuje tradicionalnu preglednost fajl sistema za korisnike. Zato se mnogi vani koncepti u izradi
distribuiranih sistema mogu demonstrirati implementacijom DFS-a:
1. distribuirani fajl sistemi primenjuju koncept transparentnosti
2. nacin adresiranja u DFS-u je primer ''opsluivanja imenoanja''
3. korienje keiranja i replikacije fajlova radi poveanja performansi i bolje dostupnosti faljova
4. Kontrola pristupa i zatita podataka u DFS-u predstavlja problem.

8.1 Aspekti DFS-a

Veliki broj korisnika i fajlova je kljuni aspekt fajl sistema, a distribuiranom okruenju je ovaj aspekt jo
izraeniji. Novi aspekt DFS-a je disperzija krisnika i fajlova(Npr korisnik u DFS-u moe da pristupa svojim
podacima koji se nalaze na HD-u nekog drugog raunara u mrei). Disperziju i mnotvo (korisnika i
fajlova) bi trebalo sakriti od korisnika.
DISTRIBUIRANI KLIJENTI. DFS bi trebao da omogui transparentno logovnje tj. korisnik treba da
vidi sistem jedinstveno nezavisno od servera ("HOST" raunar) uklljuujui i proceduru za
logovanje i transparentan pristup. Mehanizam pristupa fajlu je jedinstven, bez obzira da li su fajlovi
na lokalnom ili udaljenom serveru.
DISTRIBUIRANI FAJLOVI. DFS bi trebalo da omogui trasparentnost lokacije, tj. imena fajlova ne
treba da sadre informacije o njiovoj fizikoj lokaciji i nezavisnoj lokaciji, tj. fajlovi se mogu
premetati sa jedne lokacije na drugu bez promene imena.
VELIKI BROJ KORISNIKA. DFS bi trebao da omogui tansparentnu konkurentnost, tj. fajlu koji deli
vie krisnika moe se pristupiti bez greke od strane bilo kog korisnika.
VELIKI BROJ FAJLOVA. DFS bi trebaloda omogui transparentnost replikacije tj. auriranje replika
se vri na atomskom nivou i korisnici nisu ni svesni postojanja vie od jedne kopije.
Drugi aspekti ukljuuju otpornost na greke, skalabilnost, heterogenost DFS-a.

8.2 Organizacija Fajl Sistema

Posmatrano funkcijski, fajl sistem se sastoji od etiri glavne komponente:
1. servis direktorijuma
2. servis autorizacije
3. servis fajlova
4. servisi sistema

SERVIS DIREKTORIJUMA. Glavna funkcija je mapiranje tekstualnih imena fajlova u adrese. Mapiranje je
dosta nezavisno od trenutnih operacija nad fajlom. Zbog toga, uobiajeno je odvajanje servisa
direktorijuma od servisa fajlova kako bi se podrala modularnost i portabilnst . Obino je opsluivanje
fajlova na usluzi razliitim strukturama direktorijuma. Operacije nad direktorijumima ukljuuju pregled,
dodavanje i brisanje sadraja direktorijuma.
SERVIS AUTORIZACIJE . Uloga servisa autorizacije je da obezbedi kontrolu pristupanja fajlu. U
implementaciji, autorizacija se moe realizovati u sklopu servisa direktorijuma ili servisa fajlova. U
prethodnom sluaju, komponenta za servis direktorijuma uva informacije o pristupima fajlovima i
direktorijumima. Ako je korisnik autorizovan za pristup fajlu ili direktorijumu, njemu se omoguava obrada
eljenog fajla , i odreene mogunosti, koje se definiu pravima korisnika pri korienju fajla. Kada se
kasnije pristupa fajlu, prava pristupa se proveravaju preko fajl servera. Kasnije komponenta za servis
direktorijuma obezbeuje samo obradu fajla. Klijent mora bit autorizovan od strane fajl sistema svaki put
kad izvodi neku operaciju nad fajlom.
SERVIS FAJLOVA. Fajl sistemi koji podravaju transakcije dele fajl servise na transakcione i osnovne fajl
servise. Transakcioni servisi sprovode upravljanje konkurentnom obradom i upravljanje replikacijama.
Osnovni fajl servisi su ''read/write'' i ''get/set''. Servis fajlova takoe podrava kreiranje i brisanje fajlova.
Servis fajlova je u interakciji sa sistemskim opsluivanjem kod poslova dodeljivanja i oslobaanja prostora
bafera i fajla.
SERVISI SISTEMA. Funkcije koje obezbeuje sistem obuhvataju trenutne ''read/write'' operacije,
mapiranje logikih u fiziki blok adresa, i upravljanje prostorom koji zauzima (memorijom) fajl. Upravljanje
keom i odzivima je takoe usluga sistemskih servisa fajl sistema.

8.3 Fajl Serveri

Servisi se implementiraju procesima zvanim serveri. Servis moe biti implementiran od strane samo
jednog servera ili veeg broja kooperativnih servera. Server moe obezbediti mnotvo usluga. Velik fajl
sistemi su sastavljeni od razliitih fajl servera.
Montiranje fajlova (maunting) je koristan koncept za projektovanje velikih fajl sistema. Operacija
montiranja od strane klijenta spaja udaljeni imenovani fajl sistem za klijentovu hierarhiju fajl sistema u
trenutku identifikacije preko imenovane putanje. Taka (mesto) montiranja je obino prazan
poddirektorijum. Specificiranje fajl sistema koji e se mauntovati se vri prema konvenciji imenovanja
udaljenog fajl sistema. Na ovaj nain se ostvaruje transparentnost lokacije. Korienjem mehanizma
montiranja razliiti klijenti mogu dobiti razliite poglede fajl sistema.
Fajl server moe zabraniti montiranje celog ili dela njegovog fajl sistema predefinisan skupom servera
(host raunari) zbog bezbednosnih razloga.
Montiranje fajl sistema moe se sprovesti na tri naina:
EKSPLICITNO MONTIRANJE. Klijenti zahtevaju operaciju mauntovanja eksplicitno kad im ustreba.
"Pogled" fajl sistema je definisan od strane korisnika.
BOOT MONTIRANJE. Propisani skup se mauntuje u vreme "boot-ovanja" korisnika. Klijenti imaju
jedinstven statian pogled celog fajl sistema, ak i ako nekima od njih nee trebati svi propisani
mauntovani serveri.
AUTO MONTIRANJE. Server se bezuslovno mauntuje kada klijent po prvi put otvori fajl. Pogled fajl
sistema je dinamian, kao kod eksplicitnog mauntovanja ali bez potrebe za pozivima eksplicitnog
mauntovanja.
Montiranje zahteva poznavanje lokacija fajl servera. Fajl server se moe locirati na dva naina:

Klijenti se konsultuju sa registracioni serverom tamo gde se serveri moraju registrovati za svoje
usluge. Registracioni server dodeljuje, po nekom kriterijumu, najbolji server.

Klijenti emituju zahteve za montiranjem a fajl serveri odgovore na te zahteve. Sada klijent moe
da bira jedan od servera, koji su se javili, primenom neke strategije.

8.3.1 Fajl Serveri Sa i Bez Informacija o Postojeem Stanju (Stateful and

Stateless)
Klijentovi ''read/write'' zahtevi mogu biti jednopotezne operacije. Obino, klijent pokree takozvanu fajl
sesiju putem operacije otvranja, nakon koje slede kasniji ''read-write'' zahtevi. U ovom sluaju postoji
informacija o stanju za svaku fajl-sesiju. Na primer informacije o stanju mogu obhvatiti:
koji klijent je otvorio fajl
fajl-deskriptore zbog identifikacije fajla u predstojeim operacijama
pokazivae trenutne pozicije fajla za sledei sekvencijalni pristup
montiranje informacija zbog daljinskog pristupa
lock status zbog koordiniranja deljenja fajla
jednokratni sesijski kljuevi zbog bezbedne komunikacije
sadraj kea ili bafera radi poboljanja performansi
Jasno je da informacije o stanju fajl-sesije mogu biti podeljene izmeu klijenta i fajl servera.
Fajl server sa informacijama o stanju je onaj koji sadri neke bitne informacije o stanju fajla. Na primer;
kada se fajl otvori, klijent prima fajl deskriptor za sledei pristup. Tabela mapiranja fail deskriptora za
fajlove odrava se od strane servera. Slino tome, pokaziva pozicije fajla uva se za svakog klijenta
tokom sekvencijalnog pristupa fajlu, osim u sluaju "nasleivanja".
''Stateless'' fajl server se zove tako zato to ne uva informacije o stanju. U ovom sluaju, svaki zahtev bi
sadrao puno ime fajla i pokaziva pozicije fajla.
Informacije o stanju koje se nalaze u zahtevima stateless servera (bez informacija o stanju) poveavaju
duinu poruke i moraju biti izvrene od strane servera svaki put kada se pristupi fajlu.
uvanje informacija u statefull serveru omoguava postizanje bolih performansi. Sa druge strane ako
statefull file server "padne", informacija o stanju za svaku fajl-sesiju je zauvek izgubljena a oporavak, ako
je uopte mogu, zavisi iskljuivo od klijenta. "Pad" stateless fajl servera je lako povratiti, a javlja se kao
kanjenje odziva.

8.4 Semantika Deljenja Fajla

Deljenje fajla od strane vie klijenata pokree dva vana problema. Operacije pristupa mogu se prekopiti
ako postoj vie kopija istog fajla. To omoguava simultani pristup deljenom podatku. Svaki vor(raunar u
mrei) koji ima kopiju fajla moe imati razliito vienje podatka. Ovaj problem naziva se kontrola
postojanosti (koherencije).
Viestruki pristupi od strane klijenata istom deljenom fajlu imaju formu povezanih jednostavnih read/write
operacija, iluzija simultanosti moe se postii preplitanjem izvrenja ovih sekvenci. Primari razlog je
postizanje postojanog stanja podatka nakon preplitanja u izvravanju sekvenci, na primer, rezultat je
jednak nekom serijskom izvravanju ovih sekvenci bez preplitanja. Reenje pomenutog problema zavisi
od semantike itanja i pisanja.
UNIX SEMANTIKA. Read operacija e vratiti ''poslednju'' upisanu vrednost. Ova semantika potie od
sistema sa jednim procesorom, gde se podaci keiraju po fajl osnovama. U distribuiranim sistemima
moe postojati mnotvo kea istog fajl podatka i problem konzistentnosti kea mora da se rei.
Unix semantika modelira poslove sa prostim read/write operacijama i pokuava da postigne globalni
konzistentni pogled deljenog podatka i moe se posmatrati na dva naina, tako da se odnosi na
semantiku transakcije i semantiku sesije.

SEMANTIKA TRANSAKCIJE: Jedinca pristupa fajlu ili grupi fajlova je nedeljiva sekvenca read i write
operacija. Operacije transakcije su obuhvaene parom naredbi: poetak transakcije/kraj transakcije.
Izvravanje transakcije se ne ometa od strane drugih konkurentnih transakcija. To znai da zahtev za
izvravanje dve ili vie konkurentnih transakcija je isti kao da se izvravaju jedna za
drugom(sekvencijalno). Jedino se odrava konzistentnost podataka, stalne izmene fajla se sprovode
samo na kraju uspene transakcije.
SEMANTIKA SESIJE: Izmene na otvorenom fajlu su fiziki vidljive samo lokalnom klijentu. Samo kada je
fajl zatvoren izmenjeni fajl se kopira na fajl server i promena je trajno izvrena. Tako da je sesija
obuhvaena parom naredbi: ''open/close'' i deljenje fajla postoji samo izmeu uspenih sesija.

8.5 Keiranje
Keiranje od strane korisnika klijent-server sistema eliminie prenos kroz mreu kada klijent pristupi fajlu.
Na ovaj nain se moe postii prednost u izvravanju ali keiranje klijenta unosi nekonzistentnost u
sistem. Ako klijent lokalno vri izmene keiranog fajla i ubrzo zatim drugi kljient proita fajl sa servera,
drugi klijent dobija zastareo fajl.
''WRITE-TROUGH'' STRATEGIJA pokuava da rei problem nekonzistentnosti trenutnim slanjem ''write''
naredbi fajl serveru. Shodno tome, kada drugi klijent ita fajl sa fajl servera, dobija novu vrednost. Ipak
promene se nee videti od strane drugih procesa koji imaju isti fajl u svom keu.
''WRITE-INVALIDATE'' ili ''WRITE-UPDATE'' protokoli se mogu koristiti za reenje ovog problema.
Ponitavanje keeva od strane fajl servera obavetava sve klijente da su njihovi keevi "zastareli" i da se
moraju ponovo uitati za predstojee korienje.
''Write-trough'' i ''write-invalidate'' simuliraju Unix semantiku.
Jasno je da sa ''write-trough'' keom prenos mreom je eliminisan samo za itanje. Kako bi se snizio
promet write naredbi kroz mreu promene se mogu prikupiti na strani klijenta i da se periodino alje write
naredba. Ova strategija kontrole se naziva ''WRITE-BACK'' i nije podrana od strane Unix semantike.
Dalja olakanja u radu sa keiranjem trae usvajanje semantike sesije. Izmenjeni fajl se aurira(slanjem
"write" naredbe) posle zatvaranja. Ova strategija se zove ''WRITE-ON-CLOSE''.

8.6 Replikacija Fajla

U distribuiranim fajl sistemima se esto vri replikacija fajlova. To znai da postoji vie kopija fajla i svaka
kopija se odrava na odvojenim serverima.
Glavni razlozi za ovo su:
poveanje sigurnosti (pouzdanosti) sa viestrukim ''backup''-ima
dozvoljavanje pristupa fajlu ako fajl server "padne"
rasporeivanje optereenja putem vie servera
Jasno se vidi da replikacijom fajla puzdanost, pristupanost i performanse sistema mogu da se
poboljaju.
Kada se vre izmene na replikovanom fajlu, izmene se moraju poslati svim kopijama. Ako proces ovo radi
sekvencijalno i "srui se" nakon to je zapoeo slanje poruka o izmenama, a pre nego to uspe da
poalje poslednju, neke operacije itanja u budunosti mogu dobiti novu vrednost a druge mogu dobiti
staru vrednost fajla. ''Update'' protokol reava ovaj problem.

8.6.1 Update Protokoli

Replikacija osnovne kopjie. Jedan server je dizajniran kao primarni, svi ostali su sekundarni. Izmena
replikovanog fajla se alje primarnom serveru, koji vri izmene lokalno na fajlu i zatim alje poruke o
izmenama sekundarnim serverima. Operacije itanja mogu se izvoditi na bilo kojoj kopiji primarnoj ili

sekundarnoj. Kako bi se izbegla situacija da se ne update-uju sve sekundarne kopije, a prmarna kopija se
"srui" prvo se upisuju izmene u trajno skladite fajla, a posle se vri promena primarne kopije. Nakon
oporavka od "pada" sa primarnih se moe zavriti slanje zahteva za izmenu sekundarnim. Ipak, ako je
primarni iskljuen, ne mogu se izvriti izmene.
"Quorum" glasanje. Klijenti moraju zahtevati i odravati dozvole mnogih servera bilo pre itanja ili
pisanja u odazvani fajl. Pretpostavimo da se fajl replikuje na N servera. Pisanje u replikovani fajl, zahteva
od klijenta da sakupi "quorum" za pisanje Nw, koji je ogranien na 2*Nw N. Kad se sakupi Nw servera
koji su se sloili, u fajl se upisuje i nova verzija je povezana sa fajlom. Broj verzije je isti za sve
novoizmenjene kopije. Kako bi se itao replikovani fajl, klijent mora da prikupi kvorum za itanje (read
quorum) Nr, koji je ogranien na Nr+Nw N. Poto su oba kvoruma isprepletana meusobno, bilo koji
sakupljeni kvorum itanja e morati da sadri veinu izmenjene kopije. Jasno je, da je metod kvorum
glasanja robusniji ako se uporedi sa replikacijom osnovne kopije.

9. DISTIBUIRANA DELJENA MEMORIJA

9.1 Motivacija i Principi

Posledica okruenja distribuirnih sistema gde su, meusobno povezani raunari, fiziki odvojeni je
korienje paradigme slanja poruka za meuprocesnu komunikaciju. Ova paradigma je podrana od
strane hardvera komunikacijske mree u pravom smislu. Meusobno povezani raunar mogu veoma lako
da formiraju multiraunar sa hiljadama procesora. Dizajniranje multiprocesorske maine procesora slinih
karakteristika koji koriste istu memoriju je teak posao.
Mnoge tehnike korienja maina sa deljenom memorijom za sinhronizaciju procesa i meuprocesnu
komunikaciju su poznate kao multiprocesorsko programiranje. U sluaju multiprocesora, odsustvo deljne
memorije zahteva korienje tehnika razliitih od onih u upotrebi kod maina sa deljenom memorijom.
Generalno gledano, paradigma prenosa poruke se mora koristiti. Prenos poruke nosi sa sobom mnoga
komplikovana pitanja ukljuujui kontrolu toka, gubitak poruka, baferovanje i takozvani ''blocking''.
Korienje RPC-a(Remote procedure call) prikriva neke od ovih potekoa skrivajui time i trenutnu
komunikaciju od programera u bibliotekim procedurama. Tako, RPC (Remote Procedure Calls)
obezbeuje transparentnost komunikacije. Postoje ogranienja pri korienju RPC-a, na primer velika
struktura podataka koja sadri pokazivae ne moe se preneti RPC-om bez znaajnog truda.
Komunikacija se prirodno ogleda u oblicima razmene informacija izmeu nepovezanih adresnih prostora.
Postoji oigledna potreba direktnog deljenja informacija u okruenju distribuiranog sistema, tj. omoguiti
procesoru da pristupi memoriji udaljenog raunara. Distribuirana deljena memorija (DSM) simulira logiki
prostor deljene memorije preko fiziki odvojenih maina. Time se postie direktno deljenje informacija. To
ima za posledicu da paradigma programiranja deljene memorije moe da se koristiti u okruenju
distribuiranog sistema. Kada se pristupa memoriji udaljenog raunara, stvarna komunikacija je
transpatentna od strane aplikacionog sloja na vrhu komunikacije prenosa poruke.

9.2 DSM Arhitektura

U istraivanju multiprocesorskih sistema, alternativni dizajn je distribuiranje pojedinanog logiki deljnog
prostora tako da procesori mogu pristupiti memoriji udaljene maine bez keiranja. U tom sluaju pristup
udaljenoj memoriji je mnogo sporiji nego pristup lokalnoj memoriji i ova injenica nije skrivena
korienjem hardverskog keiranja. Multiprocesorska arhitektura sa ovakvim tipom memorije se
pretstavlja se kao maina sa neuniformnim pristupom memoriji (NUMA).
DSM sistem je NUMA sistem deljene memorije. Postoje neke razlike izmeu NUMA multiprocesora i DSM
sistema. Neki od njih jasno lee u hardverskim komponentama, na primer vremena pristupa ili nain na
koji podravaju broadcast komunikaciju.
Svarna razlika je da se na NUMA multiprocesorima udaljenim podacima pristupa preko adresa dok je na
DSM sistemima softverska podrka uvek neophodna.
Za dalju diskusiju moramo poznavati osnovne organizacije jedinica memorije.
Kad blok sa eljenim podacima nije u lokalnoj memoriji, moe se daljinski pristupiti bloku ili se blok
premeta u lokalnu memoriju za budue pristupe. Premetanje bloka moe znaiti da je blok stvarno
premeten ili samo iskopiran (premetanje bloka i replikacija bloka).
Premetanje bloka postje neophodno kada uestalost daljinskog pristupa pree neki prag.Postojee
strategije premetanja su ''pull-based'', tj. procesor povlai blok iz udaljene memorije kada je potreban ili
po zahtevu. Alternativno procesor moe gurnuti blok drugom procesoru u nadi da e prosleeni blok biti
potreban drugom procesoru veoma brzo. Usled premetanja bloka moe doi do takozvanog "pucanja"
bloka. Moe se dogoditi da se permeteni blok odmah zahteva od strane drugog procesora, moda i
prethodnog, tako da neprekidno prelazi sa jednog procesora na drugi. Replikacija bloka reava ovaj
problem. ta vie, replikacija bloka podrava konkurentni pristup istim podacima. Ali replikacija bloka
poveava potrebu korienja skupe kontrole memorykoherencije.

Fizika organizacija memorije u okviru bloka ne utie na logiku organizaciju podatka. Ova injenica
moe pokrenuti problem tzv. pogrenog deljenja. Blok je premeten ili iskopiran ak i ako se samo mali
deo podataka u okviru bloka zahteva od strane nekog procesora. Ako je podatak iz drugog dela bloka
potreban drugom procesoru, DSM tretira blok kao deljeni blok i ako se ustvari podaci ne dele.

9.2.1 Vrste DSM Sistema

Moemo razlikovati 3 vrste DMS-a:
page-based DSM (zasnovani na stranicama)
shared-variable DSM (deljena promenjljiva)
object-based DSM (zasnovani na objektima)
PAGE-BASED DSM. Mehanizam koji se koristi je slian klasinom sistemu stranine organizacije
memorije. Udaljeni procesor preuzima ulogu povratnog skladitenja. Pokuaj da se referencira stranica
na udaljenoj maini prouzrokuje prekid za operativni sistem. Operativni sistem tada zahteva stranu tako
to alje poruku udaljenoj maini, koja pronalazi traenu stranu i alje je nazad.
SHARED-VARIABLE DSM. Samo se odabrana veliina adresnog prostora deli. Da bi se odredila deljena
promenjljiva ptrebna je informacija od strane korisnika.
OBJECT-BASED DSM. Korienje objektne tehnologije prouzrokuje da programi ne mogu samo prosto
da pristupe deljenom podatku, ve moraju da potiju metode zatite. Kao posledica, sistem izvravanja
(runtime system) moe preuzeti kontrolu za svaki pristup pomaui tako ouvanje konzistentnosti
deljenog podatka.
''Shared-variable'' DSM i ''object-based'' DSM nemaju problema sa pogrenim deljenjem.

9.3 Modeli Postojanosti Memorije

Problem koherencije u kontekstu vieadresnih (multicast) i distribuiranih fajl sistema se tie ugla iz kojeg
posmatramo podatke. Deljeni podaci su eksterni za proces. U DSM sistemima procesi ostaju sami u
deljenoj memoriji. Nekonzistentnost memorije direktno utie na integritet izvravanja procesa.
Pretpostavimo da je varijabla x smetena na mainama A i B. Proces A na maini A upisuje novu vrednost
x u trenutku T a DSM sistem podhitno alje auriran blok koji sadri x za B. x na maini A je auriran u
trenutku T+t. Jasno je da ako izmeu vremena T i T+t jedan proces uita x sa A a drugi x sa B, vrednosti
dobijene obradom e biti razliite.
Izraz koherencija se ponekad koristi za najstroe zahteve konzistencije kada se DSM sistem ponaa
potpuno identino centralizovanoj deljenoj memoriji sistema bez replikacije podataka. U prethodnom
primeru, memorija je pouzdana pre trenutka T i posle trenutka T+t.
Izraz model postojanosti se koristi za manje stroe zahteve gde je memorija postojana samo u
pojedinim trenucima sinhronizacije.
Izbor modela postojanosti memorije predstavlja izbor izmeu lakoe programiranja i performansi sistema.
Model zabrane ini programiranje slinim onom kod centralizovanih sistema sa deljenom memorijom i
zato je lake ali smanjuje mogunosti za konkurentan rad.
Modeli postojanosti su grupisani u dve kategorije:
modeli postojanosti generalnog pristupa
modeli postojanosti sinhronizovanog pristupa
Modeli generalne postojanosti su bazirani na generalnom read/write pristupu memoriji. Mogu se napraviti
sa manje restriktivnim smanjivanjem zahteva za organizovanje ''write'' operacije.

Modeli postojanosti sinhroinzovanog pristupa zasnovani su na operacijama sinhronizovanog pristupa, koji

pristupa sinhronizovanom tipu specificirane varijable. Zahtevi postojanosti se smanjuju od strane razliitih
usvojenih operacija sinhronizovanog pristupa.

9.3.1 Modeli postojanosti generalnog pristupa

AUTOMATSKA POSTOJANOST (poznata kao stroga konzistentnost) je jedna od najstroih i ona se
definie sledeim uslovima: ''Bilo koje itanje memoriske lokacije x-a vraa vrednost smetenu
poslednjom operacijom pisanja u x''.
SEKVENCIJALNA POSTOJANOST je za nijansu slabiji model od automatske postojanosti: ''Rezultat bilo
kog izvravanja je isti kao da su operacije svih procesa izvrene po nekom redosledu, i operacije svakog
procesora ponaosob se pojavljuju u ovom redosledu, koji je odreen njegovim programom.
UZRONA POSTOJANOST predstavlja dalje pojednostavljenje sekvencijalne konzistentnosti. Upise koji
su potencijalno uzrono povezani moraju videti svi procesi u istom redosledu. Konkurentni upisi mogu se
videti u razliitom redosledu na razliitim mainama.
PIPELINED RAM (PRAM) Postojanost. Zahtev da uzrono povezani upisi (write operacije) moraju biti
vidljivi u istom redosledu na svim vorovima se ignorie: Upis od strane jednog vora primaju svi procesi
u redosledu po kom je postavljen, ali upis razliitih vorova moe biti vidljiv u drugaijem redosledu.
POSTOJANOST PROCESORA. Zahtev, da uzrono povezni upisi moraju biti vidljivi u istom redosledu na
svim vorovima, se ignorie: upise od strane jednog vora primaju svi procesi po redu po kom su
postavljeni, ali upisivanja (write operacije) razliitih vorova mogu biti vidljivi u drugaijem redosledu.

9.3.2 Modeli postojanosti sinhronizovanog pristupa

Slaba poostojanost.
Sinhronizovan pristup synsh(s) koristi se da obezbedi da su svi prethodni pristupi izvrenii pre pokretanja
sinhronizovanog pristupa, i nijedan budui pristup se ne pokree dok se svi prethodni sinhronizovani
pristupi ne izvre. Pristupi sinhronizacionoj varijabli su takoe sekvencijalno postojani.
Postojanost otputanja''.
Ni jedan budui pristup se ne moe izvriti dok god se ne zavri operacija aquire(s), i sve prethodne
operacije moraju se izvriti pre zavretka operacije relese (s).
Sinhronizovani pristup mora biti procesorski postojan. Par aquire (s) i relese (s) obezbeuje iskljuenje
kritinih regiona.
Postojanost ulaska.
Nijedan budui pristup ne moe se izvriti dok se na zavri opreacija aquire (s) i sve prehtodne operacije
moraju se izvriti pre zavretka operacije relese (s).
Usklaeni pristup mora biti procesorski postojan. Par aquire (s) i relese (s) obezbeuje obostrano
iskljuenje kritinih regiona.

9.4 Algoritmi Memory Menadmenta

U DSM sistemu, postoje tri opcije kako procesor moe pristupiti udaljenom bloku podataka:
1. udaljenom bloku se pristupa daljinski na udaljenoj maini.
2. udaljeni blok se premeta u lokalnu memoriju. Budui pristupi izvode se lokalno.
3. udaljeni blok se replikuje u lokalnoj memoriji. Simultani pristupi istom bloku su mogui.

Uzimajui u obzir dva generalna tipa pristupa, read/write postoje 9 razliitih kombinacija od kojih se 4
opisuju na sledei nain:
1. Read-remote-write-remote
2. Read-migrate-write-migrate
3. Read-replicate-write-migrate
4. Read-replicate-write-replicate
Read-remote-write-remote
Ova strategija pristupa naziva se algoritam centralnog servera
- serveri su potencijalno usko grlo
- koherencija memorije je trivijalna
Read-migrate-write-migrate
Strategija se naziva algoritam prenosa. To je protokol jednog itaa i jednog pisaa.
- bolje izvaenje moe se postii "istraivanjem" programskog prostora
- problem je efekat ''block - bouncing'' a i moe da doe pogrenog deljenja (false sharing)
Read-replicate-write-migrate
Strategija pristupa se naziva algoritam ''read-replication''. To je protokol vie itaa jedan pisa.
Strategija koristi ''write-invalid'' protokol u sluaju pristupa za pisanje na ''read-replicated'' blok.
Read-replicate-write-replicate
Ova strategija pristupa predstavlja algoritam ''full replication'' (potpune replikacije). To je protokol vie
itaa vie pisaa.
-najee koristi ''write-update'' protokol zbog sluaja da se pristupa radi itanja ''read-replicated''
bloka.
-pretpostavlja da je grupa lanova konana (''copy set'' deljenog bloka podataka je poznat).

10. ZATITA U DISTRIBUIRANIM RAUNARSKIM SISTEMIMA

10.1 Zatita u raunarskim sistemima
Zatitu kod raunara odreuju tri sledee karakteristike:
- tajnost (privatnost, poverljivost): resursima raunarskih sistema mogu pristupiti ("read") samo
ovlaeni korisnici
- integritet: resurs moe biti promenjena ("write") samo preko ovlaenih korisnika
- prava pristupa: ovlaene grupe imaju pristup komponentama raunara (tj. sistem radi bez servisa
odbijanja)
Tolerancija greaka obuhvata
- pouzdanost
- sigurnost
Tolerancija greaka i zatita raunara i komunikacionog sistema je nazvana pouzdanost
Kod ugroavanja bezbednosti distribuirani sistemi su ranjiviji nego samostalni raunarski sistemi zbog:
- otvorene arhitekture
- potrebe za interakcijom preko irokog opsega autonomije i heterogenosti sistema
- protok poruka ICP kroz komunikacionu mreu (otvorenu za spooting i forging u komunikaciji)

10.2 Osnove raunarske zatite

Dva gledita raunarske zatite:
- politika kontrole pristupa: politika zatite opisuje kako subjekti mogu pristupiti objektima
- politika kontrole toka: politika zatite opisuje tok informacija izmeu entiteta (objekta i subjekta)
etiri kategorije opte zatite objekta od pretnji:
- prekid
- presretanje
- modifikacija
- fabrikovanje
Osnovni pristupi u radu sa problemima zatite su :
- autentifikacija (iskljuuje eksterne napadae)
- autorizacija (kontrola internih napadaa)
- tolerancija greaka (spreavanje nenamernih greaka)
- enkripcija (ouvanje privatnosti )
- nadzor (pasivna forma zatite, nalaenje naruavanja zatite)
Poitika zatite opisuje korisnike zahteve u vezi sa zatitom koju se daje raunarski sistem.
Model zatite formalno predstavljanje politike zatite.
Mehanizam zatite treba da:

- obezbeuje operativni sistem

- koristi se za implementaciju politike zatite
Modeli zatite:
- model kontrole diskrecionim pristupom (Dicretionary Access Control) baziran na individualnoj osnovi
tj. vlasnici objekata su slobodni da daju dozvole pristupa drugim korisnicima
- model kontrole mandatornim pristupom (MandatoryAccessControl) bazirana na sistemu tj. postoje
irokosistemska pravila koja ograniavaju pristup objektima
- kontrola pristupa zasnovana na ulogama (RoleBasedaccessControl) neutralna politika tj. razliite
politike mogu biti odreene dok se koristi ovaj model, ukljuujui DAC i MAC politiku)
Zahtevi zatite u distribuiranim sistemima:
princip arhitekture distribuiranih OS je razdvajanje mehanizma (u kernelu) od politike (u serverima)
sposobnost zadravanja meuoperativnosti i transparentnosti uprkos potencionalnim pretnjama transparentna zatita. Da bi se to ostvarilo, potrebna je standardna arhitektura sistema zatite sa
API za poverljivu aplikaciju. Primer takve API je General Security Service Application Program
Interface (GSS-API).

proces klijenta

serveri sa drugim operativnim

sistemom

server
autentifikacioni

autorizacioni
server

drugi serveri
zatite

zahtev

odgovor

bezbedno jezgro (trusted secure kernel)

10.3 Modeli kontrole diskrecionog pristupa

Omoguavaju kontrolu pristupa na individualnoj osnovi. Vlasnici ili korisnici objekata mogu opcionalno da
odobre pristup njima.
Formalno to moe biti opisano preko matrice kontrole pristupa (ACM) koristei model distribuiranog
odeljka (logino grupisanje preko graninih vorova subjekata i objekata koji "sarauju")
- pristup je baziran na distriburanom identifikatoru - aplikaciono orjentisanom, nezavisnom od
operativnog sistema na niem nivou
- svaki distribuirani odeljak ima barem jednog lana - vlasnika (koji ima najvee privilegije)
- moe biti hijerarhijski struktuiran
ACM moe biti implementiran koristei listu kontrole pristupa (ACL), listu mogunosti (CL), lock-key
(kombinacija ACL i CL)

10.4 Mandatorni modeli kontrole pristupa

Bave se kontrolom protoka informacija na nivou celog sistema. Ovde je svaki objekat pod kontrolom
zatitnih podsistema i ne postoje opcionalna pravila pristupa objektu.
Svi entiteti sistema su kategorisani u klase zatite, klasifikacija je imenovana za svaki subjekat i objekat i
tada je pristup kontrolisan prema ovim klasifikacijama.
Klase entiteta se retko menjaju nakon kreiranja entiteta
Primeri ovih modela ukljuuju: Lattice model, Bell-LaPadula model, Biba model

10.4.1 Lattice "Reetka" model

"Reetka" je direktni aciklini graf sa jednim izvorom i jednim uem. Svaki objekat i subjekat je povezan
sa klasom zatite, i sve klase zatite formiraju delimino ureen skup. Informacije mogu tei samo u
pravcu koji odgovara deliminoj ureenosti.
Formalna definicija modela "reetka":
FM = <S,O,SC,F >
gde je:
S - skup subjekata (aktivni inioci odgovorni za tok informacija)
O - skup objekata (logini ili fiziki resursi informacija)
SC - ogranian skup klasa zatite koji odgovara nevezanim klasama informacija (sve forme delimino
ureene)
- najmanji gornji granini operator u SC; za bilo koje dve klase A i B, klasa je jedinstveno definisana
- najvei donji granini operater u SC; za bilo koje dve klase A i B, klasa je jedinstveno definisana
- tok relacije definisan na paru zatitnih klasa; sredstvima informacija u klasi A je dozvoljen protok u
klasu B (postoji samo kada je B vei od A u deliminoj ureenosti)
FM je zatien samo ako izvrenje niza operacija ne dovodi do toka informacija koji naruava tok relacija

10.4.2 Bell-LaPadula model

Dekartov proizvod linearno ureene "reetke" (hijerarhija) - nivo zatite, i podskup "reetke" (nehijerarhija)
- kategorija zatite
Primer:
nivo zatite: neklasificiran, poverljiv, tajni, top secret
kategorije zatite: podskup kriptografija,
Ovaj model je kombinacija nivoa zatite i kategorija zatite se naziva klasifikacija za objekte i dozvola za
objekte.
Tok relacija je definisan tako da subjekti mogu itati samo objekte iste ili nie klasifikacije i subjekti mogu
pisati samo u objekte sa istom ili viom klasifikacijom.

10.5 Modeli kontrole pristupa zasnovani na ulogama (RBAC)

RBAC je alternativa za tradicionalne modele kontrole diskrecionog i mandatornog pristupa. RBAC je

nain za izraavanje politike zatite i on ima neutralnu politiku. Odreena politika se postie
konfiguracijom komponenti RBAC.
Model je baziran na:
- tri skupa: korisnici (Users), uloge (Roles) i prava pristupa (Permissions)
- relacijama: dodeljivanje korisnika (UA), dodeljivanja prava pristupa (PA) i hijerarhija uloga (RH)
- skup ogranienja drugih komponenti modela
Ogranienja

RH
Hijerarhija
Uloga

U
Korisnici

R
Uloge
UA
Dodela
Korisnika

Prava pristupa
PA
Dodela
prava pristupa

Korisnici imaju svoje uloge a uloge odgovarajua prava pristupa

Hijerarhija uloga dozvoljava nasleivanje prava pristupa izmeu funkcija
Korisniku je onda odobren pristup odreenim akcijama ako uloga, koju korisnik ima, ili bilo koja nasleena
uloga poseduje potrebna prava pristupa
Koncept uloga i hijerarhije uloga obezbeuje laku administraciju sistema
RBAC moe biti korien i za kontrolu pristupa procesima upravljanja u RBAC modelima

10.6 Kriptografija
Kriptografija moe biti primenjena za autentifikaciju principala i potpisivanje poruka u distribuiranim
sistemima
Indetetii klijenata i servera se nazivaju principali.
principalu

Principal je autentifikovan znai da je dat tajni klju

Poruka autentifikacije: jedinica podataka koja nosi digitalni zapis tako da poruka ne moe biti poreknuta

10.7 Kriptografski sistemi sa tajnim kljuem

Algoritam je dekomponovan na dva dela: funkciju (javni) i klju (tajni)
Poseban tajni klju se koristi da podrava privatne razgovore izmeu principala (enkripcija i dekripcija za
oba), takozvana simetrina kriptografija
Primeri: DES, IDEA
Problemi:

 distribucija kljua - mora postojati sposobnost sigurne distribucije tajnih kljueva

veliki broj kljueva - potreban je poseban klju za svaku komunikaciju dva principala

10.8 Kriptografski sistemi sa javnim kljuem

Koncept javnog kljua u kriptografiju su uveli Diffie i Hellman
Svaki principal sadri par ifrujuih i deifrujuih kljueva, Ke i Kd
Algoritam enkripcije E i Ke su poznati korisnicima, Algoritam dekripcije D i Kd su privatne informacije koje
pripadaju principalu - asimetrina kriptografija.
Primeri: RSA, Diffie-Hellman
Problemi:
vea raunska sloenost - algoritmi za kriptografiju sa javnim kljuem su bazirani na reavanju
intezivnih problema
distribucija javnih kljueva - mora postojati sposobnost sigurne distribucije javnih kljueva

10.9 Autentifikacija i distribucija kljueva

"pretnje" sistemu sa atentifikacijom

imposter

eavesdro
p

repudiation

replay

imposter

forgery

Krajni cilj protokola autentifikacije:

za interaktivne vezno-orjentisane servise: dostii optu pouzdanost kljua sesije za procese
komunikacije
za one-way takozvane connectionless servise: autentinost i zatita integriteta kombinovanih u "oneshot" poruci
Veina distribuiranih aplikacija prate klijent/server paradigmu programiranja; interakcija se ostavaruje kao
komunikacija pitanje/odgovor. Za ovo se moe koristiti klju sesije, ali konceptualno jednostavniji je uvid u
naloge

10.9.1 Protokoli autentifikacije

Protokoli autentifikacije treba da predstave nesigurno sistemsko okruenje
Osobine poruka koje moraju biti zadovoljene:
autentinost nema poricljivosti poruke
integritet - poruka je neizmenjena

 aktuelnost - poruka je neponovljiva (nema reemitovanja)

Mnogi protokoli autentifikacije koristi autentifikacioni server koji
generie klju sesije
deli privatne informacije sa svakim principalom (server klju)
Nain za obezbeenje aktuelnosti poruka
trenutno stanje - broj, koji je korien samo jednom; replay je otkriven kada se isto trenutno stanje vidi
dvaputa; nezgodno je kada je zahtevan vei broj poruka
vremensko upozorenje - replay je otkriven kada vremensko upozorenje poruke ima veu razliku od
sadanjeg vremena nego to je dozvoljeno; nezgodno je to je potrebna dobra sinhronizacija sata
Primeri
Needham-Schroeder protokol
Denning-Sacco protokol
Otway-Rees protokol
Kerberos V protokol
CCITT X.509 protokol

10.10 Kerberos protokol

Kerberos-ov protokol je baziran na Needham-Schroeder-ovom protokolu i koristi vremenska upozorenja
za spreavanje replay-a i smanjenje broja poruka. Koristi secret-key (DES) kriptosistem
Projektovan je za model klijent/server i obezbeuje servis atentikacije za klijente i servere. Servis
autentifikacije je u dva servera:
autentifikacioni server (AS) - izvrava autentifikaciju korisnika u login vremenu i zahtevnih naloga za
TGS
Ticket Granting Server (TGS) -servisira naloge za servere na zahtev klijenta
Ticket: indetitet, IP adresa, vremensko_upozorenje, vek_trajanja, klju sesije ifrovano sa ifrom
servera
- potpisani certifikat koji se koristi za potvrivanje zahteva klijenta za servisom
Authenticator: indetitet, IP adresa, vremensko_upozorenje ifrovano sa kljuem sesije
- dokazuje da je principal koji koristi nalog jednak onome kome je nalog dat
Autentifikacion
Ovlaenja: par autentikatora (authenticator) i naloga(ticket)
i
server

vri autentifikaciju klijenta i njegovo pravo da pristupi serveru

Kerberos-ov protokol je iroko korien i takoe je deo DCE servisa zatite

Kerberos 5 autentifikacioni protokol

1.

C K: C, G,N

Ticket granting
server

3
4

Klijent

Server

2.

K C: Kcg , N Kc, Ticketcg

3.

C G: Authenticatorcg, Ticketcg

4.

G C: Kcs , N Kcg, Ticketcs

5.

C S: Authenticatorcs, Ticketcs

Ticketab = B, A, addr, Ts, L, Kab Kbs

Authenticatorab = A, addr, Ta Kab

10.11 Prikriveni kanali

Prikriveni kanal je komunikaciona staza koja ilegalno proputa informacije preko prividno legitimno
korienih raunarskih resursa. Postoje dva tipa prikrivenih kanala:
kanali memorisanja - opservacija direktnih ili indirektnih promena u memoriji (ime datoteke, veliina,
slobodni prostor na disku, ...)
kanali vremenskog podeavanja - opservacija vremenskog podeavanja ponaanja procesa i
dogaaja (proces uzastopnog vremena, ...)
Distribuirani sistemi uvode prikrivene mrene kanale koji su bazirani na:
prostornim informacijama (veliina paketa, adresa odredita, port, ...)
vremenskim informacijama (brzina paketa, vreme izmeu paketa, ...)
Zbog pasivnog karaktera eksploatacije prikrivenih mrenih kanala, njihovo otkrivanje je veoma teko, ali
protok informacija preko prikrivenih mrenih kanala moe biti redukovan pomou tehnika preventivne
analize komunikacija:
enkripcija - spreavanje korienja informacija iz poruka
dodavanje - promena svih paketa da imaju istu veliinu ili umetanje lanih paketa
rutiranje - sluajni paketi se kopiraju u jedinstvene tokove podataka
rasporeivanje - sluajan pristup paketima

10.12 Mehanizam Nadzora

To je mehanizam "poslednje sredstvo" - nadzor moe da pomogne da otkrije kad se desi neko
naruavanje bezbednosti, ko je odgovoran, koliko je informacija bilo ugroeno, itd.
Nadzorom moe da se dobije:
procena povezanosti prikrivenih mrenih kanala
odbijanje napada servisnog tipa preko
-

iscrpljenja resursa (raunskih, memorijskih, komunikacioni portovi)

virusa

prevara (RIP, ARP, RPC) - tj. izmiljeni paketi nekih protokola sa namerom korupcije mrenim
ureajima

Nadzor se moe vriti:

on-line
off-line (kada problemi ve postoje) koristei "detalje" uneenih informacija
Pristupi za otkrivanje napada korienjem nadzora:
statistika analiza uneenih podataka da bi se dobio profil sistema i otkrile anomalije
vetaka inteligencija: sitemi zasnovani na znanju
formalni jezik: trag napada moe biti vien kao reenica formalnog jezika, koji ralanjavanjem
sluajnih tokova moe shvatiti ablone napada

11. UNIX i WINDOWS NT

11.1 Istorija UNIX-a

1965 Multics: MIT, Bell Laboratories, General Electric
1969 K.Thompson, D.Ritchie, B.Kernighhan Space Travel - PDP 7 - Unix (assembler)
1971 Patent department, PDP 11, text processing Thompson B languange - Ritchie C languange
1973 Unix preraen u C, 25 univerzitetskih instalacija besplatno
1977 500 instalacija, 125 na univerzitetima, prenosni komercijalni Unix System III, System V,
UnixWare, SCO,...
1978 BSD Unix : Berkley University, Bill Joy 2.x BSD (16bit, PDP-11), 4.x BSD(32bit, VAX)
1991 Linus Thorvalds, University Helsinky Linux

11.2 Opis ciljeva "ranog" 4BSD Sistema

Ciljevi BSD (Berkeley Software Distributions):
Polazei od 3BSD mogu raditi u DEC VAX, osim 4.4BSD (68000, SPARC, MIPS, HP300, i386).

3BSD podrka virtuelnoj memoriji: zahtev za numerisanjem i zamenu strane

4BSD - cilj da obezbedi podrku za DARPA Internet mrene protokole, TCP/IP

mrene aplikacije telnet, ftp, rlogin, rcp, rsh

podrka za 10Mbit/s Ethernet, token-ring, protokoli XEROX NS i ISO/OSI

NFS (Network File System) implementacija

4.4BSD Lite-2 je bilo poslednje reenje. Korieno je u :

NetBSD: i386, spare, alpha, hp300, mac68k, vax, pmax,...

FreeBSD: PC kompatibilni raunari

OpenBSD: zatita, kriptografija, portabilnost

11.3 Proces adresiranja

Postoje etiri tipa memorijskih objekta u sistemu:
imenovani objekti predstavljaju fajlove ili hardver koji omoguuju mapiranje memorije
anonimni objekti predstavljaju oblasti memorje koje su popunjene nulom pri prvom korienju;
koristi particiju razmene za povratak
pratei objekti dre privatne kopije modifikovanih strana; oni koriste oblast razmene, koja
obezbeuje njihove inicijalne strane kopiranjem postojeih strana kao odgovor na copy-on-write
greke
kopirani objekti dre stare strane iz fajlova koji su bili modifikovani nakon to su bili privatno
mapirani

11.4 Deljenje memorije u BSD Unix-u

Memorija se deli izmeu procesa koji nastaju nakon mmap() sistemskog poziva; podela nastaje
mapiranjem fajlova od strane jednog ili vie procesa u njihovom adresnom prostoru. Povezani sistemski
pozivi:
munmap - brie mapiranje
mprotect - menja zatitu strana
mlock - primorava strane da budu rezidentne
munlock - obrnuta operacija
msync - osveavanje kea koji sadri modifikovane strane u glavnu memoriju ( i moda u
fajlsistem)
Mapiranje moe biti:
javno: memorijske strukture ukazuju na isti objekat
privatno: ukazivanje na objekte umetnute u pratee objekte koji koriste copy-on-write semantiku
da dozvoli nedoslednost kada mea javno i privatno mapiranje, kopirani objekti mogu biti
upotrebljeni da obezbede privatme snimke

11.5 IPC model

4.4BSD omoguuje bogat skup interprocesnih komunikacionih (IPC) sposobnosti namenjenim za podrku
konstrukcije distribuiranih programa napravljenim na komunikacionim primitivama.
IPC olakice su dizajnirane da podre sledee:
transparentnost lokacije. Komunikacija izmeu procesa ne sme zavisiti od toga da li su procesi na
istoj maini.
efikasnost. IPC sposobnosti su na vrhu mreno-komunikacionih sposobnosti.
kompatibilnost. Postojei servisi bi trebalo da budu upotrebljivi u distibuiranim okruenjima bez
promene.
Zahtevi za podrku ovih ciljeva:
podrka za komunikacione mree koje koriste razliite protokole: pojam komunikacionih domena.
Imena komunikacionih krajnjih taaka mogu varirati izmeu domena.
objedinjena apstrakcija za krajnju taku komunikacije koja moe biti manipulisana kao opisna
datoteka: soket. Soketi su napravljeni u komunikacionim domenima.

11.6 Komunikaciona semantika

Aspekti komunikacione semantike moraju biit dostupni aplikacijama na kontrolisan i uniforman nain. Svi
soketi su klasifikovani prema komunikacionoj semantici.
Ovi semantiki tipovi su:

ureena isporuka podataka

neidentina isporuka podataka

dostupna isporuka poruka

uvanje okvira poruke

podrka nepovezanim porukama

komunikacija orjentisana na veze

11.7 Tipovi soketa

datagram soket je potecijalno nepouzdan model, komunikacija paketa bez veza
tok soket je model pouzdanog toka bajtova zasnovan na konekciji koja moe da podri nepovezan
prenos podataka
sekvencionalni paket soket je sekvencionalni model, pouzdan, neduplirana komunikacija bazirana
na konekciji koja uva okvire poruke.

11.7.1 Sistemski pozivi soketa

s = socket( domen, tip, protokol); kreira socket specifinog tipa
bind(s, adresa); veza domena i adrese
connect(s, adresaServera); konekcija zapoeta
listen(s); dolazea veza bie primljena
sNew = accept(s, adresaKlijenta); novi socket je kreiran po konekciji
read, write, send, recv, sendmsg, recvmsg

11.7.2 Nepovezani komunikacioni soket

peer process

peer process

socket(domen,tip,protokol)

socket(domen,tip,protokol)

bind(soket, adresa, )

bind(soket, adresa, )

sendto(soket, msg, )
recvfrom(soket, msg, )

recvfrom(soket, msg, )
sendto(soket, msg, )

#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <stdio.h>
#define BUFSZ 256
main() {
int s, n, len;
char buf[BUFSZ];

struct sockaddr_in sin;

socket(AF_INET, SOCK_DGRAM, 0);
sin.sin_family = AF_INET;
sin.sin_port = htons(1234);
bcopy(hp->h_addr, &sin.sin_addr, hp->h_length);
sendto(s, buf, BUFSZ, 0, &sin, sizeof(sin));
len = sizeof(sin);
n = recvfrom(s, buf, sizeof(buf), 0, &sin, &len);
buf[n] = NULL;
printf("%s\n", buf);

close(s);
exit(0);

11.7.3 Povezani komunikacioni soket

Server

Klijent

socket(domen, tip,
protokol)

socket(domen,tip,protokol)

bind(soket, adresa, )

listen(soket)

rendezvous

connect(soket, )

newsock = accept(soket, )

fork()

read(newsock, )

write(newsock, )
/* Server */
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <stdio.h>
#define NSTRS 3
char *strs[NSTRS] = { "first\n", "second\n", "third\n" };
main() {
char c;
int fromlen;
int i, s, ns;
struct sockaddr_in sin, fsin;

request

reply

write(soket, )

read(soket, )

s = socket(AF_INET, SOCK_STREAM, 0);

sin.sin_family = AF_INET;
sin.sin_port = htons(1234);
bcopy(hp->h_addr, &sin.sin_addr, hp->h_length);
bind(s, &sin, sizeof(sin));
listen(s, 5);
ns = accept(s, &fsin, &fromlen)
for (i = 0; i < NSTRS; i++)
write(ns, strs[i], strlen(strs[i]));
for (i = 0; i < NSTRS; i++)
while (read(s, &c, 1)) == 1) {
putchar(c);
if (c == '\n') break;
}
close(s);
exit(0);
}
/* Client */
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <stdio.h>
#define NSTRS 3
char *strs[NSTRS] = { "first\n", "second\n", "third\n" };
main() {
char c;
int i, s;
struct sockaddr_in sin;
s = socket(AF_INET, SOCK_STREAM, 0);
sin.sin_family = AF_INET;
sin.sin_port = htons(1234);
bcopy(hp->h_addr, &sin.sin_addr, hp->h_length);
connect(s, &sin, sizeof(sin);
for (i = 0; i < NSTRS; i++) {
while (read(s, &c, 1)) == 1) {
putchar(c);
if (c == '\n') break;
}
}
for (i = 0; i < NSTRS; i++)
write(s, strs[i], strlen(strs[i]));
close(s);
exit(0);
}

11.8 Besplatni operativni sistemi

Naslednici 4.4BSD Unix-a
- NetBSD

http://www.netbsd.org

portabilnost
FreeBSD http://www.freebsd.org

PC kompatibilna platforma (Intel)

OpenBSD http://www.openbsd.org

zatita, kriptografija, portabilnost

glavne Linux distribucije

Debian GNU/Linux

RedHat Linux

SuSE Linux

Slackware

Caldera Open Linux

11.9 Mreni API u Windows NT

Win32 I/O API
-

open, close, read, write,...

mrena komunikacija samo kada se pristupa udaljenom fajlu ili imenovanom toku

Win32 network (WNet) API

-

prikljuivanje i pretraga na udalljenom fajl sistemu (LAN Manager, NetWare, VINES,...)

Win32 imenovani pipe i mailslot APIs

-

imenovani tokovi su interfejsi visokog nivoa za komunikaciju jedan-na-jedan

mailslots omoguuje komunikacione mehanizme jedan-na-vie i vie-na-jedan

NetBIOS API
-

backward kompatibilnost za MS-DOS, 16-bit Windows i OS/2

Windows Sockets API

-

prua interfejs UNIX stila za umreavanje

Poziv udaljenih procedura (RPC) sposobnost

-

runtime biblioteka i kompajler za razvoj distribuiranih aplikacija

11. 10 Imenovani tokovi

orginalni interfejs visokog nivoa za NetBIOS
implementiran na pseudo fajl sistemu. Pipe datoteka je smetena u memoriji i ponaa se kao
uobiajeni fajl sistem.
predstavljen je kao objektna datoteka i radi pod istim zatitnim mehanizmima kao drugi NT izvrni
objekti.
moe postojati ili na lokalnom ili na udaljenom raunaru i obezbeuje sredstva za komunikaciju u
distribuiranom okruenju
iza API-a,koristi nii nivo transportnih mehanizama i, suprotno RPC-u, koristan je za slanje tokova
podataka

 moe biti korien kao mreni prenos za RPC sredstvo.

12. MIKROKERNEL

12. 1 Koncept Mikrokernela

Svaki operativni sistem upravlja skupom resursa i obezbeuje skup standardnih servisa. Na primer, UNIX
operativni sistem upravlja procesorom, memorijom i ulazno-izlaznim ureajima. Naknadno, on
obezbeuje proces servis, memorijski servis, servis rasporeivanja, fajl servis i mreni servis.
Tradicionalni operativni sistemi su monolitni, tj. svim resursima upravlja i sve servise obezbeuje kernel
ovih operativnih sistema.
U mikrokernel baziranim operativnim sistemima, svi servisi su obezbeeni od strane obinih procesa na
nivou korisnika.

12. 2 Monolitni operativni sistem

Kljuni deo monolitnog operativnog sistema je njegov kernel. On upravlja svim resursima i obezbeuje
servise odreenog tipa, kvaliteta i dostupnosti. Da bi upravljao novim resursima ili obezbeivao servis
novog tipa, kvaliteta ili dostupnosti, kernel mora biti promenjen.
Pored toga, monolitni kernel je ogoman, sloen i nepouzdan. Na primer, kernel 4.4BSD UNIX operativnog
sistema se sastoji od 200.000 linija izvornog koda. Greka u implementaciji mrenog servisa, na primer,
moe da prouzrokuje zastoj u procesu rasporeivanja ili upravljanja memorijom.
Pored toga, monolitni operativni operativni sistemi su dobro razumljivi i prilino efikasni.

12. 3 Mikrokernel pristup

U poreenju sa kernelom monolitnog operativnog sistema, mikrokernel implementira samo minimalni
skup prostih apstrakcija i mehanizama. Ali on, meutim, ne upravlja bilo kojim resursima niti obezbeuje
bilo koji servis.
Servisi i apstrakcije visokog nivoa operativnog sistema su implementirani preko uobiajenih,
sekvencijalnih procesa-servera. Na primer, moe postojati mnogo rasporeivaa gde svaki implementira
servis ili razliit kvalitet (rasporeivanje u realnom vremenu nasuprot vremenske raspodele).
Operativni sistemi bazirani na microkernel-u su ukljueni na servere, koji upravljaju resursima i
obezbeuju standardne servise odreene vrste, kvaliteta i dostupnosti. Na primer, prosti UNIX operativni
sistem e se sastojati od memorijskog servera, servera rasporeivanja, servera imenovanja, fajl servera,
mrenog servera i terminalnog servera.
Prednosti Mikrokernela
Ako mikrokerneli ne upravljaju nijednim resursom niti pruaju ijedan servis u operativnom sistemu, oni
mogu biti znatno manji i jednostavniji nego monolitni kerneli. Zbog toga, njih je mnogo lake dizajnirati,
implementirati i testirati. Na primer, dizajniranje, implementacija i testiranje microkernel-a RC 4000 nije
prekorailo jednu godinu.
Lake je dizajnirati, implementirati i testirati nezavisne servere operativnog sistema. Potom, moemo
prosto preraditi ve implementirane i testirane servere.
Nakon to je operativni sistem ukljuen u skup servera i mikrokernela, vie operativnih sisteme moe biti
aktivno u isto vreme. Mogue je, na primer, pustiti NetBSD UNIX i Oberon operativni sistem da rade
istovremeno.
Microkernel koncept e izgleda biti najprirodniji koncept za distribuiranu sistemsku konstrukciju.

Nedostaci Mikrokernela
Generalno, postoji jedan inherentan problem mikrokernela; oni su veoma neefikasni. Izvor ovih
nedostataka je direktno povezan sa velikim brojem primljenih poruka kao i velikim brojem razvodnika
poruka.
Na primer, ako je FTP servis obezbeen sa etiri servera; interfejs server, IP server, TCP server i FTP
server, onda su potrebne etiri poruke i etiri razvodnika poruka da bi se primio paket podataka. Osim
toga, ako je komunikacija izmeu procesa i njihov rasporeiva baziran na prenosu poruka, ova
optereenja mogu biti jo vea.
Da bi savladali ove nedostatke, mikrokerneli su dizajnirani da minimiziraju i interprocesnu komunikaciju i
optereenja razvodnicima prekida.

RC 4000
Mikrokernel RC 4000 je najraniji mikrokernel dizajniran kao vieprogramski sistem koji moe biti korien
kao osnova razliitih operativnih sistema. Definie apstrakciju sekvencionalnih procesa, komunikacionih
poruka i memorijskog dela. Osim toga, obezbeuje mehanizam za upravljanje procesom, interprocesnu
komunikaciju, proces rasporeivanja i ulazno-izlaznu manipulaciju.
Vana karakteristika sistema RC 4000 je hijerarhijska organizacija procesa koji su bazirani na relaciji
roditelj-dete. Ovo omoguuje jedan od sledeih pravila za kontrolu procesa i upravljanje resursom:
-

proces moe kontrolisati samo njegove procese decu

proces moe dodeliti resurse samo njegovim dete procesima

Kada se sistem startuje, sve resurse poseduje inicijalni operativni sistem. On moe kreirati druge procese
i dodeliti njima svoje resurse. Kada se dete proces zavri, svi njegovi resursi se vraaju roditelju.

12.4 Upravljanje procesima

Proces je najvanija apstrakcija mikrokernela RC 4000. Realno, postoje dve vrste; unutranji procesi, koji
predstavljaju izvrni program i spoljanji procesi, koji su apstrakcija ulazno-izlaznog ureaja.
Unutranji procesi formiraju procesnu hijerarhiju. Kad god proces kreira novi, on postaje njegov roditelj i
zbog toga ga moe zaustavljati, modifikovati, nastavljati i brisati. Ovo je osnovno pravilo kontrole procesa.
Unutranji procesi su rasporeeni od strane mikrokernela na principu "svaki-sa-svakim". Ovo je primer
kratkorone politike. Potom, roditelj proces moe modifikovati rasporeivanje procesa pomou
zaustavljanja procesa i nastavljanja procesa.
Ako se na unutranje i spoljanje procese ukazuje njihovim indetifikatoima mogue je zameniti spoljanji
proces unutranjim. Ovo moe biti korieno za testiranje programa bez prisustva odreenih ureaja,
kontrole pristupa ili korisnikog zahteva.

12.5 Upravljanje memorijom

Zatita memorije je bazirana na zatitnom kljuu i zatitnom registru. Svaka memorijska re je povezana
sa zatitnim kljuem i svaki proces ima zatitni registar. Kada proces pristupi memorijskoj rei, monitor
proverava da li je bit na poziciji kljua u zatitnom registru postavljen. Ako nije, tj. kada je zatitno pravilo
narueno, proces e biti iskljuen.
Kada roditelj kreira novi proces, on specificira deo njegovog memorijskog prostora gde dete moe
pristupiti i vrednost zatitnog kljua ove oblasti i vrednost detetovog zatitnog registra.
Ako roditelj proces moe kontrolisati njegove procese decu, on moe stvoriti mnogostruki memorijski
prostor izmeu njih. Na primer, kada postoji nedostatak memorije, on moe zaustaviti jednog od njegovih

roditelja, sauvati njegovu memoriju i koristiti je. Kasnije, kada dodatna memorija bude dostupna, on
moe uitati prethodni sadraj i nastaviti proces.

12.6 Meuprocesna komunikacija

Da bi procesi mogli saraivati oni moraju komunicirati. RC 4000 obezbeuje dva naina asinhronog
slanja poruka. Poiljalac formira poruku i alje primaocu. Primaoc prima poruku, obrauje zahtev i alje
odgovor, koji konano prima orginalni poiljalac.
Kada proces hoe da primi ili poruku ili odgovor koji jo nije poslat, on biva blokiran dok drugi proces ne
izvri operaciju slanja.

12.7 Ulaz/izlaz
Svi dostupni I/O ureaji su vieni kao spoljanji procesi. Da bi zapoeo I/O operaciju, proces formira
zahtev i alje ga odreenom spoljanjem procesu. Kada kernel primi zahtev, on startuje I/O operaciju.
Kada je to zavreno, kernel alje odgovor.
Ako je procesu potreban ekskluzivni pristup I/O ureaju, moe da iskoristi mehanizam rezervacije
spoljanjeg procesa. Kada je spoljanji proces rezervisan on odbija sve zahteve sem onih od procesa koji
ga je rezervisao. Kada je proces zavren, kernel oslobaa sve rezervacije koje je proces napravio.

12.8 U235
U235 je eksperimentalni mikrokernel, koji obezbeuje minimalni skup apstrakcija i mehanizama za
upravljanje procesima, upravljanje memorijom i upravljanje procesorom. Koristei ovo, sekvencionalni
procesi mogu primeniti veliki broj servisa razliite vrste, kvaliteta i dostupnosti. Na primer, oni mogu
primeniti distribuirani servis deljive memorije, daljinski vremenski servis ili servis rasporeivanja u
realnom vremenu.
Mogue je stvoriti razliite vrste operativnih sistema nad U235 microkernelom. Na primer, ako su
memorijski servis i proces rasporeivanja dostupni samo lokalnim procesima, i ako ovaj servis
zadovoljava zahteve u realnom vremenu, moe se napraviti centralizovan, operativni sistem koji radi u
realnom vremenu. Slino, ako su servisi dostupni udaljenim procesima, moe se napraviti mreni
operativni sistem.

12.8.1 Procesi i domeni

Sekvencionalni proces je definisan kao apstrakcija raunanja i domen je definisan kao apstrakcija
raunskog okruenja u kojima se procesi izvravaju. Domen ukljuuje memorijski prostor i ulazno/izlazni
prostor. Memorijski prostor je definisan kao skup memorijskih rei koje proces moe da ita ili pie.
Slino, ulazno/izlazni prostor je definisan kao skup ulazno/izlaznih portova kojima proces moe pristupiti.
Svaki proces je izveden u nekom domenu, tj. moe pristupiti njegovom i memorijskom i ulazno/izlaznom
prostoru.
Procesi izvedeni u istom domenu dele sve resurse domena, tj. dele podatke, programe ili mogu pristupiti
istim ulazno/izlaznim portovima. Kada je novi proces kreiran, njegov roditelj formulie domen u kojem
proces treba da se izvrava.
Osim toga, procesi izvedeni u razliitim domenima su prilino nezavisni i mogu uticati jedan na drugoga
samo upotrebljavanjem razliitih mehanizama. Ovo je glavni razlog zbog kojeg su domeni uvedeni.

12.8.2 Meuprocesna komunikacija

Procesima je potrebna sinhronizacija i komunikacija. U235 microkernel obezbeuje dva naina procesne
komunikacije. Ako su procesi izvedeni u istom domenu dele njegov memorijski prostor, oni mogu
komunicirati itanjem i pisanjem poruka iz/u ovaj prostor. Ovo je prirodna i efikasna vrsta interprocesne
komunikacije. Kada procesi ele da komuniciraju izmeu sebe u razliitim domenima, mogu da koriste
mehanizam sinhronog slanja poruka. Ovo je optiji ali manje efikasan nain interprocesne komunikacije.

Poto je komunikacija preko slanja poruka sinhrona, proces e biti blokiran ako pokua da primi poruku
koja jo nije poslata ili ako pokua da poalje poruku koju proces ne oekuje. Ove dodatne osobine mogu
biti iskoriene za procesnu sinhronizaciju.

12.8.3 Upravljanje memorijom

Da bi upravljao memorijskim prostorom, svaki domen je povezan sa odreenim procesom - memorijski
straninik. On je odgovoran za manipulaciju sa straninim grekama, dodeljivanje procesa memoriji i
dodeljivanje kernela memoriji. Da bi dozvolio bilo kojem procesu da upravlja resursima memorije, U235
mokrokernel obezbeuje apstrakciju memorijske strane i mehanizam za njihovo mapiranje i demapiranje.
Kada doe do straninih greaka, preduzimaju se sledei koraci:
-

kada proces uputi nemapiranu memorijsku stranu, on alje zahtev njegovom straniniku. On
sadri informacije o vrsti greke kao i adresu greke

kada straninik primi zahtev, analizira razlog stranine greke. Ako proces narui memorijsko
zatitno pravilo, straninik moe da uniti proces. Inae, straninik nalazi slobodnu memorijsku
stranu, puni je sa odgovarajuim podacima i smeta u memorijski prostor greaka procesa. Ako
straninik nema slobodnu memorijsku stranu, moe da premesti u ve korienu.

kada je defektna memorijska strana mapirana, proces moe da nastavi izvrenje.

12.9 Proces rasporeivanja

Da bi procesi mogli da se izvravaju, mora im prvo biti dat procesor. Ovo je zadatak odreenog procesa rasporeivaa. Svaki proces je povezan sa jednim takvim procesom. Da bi dozvolio svakom procesu da
deluje kao rasporeiva, microkernel definie apstrakciju vremenskog kvantuma i mehanizam za
dodeljivanje njega drugom procesu.
Sledei scenario opisuje korake koje proces preduzima da bi rasporedio druge procese:
-

rasporeiva dodeljuje vremenski kvantum jednom od njegovih rasporeivaa. Rasporeiva

dodeljuje minimum njegovog vremenskog kvantuma i dodeljeni vremenski kvantum. Dodeljivanje
vremenskog kvantuma prouzrokuje zaustavljanje rasporeivaa i proces kome je procesor
dodeljen nastavlja

proces se izvrava dok se ne blokira, ili dok prati dodeljenu vremensku porciju. Kada se jedan od
ovih dogaaja desi proces alje poruku njegovom rasporeivau. Ona sadri razne informacije o
upotrebi procesora.

rasporeiva prima poruku i moe da rasporedi sledei proces

Ova apstrakcija i mehanizam se moe koristiti za implementaciju ogromnog broja politike rasporeivanja.
Na primer, sasvim je mogue imati skup procesa rasporeenih pomou politike svaki-sa-svakim i drugi
skup procesa rasporeenih pomou FIFO algoritma.

13 CORBA

Implementacija aplikacije zahteva od razvojnih timova da brinu o upravljanju deljivim resursima servera
(kao to je memorija ili procesorsko vreme), da brinu o upravljanju kontekstom ili rukovanju nitima (eng.
Thread).
To je krupan zahtev koji moe u mnogome usporiti razvoj aplikacije, jer bi se svaka transakcija
programirala. Takve transakcije se nazivaju programirane (eng. Programmatic transactions). Aplikacije
koje ih koriste su teke i skupe za odravanje. To je jedan od razloga zato je razvoj komponentnih
modela postao popularan i doiveo veliki razvoj poslednjih godina. Komponente kojima je implementiran
mehanizam izvravanja transakcija, na ovaj nain se mogu koristiti u pravljenju novih aplikacija.
Komponentni model omoguava lake izmene i odravanje. S druge strane skrauje se vreme potrebno
za implementaciju jer postoje razliite gotove komponente koje se mogu iskoristiti. Ovakav pristup
implementaciji transakcija se naziva deklarativnim pristupom. Programeri su osloboeni brige o realizaciji
mehanizama za kontrolu izvrenja transakcija.
Trenutno najpopularniji komponentni modeli su COM+ (eng. Component Object Model), EJB (eng.
Enterprise Java Beans) i CORBA.

13.1 OMA (Object Managment Arhitecture)

Core Object Model
-

definie OO koncept na kojem su specifikacije arhitekture CORBA napravljene

OMA Referent Architecture

-

osnovni okvir za distribuirane heterogene objektno orjentisane tehnologije

13. 2 The OMA Reference Arhitecture

Object Request Broker (ORB)
-

kima itave arhitekture, koja spaja druge komponente. ORB obezbeuje komunikaciju izmeu
komponenti u distribuiranom okruenju razmenom zahteva i odgovora

Object Services
-

osnovni servis sa standardnim interfejsom, koji programeri mogu koristiti za rad sa distribuiranim
objektima (tj. servis adresiranja, razmena, istrajnost)

opte osobine
-

domen objektnih interfejsa za aplikacije (osobina internacionalizacije, vremenska osobina)

domen interfejsa
-

standardizovani objektni interfejsi karakteristini za specifinu aplikaciju (telekomunikacije,

elektronska trgovina)

objekti aplikacije
-

objekt specifian za odreene aplikacije (ovaj deo nije stardadizovan od OMG)

13.3 Common Object Request Broker Arhitecture (CORBA)

CORBA je industrijski standard za distribuirane aplikacije koji je definisao OMG (Object Management
Group). OMG pokuava da pretvori u stvarnost ideju o mogunosti da se komponente softvera mogu
koristiti ako su ve jednom napisane, ili da se mogu kupiti gotove od drugih proizvoaa.Ovaj standard
definie interfejs koji bi trebalo da omogui da komponente pisane u razliitim jezicima meusobno
sarauju. To je ostvareno definisanjem seta metoda koje su vidljive za ostale komponente.
Od poetka je zamiljeno da komponente mogu da budu postavljene na razliite vorove u mrei. Bez
obzira da li su na istom serveru ili su distribuirane kroz mreu, komponente komuniciraju zahvaljujui
uslugama ORB (eng. Object Request Broker). Klijent i server CORBA komponente slobodno komuniciraju
kroz mreu i pozivaju udaljene funkcije. To je upravo ono to je neophodno za ostvarenje koncepta
aplikativnog servera kao srednjeg sloja u kome izvrenje posla aplikacije zavisi od ispunjenja zahteva
upuenog serveru koji je zaduen za logiku aplikacije. CORBA dakle predstavlja model koji potpuno
podrava ideju troslojne arhitekture, koja po prirodi ima aplikaciju distribuiranu izmeu klijenta,
aplikativnog servera i servera baze podataka.
Osnovna komponenta OMA arhitekture je ORB, ija funkcionalnost je specificirana u arhitekturi CORBA.
To je objektna magistrala, koja omoguuje transparentni zahtev prenosa na lokalne ili udaljene objekte i
takoe prima odgovore. Ovo okruenje je nezavisno od programskog jezika, operativnog sistema ili
hardver platforme.

13. 4 Object Request Broker (ORB)

ORB ima mehanizam za poziv udaljenih procedura (RPC), kojim za komponente potpuno maskira mreu
i sve komunikacione tehnologije ispod, ime omoguava da se pozivi funkcija vre kao da su lokalni bez
obzira gde se nalaze. Ni klijent ni server na taj nain vie ne moraju brinuti o lokaciji, jeziku na kome je
komponenta pisana niti o nainu na koji se vri transport podataka kroz mreu (prikazano na slici).
ORB moe biti implementiran kao proces na host-u kojem klijent pristupa, kao proces na nekom
centralnom raunaru kroz koji klijent i server komuniciraju, ili kao servis operativnog sistema. U
komunikaciji se koristi IIOP protokol (eng. Internet Inter-ORB Protocol).

K lije n t

S e rv e r

O dgovor

Z a h te v

P r o s le e n
z a h te v

P r o s le e n
odgovor

O b je c t R e q u s t B r o k r ( O R B )

Struktura ORB-a

Dinamiki
interfejs
zahteva

IDL
stubs

ORB
interfejs

IDL
skelet

ORB jezgo
ORB zavisni interfejs
Standardni interfejs
Prema-objektni tip generisanog interfejsa
Ovde moe biti viestukih objektnih adaptera

Dinamiki
interfejs

Objektni

skel
adapter
et

13. 5 Jezik za definiciju interfejsa

Opisuje interfejse objekata arhitekture CORBA koji su neophodni za uspenu transparentnu
komunikaciju. Klijent poziva samo metode interfejsa definisane u IDL-u i implementacija ovih metoda je
potpuno nezavisna od interfejsa.
IDL specifikacija je kompajlirana pomou IDL kompajlera u ciljnom jeziku, korienom za implementaciju
CORBA objekata. Ovde je jezik vezan za razliite programske jezike (C, C++, Java, Smalltalk, Ada95,
COBOL,...)
Osnovni pojmovi IDL jezika
-

moduli

tipovi

interfejsi

operacije

atributi

naslee (jednostruko, viestruko)

izuzeci

13. 6 CORBA meuoperativnost

Odaljeni objekat arhitekture CORBA je predstavljen u adresnom prostoru klijenta pomou stubsa, koji
organizuju parametre i operacije i komuniciraju sa jezgrom ORB-a. Sa strane servera ORB gura primljene
poruke u skelet, koji deorganizuje operaciju i parametre i poziva implementaciju CORBA objekta.
Poruka razmenjena izneu klijenta i servera je specificirana pomou Internet Inter-ORB protokola (IIOP),
koji koristi TCP/IP kao protokol prenosa i osigurava meuoperativnost ORB-ova razliitih proizvoaa.
IIOP je specifian sluaj optijeg General Inter-ORB protokola (GIOP).
Ako je, za vreme klijentove ili serverove kompilacije, interfejs nepoznat, CORBA obezbeuje Dinamiki
Zahtevni Interfejs (DZI) za klijenta i Dinamiki Skelet Interfejs (DSI) za server za "runo" generisanje
zahteva za operacijama.
Za transparentno upuivanje udaljenih objekata koristi se Interoperable Object References (IOR).

13. 7 CORBA servis adresiranja

Obezbeuje mapiranje izmeu imena i objekta upuivanja.
IOR su sastavljeni od predmeta indetifikacije (imena) razumljivih ljudima to obezbeuje stalno prisutan
mehanizam identifikacije.

Klijen
t
Apple
t

Klijent Application
Server
Prox
y

Proxy

resolve()
CORBA adresiranje Service
NamingContex
t

ObjectImpl
unbind(
bind( )

13. 8 Resursi arhitekture CORBA

Object Menagment Group

-

http://www.omg.org

CORBA
-

http://www.corba.org

Literatura
[1] Koncepti operativnih sistema,Ji afak, STU Bratislava, 1999.
[2] Konkurentno programiranje, folije, Marko Vukovi, FON 1984.
[3] Operativni sistemi i konkurentno programiranje, skripta,Boidar Radenkovi, FON 2000