1. Distribuiran program. Razlike u odnosu na paralelan program.

Distribuirano programiranje je jedan od dva osnovna pristupa za postizanje konkurentnosti. U distribuiranom

programiranju(DP) program koristi isti princip paralelnog programiranja(PP),ali procesi mogu biti,za razliku od
paralelnog programa, u razlicitim racunarima. Distribuirani program nekad rade u paraleli.(2. Slike,slajd 8,9).


2. Prednosti I mane distribuiranih programa

DP omogucava server da koristi resurse locirane na racunarskoj mrezi. Program moze da pristupi hardveru drugog
racunara ili dobije uslugu od softvera drugog racunara. Moguc je pristup velikoj kolicini informacija koja prevazilazi
kapacitete jednog racunara. Omogucena je veca procesorska(racunarska) moc. Mana distr. programa je manja
brzina u odnosu na paralelni program.


3. Distribuirano programiranje I konkurentnost

Za dogadjaje kazemo das u konkurenti ako se pojave u istom vremenskom interval(VI). Zadaci koji se izvrsavaju u
istom VI su konkurentni zadaci. Konkurentnost se koristi da bi program uradio vise tokom istog
perioda,istovremeno opsluzivao vise korisnika,bio jenostavniji. Dobrim dizajnom,program se moze podeliti na
zadatke koji se mogu izvrsavati jednovremeno. DP je jedan od osnovnih pristupa za postizanje konkurentnosti.
Procesi koji se izvrsavaju mogu(a ne moraju) biti u razlicitim racunarima. Konkurentnost se moze javiti u vise
nivoa:1. nivo instrukcije(delovi instrukcije se mogu paralelno izvrsiti); 2.nivo funkcije/procedure(funkcionalne
celine se izvrsavaju jednovremeno); 3.nivo objekta(vise objekata ucestvuje u resavanju zadatka); 4.nivo
aplikacije(nekoliko aplikacija moze saradjivati u resavanju istog problema).


4. Distribuiran raunarski sistem ( definicija, primeri primene)

Distribuiran sistem je mnotvo povezanih raunara koje korisnik doivljava kao jedan skladan sistem. Sastoji se od
hardvera tj. mnotva raunara povezanih komunikacionom mreom a radi kao skladan sistem zahvaljujudi softveru.
Distribuiran sistem integrie razliite aplikacije koje se izvravaju na razliitim raunarima u jedan sistem i on je
zapravo suprotan centralizovanom sistemu.
Primeri aplikacija u distribuiranom sistemu su:
Sistem mobilne telefonije
GPS sistem sa brojnim primenama
World Wide Web model distribuiranih dokumenata
Nadzorno upravljaki sistemi u industriji ( SCADA)
Sistem elektronskog pladanja
Raunarsko poslovanje velike kompanije


5. Osobine distribuiranog sistema

Dobre osobine distribuiranog sistema su:
Razlike meu raunarima i nain komunikacije sakriven je od korisnika
Korisnici i aplikacije interaguju sa distribuiranim sistemom na konzistentan i jednoobrazan nain bez obzira na
mesto i vreme interakcije
Lako se proiruje
podrava heterogene raunare i mree jer ima softver slojevito organizovan

Loe osobine DS-a su:
Veoma sloen softver
Umanjene performanse zadataka koji se mogu obaviti u jednom raunaru zbog trajanja komunikacije
Teorijski zahtevi koji se postavljaju pred DS se ne mogu u potpunosti realizovati (dobro ovo ali onda
posledino loe ono)


6. Ciljevi distribuiranog sistema: povezivanje, transparencija, otvorenost, skalabilnost.

