MINISTERUL EDUCAŢIEI ŞI CERCETĂRII

UNIVERSITATEA „TIBISCUS” TIMIŞOARA

FACULTATEA DE CALCULATOARE ŞI INFORMATICĂ APLICATĂ

Timişoara, str. Lascăr Catargiu nr. 4-6

Tel: +40/256/220.687; Fax: +40/256/202.930
E-mail: fcia@tibiscus.ro Web: www.tibiscus.ro

Curs de masterat
Specializarea: Web Design, Web Design pentru e-Society
Anul universitar 2009/2010

PROTOCOALE DE SECURIZARE

1/61/
 Aceată pagină este lăsată intenţionat liberă

This page intentionally left blank.

2/61/
CUPRINS / CONTENTS

1.1 Componentele reţelelor de calculatoare...............................................................................................6

1.2 Modele de referinţă..........................................................................................................................7
1.2.1 Modelul OSI..............................................................................................................................7
1.2.2 Modelul TCP/IP........................................................................................................................8
1.2.3 Probleme generale de proiectare...............................................................................................9
1.2.4 Modelul client - server............................................................................................................12
1.2 Protocoale..........................................................................................................................................13
Protocoalele IPX/SPX din stiva NetWare dezvoltate de firma Novell................................................13
Protocoale NetWare de nivel inferior..................................................................................................14
__Protocolul MLID (Multiple Link Interface Driver)..........................................................................14
Protocoalele NetWare de nivel mediu.................................................................................................15
__Protocolul IPX (Internetwork Packet Exchange).............................................................................15
__Protocolul RIP (Routing Information Protocol)...............................................................................15
__Protocolul NLSP (Network Link Services Protocol)........................................................................15
__Protocolul SPX (Sequenced Packet Exchange)...............................................................................15
Protocoale NetWare de nivel superior.................................................................................................16
__Protocolul NCP (NetWare Core Protocols).....................................................................................16
__Protocolul SAP (Service Advertising Protocol)...............................................................................16
Protocoale utilizate pe Internet............................................................................................................16
Prezentare generală..........................................................................................................................16
Protocoale de nivel mediu utilizate pentru Internet..............................................................................18
__Protocolul IP (Internet Protocol).....................................................................................................19
__Protocolul ARP (Address Resolution Protocol)...............................................................................22
__Protocolul RARP (Reverse Address Resolution Protocol)...............................................................22
__Protocolul ICMP (Internet Control Message Protocol)....................................................................22
__Protocolul RIP (Routing Information Protocol)...............................................................................22
__Protocolul OSPF (Open Shortest Path First)....................................................................................22
__Protocolul TCP (Transmission Control Protocol)............................................................................22
__Protocolul UDP (User Datagram Protocol).....................................................................................23
__Protocolul DNS (Domain Name Server).........................................................................................23
Protocoalele de nivel superior utilizate pe Internet...............................................................................23
__Protocolul FTP (File Transfer Protocol)..........................................................................................23
__Protocolul Telnet...........................................................................................................................23
__Protocolul SMTP (Simple Mail Transfer Protocol)..........................................................................24
__Protocolul NFS (Network File System)...........................................................................................24
__Protocolul XDR (Externai Data Representation).............................................................................24
__Protocolul RPC (Remote Procedure Caii).......................................................................................24
Protocoale AppleTalk..........................................................................................................................24
Protocoalele de nivel inferior AppleTalk.............................................................................................25
__Protocolul LocalTalk (LLAP).........................................................................................................25
__Protocolul EtherTalk (ELAP).........................................................................................................26
__Protocolul TokenTalk (TLAP).......................................................................................................26
__Protocolul AARP (AppleTalk Address Resolution Protocol)...........................................................26
__Protocoale de nivel mediu AppleTalk.............................................................................................26
__Protocolul DDP (Datagram Delivery Protocol)...............................................................................26
__Protcolul RTMP (Routing Table Maintenance Protocol).................................................................26

3/61/
 __Protocolul NBP (Name Binding Protocol)......................................................................................26
__Protocolul ATP (AppleTalk Transaction Protocol)..........................................................................27
__Protocoalele de nivel superior AppleTalk........................................................................................27
__Protocolul ADSP (AppleTalk Data Stream Protocol)......................................................................27
__Protocolul ASP (AppleTalk Session Protocol)................................................................................27
__Protocolul PAP (Printer Access Protocol).......................................................................................27
__Protocolul ZIP (Zone Information Protocol)....................................................................................27
__Protocolul AFP (AppIeTalk Filing Protocol)...................................................................................27
__Protocolul AppleShare...................................................................................................................28
Protocoale DNA (Digital NetworkArchitecture).................................................................................28
Protocoalele DNA de nivel inferior....................................................................................................28
__Protocolul Ethernet Version 2.........................................................................................................28
__Protocolul DDCMP (Digital Data Communications Message Protocol)...........................................29
__Protocolul HDLC (High-Level Data Link Control).........................................................................29
Protocoale DNA de nivel mediu.........................................................................................................29
__Protocolul CLNS (Connectionless-Mode Network Service)............................................................29
__Protocolul CONS (Connection Oriented Network Service)..............................................................30
__Protocolul NSP (Network Services Protocol)..................................................................................30
__Protocolul ISO 8073 (Connection-Oriented Transport Protocol Specification).................................30
Protocoalele DNA de nivel superior...................................................................................................30
__Protocolul Session Control.............................................................................................................31
__Protocolul ISO 8327 (Session Protocol Specification).....................................................................31
__Protocolul ASN.1 with BER (Abstract Syntax Notation One with Basic Encoding Rules)................31
__Protocolul FTAM (File Transfer, Access and Management)...........................................................31
__Protocolul DAP (Data Access Protocol)..........................................................................................31
__Protocolul NVTS (Network Virtual Terminal Service)....................................................................31
__Protocoalele MAILbus şi X.400 Message Handling System............................................................31
__Protocoalele Naming Service şi X.500 Directory............................................................................32
Protocoale SNA (System Network Architecture)................................................................................32
Nivelurile modelului SNA.................................................................................................................32
Arhitectura SNA şi componentele ei...................................................................................................33
Protocoale SNA de nivel inferior........................................................................................................34
__Protocolul Token Ring...................................................................................................................34
__Protcolul SDLC (Synchronous Data Link Control).........................................................................35
__Protocolul NCP (Network Control Program)...................................................................................35
Protocoale SNA de nivel mediu.........................................................................................................35
__Protocolul APPN (Advanced Peer-to-Peer Networking)..................................................................35
__Protocolul VTAM (VirtualTelecommunications Access Method)....................................................35
Protocoalele SNA de nivel superior....................................................................................................35
__Protocolul CICS (Customer Information Control System)...............................................................35
__Protocolul IMS (Information Management System)........................................................................36
__Protocolul APPC (Advanced Program-to-Program Communication)...............................................36
__Protocolul DDM (Distributed Data Management)...........................................................................36
__Protocolul SNADS (SNA Distributed Service)..............................................................................36
__Protocolul DIA (Document Interchange Architecture) .................................................................36
Alte protocoale şi standarde.................................................................................................................36
__Protocolul SLIP (Serial Line Internet Protocol)...............................................................................36
__Protocolul PPP (Point-to-Point Protocol)........................................................................................37
FDDI.................................................................................................................................................37
4/61/
 __X.25..............................................................................................................................................38
Frame Relay......................................................................................................................................38
Reţele digitale cu integrarea serviciilor (ISDN) şi reţele integrate de bandă largă (B-ISDN)..................39
Reţeaua optică sincronă (SONET) şi Ierarhia digitală sincronă (SDH).................................................40
__Modul de transfer asincron (ATM).................................................................................................40
__Serviciul SMDS (Switched Megabit Data Service).........................................................................41
Aplicaţii bazate pe protocoale TCP şi UDP.........................................................................................42
Socluri API.......................................................................................................................................42
Principalele apeluri sistem ce utilizează socluri..............................................................................45
Algoritmul utilizat în cazul unui server orientat pe conexiune........................................................47
Server concurent orientat pe conexiune...........................................................................................47
Server iterativ orientat pe conexiune...............................................................................................48
Exemple...............................................................................................................................................48
Funcţia readline()- citeşte N octeţi dintr-un descriptor de soclu..........................................48
Funcţia writen() - scrie N octeţi într-un descriptor de soclu...................................................49
Funcţia str_echo() – procesare de către un server TCP concurent a conexiunii cu un client. 49
Funcţia str_cli() – procesare de către un client a conexiunii cu un server TCP......................50
Funcţia dg_echo() – procesare de către un server UDP a cererilor client.......................................51
Funcţia dg_cli() – procesare de către un client a răspunsurilor unui server UDP...........................52
Definitii pentru programe client / server TCP şi UDP.....................................................................53
Exemplu de programe client / server TCP cu conexiune.................................................................53
Exemplu programe client / server UDP fără conexiune..................................................................58

5/61/
1.1 Componentele reţelelor de calculatoare
O reţea de calculatoare, este un sistem de comunicaţii care conectează mai multe noduri ("hosts"). Un nod poate fi
un calculator personal foarte simplu sau chiar un instrument de uz mai general (cum ar fi un telefon mobil), dar
poate fi şi un supercalculator. Unele noduri dispun de un singur dispozitiv (interfaţă, controller) pentru conectarea în
reţea, altele dispun de mai multe asemenea dispozitive: există deci noduri mono-punct şi noduri multi-punct („multi-
home"). Există, de asemenea, deosebiri între noduri după rolul pe care îl joacă în reţea: unele sunt specializate (de
exemplu, server de fişiere, server Web etc.), altele sunt de uz general, adică accesibile pentru diverse servicii pentru
unul sau mai mulţi utilizatori interactivi.
O reţea locală ("Local Area Network - LAN") conectează calculatoare apropiate din punct de vedere geografic: în
aceeaşi sală sau clădire, eventual chiar calculatoare situate la câţiva kilometri distanţă. Legătura, este realizată prin
diverse mijloace, de regulă pe cablu, la viteze mari de transfer: de la 10 Mbps (megabiţi pe secundă) până la 100
Mbps sau chiar l Gbps.
O reţea răspândită geografic ("Wide. Area Network - WAN") conectează calculatoare situate la mari distanţe, chiar
în ţări diferite. Suportul fizic pentru conectare îl constituie liniile telefonice, canalele radio sau satelit etc., iar
vitezele de transfer sunt în general mai mici decât, la reţelele locale: de la câţiva zeci de Kbps la sute de Mbps (155
Mbps este momentan valoarea utilizată pe conexiunile principale la nivel global).
Reţelele metropolitane ("Metropolitan Area Networks - MAN") acoperă de obicei un întreg oraş sau o aglomeraţie
urbană şi funcţionează la viteze tipice pentru LAN, fiind conectate de obicei prin fibre optice.
Merită a fi menţionat aici şi conceptul de reţea privată virtuală ("Private Virtual Network - PVN"), care
desemnează o reţea construită pe suport public (de regulă în cadrul WAN), dar cu acces controlat, astfel încât
să asigure confidenţialitatea comunicărilor.
Prin interconectarea, unor reţele individuale se realizează interfeţele. Un caz particular de interreţea este cel
cunoscut sub numele de Internet, care constă din toate reţelele interconectate pe baza familiei de protocoale
TCP/IP, descrisă mai târziu. Fizic interconectarea înseamnă că există un nod multipunct care face parte din mai
multe reţele (conectat în fiecare reţea prin unul din punctele sale), aşa cum este ilustrat în Figura 1.1).

Figura 1.1: Interconectarea reţelelor.

Interconectarea reţelelor se realizează în mai multe moduri, deosebite prin nivelul la care se face conectarea
(conceptul de nivel este explicitat în subcapitolul următor):
 Repetoarele realizează conectarea la nivel fizic, transmiţând între cele două reţele toate semnalele (inclusiv
zgomotele!). Acest mod de lucru se întâlneşte mai ales la reţelele bazate pe Ethernet.
 Punţile ("Bridges") fac conectarea la nivelul legăturii de date şi conţin logica necesară pentru a selecta
numai o parte din cadrele ("frames") care circulă în fiecare reţea pentru a fi transmise spre cealaltă
reţea.
 Ruterele ("Routers") lucrează la nivelul "reţea" şi nu fac doar simple transferuri de informaţie de la o reţea
la alta, ci iau şi decizii asupra celei mai potrivite căi (rute) de urmat pentru fiecare pachet.
 Porţile ("Gateways") desemnează generic orice entitate pentru conectarea a două sau mai multe reţele.
Specific acest termen se referă uneori la software-ul care operează la nivelul aplicaţiilor şi face conversii

6/61/
 dintr-un format în altul (de exemplu, pentru transmiterea poştei electronice sau transmiterea fişierelor).

1.2 Modele de referinţă

