Sisteme distribuite

1. Ce este un sistem distribuit?

Definiţie: “Un sistem distribuit este o colectie de calculatoare independente
care apar utilizatorilor sistemului ca un singur calculator“(Tanenbaum, 1994)
Aspecte:
- hardware: maşinile sunt autonome
- software: utilizatorii gândesc sistemul ca un singur calculator.

Exemplul 1
- sistemul unei bănci cu sute de filiale în întreaga lume.
- fiecare filială are un server care stochează conturile locale şi tratează
tranzacţiile locale
- fiecare calculator are capacitatea de a conversasa cu celelalte calculatoare ale
altor filiale şi cu calculatorul central de la filiala centrală
- tranzacţiile sunt realizate indiferent de locul în care a fost deschis contul
clientului
- clienţii nu sesizează nicio diferenţă între acest sistem şi un sistem centralizat
(pe care acesta îl înlocuieşte în vremurile curente

Exemplul 2
- o fabrică plină cu roboţi
- fiecare robot este un calculator puternic care tratează prelucrarea imaginilor,
planificarea, comunicarea şi alte sarcini
- toti roboţii se comporta ca dispozitive periferice ataşate la acelaşi calculator
central
- un robot din linie de asamblare, care observă ca o parte pe care este programat
s-o instaleze este defectă, cere altui robot din departamentul de piese să-i aducă un
înlocuitor

1
 Exemplul 3
- o reţea de staţii de lucru dintr-o universitate sau departament al unei
companii
- deţine o colecţie de procesoare în sala serverelor care nu sunt asignate
utilizatorilor specifici, ci sunt asignate dinamic la cerere
- există un singur sistem de fişiere cu toate fişierele accesibile de la toate
maşinile în aceeaşi modalitate şi utilizând aceeasi cale
- când utilizatorul introduce o comanda, sistemul caută locul cel mai bun
pentru a executa comanda, posibil pe staţia de lucru a utilizatorului
- o staţie de lucru a altui utilizator
- una dintre maşinile neasignate în camera serverelor
- sistemul ca un întreg arată şi se comportă ca un sistem uni-procesor cu
partajarea timpului

Definiţia modernă (fără acord general)

Un sistem distribuit este un sistem de procesare a informaţiei care conţine un

număr de calculatoare independente care cooperează între ele peste o reţea de
comunicare pentru a atinge un obiectiv specific.
Aspecte:
- calculatoarele sunt legate între ele prin reţele de comunicare care sunt capabile
să schimbe mesaje între calculatoare.
- obiectivul acestui schimb de mesaje este acela de a coopera pentru atingerea
unui scop.

Puncte de vedere
- fizic: calculatoarele sunt noduri ale reţelei de comunicare şi deţin detalii
asupra reţelei de comunicare
- logic:
- aspectele aplicaţiilor
- interpretat ca o multime de procese cooperante
- distribuirea logică este independentă de cea fizică: de exemplu,
procesele nu trebuie în mod necesar să fie legate peste reţea, ci se pot găsi pe
acelaşi calculator

2
 Avantajele sistemelor distribuite faţă de sistemele centralizate
Descentralizarea este economică:
- sistemele de calcul bazate pe reţea oferă un raport mai bun preţ/performanţă
decât sistemele centralizate
- redundanţa creşte disponibilitatea când părţi ale sistemului cad
- aplicaţiile ale căror componente pot fi rulate simultan oferă beneficii în
termeni de performanţă crescută vis-à-vis de soluţiile centralizate
- sistemele distribuite pot fi extinse prin adăugarea de componente, oferind
astfel o scalabilitate mai bună comparată cu sistemele centralizate

Noţiune Descriere
Economie Raport preţ/performanţă mai bun pentru calculatoare în reţea
decât central
Viteză Un sistem distribuit are o putere de calcul totală mai mare
decât un calculator
Distribuire inerentă Anumite aplicaţii implică separarea spaţială a calculatoarelor
Incredere Dacă un calculator cedează, sistemul ca întreg poate
supravieţui
Creştere incrementală Puterea de calcul poate fi adăugată în incremente mici
Partajarea datelor Permit accesul mai multor utilizatori la date comune
Partajarea dispozitivelor Permit accesul la dispozitive scumpe
Comunicare Permit o comunicare mai uşoară interumană
Flexibilitate Permit distribuirea încărcării la maşinile disponibile într-o
manieră cost-efectivă.

Avantajele unui mediu de calcul distribuit faţă de aplicaţii izolate

1. Performanţă ridicată: aplicaţiile pot fi executate simultan, iar încărcarea poate fi
distribuită la servere multiple.
2. Colaborare: aplicaţii multiple pot fi conectate prin mecanisme standard de calcul
distribuit.
3. Incredere & disponibilitate ridicata: aplicaţiile pot fi grupate în maşini multiple.
4. Scalabilitate: prin lansarea de componente distribuite reutilizabile pe servere
puternice.
3
5. Extensibilitate:(re)configurarea aplicaţiilor distribuite în reţea.
6. Productivitate ridicată şi timp redus pentru ciclul de dezvoltare: prin împărţirea
problemelor mari în probleme mai mici, fiecare dintre aceste componente pot fi
dezvoltate în echipe de dezvoltare mici şi izolate.
7. Reutilizare: serviciile pot fi utilizate potenţial de aplicaţii client multiple.
8. Cost redus: datorită reutilizării componentelor anterior dezvoltate care sunt
accesibile în reţea.

Dezavantajele sistemelor distribuite

Noţiune Descriere
Software Complexitatea programării sistemelor distribuite
Reţelistica Reţeaua poate fi saturată şi poate cauza o serie de probleme
Securitate Accesul uşor se aplică şi datelor secrete

2. Design şi middleware
Software cuplat slab versus cuplat strâns
Cuplat slab:
- permite maşinilor şi utilizatorilor unui SD să fie independente unul de altul
- exemple:
1. PC-uri care partajează anumite resurse, precum imprimante sau baze de
date, peste o LAN
2. sisteme de operare de reţea: sistem de fişiere partajat, fiecare calculator are
sistemul sau de operare şi se supune cererilor utilizatorului
Strâns cuplat:
- sistem de partajare a timpului care este unic
- utilizatorii nu sunt conştienţi de existenţa mai multor procesoare ȋn sistem
- exemple: sistemele cluster

Administrarea proceselor şi sistemelor de fişiere într-un SD

- mecanism global unic pentru comunicare între procese astfel încât orice proces poate
discuta cu oricare alt proces

4
- modalitatea în care procesele sunt create, distruse, pornite şi oprite nu trebuie să
varieze de la maşină la maşină
- sistemul de fişiere trebuie să arate la fel de oriunde (sistem global de fişiere)
- oriunde aceeaşi interfaţă de apel de sistem=> (?) nuclee identice care să ruleze pe
toate maşinile sistemului
- când un proces trebuie pornit, toate nucleele trebuie să coopereze pentru a găsi cel
mai bun loc pentru execuţia sa

Probleme de design:
a) Transparenţa
- SD: o mulţime de procese cooperante
- complexitatea rezultă din faptul că distribuţia trebuie să fie realizată transparent (mai
exact invizibilă) pentru programatorul aplicaţiilor
- un sistem cu partajarea timpului care oferă o imagine a unui sistem singular se
consideră a fi transparent
Exemple:
1. Utilizatorul unei comenzi make din Unix, pentru a compila un număr mare de
fişiere nu trebuie să ştie că toate compilatoarele acţionează în paralel pe maşini
diferite.
2. Citirea unor fişiere la distanţă în aceeaşi manieră ca şi în cazul fişierelor
locale.