Povezivanje korisnika i udaljenih resursa podrazumeva deljenje ureaja (tampaa, skenera, diska...), razmenu
datoteka, rad na daljinu ( telekonferencije, elektronska trgovina). Bezbednost sistema je veoma vana.
DS je transparentan kada ga korisnici i aplikacije doivljavaju kao jedan raunarski sistem.
Postoje razliiti tipovi transparentnosti prema.
Pristupu-skriva razlike u predstavi ( reprezentaciji) podataka
Npr. Little-big endian format brojeva
Lokaciji-korisnik ne zna gde se resurs fiziki nalazi
Npr. Ne znas gde je server na kojem je neki sajt
Migraciji-resursi se mogu premetati bez uticaja na korisnike
Isti program pokrenem danas na prvom raunaru a sutra na drugom
Relokaciji-odnosi se na premetanje resursa tokom upotrebe
Dok se program izvrava skoi (program) s jedne na drugu mainu
Replikaciji-sakriva postojanje kopija resursa koje postoje zbog eventualne otpornosti sistema na otkaze
Konkurentnosti-prividno istovremena upotreba deljenih resursa tj. da ne vidimo da nismo jedini na sistemu
Otkazima-DS se neprimetno oporavi od nepravilnog rada resursa
Perzistenciji-sakriva se gde je resurs sauvan ( u RAM-u ili na disku)
Iako je transparentnost poeljna nekad nije dobro sakrivati aspekte distribuiranosti od klijenta jer treba
uzeti u obzir realnost. Recimo zahtev da 24 SATA stignu u elektronsko sandue u 7 ujutru nema smisla kad smo u
vremenskoj zoni daleko od mesta tampanja.
Uglavnom postoji balans izmeu visoke transparentnosti i brzine rada
Na primer mnoge internet aplikacije predugo pokuavaju da uspostave vezu sa serverom pre nego to se obrate
drugom serveru.
Otvorenost
Otvoren DS prua servise (usluge) po standardnim pravilima ( i sintaksnim i semantikim)
Servisi se obino specificiraju preko interfejsa
Sintaksa interfejsa se opisuje IDL-om a semantika servisa se neformalno opisuje
Uvoenje interfejsa omoguduje da proces kome treba usluga moe komunicirati sa procesom koji implementira
servis i da postoje razliite implementacije servisa o emu korisnik ne brine.
Dobro definisan interfejs je kompletan,neutralan (implementacioni detalji nisu spolja vidljivi,
interoperabilan( delovi razliitih proizvoaa mogu da rade zajedno i komuniciraju preko interfejsa) i portabilan
to znai da se aplikacija razvijana za jedan sistem moe izvravati bez modifikacija na drugom sistemu koji ima iste
interfejse.
Otvoren sistem je fleksibilan jer je orgabizovan preko mnotva malih komponenti koje se mogu lako
zameniti ili izmeniti (prilagoditi) i jer komponente implementiraju poznate interfejse.
Skalabilnost
se odnosi na rast odnosno na:
dodavanje novih korisnika i resursa
geografsko proirenje sistema (pristup sa udaljenih mesta)
ouvanje jednostavne administracije sistema iako se sistem proiruje.
Skalabilan je u suprotnosti sa centralizovan jer:
Centralizovan servis se izvrava samo na jednom serveru
Centralizovani podaci se nalaze samo na jednom mestu
Centralizovan algoritam-odluka se donosi samo na osnovu kompletne informacije.

7. Tipovi distribuiranih sistema (klaster, grid computing).

Tipovi distribuiranih sistema su:
Distribuirani sistemi za intenzivno racunanje koji obicno izvrsavaju jednu aplikaciju, a to su klaster i grid computing.
Distribuirani informacioni sistemi i
Distribuirani rasplinuti (pervasive) sistemi
Klaster se tipicno upotrebljava u sistemima gde postoji potreba za intenzivnim racunanjem-vise racunara
radi u paraleli.
Jedan racunar nema nama dovoljnu snagu a klaster cini nekoliko slicnih (cesto identicnih) racunara
smestenih na jednoj lokaciji. Oni izvrsavaju isti operativni sistem i povezani su u istu mrezu. Ceo klaster se logicki
ponasa kao jedan racunar.
Grid computing predstavlja veci broj dislociranih racunara koji ucestvuju u racunanju. Ti racunari se
razlikuju u hardveru, operativnom sistemu, mrezi, administraciji, bezbednosti i organizovani su u virtualnu
organizaciju iako fizicki pripadaju razlicitim organizacijama.
Arhitektura grid computing sistema je slojevita. Komunikacioni protokoli omogucuju transakcije u gridu.


8. Povezivanje aplikacija (procesiranje distribuiranih transakcija, globalna integracija aplikacija).

Procesiranje transakcija je tipicno prisutno u aplikacijama koje rade sa bazama podataka. Tipican scenario
integracije je sledeci:
Mrezna aplikacija se sastoji ood jednog ili vise servera. Udaljeni programi (klijenti) upucuju zahteve serverima.
Nekoliko zahteva klijenata se objedinjuje u jedan veci zahtev koji se izvrsava kao distribuirana transakcija.
Procesiranje transakcija se zasniva na nekoliko osnovnih operacija ( primitiva ):
Begin_transaction, end_transaction ( banka na primer ne sme da ne zavrsi transakciju da bi se imalo pravo stanje
na racunu u svakom trenutku), abort_transaction-prekida transakciju i restaurira stare vrednosti, read, write.
Osobine transakcija su:
Atomicnost-prema spoljasnjem svetu transakcija je nedeljiva
Konzistentnost-transakcija ne narusava ispravnost podataka
Izolovanost-istovremene transakcije ne uticu jedna na drugu
Postojanost-kada se transakcija uspesno zavrsi promene koje je izazvala postaju trajne.
Omogucene su i ugnjezdene transakcije.
Osnovna transakcija sadrzi vise podtransakcija sto je prirodan nacin podele posla u DS. Podtransakcije mogu
postojati u vise nivoa. Prekidanje podtransakcije restaurira stare vrednosti u svim drugim podtransakcijama( iako
su se izvrsile bez gresaka).
Monitor procesiranja transakcije je komponenta koja izvrsava distribuiranu transakciju.
Globalna integracija aplikacija
Middleware posreduje u povezivanju aplikacija-softverska magistrala-Enterprise Service bus (ESB)
Service Oriented Architecture (SOA) je savremen koncept gde serverske aplikacije pruzaju usluge-servise, klijent
aplikacije su korisnici usluga i servisi i korisnici usluga su slabo povezani. Koristi se komunikacija zasnovana na
porukama (Message Oriented Middleware).


9. Softverska i sistemska arhitektura?

Treba razlikovati
Logiku organizaciju softverskih komponenti Softverska arhitektura
Podela posla u DS(distribuirani sistemi) po celinama komponentama

Fiziku realizaciju softverskih komponenti Sistemska arhitektura
Realizacija gde se primerci komponenti rasporeuju na stvarne raunare
Softverske komponente:
Komponenta je modularna softverska jedinica
Sa jasno definisanim interfejsom
Implementacija je izmenjiva
Softverske komponente su gradivne jedinice DS
Komponente su povezane i razmenjuju podatke
Nain povezivanja komponenti definie stil softverske arhitekture
Sistemske arhitekture:

Govori o fizikom rasporedu komponenti
Organizacije komponenti
Centralizovana organizacija (klijent,server)
Decentralizovana organizacija(vertikialna distribucija,horizontalna distribucija)
meovita


10. Stilovi softverske arhitekture(slojevita,objektno-orijentisana,)?

Cilj je da se uspostavi distribuciona transparentnost.Otezavaju poteskoce koje se odnose na:
- Performanse
-Tolerantnost otkaza
Lakocu programiranja
...
Vani stilovi arhitekture DS:
1. Slojevite arhitekture - Layered architectures
2. Objektno-orijentisane arhitekture - Object-based architectures
3. Podacima usresreene arhitekture - Data-centered architectures
4. Arhitekture zasnovane na dogaajima - Event-based architectures
Ne postoji jedan stil koji se moe upotrebiti u vecini DS.

1. Slojevita arhitektura

Komponente su organizovane po slojevima
Postoji hijerarhija slojeva
Samo susedni slojevi komuniciraju


2. Objektno-orijentisana arhitektura

Slobodnija organizacija komponenti u odnosu na slojevitu arhitekturu
Svaki objekat odgovara komponenti
Objekti su tipino dislocirani i komuniciraju upotrebom Remote
Procedure Call (RPC)
Veze su po modelu klijent-server

3.Podacima usresreena arhitektura:

Komponente (tanije, procesi) komuniciraju preko zajednikih skladita podataka
Aktivnih ili pasivnih
Postoje implementacije DS gde se sva komunikacija odvija preko deljenih datoteka.
4. Arhitektura zasnovana na dogaajima:

Komponente komuniciraju (uglavnom) preko propagacije dogaaja
Pri tome se prenose i podaci koji se odnose na dogaaj
Ovi DS se nazivaju i Publish/Subscribe sistemi
Neke komponente emituju poruke
Druge komponente primaju poruke
pretplate se na neke tipove poruka i onda samo takve poruke primaju
Middleware se brine o mehanizmima razmene poruka
Efekat je slaba povezanost komponenti
Komponente ne moraju eksplicitno da se obracaju jedna drugoj


11. Centralizovana arhitektura. Klijent-server model ?

- Poznatija kao Klijent-Server model
-Ucesnici su dve komponente(procesa):
Server - implementira sevis
Klijent koristi uslugu servisa
-Upit-odgovor ponaanje


Klijent server arhitekture:
-Fizicka dvoslojna arhitektura(klijent-server) ima svoje alternative


12. Viseslojna arhitektura.Middleware?

-Slojevitost prati loginu organizaciju aplikacije
- esto se koristi troslojna arhitektura softvera:
1. sloj korisnikog interfejsa
(UI User Interface)
unos i prikaz podataka
2. sloj obrade (processing)
obrada zahteva ili rezultata
3. sloj podataka (data)
skladitenje (perzistencija)
podataka
Komunikacija izmeu slojeva se odvija po Klijent-Server modelu


Middleware
Middleware je sloj izmeu distribuiranih aplikacija i platformi(operativnih sistema)
Treba da pomogne u postizanju (distributivne) transparentnosti
Sakriva
Distribuiranost podataka
Distribuiranost procesiranja
Upravljanje iz aplikacija
Postojeci middleware-i su pratili specifine stilove u arhitekturi
OMG CORBA; Microsof DCOM adaptiran objektno-orijentisan stil
TIBCO prati stil arhitekture zasnovane na dogaajima
...
Upotreba middleware namece arhitektonski stil
Savremena reenja DS trae prilagodljiv middleware


13. Procesi i niti u distribuiranom sistemu

Gledano sa strane operativnog sistema(OP),proces je program koji se izvrava.Zadatak OS-a je da rukuje i
rasporeuje procese na izvrenje.A gledano sa strane procesa(dok ga OP opsluuje),proces ima utisak da je
procesor samo njegov.OP brzo smenjuje procese u izvrenju,tako da se stie utisak jednovremenog rada ili ti
multitaskinga.
Nijedan valjan posao nemoemo poeti bez resursa,a oni su tu da se troe i dele,pa stim u vezi vie
procesa moe koristiti isti resurs,a OP je tu da nam da nam da mehanizam za pristup deljenim resursima.
Procesi i Niti
Proces
-izvrava program
-Stanje procesa (Kontekst procesa) je veliko
*CPU kontekst
*Memoriskem mape,modifikovanje registara u MMU
*informacije za upravljanje procesima npr.blokiranje na mutex-u.
*otvorene datoteke ,brojake(statistike)informacije,privilegije...

Nit(Thread)
-Izvrava deo zadatka procesa-takoe se prikljuuje na procesor.
-Kontekst niti je manji od konteksta procesa
*OS ga bre sauva i restaurira
Procesi i niti u Distribuiranom sistemu
Efikasna organizacija klijent-server veze zahteva vie programskih niti
-Jednovremeno izvravanje komunikacije i lokalne obrade podataka
Klijent sa vie niti
-Viestruke komunikacije sa blokirajudim pozivima
-Izdvojena obrada podataka koji pristiu
-Jednovremeno pribavljanje podataka od vie servera
-Primer:Web browser
Server sa vie niti
-Jednovremeno obsluivanje vie klijenata
-(ostale ved navedene prednosti)


14. Niti i dizajn server

Server je proces koji prua neku uslugu klijentima(servis)
-eka na zahtev klijenta
-procesira zahtev
-eka na novi zahtev
Organizacija servera
-Iterativan server sam obrauje zahtev i vrada rezultat
-Konkurentan server-zahtev prosleuje drugoj niti/procesu i odmah je spreman da prihvata novi
zahtev


15. Objektno orijentisana arhitektura servera.Adapter objekat

Unutar servera postije lokalni objekti koji pruaju usluge
-Relativno je jednostavno iriti skup usluga dodavanjem novih objekata
Poseban objekat prihvata pozive klijenata i prosleuje ih (rasporeuje) lokalnim objektima
-Politike aktivacije-pre poziva metode kod objekata se moraju uitati
*npr.objekat postoji samo tokom poziva klijenta
*npr.objekat se smeta u izolovani adresni prostor
-Politika u odnosu na niti
1.Jedna kontrolna nit za ceo server(najjednostavniji pristup)
2.Za svaki objekat posebna nit
-Server prosleuje poziv niti objekta
-Ako je nit zauzeta,novi poziv se privremeno stavlja u red.
-Serijalizacija poziva metoda objekta Jednostavna implementacija
3.Svaki poziv u zasebnoj niti
-Metode implementiraju zatitu od konkurentnog pristupa
Adapter objekta
Jedan server moe imati vie politika aktivacija u isto vreme
-Sprovode ih adapteri objekta
Adapter objekta
-implementira odreenu politiku aktivacije (moe se konfigurisati)
-je generika komponenta(ima jednostavan interfejs koji ne zavisi od interfejsa objekta)
-moe upravljati sa vie objekata


16. Migracija koda i softverski agenti

Razlog migracije koda
-prebacivanje sa opteredenog na neoptereden CPU
-esto se minimizuju komunikacije (a ne opteredenje CPU-a)
*primer:obrada velikog broja DB podataka se moe preseliti na server
Modeli migracije koda
-Weak mobility Nakon prenosa proces se pokrede od poetka
*primer:Java applet
-Strong mobility-Proces se privremeno zaustavi,prenese i nastavi da radi
Problemi migracije
-Pristum lokalnim resursima
*Kod koji koristi lokalni resurse se nekada nemoe migrirati
-Heterogeni sistemi(drugaiji hardver)
*upotreba skript jezika i virtualne maine (npr.java,c#)


Softverski agenti
Softverski agenti su autonomne jedinice sposobne da obavljaju zadatke u saradnji sa drugim agentima(po
mogudnosti sa udaljenim)
-Agent je proces
-Sposoban je da preuzme inicijativu
*npr.agenti koji dogovaraju sastanak
Agentska tehnologija predstavlja osnovu za rad agenata
-Podrane su migracije


17. Slojevitost komunikacionog protokola. OSI model.

ISO referentni model - pojednostavljuje dogovaranje kod prenosa poruke.
Protokoli odreuju pravila (standardna)
Format poruka; Sadraj; Znaenje poruka
Promene u jednom sloju ne utiu na druge slojeve.
OSI model Open Systems Interconnection Reference Model
Uveden radi razumevanja raunarskih mrea
Protokoli razvijeni kao deo OSI modela , nisu iroko upotrebljeni
OSI model omogucava komunikacije u otvorenom sistemu. Ima 7 slojeva-protokol stack: svaki se odnosi na
poseban aspekt i svaki ima interfejs ka gornjrm nivou.
Pri slanju poruke svaki sloj doda svoj header koji se kod prijema uklanja.
1.Fiziki sloj: bavi se prenosom 0 i 1 alje bite. Ne daje zaglavlje tokom slanja, bavi se hardwerskim
informacijama. Standardizuje elektrine, mehanike i signalne interfejse i odreuje napon, brzinu prenosa,
obostranost slanja, veliinu i oblik konektora, broj i znaenje pinova.
2.Data-link sloj: detekcija greaka u prenosu i ispravka, grupie bite u frame-ove. Postavlja bit-pattern na poetku i
na kraju, dodaje checksum kontrolu i redni broj poruke u zaglavlje frame-a.
3.Mreni sloj: Bavi se rutiranjem poruka, ali najkradi put ne znai i najbolji, na put poruke utie: kanjenje, gustina
saobradaja, broj poruka koje su spremne za slanje i te promjene su dinamine. Primjer: IP, ATM.
4.Transportni protokoli:Namjena je isporuiti poruku do odredita. Reuzima poruku od vieg sloja, razbija je na
djelove, svakom djelu dodaje redni broj i alje. Zaglavlje sadri informacije o: koji djelovi su poslati, koji su
primljeni, koje treba ponovo poslati, koliki je prihvatni prostor na prijemnoj strani.
Connection oriented: prvo se uspostavlja veza i vri dogovor oko daljih protokala, npr. telegonski razgovor.
TCP- pouzdan u svakoj mrei.
Connectionless- pimjer slanja pisma potom.
UDP- neznatno proiruje IP, potrebna dodatna kontrola greke i prenosa paketa.
TCP/UDP su pogodni za klijent-server model.


18. Povezivanje klijenta i servera.

Server se registruje, a klijent locira raunar-treba mu IP adresa i proces u okviru maine-treba mu endpoint(port).
Sve ovo se deava na aplikacionom nivou, primjer je kalkulator.


19. Komunikacija upotrebom Berkeley Sockets.

To je biblioteka f-ja koja omogudava slanje I prijem poruka preko Internet transportnih protokola.
Socket je endpoint(port) u koji aplikacija upisuje podatke, i iz njega se mogu itati podaci.
Socket rutine za TCP/IP:
socket kreira novi endpoint
bind povee lokalnu adresu sa soketom
listen objavi spremnost prihvatanja konekcija
accept blokira dok se ne pojavi zahtev za konekcijom
connect namerava da uspostavi konekciju
send alje podatke preko konekcije
receive prima podatke preko konekcije
close oslobaa konekciju
Server de napraviti vie niti za vie klijenata, jedna glavna i druge koje komuniciraju, to je kod TCP-a. Kod UDP-a je
mnogo jednostavnije.


20. Remote Procedure Call (proireni RPC, asinhroni RPC).

Posmatramo na jo viem nivou apstrahovanja. Ovo je protokol za pozivanje procedura iz udaljene maine, treba
da lii na poziv lokalne procedure.
Upotreba stub-ova. Primjer inverzne matrice.
Sinhroni poziv:
Potekode koje rjeava su: izvravanje koda u dvije maine, prosleivanje ulaznih parametara i rezultata kroz
mreu, predstava brojeva, prenos po reference, prenos sloenih struktura.
Koraci RPC-a:
1. Klijent poziva klijent stub na normalan nain
2. Klient stub formira poruku i poziva OS
3. Klijent OS alje poruku u server OS
4. Server OS predaje poruku server stub-u
5. Server stub otpakuje parametre i poziva metodu servera
6. Server izvrava metodu i vrada rezultat stub-u
7. Server stub pakuje odgovor u poruku u predaj u OS
8. Server OS salje poruku u klijent OS
9. Klijent OS predaje odogovor klijent stub-u
10. Klijent stub raspakuje odgovor i predaje klijent program

Proireni RPC model:
Originalni RPC razmenjuje poruke izmeu raunara
Zbog transparentnosti RPC se moe upotrebiti i za lokalne pozive
Efikasnije je koristiti Interprocess Communication (IPC) umesto slanja
poruka u okviru jednog raunara
Upotebom proirenog RPC modela nema razlika izmeu lokalnih i
udaljenih poziva
Migracija koda se lako sprovodi
Asinhroni RPC:
Da klijent saopti neto serveru, ne treba mu povratni rezultat, sporiji je od sinhronog, klijent je rastereden.


21. Povezivanje na udaljeni objekat.

Remote Method Invocation (RMI) je naziv za pozivanje metoda
udaljenog objekta (zasnovan na RPC)
Postoje stub-ovi nazvani: Proxy i Skeleton
Povezivanjem na udaljeni objekat se kreira referenca na objekat
Preko reference se pozivaju metode objekta
Reference se mogu prenositi izmeu procesa na razliitim mainama

22. Komunikacija zasnovana na porukama (Messaging).

RPC i RMI
Su jedan nain komunikacije u DS
Nisu uvek pogodni( mora da se pogodi server I port)
Messaging je drugi nain
Komunkacija zasnovana na porukama, jedan dogadjaj -> jedna poruka. Tu se koristi mehanizam dojava.

23. Perzistencija i sinhronizam u komunikaciji.

Hostovi (poiljaoc i primaoc) su povezani mreom

a) Persistent asynchronous communication
b) Persistent synchronous communication