Pentru ca între calculatoarele dintr-o reţea să se poată desfăşura cu succes o comunicare este necesar să se
stabilească anumite protocoale. Un protocol poate fi definit ca un set de reguli şi convenţii stabilite între
participanţii la o activitate comună. Deoarece protocoalele utilizate în reţelele de calculatoare s-au dovedit a fi
deosebit de complexe, s-a convenit ca ele să fie proiectate pe niveluri sau straturi ("layers) pentru a simplifica
implementarea. Fiecare nivel defineşte anumite servicii şi eventual protocoalele corespunzătoare acelor servicii.
Rezultă în felul acesta modele de referinţă pentru protocoale, standardul fiind reprezentat de modelul OSI.

1.2.1 Modelul OSI

Modelul OSI (OSI = Open System Interconnection) a fost dezvoltat între 1971 1984 şi constituie mai mult un
ghid decât o specificare, cu toate că pe baza sa a fost dezvoltată şi o familie de protocoale concrete.

Figura 1.2: Modelul de referinţă OSI.

Reprezentarea grafică uzuală a acestui model este redată în Figura 1.2. Modelul este structurat pe 7 niveluri şi
aşa cum se observă din figură, există, două feluri de comunicări în cadrul său: prin protocoale şi prin interfeţe.
Nivelurile cu acelaşi rang din cele două calculatoare pot schimba informaţii prin protocoalele corespunzătoare.
În fiecare calculator există, pe de altă parte comunicare între nivelurile vecine prin interfeţe. Pentru ca o
informaţie de nivel transport de la calculatorul sursă A să ajungă la nivelul transport din calculatorul destinaţie
B (conform protocolului de transport) este nevoie în realitate ca informaţia să parcurgă mai întâi nivelurile reţea,
legătură de date şi fizic de pe calculatorul A, apoi nivelurile fizic, legătura de date, reţea şi în fine transport pe
calculatorul B.
Urmează o trecere în revistă a nivelurilor din acest model, cu evidenţierea sarcinilor (serviciilor), problemelor şi
conceptelor specifice.
Nivelul fizic realizează transferul biţilor printr-un mediu (canal) de comunicare. Probleme tipice sunt:
reprezentarea fizică a fiecărui bit, dacă se poate face transmisie simultană în ambele sensuri, cum se stabileşte şi
cum se termină o conexiune, etc.

7/61/
 Nivelul legăturii de date transmite cadre de date (în mod tipic câteva sute sau mii de octeţi) de la sursă la
destinaţie şi cadre de confirmare, de la destinaţie spre sursa, având responsabilitatea de a recunoaşte
delimitările între cadre şi de a cere retransmiterea, cadrului dacă a apărut o eroare în secvenţa de octeţi. Pentru
recunoaşterea delimitărilor se ataşează de obicei tipare speciale de biţi la începutul şi sfârşitul cadrului (în plus
faţă de informaţia utilă din cadru).
Nivelul reţea are ca responsabilitate principală dirijarea (rutarea) pachetelor în reţea. Fiecare pachet conţine,
pe lângă datele utile, şi informaţii de adresare, pentru identificarea sursei şi destinaţiei. Deciziile de dirijare se
iau pe baza unor informaţii fixe despre topologia reţelelor sau pe baza unor informaţii determinate dinamic, ţinând
eventual cont şi de gradul de congestionare a diverselor trasee. Sunt frecvente cazurile când pachetele traversează,
mai multe reţele între sursă şi destinaţie, cu caracteristici diferite. Este tot sarcina nivelului reţea să ţină cont de
aceste deosebiri.
Nivelul transport acceptă date de la nivelul sesiune (în partea, de emisie) şi de regulă trebuie să asigure că
acestea, ajung corect, eventual fragmentate, la celălalt, capăt.
În mod obişnuit, nivelul transport creează câte o conexiune de reţea distinctă pentru fiecare conexiune de
transport solicitată de nivelul sesiune, dar este posibilă şi crearea unor sesiuni multiple pentru creştera
productivităţii transferului sau multiplexarea aceleiaşi conexiuni reţea pentru mai multe conexiuni transport.
Tot la nivelul transport se stabileşte dacă nivelului sesiune i se asigură un serviciu "canal punct la punct” fără
erori, cu furnizarea octeţilor în ordinea, în care au fost emişi sau alt tip de serviciu, mai puţin fiabil. O asemenea
alternativă ar fi, de exemplu, trimiterea individuala a fiecărui mesaj, fără garanţii în privinţa ordinii de livrare.
Trebuie reţinut ca spre deosebire de nivelurile inferioare unde comunicările se fac între vecini imediaţi în
reţea, nivelul transport realizează comunicare "capăt la capăt" ("end to end"): un program din calculatorul sursă
desfăşoară o "conversaţie" cu un program de pe calculatorul destinaţie.
Cum majoritatea calculatoarelor funcţionează în regim de multiprogramare, este posibil ca mai multe
programe de pe acelaşi calculator să fie simultan angajate în conexiuni. Antetul introdtus de nivelul
transport în mesaje trebuie să identifice (adreseze) în mod unic fiecare conexiune.
Nivelul sesiune furnizează utilizatorilor câteva servicii suplimentare faţă de nivelul transport. Unul dintre aceste
servicii este controlul dialogului, care permite să se stabilească dacă se poate realiza trafic simultan în ambele
sensuri sau nu. De asemenea, se poate controla accesul la anumite operaţii critice şi se pot introduce puncte de
control, astfel ca în caz de eşec, o operaţie, să poată fi reluată din punctul de întrerupere şi nu de la început.
Nivelul prezentare are ca preocupare sintaxa şi semantica informaţiilor transmise de la o aplicaţie la alta. Un
exemplu tipic este stabilirea unei codificări standard pentru reprezentarea informaţiilor în timpul transferului
"pe cablu" şi definirea unui mod standard de reprezentare a diverselor structuri de date.
Nivelul aplicaţie conţine cea mai mare diversitate de protocoale, teoretic fiecare aplicaţie putând defini un
protocol specific. Există însă şi la acest nivel câteva protocoale frecvent şi larg utilizate, cum ar fi cele pentru:
terminal -virtual, transfer de fişiere, poştă electronică, hipertext etc.

1.2.2 Modelul TCP/IP

Primul model de referinţă în ordinea apariţiei a fost modelul TCP/IP, definit în legătură cu prima, reţea, de
calculatoare realizată în jurul anului 1970 cu sprijin de la Departamentul Apărării (DoD) al SUA: ARPANET.
Numele modelului provine de la cele două protocoale principale ale sale: TCP şi IP, iar o reprezentare
comparativa cu modelul OSI este dată în Figura 1.3.

8/61/
 Figura 1.3: Modelul de referinţă TCP/IP.

Se observă că acest model nu defineşte niveluri distincte pentru sesiune şi prezentare, iar nivelurile fizic şi
legătura de date sunt comasate într-unul singur, nod - reţea, care nu este detaliat în cadrul modelului.
Nivelul internet a fost conceput, ca de altfel întregul model, pentru utilizarea în reţele cu comutare de pachete şi
are rolul de a permite nodurilor din reţea să emită pachete care să circule independent până la destinaţie. Este posibil
ca pachetele să ajungă în altă ordine decât cea în care au fost trimise, rearanjarea lor fiind sarcina nivelurilor
superioare.
Nivelul transport corespunde în bună măsură nivelului cu acelaşi nume din modelul OSI. Cele două protocoale
definite pentru acest nivel, TCP şi UDP, realizează transmisii cu conexiune şi respectiv fără conexiune de tip "capăt
la capăt".
Nivelul aplicaţie apare în modelul TCP/IP imediat deasupra nivelului transport şi larga răspândire a protocoalelor
care corespund modelului TCP/IP arată că această decizie de proiectare a fost corectă. Protocoale mai cunoscute la
acest nivel, descrise ceva mai detaliat în următorul subcapitol sunt: TELNET, pentru terminal virtual (sesiune la
distanţă), FTP pentru transfer de fişiere, SMTP pentru poştă electronică, DNS pentru serviciul numelor de domenii,
HTTP pentru hipertext (pagini Web), etc.

1.2.3 Probleme generale de proiectare

Există o serie de probleme comune tuturor familiilor de protocoale, care merită a fi evidenţiate separat. Aceste
probleme sunt generate de factori cum sunt: diferenţele arhitecturale ale calculatoarelor; diferenţele de caracteristici
fizice şi funcţionale ale suporturilor de interconectare; diferenţele de regim de tratare a informaţiilor transmise etc.
Ordinea octeţilor în reţea. Între calculatoare există diferenţe în modul de memorare a valorilor reprezentate
pe mai mulţi octeţi: unele calculatoare (Motorola, Sparc, etc. - arhitecturi big endian) memorează octetul mai
semnificativ la adresa de start în memorie (adresa mai mică), iar altele (în principal Intel - arhitecturi little endian)
memorează octetul mai puţin semnificativ la adresa de start. Din acest motiv la transmiterea în reţea, a unor asemenea
valori trebuie precizată ordinea în care apar octeţii. Aşa cum sunt definite protocoalele, câmpurile multioctet care se
transmit se consideră numai de tip întreg şi se acceptă în general convenţia că în reţea octeţii circulă în format big
endian. In consecinţă, la arhitecturile little endian software-ul de implementare a protocoalelor trebuie să asigure
transformările necesare.
Încapsularea. Aşa cum a. rezultat din prezentarea modelelor de referinţă, la informaţia propriu-zisă
schimbată între programele unei aplicaţii situate pe calculatoare diferite, protocoalele de pe fiecare nivel utilizează
informaţii suplimentare: acestea se adaugă la emiţătorul unui mesaj şi trebuie recunoscute şi îndepărtate la
receptorul mesajului. Se spune că informaţia utilă este încapsulată pentru transmiterea în reţea. Figura 1.4
ilustrează, încapsularea pentru o aplicaţie bazata pe familia de protocoale TCP/IP. Antetele de protocol de la fiecare
nivel conţin informaţii de adresare şi informaţii de comandă specifice protocolului. Software-ul de implementare a
protocolului de pe un anumit nivel este evident responsabil doar pentru antetul corespunzător nivelului respectiv,
restul informaţiei fiind considerată drept date utile la acest nivel.

9/61/
 Figura 1.4: Încapsularea în familia de protocoale TCP/IP cu reţea Ethernet.

Multiplexarea şi demultiplexarea. În Figura 1.5 este reprezentat un calculator multipunct conectat la două
reţele Etheniet, pe care rulează simultan mai multe procese utilizator provenite din aplicaţii de reţea. Toate aceste
procese sunt bazate pe familia de protocoale TCP/IP, dar unele folosesc la nivelul transport TCP, iar altele UDP.
Funcţionarea corectă cere în acest caz din partea implementării familiei de protocoale posibilităţi de multiplexare şi
demultiplexare.
Implementarea protocoalelor de nivel transport trebuie să recunoască dacă un pachet primit de la IP este destinat
unui proces sau altuia (demultiplexare) şj pe de altă parte trebuie să trimită toate mesajele primite de la procese
(nivelul aplicaţie) spre acelaşi modul software (IP) din nivelul reţea (multiplexare).
Analog, modulul IP trebuie pe de o parte să recepţioneze pachete primite pe oricare dintre interfeţele de reţea şi
să le dirijeze spre protocolul de nivel transport corespunzător (multiplexare/demultiplexare). Pe de altă parte,
modulul IP trebuie să recunoască dacă un pachet primit de la oricare din protocoalele de pe nivelul transport
(multiplexare) este destinat uneia sau celeilalte dintre interfeţele de reţea (demultiplexare).
La râdul său, software-ul încorporat în interfaţa de reţea este de regulă realizat astfel încât să poată opera cu mai
multe protocoale de nivel reţea, nu numai cu IP.
Fragmentarea şi reasamblarea. Majoritatea tehnologiilor (protocoalelor) de comunicare în reţea au o
dimensiune maximă de pachet care poate fi tratată. În cazul cel mai cunoscut, Ethernet, această unitate maximă de
transrnisie (MTU - Maximum Transmissioii_ Unit) este de 1518 octeţi: 1500 octeţi informaţie +- 14 octeţi prefix + 4
octeţi sufix. În alte cazuri, valoarea MTU poate fi chiar mult mai mică.

10/61/
 Figura 1.5: Multiplexarea şi demultiplexarea.

Pentru transmiterea unor mesaje mai lungi decât MTU se pune evident problema fragmentării mesajului la
emiţător şi a. reasamblăni sale la recepţie. Aceasta poate să apară şi la nivelurile superioare nivelului reţea: un
pachet TCP are de exemplu lungimea maximă de 64 kocteţi. Din motive de eficienţă, fragmentarea trebuie
făcută cât mai târziu posibil, adică la nivel cât mai jos, astfel încât nivelurile superioare să poată lucra mai
rapid.
Moduri de serviciu. Fiecare nivel al urnii model de referinţă poate fi caracterizat §i prin tipul de servicii de
comunicaţii oferite nivelurilor superioare. Va fi prezentată numai oferta pe care nivelul transport o face
nivelului aplicaţie, cu următorii parametri principali:
- cu conexiune / fără conexiune;
- secvaiţierea;
- controlul erorilor;
- controlul fluxului;
- flux de octeţi / mesaje;
- full-duplex / half-duplex.
Un serviciu cu conexiune presupune că cele două, programe de aplicaţie stabilesc o conexiune logică înainte
de a începe transferul propriu-zis. Aceasta apare ca un circuit virtual între cele două programe pe durata
comunicării, deşi comunicarea are loc efectiv prin comutarea de pachete., Schimbul de informaţii cu conexiune
presupune deci parcurgerea a trei etape: stabilirea conexiunii, transferul de mesaje şi terminarea conexiunii.
Operaţiile de stabilire şi de terminare a conexiunii se consideră regie de sistem şi este important ca durata
acesteia să fie cât mai mică. Se foloseşte comunicarea cu conexiune atunci când programele îşi transmit
secvenţe de mesaje (de exemplu, la transferul de fişiere).
Serviciul fără conexiune, numit şi serviciu de datagrame, transmite independent fiecare mesaj, care trebuie,
deci, să conţină toate informaţiile necesare pentru livrare.
Secvenţierea indica faptul că receptorul primeşte datele în ordinea în care acestea au plecat de la emiţător.
Datorită lucrului cu comutare de pachete este posibil ca două pachete consecutive să urmeze rute diferite de la
emiţător la receptor şi deci pachetul care a plecat al doilea să ajungă primul.
Controlul erorilor are rolul de a garanta că programele de aplicaţie primesc date fără erori. Există două
cauze principale de erori: coruperea datelor şi pierderea datelor.
Pentru a detecta, dacă datele au fost corupte, se introduce, de regula o sumă de control pe care receptorul o
poate verifica şi daca diferă de cea transmisă cere retransmiterea mesajului. În acest scop, procedeul sumei de
control se combină de obicei cu achitarea pozitivă ("positive acknowledgment"), care înseamnă că receptorul
anunţă emiţătorul când primeşte date, corecte sau nu: dacă datele nu s-au primit corect, emiţătorul trebuie să le
retransmită.
Pentru a detecta pierderea datelor, de fiecare dată când trimite un mesaj emiţătorul porneşte un timer şi dacă
nu primeşte mesaj de achitare până la expirarea timerului, retransmite datele. Este însă posibil ca mesajul

11/61/
pierdut să fie chiar cel de achitare, caz în care receptorul poate primi aceleaşi date de două ori si deci trebuie să
aibă posibilitatea de a detecta dublurile.
Controlul fluxului asigură că emiţătorul transmite date nu mai rapid decât pot fi acestea primite de receptor.
Este de regulă necesar controlul fluxului la comunicările orientate pe conexiune.
Un serviciu de flux de octeţi nu conţine explicit informaţii care să indice limite de mesaje. Din nou,
protocoalele cu conexiune lucrează de obicei în acest mod, iar cele fără conexiune indică limita mesajelor prin
faptul că transmit câte un singur mesaj.
O conexiune full-duplex permite transfer simultan de date în ambele direcţii între emiţător şi receptor. Unele
protocoale sunt half-duplex, adică permit la un moment dat transfer numai într-o direcţie.
Fiecare protocol de nivel transport este caracterizat printr-o combinaţie a acestor caracteristici, cu precizarea
că nu orice combinaţie are sens. Ca exemplu, dacă un protocol are controlul erorilor şi secvenţiere se spune că
este fiabi. Nu se justifică o combinaţie între secvenţiere şi absenţa conexiunii, pentru că o comunicare fără
conexiune înseamnă că datagramele consecutive sunt independente.
Transmisii "capăt la capăt" sau "pas cu pas". Anumite caracteristici ale serviciilor de transfer se
aplică pe bază de "capăt la capăt", iar altele doar în regim pas cu pas". "Capăt la capăt" înseamnă de la
emiţător până la receptor, indiferent câte reţele distincte (rutere) se află între aceştia. Un exemplu de astfel de
caracteristică este controlul fluxului în protocolul TCP. Controlul erorilor pe de altă parte se face de regulă "pas
cu pas" adică între două calculatoare vecine pe parcursul transmisiei. Ca regulă generală, doar protocoalele de
la nivelul transport şi mai sus pot lucra în regim "capăt la capăt".
Tampoane şi date urgente. În cazul unui serviciu orientat pe flux de octeţi se utilizează de regulă
tampoane atât la capătul de emisie cât şi la cel de recepţie, realizând astfel o regularizare a fluxului. Utilizarea
tampoanelor este impusă nu numai de posibilele diferenţe de viteză de prelucrare la emisie şi la recepţie, dar şi
de caracteristicile de fiabilitate ale protocolului. De exemplu, la TCP emiţătorul trebuie să păstreze informaţia
trimisă până când primeşte ca răspuns de la destinatar un mesaj de achitare.
Exista însă şi situaţii în care utilizarea tampoanelor trebuie dezautorizată. Astfel, utilizarea unui editor de
text în mod ecran într-o sesiune la distanţă impune transmiterea separată a fiecărui caracter în ambele sensuri.
Chiar şi atunci când transmiterea în mod linie cu linie este acceptabilă, apar caractere cărora trebuie să li se dea
atenţie imediat, cum ar fi cel pentru terminarea unei comenzi: ^C.
Este evident că transmiterea unor caractere individuale (sau mai general a unui număr mic de caractere într-
un mesaj) are consecinţe negative asupra funcţionarii reţelei: indiferent cât este de scurt un mesaj, la el se
adaugă toate antetele specifice nivelurilor prin care trece, ceea ce duce la un raport foarte defavorabil între
informaţia utilă şi lungimea mesajului.

Figura 1.6:: Date transmise prin tampon şi date urgente.

Soluţia uzual adoptată în implementări este ilustrată în Figura 1.6: atât la emisie cât şi la recepţie datele
„obişnuite” se transmit prin tampon, iar pentru cele urgente există mecanisme prin care se atrage atenţie că ele
trebuie prelucrate înaintea celor deja aflate în tampon. Apar diferenţe între protocoale referitoare la cantitatea
de date urgente, la mecanismele de semnalare, etc.
Uneori pentru „datele urgente” se mai foloseşte denumirea de date în afara benzii ("out-of-band data"),
celelalte fiind atunci date în bandă ("in-band data").

1.2.4 Modelul client - server

La nivelul aplicaţie există în majoritatea cazurilor o asimetrie între programele aflate la cele două, capete (de
regulă pe două calculatoare diferite): unul are esenţial rolul de a oferi anumite servicii, iar celălalt de a solicita

12/61/
aceste servicii. Se utilizează denumirea de model client - server pentru a caracteriza acest mod de lucru.
Acesta este modelul dominant în proiectarea aplicaţiilor utilizate în reţelele de calculatoare, deşi sunt
posibile şi au fost dezvoltate şi alte modele. In aplicaţiile complexe dezvoltate mai recent, în special dacă se
utilizează şi sisteme de gestionare a bazelor de date s-a impus de exemplu modelul multistrat ("mulţi-tier").
Trebuie de asemenea precizat că în multe aplicaţii acelaşi program poate juca în contexte diferite atât rol de
server cât şi rol de client: el oferă anumite servicii, dar la rândul său solicită servicii oferite de alte programe.

În modelul client - server "clasic" programul cu rol de server trebuie pornit primul, iar proiectarea şi
codificarea sa se fac după următoarea schemă:
1. Se deschide un canal de comunicare şi se informează calculatorul local că programul este
pregătit să accepte cereri de la clienţi la o locaţie (adresă) determinată.
2. Programul rămâne în aşteptare până la sosirea unei cereri de la un client.
3. Programul acceptă cererea şi o tratează, elaborând s,i un mesaj de răspuns care se trimite
clientului. Aici apar diferenţe după cum programul poate trata simultan mai multe cereri sau
numai câte una singură, vorbindu-se de servere concurente, respectiv servere iterative.
4. Se revine la pasul 2.
Programele server sunt prin urmare scrise de regulă ca programe ciclice, care rămân în funcţiune un timp
nedeterminat după ce au fost activate. Trebuie de asemenea reţinut că este necesar să se asigure posibilitatea
de a înregistra cererile de la clienţi care sosesc înainte ca serverul să revină în starea de acceptare a unei noi
cereri, în această privinţă soluţia uzuală este ca facilitatea de înregistrare a cererilor să fie inclusă în suportul de
execuţie la care are acces programatorul de aplicaţii.

Pentru programele client acţiunile tipice sunt următoarele:

1. Deschiderea unui canal de comunicare şi conectarea la o locaţie determinata, a
unui anumit calculator.
2. Emiterea de cereri de servicii către server şi recepţionarea rezultatelor, ori de
câte ori este necesar.
3. Închiderea canalului de comunicare şi terminarea programului.
Programele client sunt elementele active în aplicaţiile client - server. Se spune de
altfel că serverele deschid canalele de comunicare în mod pasiv.

1.2 Protocoale
Un protocol este un set de reguli de comunicare. Un exemplu simplu de protocol utilizat în lumea reală este
modul de felicitare a unei persoane: prin îmbrăţişare, strângere de mână sau prin sărut. Modul de felicitare
depinde de locul unde se întâmâplă şi de persoana căreia vă adresaţi. Dacă folosiţi modul de felicitare
necorespunzător, veţi fi înţeles greşit.
În domeniul comunicaţiilor de date, aceste protocoale sunt mult mai complexe şi mai precise, dar ideea de bază
este aceeaşi. De exemplu, un protocol poate defini formatul în care un pachet de date este trimis prin reţea,
precum şi modul de interpretare a fiecărui câmp din interiorul pachetului, în mod evident, cele două
terminale care intră în comunicaţie trebuie să se înţeleagă relativ la formatul pachetelor: le vor schimba între ele.
Notă
Un protocol disponibil pe piaţă trebuie să fie o implementare a unui standard înţeles de toate celelalte
companii producătoare de astfel de produse. Dacă implementarea unei companii este înţeleasă greşit de alta,
înseamnă că între cele două implementări există incompatibilitate.
O stivă de protocoale este un grup de protocoale care funcţionează împreună, toate produse de aceeaşi
companie, cum este cazul SNA (Serial Number Arithmetic) dezvoltat de IBM, sau care sunt utilizate în acelaşi
mediu de lucru, cum este cazul suitei de protocoale utilizate Internet. Stivele de protocoale au definite interfeţe
cu protocoalele care funcţionează pe nivelurile adiacente ale modelului OSI, cum este cazul protocoalelor IPX
(Internetworking Packet Exchange) şi SPX (Sequenced Packet Exchange) din stiva NetWare.

13/61/
Protocoalele IPX/SPX din stiva NetWare dezvoltate de firma Novell

Stiva de protocoale NetWare îşi daterează numele celor două protocoale principale care funcţionează pe nivelurile
reţea şi transport ale modelului OSI: IPX şi SPX.

Notă
NetWare a fost prima dată dezvoltat de Novell, la începutul anilor 1980. Proiectarea lui a avut la bază
protocolul XNS (Xerox Net-work System) dezvoltat de Xerox la Centrul de Cercetare din Palo Alto (PARC).

Stiva de protocoale IPX/SPX NetWare oferă servicii de administrare a fişierelor, servicii de tipărire, de mesagerie şi
de aplicaţii. Arhitectura utilizată de această stivă este centralizată, deoarece calculatoarele transmit cereri de servicii
la server. De exemplu, salvarea unui fişier pe serverul de fişiere din reţea înseamnă pur şi simplu salvarea lui pe o
unitate F (sau pe o altă unitate mapată pe calculator), în acelaşi mod în care ar fi salvat pe unitatea locală C.
Protocoalele NetWare sunt modulare: le puteţi utiliza pentru multe tipuri de configuraţii hardware. Puteţi de
asemenea să utilizaţi şi alte protocoale, cum sunt TCP/ IP şi AppleTalk, împreună cu protocoalele NetWare
deoarece sunt flexibile. Datorită faptului că NetWare poate lucra şi cu alte protocoale în afară de IPX şi SPX, el
oferă un grad mare de interoperabilitate cu alte sisteme.
Stiva de protocoale NetWare poate fi mapată pe modelul OSI, aşa cum este prezentat în Figura A. l. În continuare
vor fi prezentate protocoalele NetWare, organizate pe funcţiile pe care le îndeplinesc, în concordanţă cu modelul
OSI.

Figura A.1. Stiva de protocoale NetWare mapată pe modelul OSI

Protocoale NetWare de nivel inferior

În mod normal, stiva de protocoale NetWare rulează pe protocoalele standard de nivel inferior, cum este Ethernet
(IEEE 802.3) şi Token Ring (IEEE 802.5). Protocolul de nivel inferior ce va fi prezentat în continuare, MLID, este
un standard pentru driverele plăcilor de interfaţă cu reţeaua.

__Protocolul MLID (Multiple Link Interface Driver)

Protocolul MLID operează pe subnivelul MAC al nivelului legătură de date din modelul OSI. El se ocupă cu accesul
la m°diu şi utilizează următoarele metode:
 administrarea conflictelor de acces la mediu
 trecerea jetonului de la o staţie la alta
 interogararea staţiilor
MLID este un standard pentru driverele de reţea. Fiecare tip de conexiune la reţea are un driver MLID unic.
Protocolul MLID este implementat în software. Un exemplu în acest sens este fişierul din DOS numit
NE2000.COM, scris pentru plăcile de reţea Novell/Eagle NE2000.
MLID mai este numit şi driverul de reţea sau driverul de LAN. Sarcina lui este comunice direct cu hardware-ul
plăcii de reţea. MLID este independent faţă de protocoalele de nivel superior datorită modul LSL (link support

14/61/
layer), aflat pe subnivelul LLC de pe nivelul legătură de date, care acţionează ca o interfaţă între MLID şi
protocoalele de nivel superior.
Interacţiunea dintre MLID, LSL şi alte componente este specificată de ODI (Open datalink Interface), standardul
Novell pentru comunicaţiile modulare din reţea. Specificaţia ODI vă permite să configuraţi uşor software-ul de client
cu ajutorul aceloraţi programe, indiferent de tipul plăcii de reţea. Cu această arhitectură, numai MLID este schimbat;
înainte de a exista ODI, trebuia să creaţi versiuni particulare de driver IPX pentru fiecare card de reţea.

Protocoalele NetWare de nivel mediu

Protocoalele NetWare de nivel mediu includ următoarele:

 IPX: utilizat pentru transportul pachetelor de date
 RIP şi NLSP: protocoale de rutare
 SPX: rulează la nivelul transport şi adaugă servicii orientate pe conexiune atunci când este necesară o
eficienţă superioară a comunicaţiei

__Protocolul IPX (Internetwork Packet Exchange)

Cel mai important protocol Novell este IPX. El are rolul de a administra adresarea (adresele logice şi de serviciu), de a
selecta rutele şi de a face conexiunile pentru serviciile oferite aplicaţiilor. IPX oferă servicii de datagrame fără
conexiune, ceea ce înseamnă că datele sunt trimise prin reţea pe mai multe rute şi nu printr-o singură conexiune. IPX
are la bază protocolul de datagrame IDP (Internetwork Datagram Protocol) dezvoltat de (Xerox Network System).
Deoarece oferă comunicaţii fără conexiune, IPX nu este potrivit pentru anumite tipuri de comunicaţii. Cele mai multe
comunicări dintr-o reţea, inclusiv conexiunile staţiilor dintr-o reţea şi procesele de tipărire, utilizează protocolul SPX,
descris în secţiunile următoare ale acestei anexe. Protocolul IPX este utilizat pentru transmiterea mesajelor de genul
notificărilor în caz de erori şi de sincronizare.
IPX realizează o selecţie dinamică a rutei pe baza tabelelor de informaţii realizate de RIP. În versiunea NetWare 4.1,
IPX este implementat de programul IPXODI.COM, care urmăreşte specificaţiile ODI. Versiunile mai vechi de
NetWare utilizau un program numit IPX.COM. Aşa cum a fost prezentat în secţiunea anterioară, înainte de a fi
utilizat ODI, erau necesare versiuni particulare de IPX pentru configurarea fiecărei plăci de reţea.

__Protocolul RIP (Routing Information Protocol)

RIP este protocolul predefinit de rutare în reţelele NetWare. Protocolul RIP utilizează metoda vectorului distanţă
pentru a determina numărul de hop-uri aflate pe diferite rute. Hop-urile sunt routerele intermediare pe care pachetele
trebuie să le traverseze pentru a ajunge la o destinaţie particulară.
Protocolul RIP funcţionează la nivelul reţea al modelului OSI deşi are atribuită o adresă. Deoarece este protocol
vector distanţă, RIP transmite tabelele de rutare periodic în toată reţeaua. Acest lucru poate produce gâtuiri atunci
când informaţiile trebuie transmise pe legături de mare distanţă. Pentru reţelele de arie mare este indicat să utilizaţi
protocoale care utilizează pentru routare metoda stării legăturilor, cum este protocolul NLSP.

__Protocolul NLSP (Network Link Services Protocol)

Protocolul NLSP este un alt protocol de rutare ce funcţionează la nivelul reţea al modelului OSI. Protocolul NLSP
utilizează metoda stării legăturilor pentru descoperirea rutelor şi crearea tabelelor de rutare. Are la bază protocolul de
rutare OSI numit IS-IS (Intermediate System - Intermediate System).
Protocoalele cu rutare pe baza stării legăturilor nu transmit în toată reţeaua tabelele de rutare periodic, aşa cum fac
protocoalele pe baza vectorilor distanţă. Aceste protocoale transmit tabelele numai în cazul în care apare o
modificare în reţea, de exemplu când o legătură se întrerupe sau se adaugă o nouă legătură pe o anumită rută.
Protocolul NLSP poate fi implementat pe reţele plasă sau plasă hibrida pentru creşterea toleranţei la defecte.

__Protocolul SPX (Sequenced Packet Exchange)

SPX este un protocol de transport care aduce un plus de eficienţă protocolului IPX. Acest protocol se ocupă de
adresare, de divizarea şi combinarea segmentelor de date şi de serviciile cu conexiune (secvenţierea segmentelor,

15/61/
controlul erorilor şi controlul fluxului end-la-end).
Protocolul SPX oferă servicii orientate pe conexiune atunci când transferul pachetelor sub formă de datagrame IPX
nu poate fi utilizat, cum este cazul transmiterii fişierelor la serverul de tipărire. Acest protocol oferă fiabilitate prin
intermediul circuitelor virtuale care sunt identificate ca ID al conexiunii. Pentru pachetele ajunse corect la destinaţie,
se trimit confirmări. Dacă sistemul destinaţie nu trimite aceste confirmări, pachetele vor fi retransmise.
Notă
Protocolul SPP (Sequenced Packet Protocol) dezvoltat de Xerox reprezintă baza protocolului SPX.

Protocoale NetWare de nivel superior

Cele două protocoale de nivel superior dezvoltate de Novell sunt NCP şi SAP, ambele acoperind toate nivelele superiore ale
modelului OSI. Protocolul NCP funcţionează la nivele transport, sesiune, prezentare şi aplicaţie. Protocolul SAP
funcţionează la nivelele sesiune şi aplicaţie.

__Protocolul NCP (NetWare Core Protocols)

Protocolul NCP funcţionează pe patru niveluri ale modelului OSI:

 La nivelul transport oferă servicii cu conexiune, cu secvenţierea pachetelor, controlul erorilor şi controlul de
flux end-la-end.
 La nivelul sesiune, protocolul NCP administrează sesiunile pentru transferurile de date.
 La nivelul prezentare, protocolul NCP este responsabil cu conversia (codurilor de caractere şi sintaxei
fişierelor).
 La nivelul aplicaţie, protocolul administrează utilizarea serviciilor, oferind un redirector al sistemului de
operare.

Protocolul NCP oferă un grup de funcţii care definesc schimburile dintre calculatorul client şi server. De exemplu,
un calculator client poate cere unui server să deschidă sau să modifice un fişier. Alte funcţii ale protocolului NCP
sunt cele de tipărire, de administrare a numerelor, servicii de administrare a fişierelor, sincronizare, precum şi de
blocare/deblocare a accesului la anumite fişiere. Deoarece NCP funcţionează la nivelul transport (pe lângă funcţiile
de nivele superioare) oferă şi servicii cu conexiune eficiente, în multe cazuri protocolul SPX ne mai fiind necesar.

__Protocolul SAP (Service Advertising Protocol)

La nivelul sesiune, protocolul SAP are rolul de a asigura administrarea sesiunilor pentru transferul fişierelor.
La nivelul aplicaţie, protocolul SAP anunţă în mod activ serviciile disponibile.
Ofertanţii serviciului, cum sunt serverele de fişiere sau serverele de tipărire, utilizează protocolul SAP pentru a
transmite mesaje prin care fac cunoscuteserviciile lor în toată reţeaua. Fiecare ofertant trimite mesaje la fiecare 60 de
secunde. Aceste pachete conţin tipul serviciului oferit şi adresa serverului care oferă acest serviciu. Calculatoarele
client pot şi ele să ceară informaţii despre servicii, cum este locaţia celui mai apropiat server de fişiere, prin
trimiterea unui pachet de tipul Service Query Packet.
Notă
În reţelele de arie mare, protocolul SAP poate deveni o problemă din cauza cantităţii de pachete transmise
în toată reţeaua de toate serverele pe legături lente, în acest caz, administratorul de reţea poate întrerupe
funcţionarea protocolului SAP pentru anumite servere.

Protocoale utilizate pe Internet

Prezentare generală

16/61/
 Familia de protocoale TCP/IP, având ca protocoale principale pe cele numite TCP, respectiv IP, conţine în
realitate un număr mai mare de protocoale, cele mai importante fiind prezentate în Figura A.2.0, care arată şi
plasarea lor pe nivelurile modelului de referinţă OSI.

Figura A.2.0 Familia de protocoale TCP/IP

Suita de protocoale utilizată pe Internet a fost dezvoltată o dată cu Internetul. Această suită de protocoale a fost
dezvoltată de Agenţia de Cercetare pentru Proiecte Avansate din Departamentul de Apărare al Statelor Unite
(ARPA şi mai târziu DARPA) în cadrul unui proiect mare de interconectare a reţelelor de calculatoare, început în
1969. Denumirea de TCP/IP provine de la Transmission Control Protocol (protocol de control al transmisiei) şi
Internet Protocol (protocol pentru Internet) şi au devenit standarde de facto datorită succesului Internetului. TCP/IP
este de departe cel mai utilizat protocol de interconectare a calculatoarelor.
TCP/IP a devenit astfel un standard de interoperabilitate a calculatoarelor, dar fără a avea un proprietar, ceea ce
înseamnă că nu aparţine nici unei companii şi oricine doreşte sa-1 utilizeze o poate face. Rezultatul principal este
faptul că această suită de protocoale este compatibilă cu foarte multe produse hardware.
Suita de protocoale Internet a fost dezvoltată cu zece ani înainte de definirea modelului OSI şi din această cauză nu
poate fi mapată prea bine pe acest model. Suita de protocoale pe Internet a fost definită pe baza unui model propriu,
cunoscut sub numele de modedelul Internet sau modelul DOD. Figura A.2 prezintă relaţia între suita de protocoale
utilizate pe Internet şi modelul OSI.

Figura A.2 Relaţia între suita de protocoale utilizate pe Internet şi modelul OSI.

17/61/
Cele patru niveluri ale modelului DOD (prezentate în Figura A.2) şi nivelurile spunzătoare ale modelului OSI sunt
următoarele:
 Nivelul de acces la reţea corespunde nivelurilor fizic şi legătură de date ale modelului OSI.
 Nivelul Internet corespunde nivelului reţelei din modelul OSI. Protocoalele acestui nivel se ocupă cu
transportul pachetelor prin reţele. Principalul protocol al nivelului Internet este IP.
 Nivelul punct-la-punct corespunde în mare nivelului transport al modelului OSI. Protocoalele acestui
nivel comunică cu cele de acelaşi nivel aflate pe alte calculatoare din reţea. Un exemplu de protocol punct-
la-punct este TCP.

Nivelul proces/aplicaţie corespunde nivelurilor sesiune, prezentare şi aplicaţie ale modelului OSI. Protocoalele acestui
nivel asigură servicii de aplicaţii în reţea. Exemple ale acestor protocoale sunt Telnet (emulator de terminal) şi FTP
(protocol de transfer al fişierelor).

Figura A.3 Modelul Internet mapat pe modelul OSI

Figura A.3 prezintă modelul Internet mapat pe modelul OSI. Protocoalele Internet nu acoperă primele două nivele
ale modelului OSI, din cauză că proiectanţii TCP/IP utilizează standardele deja existente pentru nivelurile fizic şi
date, cum este Ethernet sau Token Ring, pentru a face protocolul TCP/IP independent de hardware. Rezultatul este
că această stivă este utilizată de o gamă foarte largă de reţele calculatoare.
Deoarece suita de protocoale utilizată pe Internet nu include şi protocoale de nivel inferior, vom prezenta în
continuare protocoalele de nivel mediu şi superior utilizate pentru Internet.

Protocoale de nivel mediu utilizate pentru Internet

Aşa cum a fost prezentat, protocoalele nivelurilor reţea şi transport din modelul OSI se ocupă cu transportul
pachetelor de date prin reţea. Protocolul TCP/IP precum şi protocoale de Internet utilizează trei tipuri de adrese:
 Adrese fizice sau hardware, care sunt utilizate de nivelurile fizic şi legături de date. Adresele fizice sunt
de obicei scrise din fabricaţie pe placa de reţea a fiecărui echipament.
 Adresele IP oferă identităţi logice nodurilor unei reţele. Aceste adrese sunt unic alocate de administratorul
de reţea, după anumite reguli. Ele sunt exprimate în patru grupe de cifre separate prin puncte - de
exemplu 193.226.141.65.
 Numele nodurilor logice, pe care un administrator poate de asemenea să le aloce, sunt mai uşor de
memorat decât o serie de numere - de exemplu lalescu, moisil, pitagora, etc.

18/61/
__Protocolul IP (Internet Protocol)

Protocolul IP funcţionează la nivelul reţea. Funcţiile pe care le îndeplineşte, precum şi metodele pe care le
utilizează sunt după cum urmează:
 Pentru adresare, IP utilizează adresele logice de reţea.
 Pentru comutaţie utilizează metoda comutaţiei de pachete.
 Pentru selecţia rutei utilizează metoda dinamică.
 Pentru serviciile cu conexiune oferă controlul erorilor.
Protocolul IP este un protocol cu datagrame fără conexiune. (Pachetele IP mai sunt cunoscute şi sub denumirea de
datagrame IP). Protocolul IP utilizează comutaţia de pachete şi efectuează selecţia rutei prin utilizarea tabelelor
dinamice de rutare. Un pachet provenit dintr-un mesaj mai lung poate fi rutat pe o cale diferită de alte pachete al
aceluiaşi mesaj, în funcţie de starea reţelei din acel moment. De exemplu, dacă o legatură se întrerupe sau se
congestionează, pachetele pot utiliza alte rute.
Fiecărui pachet IP i se ataşează un header care include adresa sursă şi destinaţie. IP utilizează secvenţierea dacă
mesajul original este prea mare pentru a putea fi inclus într-un singur pachet IP, care presupune segmentarea
mesajelor la transmisie şi reasamblarea lor la recepţie. IP efectuează corecţie de erori la nivelul header-ului
folosind o sumă de verificare.
Notă
O sumă de verificare este o metodă de verificare a erorilor în care datele sunt supuse unui algoritm, iar
rezultatul este ataşat la pachet. Când pachetul ajunge la destinaţie, se fac calcule cu datele din pachet
pentru a se vedea dacă rezultatul coincide cu valoarea sumei de verificare.
Adresele IP sunt unice, pe patru bytes şi trebuie alocate fiecărui echipament sau nod adresabil din reţea, în
funcţie de clasa adreselor IP, un număr de bytes specifică zona de reţea şi un număr de bytes specifică adresa
calculatorului sau a echipamentului din acea zonă de reţea. Dacă doriţi să conectaţi reţeaua la Internet, trebuie
cerută adresa ce va fi alocată acestei reţele la centrul de informaţii despre reţea NIC (Network Information
Center), în cazul României de la RNC (Reţeaua Naţională de Calculatoare – http://www.rnc.ro). Astfel, în mod
sigur nu vor exista două reţele cu aceeaşi adresă. Adresele IP sunt alocate în concordanţă cu cele trei clase de
reţele: A, B şi C. Prin construc]ie o IP address este divizată în trei clase: clasa A, clasa B şi clasa C. Fiecare
clasă este utilizată într-un anumit context dependent de numărul maxim de calculatoare suportat de reţea. Fiecare
nod (=host=calculator) al reţelei trebuie să aibe partea de Host Address unic definită în cadrul reţelei.
După cum se vede în figura de mai jos IP address este formata din 4 grupe de câte maximum 3 cifre zecimale
separate printr-un “.”:
xxx. yyy. zzz. ttt unde un grup xxx, yyy, zzz, tttt [0,255]
În fapt cele 4 grupe de cifre corespund unei configuraţii binare pe 32 biţi (4 octeţi):

19/61/
 1 2 3 4
Adresă de IP

Cei 4 octeţi ai adresei de IP (IP address) sunt reprezentaţi în notaţie zecimală cu punct, fiecare octet putând
conţine o valoare cuprinsă între 0 şi 255 (exemplu: 193.226.14.65). IP address (în configuraţie binară pe 32 biţi)
se setează prin soft.

Notă
Astăzi prin preluarea protocolului TCP/IP de către Internet, protocolul în funcţiune IP versiunea 4 (IPv4),
care vehiculează adrese pe 32 biţi, se consideră depăşit deoarece cu el pot fi vehiculate prea puţine adrese
distincte (cca 4 miliarde). În consecinţă el este în curs de înlocuire de protocolul IP versiunea 6 (IPv6),
care va vehicula adrese pe 128 biţi.

Logic o adresă de IP este formată din două părţi: adresa reţelei (Network Address, octeţii 1, 1+2 sau 1+2+3) şi
adresa host-ului (calculatorului) din reţea (Host portion = Host Address, octeţii 2+3+4, 3+4 sau 4).
Dacă Host Address este 0, atunci IP address identifică reţeaua (Network Address): ex. 193.226.14.0
Dacă Host Address este 255, atunci IP address identifică toate calculatoarele din re]ea (Broadcast Address): ex.
193.226.14.255