Tipuri de transparenţă
Tip
Transparenţa locaţiei
Transparenţa migrării
Transparenţa replicării
Transparenţa concurenţei
Transparenţa paralelismului
Transparenţa accesului
Semnificaţie
Utilizatorul nu poate spune unde sunt localizate
resursele
Resursele pot fi mutate oricând fără a le schimba
numele
Utilizatorul nu poate spune câte copii există
Utilizatorii multipli pot partaja automat resurse
Se pot executa activităţi în paralel fără ca utilizatorii
să ştie
Modalităţi identice în care accesul are loc la
componente locale sau la distanţă

5
Transparenţa eşecurilor Utilizatorii nu sunt constienţi de eşuarea unei
componente
Transparenţa tehnologiei Tehnologii diferite, precum limbajele de programare
sau sistemele de operare sunt ascunse de utilizator

b) Flexibilitatea

- utilizarea de sisteme monolitice sau micro-nuclee?

- utilizarea sistemului monolotic: un sistem centralizat+ facilitate de reţea
- micro-nucleele sunt mai flexibile deoarece nu fac mare lucru.

c) Incredere

- unul dintre scopurile SD: să se realizeze un sistem mai de încredere decât un sistem
bazat pe un singur processor;
- exemplu: dacă o maşină nu mai este disponibilă, altele îi preiau sarcinile;
- probabilitatea încrederii în componente: dacă o maşina are probabilitatea să fie
disponibilă de 95%, posibilitatea ca patru sisteme dintr-un SD sunt indisponibile este
de (5%)^4=0.0006 % <<5%
- zicală: “definiţia” Lamport a unui SD: este un sistem “în care nu putem obţine
rezultatele dorite pentru că o anumită maşină despre care n-am auzit niciodată a căzut"

3. Comunicarea în SD
- comunicarea interprocese:
- Monoprocesor:
- comunicarea între procese presupune implicit că există o memorie
comună
- ex.: sincronizare – semaforul este partajat
- SD: nu există memorie partajată, accesul la resurse se face prin mesaje
- procesele: sunt componente active cu stare şi comportare
- starea: constă din datele pe care le administrează procesul
- starea poate fi stare activă sau stare pasivă
- comportare: implementarea logicii aplicaţiilor

6
- mesaj: secvenţă de octeţi care sunt transportaţi între două procese via un mediu de
comunicare

Comunicarea între 2 procese

- unul dintre procese este expeditorul, altul este destinatarul (receptorul)

- diagrama spaţiu-timp

- starea activă:
- linie neagră groasă
- au loc calcule
- şabloane în scurgerea mesajelor:
- comunicarea orientată spre mesaje
- comunicarea orientată spre cereri - fără aşteptare răspuns
- cu răspuns de la destinatar

Sincronicitatea mecanismului de comunicare

- descrie separarea în timp între expeditor şi destinatar

Comunicarea sincronă: expeditorul este pasiv în timpul procesului de comunicare
până când mesajul ajunge la destinatar
Comunicarea asincronă: expeditorul rămâne activ după ce mesajul a fost expediat
- este mai rapid! Suportă mai bine paralelismul proceselor
- este necesar un SD care să fie capabil să ţină mesaje în
zona tampon

7
 Clasificarea mecanismelor de comunicare

Şablon comunicare Nivele de sincronizare

Asincron Sincron
Orientat mesaj 1/fără aşteptare la expediere 2/rendez-vous
Orientat cerere 3/invocare de serviciu la distanţă 4/apel de procedură la distanţă

Exemple:
1. Serviciile datagrama:
- comunicare asincronă orientată spre mesaje;
- expeditorul trimite un mesaj la destinatar fără a aştepta un răspuns sau a
schimba starea într-una pasivă
2. Rendez-vous: stabileşte un moment (logic) pentru întâlnirea între expeditor şi
destinatar
3. RSI: expeditorul rămâne activ atâta timp cât destinatarul procesează cererea
4. RPC: expeditorul transmite o cerere la destinatar şi este pasiv până când destinatarul
trimite rezultatele cererii

Modelul client-server
- ȋmparte o aplicaţie de reţea ȋn două părţi: partea client şi partea server
- partea de client a unei conexiuni ȋn reţea necesită informaţii sau servicii de la
partea de sever
- partea de server răspunde cerinţelor clientului
- o aplicaţie ȋn modelul client- server realizează două funcţii separate şi bine
definite: cererea de informaţii şi răspunsul la cererile de informaţii
Avantaje:
- simplitate – nu este necesară stabilirea unei conexiuni anterioare
- unul sau mai mulţi clienţi pot avea acces la serviciu
- uşurinţă în migrarea aplicaţiilor existente bazate pe programare procedurala
- potenţial pentru concurenţă
Dezavantaje:
- restricţionarea la paradigmele programării procedurale exclude alte abordări
precum programarea funcţională sau declarativă
- transparenţa nu mai poate fi atinsă în cazul unui eşec radical de sistem
- probleme cauzate de concurenţă când procesele trebuie să se sincronizeze

8
 Procedurile din biblioteci pentru servicii de comunicare
send(dest,&mptr)
- expediază mesajul referit prin mptr la un proces identificat de dest
- cauzează blocarea apelantului până când mesajul a fost expediat
receive(addr,&mptr)
- cauzează blocarea apelantului până când soseşte mesajul
- când acesta soseşte, este copiat într-un tampon indicat de referinta mptr şi
apelantul este deblocat
- parametrul addr specifică adresa la care destinatarul aşteaptă mesajul
- sunt posibile numeroase variante ale acestor proceduri şi a parametrilor lor