c) Transient asynchronous communication
d) Receipt-based transient synchronous communication

e) Delivery-based transient synchronous communication
f) Response-based transient synchronous communication



24. Message-Oriented Middleware (MOM).

Koristi message- orjentisanu perzistentnu komunikaciju. Ovdje postoji skladistenje poruka i ne zahtjeva se da
posiljaoc ili primalac poruka bude aktivan.
Osnovna ideja :
Kod slanja poruka se upisuju u red poruka
Poruka se prenosi do odredita preko niza servera
Isporuka u odredite eka da ono bude raspoloivo (spremno)
Posledice:
poruka de biti isporuena, ali se ne zna kada
ne garantuje se da de biti proitana (ili obraena)
Svaka aplikacija ima svoj red za poruka koje cita , a druge aplikacije u njega salju poruke. Vise aplikacija moye citati
isti red poruka.

-Dobra strana MOM-a je slaba povezanost posiljaoca I primaoca:
- Primaoc ne mora da radi kada se pruka salje
- Ppsiljaoc ne mora da radi kada seporuka obradjuje
- Posiljaoc i primaoc rade nezavisno
-Adresa odredista treba da je poznata = adresa reda poruka
-Postoji ogranicenje na velicinu poruke
-Osnovne rutine:
Put- dodaj poruku u red
Get- blokiraj ako je red prazan, inace izvadi prvu poruku
Poll- provjeri da li ima poruka I ako ima izvadi prvu
Notify- postavi metodu koja ce biti pozvana kada pristigne poruka
-Adresa reda poruka se mapira na adresu
maine
- Rutiranje poruka omogudava MOM
Preko adaptivne eme mapiranja u ruterima
- Omogucavaju
Sekundarno procesiranje (razlozi: fault tolerance, security)
Transformisanje
sadraja poruke
Multicast poruke


25. Imena entiteta u distribuiranom sistemu (upotreba, tip, prostor imena, putanja).

Sinhronizacija.
-Imena se koriste za oznaavanje i referenciranje entiteta.
-Postoje tri tipa imena:1.Adresa ime access point-a entiteta; 2. Identifikator; 3. itljiva adresa (human-friendly
name) kao tekst;
-Imena se organizuju u prostor imena (name space).Prostor imena se predstavlja imenovanim grafom.vor
predstavlja entitet.Naziv grane je ime po kome se entitet poznaje.Direktorijum je vor koji ima vie odlaznih grana
kolekcija entiteta.
-Putanja je niz naziva koji referenciraju entitet


26. Utvrivanje redosleda dogaaja. Sinhronizacija logikog vremena.

-Utvrivanje redosleda dogaaja odnosi se na sinhronizaciju rada distribuiranih procesa. Problem: Nema globalno
poznatog sata, tj.procesi na razliitim mainama imaju sopstvenu predstavu o vremenu.
-Sinhronizacija logikog vremena - Poznavanje tanog vremena nije od presudnog znaaja ved je bitno da se
dogaaji u razliitim procesima deavaju u eljenom redosledu.
-Lamport je uveo logiki asovnik. Grupa distribuiranih procesa se moe dogovoriti o redosledu dogaaja.
Algoritam daje nain utvrivanja globalnog redosleda dogaaja. Svakom dogaaju E se dodeljuje globalna logika
vremenska znaka (timestamp) C(E). Informacije o vremenu se prenose porukama gde slanje poruke svakako
prethodi njenom prijemu. Pravila:
1. Ako dogaaj A prethodi B (u istom procesu) tada je C(A) < C(B)
2. Ako je A slanje, a B prijem poruke tada je C(A) < C(B)
3.


27. Delenje resursa i meusobna iskljuivost. Algoritmi za dodelu pristupa.

-U mnogo sluajeva procesi jednovremenopristupaju istom resursu. Meusobna iskljuivost (mutual exclusion) u
pristupu procesa treba da sprei korumpiranje resursa (da bi njegovi podaci ostali konzistentni). Obezbeuje da u
svakom trenutku pristup deljenom resursu ima samo jedan proces. Primenjuju se sinhronizacioni algoritmi.
-Postoje brojni algoritmi:
1) Zasnovani na dozvoli pristupa
Centralizovana odluka preko koordinatora
Decentralizovana odluka
Distribuirna odluka
2) Zasnovani na prosleivanju token-a
Svi algoritmi su osetljivi na greke u komunikaciji i otkaze u procesima.


28. Sinhronizacija upotrebom koordinatora. Izbor koordinatora. Replikacija i konzistencija
podataka.