Notă
Pentru reţelele conectate la Internet (reţele globale ale universităţilor, baze de date, companii, etc.), partea
de reţea- Network Address - a IP address este asignată de către o autoritate distribuită: NIC pentru SUA
respectiv RIPE pentru Europa respectiv RNC pentru România, asigurându-se astfel unicitatea adresei de
reţea.

Următoarele IP addresses sunt rezervate pentru scopuri speciale, ele neputând fi asignate nici unui host:

Network Addresses: -identifică reţeaua- porţiunea Host Address este setată la zero
exemplu: 193.226.14.0
Broadcast Address: -identifică toate host-urile din reţea- porţiunea Host Address este setată la 255
exemplu: 193.226.14.255
Loopback Addresses: 127.0.0.0 şi 127.0.0.1 - simulează host-ul local pentru diferite programe de test
sau simulare reţea-.

Adrese de clasă A:
Sunt adrese utilizate pentru sisteme cu un număr mic de reţele, dar cu un număr mare de calculatoare. Aceste
adrese utilizează primul byte pentru specificarea reţelei, iar ultimii trei pentru specificarea calculatorului. Primul
byte din adresa de clasă A poate fi în intervalul 0-127 - de exemplu, 80.23.102.3. Adresele IP valabile pentru
această clasă au fost deja alocate.
Adresarea în clasa A (Class A Addressing)
 primul octet specifică Network Address (porţiunea de reţea) a IP address;
 următorii trei octeţ]i specifică Host Address (porţiunea de host) a IP address;
 bitul 7, cel mai semnificativ, al Network Address este întotdeauna 0;
 valorile 0 şi 127 pentru primul octet (Network Address ) sunt rezervate;
 pot fi definite maximum 126 reţele cu adrese în clasă A;
 pentru fiecare adresă de reţea clasă A pot fi definite mai mult de 16 milione de adrese de noduri-uri