Primitive cu blocare

Primitivele de transmitere de mesaje sunt numite primitive blocante sau

primitive sincrone.
Când un proces apelează send
- specifică o destinaţie şi un tampon care să fie expediat la destinaţie
- când mesajul este expediat, procesul expeditor este suspendat în blocare
- instrucţiunile care urmează apelul send-ului nu sunt executate până când
mesajul n-a fost expediat complet
Un apel la un receive
- nu returnează controlul până când mesajul a fost recepţionat şi pus într-un
tampon mesaj indicat de parametru
- procesul rămâne suspendat în receive până când vine mesajul chiar dacă
poate să ţină ore întregi
- în anumite sisteme, destinatorul poate specifica de la cine doreşte sa
recepţioneze, în care caz rămâne blocat până când soseşte mesajul de la acel
expeditor.

Primitive ne-blocante
- sunt numite şi primitive asincrone.
- dacă expedierea este ne-blocantă, se returnează controlul la apelant imediat, înainte
de expedierea mesajului.

9
- avantajul acestei scheme este aceea că procesul de expediere poate continua calculul
în paralel cu transmiterea mesajului, în loc să aibă CPU-ul inactiv.
- alegerea între primitivele blocante şi cele neblocate este în mod normal realizată de
designerii de sistem.

Probleme cu primitivele ne-blocante

-expeditorul nu poate modifica tamponul mesajului până când mesajul a fost expediat
-procesul expeditor nu are nici o idee când are loc transmiterea, astfel încât nu ştie
când este sigur să folosească zona tampon
-soluţii:
- copiază mesajul într-un tampon intern şi permite procesului să continue
- seamănă cu un apel blocant: când primeşte controlul înapoi este liber să
utilizeze tamponul, dar mesajul nu este încă transmis şi expeditorul nu
este ȋmpiedicat de acest fapt
- dezavantajul acestei metode este acela că toate mesajele trebuie copiate
din spaţiul utilizator în spaţiul nucleului
- întrerupe expeditorul când mesajul a fost expediat pentru a-l informa că
tamponul este din nou disponibil
- întreruperile la nivel utilizator fac programarea dificilă şi subiect pentru
condiţiile de întrecere care pot conduce la imposibilitatea de repetare
- metoda este eficientă şi permite paralelismul
- dezavantaj: programele bazate pe întreruperi sunt dificil a fi scrise
corect şi aproape imposibil să fie depanate când ceva nu merge bine.

Puncte de vedere
Al designerului de sistem de operare:
- diferenţe între primitivele sincrone şi asincrone: expeditorul poate utiliza sau
nu tamponul pentru mesaje imediat după reobţinerea controlului
Al designerului de limbaje de programare:
- sincron: expeditorul este blocat până când destinatarul a acceptat mesajul şi
confirmarea a fost primită de catre expeditor
- orice altceva este asincron
- dacă expeditorul obţine controlul înapoi înainte ca mesajul să fie copiat sau
expediat, primitiva este asincronă

10
 - când expeditorul este blocat până când destinatarul a confirmat mesajul, este
vorba de o primitivă asincronă.

Recepţionare ne-blocantă
- returnează controlul aproape imediat.
- când ştie apelantul ca operaţia a fost terminată?
- oferirea unei primitive explicite care permite destinatarului să fie blocat când
este necesar
- oferă o primitivă de testare pentru a permite destinatarului să solicite
nucleului să verifice starea
- exemplu: recepţionare condiţionată, care fie returnează un mesaj sau semnalează
eşec, dar în orice caz returnează imediat sau într-un interval dat.

Time-out
- într-un sistem în care apelurile send sunt blocante, expeditorul se poate bloca pentru
totdeauna
- pentru a preveni această situaţie, în anumite sisteme, apelantul poate specifica un
interval de timp în care aşteaptă un răspuns
- dacă nu primeşte nici un răspuns în respectivul interval, apelul send se termină cu un
status de eroare.

4. Apel de procedură la distanţă (Remote Procedure Call)

Modelul client-server vs. RPC

Client-server:
- construit în jurul I/O
- toate comunicaţiile sunt construite în send/receive
- calculul distribuit seamănă cu calculul centralizat
RPC permite apel la proceduri localizate pe alte maşini.

Principiul RPC
- 1980, Birrell şi Nelson
- când un proces pe o maşină A apelează o procedură de pe maşina B, procesul apelant
de pe A este suspendat şi execuţia procedurii apelate are loc la B

11
- informaţia poate fi transportată de la apelant la apelat în parametri şi se poate
întoarce prin rezultatul procedurii
- programatorul nu vede nici o transmitere de mesaje sau I/O.

Probleme
- procedura care apelează şi procedura apelată rulează pe maşini diferite, se execută în
spaţii de adresare diferite -> complicaţii
- parametrii şi rezultatele trebuie să fie transmise, ceea ce nu este simplu, în special
dacă maşinile nu sunt identice
- ambele maşini pot să cedeze şi fiecare din eşecurile posibile cauzează probleme
diferite.

Operaţii RPC de bază

- ideea din spatele RPC este aceea de a face în aşa fel încât apelulul la distanţă să arate
cât mai apropiat de cel local, adică RPC să fie transparent: procedura care apelează să
nu fie conştientă că procedura apelată este executată pe o maşină diferită sau viceversa
- exemplu: citirea unei date dintr-un fişier
- într-un sistem tradiţional (mono-procesor) :
- rutina de read este extrasa din biblioteca de editorul de legături şi inserat
in programul obiect
- procedura de citire este un fel de interfaţă ȋntre codul utilizator şi
sistemul de operare
- cu RPC:
- când read este o procedură la distanţă (ex. una care va rula pe maşina
serverului de fişiere), o versiune diferită a read, numită stub a clientului, este
pusă în bibliotecă
- spre deosebire de read-ul original, nu pune parametrii în regiştri şi cere
nucleului să îi furnizeze data
- împachetează parametrii într-un mesaj şi cere nucleului să trimită
mesajul la server
- ca urmare a apelului la expediere, stub-ul clientului apelează receive şi
se blochează până când răspunsul vine înapoi
- când mesajul ajunge la server, nucelul îl pasează la un stub al serverului
care este legat de serverul adevărat
- stub-ul serverului este în apel de receive şi blocat în aşteptarea mesajelor

12
 - stubul serverului despacheteză parametrii din mesaj şi apoi apelează