-Sinhronizacija procesa obino zahteva postojanje koordinatora(dodatni proces)
Posveden proces (nepromenljiv)i dinamiki izabran proces.
Prvenstveno je bitan ako posveden koordinator moe da zataji.
Dinamiki koordinator treba da bude izabran.Potrebno je da se procesi dogovore koji proces de biti koordinatotor.
Postoji nekoliko algoritama za izbor:Bully algoritam i algoritam prstena.
Bully algoritam:Preduslov je da svi procesi imaju jedinstven broj (prioritet). Proces P shvati da nema koordinatora i
pokrene izbore. alje poruku izbori svim procesima vedeg broja.
Ako niko ne odgovori on se promovie u koordinatora. Onome ko odgovori se predaje uloga inicijatora.
Algoritam prstena: Preduslov je procesi se nalaze u lancu (fizikom ili logikom) i imaju
brojeve (prioritete). Proces P shvati da nema koordinatora pokrene izbore. alje poruku u koju svaki P ubacuje svoj
broj. Kada se krug zatvori P odredi koordinatora sa najviim prioritetom i obavesti sve procese (poalje novu
poruku).
- Postoje dva dobra razloga za replikaciju podataka: Povedanje pouzdanosti sistema
i poboljanje performansi.Repliciracija zahteva kopiranje podataka kroz mreu(Potreban je balans: brzina pristupa /
opteredenje mree) pa se radja problem konzistentosti. Kada se podaci replike promene tada replika postaje
drugaija. Promene u replikama se moraju propagirati.
Da bi se replike ouvale konzistentnim neophodno je propagirati promene tako da privremene nekonzistentnosti
nisu uoljive.


29. Replikacija podataka

Postoje dva dobra razloga za replikaciju podataka:
-povecanje pouzdanosti sistema(ako se jedna replica osteti,mogu se koristiti podaci iz drugih replika)
-poboljsanje performansi(podaci se premestaju blize procesu koji ih koristi)
Replikacija zahteva kopiranje podataka kroz mrezu,pa je potreban balans izmedju brzine pristupa I opterecenja
mreze. Replikacija radja problem konzistentonsti:
-kada se podaci sa replike promene I replica postaje drugacija;
-promene u replikama se moraju propagirati,a time se obaraju performance sistema;
-da bi se replike ocuvale konzistentnim neophodno je propagirati promene tako da privremene nekonzistentnosti
nisu uocljive;
-Replikacija kao tehnika skaliranja:
Skalabilan system podrazumeva I bolje performanse,odnosno upsljavanje vise procesa koji rade sa kopijama
podataka. Sinhrona replikacija podrazumeva da se promena podataka propagira u sve kopije kao jedna ,,atomska
operacija-transakcija. Tada treba sinhronizovati redosled promena nastalih na raznim mestima. Takodje,sinhrona
transakcija podrazumeva dosta komunikacija. Sve ovo sinhronu replikaciju cini ,,skupom,te je prakticno resenje u
smanjenju njenih ogranicenja.


30. Konzistencija podataka. Modeli konzistencije.

Konzistencija se odnosi na operacije citanja I pisanja nad deljenim podacima u skladistu podataka(Data Store).
Postoje (distribuirana) deljena memorija,(distribuirana) deljena baza podataka,(distribuiran) deljen system
datoteka(File System). Svaki process koji pristupa podacima ima lokalnu kopiju celog skladista-repliku. Operacija
koja menja podatke je operacija zapisa(Write). Ona se propagira u svim replikama. Ostale operacije su tipa Read.
-Model konzistencije
Model konzistencije je ugovor procesa I lokalnog skladista podataka. Ako process postuje pravila,skladiste podatka
ce biti korektno(npr. Nakon operacije write,read treba da vrati ono sto je promenjeno). Osnovni modeli
konzistencije su:Kontinualna konzistencija I konzistentan redosled operacija.
Cilj kontinualne konzistencije je da se postave granice na:
-dozvoljene razlike u numerickim vrednostima izmedju replika(primer: vrednosti merenje u sistemu za nadzor se
stalno menjaju zbog prisutnog suma,ali merni uredjaji imaju konacnu tacnost).
-maksimalno dozvoljena odlaganja osvezavanja podataka. Definise se period u kome se smatra da je replika
konzistenta iako se tokom tog perioda dogadjaju promene vrednosti(primer:merenja se ocitavaju brze nego sto je
klijentu potrebno).
-dozvoljene razlike u redosledu operacija:definise se maksimalan dozvoljen broj privremenih zapisa(promena) u
serveru koji cekaju na sinhronizaciju sa serverima ostalih replika.
Konzistentan redosled operacija je osnova za brojne modele konzistencije medju kojima su:
-sekvencijalna konzistencija-obzbedjuje da se sve write operacije svuda vide u istom redosledu;
-uzrocna(kauzalna)konzistenicja:obezbedjuje da operacije koje potencijalno zavise jedna od druge moraju biti
primenjene prema zahtevanom redosledu;
Modeli klijent centricne konzistencije. Oni su bitni za mobilne klijente(pretpostavlja se da se isti klijent povezuje na
razlicite replike). Ne razmatra se slucaj da se podaci dele izmedju vise klijenata vec se razmatra konzistentnost
podataka prem samo jednom klijentu. U osnovi,ovi modeli obezbedjuju da klijent uvek zatekne stanje koje je
poslednje ostavio cak I kada se poveze na novu repliku.


31. Protokoli distribucije promena u replike(modeli propagacija. Push/Pull protokoli.
Unicast/multicast propagiranja promena).

Replikacija podataka pravi kopije. Za implementaaciju distribuiranog skladista potrebno je znati: gde se vrsi
replikacija,kada se vrsi,ko je vrsi. Tipovi replika:stalne(permanentne),server-inicirane,klijent-inicirane.(nisam pisao
o svakoj posebno,cini mi se da se pitanje ne odnosi na to).
Propagiranje promena. Promena izazvana klijentom se prenosi u kopiju. Nadalje promena propagira u ostale
kopije. Ne moraju se sve replike trenutno izmeniti!
Mogucnosti:
-propagira obavestenje da je nastala promena;
-prenose se podaci sa kopije na kopiju;
-prenose se operacije (koje prave izmene) sa kopije na kopiju;
Propagacija obavestenja:Obicno se navodi koji deo podatka je promenjen. Kda se pristupa podacima koji su
oznaceni kao promenjeni(nisu vlaidni) prvo se moraju osveziti. Zbog velikog broja dojava moze da optereti mrezu.
Propagacija podataka:korisno je kada je Read/Write veliko (?!?!?!). mogu se beleziti samo promene I one slatiu
kopije-pogodno je pakovanje vise promena u jednu poruku.
Propagacija operacija:slanje operacija koje ce u kopijama izazvati istu promenu podataka. Prenose se I parametri
operacija. Kod slozenih operacija,nekad je jednostavnije poslati rezultate.
Push/Pull protokoli
Moguci su: Push modeli-slanje promena; Pull modeli-ocitavanje promena; Lease-hibridni model.
Push model salje promene u kopije(replike) I kada one to ne traze. Primenjuje se kada se zahteva visok stepen
konzistencije-identicne replike. Model je efikasan kada je read/write odnos visok u svakoj replici.
Pull model:zahteva od drugog server da posalje podatke. Primena je kod kes klijenta. Efikasan za mali read/write
odnos.
Unicast/Multicast propagiranja promena. Multicast je pogodan za osvezavanje vise replica na LAN-u. Multicast je
zapravo slanje poruke na vise adresa-racunara. Unicast je pogodnije kada postoji jedan klijent.


32. Sistem tolerantan na otkaze (osobina, cilj).

Osobina distribuiranog sistema (DS) je postojanje dinamikog otkaza (kja ih razlikuje od sistema na jednoj maini).
Dinamiki otkaz nastaje kada deo sistema (komponente) zakae. Otkaz dela sistema moe da loe utie na rad
ostatka sistema dok za neke delove sistema je potpunoi ne bitan. Sistem moe da prui servis i kada postoje uzroci
greka.
Cilj je da se dizajnira DS tako da se sistem moe automatski oporaviti od deliminog otkaza. Pri tome se ne smeju
ozbiljno naruiti performanse sistema, tj. u prisustvu deliminog otkaza sistem treba da nastavi sa radom (na
prihvatljiv nain). Sa ovim dobijamo sistem tolerantan na otkaze fault tolerant. U tesnoj vezi je sa pojmom
pouzdanosti dependable systems.


33. Osobina distribuiranog sistema: raspoloivost, pouzdanost, sigurnst, odravnost.

Pojam dependable (pouzdanost) ukljuuje zahteve DS-a:
Raspoloivost: osobina sistema da radi bez geke. Definie se verovatnoda da sistem radi bez greke u
svakom trenutku. Odnosi se na trenutak.
Pouzdanost: osobina da sistem radi kontinualno bez pojave greke. Odnsi se na period.
Sigurnost: privremen otkaz ne prouzrokuje katastrofu. Potrbna u sistemima velikog rizika, teko se
postie.
Odrivost: koliko brzo se sitem moe popraviti.


34. Uzroci greaka i tipovi otkaza. Problem klijent-server komunikacije.

Dependable system je usko povezan sa kontrolom uzroka grekea:
- Prevencija uzroka greke
- Otklanjanje uzroka greke
- Predvianje uzroka greke
Klasifikacija uzroka greaka:
- Prolazni: jednom se pojavi i nestane. Jednostavano se prevazilaze ponavljanjem operacije.
- Povremeni: pojavljuju se s vremena na vreme. Teko se otkrivaju.
- Trajni: postoje dok se deo sistema ne popravi. Softverska greka, pregoreo ip...


35. Skrivanje otkaza upotrbom redudanse. Grupa procesa. Atomski mutkiaksting.

U fault tolerant sistemu najbolje je skriti otkaz od drugih procesa. Kljuna tehnika je upotreba redudanse
(suvinosti):
- Suvinost imformacija (dodatni bit, npr. Hamingov kod, kontrola suma...)
- Suvinost u vremenu (akcija se ponavlja, npr. ne uspela komunikacija)
- Fizika suvinost (u hardveru i/ili softveru)
U DS-u procesi se repliciraju u grupe procesa. Ideja: kada se poruka poalje grupi svi procesi je moraju primiti i ako
neki od procesa zakae, oekije se da de neki drugi proces preuzeti poruku i obraditi je. Grupa procesa moe biti
dinamika: proces moe napustiti grupu i/ili se pridruiti nekoj grupi; proces moe pripadati u vie grupa
jednovremeno. Organizacija grupe procesa: a) grupa ravnopravinih uesnika (simetrina, nema signal single-point-
failure, sloena implementacija). b) hijerarhijski organizovana (otkaz koordinatora pravi problem).
Atomski multikasting: svi procesi moraju primiti poruku. Problem prisutan kod npr. replikacije podataka. Poruka se
dostavlja svim procesima ili nikome (redosled poruka je bitan). Proces pada i ponovo se pokrede: dovodi se u
stanje pre pada; alju mu se poruke koje su u meuvremenu posate; ponovno pokretanje procesa zahteva da se
ponovo nae u grupi.