20/61/
 (Host Address).

Exemple de Network Address clasă A:

min: 1.yyy.zzz..ttt (ex. 1.234.50.12)
max: 126.yyy.zzz.ttt (ex.126.100.50.23)
unde: yyy, zzz, tttt [0,255]
Notă
În Internet IP addresses de clasă A sunt alocate unui număr foarte mic de utilizatori:
IBM, NASA, etc.

Adresele de clasă B
Oferă un număr egal de adrese pentru reţele şi pentru calculatoare prin alocarea primilor doi bytes pentru reţea şi a
ultimilor doi pentru calculator. Intervalul de valori pentru primul byte al adresei de clasă B este în intervalul 128-
191 - de exemplu, 132.45.67.28. Această clasă este de obicei alocată universităţilor şi organizaţiilor comerciale.
Adresarea în clasa B (Class B Addressing)
 primii doi octe]i specifică Network Address (porţiunea de reţea) a IP address;
 următorii doi octeţi specifică Host Address (porţiunea de host) a IP address;
 biţii 7 şi 6, cei mai semnificativi, ai Network Address sunt 10;
 pot fi definite mai mult de 16 mii de reţele cu adrese în clasă B;
 pentru fiecare adresă de reţea clasă B pot fi definite mai mult de 65 mii de adrese de host-uri (Host
Address).

Exemple de Network Address clasă B:

min: 128.0.zzz.ttt (ex. 128.40.125.200)
max: 191.255.zzz.ttt (ex. 191.47.134.60)
unde: zzz, tttt [0,255]
Adresele de clasă C
Utilizează primii trei bytes pentru specificarea reţelei şi ultimul byte pentru calculator. Deoarece este liber un
singur byte pentru adresele calculatoarelor, reţelele de clasă C nu vor avea un număr mare de calculatoare
conectate. Intervalul de valori pentru primul byte a adreselor de clasă C este între 192 - 223 - de exemplu,
194.123.45.7.
Adresarea în clasa C (Class C Addressing)
 primii trei octeţi specifică Network Address (porţiunea de reţea) a IP address;
 ultimul octet specifică Host Address (porţiunea de host) a IP address;
 biţii 7, 6 şi 5, cei mai semnificativi, ai Network Address sunt 110;
 pot fi definite mai mult de 2 milioane de reţele cu adrese în clasă C;
 pentru fiecare adresă de reţea clasă C pot fi definite 254 adrese de hosturi (Host Address).

21/61/
 Exemple de Network Address clasă C:
min: 192.0.0.ttt (ex. 193.226.14.65)
max: 223.255.255.ttt (ex. 223.226.14.65)
unde: tttt [0,255]
Notă
IP address a host-ului lalescu: 193.226.14.65, are partea de Network Address de clasă C;
Frecvent, în Internet, adresele de clasă C se subdivid corespunzător unor subreţele, caz
rezolvat de router-ul Internet prin tabelele de routare gestionate de administratorul de
reţea.

__Protocolul ARP (Address Resolution Protocol)

ARP este un protocol de nivel reţea care are rolul de a mapa numele nodurilor la adresele lor de IP. El face
asocierea şi între adresele logice şi fizice ale echipamentelor. Protocolul ARP păstrează o tabelă de mapări nume-
adresă şi poate trimite pachete de interogare dacă această tabelă nu conţine o anumită corespondenţă nume-adresă.
Acest pachet de interogare va cere entităţii corespunzătore perechea nume-adresă.

__Protocolul RARP (Reverse Address Resolution Protocol)

Este un protocol asemănător, RARP (Reverse Address Resolution Protocol), efectuează aceleaşi funcţii dar în
sens invers; adică, pentru o adresă IP el determină numele corespondent.

__Protocolul ICMP (Internet Control Message Protocol)

ICMP este un protocol utilizat cu IP pentru a îmbunătăţi procedurile e erorilor. El funcţionează la nivelul reţea şi
se aplică pentru servicii cu conexiune. ICMP oferă controlul erorilor şi controlul fluxului la nivel reţea.
ICMP detectează condiţiile de eroare, cum sunt congestia între reţele şi întreruperea legăturilor, şi notifică
protocolul IP precum şi protocoalele de nivel superior; astfel încât pachetele să poată fi rutate pe alte legături.

__Protocolul RIP (Routing Information Protocol)

RIP este un protocol la nivel reţea. Este un protocol de rulare pe baza metodei vector distanţă, ceea ce înseamnă
că va transmite periodic tabelele de rutare prin prin reţea. Este similar protocolului RIP din suita NetWare şi poate
produce gâtuiri în reţelele de arie mare, ceea ce a condus la înlocuirea lui cu protocolul OSPF.

__Protocolul OSPF (Open Shortest Path First)

OSPF este un alt protocol de nivel reţea care are rolul de descoperire a rutelor. Este un protocol bazat pe metoda
stării legăturilor, similar cu protocolul NLSP al NetWare, descris mai devreme în acest capitol. El a fost dezvoltat
pentru a fi mai eficient şi pentru a crea mai puţin trafic faţă de protocolul RIP. Asigură o încărcare doderată în
trafic, precum şi routare pe baza clasei serviciului.

__Protocolul TCP (Transmission Control Protocol)

TCP: Transmission Control Protocol este un protocol orientat pe conexiune care pune la dispoziţia proceselor
din aplicaţii un flux de octeţi fiabil, full-duplex. Este protocolul pe care se bazează cele mai multe programe de

22/61/
aplicaţii din Internet.
TCP este principalul protocol de transport din stiva Internet. El oferă şi servicii de adresare (pe baza adreselor de
serviciu) la nivelul reţea.
TCP oferă servicii de transport eficiente, full duplex şi orientate pe conexiune pentru protocoalele de nivel
superior. TCP funcţionează în conjuncţie cu protocolul IP pentru transportul pachetelor prin reţea. TCP alocă o
conexiune, un ID, fiecărui circuit virtual. De asemenea, asigură segmentarea şi reasamblarea cu numere de
secvenţă a mesaje Corecţia erorilor este îmbunătăţită prin mecanismul de confirmare a pachetelor transmise.

__Protocolul UDP (User Datagram Protocol)

UDP este un protocol fără conexiune care funcţionează la nivelul transport, UDP transportă datagrame, dar nu are
un mecanism de confirmare a pachetelor transmise. De asemenea, UDP utilizează adrese de port pentru
transmiterea datagramelor, dar aceste adrese de port sunt simple pointere către un proces, nu către un identificator
de conexiune ca în cazul protocolului TCP. Lipsa unor marcări suplimentare face ca acest protocol să fie mai
eficient faţă de TCP.

__Protocolul DNS (Domain Name Server)

DNS este un sistem distribuit de baze de date care funcţionează la nivelul transport şi oferă mapare nume-adresă
pentru aplicaţiile client. Serverele DNS păstrează baze de date ce conţin o structură ierarhică de nume ale
diferitelor domenii în scopul utilizării numelor logice pentru identificarea echipamentelor. Acest tip de
corespondenţă nume-adresă este numit „iniţiată de furnizare de servicii". Cea mai largă utilizare a DNS este
Internetul. Serverele DNS sunt utilizate pentru conversia numelor site-urilor, cum este TIBISCUS.RO în adrese
de reţea.

Protocoalele de nivel superior utilizate pe Internet

Protocoalele de nivel superior pentru Internet oferă în general aplicaţii sau servicii utilizate pe Internet, cum sunt
transferul de fişiere şi poşta electronică.

__Protocolul FTP (File Transfer Protocol)

Aşa cum îi spune şi numele, FTP este utilizat pentru transferul fişierelor între nodurile reţelelor, în plus, permite
utilizatorilor să iniţieze procese pe calculatoare îndepărtate. FTP permite utilizatorilor să acceseze calculatoare
îndepărtate. El funcţionează la nivelurile superioare ale modelului OSI, după cum urmează:

 La nivelul sesiune, FTP oferă administrarea sesiunilor, stabilirea conexiunilor, transferul fişierelor şi
eliberarea conexiunilor.
 La nivelul prezentare, FTP se ocupă cu conversia fişierelor, utilizând o sintaxă independentă de maşină.
 La nivelul aplicaţie, FTP oferă servicii de reţea, mai precis servicii de fişiere.

FTP este un protocol punct-la-punct. FTP are abilitatea de a transfera fişiere între calculatoare diferite deoarece
utilizează o structură generică de fişiere care este independentă de sistemul de operare.

__Protocolul Telnet

Telnet este utilizat pentru emularea terminalelor îndepărtate. El permite utilizatorilor să acceseze aplicaţii la
distanţă prin emularea unui terminal îndepărtat. Telnet permite conectivitate între sisteme de operare diferite.
Telnet funcţionează pe nivelurile superioare ale modelului OSI, după cum urmează:

 La nivelul sesiune, oferă un control al dialogului, printr-o metodă de transmisiune half duplex. De
asemenea, oferă administrarea sesiunilor prin controlarea stabilirii şi eliberării conexiunii, precum şi prin
controlarea transferului de fişiere.

23/61/
  La nivelul prezentare, Telnet are rolul de a converti sintaxele utilizând ordinea bytes-lor şi codurile
caracterelor.
 La nivelul aplicaţie, acest protocol oferă serviciile necesare operaţiilor de la distanţă.

__Protocolul SMTP (Simple Mail Transfer Protocol)

SMTP este protocolul utilizat pentru routarea mesajelor de poştă electronică. Pentru a putea furniza serviciul de
mesagerie, acest protocol funcţionează la nivelul aplicaţie.
SMTP nu oferă o interfaţă cu utilizatorul pentru transmiterea şi recepţionarea mesajelor, dar cele mai multe
aplicaţii de poştă electronică de pe Internet pot interfaţa cu acest protocol. SMTP utilizează TCP şi IP pentru
rutarea mesajelor de poştă electronică prin reţea.

__Protocolul NFS (Network File System)

NFS este un protocol de nivel aplicaţie care oferă servicii de administrare a fişierelor şi servicii de operare de la
distanţă. Un avantaj major al acestui protocol este caracterul său transparent; permite sistemelor de fişiere
îndepărtate să apară ca şi cum ar face parte din sistemul local de fişiere.

Notă
NFS face parte dintr-o familie de protocoale dezvoltate de Sun Microsystems şi este considerat a fi parte
din stiva de protocoale Internet. Acest grup de protocoale cuprinde platforma ONC (Open Network
Computing) a firmei Sun. De asemenea, NFS este şi numele unuia dintre protocoalele din familia Sun.

__Protocolul XDR (Externai Data Representation)

XDR este un protocol de nivel aplicaţie care se ocupă cu procesul de conversie. El utilizează metodele de
ordonare a bytes-lor, codurile caracterelor şi sintaxa fişierelor.
XDR este utilizat pentru reprezentarea datelor într-un format independent de maşină. Permite descrierea şi
codificarea datelor prin utilizarea unor biblioteci de rutine C permit programatorului să creeze structuri de date
care pot fi portate între diferite maşini.

__Protocolul RPC (Remote Procedure Caii)

RPC este un protocol de nivel sesiune care se ocupă cu administrarea sesiunilor (stabilirea şi eliberarea
conexiunilor, transferul de fişiere). Cu ajutorul acestui protocol un redirector de software determină dacă o cerere
poate fi satisfăcută local sau necesită accesarea reţelei. Redirectorul administrează împachetarea cererilor
transmise în reţea, iar transferarea acestor pachete este transparentă pentru utilizator.
Serverele RPC sunt în general specializate pentru administrarea cererilor RPC. Ele pot stoca fişiere mari şi au
abilitatea de a administra multe apeluri de proceduri. Serverul execută cererea şi generează un pachet de răspuns
pe care îl trimite la calculatorul emiţător al cererii.

Protocoale AppleTalk

AppleTalk este numele dat stivei de protocoale proiectate pentru calculatoare Apple Macintosh. Apple Computer
au început dezvoltarea stivei de protocoale AppleTalk în 1983. Faza 1 a avut unele limitări. Nu putea asigura
suport pentru comunicaţii între reţele deoarece schema de adresare nu include adrese de reţea. În 1989, Apple
Computers au extins abilităţile stivei de protocoale AppleTalk prin proiectarea fazei 2. Faza 2 permite
intercomunicarea cu alte reţele prin introducerea adreselor de reţea. Permite de asemenea, în cazul reţelelor
complexe, coexistenţa cu multe protocoale, Tabelul A.l rezumă diferenţele dintre stiva AppleTalk de fază l şi cea
de fază 2.

Caracteristică Faza l Faza 2

24/61/
 Figura A.4 Maparea stivei de protocoale Apple Talk pe modelul OSI

Protocoalele din cadrul stivei AppleTalk pot fi mapate pe modelul OSI, aşa cum este prezentat în Figura A.4.

Protocoalele de nivel inferior AppleTalk

Protocoalele de nivel inferior AppleTalk includ protocolul original LocalTalk, ca şi versiuni de Ethernet şi Token
Ring. Un alt protocol inclus aici este AARP (AppleTalk Address Resolution Protocol), care funcţionează la
nivelele legătură de date şi reţea al modelului OSI.

__Protocolul LocalTalk (LLAP)

Protocolul LocalTalk link Access Protocol, sau prescurtat LocalTalk, este un protocol original Apple care
funcţionează la nivelul fizic şi legătură de date.
La nivelul fizic, protocolul LocalTalk efectuează următoarele operaţii:

Tipul conexiunilor: multipunct

Topologia fizică: bus
Semnalizarea digitală: tranziţia stărilor
Sincronizarea de bit: sincronă
Utilizarea benzii: bandă îngustă

La subnivelul MAC al nivelului legătură de date, acest protocol are următoarele funcţii:

Topologie logică: bus

Accesul la mediu: conflict
Adresarea: la nivelul echipamentului fizic

La subnivelul LLC al nivelului legătură de date, acest protocol are următoarele funcţii:

Sincronizarea transmisiei: sincronă

Serviciile conexiunii: control de erori şi control de flux la nivel LLC

LocalTalk a fost dezvoltat pentru grupuri mici de utilizatori. Este un protocol lent, viteza sa de transmisie fiind de
230,4 kbps şi este limitat la 32 de echipamente conectate pe segmente de maxim 300 metri în total. Totuşi, chiar şi
cu aceste limitări, este util în cazul unor birouri mici. LocalTalk utilizează o schemă dinamică de adresare, care
permite fiecărei staţii să negocieze o adresă unică de nod în momentul pornirii reţelei.

25/61/
__Protocolul EtherTalk (ELAP)

Protocolul EtherTalk (EtherTalk Link Access Protocol) este o implementare a protocolului AppleTalk care
utilizează Ethernet (conflictul accesului, detecţia coliziunilor şi topologie star/bus).