procedura server în mod uzual.
- din punct de vedere al serverului, pare a fi apelat direct de client –
parametrii şi adresele de returnare sunt pe stivă şi nimic nu pare neuzual
- serverul efectuează lucrul sau/şi returnează rezultatele la apelant în mod
uzual: în cazul dat, serverul va completa un buffer cu data solicitată – acest
buffer va fi intern stub-ului server
- când stubul server obţine înapoi controlul după ce apelul s-a terminat,
împachetează rezultatul (bufferul) într-un mesaj şi apelează send pentru a-l
returna la client, apoi merge înapoi în ciclul său pentru a apela receive aşteptând
următoarele mesaje
- când mesajul vine înapoi la maşina client, nucleul observă că este
adresat procesului client (pârtii stub a acelui proces)
- mesajul este copiat ȋn bufferul de aşteptare şi procesul client este
deblocat
- stubul client inspectează mesajul, despachetează rezultatul, îl copiază la
apelant
- când apelantul obţine controlul ca urmare a apelului la read, ceea ce ştie
este faptul că data este disponibilă.

Operatii RPC de bază - paşii

1. Procedura client apelează stub-ul clientului.
2. Stub-ul clientului construieşte un mesaj şi informează nucleul.
3. Nucleul expediază mesaj la nucleul la distanţă.
4. Nucleul la distanţă oferă mesajul stub-ului serverului.
5. Stubul serverului împachetează parametrii şi apelează serverul.
6. Serverul efectuează procedura şi returnează rezultatul la stub.
7. Stub-ul server îl impachetează într-un mesaj şi informează nucleul.
8. Nucleul la distanţă expediază mesajul la nucleul clientului.
9. Nucleul clientului dă mesajul la stubul clientului.
10. Stubul despachetează rezultatul şi îl returnează la client.

Transmiterea parametrilor
- stubul clientului: preia parametrii, îi împachetează într-un mesaj şi-i trimite la stub-ul
server.

13
- ȋmpachetarea parametrilor într-un mesaj este numită parameter marshaling
(inşiruirea parametrilor)
- exemplu: sum(i,j): doi parametri întregi şi returnează suma lor aritmetică. Stubul
clientului:
- preia cei doi parametri şi-i pune într-un mesaj
- de asemenea pune şi numele sau numărul procedurii care trebuie apelată
deoarece serverul poate să suporte mai multe apeluri şi este necesar a fi
indicată care procedură a serverului este referită
- … (vezi cei 10 paşi)

- modelul funcţionează bine atâta timp cât maşinile client şi server sunt identice şi toţi
parametrii şi rezultatele sunt tipuri scalare, precum întregi, caractere şi Booleene;
- tipuri de maşini multiple => probleme potenţiale!
- exemplu: anumite maşini (ex. Intel), numără biţii de la dreapta la stânga
(format numit little endian), pe când altele (ex. Sun), îi numără în sens invers
(format numit big endian*)
- soluţie: s-a ajuns la un acord asupra unui standard pentru reprezentarea
fiecărui tip dintre dipurile da date de bază.
*numele formatelor sunt date după politicienii din Călătoriile lui Guliver care au ajuns în război legat
de subiectul: “care capăt de ou să fie spart?”.

Utilizarea standardelor în transmiterea de parametri

- un standard de reţea sau o formă canonică pentru întregi, caractere, Booleene,
numere în virgulă mobilă
- cere tuturor expeditorilor să convertească reprezentările lor interne în această formă
la înşiruire
Problemă: metoda este câteodată ineficientă
- de exemplu: marshalizare în little endian, dar conversaţia se face între două big
endian
- a doua abordare: clientul utilizează formatul său nativ şi indică în primul bit al
mesajului care format este
- stubul server converteşte dacă este necesar

14
 De unde vin procedurile stub?
- în numeroase sisteme bazate pe RPC, procedurile stub sunt generate automat
- dată o specificaţie a procedurii server şi reguli de codare, formatul mesajului este
unic determinat
- un compilator citeşte specificaţiile serverului şi generează un stub al clientului care
împachetează parametrii în formatul de mesaj aprobat oficial
- similar, compilatorul poate de asemenea produce în stub server care despachetează
mesajele şi apelează serverul
- ambele proceduri stub sunt generate dintr-o singură specificaţie formală a serverului
- face viaţa mai uşoară pentru programatori
- reduce şansele de eroare
- face sistemul transparent relativ la diferenţele interne de reprezentare a datelor

Parametrii pointeri şi referinţe

Exemplu: stubul clientului cunoaşte că parametrul secund pointează la o matrice
de caractere şi cunoaşte cât este de mare este matricea.
Prima strategie:
- copiază matricea într-un mesaj şi o expediază la server
- schimbări la server utilizând pointerul (de ex. stocarea datelor ȋn matrice)
afectează direct bufferul mesajului la stub-ul serverului
- când serverul termină, mesajul original poate fi trimis ȋnapoi la stubul client
care apoi îl copiază înapoi la client
- referinţa-prin-apel a fost înlocuită prin copiere/reconstituire.
Optimizare:
- dacă stubul ştie că bufferul este un parametru de intrare sau un parametru de
ieşire la server, una dintre copii poate fi eliminate
- dacă matricea este de intrare la server (ex. ȋntr-un call la scriere) nu este
necesar să fie copiat înapoi
- dacă este de ieşire, nu este necesar să fie transmis iniţial
- modalitatea de a le califica este cea prin intermediul specificarii formale a
procedurii server
Specificaţia formală a unei proceduri
- scrisă într-un anumit limbaj de specificare
- spune care sunt parametrii, care sunt intrările şi care sunt ieşirile (sau
ambele), care sunt mărimile lor (maxime)
15
 Cazul general al unui pointer la o structură de date arbitrară
-exemplu: un pointer la un graf complex
Abordare:
- plasarea pointerului la stubul serverului si generarea unui cod special în
procedura server pentru utilizarea pointerilor
- un pointer este de-referenţiat (pus într-un registru şi indirectat prin registru)
prin expedierea unui mesaj înapoi la client cerându-i să i-l dea şi să-l trimită (caz read)
sau să-l stocheze (write) de la / la adresa referită
- metoda este ineficientă: exemplul unui server de fişiere care stocheză octeţi în
buffer prin expedeirea fiecăruia într-un mesaj separat

Legături dinamice
Intrebare: cum localizeaza clientul serverul?
O metodă este adresa de reţea a serverului
- abordarea este extrem de inflexibilă!
- dacă serverul se mută sau dacă serverul este replicat şi dacă interfaţa se
schimbă, numeroase programe trebuie găsite şi recompilate
- pentru a evita aceste probleme, anumite sisteme distribuite utilizeaza legătura
dinamică pentru a pune cap-la-cap clienţii şi serverele.