36. Distribuirani Commit oritikol. Dvofazni i trofazni Cimmit protokol.

Distribuirani Commit je jo iri problem od atomskog mulrikstinga. Pored pouzdane poruke treba primiti operaciju
u svakom lanu grupe ili nigde. Obino se reava uz pomod koordinatora, koordinator (K) 1 proces, uesnici (P)
pstali procesi. Alogoritam: dvofazni Commit protokol (2Phase Commit 2PC), trofazni Commit protokol (3PC).
Dvofazni Commit protokol ima dve faze po dva koraka:
1.) Lokalna primena. K alje poruku VOTE_REQUEST svim P da pokuaju da primene promene. P priprema
promene u lokalnom skladitu podataka (vrada VOTE_COMMIT ako je sve u redu ili VOTE_ABORT).
2.) Globalna primene K eka na rezultate lokalne primene. K alje GLOBAL_COMMIT ili GLOBAL_ABORT. P
na osnovu poruke K lokalno primenjuje promene ili ih odbacuje.
Dijagram stanja:
a) Koordinatora: b) Uesnika:
Slike...
Nakon pada nekog od procesa, oekuje se da se on ponovo pokrene i na osnovu zabeleenog poslednjeg stanja
nastavlja sa radom. Kada istekne time-out u stanju READY, znai da je K pao. P moe ekati K da se oporavi ili P
moe upitati proces Q u kom je stanju i doneti odluku (prema donjoj tabeli):

Stanje procesa Q Akcija ''zbunjenog'' procesa P
COMMIT Zavrava transakciju COMMIT
ABORT Prekini transakciju ABORT
INIT Prekini transakciju ABORT
WAIT Kontaktiraj drugi proces (iz grupe)

Trofaznog Commit:
Problem sa 2PC nastaje kada koordinator padne. Sutina 3PC je da se dodaje novo stanje PRECOMMIT koje
omogudava da procesi donesu odluku pre nego se koordinator oporavi. Algoritam se retko implementira. Dijagram
stanja:
a) Koordinatora b) Uesnika
Slike....


37. Oporavka od otkaza (Checkpoint, beleenje poruka,postojano skladite podataka).

Nakon otkaza proces treba da se oporavi i dovede u korektno stanje. Rekonstrukciju stanja omogudavaju
Checkpoint-i i beleenje poruka. Sutina oporavka od greki je zameniti: stanje sa grekom -> stanjem bez greke.
Strategije:
- Oporavak u nazad (Backward). Stanje sistema se povremeno belei checkpointi. Trai se stanje pre
nastanka greke. Problem: 1) traje; 2) moda ponovo nastane greka; 3) neostvarivo.
- Oporavak unapred (Foreward). Sistem se iz stanja sa grekom prevodi u novo korektno stanje. Problem:
moraju se unapred znati mogude greke.
Checkpoint omogdava oporavak u prethodno korektno stanje (skupa operacija, izbegavaju se esta snimanja
stanja). Kombinuje se sa beleenjem poruka koje nemaju stanje (Checkpoint se ree prai, poaljaoc belei poruku
pre nego je poalje, primaoc belei poruku pre nego je prosledi aplikaciji, oporavak: a) uita stanje iz Checkpoint-a;
b) pripremi poruke nastale posle snimanja stanja)
Postojano skladite podataka slui za sigurno skladitenje stanja procesa. Tip skladita u RAM-u nije postojano, na
disku nije postojano ako disk otkae , postojano skladite preivljava sve sem prirodnih katastrofa. Relacija
postojanog skladita 2 diska. Sekvencijalno se zapisuju promene.
Formiranje Checkpoint-a: Oporavak moe zahtevati da se vie procesa postavi u ranije stanje. Potreban je
distribuirani snapshot stanja recovery line. Na osnovu nezavisno formiranih checkpoint-a process teko pronalazi
recovery line -> Domine efekat.
Formiranje koordinisanog Checkpoint-a: Procesi koordinisano snimanj svoje stanje u lokalno stabilno skladite,
snimlje stanje je globalno konzistentno (nema Domino efekta). Implementacija Dvofazni blokirajudi protocol:
1.) K multicast poruku CHECKPOINT_REQUEST svim p
o Svaki P: napravi lokani Checkpoint, belei sve naknadne poruke, poalje potvrdu K, eka na
CHECKPOINT_DONE.
o K eka na potvrdu od svih P
2.) K poalje CHECKPOINT_DONE svim P.
Beleenje poruka: Koje nam sve informacije trebaju da bismo ponovo poslali poruku? Gubitak informacije -> nema
korektnog oporavka procesa, nastaje process siroe. Informacije su u zaglavlju poruke: poaljilac, primaoc, redni
broj poruke (potreban kod duplikata), redni broj isporuke opcija (kada se poruka isporuuje). Postojana poruka
== poruka zaspisana u postojano skladite.


38. Pogodnosti i primena distribuiranih upravljakih sistema

Ovi sistemi su nastali krajem 70-god,i od tada se neprekidno razvijaju rastu

*Primene je sledeca :
postrojenja procesne industrije
hemijska i petrohemijska postrojenja, rafinerije nafte, eljezare i eliane,itd.
proizvodna postrojenja
energetska postrojenja
automatka sloenijih laboratorijskih postrojenja
nova proizvodna postrojenja i
revitalizacija postojedih postrojenja

*Pogodnosti DRUS-a je:
Primenjuje se zbog povedanja:
produktivnosti proizvodnje
kvaliteta proizvoda
sigurnosti i raspoloivosti postrojenja
fleksibilnosti rada postrojenja
kvaliteta uvida u rad postrojenja
Povedanje automatike kod postrojenja i procesa
Primene novih:
raunarskih i komunikacijskih tehnologija
naprednih metoda automatskog upravljanja
Sprovodi se hijerarhijskom arhitekturom
Funkcionalna arhitektura
Fizika arhitektur


39. Hijerarhijska arhitektura distribuiranih upravljakih sistema

Opte je prihvadena
Omogudava funkcionalnu dekompoziciju na nekoliko nivoa,a to su:
Nivo 4: voenja preduzeda
Nivo 3: voenja proizvodnje
Nivo 2: voenje postrojenja/procesa
Nivo 1 : lokalno upravljanje i regulacija
Nivo 0: tehniki proces
Hijerarhijski nivo pokrede i nadzire izvoenje funkcija automatike nieg nivoa i pokrede se i nadzire funkcijama
automatike nadreenog nivoa

Lokalno upravljanje i regulacija Nivo 1
Akvizicija procesnih veliina
prikupljanje trenutnih vrednosti mernih veliina i stanja komponenata postrojenja (npr. stanja pumpi,
ventilator ,sl.)
neophodna za upravljanje procesom u otvorenoj i/ili zatvorenoj petlji, nadzor
procesa, izradu izvetaja o stanju procesa
Nadzor procesa/postrojenja i provera ispravnosti sistema
procesiranje prikupljenih podataka, proveravanje njihove prihvatljivosti, donoenje odluka o akcijama
koje treba preduzeti, provera funkcionalnosti raunara i periferija, alarmiranje, dojavljivanje greaka i neispravnih
stanja.
Sekvencijalno upravljanje i upravljanje u zatvorenoj petlji

Voenje postrojenja/procesa Nivo 2
odreivanje optimalnih radnih uslova procesa
Implementiraju se funkcije:
Optimalno upravljanje procesom
Optimizacija se sprovodi na osnovu matematikog modela procesa, a prema nekom kriterijumu
optimalnosti
koji treba da osigura optimalan rad procesa/postrojenja u promenljivim radnim uslovima.
Adaptivno upravljanje
Na osnovu merenih vrednosti procesnih veliina estimiraju se parametric matematikog modela procesa iz
kojih se zatim izraunavaju optimalne vrednosti parametara regulatora.
Optimalna koordinacija rada postrojenja
Sprovodi se na osnovu: produktivnosti proizvodnje, stanja sirovina, stanja skladita proizvedene robe,
cene energije i dodatnih kriterijuma optimalnosti.
Nadzor, skladitenje i izvetavanje
Nadzor performansi postrojenja, skladitenje podataka i izvetavanje o stanju.

Voenje proizvodnje Nivo 3
odreivanje redosleda proizvodnje (production scheduling) za jedinice proizvodnog postrojenja u zaisnosti od:
- narudbi kupaca
-stanja zaliha
-energetskih ogranienja i zahteva.
sprovodi se promenom redosleda proizvodnje i promenom proizvodnog programa
-Sofisticirane tehnike koordinacije rada proizvodnog postrojenja
- Podruje operacionih istraivanja, a ne automatskog upravljanja
Nadzor celokupnog proizvodnog postrojenja
izrada izvetaja
Najvii nivo manjih proizvodnih postrojenja

Voenje preduzeda Nivo 4
Najvii nivo sloenih industrijskih postrojenja
obuhvadeni inenjerski, ekonomski, komercijalni i kadrovski aspekti voenja preduzeda.
Softverski sistem za optimalno planiranje proizvodnje
sloena optimizacija plana proizvodnje u promjenljivim radnim i trinim uslovima
Koordinacija: menadmenta, odelenja prodaje, nabavke, raunovodstva I pogonskog osoblja.
Tipine funkcije su:
analiza trita
prikupljanje podataka o kupcima
statistika narudbi
planiranje prodaje i proizvodnje
ugovaranje
prihvatanje narudbi i provera rokova
koordinacija rada proizvodnih postrojenja
izraunavanje cena
uravnoteivanje proizvodnih kapaciteta i narudbi
deoba narudbi
pradenje rokova proizvodnje i isporuke
izvetaji o proizvodnji, narudbama i ugovorima
izvetaji o produktivnosti, prodanosti, dobiti/gubitku i sl.