__Protocolul TokenTalk (TLAP)

Protocolul TokenTalk (TokenTalk Link Access Protocol) este o adaptare a protocolului AppleTalk la nivelurile
fizic şi legătură de date. El utilizează protocolul Token Ring (accesul ; baza jetonului şi topologia star/bus).

__Protocolul AARP (AppleTalk Address Resolution Protocol)

Protocolul AARP mapează adresele AppleTalk pe adresele fizice Ethernet şi Token Ring. AARP permite
protocoalelor de nivel superior să utilizeze protocoale de nivel legătura de date altele decât LocalTalk.

__Protocoale de nivel mediu AppleTalk

Protocoalele AppleTalk care funcţionează la nivelurile medii ale modelului OSI sunt următoarele:

 DDP: pentru transmiterea pachetelor de datagrame

 RTMP: protocol de rulare pe baza mecanismului vector distanţă
 NBP: pentru maparea numelor logice pe adrese
 ATP: protocol de transport care utilizează confirmări pentru monitorizarea tranzacţiilor

__Protocolul DDP (Datagram Delivery Protocol)

Protocolul DDP este cel mai important protocol de nivel reţea din stiva AppleTalk. Oferă servicii fără conexiune
sau cu datagrame.
DDP utilizează conceptul de socket-uri sau de adrese de serviciu pentru specificarea protolului de nivel superior al
adreselor sursă şi destinaţie. DDP utilizează adresa completă pentru a ruta pachetele prin reţea. Adresa completă
este formată din adresa reţea, adresa nodului şi numărul socket-ului. O adresă de acest tip este de forma: reţeaua
logică 1002, nodul l, socket 3.
DDP funcţionează cu protocoalele RTMP, NBP şi ZIP pentru transmilerea datelor. El utilizează selecţia
dinamică a rutei şi suportă interoperatibilitatea prin furnizarea de conversie la nivelul reţea.

__Protcolul RTMP (Routing Table Maintenance Protocol)

RTMT este un protocol de rutare bazat pe metoda vector distanţă, similar cu protocolul RIP, care funcţioneză la
nivelul reţea. Acest protocol crază şi menţine tabele de rutare pe care DDP le utilizează pentru selecţia dinamică a
rutelor.

__Protocolul NBP (Name Binding Protocol)

AppleTalk utilizează acest protocol la nivelul transport pentru a face maparea j un nume logic de echipament şi
adresa corespunzătoare. Deoarece AppleTalk pe| adresarea dinamică a nodurilor, NBP trebuie să ştie adresa
curentă a unui anumej Această metodă de adresare este iniţiată de cel care cere serviciul.

__Protocolul ATP (AppleTalk Transaction Protocol)

Protocolul ATP este un protocol fără conexiune, cu confirmări, care funcţione niyehil transport. El execută
tranzacţii, nu conexiuni. O tranzacţie este formată dintr-o cerere urmată de un răspuns şi este identificată printr-un
identificator al tranzacţiei. Protocolul ATP confirmă pachetele primite şi retransmite acele pachete la care nu a
primit confirmări un interval mai mare de timp.

26/61/
__Protocoalele de nivel superior AppleTalk

Următoarele protocoale funcţionează la nivelurile superioare ale modelului OSI:

 ADSP: funcţionează la nivelurile transport şi sesiune ale modelului OSI

 ASP: administrează dialogurile
 PAP: utilizat în principal pentru tipărire
 ZIP: pentru administrarea grupurilor logice numite zone
 AFP: pentru accesul comun la fişiere
 AppleShare: pentru serviciile nivelului aplicaţie

__Protocolul ADSP (AppleTalk Data Stream Protocol)

Protocolul ADSP intră în categoria protocoalelor de nivel sesiune, deşi îndeplineşte şi funcţii de nivel transport.
Funcţiile de nivel sesiune pe care le îndeplineşte sunt stabilirea şi eliberarea conexiunii. Funcţiile de nivel
transport sunt secvenţierea şi controlul fluxului. Protocolul ADSP este o alternativă a protocolului de transport
ATP. ADSP nu urmăreşte desfăşurarea tranzacţiilor; el utilizează identificatorii de conexiune şi transmite datele
în fluxuri de bytes.

__Protocolul ASP (AppleTalk Session Protocol)

Protocolul ASP oferă servicii de nivel sesiune pentru stabilirea, menţinerea şi eliberarea conexiunilor.
Funcţionează împreună cu protocolul ATP pentru a oferi transmisii eficiente de pachete de date. ASP permite
stabilirea de sesiuni multiple pentru acelaşi furnizor de servicii, atât timp cât cererile sunt făcute individual de cei
care solicită serviciile.

__Protocolul PAP (Printer Access Protocol)

În ciuda numelui său, puteţi utiliza protocolul PAP pentru mai mult decât tipărirea documentelor. Este un protocol
de nivel sesiune care permite sesiunilor să fie iniţiate atât de cel care cere serviciul, cât şi de cel care oferă
serviciul. Protocolul PAP permite conexiuni între servere de fişiere şi staţiile de lucru, precum şi între staţii şi
serverele de tipărire.

__Protocolul ZIP (Zone Information Protocol)

Protocolul ZIP a fost dezvoltat pentru facilitarea partajării accesului la fişiere. O zonă poate reduce aparent
complexitatea unei reţele prin limitarea numărului de servicii în acea zonă. Routerele, precum şi alte noduri din
reţea, utilizează protocolul ZIP pentru maparea între zone şi numele reţelei.

__Protocolul AFP (AppIeTalk Filing Protocol)

AFP a fost dezvoltat pentru facilitarea accesului comun la fişiere. Funcţionează la nivelurile sesiune şi prezentare
pentru conversia comenzilor locale ale sistemului de fişiere într-un format care poate fi utilizat pentru servicii în
reţea. AFP oferă conversia sintaxei a fişierelor şi pentru alte aplicaţii. El permite o securitate mai bună prin
verificarea numelor şi parolelor utilizatorilor la accesul în reţea şi prin codificarea informaţiilor înainte de a fi
trimise prin reţea.

__Protocolul AppleShare

AppleShare este o suită de protocoale sau de aplicaţii care sunt oferite de AppleTalk la nivelul aplicaţie.
Următoarele protocoale intră în componenţa suitei AppleShare:

27/61/
  AppleShare File Server este sistemul de operare Macintosh. El utilizează protocolul AFP pentru a oferi
acces la fişierele distante. AppleShare File Server înregistrează utilizatorii şi permite celor înregistraţi să
aibă acces la fişierele de pe server.
 AppleShare Print Server utilizează protocoale de nivel inferior (cum sunt NBP şi PAP) pentru oferirea
serviciului de tipărire în reţea. Similar cu NetWare, stochează procesele de tipărire înainte de a le trimite
către imprimanta selectată. Utilizarea protocolului NBP permite utilizatorilor să aloce imprimantei orice
nume; protocolul NPB mapează numele imprimantei la adresa ei.
 AppleShare PC permite staţiilor DOS să acceseze serviciile de fişiere AppleShare. Un utilizator MS-
DOS care rulează AppleShare PC poate citi sau scrie pe un AppleShare File Server şi să tipărească pe un
AppleShare Prinţ Server.

AppleShare oferă servicii active de avertizare şi utilizarea de servicii în colaborare.

Protocoale DNA (Digital NetworkArchitecture)

Protocoalele DNA au fost prima dată dezvoltate în 1974 de către Digital Equipment Corporation ca arhitectură de
reţea. Implementarea DNA este cunoscută sub numele de DECnet. Această arhitectură a cunoscut mai multe
transformări, în acest moment fiind în Faza V. Digital a dezvoltat Faza V pe baza modelului OSI, dar pot fi
suportate şi versiuni mai vechi de protocoale.
DNA a devenit compatibil cu modelul OSI deoarece a adoptat unele protocoale OSI. Unele protocoale DNA nu
au o denumire prescurtată, ele fiind distinse prin numere. Figura A.5 prezintă maparea protocoalelor DNA pe
modelul OSI.

Figura A.5. Protocoalele DNA mapate pe modelul OSI

Protocoalele DNA de nivel inferior

Protocoalele de nivel inferior la care ne vom referi sunt Ethernet Version 2, DDCMP şi HDLC.

__Protocolul Ethernet Version 2

Digital, Intel şi Xerox au dezvoltat prima versiune de Ethernet. Ethernet Versio2 este foarte asemănătoare cu
prima versiune şi oferă baza de proiectare pentru IEEE 802.3. Ca şi IEEE 802.3, Ethernet Version 2 utilizează
pentru accesul la mediu CSMA/CD şi codificare digitală Manchester pentru a obţine viteze de 10 Mbps pe cablu
coaxial Ethernet Version 2 utilizează un alt format de cadru faţă de IEEE 802.3.

La nivelul fizic, Ethernet Version 2 oferă următoarele:

 Tipul de conexiune: multipunct
 Topologie fizică: bus
 Semnalizare digitală: starea tranziţiilor

28/61/
  Sincronizare de bit: sincronă
 Utilizarea benzii: bandă îngustă

La subnivelul MAC al nivelului legătură de date, acest protocol are următoarele funcţii
 Topologie logică: bus
 Accesul la mediu: conflict
 Adresarea: la nivelul echipamentului fiz

__Protocolul DDCMP (Digital Data Communications Message Protocol)

DDCMP este un protocol original DNA. El funcţionează Ia nivelul fizic şi la subnivelul LLC din cadrul nivelului
legătură de date.

Caracteristicile protocolului DDCMP includ:

 Servicii sincrone sau asincrone
 Mod de transmisie full sau half duplex
 Topologii punct-la-punct sau multipunct
 Servicii cu conexiune şi controlul erorilor prin intermediul comenzilor şi confirmărilor
 Servicii de control al fluxului şi de secvenţiere a mesajelor la nivelul LLC

__Protocolul HDLC (High-Level Data Link Control)

Protocolul HDLC este un protocol ce funcţionează la nivelul legătură de date, model; după protocolul SDLC (care
va fi prezentat ulterior în această documentaţie). Acest protocol suportă atât transmisiuni sincrone cât şi
transmisiuni asincrone. HDLC defineşte formatul de cadru de date şi formatul cadrului de comandă, ca şi setul de
comenzi propriu zise. Prin utilizarea acestor comenzi, HDLC poate oferi control de flux la nivel LLC. La nivelul
fizic, acest protocol oferă conexiuni punct-la-punct.

Protocoale DNA de nivel mediu

Protocoalele DNA de nivel mediu includ următoarele:

 CLNS: protocol standard ISO de nivel reţea

 CONS: protocol standard ISO de nivel reţea
 NSP: protocol proprietar DNA
 ISO 8073: protocol de transport ce oferă diferite clase de servicii

__Protocolul CLNS (Connectionless-Mode Network Service)

CLNS este un protocol de nivel reţea ce oferă servicii fără conexiune şi care suportă următoarele protocoale ISO:

 ISO 8473: Protocol pentru servicii fără conexiune (Protocol for Providing the Connectionless-Mode
Network Service). Acest protocol administrează comunicaţiile dintre două echipamente terminale.
 ISO 9542: Protocol de comunicare între sisteme terminale şi sisteme intermediare de rulare pentru
servicii fără conexiune (End System to Intermediate System Routing Exchange Protocol for
Providing the Connectionless-Mode Network Service), numit şi ES - IS. Oferă funcţii simple de
rutare care nu implică şi rutarea între reţele.
 ISO 10589: Protocol de rutare între sisteme intermediare din acelaşi domeniu pentru servicii fără
conexiune (Intermediate System to Intermediate System Intra-Domain Routing Exchange Protocol
for Providing the Connectionless-Mode Network Service), numit şi IS - IS. Oferă funcţii complexe de
routare; între reţele.

29/61/
DNA Fază V utilizează în general protocolul CLNS la nivelul reţea în locul protocolului CONS (vezi secţiunea
următoare). Protocolul CLNS oferă selecţia dinamică a rutei şi metoda de descoperire bazată pe starea legăturilor.

__Protocolul CONS (Connection Oriented Network Service)

