În proiectarea primelor re Ńele de calculatoare, s-a acordat atenŃ ie în primul rând [613912]

În proiectarea primelor re Ńele de calculatoare, s-a acordat atenŃ ie în primul rând
echipamentelor, iar programele au fost gândite ulterior. Aceast ă strategie s-a schimbat radical.
Programele de reŃ ea sunt acum foarte structurate. În continuare se vor examina anumite detalii ale
tehnicii de structura`re a programelor.

Ierarhii de protocoale
Pentru reducerea complexit ăŃii proiectării, majoritatea reŃ elelor sunt organizate sub forma
unei unei serii de structuri sau niveluri , fiecare din ele construit peste cel de dedesubt. Num ărul de
niveluri, numele fiec ărui nivel, conŃ inutul și funcŃia sa variază de la reŃea la reŃea. Oricum scopul
fiecărui nivel este s ă ofere anumite servicii nivelurilor superioare, protejându-le totodat ă de
detaliile privitoare la implementarea efectivă a serviciilor oferite. Într-un anumit sens fiecare nivel
este un fel de maș ină virtuală, oferind anumite servicii nivelului de deasupra lui.
Nivelul n de pe o maș ină conversează cu nivelul n de pe o alt ă mașină. Regulile și
convenŃiile utilizate în conversa Ńie sunt cunoscute sub numele de protocolul nivelului n. În
principal, un protocol reprezint ă o înŃelegere între păr Ńile care comunică , asupra modului de
realizare a comunic ării : cum se construie ște reŃeaua fizică; cum se conecteaz ă computerele la
reŃea;cum se formateaz ă datele în vederea transmisiei–formatul mesajelor; cum se transmit datele –
sincronizarea comunicarii secvenŃ ale a mesajelor, controlul fluxului; cum se trateaz ă erorile–
controlul erorilor.
În fig. 2.1 este ilustrat ă o reŃea cu cinci niveluri. Entit ăŃile din niveluri corespondente de pt
mașini diferite se numesc egale. Entit ăŃile egale pot fi procese, dispozitive hardware, sau chiar fiin Ń:
umane. Cu alte cuvinte, entit ăŃile egale sunt cele care comunic ă folosind protocolul.
În realitate, nici un fel de date nu sunt transferate direct de pe nivelul n al unei mașini pe
nivek n al altei mașini. Fiecare nivel transfer ă datele și informaŃiile de control nivelului imediat
inferior până când se ajunge la nivelul cel mai de jos. Sub nivelul 1 se afl ă mediul fizic prin care se
produce comunicarea efectivă . în Fig. 2.1, comunicarea virtual ă este reprezentat ă prin linii
punctate, iar comunicarea fizic ă prin linii continue. între dou ă niveluri adiacente exist ă o interfaŃă.
InterfaŃa definește ce operaŃii și servicii primitive ofer ă nivelul de jos că tre nivelul de sus.
Când proiectan Ńii de reŃea decid câte niveluri s ă includă într-o reŃea și ce are de făcut fiecare
din ele, unul din considerentele cele mai importante se refer ă la definirea de interfe Ńe clare între
niveluri.
18

Fig. 2.1 Niveluri, protocoale ș i interfeŃe

Aceasta presupune ca, la rândul s ău, fiecare nivel s ă execute o colecŃ ie specifică de funcŃii
clar definite. Pe lângă minimizarea volumului de informa Ńii care trebuie transferate între niveluri
interfeŃele clare permit totodat ă o mai simpl ă înlocuire a implement ării unui nivel cu o
implementare complet diferit ă (de exemplu, toate liniile telefonice se înlocuiesc pri n canale de
satelit). Aș a ceva este posibil, pentru c ă tot ceea ce i se cere noii implement ări este să furnizeze
nivelului superior exact setul de servicii pe care îl oferea vechea implementare. De altfel, este un fapt
obișnuit ca doua gazde s ă folosească implementări diferite.
O mulŃime de niveluri și protocoale este numit ă arhitectură de reŃea. SpecificaŃia unei
arhitecturi trebuie s ă conŃină destule informaŃ ii pentru a permite unui proiectant s ă scrie programele
sau să construiască echipamentele necesare fiec ărui nivel, astfel încât nivelurile s ă îndeplinească
corec: protocoalele corespunz ătoare. Nici detaliile de implementare și nici specifica Ńiile interfeŃelor
nu fac parte din arhitectur ă, deoarece acestea sunt ascunse în interiorul ma șinilor și nu sunt vizibile
din afară. Nu este necesar nici m ăcar ca interfeŃele de pe mașinile dintr-o re Ńea să fie aceleași – ca
condiŃia, însă, ca fiecare maș ină să poată utiliza corect toate protocoalele. O list ă de protocoale
utilizate de către un anumit sistem, câte un protocol pentru fiecare ni vel, se numeș te stivă de
protocoale .

19

Analogie pentru explicarea ideii de comunicare multinivel
2 filozofi (procese egale de la nivelul 3) vor s ă comunice unul cu altul dar vorbind limbi
dife
rite (primul – urdu și engleză iar al doilea chinez ă și franceză) angajează fiecare câte un
trans
lator (procese egale de la nivelul 2), iar fiecare translator contacteaz ă la rândul său o secretară
(proce
se egale de la nivelul 1). Filozoful 1 dore ște să comunice partenerului s ău o opine specifică .
Pentr
u aceasta el trimite un mesaj in eneglez ă prin interfaŃa 2/3 către translatorul sau, c ăruia îi spune
următoa
rele cuvinte : „I like rabbits” (Fig.2.2). Translator ii s-au înŃ eles asupra limbii neutre,
olande
za, așa că mesajul este convertit în „Ik vind konijnen leuk”. Ale gerea limbii reprezint ă
protoc
olul nivelului 2 și este la latitudinea proceselor pereche de pe acel nive l . În continuare
translatorul înmâneaz ă mesajul secretarei, care îl trimite, de exemplu pri fa x (protocolul nivelului
1). Când mesajul este primit, este tradus în francez ă și trimis prin interfaŃ a 2/3 către folosoful 2. Se
obser
vă că atât timp cât interfe Ńele nu se modifică , fiecare protocol este complet independent de
cele
lalte. Dacă filosofii doresc, pot schimba olandeza cu alt ă limbă, cu condiŃia ca amândoi s ă se
înŃel
eagă asupra acestui lucru și nici unul din ei s ă nu modifice interfa Ńa cu nivelul 1 sau cu nivelul
3. În
mod similar secretarele pot înlocui faxul cu poș ta electronică sau cu telefonul f ără a deranja
(sau
măcar a informa) celelalte niveluri. Fiecare proces poate adăuga anumite informa Ńii
suplim
entare destinate numai procesului s ău pereche, ele nefiind transmise în sus, c ătre nivelul
superi
or.

Fig.2.2. Arhitectura filosof-translator-secretar ă
20

Să considerăm un exemplu mai tehnic : cum se realizeaz ă comunicarea la ultimul nivel din
reŃeau
a cu 5 niveluri (Fig.2.3). O aplica Ńie care se execut ă la nivelul 5 produce un mesaj M și îl
furniz
ează nivelului 4 pentru a-l transmite. Nivelul 4 insereaz ă un ant et în faŃa mesajului, pentru a-l
identi
fica și pasează rezultatul nivelului 3. Antetul include informa Ńii de control, de ex. numere de
ordine
care ajută nivelul 4 de pe maș ina de destinaŃie să livreze me-
saje
le în ordinea corect ă în cazul în care nivelurile inferioare nu pă strează această ordine. Pe unele
nivel
uri antetele conŃ in câmpuri de control pentru m ărime, timp ș i alte informaŃii.

Fig.2.3. Exemplu de flux de informa Ńii pentru suportul comunic ării virtuale la nivelul 5

În num
eroase reŃ ele nu există mici o limită cu pivire la m ărimea mesajelor transmise în
protoc
olul nivelului 4, dar exist ă întotdeauna o limit ă impusă de protocolul nivelului 3. În
consec
inŃă, nivelul 3 trebuie s ă spargă mesajele primite în unit ăŃi mai mici, pachete, ata șând fiecărui
pache
t un antet specific nivelului 3. În exemplu, M este descompus în două părŃi M1 și M2.

Ni
velul 3 decide ce linie de transmisie s ă utilizeze și trimite pachetele niveului 2. Nivelul 2
adaugă
nu numai câte un antet pentru fiecare bucat ă, ci și o încheiere, după care furnizeaz ă unitatea
rezul
tantă nivelului 1 pentru a o transmite fizic.În ma șina receptoare mesajul este trimis în sus, din
nivel
în nivel, pe parcurs fiind eliminate succesiv toate antetele. Nici un antet corespunz ător
nivel
urilor de sub n nu este transmis în sus nivelului n.
Ce este important de înteles în Fig.2.3 este rela Ńia dintre comunicaŃ ia virtuală și cea efectivă
și diferenŃ a între protocoale și interfeŃe. De ex. protocoale egale de la nivelul 4 î și imaginează
concept
ual comunicarea ca realizându-se pe „orizontal ă”, utilizând protocolul nivelului 4. De și
21

fiecare din ele are, probabil, o procedur ă de genul TrimiteÎnCealalt ăParte sau
PrimeșteDinCealaltăParte, aceste proceduri nu comunic ă de fapt cu cealalt ă parte, cu cu nivelurile
inferioare prin interfa Ńa 3/4.
Abstractizarea proceselor pereche este crucial ă pentru proiectarea întregii re Ńele. Astfel se
descompun în probleme de proiectare mai mici, rezolvabile (proiectarea nivelurilor individuale).

Servicii orientate pe conexiuni ș i servicii fără conexiuni
Nivelurile pot oferi nivelurilor de deasupra lor două tipur i de servicii : orientate pe
conexiuni
și fără conexiuni.
Servici
ul orientat pe conexiuni este modelat pe baza sistemului telefornic. Pentru a utiliza
un serviciu orientat pe conexiuni, beneficiarul trebuie mai întâi s ă stabilească o conexiune, s ă
foloseas
că această conexiune și apoi să o elibereze. Conexiunea func Ńionează ca o Ńeavă : emiŃătorul
introduce
obiectele (biŃii) la un capăt, iar receptorul le scoate afar ă, în aceeași ordine, la cel ălalt
capăt.

Acest
serviciu sigur admite două variante : secvenŃ ele de mesaje și fluxurile de octeŃ i. Când
sunt tri
mise 2 mesaje de 1024 octe Ńi ele vor sosi sub forma a două mesaje distince de 1024 octe Ńi,
niciodată c
a unul singur de 2048 octe Ńi.
Serviviu
l fără conexiuni este modelat pe baza sistemului poș tal. Toate mesajele (scrisorile)
conŃin adr
esele complete de destina Ńie și fiecare mesaj circul ă în sistem independent de celelalte.
Este posi
bil însă ca cel care a fost expediat primul s ă ajungă al doilea.
Fieca
re serviciu poate fi caracterizat printr-o calitate a serviciului . Unele servicii sunt
sigure în sensul că nu pierd niciodat ă date.
Nu ori c
e aplicaŃie necesită conexiuni. De ex. în m ăsura în care poș ta electronică devine ceva
tot mai uz
ual, se poate să nu apară foarte curând publicitate prin poș tă.
Serviviul
nesigur (neconfirmat) f ără conexiuni este deseori numit servici u datagramă
Mai e
xistă un serviciu numit servic iul cerere-răspuns. Aici emiŃătorul transmite o singur ă
datagr
amă care conŃ ine o cerere, replica primit ă de la receptor conŃ ine răspunsul.
În Fig
.2.4. sunt rezumate tipurile de servicii discutate mai sus.
Nu totdeanuna comunica Ńiile sigure (confirmate) sunt disponibile. De exemplu Ether net-ul
nu oferă comunicaŃii sigure. Pachetele pot fi uneori alterate în timpul tranz acŃiei.
Urmează c
a protocoalele nivelurilor superioare s ă se ocupe de aceast ă problemă.

22

Fig. 2.4.Ș ase tipuri diferite de servicii

2.3. Primitive de serviciu
Un serviciu este specificat formal printr-un set de prim itive (operaŃii) puse la dispozi Ńia
utili
zatorului care folose ște serviciul.Aceste primitive comandă serviciului să execute anumite
acŃiuni s
au să raporteze despre ac Ńiunile executate de o entitate pereche. Dac ă stiva de protocoale
este
localizată în sistemul de operare (în majoritatea cazurilor), primi tivele sunt în mod normal
apeluri sistem. Acestea cauzeaz ă o trecere a sistemului de operare în modul nucleau (kerne l), care
preia controlul maș inii pentru transmiterea pachetelor necesare.
Setul
de primitive disponibile depinde de natura serviciului oferit. Ca un exemplu minimal
de primitive de serviciu care pot fi oferite pentru a implementa un flux de octe Ńi într-un mediu
client
-server, se pot considera primitivele listate în Fig.2.5.

Fig. 2.5. Cinci primitive de serviciu pentru implementarea unui serviciu simplu orientat pe
conexiune
23

Primitivele pot fi folosite astfel :
– mai întâi serverul execut ă LISTEN pentru a indica faptul c ă este pregă tit să accepte conexiuni. În
mod obișnuit pr
ocesul server este blocat pân ă la apariŃia unei cereri de conexiune
– proc
esul client execut ă CONNECT pentru a stabili o conexiune cu serverul. Apelul CONNECT
trebuie să specifice cu cine se dore ște conectarea, aș a că ar putea avea un parametru prin care se
trans
mite adresa serverului. De cele mai multe ori, sistemul de operare va trimite un pachet entit ăŃii
pere
che cerându-i s ă se conecteze, cum este ar ătat de (1) Fig.2.6. Procesul client este suspendat
până
apare un răspuns. Când pachetul junge la server, el este procesat de sistemul de operare al
acestuia. Când acesta observă că pachetul cere o conexiune, verific ă dacă este un ascult ător. Dacă
da, f
ace două lucruri : deblocheaz ă ascultătoruil și trimite apoi o confirmare (2). Sosirea confirm ării
elibe
rează clientul. SecvenŃ a (2) este generat ă de codul protocolului însu și, nu ca răspuns al unei
prim
itive de la nivelul utilizatorului. Dac ă ân urma cererii de conexiune nu exist ă nici un ascultător,
rezul
tatul este nedefinit.

Fig.2.6. Pachete trimise într-o simpl ă interacŃiune client-server pe o retea orientat ă pe conex

– se
rverul execută RECEIVE pentru a a fi preg ătit să accepte prima cerere. În mod normal serverul
face
acestă operaŃie imediat ce a fost eliberat din blocarea impus ă de LISTEN, înaite s ă ajungă
confir
marea înapoi la client. Apelul RECEIVE blocheaz ă serverul.
– cl
ientul execută SEND pentru a transmite cererea sa (3) urmat de execuŃ i a unui RECEIVE pentru
a obŃine
răspunsul.
– sos
irea pachetului de cerere la ma șina server deblocheaz ă procesul server pentru ca acesta
să proceseze cererea. După asta, folosește SEND pentru a r ăspunde clientului (4). Sosirea
pache
tului deblocheaz ă clientul care analizeaz ă răspunsul obŃ inut. Dacă nu există cereri din partea
clie
ntului, acesta le poate face acum. După ce a terminat, poate folosi DISCONNECT pentru a
term
ina conexiunea. De obicei apelul ini Ńial DISCONNECT este blocant, suspendând clientul și
trim
iŃând un pachet c ătre server pentru ai comunica faptul c ă respectiva conexiune nu mai este
nece
sară (5). Când serverul prime ște pachetul, el lanseaz ă un DISCONNECT propriu, confirmând
cere
rea clientului și eliberând conexiunea. Când pachetul serverului (6) aj unge înapoi la ma șina
clie
ntului, procesul client este eliberat și conexiunea este întrerupt ă. Așa FuncŃionează serviciile
baza
te pe conexiuni.
24

. 2.4. RelaŃ ia dintre servicii ș i protocoale
Deși sunt adesea confundate ele reprezint ă conc epte distince. DiferenŃ a dintre ele este foarte
importa
ntă. Un serviciu este un set de primitive (opera Ńii) pe care un nivel le furnizeaz ă nivelului de
deasupr
a sa. Serviciul define ște ce operaŃii este pregătit nivelul să realizeze pentru utilizatorii s ăi,
dar nu
spune nimic despre cum sunt implementate aceste opera Ńii. Un serviciu este definit în
context
ul unei interfe Ńe între două niveluri, nivelul inferior fiind furnizorul serviciului și nivelul
superior
fiind utilizatorul serviciului.
Prin contrast un protocol este un set de reguli care guverneaz ă formatul și semnificaŃia
cafre
lor, pachetelor sau mesajelor schimbate între ele de entit ăŃile pereche dintr-un nivel. Entit ăŃile
foloses
c protocoale pentru a implementa defini Ńiile serviciului lor. Ele sunt libere s ă-și schimbe
protocoa
lele după bunul plac, dar s ă nu modifice serviciul pe care-l vă d utilizatorii. Astfel serviciul
și protocolul sunt comple decuplate.
Servi
ciile sunt legate de interfe Ńele dintre niveluri, (Fig.2.7). Prin contrast protocoalel e sunt
legate de pachetele trimise între entit ăŃile pereche de pe diferite ma șini.
Ca o
analogie cu limbajele de programare, un serviciu este ca un tip de date abstracte sau ca
un obiect într-un limbaj orientat pe obiecte. El define ște operaŃiile care pot fi aplicate pe un obiect,
dar nu
specifică modul de implementare a opera Ńiilor. Un protocol se refer ă la implementarea
servic
iului și nu este vizibil pentru utilizatorul serviciului.

Fig.2.7. RelaŃia sintre un server ș i un protocol

25