40. Fizika i funkcionalna arhitektura sistema

Fizika i funkcionalna arhitektura
Funkcionalna arhitektura i fizika arhitektura sistema nisu iste
Fizika arhitektura je sabirniki orijentisana
esto se funkcije dva ili vie funkcionalnih nivoa implementiraju u jednom fizikom nivou
Dobija se jednostavniji DS

Fizika - Sabirniki orijentisana arhitektura
Tipino tri komunikacione mree,a to su :
1) Fieldbus
Povezivanje upravljakih ureaja sa pametnim senzorima i izvrnim organima
2) Upravljaka mrea na nivou postrojenja
Povezivanje vie upravljakih ureaja (i SCADA sistema)
3) Poslovna magistrala
Povezivanje upravljakog sistema sa ostalim aplikacijam

Jednostavna sabirnika arhitektura
Smanjuje cenu i trokove odravanja
Dva fizika nivoa (dve mree) u manjim proizvodnim postrojenjima
1. Funkcije niih slojeva: lokalno upravljanje
-automatika u nivoima 1 i 2
2. Funkcije viih slojeva: kombinacija voenja postrojenja i proizvodnje
- voenje preduzeda se izvodi na izdvojenom (nezavisnom) raunarskom sistemu
Jedna mrea za sve
-Jo jednostavnije

Jedinstven distribuiran sistem
Jedinstven distribuiran sistem povezuje brojne aplikacije
- Informacija se unosi/nastaje jednom (u jednoj aplikaciji)
- Informaciju koriste druge aplikacije
-Objedinjeno reavanje problema (saradnja aplikacija)
esto se naziva Informacioni sistem
Oteano je povezivanje aplikacija
Svaka aplikacija ima svoj model podataka
Postoje razliite softverske tehnologije (komunikacije, ...)
Aplikacije su pisane od strane raznih proizvoaa
Uvode se specifikacije i standardi radi olakanog povezivanja aplikacija


41. OPC (ideja, arhitektura, specifikacije, mesta primene)

Ideja OPC-a
OPC = OLE for Process Control
OLE = Object Linking and Embedding
OPC komponente: OPC klijenti i OPC serveri. Tipian klijent je MMI
Serveri su izvori podataka, oni prikupljaju/alju podatke iz upravljakih uredjaja i pripremaju ih za klijente, mogu
biti upotrebljeni za realizaciju jezgra SCADA softvera.
OPC specifikacije definiu grupe programskih interfejsa putem kojih se pristupa OPC serverima (distribuiranim
objektima)
Specifikacije:
Pristup trenutnim vrednostima veliina: OPC DA - Data Access, OPC XML DA, OPC DX Data Exchange
Pristup istorijskim vrednostima veliina: OPC HDA - Historical Data Access
Pristup alarmima i dogadjajima u sistemu: OPC AE - Alarms and Events
Posredno upravljanje
Bezbednost sistema
Mesta primene su: Povezivanje komponenti distribuiranog upravljakog
sistema, pristup podacima postojedeg upravljakog sistema, pristup podacima upravljakih uredjaja
(mernoakvizicionih uredjaja)...


42. OPC server

OPC Data Access Server
Omogudava brz pristup trenutnim vrednostima veliina
Pored vrednosti oitavaju se i vremenska znaka (timestamp) i
kvalitet vrednosti, veliine mogu imati dodatne podatke, osobine poput: granice
vrednosti, in. jedinica, granice alarma, ...
Sinhroni i asinhroni pristup vrednostima: oitavanje i
zapis. Sinhroni pristup je namenjen jednostavnim klijentima koji pristupaju malom broju veliina. Asinhroni pristup
minimizuje upotrebu CPU i mree
Klijenti mogu grupisati veliine prema potrebi. Na nivou grupe veliina se omogudava: kontinualna konzistencija
podataka (deadband, update rate), pretplata na promene vrednosti veliina - PUSH model sinhronizacije.
Server: Prua informacije o serveru odrava grupe veliina
Grupa (veliina): Manipulie podacima o sebi, sadri mehanizme za
logiko organizovanje veliina
OPC Historical Data Access Server
Opisuju interfejse bitne za: skladitenje vrednosti veliina, oitavanje ranije prikupljenih/skladitenih vrednosti
Specifikacije predvidjaju postojanje: jednostavnijih servera koji bi implementirali samo osnovne funkcionalnosti
istorijskog servera, sloenih servera kod kojih se vre filtracije podataka, statistika obrada, kompresija podataka i
sl.
I ovde je predvidjen mehanizam dojave kao najefikasniji nain prenosa podataka izmedju klijenata i servera.
Postoje veliine i imaju osobine (kao u OPC DA). Klijent specificira period od intresa
Vrednosti veliina mogu biti: Sirovi podaci (raw data), skladiteni podaci (mogu biti
kompresovani), agregirane vrednosti avg, min, max..., anotacije korisnik moe komentare dodeliti veliinama
(uz vremensku znaku) i oitati ih, interpolirani podaci vrednosti veliina dobijene linearnom interpolacijom,
modifikovane vrednosti promenjene nakon skladitenja u server
OPC Alarms & Events Server
Obavetava klijenta kada se desi dogadjaj ili alarm
vrednost parametra premai zadate granice
promene stanja opreme
U osnovi klijent se pretplati na tipove dogadjaja tako da
ga server obavetava kada se dogadjaj desi
Podrane su oblasti (Area)
Podrana su brojna filtriranja dojava, prema: EVENT tipu dogadjaja, CATEGORY kategoriji dogadjaja, SEVERITY
ozbiljnosti, AREA geografskoj oblasti gde se desio, SOURCE izvoru dogadjaja
Osnovni pojmovi iz AE:
Condition je stanje nekog objekata (ili servera)
Alarm je nenormalno stanje (condition) i tretira se kao
specijalan condition.
Dogadjaj (Event) moe, a ne mora biti uslovljen
condition-om


43. UMS Utility Management System

Sadri sofisticiran upravljaki sistem. Pomae osoblju (operaterima) da optimizuju performanse sistema, kvalitet i
sigurnost usluga
ine ga: Osnovne SCADA funkcije, aplikacije za simulaciju i analizu sistema, spoljanje aplikacije povezane sa njim
Mesto primene UMS:
Tipina mesta primene su sistemi za proizvodnju, prenos
i distribuciju vode, gasa, elektrine energije, grejanja
Tipino zasnovani na SCADA podsistemu Sturi podaci
Podaci o sistemu su smeteni u DBMS: podaci su brojni i raznorodni (dobro), DBMS je spor (loe), Integracija preko
DBMS sa drugim aplikacijama je moguda, ali oteana.
Potreba UMS-a:
Simulacije i analize ponaanja sistema:
U realnom vremenu prorauni na osnovu izmerenih podataka
Simulacije van realnog vremena: What-if analize sa proraunima, planiranja, analize istorijskih zbivanja, obuka
kadrova
Povezivanje UMS sa ostalim aplikacijama:
Potreban je jedinstven nain prenosa podataka izmedju aplikacija
DAF specificira jedan deo nain prenosa podataka izmedju
aplikacija
UMS sadri detaljne (fizike) modele sistema: Mrea, proizvodnja, zahtevi potronje.


44. Data Access Facility (DAF) specifikacija (namena, osnovni tipovi podataka, servisi)

Cilj je olakati (unaprediti) povezivanje UMS sa ostalim aplikacijama. DAF specifikacija je zasnovana na CORBA-i...
DAF se odnosi na:
Odnosi se na pribavljanje read-only podataka iz UMS: ulaznih podataka i rezultata analize, stvarna (merena) i
simulirana stanja, podaci o modelu sistema.
Omogudava integraciju sa drugim aplikacijama u nearreal-
time ili non-real-time modu
Pokriva: Pristup podacima, dojave o promenama podataka, konkurentan pristup podacima, semantiku podataka
(EPRI CIM)
DAF se NE odnosi na :specifinosti sistema, auriranje podataka sistema, definisanje meta podataka, sloenije
funkcionalnosti...
Osobine
Jednostavna implementacija, Brz odziv (visoke performanse),
DAF osnovni tipovi podataka su:
upiti i rezultati se prikazuju preko: resursa, propertija i vrednosti.
Resurs je bilo ta sa jedinstvenom identifikacijom. Opisuje se sa:
Binarnim identifikatorom (ResourceID) = 2 x 64bita
Postoji mogudnost upotrebe tekstualnog identifikatora (Uniform
Resource Identifier - URI).
Primeri:
primerak pumpe, generatora, prekidaa, opis veze elemenata, opis meta-podatka
Properti je osobina resursa koja se moe opisati. Identifijuje se binarnim identifikatorom : PropertyID ==
ResourceID
Ima domen vrednosti opseg vrednosti. Vrednost propertija je elementaran podatak, predstava se unijom
nekoliko CORBA tipova (SimpleValue)
Primeri:
Status prekidaa, lokacija elementa, broj operacija ukljuenja/iskljuenja
DAF servisi
Odnose se na implementaciju DAF specifikacije
Servisi su:
1. Realizuje upit koji vrada opis jednog ili vie resursa
2. Obezbedjuje prevodjenje identifikatora resursa (ResourceID) u
tekstualnu reprezentaciju (URI) i obratno
3. Dojava o promenama podataka
(ResourceEventSource)




45. Data Acquisition from Industrial Systems (DAIS) specifikacija (osnove osobine, namena i mesta
primene)