Specificarea formală a serverului

- exemplu: în specificaţie se indică numele serverului (ex. file_server), numărul de
versiune (ex 3.1), o listă de proceduri oferită de server (read, write, create şi delete).
- pentru fiecare procedură se specifică tipurile parametrilor.
- fiecare parametru este specificat ca fiind un parametru in, out sau in-out (direcţia este
relativă la server)
- un parametru in, precum un nume de fişier, este trimis de la client la server
- un parametru out precum buf în read, este expediat de la server la client; buf
indică locul unde serverul pune data solicitată de client
- un parametru in-out poate fi trimis de client la server, modificat şi expediat
înapoi la client (copiere/recuperare).

16
 Binder (liant, legator) si register
-când un server începe execuţia, apelul la iniţializare din afara ciclului principal
exportă interfaţa serverului, adică serverul expediază un mesaj la un program numit
binder, pentru a-şi face cunoscută existenţa
-acest proces de expediere a mesajului este referit ca înregistrarea serverului
-pentru a se înregistra, serverul oferă binderului:
- numele său
- numărul său de versiune
- un identificator unic, tipic pe 32 biţi
- handle utilizat pentru localizarea sa; acesta este independent de sistem şi
poate fi o adresă Ethernet, o adresă IP, o adresă X.500, un identificator de
proces sau altceva
- alte informatii, precum autentificarea.
-un server poate de asemenea să se dez-registreze de la binder când nu mai este
pregătit să ofere servicii.

Interfaţa binderului
Call Input Output
Register Name,version,handle, unique id
Deregister Name,version,unique id
Lookup Name, version Handle, unique
id

Cum localizează clienţii serverul?

1. Apelează una dintre procedurile la distanţă pentru prima dată, de exemplu read.
2. Stubul clientului observă că nu este legat la un server şi trimite un mesaj la binder
cerând să importe versiunea 3.1 a interfeţei file_server.
3. Binderul verifică dacă cel puţin un server a exportat o interfaţă cu acest nume şi cu
această versiune.
4. Dacă nici unul dintre serverele care rulează este dispus să suporte această interfaţă,
apelul eşuează.
5. Dacă există un server adecvat, binderul oferă handle-ul şi identificatorul unic
stubului client.
6. Stubul clientului utilizează handle ca adresă pentru a expedia mesajul dorit.
17
7. Mesajul conţine paranetrii şi identificatorul unic pe care nucleul serverului le
utilizează pentru a direcţiona mesajele sosite la serverul corect în condiţiile în care mai
multe servere rulează pe acea maşină.

Legare dinamică: avantaje vs. dezavantaje

Avantaje:
- poate trata servere multiple care suportă aceeaşi interfaţă
- binderul poate împrăştia clienţii aleator la servere pt. încărcare balansată
- binderul poate chestiona periodic serverele, dez-registrând automat oricare
server care nu răspunde, pentru a atinge un anumit grad de tolerare a
eşecurilor
- binderul poate asista la autentificare: un server poate specifica, de exemplu,
că poate utiliza numai o listă specificată de utilizatori, caz ȋn care binderul
refuză utilizatorii care nu sunt pe listă
- binderul poate de asemenea verifica dacă atât clientul cât şi serverul
utilizează aceeaşi versiune de interfaţă
Dezavantaje:
- surplusul extra în timp pentru exportarea şi importarea interfeţelor
- deoarece numeroase procese client au viaţa scurtă şi fiecare proces de legare
trebuie startat de fiecare dată, efectul poate fi semnificativ
- într-un sistem distribuit mare, binderul poate deveni sursă de gâtuire
- sunt necesari binderi multipli
- când o interfaţă este înregistrată/dez-registrată, un număr substanţial de
mesaje este necesar pentru a ţine toţi binderi sincronizaţi şi la zi, creând astfel
un nou surpuls.

Protocol orientat conexiune vs fără conexiune

Protocol orientat-conexiune:
- în momentul în care clientul este legat la server, o conexiune este stabilită
între ei
- tot traficul, în ambele direcţii, utilizează această conexiune
- avantaje: comunicarea devine mai uşoară
- când un nucleu expediază un mesaj, nu-şi face probleme că poate fi
pierdut sau că trebuie să primească o înştiinţare (tratat de software-ul care
suportă conexiunea)

18
 - avantajul principal (nu se pierd pachete) nu este strict necesar in LAN care
sunt de încredere
- dezavantaj: pierdere în performanţă; tot software-ul extra produce încetinire
Drept consecinţă, majoritatea sistemelor distribuite care sunt construite pentru utilizare
într-o singură clădire sau un campus utilizează protocoale fără conexiune.

Remote Method Invocation (RMI)