Protocolul CONS este un protocol de nivel reţea care oferă servicii cu conexiune, care suportă următoarele
protocoale ISO:
 ISO 8208: Protocolul de nivel pachet X.25 pentru echipamente terminal de date (X.25 Packet-Level
Protocol for Data Terminal Equipment). Este versiunea ISO a protocolului X.25 (vezi secţiunea
„X.25" prezentată în acest document)
 ISO 8878: Utilizarea protocolului X.25 pentru oferirea serviciilor OSI orientate pe conexiune. Este
un protocol care permite servicii complete orientate pe conexiune pentru X.25.
Protocolul CONS oferă metoda bazată pe starea legăturilor pentru descoperirea şi selecţia dinamică a rutei. Oferă
în plus controlul fluxului la nivel reţea, controlul erorilor şi controlul secvenţelor de pachete.

__Protocolul NSP (Network Services Protocol)

Protocolul NSP este un protocol de nivel transport, unul din protocoalele originale DNA. A făcut parte din stiva
DNA din 1970. Este un protocol orientat pe conexiune, care oferă controlul fluxului şi care poate utiliza canale
normale sau de mare viteză full duplex.

__Protocolul ISO 8073 (Connection-Oriented Transport Protocol Specification)

ISO 8073 este un protocol de nivel transport care oferă diferite clase de servicii, permiţînd implementarea lui
pentru cerinţe speciale. O clasă de servicii poate fi selectată pe baza nivelului dorit de control al fluxului, al
erorilor şi al segmentării pachetelor.

Protocoalele DNA de nivel superior

Protoalele DNA de nivel superior includ atât protocoale originale DNA cât şi protocoale standard OSI. Vom
prezenta în această secţiune următoarele protocoale:
 Session control: protocol originar DNA
 ISO 8327: protocol standard de sesiune
 ASN.l with BER: descrie o sintaxă generică de fişier pentru facilitarea schimbului de fişiere între
diferite calculatoare
 FTAM: protocol generic de transfer de fişiere
 DAP: utilizat cu FTAM
 NVTS: protocol pentru terminal virtual
 MAILbus and X.400 Message Handling System: serviciu care permite transferul mesajelor pentru
clienţi îndepărtaţi
 Naming Service and X.500 Directory: oferă adresarea serviciilor şi servicii de directoare OSI

__Protocolul Session Control

Sesion Control este un protocol proprietar DNA care operează la nivelurile sesiune şi prezentare ale modelului
OSI.. Oferă o interfaţă între serviciile nivelului aplicaţie şi protocoalelor nivelului transport. Funcţiile oferite de
acest protocol includ:
- Rezoluţie de nume/adresă
- Administrarea conexiunilor de transport
- Selecţia stivei de protocoale
- Adresarea identificatorilor de conexiune

30/61/
__Protocolul ISO 8327 (Session Protocol Specification)

Protocolul ISO 8327 este implementat în concordanţă cu definiţiile ISO ale nivel l sesiune, aşa cum sunt ele
specificate în documentul ISO 8326. El oferă următoarele servicii.
 Negocierile de stabilire şi eliberare a conexiunilor.
 Transfer de date half duplex.
 Suport pentru conexiuni multiple de nivel transport pentru fiecare sesiune
 Sincronizarea transferurilor de pachete.

Notă:
Sincronizarea transferurilor de pachete este obţinută prin util unor markeri, numiţi jetoane de
sincronizare, care permit refa dialogului la fiecare moment de sincronizare.

__Protocolul ASN.1 with BER (Abstract Syntax Notation One with Basic Encoding Rules)

Protocolul ANS. l este un protocol de nivel prezentare care conţine un set de reguli de sintaxă pentru facilitarea
schimbului de date între diferite sisteme. El descrie un un cod de caractere standard pe care diferite entităţi îl pot
utiliza ca un cod de comunicare. Regulile propriu-zise sunt descrise în BER. Una dintre reguli este descrierea
tipului de cod de caracter udlizat pentru distingerea între două scheme de numere în virgulă mobilă.

__Protocolul FTAM (File Transfer, Access and Management)

FTAM este un protocol generic de transfer, acces şi administrare de fişiere operează la nivelul aplicaţie. El
specifică faptul că orice implementare FTAM trebuie să conţină anumite tipuri de documente, cum ar fi text şi
date binare, precum şi servicii, cum sunt transferul fişierelor şi administrarea lor. Producătorilor le este permis să
creeze implementări particulare ale acestui protocol.

__Protocolul DAP (Data Access Protocol)

DNA are abilitatea de a transfera fişiere prin intermediul protocolului DAP. Acest protocol de nivel aplicaţie ajută
protocolul FTAM să ofere operaţii de administrare de fişiere, cum sunt crearea fişierelor, ştergerea fişierelor,
stocarea fişierelor etc. De asemenea permite accesul la fişiere indexate.

__Protocolul NVTS (Network Virtual Terminal Service)

NVTS este un serviciu care permite acces prin intermediul unor terminale virtuale la calculatoare îndepărtate. El
operează la nivelurile prezentare şi aplicaţie. NVTS utilizează conversia codurilor de caractere pentru conversia
datelor din formatul terminalului local într-un format cunoscut de reţea pentru a le putea transmite la terminalul
îndepărtat. Acest lucru permite comunicarea între reţele eterogene.

__Protocoalele MAILbus şi X.400 Message Handling System

Aceste protocoale funcţionează la nivelul aplicaţie şi sunt utilizate pentru servicii de poştă electronică. MAILbus
oferă poştă electronică DNA. De asemenea, utilizează standardul X.400 pentru interfaţarea cu alte sisteme sau
reţele compatibile X.400. X.400 este o recomandare care specifică modul în care mesajele sunt stocate şi
retransmise între echipamente diferite.

__Protocoalele Naming Service şi X.500 Directory

Protocolul DNA Naming Service funcţionează la nivelurile transport şi aplicaţie pentru oferirea serviciului de
rezoluţie nume/adresă. Acesta permite echipamentelor reţelei să funcţioneze cu nume alfanumerice. Apoi,
Naming Service traduce aceste nume în adrese de reţea. Acest serviciu nu este însă complet compatibil cu

31/61/
recomandările X.500, dar Digital va rezolva această deficienţă la noile versiuni.

Protocoale SNA (System Network Architecture)

SNA este o arhitectură originală IBM. A fost iniţial dezvoltată în 1974 în concordanţă cu modelul ierarhic de
reţea utilizat de IBM în acea perioadă. Echipamentele din calculatoare host mainframe, controlere de comunicaţie,
controlere de grup şi terminale.

Figura A.6 Maparea SNA pe modelul OSI

În 1984, IBM a adăugat suport pentru facilităţi avansate, cum sunt procesarea distribuită, interconectarea şi
gestionarea reţelei. Această extensie este cunosctă sub numele de “Advanced Peer-to-Peer Networking” sau
APPN.

IBM a lansat în 1987 produsul SAA (Systems Application Architecture). El prornovează facilităţi mai avansate
ale SNA, cum sunt LU 6.2 şi PU 2.1.

SNA a fost dezvoltat pe baza modelului pe şapte niveluri, numit model SNA, care precede modelul de referinţă
OSI (şi, de fapt, este baza modelului OSI). Figura A.6 compară cele două modele şi mapează diferite produse şi
protocoale SNA pe modelul OSI

Nivelurile modelului SNA

Modelul SNA, aşa cum este prezentat în Figura A.6, este asemănător modelului OSI cu excepţia faptului cu
excepţia faptului că funcţionalităţile sunt grupate uşor diferit. Modelul SNA următoarele niveluri:

 Nivelul de control fizic este primul nivel al modelului SNA, care se ocupă cu caracteristicile
transmisiunii fizice a semnalului. Acest nivel defineşte caracteristicile electrice, mecanice şi de procedură
ale mediului fizic, precum şi interfeţele cu el. SNA nu defineşte nici un protocol de control al nivelului
fizic. IBM s-a aliniat la standardele internaţionale pentru nivelele fizice, singura deosebire fiind
standardul Token Ring, care a început ca un standard de firmă şi apoi a fost standardizat la nivel mondial
sub numele de IEEE 802.5.
 Nivelul de control al legăturii de date: nivelul doi al modelului SNA este asemănător celui din modelul
OSI, specificând metodele de acces la mediu şi formatele de cadre utilizate. La acest nivel, modelul SNA
defineşte protocolul SDLC pentru comunicaţii master-slave sau principal-secundar şi Token Ring pentru
comunicaţiile în reţelele punct-la-punct.
 Nivelul de control al căii de transmisie defineşte funcţiile de bază incluse în nivelul reţea din modelul
OSI, adică rularea şi asamblarea/dezasamblanea pachetelor de date. Include de asemenea şi controlul
fluxului, prezent în modelul OSI la nivelul legătură de date.
 Nivelul de control al transmisiei: acest nivel oferă servicii end-la-end, similare cu cele oferile de nivelul

32/61/
 transport al modelului OSI. În plus, acest nivel oferă servicii de criptare a datelor, funcţie alocată
nivelului prezentare în modelul OSI.
 Nivelul de control al fluxului de date: acest nivel corespunde în mare nivelului sesiune al modelului
OSI. El administrează dialogurile, controlează procesarea cererilor şi a răspunsurilor, mesajele de grup şi
întrerupe fluxul de date la cerere.
 Nivelul de prezentare a serviciului include servicii ale nivelului prezentare din modelul OSI, în
principal servicii de conversie a datelor, ca şi servicii ale nivelului aplicaţie din modelul OSI, cum sunt
coordonarea resurselor comune şi sincronizarea operaţiilor.
 Nivelul de tranzacţie a serviciului: nivelul cel mai de sus al modelului SNA oferă funcţii ale nivelului
aplicaţie din modelul OSI. Oferă servicii de aplicaţie pentru procesarea distribuită şi administrarea reţelei.
Un exemplu de serviciu de tranzacţie SNA este SNADS (SNA Distribution Service), care oferă un sistem
de distribuţie a aplicaţiilor SNA.

Arhitectura SNA şi componentele ei

Arfitectura ierarhizată a SNA are o terminologie proprie pentru diferitele componente hardware. Echipamentele
componente ale unei reţele SNA poartă numele de noduri şi ele sunt categorisite după tip. Figura A.7 ilustrează
diferitele tipuri de noduri SNA.
Nodurile host (tipul 5) sunt calculatoare mainframe sau minicalculatoare. Un nod host controlează un
domeniu, care este compus din unităţi fizice, unităţi logice, legături şi alte resurse asociate. Domeniile includ
una sau mai multe subzone, care sunt diviziuni compuse din controlere de comunicaţii şi unităţi fizice şi
logice asociate.
Nodurile controlerelor de comunicaţie (tipul 4) sunt echipamente care rutează şi controlează fluxul de
informaţii din subzonele unei reţele SNA. Aceste noduri mai sunt numite şi procesoare front-end deoarece
preiau unele procese ale nodurilor host. În mod normal sunt ataşate prin canale de mare viteză direct la hosturi
sau prin intermediul altor controlere de comunicaţie.
Nodurile periferice (tipul 2) includ echipamentele client, cum sunt controlerele de grup, terminalele şi
imprimantele.

Figura A.7 Tipurile de noduri SNA

Pentru conectarea diferitelor tipuri de noduri, IBM a clasificat echipamentele de reţea şi software-ul astfel:
 Unităţi fizice (FU): Combinaţie de hardware şi software care administrează şi monitorizează resursele
unui nod. Cele trei tipuri de noduri descrise mai sus sunt unităţi fizice.
 Unităţi logice (LU): Combinaţie de software şi hardware care oferă puncte de conectare pentru
comunicarea între noduri. Ele permit oamenilor şi aplicaţiilor să acceseze reţeaua.

33/61/
  Puncte de control: Instrumente de administrare software care operează cu unităţi fizice de tipul 5 şi de
tipul 2.1 pentru a permite administrarea şi controlarea fluxului de date din reţea.
Tabelele A.2, A.3 şi A.4 prezintă modul în care sunt clasificate cele trei categorii şi tipurile de echipamente pe
care le includ.

Tip Descriere
1 Noduri terminale
Tabelul A.2 2 Controlere de grup, terminale şi imprimante. Aceste echipamente pot
Unităţile fizice comunica numai cu calculatoare mainframe.
ale SNA 2.1 Minicalculatoare, controlere de grup, gateway-uri şi staţii care pot comunica
cu calculatoare mainframe sau cu alte tipuri de echipamente. Unităţile fizice
de tipul 2.1 sunt fundaţia fizică a noilor specificaţii APPN
4 Controlere de comunicaţie
5 Calculatoare host

Tip Descriere
0 Unităţi logice cu scop general utilizate pentru comunicaţii între programe.
Tabelul A.3 Aceste unităţi logice au fost înlocuite de cele de tip 6.2, mult mai avansate.
Unităţile logice 1 Grupuri de terminale, cititoare de cartele şi imprimante.
ale SNA 2 Grupuri de echipamente, similare cu cele de tip l.
4 Conexiuni vechi punct-la-punct, cum sunt cele de tipul 6670.
6 şi 6.1 Conexiuni la puncte CICS sau comunicaţii IMS între calculatoare mainframe.
6.2 APPN
7 Staţii de afişare (cum ar fi 5270).

Tip Descriere
5 Aceste unităţi fizice (host-uri) rulează un software centralizat într-o reţea SNA
Tabelul A.4 pentru a administra configuraţiile, pentru a coordona cererile şi a oferi servicii
Puncte de control de sesiune utilizatorilor reţelei. Acest sistem este numit SSCP (System Service
SNA Control Point). Mai multe SSCP-uri pot împărţi reţeaua în domenii ierarhice.
2.1 Aceste unităţi fizice sunt capabile de acelaşi tip de management ca şi
echipamentele de tip 5 dar la o scară mai mică. Unităţile fizice de tip 2.1 oferă
puncte de control în reţelele punct-la-punct.

Următoarele secţiuni descriu unele protocoale şi produse cheie ale SNA în concordanţă cu funcţiile pe care le
îndeplinesc relativ la modelul OSI.

Protocoale SNA de nivel inferior

Protocoale SNA de nivel inferior sunt Tokep Ring, SDLC şi NCP, un protocol care include atât funcţionalităţi de
nivel legătură de date, cât şi funcţionalităţi de nivel reţea.

__Protocolul Token Ring

Token Ring este o specificaţie IBM pentru reţele locale la nivel fizic şi legătură de date. El utilizează o metodă de
acces la mediu cu jeton pentru transmiterea datelor cu viteze de 4 sau 16 Mbps pe o topologie fizică de stea şi logică de
inel. Utilizează conexiuni punct cu punct, cu semnalizare digitală a tranziţiei stărilor, sincronizare de bit sincronă şi
lungime de bandă de bază.
Token Ring a fost baza standardului IEEE 802.5. IBM Token Ring utilizează cablu bifilar protejat (STP) şi
conectori specifici IBM.

34/61/
__Protcolul SDLC (Synchronous Data Link Control)

SDLC este un protocol la nivel legătură de date care suportă conexiuni punct-la-punct sau conexiuni multipunct
între reţele SNA primare şi secundare. SDLC utilizează metoda de acces prin polling şi sincronizarea de cadru.
Poate oferi conexiuni full duplex sau half duplex pe linii telefonice închiriate sau comutate. SDLC generează
mesaje specifice de control, pe lângă informaţiile specifice headerului nivelului legături de date.

__Protocolul NCP (Network Control Program)

Protocolul NCP al IBM a fost iniţial proiectat să controleze resursele ataşate la controlerele de comunicaţie. În
primul rând oferă funcţii de nivel legătură de date. NCP a fost extins pentru a putea efectua funcţii de rutare şi
servicii de gateway specifice nivelului reţea. Utilizează metoda de acces la mediu prin polling şi permite
adresare fizică şi logică. În plus, pe lângă controlul fluxului, asigură şi selecţia statică a rutei.

Protocoale SNA de nivel mediu

Protocoalele SNA de nivel mediu sunt APPN şi VTAM.

__Protocolul APPN (Advanced Peer-to-Peer Networking)

APPN funcţionează la nivelurile reţea şi transport pentru a asigura conexiuni punct-la-punct între unităţi fizice
multiple de tip 2.1. APPN este dependent de punctele de conexiuni logice APPC (Advanced Program-to-
Program Communications). APPN oferă facilităţi de descoperire a rutei, controlul fluxului cu fereastră şi servicii
director.

__Protocolul VTAM (VirtualTelecommunications Access Method)

VTAM este un produs IBM care oferă controlul comunicaţiilor de date şi controlul fluxului de date într-o reţea
SNA. VTAM controlează atât domenii simple cât şi domen multiple. SSCP este principala componentă software
a VTAM.
La nivelul transport, VTAM utilizează identificatori de conexiune pentru adresare, diviziunea şi combinarea
segmentelor de date şi oferă controlul fluxului end-to-end. La nivelul sesiune, VTAM controlează comunicaţiile
half duplex şi administrează sesiunile (stabilirea şi eliberarea conexiunii, transferul de date).

Protocoalele SNA de nivel superior

Protocoalele SNA care funcţionează la nivelurile superioare sunt următoarele:

 CISC: un mediu pentru programarea aplicaţiilor de procesare a tranzacţiilor
 IMS: similar cu CISC
 APPC: extensie a SNA care permite comunicaţii punct-la-punct
 DDM: acces transparent la fişiere îndepărtate
 SNADS: controlează distribuţia mesajelor
 DIA: standard pentru schimbul de documente

__Protocolul CICS (Customer Information Control System)

CISC este un instrument pentru construirea de aplicaţii ale tranzacţiilor şi procesare. Oferă un set de comenzi de
intrare şi ieşire generice pentru mediu SNA. CISC oferă acces distribuit la fişiere, securitate, multitasking,
comunicaţii terminal-către-aplicaţie, administrarea stocărilor de informaţii, urmărirea tranzacţiilor, recuperarea
tranzacţiilor.
La nivelul sesiune, CISC controlează comunicaţiile half duplex şi administrează sesiunile (stabilirea şi eliberarea
conexiunii, transferul datelor). La nivelul prezentare se ocupă cu conversia sintaxei fişierelor.

35/61/
__Protocolul IMS (Information Management System)

IMS este un instrument pentru construirea de aplicaţii a tranzacţiilor şi procesare, similar cu CISC. Este format
din două părţi: IMS Transaction Manager şi IMS Database Manager. IMS permite aplicaţiilor multiple să
partajeze baze de date şi să programeze priorităţile tranzacţiilor.
Ca şi CISC, IMS funcţionează la nivelurile sesiune şi prezentare prin controlarea comunicaşiilor half duplex,
administrarea sesiunilor şi conversia sintaxei fişierelor (stabilirea şi eliberarea conexiunii, transferul datelor).

__Protocolul APPC (Advanced Program-to-Program Communication)

APPC este o extensie a SNA care defineşte LU de tip 6.2 şi permite comunicaţii punct-la-punct între unităţile
logice. APPC oferă funcţionalităţi ale nivelurilor transport şi sesiune. La nivelul transport utilizează
identificatori de conexiune pentru adresare, oferă diviziunea şi combinarea segmentelor de date şi controlul
fluxului end-la-end. La nivelul sesiune controlează comunicaţiile half duplex şi administrează sesiunile
(stabilirea şi eliberarea conexiunii, transferul de date).

__Protocolul DDM (Distributed Data Management)

Protocolul DDM este un serviciu de nivel aplicaţie care oferă acces transparent la date. Utilizează interceptarea
apelurilor sistemelor de operare pentru obţinerea transparenţei. DDM primeşte cereri pentru accesul la fişiere de
la procesele client, şi, funcţie de locaţia serverului, transmite sistemului local de operare fişierul sau se adresează
altui server.

__Protocolul SNADS (SNA Distributed Service)

SNADS este un serviciu de nivel aplicaţie care controlează distribuţia de mesaje şi documente. Utilizează pentru
distribuţia fişierelor mecanismul de stocare-şi-retransmisie. SNADS are o infracstructură pentru transmiterea
mesajelor de poştă electronică..

__Protocolul DIA (Document Interchange Architecture) .

DIA este un protocol de nivel aplicaţie care defineşte un standard pentru schimbul de documente între diferite
calculatoare. Transferul fişierelor, găsirea şi stocar documentelor sunt coordonate de DIA.

Alte protocoale şi standarde

În continuare se vor descrier diferite standarde şi protocoale. Uneele sunt protocoale de reţele locale; altele,
inclusiv cele utilizate pentru reţelele publice de date, sunt folosite în reţelele de arie mare.

__Protocolul SLIP (Serial Line Internet Protocol)

Protocoalele SLIP şi PPP sunt standarde comune utilizate foarte des pentru comunii seriale punct-la-punct pentru
conectare la Internet. Dacă vă conectaţi de acasă la Internet veţi folosi acest protocol. Timp de peste zece ani,
protocolul SLIP a fost un protocol foarte popular, care oferă un mod foarte simplu şi eficient de conectare la
servere TCP/IP. Totuşi, protocolul SLIP este un protocol care funcţionează la nivelul fizic şi nu oferă controlul
erorilor şi securitate., În ciuda acestui fapt, acest protocol este foarte popular pentru accesul la Internet. Cei mai
mulţi utilizatori nu au nevoie de conexiuni securizate şi cele mai multe modeme de viteză mare oferă propriul
lor control al erorilor.
Notă
Deşi SLIP funcţionează la nivelul fizic al modelului OSI, el este de multe ori prezentat ca un protocol

36/61/
 de nivel legătură de date.

__Protocolul PPP (Point-to-Point Protocol)

Protocolul PPP a fost dezvoltat ca o îmbunătăţire a protocolului SLIP, oferind servicii atât la nivel fizic cât şi la
nivel legătură de date. PPP include funcţii adiţionale de suport multiprotocol, control al erorilor, securitate,
adresare IP dinamică. Ambele protocoale sunt protocoale punct-la-punct. PPP oferă adresare fizică la nivelul
MAC şi control de erorii LLC.
Figura A.8 prezintă maparea protocoalelor PPP şi SLIP pe modelul OSI.

Figura A.8 Maparea protocoalelor PPP şi SLIP pe modelul OSI

FDDI

FDDI este o topologie standard pentru reţele locale (LAN) şi metropolitane (MAN) care utilizează fibra optică
pentru transmiterea pachetelor de date. Datorită utilizării fibrei optice, lungimea cablurilor poate fi mult mai
mare faţă de cea utilizată în reţelele locale, deci poate fi utilizată şi pentru reţele de arie mare. Această topologie
administrează accesul la reţea prin utilizarea unei metode de transfer al jetonului similar cu IEEE 802.5, Token
Ring. Ea are multe îmbunătăţiri faţă de reţele Token Ring, printre care o strategie de toleranţă la defecte care
presupune instalarea a două inele în locul unuia singur, precum şi o tehnică de acoperire, numită „wrapping”.
Figura A.9 prezintă modul de mapare FDDI pe modelul OSI.

Figura A.9 Standardul FDDI mapat pe modelul OSI

37/61/
FDDI utilizează viteze uzuale de transmisie în jurul valorii de 100 Mbps, ceea ce îl face foarte bun pentru
aplicaţii de video şi multimedia. FDDI are o arhitectură de inel dual. Ea utilizează inelul primar pentru transferul
datelor şi pe cel secundar pentru asigurarea toleranţei la defecte şi pentru backup. Cele două inele au sensuri
diferite de parcurgere lucru pentru care sunt numite „dual counter-rotating rings”. Staţiile de pe inelul FDDI pot
fi cu ataşare simplă, conectate la un singur inel, sau cu conectare dublă, conectate la ambele inele. La o
întrerupere a inelului, dacă toate staţiile sunt cu ataşare simplă, acesta se va întrerupe deoarece jetonul nu va mai
putea ajunge la staţia următoare. Dacă însă staţiile sunt cu conectare dublă, inelul se va reconfigura automat şi
jetonul va evita întreruperea.

__X.25

Organizaţia internaţională CCITT, numită acum ITU, a standardizat X.25 în anul 1974 ca un standard de
comutaţie de pachete pentru reţele de arie mare.
Aşa cum se vede în Figura A.10, X.25 funcţionează la nivelul reţea. În mod normal se interfaţează la nivelul
legătură de date cu protocolul LAPB (Link Access Procedures-Balanced), care rulează pe X.21, sau un alt
protocol CCITT de nivel fizic, cum este X.21bis sauV.32.

Figura A.10 Protocolul X.25 mapat pe modelul OSI

 X.25 oferă circuite permanente sau comutate, care permit transmisii cu control de flux end-la-end.
Totuşi, viteza liniilor utilizate pentru X.25 este mult prea mică pentru a oferi servicii de aplicaţie
specifice reţelelor locale într-o reţea de arie mare.
 La nivelul fizic, X.21 permite o topologie hibridă tip plasă şi conexiuni punct-la-puncr.
 LAPB este un protocol de nivel legătură de date bazat pe SDLC care oferă control de erori şi de flux la
nivelul LLC.
La nivelul reţea, X.25 oferă un tip de adresare numit adresare de canal, similară cu adresarea logică, cu
deosebirea că adresa este menţinută pentru fiecare conexiune pe durata ei.

Frame Relay

|Frame Relay este o tehnologie cu comutaţie de pachete similară cu X.25 care foloseşte circuite virtuale. Ca şi
X.25, este utilizată în reţele de arie mare. Frame Relay lasă anumite sarcini de control al erorilor şi monitorizare
pe seama protocoalelor de nivel superior, ceea ce îi conferă o viteză sporită. Figura A. 11 prezintă funcţiile
oferite de Frame Relay la nivelurie fizic şi legătură de date ale modelului OSI, aşa cum sunt ele definite de
recomandările CCITT I.451/Q.931 şi Q.922.

38/61/
 Figura A.11 Frame Relay mapat pe modelul OSI

La nivelul fizic, Frame Relay oferă conexiuni punct-la-punct pe topologii hibride. La nivelul LLC, oferă detecţia
dar nu şi corecţia erorilor.
Notă
Serviciile de Frame Relay permit în general clienţilor să specifice diferite rate de transmisie, în
funcţie de necesităţile lor de bandă.

Reţele digitale cu integrarea serviciilor (ISDN) şi reţele integrate de bandă largă (B-ISDN)

ISDN este set de standarde proiectate pentru transmisii de voce, video şi date pe reţele telefonice digitale.
B-ISDN oferă o capacitate de bandă mai mare, care poate fi utilizată pentru video, imagini în mişcare şi
multimedia. B-ISDN poate fi implementat cu SONET şi ATM, care vor fi descrise în continuare.
La nivelul fizic, ISDN oferă multiplexare cu diviziune de timp (TDM). La nivelul reţea ISDN este definit
de^comandările CCITTI.450/Q930 şi I.451/Q.931.
Figura A.12 prezintă maparea ISDN pe modelul OSI.

Figura A.12 ISDN mapat pe modelul OSI

ISDN funcţionează numai ca serviciu de transmisie. Specificaţiile ISDN utilizează protocolul LAPD (Link
Access Procedure, D Cannel) la nivelul legătură de date, care oferă servicii cu confirmări, fără conexiune, full
duplex. La nivelul MAC, LAPD oferă adresare fizică. La nivelul LLC face control de flux şi secvenţiere de
cadre.
Standardul ISDN pentru integrarea transmisiilor digitale şi analogice pe reţele digitale permite conexiuni cu
comutaţie de circuite şi cu comutaţie de pachete. Aceste conexiuni sunt oferite prin canalele digitale de
comunicaţie, numite pipe-uri. Prin utilizarea pipe-urilor ISDN sunt disponibile mai multe canale multiplexate de
viteză standard. Aceste canale sunt clasificate după cum urmează:

39/61/
  Canalul A: canal analogic, 4 kHz;
 Canalul B: canal digital, 64 Kbps;
 Canalul C: canal digital utilizat pentru semnalizări în afara benzii, 8 sau 16 Kbps;
 Canalul D: canal digital utilizat pentru semnalizări în afara benzii, 16 sau 64 Kbps. Include trei
subcanale: s - pentru semnalizare, t - pentru măsurări telemetrice, p – pentru date de bandă îngustă.
 Canalul E: canal digital pentru semnalizări interne ISDN, 64 Kbps;
 Canalul H: canal digital, 384,1536 sau 1920 Kbps;
LAPD operează pe canalul D.

Următoarele trei combinaţii de canale au fost standardizate de CCITT pentru utilizare internaţională:

 Rata de bază: include 2 canale B (la 64 Kbps) şi l canal D (la 16 Kbps)

 Rata primară: include l canal D (la 64 Kbps), 23 de canale B în Statele Unite şi Japonia sau 30 de
canale B în Europa şi Australia
 Hibrid: include l canal A (4 kHz) şi 1 canal C (8 sau 16 Kbps)

Reţeaua optică sincronă (SONET) şi Ierarhia digitală sincronă (SDH)

SONET a fost dezvoltat de Bell Communication Research. Este un protocol de nivel fizic standardizat de ANSI
şi utilizat pentru reţelele de arie mare. ITU (fostul CCITT) a creat un standard similar numit SDH. Implementări
regionale, dezvoltate din cauza diferitelor situaţii locale, sunt SDH- Europa, SDH-SONET (America de Nord) şi
SDH- Japonia. Figura A.13 prezintă maparea SONET şi SDH pe modelul OSI. SONET şi SDH oferă conexiuni
punct-la-punct, pe topologii plasă sau inel şi utilizează metoda de multiplexare TDM.

Figura A.13 SONET şi SDH mapat pe modelul OSI

__Modul de transfer asincron (ATM)

ATM este un standard recent dezvoltat de ITU şi ATM Forum. Reţelele ATM sunt descendente ale reţelelor cu
comutaţie de pachete. Acest protocol are funcţionalităţi ale nivelurilor de legătură de date şi reţea ale modelului
OSI şi poate opera peste protocoalele de nivel fizic ca FDDI sau SONET/SDH. Figura A. 14 prezintă modul de
mapare al ATM OSI.

40/61/
 Figura A.14 maparea ATM pe modelul OSI

Avantajul vitezei foarte mari a acestui protocol provine din transmisia uniformă de pachete de date, care sunt
împărţite în subdiviziuni de dimensiuni egale cu 53 de biţi, numite celule, şi rutate prin comutatoare hardware cu
selecţie statică a rutei.
La nivelul LLC, ATM oferă o sincronizare izocronă a transmisiei şi control de erori.

__Serviciul SMDS (Switched Megabit Data Service)

SMDS este o tehnologie bazată pe comutare de celule, dezvoltată de Bell Communication Research. Ca şi ATM,
utilizează pachete de dimensiuni mici, numite celule. Poate fi mapat pe nivelurile legătură de date şi reţea ale
modelului OSI şi este utilizat în mod normal cu protocoalele de nivel fizic DQDB (IEEE 802.6) şi
SONET/SDH. La nivelul LLC, SMDS oferă sincronizare izocronă a transmisiei. Figura A. 15 prezintă modul de
mapare a SMDS pe modelul OSI.

Figura A.15 maparea SMDS pe modelul OSI

41/61/
Aplicaţii bazate pe protocoale TCP şi UDP

Socluri API
Această secţiune descrie o interfaţă de program aplicaţie (Application Program Interface - API)
pentru protocoale de comunicare cunoscută sub numele de socluri (sockets) sau programarea cu
socluri. API este o interfaţă disponibilă programatorului oferită iniţial în sistemele Unix, pentru lucrul cu
familia de protocoale TCP/IP. Ulterior, programarea cu socluri a fost oferită şi în alte sisteme de
operare, în forme compatibile cu cea de pe Unix. În principiu API asigură comunicarea cu nivelul
transport (TCP sau UDP) al familiei de protocoale, întrucât acest nivel este cel care pune la dispoziţie
comunicarea "capăt la capăt" necesară programării aplicaţiilor de reţea.

Orice API depinde atât de platforma pe care se bazează (aici sistemul de operare Unix), cât şi de
limbajul pentru care este destinată (aici limbajul C). Formal, o API consta dintr-o bibliotecă de funcţii
disponibile programatorilor.

Există o analogie evidentă între operaţiile cu perifericele într-un sistem de calcul şii comunicaţiile în
reţea ale acelui sistem. Apelurile sistem prevăzute pentru accesul la fişiere pot servi de exmplu pentru
comunicarea în reţea, dar pentru a ţine cont de particularităţile reţelelor, a fost imaginat un concept
nou, acela de soclu ("socket"). Ca şi fişierele, soclurile sunt reprezentate în sistem prin descriptori de
soclu (descriptori de fişier în cazul fişierelor), dar spre deosebire de fişiere un soclu există doar în
memorie.

Între particularităţile lucrului în reţea se amintesc următoarele:

 Relaţia client-server tipică aplicaţiilor de reţea este asimetrică, deci un program care
operează în reţea trebuie să cunoască ce rol joacă.

 comunicare în reţea poate fi cu conexiune sau fără conexiune, în primul caz asemănarea
cu fişierele este mai evidentă, dar pentru comunicarea fără conexiune nu există o analogie
cu "open", pentru că fiecare operaţie poate implica un alt proces, eventual pe un alt
calculator.

 Numărul de parametri care trebuie specificaţi pentru o conectare în reţea este mai mare
decât cel necesar la operaţiile cu fişiere: protocolul utilizat, adresa locală şi la distanţă,
procesul local şi cel de la distanţă.

 Cel puţin la unele protocoale sunt importante limitele între înregistrări, pe când
comunicarea cu fişierele este orientată pe un flux de octeţi.

Există de aceea câteva apeluri sistem noi, unele utilizate atât pentru comunicarea cu conexiune, cât şi
fără conexiune, iar altele specifice pentru fiecare din cele două moduri de coimmicare.

O schiţă a scenariului tipic pentru transferurile cu conexiune este prezentată în Figura 1. Se observă
că mai întâi este pornit serverul, iar clientul este lansat mai târziu, astfel încât sa existe siguranţa că
clientul poate găsi disponibile serviciile solicitate.

42/61/
 Figura 1: Schema de principiu a aplicaţiilor bazate pe protocoale cu conexiune (TCP).

Pentru un client-server care utilizează un protocol fără conexiune apelurile sistem sunt diferite. Figura
2 arată aceste apeluri sistem. Clientul nu stabileşte o conexiune cu serverul, în schimb clientul trimite
o datagramă către server utilizând apelul sistem endto() care pretinde adresa serverului ca şi
parametru. Datagrama conţinând şi adresa de reţea a procesului client, serverul va cunoaşte unde să
trimită răspunsul. Similar, serverul nu are o acceptare a conexiunii din partea clientului, în schimb
serverul recurge la apelul sistem recvfrom() care aşteaptă până când datele sosesc de la un client
oarecare.

43/61/
 Figura 2: Schema de principiu a aplicaţiilor bazate pe protocoale fără conexiune (UDP).

Fiecare soclu este definit printr-un întreg scurt numit descriptor de scoclu (socket descriptor). Apelul
funcţiei socket(), crează un soclu.

44/61/
Protocoalele din familia TCP/IP definesc o comunicare de tip punct final care constă dintr-o adresă de
IP şi număr de port.

Un soclu software oferă o structură de adresă generică numită sockaddr. Programele de aplicaţie
utilizează această structură atunci cînd este necesară memorarea de adrese pentru punctul final
(adresă de IP şi număr de port).

struct sockaddr { /* struct to hold an address */

u_short sa_family; /* AF_xxx family */
char sa_data[14]; /* upto 14 bytes of protocol specific address */
};

Pentru familia de protocoale Internet următoarele structuri sunt definite în <netinet/in.h>:

struct in_addr {
u_long s_addr; /* 32 bit address */
};

struct sockaddr_in {
short sin_family; /* AF_INET family */
u_short sin_port; /* 16 bit port number */
struct in_addr sin_addr; /* 32 bit host address */
char sin_zero[8]; /* unused */
};

Pentru a reprezenta o comunicare TCP/IP cu punct final, o aplicaţie utilizeză structura, , sockaddr_in.

Principalele apeluri sistem ce utilizează socluri

1) socket()