Efikasan real-time prenos velike koliine podataka iz
industrijskog procesa do raznih klijenata, omogudava listanje parametara i auriranje njihovih vrednosti, prenose
se on-line podaci...
Mesta upotrebe DAIS-a su: Brojni industrijski procesi
DAIS specifikacija:
OMG dokument: Zasnovana na CORBA middleware-u
Zasniva se na OPC specifikaciji: opisuje interfejse (i metode), opisuje informacioni model nain upotrebe
metoda interfejsa
Podrava semantiku modela - CIM (Common Information Model)
Odnosi se na : prenos podataka iz procesa, jednovremeni prenos velike koliine podataka do raznih klijenata
(pretplatnika), razliiti tipovi i klijenata i servera
Vrste podataka u DAIS-u su: Vrednosti veliina (measurement data access), alarmi i dogadjaji (alarms & events). Ovi
podaci su dostupni iz: Upravljake opreme PLC, RTU, kontroleri, kontrolnih centara SCADA, aplikacija - SCADA,
Management Systems
Pristup veliinama
Specifikacija sadri interfejse za: Pregled podataka u serveru, pregled opisa modela koji podrava server,
sinhrono i asinhrono itanje i zapis podataka u server, pravljenje pretplata na server i rukovanje njima, callback
interfejsi klijenta za prenos vrednosti po principu dojave (event driven mehanizmom)...
Delovi specifikacije su: DAIS Server, DAIS Data Access, DAIS Alarm & Events
Aplikacija mora implementirati:
DAIS Server
DA ili AE ili oba


55. Tipovi bezbednosnih pretnji u distribuiranim sistemima, bezbednosna politika i sigurnosni
mehanizmi

Tipovi pretnji:

Presretanje (interception) neautorizovana stranka dobije pristup podacima ili servisima. Ovde spada i ilegalno
kopiranje podataka.
Prekidanje (interruption) servis ili podatak postane nedostupan, neupotrebljiv ili uniten. Npr. denial of service
(DoS)
Modifikacija (modification) neautorizovana izmena podataka ili izmena servisa, koji vie nije u skladu sa
specifikacijom
Fabrikacija (fabrication) generisanje dodatnih podataka ili aktivnosti koji ne bi postojali u normalnim
situacijama. Npr. ilegalno ponavljanje ranijeg zahteva za prenos novca ili dodavanja zapisa u datoteku sa lozinkama

Bezbednosna politika (security policy) sistema tano opisuje ta je
entitetima (korisnici, servisi, podaci, maine) u sistemu dozvoljeno i ta nije. Sprovodi se sigurnosnim
mehanizmima.

Kada je definisana sigurnosna politika za odreeni sistem, mogude je predi na odabir sigurnosnih mehanizama
kojima de se ta politika obezbediti:

Enkripcija (encryption) transformie podatke u format koji nije razumljiv za napadae
Autentifikacija (authentication) verifikacija identiteta korisnika, klijenata, servera, itd.
Autorizacija (authorization) provera da li entitet ima pravo na izvravanje odreene akcije
Beleenje istorijata aktivnosti (auditing) upisivanje u dnevnike dogaaja (uglavnom tekstualne) koji je entitet
emu pristupio i na koji nain.

56. Dizajn (planiranje) bezbednog sistema

Distribuirani sistem, kao i svaki raunar, treba da ima irok dijapazon bezbednosnih mehanizama preko kojih je
mogude primeniti razliite bezbednosne politike.

Kod planiranja bezbednosnog sistema je bitna:
Zatita (distribuiranih) aplikacija preko kontrole pristupa
Slojevitost sigurnosnih mehanizama
Jednostavnost

Kod kontrole pristupa imamo tri mogudnosti:

1. Naglasak na podacima
Najvanije kod ovog pristupa je ouvanje integriteta podataka
Nisu vane operacije koje se mogu izvravati nad podacima
Tipian primer je baza podataka koji ima razliita pravila za ouvanje integriteta
podataka koja se automatski primenjuju kada se podatak promeni
2. Naglasak na operacijama
Specificira se koje se operacije mogu izvravati i od strane kojih entiteta
Primer je server koji zna koji korisnik sme da pozove koju metodu na serverskom
objektu. Mogude su i vede granulacije, da se pristup definie na nivou interfejsa ili
ak serverskih objekata
3. Naglasak na korisnicima
Samo pojedini korisnici imaju pristup aplikacijama
Korisnici se dele u grupe prava pristupa se definiu za grupe
Jedan korisnik moe da bude lan vedeg broja grupa
Primer: u raunarskom sistemu univerziteta je pristup nekim aplikacijama mogud
samo za nastavno osoblje (ne i za studente)

Slojevitost

Distribuirani sistemi funkcioniu na slededim slojevima:
Aplikacije koje koriste distribuirane resurse
Middleware srednji sloj koji sakriva heterogenost distribuiranih sistema
Servisi operativnog sistema
Kernel (jezgro) operativnog sistema

Pitanje slojevitosti se svodi na odluku na kojem od gornjih slojevima da se implementiraju bezbednosni mehanizmi.
Ako su bezbednosni mehanizmi na viim slojevima, onda ukupna
bezbednost u mnogome zavisi od niih slojeva.

Jednostavnost

Tei se postizanju bezbednosti sa manjim brojem jednostavnih bezbednosnih mehanizama koji su
lako razumljivi i
provereno rade
Jednostavnost je naroito potrebna kod sloenih sistema, kao to su sistemi naplate:
digitalni protokoli naplate
vie entiteta se moraju dogovoriti da bi se naplata izvrila
Ako je korisnik u stanju da shvati bezbednosne mehanizme, onda je veda verovatnoda da de imati poverenje u
pouzdanost sistema


57. Enkripcija i dekripcija poruka (simetrina i asimetrina kriptografija). Hash funkcije.

Ako stranka A eli da poalje poruku m stranci B onda da bi zatitila poruku od sigurnosnih pretnji
A de izvriti enkripciju poruke m (dobija se m)
A de poslati enkriptovanu poruku (m)
B de izvriti dekodiranje poruke (m i dobide m)

Definicije
poruka (P) podatak ili deo podatka koji stranka A alje stranci B
kodirana poruka (C) poruka koja je promenjena sa ciljem da bude nerazumljiva za potencijalne napadae
klju (K) tajni podatak koji omogudava strankama da poruke ifriraju
enkripcija (kodiranje) (E) proces u kojem stranka modifikuje poruku sa ciljem da ona bude nerazumljiva za
potencijalne napadae. Rezultat
ovog procesa je kodirana poruka
dekripcija (dekodiranje) (D) proces u kojem se od kodirane poruke pravi izvorna poruka


Kodiranje poruka treba da spei akcije uljeza (pretnje bezbednosti):
presretanje, modifikaciju i fabrikaciju

Enkripcija (kodovanje)
Generie kodiranu poruku na osnovu originalne poruke i tajnog kljua C=Ek(P)
Dekripcija (dekodovanje)
Generie originalnu poruku na osnovu kodirane poruke i tajnog kljua

Nemogude je nadi klju K ako su poznate poruka P i kodirana poruka C
Nemogude je nadi drugi klju K za koji bi bilo Ek(P)=Ek(P)

Simetrina kriptografija

Isti klju za enkripciju i dekripciju
Drugo ime: kriptografski sistemi sa deljenim kljuem
Da bi komunikacija bila bezbedna, kljuevi moraju biti tajni (kao i kod svih kriptografskih sistema)
Oznaka za deljeni klju: KA,B
( ( ))
K K
P D E P =
, ,
( ( ))
A B A B
K K
P D E P =

Asimetrina kriptografija

Odvojeni kljuevi za enkripciju i dekripciju
Oznake za kljueve: KE i KD
Jedan od kljueva se uva u tajnosti
Jedan klju moe da bude javan zbog toga se ovakvi sistemi zovu
se jo i sistemi sa javnim kljuevima
Da bi komunikacija bila bezbedna, kljuevi moraju biti tajni (kao i
kod svih kriptografskih sistema)
Oznaka za javni klju strane A:
A
K
+

Oznaka za privatni klju strane A:
A
K
-

( ( ))
D E
K K
P D E P =
( ( ))
A A
K K
P D E P
- +
=

Hash funkcije

Slue za igosanje poruke prave ig na osnovu poruke
Hash funkcija H je jednosmerna funkcija
na osnovu iga se ne moe rekonstruisati poruka
Vane osobine
Slaba otpornost na koliziju za poruku m se ne moe nadi poruka m koja za koju je H(m)=H(m)
Jaka otpornost na koliziju nemogude nadi dve poruke m i m za koje de biti H(m)=H(m)
Primer: MD5 (Message Digest 5)
od poruke proizvoljne duine pravi jedinstveni 128-bitni message digest

U klijent-server modelu komunikacije u (distribuiranom) sistemu
koncepti bitni za bezbednost su:
Bezbedan komunikacioni kanal
Autorizacija uesnika kontrola pristupa
Upravljanje (menadment) bezbednostnim mehanizmima


58. Digitalni potpisi

Poverljivost (confidentiality) poruke se ne mogu prislukivati
postie se enkripcijom poruke

Integritet (integrity) poruke se ne mogu se zlonamerno promeniti.
Osigurava se:
digitalnim potpisima i
kljuevima sesija

Digitalni potpisi

Kada A poalje poruku B onda je potrebno osigurati sledede:
da strana B nede zlonamerno promeniti sadraj primljene poruke
da strana A ne moe da tvrdi da nikad nije poslala poruku
Ove dve stvari se mogu osigurati ako A digitalno potpie poruku na nain koji jedinstveno povezuje potpis sa
sadrajem poruke
Kljuna je re jedinstveno jer se na ovaj nain iskljuuje mogudnost modifikacije poruke
Mogude je jednoznano identifikovati stranu A, pa ona ne moe da tvrdi da nije poslala poruku
Postoji vie naina za digitalno potpisivanje poruka. Spomenudemo slededa dva:
potpisivanje sistemom javnih kljueva
potpisivanje message digest-om (upotrebom hash funkcije)

Kljuevi sesija