- invocă metode ale obiectelor la distanţă (adică obiecte localizate în alte sisteme)
- detaliile de reţele cerute explicit de programarea cu streamuri şi socluri dispar şi
faptul că obiectul este localizat la distanţă este aproape transparent programatorului
- programul server care controlează obiectul la distanţă înregistrează interfaţa cu un
serviciu de numire astfel făcând interfaţa accesibilă programelor client
- interfaţa conţine semnăturile pentru metodele obiectelor pe care serverul doreşte să le
facă disponibile public
- programul client poate utiliza acelaşi serviciu de numire pentru a obţine o referinţă la
aceasta interfaţă în forma unui stub
- stubul este un surogat local ('stand-in‘/ placeholder) pentru obiectul la distanţă
- pe sistemul la distanţă va fi un alt surogat, scheletul.

Local machine Remote machine

Apparent invocation flow Actual invocation flow

19
 Detalii RMI
- când programul client invocă o metodă a obiectului la distanţă, apare clientului ca şi
cum metoda este invocată direct asupra obiectului
- o metodă echivalentă este apelată de stub
- stubul forwardează apelul şi orice parametri scheletului de la maşina la distanţă
- în Java numai tipurile de primitive şi acele tipuri de referinţe care implementează
interfaţa Serializable pot fi utilizaţi ca şi parametri – serializarea acestor parametri este
numită marshalling (înşiruire)
- la recepţionarea şirului de octeţi, scheletul converteşte acest şir în apelul original al
metodei şi parametri asociaţi (deserializarea parametrilor fiind numită unmarshalling)
- la final, scheletul apelează implementarea metodei de la server.

5. Semantica eşecurilor în RPC. Comunicaţie în grup

Eşecuri în comunicare
- pierderea de mesaje
- căderea unui proces

1. Pierderea mesajului cerere

2. Pierderea mesajului răspuns
3. Căderea serverului
4. Căderea clientului

Tipuri de eşecuri
1. Pierderea unui mesaj cerere
- clientul trebuie să retransmită mesajul după un time-out
- problemă: clientul nu poate diferenţia diferitele tipuri de eşecuri

20
 - exemplu: dacă mesajul rezultat este cel care a fost pierdut, o
retransmitere a mesajului cerere poate rezulta în executarea de două ori a
procedurii la distanţă
- exemplu: proceduri care necesită mult timp vs. selecţia unui time-out
scurt
2. Pierderea unui mesaj răspuns:
- clientul retransmite cererea după un time-out
- problemă: dacă serverul nu recunoaşte ce s-a întâmplat, execută procedura din
nou
3. Căderea serverului:
- dacă serverul cade datorită unei erori, trebuie determinat dacă execuţia parţială
a procedurii a produs deja efecte în stare
- exemple: dacă baza de date a fost modificată în timpul procedurii, problema
recuperării şi a continuării din momentul eşecului nu este trivială
4. Căderea clientului:
- un proces client care cade in timpul executiei unui RPC este referit ca o
invocare orfană
- problemă: ce face serverul cu rezultatele şi unde trebuie să le trimită

Semantica eşecurilor

Aplicaţii diferite pot avea cerinţe diferite în ceea ce priveşte calitatea serviciului
(QoS) în termeni de detecţie a eşecurilor şi recuperare
Semantica Operaţie Pierdere Cădere
eşecului fără eşec mesaj server
Maybe (Poate) Execuţie: 1 Execuţie: 0/1 Execuţie: 0/1
Rezultat: 1 Rezultat: 0 Rezultat: 0
At-least-once Execuţie: 1 Execuţie: >=1 Execuţie: >=0
(Cel puţin o dată) Rezultat: 1 Rezultat: >=1 Rezultat: >=0
At-most-once Execuţie: 1 Execuţie: 1 Execuţie: 0/1
(Cel mult o dată) Rezultat: 1 Rezultat: 1 Rezultat: 0
Exactly once Execuţie: 1 Execuţie: 1 Execuţie: 1
(Exact o dată) Rezultat: 1 Rezultat: 1 Rezultat: 1

21
 Semantica Maybe
- referită ca şi efortul cel mai bun
- nu oferă mecanisme pentru tratarea eşecurilor
- exemplu: RPC poate fi executat o dată sau niciodată la partea server
- clientul recepţionează cel mult un rezultat
- nu ofera garantii
- atâta timp cât nu apar eşecuri, RPC este adresat adecvat

Semantica At-least-once
- RPC va fi executat la partea server cel puţin o dată în cazul pierderii de
mesaje
- după un time-out, clientul repetă RPC până când recepţionează un răspuns de
la server
- o procedura poate fi efectuata de mai multe ori la server
- e posibil ca un client să recepţioneze răspunsuri multiple datorate execuţiei
repetate
- nu oferă o confirmare dacă serverul cade
- adecvată pentru proceduri idempotente care nu cauzează schimbarea stării la
server şi pot fi executate mai mult decât o dată fără a produce pagube

Semantica At-most-once
- procedura va fi executata cel mult o data- atât în cazul pierderii de mesaje cât
şi a căderii serverului
- daca serverul nu cade, sunt garantate exact o executie si exact un rezultat
- necesita un protocol complex de gestiune a mesajelor şi numerotare

Semantica Exactly once

- cazul ideal; nu este uşor de atins
- invocarea de către un client va rezulta într-o singură execuţie la partea server
şi va fi furnizat un singur rezultat
- dezirabilă pentru tranzacţii bancare
- cazul cel mai simplu: operaţii idempotente
- cazul unei simple informări care doar citeşte data de la serverul de la distanţă
fără a schimba starea serverului
- execuţia repetată şi numeroase mesaje rezultat nu sunt o problemă.

22
 6. Sincronizarea ceasurilor - ceasuri logice- ceasuri fizice

Sicronizare: sisteme monoprocesor vs. sisteme distribuite

Mono-procesor:
- se utilizează regiuni critice, excludere mutuală, iar alte probleme de
sincronizare sunt rezolvate cu ajutorul semafoarelor şi monitoarelor
Sisteme distribuite:
- semafoarele şi monitoarele nu sunt adecvate pentru că se bazează pe
existenţa memoriei partajate
- probleme care trebuie tratate:
- timpul
- excluderea mutuală
- algoritmi de alegere
- tranzacţii atomice
- impas

Construirea algoritmilor pentru sincronizarea ceasului

Abordare centralizată:
- colectează toată informaţia din sistem într-un singur loc
- un proces o examinează şi ia o decizie aşa cum se procedează în cazul mono-
procesor
- punct de eşec: centralizatorul
Algoritmii distribuiţi au următoarele proprietăţi:
1. Informaţia relevantă este strânsă la maşini multiple.
2. Procesele iau decizii bazate numai pe informaţia locală.
3. Un singur punct de eşec în sistem trebuie evitat. De ce? Sistemele distribuite trebuie
să fie mai de încredere decât maşinile individuale. Dacă una cedează, restul trebuie să
fie capabil să continue să funcţioneze
4. Nu există un ceas comun sau o sursă de timp global precis.

Algoritmi distribuiţi – a 4a proprietate

Contraexemplu: sistemele centralizate – într-un sistem centralizat timpul este
ne-ambiguu.

23
 - când un proces doreşte să cunoască timpul, face un apel de sistem şi nucleul
îi răspunde
- dacă procesul A se informează asupra timpului şi mai târziu procesul B se
informează, valoarea lui B > valoarea lui A.
Intr-un SD, ajungerea la un acord asupra timpului nu este trivială.
Exemplu: lipsa cunoaşterii timpului global într-un cluster de maşini Unix.

Exemplu: make

Make examinează timpii la care fişierele sursă şi obiect au fost modificate;

make urmăreşte toate fişierele sursă pentru a afla care trebuie recompilate şi apelează
compilatorul pentru a le recompila
Normal:
- dacă fişierul sursă input.c are timpul 2151 şi fişierul obiect corespunzător are
timpul 2150, make recunoaşte faptul că input.c a fost schimbat de când input.o
a fost creat şi astfel input.c trebuie recompilat
- dacă output.c are timpul 2144 şi output.o are timpul 2145, nu este necesară o
recompilare
Desincronizare:
- la timp scurt după timpul real 2144 output.c este modificat pe o maşina cu
ceas dat înapoi
- make nu va apela compilatorul
- programul binar executabil rezultat că conţine o mixtură de fişiere obiect de
la sursele vechi şi sursele noi

24
 Ceasul calculatorului
- fiecare calculator are un circuit pentru a ţine evidenţa timpului
- cuvântul "ceas" se referă la acest dipozitiv, dar nu sunt ceasuri în sensul
uzual, contor de timp este un cuvânt mai adecvat
- contorul de timp este bazat pe un cristal de cuarţ prelucrat precis
- când este ţinut sub tensiune, cristalul de cuarţ oscilează la o frecvenţă bine
definită care depinde de tipul de cristal, cum este tăiat şi cantitatea de
tensiune
- asociat cu fiecare cristal sunt doi regiştri, un registru contor şi un registru păstrător
- fiecare oscilatie a cristalului decrementeaza contorul cu unu
- când contorul ajunge la zero, este generată o întrerupere şi contorul este
reîncărcat din registrul păstrător
- astfel este posibilă programarea unui contor de timp care generează o întrerupere de
60 de ori pe secundă sau la altă frecvenţă dorită
- fiecare întrerupere este numita tic de ceas.

Alunecarea ceasului
- deşi frecvenţa oscilatorului este de obicei stabilă, este imposibilă garantarea faptului
că diferite calculatoare vor rula la aceeaşi frecvenţă
- când sistemul are n calculatoare, cele n cristale rulează la rate diferite, cauzând
ceasurile (software) să iasă gradual din sincronizare şi să dea valori diferite la citire
- aceasta diferenţă în valorile de timp este numită alunecarea ceasului (skew)
- consecinţă: programele care se bazează pe timpul asociat cu un fişier, obiect, proces
sau mesaj pot eşua – ex. “make”

Timpi relativi
- problema “make” în cazul unui singur calculator si a unui singur ceas este rezolvată:
- toate procesele pe maşina care utilizează ceasul vor fi intern consistente
- nu contează dacă ceasul este decalat cu o cantitate mică
- tot ceea ce contează este timpul relativ
- Lamport – 1978
- a demonstrat că sincronizarea ceasurilor este posibilă şi a prezentat un
algoritm
- ideea: sincronizarea ceasurilor nu trebuie să fie absolută

25
 - dacă două procese nu interacţionează, nu este necesară sincronizarea
ceasurilor lor deoarece lipsa sincronizării nu va fi observată şi nu va cauza
probleme
- ceea ce contează în mod uzual nu este ca procesele să fie de acord asupra
timpului exact, ci să fie de acord asupra ordinii în care apar evenimentele
- exemplul “make” : ceea ce contează este dacă output.c este mai vechi sau mai nou
decât output.o nu timpii lor absoluţi de crerare.

Ceasurile logice şi ceasurile fizice

Pentru numeroase aplicaţii:
- este suficient ca toate maşinile să fie de acord asupra aceluiaşi timp
- nu este esenţial ca acest timp să fie în acord cu timpul real
Ex. make – este adecvat ca toate maşinile sa fie de acord ca este 10:00, deşi în realitate
este 10:02.
Inţeles: ceea ce contează este consistenţa internă a ceasurilor, nu cât sunt de apropiate
de timpul real.
Pentru acesti algoritmi convenţia este aceea de a fi numite ceasuri logice.
Contra-exemplu: cazul în care sunt constrangeri aditionale ca ceasurile nu numai să
fie aceleaşi, dar să nu devieze de la timpul real mai mult de o anumită cantitate
ceasurile sunt numite ceasuri fizice.

Algoritmul lui Lamport: sincronizarea ceasurilor logice

Lamport a definit relaţia întâmplat-înainte.

- expresia a← b
- se citeşte "a se întâmplă înainte de b”
- înseamnă că toate procesele sunt de acord că prima dată apare evenimentul a şi apoi
apare evenimentul b
- relaţia întâmplat-înainte poate fi observată direct în situaţiile următoare:
1. Dacă a şi b sunt evenimente în acelaşi proces, dacă a apare înainte de b atunci
a←b este adevarat.
2. Dacă a este un eveniment de expediere a unui mesaj de la un proces şi b este
evenimentul de recepţionare a mesajului la alt proces, atunci a← b este adevărat.

26
 - înţeles: un mesaj poate fi recepţionat înainte de expediere sau în acelaşi
timp cu expedierea, deoarece necesită un timp finit pentru a fi ajunse.

Proprietăţile relaţiei întâmplat-înainte

- tranzitivitate: dacă a← b şi b← c atunci a← c.
- dacă două evenimente x şi y, întâmplate în procese diferite care nu schimbă mesaje
(nici indirect prin a treia parte), atunci x← y nu este adevărat, nici y← x; evenimentele
sunt numite concurente.
Ceasul logic
- pentru fiecare eveniment a se asignează o valoare în timp C(a) asupra căruia toate
procesele sunt de acord
- proprietatea că dacă a← b, atunci C(a)<C(b)
- înţeles:
- dacă a şi b sunt două evenimente din acelaşi proces şi a se intampla înaintea
lui b, atunci C(a)<C(b)
- dacă a este expedierea unui mesaj de către un proces şi b este recepţionarea
acelui mesaj la alt proces, atunci C(a) si C(b) trebuie asignate în aşa fel încât toate
procesele sunt de acord asupra valorilor C(a) şi C(b) cu C (a) <C(b).
- C trebuie întotdeauna să meargă înainte ( să crească) şi niciodată să mearga înapoi
(să descrească)
- corecţiile în timp pot fi realizate prin adăugarea unei valori pozitive, niciodată
prin scăderea uneia.

Exemplu

Nesincronizat Sincronizat

27
 Stânga:
- 3 procese care rulează în maşini diferite, fiecare cu ceasul propriu cu viteză proprie
- când ceasul a ticăit de 6 ori în procesul 0, a ticăit de 8 ori ân procesul 1 şi de 10 ori în
procesul 2
- fiecare ceas rulează cu o rată constantă, dar ratele sunt diferite datorită diferenţelor în
cristale
- timpul 6: procesul 0 expediază mesajul A la procesul 1
- ceasul de la procesul 1 citeşte 16 când acesta ajunge
- dacă mesajul poarta şi timpul de start, 6, procesul 1 concluzionează că au fost
necesare 10 ticuri pentru a ajunge mesajul la proces
- conform acestui fapt, mesajul B de la 1 la 2 poate necesita 16 ticuri, o valoare
plauzibilă
- mesajul C de la 2 la 1 pleacă de la 60 şi ajunge la 56. Imposibil!
- mesajul D de la 1 pleacă de la 64 şi ajunge la 54. Imposibil!

Dreapta: – Soluţia Lamport:

- urmăreşte relaţia “întâmplat-anterior|”
- deoarece C a plecat la 60, trebuie să ajungă la 61 sau mai târziu
- de aceea, fiecare mesaj poartă şi timpul de expediere, conform cu ceasul
expeditorului
- când un mesaj ajunge şi ceasul receptorului arată o valoare mai timpurie decât timpul
expedierii mesajului, destinatarul muta ceasul propriu la o valoare mai mare cu unu
decat timpul de expediere
- astfel mesajul C ajunge la 61. Similar, D ajunge la 70.

Ajustări pentru a îndeplini cerinţele pentru timp global

- între oricare două evenimente ceasul trebuie să ticăie cel puţin odată
- două evenimente nu pot să apară în acelaşi timp
- abordare: ataşează numărul de proces la care evenimentul a apărut la timpul
evenimentului, separat de punctul zecimal
- exemplu: evenimentele se întâmplă în procesele 1 şi 2, ambele la timpul 40, primul
devine 40.1, iar ultimul devine 40.2
- operaţia “→” asignează timpul la toate evenimentele dintr-un sistem distribuit şi este
subiect al următoarelor conditii:

28
 1. Dacă a se intampla înainte de b în acelaşi proces atunci C(a)< C(b).
2. Dacă a şi b reprezintă expedierea şi recepţionarea unui mesaj, C(a)<C(b).
3. Pentru toate evenimentele distincte a şi b, C(a) nu este egal cu C(b).
“→” o ordonare totală a tuturor evenimentelor în sistem.

Necesitatea ceasurilor fizice

Algoritmul lui Lamport pentru sincronizarea ceasurilor logice:
- oferă o ordonare neambiguă a evenimentelor
- valorile in timp asignate evenimentelor nu sunt necesar apropriate de timpii
reali la care apar
In anumite sisteme precum sistemele în timp real, ceasul real este important! Pentru
aceste sisteme sunt cerute ceasuri fizice externe.
Din raţiuni de eficienţă şi redundanţă, ceasurile fizice multiple sunt în general
dezirabile, ceea ce conduce la două probleme :
1. Cum sunt sincronizate ceasurile cu cele reale?
2. Cum sunt sincronizate ceasurile între ele?

Cum este de fapt măsurat timpul?

1. Secunda solară
- până în secolul 17, timpul a fost măsurat astronomic
- evenimentul la care soarele atinge cel mai ridicat punct pe cer este numit
tranzit al soarelului – evenimentul apare la prânz în fiecare zi
- intervalul între două tranzite consecutive ale soarelui este numita zi solara
- cum se consideră 24 de ore într-o zi, fiecare conţinând 3600 secunde, secunda
solară este definită ca fiind a 86400 parte a unei zile solare
- anii 1940: perioada de rotaţie a Pământului nu este constantă!
- pământul încetineşte datorită fricţiunii datorate atmosferei şi mareelor
- geologii susţin ca acum 300 de milioane de ani erau 400 zile pe an în sens
matematic
- lungimea anului, timpul pentru o rotaţie în jurul soarelui se considera
neschimbată; ziua a devenit mai lungă
- în plus pe lângă acest trend pe termen lung, variaţii scurte în lungimea zilei
apar şi datorita turbulenţelor de adâncime în miezul Pământului
- astronomii au calculat lungimea zilei măsurând un număr mare de zile şi
considerarea mediei înainte de împărţire
29
2. TAI
Invenţia ceasului atomic în 1948 => măsurarea timpului cu o precizie mai mare,
- independent de fenomenele la care Pământul este supus
- contorizează tranziţiile atomului de cesiu 133
Fizicienii definesc secunda ca fiind timpul necesar atomului de cesiu 133 să facă exact
1770 tranziţii.
- alegerea a fost realizată astfel încât secunda atomică a fost egală cu secunda
solară medie în anul introducerii sale
- mai mult de 50 laboratoare din întreaga lume au ceasuri cu cesium 133
- periodic, fiecare laborator spune Biroului International al orei (BIH) din
Paris cât timp a ticăit ceasul lui
- BIH face media acestor valori şi produce Timpul Atomic International, TAI
- TAI este numărul mediu de ticuri ale ceasurilor bazate pe cesiu 133 din
noaptea lui 1 Ian 1958 (începutul timpului) împărţit la 1770.

Problema TAI
- TAI este stabil si disponibil oricaruia doreste sa cumpere un ceas cu cesiu
- problema serioasă este aceea ca: 86 400 secunde TAI sunt cu 3 msec mai putin decat
ziua solara în medie deoarece ziua solară medie devine din ce în ce mai lungă
- abordare
- soluţia Papei Gregor al XIII-lea: în 1582 a decretat ca 10 zile să fie omise din
calendar
- acest eveniment a cauzat răscoale pe scară deoarece latifundiarii au cerut renta
pe toata luna şi la fel şi cămătarii, pe când angajaţii au refuzat să plătească
pentru cele 10 zile pe care nu le-au lucrat
- ţările protestante, din principiu, au refuzat să aibă de a face cu decretele papale
şi nu au acceptat calendarul Gregorian pentru 170 de ani

3. UTC
- BIH rezolva problema prin introducerea secundelor de saritura cand discrepanta
intre TAI şi timpul solar creşte peste 800 msec.
- aceasta corecţie conduce la un sistem de timp bazat pe secundele TAI, dar care stă în
fază cu mişcarea aparentă a soarelui
- este numit Timp Coordonat Universal, abreviat UTC

30
- UTC este baza timpului modern civil
- a înlocuit standardul vechi, timpul mediu Greenwich (GMT), care este timpul
astronomic.
Cunoaşterea UTC
- majoritatea companiilor de curent electric isi bazeaza ceasurile lor de 60-Hz sau 50-
Hz pe UTC
- când BIH anunţă o secundă de salt, companiile ridică frecvenţa la 61 Hz sau 51 Hz
pentru 60 sau 50 sec, pentru a avansa toate ceasurile din aria lor de distribuţie
- 1 sec este un interval semnificativ pentru un calculator şi SO trebuie să ţină timpul cu
acurateţe pentru o perioadă de ani astfel încât trebuie să considere software special
pentru a ţine seama de secundele de salt când aceastea sunt anunţate
- UTC este difuzat prin radio, sateliţi etc. cu o acurateţe de 0.5msec
- trebuie cunoscută cu acurateţe poziţia relativă a expeditorului şi destinatarului, pentru
a compensa pentru întârzierea propagării semnalului

31