Apelul acestei funcţii crează un soclu nou pentru a fi utilizat în comunicare pe reţea. apelul returnează
un descriptor de soclu (sockfd).

#include <sys/types.h>
#include <sys/socket.h>

int socket( int family, int type, int protocol);

2) bind()

O aplicaţie apeleză bind() pentru a specifica o adresă locală de punct final pentru un soclu creat prin
apel socket().

#include <sys/types.h>
#include <sys/socket.h>

int bind( int sockfd, struct sockaddr *myaddr, int addrlen);

Adresa de punct final specifică atât o adresă de IP cât şi un număr de port. În primul rând serverele
utilizează bind() pentru a specifica un binecunoscut port la care sunt aşteaptate conectări.

45/61/
3) connect()

Un proces client orientat pe conexiune apelează connect() pentru a stabili o nexiune la un server.

#include <sys/types.h>
#include <sys/socket.h>

int connect( int sockfd, struct sockaddr *servaddr, int addrlen);

Structura sockaddr specifică o adresă de punct final la distanţă (de server), iar argumentul addrlen
specifică lungimea structurii de adresă.

4) listen()

Utilizată la servere orientate pe conexiune pentru a indica disponibilitatea de a accepta conexiuni.

Acest apel plasează soclul serverului intr-un mod pasiv şi îl face pregătit pentru a accepta conexiunile
care îi vin de la client.

#include <sys/types.h>
#include <sys/socket.h>

int listen( int sockfd, int backlog);

Acest apel este executat după socket() şi bind(), dar înainte de apelul accept(). Argumentul
backlog specifică numărul maxim de conexiuni cerute care pot fi introduse într-o coadă de aşteptare
de către sistem din momentul în care serverul execută deja un apel accept(). Valoarea uzuală a lui
backlog este de 5.

5) accept()

După ce un server orientat pe conexiune apelează socket(), bind() şi listen(), se face un apel
accept() pentru a extrage următoarea cerere de conexiune sosită.

#include <sys/types.h>
#include <sys/socket.h>

int accept(int sockfd, struct sockaddr *peer, int *addrlen);

accept() crează un nou soclu cu aceleaşi proprietăţi ca ale lui sockfd pentru fiecare noua conexiune
cerută şi returnează un descriptor de soclu. Argumentul peer returnează adresa punctului de
conexiune (ex. adresă client). Argumentul addrlen (returnat de apel) conţine lungimea acestei
adrese.

6) close()

#include <sys/types.h>
#include <sys/socket.h>

int close(int sockfd);

Acest apel eliberează un soclu.

7) read() and write()

46/61/
Serverul utilizează read() pentru a recepţiona o cerere (după ce o conexiune a fost stabilită),
cererea fiind emisă de client printr-un apel write(). Dupa emiterea cererii clientul utilizează un apel
read() pentru a recepţiona răspunsul.

n = read( int sockfd, char *buff, int nbyes);

Argumentul buff specifică adresa buferului în care s-au înscris datele recepţionate. Argumentul
nbytes specifică lungimea buferului.

n = write( int sockfd, char *buff, int nbytes);

Argumentul buff specifică adresa buferului din care se emit datele. Argumentul nbytes specifică
lungimea datelor ce vor fi emise.

8) htonl(), htons(), ntohl(), and ntohs()

Aceste patru rutine sunt rutine utilitare care convertesc reprezentarea binară a numerelor întregi din
ordinea nativă a hostului în ordinea standard de reţea.

#include <sys/types.h>
#include <sys/socket.h>

u_long htonl(u_long hostlong);

u_short htons(u_short hostshort);

u_long ntohl(u_long netlong);

u_short ntohs(u_short netshort);

Algoritmul utilizat în cazul unui server orientat pe conexiune

int sockfd, newsockfd();

if ((sockfd = socket(...)) < 0)

printf("socket error \n");
if (bind(sockfd, ...) < 0)
printf("bind error \n");
if (listen(sockfd, 5) < 0)
printf("listen error \n");

Server concurent orientat pe conexiune

for( ; ; ) {
newsockfd = accept(sockfd, ....); /* blocks */
if (newsockfd < 0)
printf("accept error \n");

if ((childpid = fork()) < 0)

printf("server: fork error \n");
else if (childpid == 0) { /* child */
close(sockfd);
doit(newsockfd);
exit(0);

47/61/
 }
close(newsockfd); /* parent */
}

Server iterativ orientat pe conexiune

for( ; ; ) {
newsockfd = accept(sockfd, ....); /* blocks */
if (newsockfd < 0)
printf("accept error \n");

doit(newsockfd);
close(newsockfd);
}

Exemple
Această secţiune conţine mai multe exemple care ilustrează lucrul socluri. Aceste exemple sunt:
 Funcţia readline()- citeşte N octeţi dintr-un descriptor de soclu

 Funcţia writen() - scrie N octeţi într-un descriptor de soclu

 Funcţia str_echo() – procesare de către un server TCP concurent a conexiunii cu un client

 Funcţia str_cli() – procesare de către un client a conexiunii cu un server TCP

 Funcţia dg_echo() – procesare de către un server UDP a cererilor client

 Funcţia dg_cli() – procesare de către un client răspunsurilor de la un server UDP

 Definitii pentru programe client / server TCP şi UDP

 Exemplu de programe client / server TCP cu conexiune

 Exemplu de programe client / server UDP fără conexiune

Funcţia readline()- citeşte N octeţi dintr-un descriptor de soclu

/* readline.c */
/*
Citeste "n" octeti pana la enter dintr-un descriptor de fisier/soclu. Se utilizeaza
in loc de read() atunci cad fd este un soclu - stream socket.

Returneaza numarul de octeti cititi.

*/
int
readline(fd, ptr, maxlen)
register int fd;
register char *ptr;
register int maxlen;
{
int n, rc;
char c;
for (n = 1; n < maxlen; n++)
{

48/61/
 if ((rc = read(fd, &c, 1)) == 1)
{
*ptr++ = c;
if (c == '\n') /* enter ?, terminator date */
break;
}
else if (rc == 0)
{
if (n == 1)
return(0); /* eof, nu sunt date */
else
break; /* eof, sunt ceva date */
}
else
return(-1); /* eroare */
}

*ptr = 0;
return(n);
}

Funcţia writen() - scrie N octeţi într-un descriptor de soclu

/*
Scrie "n" octeti intr-un descriprot de fisier/soclu. Se utilizeaza in loc de
write() atunci cad fd este un soclu stream socket.

Returneaza numarul de octeti scrisi.

*/