Uspenom autentifikacijom se uspostavlja bezbedan kanal
Enkripcija na tom kanalu se vri kljuem sesije
Nakon zatvaranja kanala klju sesije se unitava
Za enkripciju podataka na kanalu se koristi privremeni klju sesije
umesto kljueva kojima se uspostavlja siguran kanal iz slededih razloga:
kada se klju esto koristi, lake se razbija
titi od napada ponavljanjem prethodnih poruka
ako se i razbije klju jedne sesije, nede biti mogude dekodiranje podataka poslatih tokom ranijih (ili kasnijih) sesija
ako jedna strana ne veruje u potpunosti drugoj, onda je bolje koristiti privremene kljueve sesija


59. Bezbedan komunikacioni kanal

Za bezbednu komunikaciju je potrebno
da se zna taan identitet obe (ili vie) strane
da se ouva integritet poruka
da se ouva tajnost poruka
Za bezbednu komunikaciju je potrebno uspostavljanje bezbednog komunikacionog kanala izmeu dva (ili vie)
entiteta
Bezbedanim komunikacionim kanalom se branimo od:
presretanja,
modifikacije i
fabrikacije.
Bezbedan komunikacioni kanal nas ne brani od:
Prekidanja (interruption)
Autentifikacija je provera identiteta nekog uesnika (korisnika, procesa, raunara, itd.)
Autentifikacija i integritet poruka se ne mogu implementirati odvojeno
Autentifikacija je prvi korak kod uspostavljanja sigurnih kanala mora se utvrditi identitet svih strana (uesnika)
koje komuniciraju
Sprovoenje autentifikacije se moe zasnivati na (nekom od nabrojanih postupaka):
1. deljenim tajnim kljuevima
2. centrima za distribuciju kljueva
3. javnim kljuevima


60. Kontrola pristupa

Kad je autentifikacijom uspostavljen bezbedan komunikacioni kanal
klijent moe da pone da poziva metode na serveru
Operacije se izvravaju na resursima koje kontrolie server
Jedan klijentski poziv se uglavnom sastoji od poziva jedne metode na jednom objektu na serveru
Objekat na serveru ima svoje stanje i metode
Pozivi metoda su mogudi samo ako klijenti imaju odgovarajuda prava pristupa
Kontrola pristupa = provera prava pristupa
Autorizacija = dodela prava pristupa npr. kad se klijentu dozvoli da pozove jednu tano odreenu metodu
Gornja dva pojma se esto meaju i koriste kao sinonimi

Kontrola pristupa nekom objektu podrazumeva
zabranu pozivanja metoda od strane klijenata koji za to nemaju prava
kontrolu upravljanje objektima: kreiranje i brisanje objekata, itd.
Ako u sistemu postoji
n subjekata (koji pozivaju metode) i
m objekata (koji implementiraju metode)
onda je mogude formirati matricu M
dimenzije m*n
koja specificira za svakog klijenta ta sme da radi sa svakim objektom
Problemi ovakve matrice su
u optem sluaju je retka
kada ima puno subjekata i objekata onda je izuzetno velika
Da bi se gornji problemi matrica pristupa prevazili, razvijeni su:
liste prava pristupa (Access Control List ACL) asocirane objektima. Sadre spisak onih klijenata i njihovih prava
koji mogu pristupati objektima
dozvole (capabilities) asocirane klijentima koje sadre sva prava datog klijenta kojim objektima sme da pristupa
i koje metode da poziva
U vedim sistemima liste prava pristupa i/ili dozvole nisu dovoljni jer postaju glomazni
Kao reenje uvedeni su (bezbednosni) domeni
Domen se sastoji od ureenih parova (objekat, prava pristupa) koji
specificiraju za svaki objekat koje su dozvoljene operacije
Zahtevi za izvravanje neke operacije se uvek izdaju u domenu
Subjekat zatrai izvravanje odreene metode nekog objekta
Moguda je provera da li je operacija dozvoljena u domenu
Opte poznat primer domena su grupe korisnika
direktori kompanije u grupi direktori imaju pristup objektima i koji se odnose na finansije
ininjeri u grupe ininjeri imaju pristup objektima za upravljanje pogonom
Ako se napravi veliki broj grupa i podgrupa, onda je mogude napraviti finu granulaciju prava pristupa
Do problema dolazi kod distribuiranih baza grupa korisnika sporo je nalaenje subjekata
Reenje gornjeg problema je davanje sertifikata svakom subjektu.
Sertifikat sadri spisak svih grupa kojima subjekat pripada
Sertifikati moraju biti zatideni. Moguda je zatita digitalnim potpisom
Domeni kao uloge (role)
Korisnik se uvek prijavljuje sa ulogom u sistemu, a ona se povezuje sa privilegijama

Firewall je potreban kada je pristup (distribuiranom) sistemu omoguden i spolja (van granica sistema)
obian raunar je sistem, i razni softverski firewall programi ga tite od napada sa Interneta
Firewall je hardver ili softver koji razdvaja sistem od njegove okoline
Klasifikacija:
firewall koji filtrira mreni saobradaj - packet filtering gateway
firewall na aplikativnom sloju application-level gateway proverava i sadraj paketa, npr. email gateway koji
odbacuje poruke koje su vede od date veliine ili se okarakteriu kao spam
Sam firewall mora da bude izuzetno bezbedan
U modernim DS se kroz mreu prenosi i kod, ne samo pasivni podaci
Ovakva migracija koda rezultuje novim bezbednosnim rizicima
Potrebno je obezbediti:
da se agent (mobilan kod) koji se poalje na mreu zatiti od zlonamernih hostova (raunara)
da se hostovi (raunari) zatite od zlonamernih agenata
Ako zlonameran agent dospe na host ne sme da dobije pristup resursima tog hosta
Mehanizmi zatite hostova:
a) sandbox
b) playground
Cilj kontrole pristupa je da obezbedi da resursima distribuiranog sistema pristupaju samo autorizovani procesi
Denial of Service (DoS) i Distributed Denial of Service (DDoS) su tipovi napada iji su ciljevi da spree autorizovane
procese da pristupaju resursima
DoS napadi za cilj mogu imati
zauzimanje mrenih kapaciteta (bandwidth depletion) slanjem ogromnog broja poruka ciljnoj maini
zauzimanje resursa (resource depletion) za cilj ima da sistem koristi svoje resurse za obradu bespotrebnih
poruka, npr. TCP-SYN flooding


61. Upravljanje bezbednosnim mehanizmima

Upravljanje kljuevima
Dosad smo podrazumevali da je u trenutku kada A eli da poalje neto B onda ima na rapolaganju:
svoj par kljueva (javni i tajni)
javni klju strane B
Postavljaju se slededa pitanja:
kako se distribuiraju tajni kljuevi?
koliki je ivotni vek kljueva?
Za distribuiranje tajnih kljueva su potrebni jako sigurni mehanizmi, ili ak da se distribuiraju alternativnim
metodama (USB disk, klasina pota, itd.)
Potrebni su mehanizmi za povlaenje kljueva
npr. kada je neki tajni klju razbijen
Uspostavljanje deljenog kljua preko nesigurnog kanala (Diffie-Hellman)
Obe strane (A i B) se dogovore oko dva velika broja: n i g
A izabere svoj veliki broj x, a B svoj veliki broj y
Distribucija kljueva

Simetrini kriptografski sistemi:
Za distribuciju deljenih kljueva su potrebni bezbedni komunikacioni kanali, koji se ne mogu uspostaviti bez
kljueva
Inicijalni kljuevi se prenose alternativnim mehanizmima: telefon, floppy, USB disk, itd.
Asimetrini kriptograski sistemi:
sertifikati javnih kljueva sastoji se od javnog kljua i identifikatora entiteta kome se klju dodeljuje
i javni klju i identifikator su digitalno potpisani od strane autoriteta za sertifikate (certification authority - CA). CA
potpisuje sa svojim tajnim kljuem. Pretpostavlja se da je javni klju CA poznat javni kljuevi najpoznatijih CA su
ugraeni u Internet pretraivae.

ivotni vek sertifikata

Izdavanje doivotnih sertifikata ima svoje mane:
klju koji se dugo koristi moda se moe razbiti
Ako se neki tajni klju kompromituje, potrebno je da se on povue (revoke) tako to se objavi da odgovarajudi
sertifikat nije validan
Certificate Revocation List (CRL) sadri spisak povuenih sertifikata koji objavljuje CA
Bitna je perioda objavljivanja CRL-a: ako je dua, onda se kljuevi razbijeni od trenutka poslednjeg objavljivanja
mogu zloupotrebiti
Entiteti koji proveravaju sertifikat ne samo da moraju da ga dekodiraju, nego ga moraju uporediti i sa CRL-om
Sertifikati na Internetu uglavnom traju godinu dana i retko koji klijent proverava CRL

Upravljanje autorizacijom

Upravljanje autorizacijom se sastoji od:
Dodela prava pristupa korisnicima i grupama korisnika
Odravanje tih prava na bezbedan nain
Bitan oteavajudi faktor: resursi u distribuiranom sistemu su udaljeni
Realizacije:
centralizovano upravljanje autorizacijom centralni server autorizacije
dozvole (capabilities) svaki subjekat ima spisak svojih prava za izvravanje akcija na definisanim objektima
sertifikati atributa/autorizacije (attribute/authorization certificate)
digitalni dokument koji dozvoljava koridenje nekog servisa ili resursa
Delegacija

Delegacija je prosleivanje prava pristupa nekom servisu ili resursu
Primer
Korisnik pokrene proces A sa svojim pravima pristupa
Da bi se izvrio, proces A mora da pokrene proces B
Ako proces B mora da pristupa nekim zatidenim resursima, onda mu proces A mora proslediti odgovarajuda
prava. Ovo prosleivanje je delegacija
Distribuirani sistem treba da ima sigurnosne mehanizme preko kojih je moguda realizacija razliitih sigurnosnih
politika
Sigurnost je sloena inenjerska disciplina
Razlikujemo tri vana koncepta:
Sigurni komunikacioni kanali
Kontrola pristupa ili autorizacija
Upravljanje sigurnosnim mehanizmima