int writen(register int fd,

register char *ptr,
register int nbytes)
{
int nleft, nwritten;

nleft=nbytes;
while(nleft>0){
nwritten=write(fd,ptr,nleft);
if(nwritten<=0)
return(nwritten);
nleft -= nwritten;
ptr += nwritten;
}
return(nbytes-nleft);
}

Funcţia str_echo() – procesare de către un server TCP concurent a conexiunii cu un

client

/* str_echo.c */

/*
PING-PONG
Citeste (read) de la client printr-un stream socket (protocol TCP) cate

49/61/
 o linie pe care o retrimite (write) clientului.

Return numai cand conexiunea e terminata (fie lung. = 0 fie s-a

receptionat numai un enter)
*/

// #define MAXLINE 512 /* nr. max. baiti de citit */

int str_echo (int sockfd) {
int n;
char line [MAXLINE];
for (; ;)
{
/* PONG */
n = readline (sockfd, line, MAXLINE);
if (n == 0)
{ /* conexiune terminata */
return 0;
}
else
{
if (n < 0)
{
perror("str_echo: eroare la readline()");
return -1;
}
printf("%s (receptionat de la client): %s", pname, line); /*
afiseaza linie receptionata */
/* PING */
if (writen (sockfd, line, n) != n)
{
perror ("str_echo: eroare la writen()");
return -2;
}
/*
if (write (1, line, n) != n)
{
perror ("str_echo: eroare la write(1,...) de afisare");
return -3;
}
*/

}
}
}

Funcţia str_cli() – procesare de către un client a conexiunii cu un server TCP

/* str_cli.c */

/**
PING-PONG
Citeste continut dintr-un fisier FILE *fp si il scrie/trimite linie cu linie intr-
un soclu - stream socket - catre procesul server, apoi citeste un raspuns de la
server din soclu si il scrie in stdout (standard output).

Returneaza atunci cand un NULL sau cand linie vida este detectata in fisierul de
intrare.
*/

50/61/
// #define MAXLINE 512 /* nr. max. de baiti de citit */

void str_cli(register FILE *fp, register int sockfd)

{
int n;
char sendline[MAXLINE], recvline[MAXLINE+1];

/* se introduce linie cu linie pana la NULL sau linie vida=enter */

printf("\n%s ___prompt client: ", pname);
while ((fgets(sendline, MAXLINE, fp) != NULL) && (sendline[0] != '\n'))

{
n = strlen(sendline);
/* PING */
if (writen(sockfd, sendline, n) != n) // trimite spre server
perror("str_cli: eroare writen la soclu");

/* citeste din soclu (de la Server) si scrie in stdout */

/* PONG */
n = readline(sockfd, recvline, MAXLINE); // receptioneaza de la server
if (n < 0)
perror ("str_cli: eroare readline la soclu");

recvline[n] = 0; /* un terminator null */

/* afiseaza linie receptionata *

printf("%s (receptionat de la server): %s", pname, recvline);

/* afiseaza prompter client *

printf("\n%s ___prompt client: ", pname);
}
}

Funcţia dg_echo() – procesare de către un server UDP a cererilor client

/* dg_echo.c */
/*
PING-PONG
Citeste (Recvfrom) de la client printr-un datagram socket (protocol UDP) cate o
linie si o retrimite (Sendto) clientului.

Return numai cand conexiunea e terminata (fie lung.0 fie receptionat numai un
enter)
*/

// #define MAXLINE 512 /* nr. max. baiti de citit */

#define SA struct sockaddr

int
dg_echo(int sockfd, SA *pcliaddr, socklen_t clilen)
{
int n;
socklen_t len;
char mesg[MAXLINE];

51/61/
 for ( ; ; ) {
len = clilen;
/* PONG - recetioneaza de la client */
n = recvfrom(sockfd, mesg, MAXLINE, 0, pcliaddr, &len);
//printf("%s N= %ld\n", pname, n); /* afiseaza lungime linie receptionata */

if ((n == 0) || (mesg[0] == '\n'))

{ /* legatura client terminata */

/* afiseaza ultima linie receptionata */

printf("%s (EOF receptionat de la client)", pname);
return 0;
}

/* afiseaza linie receptionata */

printf("%s (receptionat de la client): %s", pname, mesg);
/* PING - trimite spre client */
sendto(sockfd, mesg, n, 0, pcliaddr, clilen);

}
}

Funcţia dg_cli() – procesare de către un client a răspunsurilor unui server UDP

/* dg_cli.c */

/**
PING-PONG
Citeste continut dintr-un fisier FILE *fp si il scrie/trimite linie cu linie intr-
un soclu datagrama catre procesul server, apoi citeste un raspuns de la server
din soclu si il scrie in stdout (standard output).

Returneaza atunci cand un NULL sau linie vida este detectata in fisierul de
intrare FILE *fp..
*/

// #define MAXLINE 512 /* nr. max. de baiti de citit */

#define SA struct sockaddr

void
dg_cli(FILE *fp, int sockfd, const SA *pservaddr, socklen_t servlen)
{
int n;

char sendline[MAXLINE], recvline[MAXLINE + 1];

/* se introduce linie cu linie pana la NULL sau linie vida=enter */
printf("\n%s ___prompt client: ", pname);
while ((fgets(sendline, MAXLINE, fp) != NULL) && (sendline[0] != '\n')) {
/* PING */

/* trimite spre server */

sendto(sockfd, sendline, strlen(sendline), 0, pservaddr, servlen);

/* PONG */
/* receptioneaza de la server */
n = recvfrom(sockfd, recvline, MAXLINE, 0, NULL, NULL);

52/61/
 recvline[n] = 0; /* un terminator null */
// fputs(recvline, stdout); /* afiseaza linia receptionata */
/* afiseaza linie receptionata */
printf("%s (receptionat de la server): %s", pname, recvline);

printf("\n%s ___prompt client: ", pname);

}
printf("\n%s ___EOF client ", pname);

/* trimite spre server un EOF (enter) */

sendto(sockfd, sendline, strlen(sendline), 0, pservaddr, servlen);

Definitii pentru programe client / server TCP şi UDP

Fişierul header inet.h de mai jos va fi utilizat atât pentru programul server cât şi pentru client în cazul
ambelor protocoale TCP şi UDP.

/* ------------------ inet.h -------------------------

* Definitii pentru TCP si UDP programe client / server
*/

#include <stdio.h>
#include <stdlib.h> // for exit() function
#include <unistd.h>
#include <signal.h>
#include <string.h>
#include <errno.h>
#include <sys/wait.h>

#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>

/* FEFINIRI DE PORTURI TCP SI UDP */

/* nu trebuie sa intre in conflict */
/* cu alte porturi TCP de servere */
#define SERV_UDP_PORT 6000
#define SERV_TCP_PORT 5500

/* adresa hostului local: 127.0.0.1 */

/* sau adresa altui host: 192.226.14.66 */
#define SERV_HOST_ADDR "127.0.0.1"

#define MAXLINE 512 /* nr. max. baiti de citit cu readline() */

char *pname;

/* ------------------ ------------------------- */

53/61/
Exemplu de programe client / server TCP cu conexiune

Aplicaţie simplă cu server concurent

Programele client/server TCP de mai jos urmăresc diagrama din Figura 2: Schema de principiu a
aplicaţiilor bazate pe protocoale cu conexiune.

Programele server/client explicitate mai jos realizează un ping-pong de mesaje între client şi server
după cum urmează:

1. clientul accepta un mesaj introdus de la tastatura.

2. mesajul introdus este transmis serverului.
3. serverul recepţionează mesajul.
4. serverul retransmite clientului mesajul şi îl afişează.
5. clientul receptionează mesajul de la server şi il afişează.
6. se execută pct.1

Codul programului server este dat mai jos:

/* CODUL PROGRAMULUI SERVER */

/*
* Examplu de server concurent cu conexiune care utilizeaza protocolul TCP.
*/

#include "inet.h" /* Header definitii pentru programele

client/server TCP si UDP */

#include "readline.c"
#include "writen.c"
#include "str_echo.c"

main(int argc, char *argv[])

{

int sockfd, newsockfd, clilen, childpid;

struct sockaddr_in cli_addr, serv_addr;

/* numele procesului luat de pe linia de comanda */

pname = argv[0];
/*
** Open pentru un socket TCP
(AF_INET: este din familia de protocoale Internet)
(SOCK_STREAM: este de tipul stream socket)
*/

if ( (sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0)

perror("EROARE server: nu pot sa deschid stream socket");

/*

54/61/
 ** Asignarea unei adrese locale si port protocol spre care clientul poate trimite
date.
*/
bzero((char *) &serv_addr, sizeof(serv_addr));
serv_addr.sin_family = AF_INET;
serv_addr.sin_addr.s_addr = htonl(INADDR_ANY);
serv_addr.sin_port = htons(SERV_TCP_PORT);
if (bind(sockfd, (struct sockaddr *) &serv_addr, sizeof(serv_addr)) < 0)
perror("EROARE server: nu pot sa asignez un nume adresei locala");

/*
** Server gata de conexiune pentru orice client
*/

printf("%s ++++ Server TCP astept conexiune clienti ++++\n\n", pname);

listen(sockfd, 5);

for ( ; ; ) /* server cu conexiune */

{
/*
* Bucla infinita.
* Asteptarea conexiunea cu un client.
* Acesta este un exemplu pentru un server concurent.
*/

clilen = sizeof(cli_addr);

/*
** Asteptare conexiune din partea unui client
*/

newsockfd = accept(sockfd, (struct sockaddr *) &cli_addr, &clilen);

if (newsockfd < 0)
perror("EROARE server: accept() esuat");

if ( (childpid = fork()) < 0)

perror("EROARE server: fork() esuat");

else if (childpid == 0) { /* proces copil */

close(sockfd); /* close socket original */
printf("\n%s ___client %ld conectat\n", pname, (pid_t)getpid());
str_echo(newsockfd); /* procesare cerere */
/* echo mesaje client server */
printf("\n%s ___client %ld deconectat\n", pname, (pid_t)getpid());

close(newsockfd); /* proces copil / close socket nou*/

exit(0);
}
close(newsockfd); /* proces parinte / close socket nou*/
}
}

55/61/
Testarea funcţionarii serverului TCP, poate fi făcută utilizând un client telnet ca în exemplu de mai
jos:

$ gcc –o tcp_server toc_server.c

$
$ ./tcp_server &
$ ./tcp_server ++++ Server TCP astept conexiune clienti ++++

$ telnet localhost 5500

Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.

./tcp_server ___client 14347 conectat

123456
./tcp_server (receptionat de la client): 123456
123456
asdfgh
$./tcp_server (receptionat de la client):
^]
telnet> close
Connection closed.

./tcp_server ___client 14347 deconectat

Codul programului client este dat mai jos:

/* CODUL PROGRAMULUI CLIENT */

/*
* Examplu de client care utilizeaza protocolul TCP.
*/

#include "inet.h"

#include "readline.c"
#include "writen.c"
#include "str_cli.c"

main(int argc, char *argv[])

{
int sockfd;
struct sockaddr_in serv_addr;

pname = argv[0];

/*
* Popularea structurii "serv_addr" cu date iclusiv cu adresa
* serverului la care se doreste conectarea clientului.
*/

bzero((char *) &serv_addr, sizeof(serv_addr));

serv_addr.sin_family = AF_INET;
serv_addr.sin_addr.s_addr = inet_addr(SERV_HOST_ADDR);

56/61/
 serv_addr.sin_port = htons(SERV_TCP_PORT);

/*
* Open pentru un soclu TCP
(AF_INET: este din familia de protocoale Internet)
(SOCK_STREAM: este de tipul stream socket)
*/

if ((sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0)

perror("EROARE client: nu pot sa deschid soclul");

/*
* Conectare la server.
*/

if (connect(sockfd, (struct sockaddr *) &serv_addr, sizeof(serv_addr)) < 0)

perror("EROARE client: nu ma pot conecta la server");
printf("\n%s ___CLIENT CONECTAT la serverul TCP\n", pname);

str_cli(stdin, sockfd); /* proceseaza cereri/raspunsuri */

printf("\n%s ___CLIENT DECONECTAT\n", pname);
close(sockfd); /* close soclu */
exit(0);
}

Testarea funcţionarii tandemului server/clientului TCP, se poate face în felul următor:

$ gcc -o tcp_server tcp_server.c

$ gcc -o tcp_client tcp_client.c

$ ./tcp_server &
[1] 16893
$ ./tcp_server ++++ Server TCP astept conexiune clienti ++++

$ ./tcp_client

./tcp_client ___CLIENT CONECTAT la serverul TCP

./tcp_server ___client 31535 conectat

./tcp_client ___prompt client: 123456

./tcp_server (receptionat de la client): 123456
./tcp_client (receptionat de la server): 123456

./tcp_client ___prompt client: qwerty

./tcp_server (receptionat de la client): qwerty
./tcp_client (receptionat de la server): qwerty

./tcp_client ___prompt client:

./tcp_client ___CLIENT DECONECTAT

./tcp_server ___client 31535 deconectat

$ ps
PID TTY TIME CMD

57/61/
 17923 pts/1 00:00:00 bash
16893 pts/1 00:00:00 tcp_server
31535 pts/1 00:00:00 tcp_server <defunct>
9788 pts/1 00:00:00 ps

$ kill -9 16893
[1]+ Killed ./tcp_server

$ ps
PID TTY TIME CMD
17923 pts/1 00:00:00 bash
19291 pts/1 00:00:00 ps
$

Exemplu programe client / server UDP fără conexiune

Aplicaţie simplă cu server iterativ

Programele client/server UDP de mai jos urmăresc diagrama din Figura 3: Schema de principiu a
aplicaţiilor bazate pe protocoale fără conexiune.

Codul programului server este dat mai jos:

/* CODUL PROGRAMULUI SERVER */

/*
* Examplu de server fara conexiune care utilizeaza protocolul UDP.
*/

#include "inet.h" /* Header definitii pentru programele

client/server TCP si UDP */

#include "dg_echo.c"

main(argc, argv)
int argc;
char *argv[];
{
int sockfd;
struct sockaddr_in serv_addr, cli_addr;

pname = argv[0];

/*
* Open un soclu UDP (un soclu datagrama Internet).
*/

if ( (sockfd = socket(AF_INET, SOCK_DGRAM, 0)) < 0)

perror("server: nu pot sa deschid soclul datagrama");

/*
* Bind - asigneaza adresa locala la care clientul poate sa trimita date.
*/

bzero((char *) &serv_addr, sizeof(serv_addr));

serv_addr.sin_family = AF_INET;
serv_addr.sin_addr.s_addr = htonl(INADDR_ANY);

58/61/
 serv_addr.sin_port = htons(SERV_UDP_PORT);

if (bind(sockfd, (struct sockaddr *) &serv_addr, sizeof(serv_addr)) < 0)

perror("server: nu pot sa asignez adresa locala");
/*
** Server UDP asteapta cereri client
*/

printf("%s ++++ Server UDP astept cereri client ++++\n\n", pname);

/* cereri client - raspuns server */
dg_echo(sockfd, (struct sockaddr *) &cli_addr, sizeof(cli_addr));
/* nu se mai trateaza altceva */
printf("\n%s ___client TERMINAT\n", pname);
printf("\n%s ___sever TERMINAT\n", pname);

close (sockfd);
exit(0);
}

Codul programului client este dat mai jos:

/*
* Exemplu de client care utilizeaza protocolul UDP.
*/

#include "inet.h"

#include "dg_cli.c"

main(argc, argv)
int argc;
char *argv[];
{
int sockfd;
struct sockaddr_in cli_addr, serv_addr;

pname = argv[0];

/*
* Popularea structurii "serv_addr" cu date, iclusiv cu adresa
* serverului, spre care se doreste trimiterea de date.
*/

bzero((char *) &serv_addr, sizeof(serv_addr));

serv_addr.sin_family = AF_INET;
serv_addr.sin_addr.s_addr = inet_addr(SERV_HOST_ADDR);
serv_addr.sin_port = htons(SERV_UDP_PORT);

/*
* Open soclu UDP (un soclu Internet datagrama).
*/

if ( (sockfd = socket(AF_INET, SOCK_DGRAM, 0)) < 0)

perror("client: nu pot sa deschid soclul datagrama");

/*
* Bind - asigneaza orice adresa locala pentru utilizare.

59/61/
 */

bzero((char *) &cli_addr, sizeof(cli_addr)); /* zero out */

cli_addr.sin_family = AF_INET;
cli_addr.sin_addr.s_addr = htonl(INADDR_ANY);
cli_addr.sin_port = htons(0);
if (bind(sockfd, (struct sockaddr *) &cli_addr, sizeof(cli_addr)) < 0)
perror("client: nu pot sa asignez o adresa locala");

/* emitere - receptie mesaje */

dg_cli(stdin, sockfd, (struct sockaddr *) &serv_addr, sizeof(serv_addr));

close(sockfd);
printf("\n%s ___CLIENT TERMINAT\n", pname);

exit(0);
}

Testarea funcţionarii tandemului server/clientului UDP, se poate face în felul următor:

$ gcc -o udp_server udp_server.c

$ gcc -o udp_client udp_client.c

$ ./udp_server &
[1] 18171
$ ./udp_server ++++ Server UDP astept cereri client ++++

$ ps
PID TTY TIME CMD
17923 pts/1 00:00:00 bash
18171 pts/1 00:00:00 udp_server
28027 pts/1 00:00:00 ps

$ ./udp_client

./udp_client ___prompt client: 1234567

./udp_server (receptionat de la client): 1234567

./udp_client (receptionat de la server): 1234567

./udp_client ___prompt client: 123456

./udp_server (receptionat de la client): 123456

./udp_client (receptionat de la server): 123456

./udp_client ___prompt client:

./udp_client ___EOF client

./udp_server (EOF receptionat de la client)
./udp_client ___CLIENT TERMINAT
./udp_server ___client TERMINAT

./udp_server ___sever TERMINAT

[1]+ Done ./udp_server

$ ps
PID TTY TIME CMD

60/61/
 17923 pts/1 00:00:00 bash
10813 pts/1 00:00:00 ps
$

61/61/