Prof. Dr. Ing. Valentin Sgâ rciu i Cuprins Cuprins ………………………….. ………………………….. …………………………….. [602011]

1

Universitatea Politehnica București
Facultatea de Automatică și Calculatoare
Departamentul de Automatică și Informatică Aplicată

LUCRARE DE LICENȚĂ

Aplicație pentru subnetizare

Absolvent: [anonimizat]
1 Introducere ………………………….. ………………………….. ………………………….. ………………………….. …………. 1
1.1 Obiectivele lucrării ………………………….. ………………………….. ………………………….. ……………………. 1
1.2 Motivație ………………………….. ………………………….. ………………………….. ………………………….. ……… 1
1.3 Prezentarea capitolelor ………………………….. ………………………….. ………………………….. ………………. 3
2 Descrierea domeniului. Rețele de calculatoare ………………………….. ………………………….. …………………. 5
2.1 Noțiuni introductive ………………………….. ………………………….. ………………………….. …………………… 5
2.2 Modelul OSI. Stiva de protocoale TCP/IP ………………………….. ………………………….. ………………. 10
2.3 Rutare statică. Rutare dinamică ………………………….. ………………………….. ………………………….. ….15
2.4 Switching ………………………….. ………………………….. ………………………….. ………………………….. ……18
2.5 IPv4. IPv6 ………………………….. ………………………….. ………………………….. ………………………….. …..19
2.6 Subnetizare ………………………….. ………………………….. ………………………….. ………………………….. …22
3 Cerințele sistemului ………………………….. ………………………….. ………………………….. ……………………….. 24
3.1 Surse de informare ………………………….. ………………………….. ………………………….. …………………… 24
3.2 Actorii sistemului ………………………….. ………………………….. ………………………….. ……………………. 25
3.3 Cerințe funcționale ………………………….. ………………………….. ………………………….. ………………….. 25
3.4 Cerințe nefuncționale ………………………….. ………………………….. ………………………….. ……………….. 26
4 Proiectarea aplicației. M odelare UML ………………………….. ………………………….. ………………………….. 27
4.1 Diagramele de clase ………………………….. ………………………….. ………………………….. …………………. 27
4.2 Diagrama cazurilor de utilizare ………………………….. ………………………….. ………………………….. ….31
4.3 Diagrama de activități ………………………….. ………………………….. ………………………….. ………………. 32
5 Tehnologii folosite ………………………….. ………………………….. ………………………….. …………………………. 33
5.1 Java ………………………….. ………………………….. ………………………….. ………………………….. …………… 33
5.2 JavaFX ………………………….. ………………………….. ………………………….. ………………………….. ………. 35
5.3 C#. Framework -ul .NET ………………………….. ………………………….. ………………………….. …………… 36
5.4 Servicii Web ………………………….. ………………………….. ………………………….. ………………………….. .37

ii 5.5 Arhitectura Model -View -Controller ………………………….. ………………………….. ……………………….. 37
6 Implementarea sistemului ………………………….. ………………………….. ………………………….. ……………….. 39
6.1 Aplicația de tip Desktop ………………………….. ………………………….. ………………………….. …………… 39
6.2 Serviciul Web ………………………….. ………………………….. ………………………….. …………………………. 43
7 Rezultate ………………………….. ………………………….. ………………………….. ………………………….. ………….. 46
8 Concluzii ………………………….. ………………………….. ………………………….. ………………………….. ………….. 49
9 Bibliografie ………………………….. ………………………….. ………………………….. ………………………….. ………. 51

iii Listă de figuri
Figură 2.1 Exemple de end device -uri ………………………….. ………………………….. ………………………… 6
Figură 2.2 Exemple de echipamente intermediare ………………………….. ………………………….. ……….. 6
Figură 2.3 Exemple de rețele de tip LAN și WLAN (4) ………………………….. ………………………….. .. 8
Figură 2.4 Rețea de tip peer -to-peer (6) ………………………….. ………………………….. ……………………… 9
Figură 2.5 Rețea de tip client/server (8) ………………………….. ………………………….. ……………………. 10
Figură 2.6 Modelul OSI ………………………….. ………………………….. ………………………….. ……………… 11
Figură 2.7 Substraturile Nivelului Legături de date (9) ………………………….. ………………………….. . 13
Figură 2.8 Modelul OSI vs. Stiva de protocoale TCP/IP (10) ………………………….. ………………….. 14
Figură 2.9 Clasificarea protocoalelor de rutare (11) ………………………….. ………………………….. …… 17
Figură 2.10 Clasificare protocoale de rutare (12) ………………………….. ………………………….. ……….. 17
Figură 2.11 Header -ul de IPv4 (14) ………………………….. ………………………….. ………………………….. 20
Figură 2.12 Headerul de IPv6 (15) ………………………….. ………………………….. ………………………….. . 22
Figură 2.13 Subnetizare cu mască fixă (16) ………………………….. ………………………….. ………………. 23
Figură 2.14 Subnetizare cu mască variabilă (16) ………………………….. ………………………….. ……….. 23
Figură 4.1 Diagrama de activități [partea 1] ………………………….. ………………………….. ………………. 27
Figură 4.2 Diagrama de activități [partea a 2 -a] ………………………….. ………………………….. …………. 28
Figură 4.3 Diagrama de activități [partea a 3 -a] ………………………….. ………………………….. …………. 29
Figur ă 4.4 Diagrama de clase serviciu web ………………………….. ………………………….. ……………….. 30
Figură 4.5 Diagrama cazurilor de utilizare ………………………….. ………………………….. ………………… 31
Figură 4.6 Diagrama de activități ………………………….. ………………………….. ………………………….. … 32
Figură 5.1 Procesul de dezvoltare a unui program Java (18) ………………………….. ……………………. 33
Figură 5.2 Independeța de platformă a limbajului Java (18) ………………………….. …………………….. 34
Figură 5.3 Mediul de programare IntelliJ IDEA ………………………….. ………………………….. ………… 35
Figură 5.4 Logo JavaFX (20) ………………………….. ………………………….. ………………………….. ……… 35
Figură 5.5 Siglă .NET 4.5.1 (23) ………………………….. ………………………….. ………………………….. …. 36
Figură 5.6 Componente de bază ale unui serviciu web (25) ………………………….. …………………….. 37
Figură 5.7 Arhitectura MVC (27) ………………………….. ………………………….. ………………………….. … 38
Figură 6.1 Structura principală a fișierului sample.fxml ………………………….. ………………………….. 40
Figură 7.1 Fereastra principală a aplicației ………………………….. ………………………….. ……………….. 46
Figură 7.2 Câmpurile cu date de intrare ………………………….. ………………………….. ……………………. 46

iv Figură 7.3 Ex emplu de date valide de intrare ………………………….. ………………………….. …………….. 47
Figură 7.4 Exemplu de date cu trei subrețele cerute ………………………….. ………………………….. …… 47
Figură 7.5 Răspunsul serviciului web în format JSON ………………………….. ………………………….. .. 48
Figură 7.6 Rețelele subnetizate afișate în interfața grafică ………………………….. ………………………. 48

1
1 Introducere

1.1 Obiectivele lucrării
Obiectiv general
Facilitarea realizării procesului de subnetiz are a rețelelor de calculato are prin implementarea
unei aplicații software care să fie disponibilă până în iulie 2015 .
Obiective specifice
1. Dezvoltarea aplicației astfel încât să fie disponibilă atât pentru protocolul IPv4, cât
și pentru IPv6.

2. Realizarea aplicației având în vedere po sibilitatea alegerii unui număr variabil de
subrețele dorite, cât și unui număr variabil de hosturi pentru fiecare subrețea.

3. Implementarea sistemului astfel încât să ofere posibilitatea stocării rezultatelor în
format PDF și facilitarea consultării ulteri oare a acestora.

4. Adăugarea de noi funcționalități pentru realizarea unui sistem complex de calcul și
management al rețelelor de calculatoare, în 2 ani de la momentul finalizării
sistemului de bază “Aplica ție pentru subnetizare ”.

1.2 Motivație

Adresarea log ică este una din noțiunile de bază din domeniul rețelelor de calculatoare, fiind
printre primele informații cu care iau contact cei ce doresc să învețe rețelistică. Inițial, subnetizarea
se realizează pe hartie, în scopul familiarizării studentului cu aces t procedeu și al aprofundării lui.
Ulterior, în practică, există două mari dezavantaje al acestui demers: în primul rând, timpul de
calcul este foarte mare și ar putea fi redus considerabil prin folosirea unui calculator specializat
pentru subnetizare ; în al doilea rând, deși exi stă pregătire teoretică și practică în domeniu, pot

Florentina Băcioiu Intoducere
2 interveni greșeli umane datorate oboselii sau neatenției celui care realizează subnetizarea rețelelor.
Pornind de la aceste aspecte, lucrearea curentă are în vedere realizarea unui instrument foarte util
în adresarea logică a rețelelor.
Mai mult decât atât, sistemul “Aplica ție pentru subnetizare ” este o aplicație customizată,
gândită pentru nevoile unui administrator/inginer de rețele. Aceasta vine în completarea
neajunsurilor apli cațiilor deja existente pe piață, care, spre exemplu, efectuează subnetizarea pentru
o singura subretea, lucru ineficient pentru cazul în care administratorul unei rețele ale unei
organizații mai mari dorește să efectueze subnetizarea pentru întreaga rețea . De asemenea, mai
există aplicații disponibile online, care oferă posibilitatea subnetizării mai multor subrețele, însă
numărul de hosturi pentru fiecare subnet nu are dimensiune variabilă. Acest lucru este, iarăși,
ineficient, întrucât este în dezacord c u obiectivele subnetizării de a oferi suficiente hosturi într -o
subrețea pentru a fi asignate tuturor dispozitivelor și de a face, în același timp, economie de ip -uri.

Aplicația din lucrarea curentă are în vedere faptul că este, încă, o perioadă de tranzi ție de la
IPv4 la IPv6, în care anumite organizații folosesc dual stack -ul sau au trecut complet la funcționarea
pe IPv6, în timp ce altele folosesc exclusiv IPv4 datorită limitărilor hardware ale dispozitivelor de
rețea. Așadar, aplicația oferă posibilita tea subnetizării folosind IPv4, dar și folosind IPv6. Gândind
în perspectivă, sistemul nu va trebui schimbată în cazul în care se va decide trecerea definitivă la
IPv6 , ci se va folosi exclusiv modulul destinat subnetizării în IPv6.
“Aplica ție pentru subn etizare ” se dorește a fi un prim pas în realizarea unei aplicații complexe
folosită în calcule specific rețelelor, dar și în facilitarea managementului acestuia. Subnetizarea este
un proces care nu se efectuează periodic din momentul în care configurația u nei rețele este stabilă .
Acesta se realizează la început, în momentul proiectării rețelei , iar pe parcurs, se realizează în
condițiile în care cresc nevoile organizației, iar hosturile disponibile nu mai sunt suficiente pentru
a fi asignate dispozitivelor noi adăugate. Așadar, sistemul descris în această lucrare are în vedere
posibilitatea stocării configurației logice calculate la un moment dat. Pe viitor, aceste date vor putea
fi consultate, fiind utile in cazul în care există probleme în rețea care neces ită cunoașterea
configurației logice. De asemenea, în cazul schimbării administratorului de rețea, noul responsabil
va putea cunoaște mai ușor configurația curentă și mai ales, istoricul acesteia, cu ajutorul
“Aplica ției pentru subnetizare ”.

Florentina Băcioiu Intoducere
3 Nu în ultimul rând, lucrarea are în vedere folosirea tehnologiilor de ultimă ora , alese astfel
încât obiectivele propuse să fie îndeplinite cât mai ușor . De asemenea, accentual se pune pe
separarea logicii aplicației de interfața folosită de utilizator și pe folosirea s erviciilor web.
1.3 Prezentarea capitol elor

În capitolul 1 au fost prezentate obiectivele lucrării și motivația realizării “Aplica ției pentru
subnetizare ”. Acestea constituie punctual de plecare în documentarea cerințelor și proiectarea
sistemului, astfel înc ât aplicația să ducă la îndeplinirea obiectivelor într -o proporție cât mai mare.
Capitolul 2 cuprinde descrierea domeniului aplicației. Acesta prezintă noțiuni fundamentale
de rețele de calculatoare , printre care modelul OSI, stiva de protocoale TCP/IP, el emente de rutare
static și dinamică, dar și protocoalele IPv4 și IPv6 și procesul de subnetizare.
Cerințele sistemului, atât cele funcționale cât și cele nefuncționale, sunt prezentate în
capitolul 3. De asemenea, sunt descrise sursele de informare care au influențat stabilirea cerințelor,
precum și multitudinea actorilor sistemului care interacționează cu aplicația.
Capitolul 4, numit “ Proiectarea aplicației. Modelare UML ”, cuprinde diagramele de clas ă,
diagrama cazurilor de utilizare și diagrama de activi tăți a aplicației. În această secțiune este
prezentată proiectarea și modelarea UML a sistemului dorit, astfel încât acesta să fie compatibil cu
cerințele stabilite în capitolul anterior.
În continuare, capitolul 4 este dedicat tehnologiilor alese pentru r ealizarea sistemului. Sunt
prezentate noțiuni fundamentale despre limbajul Java, JavaFX, limbajul C# și frameworkul .NET.
De asemenea, se descrie principiul de funcționare al serviciilor web, dar și arhitectura MVC.
În capitolul 5 este descrisă implementa rea propriu -zisă a aplicației. Este prezentat modul în
care au fost realizate funcționalitățile sistemului și sunt explicate porțiuni din cod folosite pentru
implementarea aplicației.
Capitolul 6, “Testarea aplica ției”, prezintă testele unitare folosite pe ntru identificarea
funcționării corecte a sistemului, cât și rezultatele acestora.

Florentina Băcioiu Intoducere
4 În capitolul 8 sunt prezentate rezultatele lucrării și concluziile bazate pe acestea. Este
dezbătut procentul de îndeplinire a obiectivelor propuse și modul în care au fost realizate. De
asemenea, sunt prezentate dezvoltările viitoare vizate, fiind luate în calcul atât îmbunătățirea
funcționalităților deja existente, cât și implementarea de noi module și integrarea lor în sistem.
Ultimul capitol este dedicat bibliografiei și cuprinde lista cărților, a site -urilor web, a
cursurilor și a lucrărilor de specialitate folosite ca referință în realizarea lucrării.

5
2 Descrierea domeniului . Rețele de calculatoare

2.1 Noțiuni introductive
Definiții
“Rețeaua de calculatoare reprezintă un ansamblu de calculatoare interconectate prin intermediul
unor medii de comunica ție, asigurându -se astfel schimbul de date și informații prin utilizarea în
comun a resurselor fizice, logice și informaționale de care dispune ansamblul de calculatoare
conectate. ” (1)
Internet. Este o rețea globală de rețele, publică, nesecurizată, conectată prin stiva de protocoale
TCP/IP.
Domeniu de coliziune . “Domeniul de coli ziune este acea zona dintr -o rețea care va fi afectată
de apariția unei coliziuni î n interiorul ei. Dispozit ivele din categoria hub -urilor și repetoarelor
propagă coliziunea. Creșterea numă rului de coliziuni este cauzată de intensificarea transmisiilor
mai ales datorită unui numar crescând de stații în același do meniu de coliziune și duce la degradarea
abruptă a performanțelor rețelei. Rețeaua locală poate fi împărțită î n domenii de coliziune separate
prin intermediul unor dispoziti ve din categoria bridge -urilor ș i switch -urilor .” (2)
Domeniu de broadcas t. “Domeniul de br oadcast este constituit din sta țiile care vor auzi un
mesaj de tip broadcast trimis de unul dintre ele. Creșterea numă rului broadcast -urilor duce la
scaderea performanțelor reț elei. Singurele dispozitive care pot separ a domeniile de broadcast sunt
routerele. ” (2)
Default gateway (DG) . Este ip -ul interfeței routerului dintr -o rețea locala, care asigură ieșirea
din rețeaua privată și accesul la Internet sau la alte re țele.
Coenxiunile in rete listică sunt de tip fizic, prin intermediul cablurilor, plăcilor de rețea (NIC –
uri – Network Interface Card) și echipamentelor intermediare – router, switch, hub, bridge, repetor,
dar și de tip logic, prin intermediul IP -urilor. Acestea din urmă dau unicit ate device -urilor și pot fi
private sau publice.
Componentele rețelei

Florentina Băcioiu Descrierea domeniului. Rețele de calculatoare
6 O rețea este formată din a)dispozitive – end device -uri: PC, laptop, server, im primantă de rețea,
telefon VoIp, și echipamente intermediare: repetor, hub, bridge, switch, router, b)me dii de transfer :
cupru – ce se întalnește la cablurile coaxial și UTP, sticla – conținută de fibra optică, aer – prin
tehnologiile wireless și radio , c)servicii : web (HTTP), mail (POP, SMTP), transfer de fi șiere (FTP,
SAMBA), acces remote (Telnet, SSH), aloca re de ip -uri (DHCP), mapare ip -nume (DNS).
End device -urile reprezintă sursa și destinația traficului din rețea. Acestea vor fi configurate cu
un ip privat unic în rețeaua din care fac parte, network mask -ul corespunzător adresei de rețea, cu
default gate way-ul necesar ieșirii din rețea și cu un ip de DNS. Ele mai sunt denumite host -uri sau
stații de lucru .

Figură 2.1 Exemple de end device -uri
Echipamentele intermediare, numite și device -uri, au rolul de a face conectivitatea în rețea. Ele
sunt dotate cu o placă de rețea (NIC), porturi de intrare -ieșire, în cazul repetorelor de semnal, hub –
urilor, bridge -urilor, switch -urilor, și cu interfețe în cazu l routerelor.

Figură 2.2 Exemple de echipamente intermediare
Mediile de transfer sunt alese în funcție de aria de acoperire, serviciile oferite și costuri. De
asemenea, se ia u în considerare dimensiunea rețelei și lărgimea de bandă necesară.
Dispozitive intermed iare de rețea

Florentina Băcioiu Descrierea domeniului. Rețele de calculatoare
7 Repetorul. Este un dispozitiv de rețea de nivel fizic, cu doua porturi, care recepționează un
semnal mic, îl amplifică și îl transmite pe portul de ieșire în rețea.
Hub-ul. Reprezintă un multiport repetor. La fel ca repetorul, acesta preia un semnal pe portul
de intrare, îl amplifică și îl trimite mai departe pe toate porturile în afară de cel pe care l -a primit.
Hub-ul funcționează half -duplex și are un singur domeniu de coliziune și un singur domeniu de
broadcast . Este foarte întâlnit în r ețelele de tip bus, conectate prin mediul Ethernet, în care toate
stațiile concurează pe aceeași conexiune.
Bridge -ul. Este un dispozitiv care leagă 2 hub -uri și are proprietantea de a opri un mesaj. Acesta
are o funcție de învățare, care ii permite rețin erea MAC -urilor. Cu toate acestea, are 2 greșeli de
proiectare : are numai 2 porturi și este o soluție software, având o memorie și un procesor
insuficiente din punct de vedere al resurselor. Bridge -ul are 2 domenii de coliziune.
Switch -ul. Reprezintă un m ultiport bridge. El funcționează în modul full -duplex, transmițând
și primind în același timp informație. Aceasta nu necesită procesare, iar dispozitivul face toate
funcțiile în hardware. Pe fiecare port exită 2 memorii, una de intrare și una de ieșire, separând
domeniile de coliziune. Numărul domeniilor de coliziune este dat de numărul porturilor pe care
switch -ul le deține și există un singur domeniu de broadcast . De asemenea, CSMA/CD este
dezactivat.
Router -ul. Interconectează rețele, separând domeniile de broadcast. De asemenea, numărul
domeniilor de coliziune este dat de numărul interfețelor de care dispune. Routerul are 4 funcții, el
realizând comutarea pachetelor, filtrarea pachetelor, comunicarea între rețele și alegerea path -ului
potrivit pentru a trimite pachete. (3)
Tipuri de rețele
În funcț ie de numărul de utilizatori, de aria geografică și de numărul și tipul serviciilor
disponibile , rețelele pot fi de tip LAN – Local Area Network, MAN – Metropolitan Area Network,
WAN – Wide Area Network sau PAN – Personal Area Network.
LAN – Local Area Network este o infrastructură de rețea care asigură accesul utilizatorilor și
dispozitivelor de rețea într -o zonă geografică restrânsă . LAN -ul interconectează dispozitive de rețea
într-o zonă limitată precum acasă, la școală, într -o clădire de birouri sau un campus. Aceasta este

Florentina Băcioiu Descrierea domeniului. Rețele de calculatoare
8 administrate, de obicei, de un singur administrator sau organizație și are propriile politici de acces
și securitate.

Figură 2.3 Exemple de rețele de tip LAN și WLAN (4)
WAN – Wide Area Network reprezintă o infrastructură de rețea care facilitează accesul la alte
rețele răspândite pe o arie geografică exinsă. Aceasta interconectează LAN -uri aflate în orașe, țări
sau continente diferite, iar de administrarea sa se ocupa mai mulți service provideri (SP) sau in ternet
service provideri (ISP). Acest tip de rețea asigură legături la viteze relative m ici între LAN -uri.
MAN – Metropolitan Area Network este un tip de re țea situat între LAN și WAN din punct de
vedere al extinderii geografice și al dimensiunii . Acesta poate reprezenta rețeaua unui oraș, spre
exemplu, și este administrat de o singură entitate precum o organizație de mari dimens iuni.
PAN – Personal Area Network este un tip de rețea care se stabilește pe o suprafață restrânsă,
între două dispozitive mobile/laptop -uri.
WLAN – Wireless LAN este o rețea asemănătoare LAN -ului, însă aceasta interconectează
utilizatorii și dispozitive le de rețea prin intermediul tehnologiei wireless . (5)

Florentina Băcioiu Descrierea domeniului. Rețele de calculatoare
9 Din punct de vedere al rela țiilor de rețea, există doua tipuri fundamentale: peer -to-peer și
client/server. Ele definesc structura rețelei și modul în care se face accesu l la resurse. Într-o rețea
de tip peer -to-peer, calculatoarele comunică între ele ca părți egale și fiecare pune la dispoziție
propriile resurse altor calculatoare din rețea. De asemenea, accesul la resurse este descentralizat,
iar fiecare calculator este responsabil de configurarea si asigurarea securității proprii. Avantajele
rețelelor peer -to-peer sunt utilizarea unor componente hardware mai puțin costisitoare,
administrarea facilă a acestora, redundanța încorporată mare, dar și faptul ca nu este necesar un
sistem de operare în rețea. Cu toate acestea, exită și dezavantaje ale acestor tipuri de rețele, printre
care se număra afectarea performanțelor utilizatorului, un nivel scazul al securității, dificultatea
realizării copiilor de siguranță și dificultat ea de păstrare a unui control al versiunilor.

Figură 2.4 Rețea de tip peer -to-peer (6)
Spre deosebire de rețeaua de tip peer -to-peer, în rețeaua de tip client/server există ca lculatoare
care pun la dispoziție resursele rețelei (servere) și calculatoare care utilizează aceste resurse
(clienți/stații de lucru). Așadar, accesul la informație este centralizat și niciun calculator client nu
își partajează resursele cu alte calculato are client sau cu serverele. Avantajele rețelelor client/server
sunt reprezentate de un nivel înalt de securitate, performanțe bune din punct de vedere al
utilizatorilor, copii de siguranță centralizate și de fiabilitatea lor. Printre dezavantaje, se număr ă
necesitatea unei administrări profesioniste și consumul ridicat de resurse hardware. (7)

Florentina Băcioiu Descrierea domeniului. Rețele de calculatoare
10
Figură 2.5 Rețea de tip client/server (8)

2.2 Modelul OS I. Stiva de protocoale TCP/IP

Modelul OSI ( Open Systems Interconnection ) este un standard pentru comunicația în rețea al
Organizației Internaționale de Standardizare (ISO), apărut în 1984. Acesta este un model ierarhic,
fiind divizat în 7 straturi, numit e și layere. Fiecare strat are rolul s ău în realizarea transmisiei de
date, având protocoale si funcționalități specific e. De asemenea, u n aspect important îl reprezintă
încapsularea specifică fiecărui layer în parte, fiind cunoscut sub numele de PDU (Prot ocol Data
Unit).
Nivelurile modelului OSI sunt: 7.Aplica ție, 6.Prezentare, 5.Sesiune, 4.Transport, 3.Rețea,
2.Legături de date, 1.Fizic. Aceasta este ordinea de la nivel superior spre nivelul inferior al
standardului și fiecare layer este dependent de la yerul superior pentru ca fiecare adaugă informații
specifice peste informațiile nivelului de la care a primit datele. Acest proce s poartă numele de
încapsulare.

Florentina Băcioiu Descrierea domeniului. Rețele de calculatoare
11
Figură 2.6 Modelul OSI
Nivelul Aplicație . Reprezintă interfața cu utilizatorul (GUI – Graphical User Interface) și
mijloceste accesul cu stiva de protocoale. La acest nivel există doua ipostaze : pe de -o parte avem
clientul, care face o interogare la server, iar de cealaltă parte avem serverul, care pr imește requestul
clientului și răspunde cu informațiile cerute, dacă acestea sunt disponibile. Serverul este un host pe
care rulează o aplicație de tip server, dar platformă hardware specifică. În spatele sistemului de
operare rulează un process care ascul ă interogările clientului. Aplicațiile pot fi: pentru clien ți –
acele programe software care pornesc procese rulate la accesarea rețelei, și server – cele care
“ascult ă” rețeaua 24/24.
Protocoalele specifice layerului 7 (Aplicație) sunt: Hypertext Transfer Protocol ( HTTP ),
Domain Name System (DNS) , SAMBA (SMB), Simple Mail Transfer Protocol ( SMTP ), Post
Office Protocol ( POP), File Transfer Protocol (FTP) , Trivial File Transfer Protocol (TFTP) , Telnet,
SSH, SMB, Dynamic Host Configuration Protocol (DHCP ), Active Directory , Internet Message
Access Protocol (IMAP) .
Nivelul Prezentare . Se ocupă cu punerea întrun limbaj comun cerut de protocolul folosit.
La acest nivel se realizează compresia datelor și se poate face criptare/decriptare. De asemenea,
aici se setează HTTP Secure (HTTPS). Layerul Prezentare formatează datele pentru nivelul
Aplicație și stabilește standarde pentru formate de fișiere. Exemple de standard video sunt
QuickTime și MPEG , iar dintre standardele pentru imagine amintim JPEG, GIF și PNG.

Florentina Băcioiu Descrierea domeniului. Rețele de calculatoare
12 Nivelul Sesiune . Deschide sesiuni de comunicare, le menține, reia sesiunile din i dle și le
închide. De asemenea, formează șirul de date pentru transfer și asigură comunicarea cu layerele
inferioare.
Nivelul Transport . La acest nivel se produce segmentarea fluxului de date pentru transfer,
se identific ă aplicațiile care vor sa comunice în rețea prin adresarea de port. Tot aici se face
managementul serviciilor și a aplicațiilor individuale. Nivelul Transport face flow -control și
stabilește lățimea canalului de comunicație, dar și dimensiunea segmentului. Acesta discută cu
layerele inferio are și asigură existența unei conexiuni înaintea trimiterii efective de date.
La nivelul layerului Transport există doua protocoale : TCP și UDP. TCP este reliable,
asigură reasamblarea datelor la destinație și este singurul însărcinat cu retransmiterea dat elor. El
trimite confirmare după ce datele au ajuns la destinație. Se ocupă cu stabilirea conexiunii, trimiterea
datelor în ordine și retransmite numai datele lipsă în caz că acestea se pierd.
Rețea . Aplicațiile și serviciile care rulează pe un dispozitiv final de rețea pot comunica cu
serviciile si aplicațiile existente pe un alt dispozitiv final de rețea, nivelul rețea asigurănd
transmiterea datelor în mod eficient prin rețea. La acest nivel se realizează adresarea logică , iar
procesele existente aici per mit datelor primite de la nivelul transport să fie ambalate și transportate.
Încapsularea specifică acestui layer permite ca datele să fie transmise la o destinație din aceeași
rețea sau într -o altă rețea.
La nivelul rețea se analizează modul în care rețel ele sunt împărțite în grupuri de gazde
pentru gestionarea fluxului de pachete dintr -o rețea, proces numit subnetizare. De asemenea, se
prezintă modul în care este facilitată comunicarea între rețele, proces cunoscut sub numele de
rutare. Stratul de rețea utilizează patru procese de bază pentru a permite schimbul de date dintre
două dispozitive finale în rețea : adresare logic ă, încapsulare, rutare și de -încapsulare. Asupra lor
vom reveni ulterior pentru a le clarifica.
Există mai multe protocoale de strat d e rețea dintre care , numai următoarele două sunt de
obicei implementate pe scară largă : Internet Protocol versiunea 4 (IPv4) și Internet Protocol
versiunea 6 (IPv6) . Alte protocoale de rețea strat mai vechi care trebuie menționate, dar care nu
sunt utiliza te pe scară largă , includ: Novell IPX (IPX), AppleTalk, Connectionless Network Service
(CLNS/DECNet) .

Florentina Băcioiu Descrierea domeniului. Rețele de calculatoare
13 Legături de date . Stratul Legături de date se ocupă cu schimbul de frame -uri (cadre) între
nodurile unei rețele. Frame -urile reprezintă pachete primite de la stratul superior cărora li s -a
adaugat un header de layer 2. Astfel, li se permite straturilor superioare accesul la mediul fizic.
Stratul legaturi de date, îndeplinește, așadar, două roluri importante : accept ă pachete de layer 3 și
le încapsuleaza în unități numite frame -uri (cadre) și controlează accesul la mediul fizic, asigurând
în același timp detectarea erorilor.
Stratul Legături de date este împarțit în două substraturi : Logical Link Control (LLC) și Media
Access Control (MAC). Logical Link Contr ol este substratul superior și permite comunicarea cu Stratul de
rețea, iar Media Access Control este cel inferior și permite diverselor tehnologii, precum Ethernet LAN, Wi-
Fi și Bluetooth , accesul la rețea.

Figură 2.7 Substraturile Nivelului Legături de date (9)
Fizic . Nivelul fizic codifică frame -urile de la nivelul Legături de date și creează semnale
electrice, optice sau de tip unde radio, pe care le trimite prin intermedi ul conexiunilor fizice către
un dispozitiv final de rețea sau către unul intermediar. Acolo se decodifică biții primiți și se trimit

Florentina Băcioiu Descrierea domeniului. Rețele de calculatoare
14 către nivelul Legături de date, urmând ca informația primită să fie pasată mai departe până la nivelul
Aplicație.
Tipurile de medii fizice de la Nivelul fizic sunt : cablu de cupru, cablu de fibră optică și
wireless , fiecare necesitând un anumit tip de semnal. Cablul de cupru permite trecerea semnalelor
electrice prin intermediul său, fibra optică transmite unde de lumină, iar prin aer se trimit semnale
radio.
Stiva de protocoale TCP/IP . Pe baza modelului OSI a apărut stiva de protocoale TCP/IP,
aceasta din urmă fiind utilizată la nivel larg în cadrul Internetului, dar si în rețelele private. TCP/IP
cuprinde patru straturi: Apli cație, Transport, Internet și Acces la rețea. Nivelul Aplicație comprimă
funcțiile si protocoalele celor trei niveluri superioare ale modelului OSI : Aplicație, Prezentare și
Sesiune. Nivelul Transport este același ca în cazul modelului OSI, meținându -se fu ncția de
segmentare a datelor. Nivelul Internet corespunde Nivelului Rețea din cadrul OSI, iar aici se
produce adresarea logică. Ultimele două straturi inferioare ale modelului OSI sunt comprimate într –
unul singur în cazul stivei de protocoale TCP/IP, rezu ltând Nivelul Acces la rețea.

Figură 2.8 Modelul OSI vs. Stiva de protocoale TCP/IP (10)

Florentina Băcioiu Descrierea domeniului. Rețele de calculatoare
15 2.3 Rutare statică. Rutare dinamică

Un router conectează o rețea la altă rețea și este resp onsabil de livrarea de pachete prin
intermediul unor rețele diferite. Acesta folosește tabela de rutare pentru a determina cea mai buna
cale pe care să trimită un pachet. Routerul este responsabil cu trimiterea acestor pachete în timp
util. De capacitatea routerului de a trimite pachete în mod eficient depinde eficacitatea cu care se
comunică între rețele.
Routerele învață rețelele aflate la distanță fie dinamic, folosind protocoale de rutare, fie
manual, folosind rut e static e. În multe cazuri, se foloseșt e o combinație atât de protocoale dinamice
cât și rute statice. Rutele statice sunt frecvent întâlnite și au avantajul că nu necesită aceeași cantitate
de prelucrare și overhead ca în cazul rutării dinamice. Spre deosebire de rutele învățate dinamic,
rutele statice nu sunt actualizate automat și trebuie reconfigurate manual de fiecare data când
topologia rețelei se schimbă. O rută statică nu se schimbă până când administratorul nu o
reconfigurează manual.
Există avantaje ale rut ării statice față de rutarea dinamică . Printre acestea de numără faptul
că rutele statice nu sunt anunțate în rețea, rezultând o securitate crescută. De asemenea, rutele
statice folosesc mai puțină la țime de bandă , iar calea folosită de o rută statică pentru trimiterea
datelor este c unoscută.
Printre dezavantajele rutării statice se numără configurarea inițială și mentenanța, care sunt
consumatoare de timp, probabilitatea mare de apariție a erorilor, mai ales în cazul rețelelor de
dimensiune mare, necesitatea intervenției administrato rului de rețea pentru reconfigurarea rutelor.
De asemenea, întreținerea devine dificilă pe masură ce dimensiunea rețelei crește , și este necesar
să se cunoască întreaga topologie de rețea pentru implementarea corespunzătoare a rutelor statice.
Rutele stati ce sunt utile pentru rețele mai mici, însă ele oferă, de asemenea, un plus de
securitate în rețelele mari pentru anumite tipuri de trafic sau pentru legături catre alte rețele care
necesită mai mult control. Rutarea static ă și cea dinamică nu se exclud rec iproc, iar cele mai multe
rețele utilizează o combinație a celor două. Un router poate avea mai multe route către o rețea,
învățate atât static cât și dinamic, însă pentru că distața administrativă (AD) a unei rute statice este
1, aceasta va avea prioritat e față de cele dinamice.

Florentina Băcioiu Descrierea domeniului. Rețele de calculatoare
16 Într-o rețea mare, cu numeroase rețele și subrețele, configurarea și întreținerea rutelor statice
între acestea este destul de greoaie și implică cheltuieli administrative și operaționale mari. Aceste
costuri suplimentare sunt difi cil de ținut sub control mai ales în cazurile în care apar schimbari dese
în rețea, precum pierderea unei conexiuni sau implementarea unei noi subrețele. În această situație,
folosirea protocoalelor dinamice de rutare facilitează configurarea și mentenanța și ofera rețelei
scalabilitate. Protocoalele dinamice de rutare au fost folosite în rețele în cepând cu anii 1980, unul
dintre exemple fiind versiunea 1 a protocolului Routing Information Protocol (RIPv1).
Pe măsură ce rețelele au evoluat și au crescut în complexitate, au apărut noi protocoale de
rutare pentru a îndeplini nevoile noilor topologii de rețele. Protocolul RIP a evoluat pentru a se
alinia cerințelor rețelelor ce au crescut ca dimensiune, fiind lansată versiunea 2 a acestuia (RIPv2) .
Totuși, acea stă nouă versiune nu este încă scalabilă pentru rețelele mari din ziua de astăzi, fiind
necesare alte protocoale pentru a răspunde nevoilor rețelelor de dimensiuni crescute. Dintre acestea,
amintim Open Shortest Path First (OSPF) și Intermediate System -to-Intermediate System (IS -IS).
De asemenea, Cisco a dezvoltat protocolul Interior Gateway Routing Protocol (IGRP), precum și
Enhanced IGRP (EIGRP), ambele foarte potrivite pentru a fi implementate în rețele de dimensiuni
mari. Mai mult decât atât, a apărut n ecesitatea de a exista conexiuni între providerii de Internet
(Internet Service Providers – ISPs), sau între ISPs și clienții lor privați, având rețele de dimensiuni
foarte mari . În acest scop, a fost dezvoltat Border Gateway Protocol (BGP ).
Protocoalele de rutare au fost dezvoltate inițial pentru Ipv4, însă o data cu epuizarea
adreselor și necesitatea suplimentării lor prin apariția protocolului Ipv6, au fost dezvoltate și
versiuni ale protocoalelor de rutare pentru Ipv6. Astfel, RIPv2, EIGRP, OSPFv2, IS -IS și BGP -4
sunt versiuni de protocoale de rutare specifice Ipv4. Pentru Ipv6 au fost dezvoltate RIPng, EIGRP
pentru Ipv6, OSPFv3, IS -IS pentru Ipv6 și BGP -MP.

Florentina Băcioiu Descrierea domeniului. Rețele de calculatoare
17
Figură 2.9 Clasificarea protocoalelor de ruta re (11)
În afară de protocoalele Ipv4 și Ipv6 pentru care au fost dezvoltate, protocoalele de rutare
mai pot fi clasificate în funcție de scopul pentru care au fost implementate : pentru interior sau
pentru exterior, în funcție de modul lor de operare : distance vector, link -state și path -vector, dar și
in funcție de comportamentul lor : classful sau classless. Aceste clasific ări pot fi observate în Figură
2.9, precum și protocoalele ce aparțin fiecărei ramuri.

Figură 2.10 Clasificare protocoale de rutare (12)

Florentina Băcioiu Descrierea domeniului. Rețele de calculatoare
18 Pentru a înțelege mai bine protocoalele de interior și de exterior, este necesar să introducem
termenul de sistem autonom. Un sistem autonom (AS) es te o colecție de routere aflate sub aceeași
administrare , cum ar fi o compani e sau o organizație. Un AS este, de asemenea, cunoscut ca un
domeniu d e rutare. Exemple tipice ale unui AS sunt rețeaua internă a unei companii și rețea ua unui
ISP. Întreg Interne tul se bazează, de fapt, pe AS -uri. Așadar, protocoalele de interior (IGP -urile)
sunt folosite pentru rutarea in cadrul aceluiași AS, iar protocoalele de exterior (EGP -urile) sunt
utilizate pentru a ruta informație între AS -uri diferite. IGP in clud RIP, E IGRP, OSPF, și IS -IS, iar
singurul protocol de tip EGP folosit în present în mod oficial la nivelul Internetului este BGP.
Protocoale le de rutare sunt folosite pentru a facilita schimbul de informații de rutare între
rutere. Un protocol de rutare este un s et de procese, algoritmi, ș i mesaje care sunt folosite pentru a
face schimb de informații de rutare și pentru a popula tabela de rutare cu cele mai bune trasee către
alte rețele . Scopul protocoalelor de rutare dinamice include: descoperirea rețelelor aflat e la distanță,
menținerea informațiilor updatate necesare rutării, alegerea celor mai bune căi către rețelele
destinație și abilitatea de a găsi o nouă cale potrivită pentru trimiterea pachetelor în cazul în care
cea curentă nu mai este disponibilă .
2.4 Switch ing

Switch -urile sunt folosite pentru a conecta mai multe dispositive împreună în aceeași rețea.
Într-o rețea de tip LAN, switch -urile sunt responsabile de conducerea și controlul fluxului de date
de la stratul de acces la resurse le din rețea , proces numi t switching.
Conceptul de comutare și transmitere de cadre este universal în rețea și telecomunicații.
Diferite tipuri de switch -uri sunt utilizate în LAN, WAN, și rețeaua telefonică publică (PSTN).
Conceptul fundamental de comutare se referă la un dispozi tiv de luarea a unei d ecizii pe baza a
două criterii: port de intrare și adresa de destinație . Decizia cu privi re la modul în care un switch
trimite trafic în rețea se face în fun cție de direcția fluxului de trafic . Portul de intrare (ingress port)
este f olosit pentru a descrie locul unde un frame intră în dispozitivul de destinație pe un port.
Termenul de port de ieșire (egress port) este folosit pentru a descrie locul prin care frame -urile
părăsesc părăsesc dispozitivul de rețea pe un anumit port. Atunci când un switch ia o decizie, se
bazează pe portul de intrare și adresa de destinație a mesajului.

Florentina Băcioiu Descrierea domeniului. Rețele de calculatoare
19 Un switch LAN are o tabel ă pe care o folosește pentru a determ ina cum să transmită trafic .
În cazul unui switch LAN, există doar un singur tabel de comutare master care descrie o asociere
clară între adrese și porturi. De aceea, un mesaj cu o adresă de destinație dată iese întotdeauna pe
același port de ieșire , indiferent de portul pe care acesta intră. S witch -urile LAN Cisco trimit cadre
Ethernet bazate pe adresa MAC destinație a cadrelor.
Există două moduri în care se poate face comutarea frame -urilor : store -and-forward sau cut-
through . Store -and-forward are două caracteristici principale care se disting de cut -through :
verificarea erorilor și buffering autom at.Store -and-forward citeș te întregul cadru într -un buffer și
verifică CRC -ul înainte de transmiterea cadru lui. Cut-through citește doar prima parte a cadrului și
începe transmiterea imedit ce adresa destinație este citit ă. Deși acest lucru este extrem de rapid, nu
asigură verificarea erorilor înainte de expediere a frame -ului.
Segmentele de rețea care împ art aceeași lățime de bandă între dispozitive sunt cunoscute ca
domenii de coliziune, pentru că atunci când două sau mai multe dispozitive din cadrul segme ntului
încerca să comunice în același timp, pot apărea coliziuni. Fiecare port de pe un switch formează un
domeniu de coliziune separat pentru a permite viteză de comunicare full-duplex extrem de mare .
În ceea ce privește domeniile de broadcast, switch -ul nu este un dispozitiv care sa le separe, precum
routerul, întrucât cel dintâi nu filtrează frame -urile de broadcast. Porturile switch -ului nu blochează
broadcasturile, așadar, conectând mai multe switch -uri, se va extinde domeniul de broadcast,
rezultând p erformanțe slabe ale rețelei.
Switch -urile funcționează la nivelul layerului 2 al modelului OSI, însă există și switch -uri
care funcționează la nivelul layerului 3, fiind capabile să realizeze funcția de rutare. De asemenea,
o rețea locală virtuală (VLAN) poate fi creată cu ajutorul unui switch de nivel 2 pentru a reduce
dimensiunile domeniilor de broadcast , funcționând asemenea unui dispozitiv Layer 3. (13)
2.5 IPv4. IPv6

IP este serviciul de la nivelul rețea implementat de suita d e protocoale TCP / IP. Acesta
oferă doar funcțiile care sunt necesare pentru a trimite un pachet de la sursă la destinație într-un
sistem interconectat de rețele. Protocolul nu a fost c onceput pentru a urmări și gestiona fluxul de
pachete. Aceste funcții, dacă este necesar, sunt efectuate de alte protocoale la nivelul altor straturi.

Florentina Băcioiu Descrierea domeniului. Rețele de calculatoare
20 Protocolul IP nu stabilește o conexiune cu destinația înaintea trimiterii efective a pachetului, nu
presupune confirmarea primirii pachetului și funcționează independent de med iul prin care sunt
trimise datele.
IP încapsulează segmentul de strat de transport prin adăugarea unui header IP. Acest antet
este utilizat pentru a livra pachetul de la gazdă la destinație. Headerul este păstrat din momentul în
care pachetul părăsește str atul rețea de la nivelul sursei până când ajunge la nivelul rețea destinație.
Procesul de încapsulare a datelor la fiecare layer permite serviciilor de la diferite straturi să
funcționeze fără a afecta alte straturi. Acest lucru înseamnă că segmentele de strat de transport
poate fi ușor ambalate prin IPv4 sau IPv6 sau prin orice nou prot ocol care ar putea fi dezvoltat în
viitor.
IPv4 a fost introdus în 1983, când a fost folosit în proiectele de cercetare avansată ale
ARPANET (Advanced Research Projects Agen cy Network ), care a fost precursorul Internet ului.
Internetul este bazat în mare parte pe IPv4, care este încă protocolul de nivel de rețea cel mai utilizat
pe scara larga. Un pachet IPv4 este format din două părți: un antet IP, ce con ține informații precum
versiunea, servicii pentru asigurarea calității, time -to-live (TTL), protocolul de layer superior
folosit (ICMP, TCP, UDP), adresele IP sursă și destinație ; payload, ce conține informații specifice
nivelului de transport și datele p ropriu -zise.

Figură 2.11 Header -ul de IPv4 (14)

Florentina Băcioiu Descrierea domeniului. Rețele de calculatoare
21 Deși de -a lungul timpului protocolul IPv4 a suferit modificări pentru a face fața cerințelor
pe măsură ce rețelele au evoluat, exi stă încă l imitări ale IPv4 , printre care se num ără: epuizarea
adreselor IP, extinderea tabelelor de rutare la nivelul Internetului, lipsa conectivit ății de la un capăt
la altul al transmisiunii datelor.
IPv4 are un număr limitat de adrese publice ce pot f i utilizate , care s -a dovedit a fi
insuficient de -a lungul timpului . Deși există aproximativ 4 bilioane de adrese asignabile, creșterea
numărului de dispozitive ce necesită o adresă IP a dus la o nevoie de suplimentare a IP -urilor. În
acest sens, a apărut subnetizarea, subiect ce va fi explicat ulterior. În ceea ce privește creșterea
tabelelor de rutare de la nivelul Internetului, neajunsul în această situație îl reprezintă faptul că
rutele IPv4 consumă o mare cantitate de memorie și resurse procesor pe rou terele din Internet. De
asemenea, Network Address Translation (NAT) este o tehnologie implementată de obicei în cadrul
rețelelor IPv4. NAT oferă o modalitate pentru mai multe dispozitive de a partaja o singură adresă
IP publică. Cu toate acestea, deoarece adresa IP publică este împărțit ă, adresa IP a unei gazde dintr –
o rețea internă este ascunsă. Acest lucru poate fi problematic pentru tehnologiile care necesită
conectivitate end -to-end.
La începutul anilor 1990, a început să se caute un înlocuitor pentru I Pv4, ceea ce a condus
la dezvoltarea versiunii 6 a protocolului IP (IPv6). IPv6 depașește limitele IPv4 și reprezintă o
îmbunătățire considerabilă , cu caracteristici ce se potrivesc cerințelor actuale ale rețelelor .
Îmbunătățirile aduse de IPv6 includ un s pațiu extins de adrese, o mai bună gestiune a pachetelor,
eliminarea nevoii de NAT și securitate integrată.
Adresele IPv6 sunt adrese pe 128 biți, spre deosebire de cele din IPv4, de numai 32 biți .
Acest lucru crește considerabil numărul de adrese IP disp onibile. Antetul IPv6 a fost simplificat,
având mai puține câmpuri . Acest lucru îmbunătățește gestionarea pachet elor de către routere . În
ceea ce privește Network Address Translation (NAT) , cu un astfel de număr mare de adrese IPv6
publice, acesta nu mai e ste necesar , evitându -se, astfel, problemele legate de aplicațiile ce necesită
conectivitate end -to-end. IPv6 are suport nativ de autentificare și capabilități de confidențialitate.
Cu IPv4, aceste caracteristici ar fi trebuit să fie implementate supliment ar pentru a face acest lucru.
Spațiul de adrese IPv4 pe 32 biți oferă aproximativ 4 .294.967.296 adrese unice. Dintre
acestea, doar 3,7 miliarde de adrese pot fi asignate , deoarece sistemul de adresare IPv4 separă

Florentina Băcioiu Descrierea domeniului. Rețele de calculatoare
22 adresele în clase, și își rezervă adrese p entru multicasting, testare și alte utilizari specifice. IPv6
oferă un spațiu de adrese de 340.282.366.920.938.463.463.374.607.431.768.211.456, sau 340
adrese undecillion, care este aproximativ echivalent cu fiecare fir de nisip pe Pământ.

Figură 2.12 Headerul de IPv6 (15)

2.6 Subnetizare

Proiectarea, implementarea ș i gestionarea unui plan de adresare IP eficient asigură că
rețelele po t funcționa eficient . Aces t lucru este valabi l mai ales pe măsură ce numă rul de cone xiuni
într-o rețea crește. Înț elegerea structurii ierarhice a adresei IP și cum să se modifice acea ierarhie
în scopul de a îndeplini mai eficient cerințele de rutare este o parte importantă a planificarii unui
sistem de adresare IP .
În adresa IPv4 , există două niveluri de ierarhie: o parte de rețea și o parte de gazdă. Aceste
două niveluri de ad resare permit grupări de bază în rețea, care să faciliteze rutarea de pachete într –

Florentina Băcioiu Descrierea domeniului. Rețele de calculatoare
23 o rețea de destinație. Un router transmit e pachete bazându -se pe porțiunea de rețea a unei adrese
IP; odată ce rețeaua este localizată, porțiunea gazdă a adresei permite identificarea dispozitivului
de destinație. Cu toate acestea, având în vedere numărul mare de rețele și dispozitive dintr -o rețea,
ierarhia pe două niveluri nu este suficientă, fiind introdus, astfel, procedeul de subnetizare. Practic,
acesta adaugă un al treilea nivel, acela de subrețea. Așadar, noua ierarhie este acum alcătuită din
trei niveluri: re țea, subrețea și gazdă.
Subne tizarea asigură îmbunătațirea performanțelor rețelelor și reduce traficul creat de
broadcasturi, micșorând numărul de dispozitive ce primesc mesajele de tip broadcast. O subrețea
sau un subnet este echivalentul unei rețele și pentru ca aceasta sa comunice cu o altă subrețea, este
necesar un router sau un switch de layer 3. Pentru a crea un plan de adresare IP pentru o companie
este necesar să se cunoască nevoile curente ale acesteia, cât și planurile de dezvoltare.

Figură 2.13 Subnetizare cu mască fixă (16)

Figură 2.14 Subnetizare cu mască variabilă (16)

24
3 Cerințele sistemului

Cerințele sistemului re prezintă o componentă foarte importantă în proiectarea aplicațiilor
software. Acestea reflectă funțiile sistemului proiectat și trebuie să fie clare, detaliate și complete.
De asemenea, este necesar să se pună accentul pe “ce” și nu “cum” se dore ște a fi p roiectat și
implementat sistemul. Cerințele sunt testabile, având instrumente de măsură specifice. (16)
Pentru indentificarea cerințelor este necesară folosirea mai multor surse de informare, printre
care consultarea actorilor si stemului, analizarea aplicațiilor existente pe piață la ora actuală,
standardele și restricțiile impuse domeniului în care se încadrează sistemul . Actorii sistemului,
cunoscuți și sub numele de stakeholderi, reprezintă multitudinea entităților exterioare s istemului
(persoane, obiecte, procese) care interacționează cu acesta.
Cerințele pot fi împărțite în două categorii, în funcție de scopul avut în vedere : cerin țe
funcționale și nefuncționale. Cerințele funționale sunt cele legate de capacitatea sistemului și
reflectă funcțiile și stările propriu -zise ale aplicației, în timp ce specificațiile nefuncționale
reprezintă restricțiile impuse sistemului și sunt în strânsă legătură cu calitatea, modul de
funcționare, dar și cu domeniul și parte a de dezvoltare a apl icației. (17)
3.1 Surse de informare
Pentru proiectarea sistemului „Aplicație pentru subnetizare” s -a pus accentul pe aplicațiile
deja existente la momentul actual, cât și pe specificațiile și restricțiile domeniului rețelelor de
calculatoare, și mai exact , al adresării logice de la nivelul Rețea al modelului OSI. Actorii
sistemului sunt, de asemenea, luați în considerare.
Câteva exemple de aplicații care efectuează operații de subnetizare pot fi găsite la adresele
http://www.tunnelsup.com/subnet -calculator , http://www.subnetonline.com/pages/subnet –
calculators/ip -subnet -calculator.php , http://www.vlsm -calc.net/ . Luând în considerare atât
neajunsurile, cât și punctele forte, aceste resurse au reprezentat punctul de pornire în realizarea
sistemului din lucrarea curentă, ce se dorește a fi o apli cație customizată .
În ceea ce privește noțiunile teoretice legate de domeniul rețelisticii, o sursă importantă de
informare o reprezintă cele 4 module CCNA ce aparțin companiei Cisco : Introducing to Networks,

Florentina Băcioiu Cerințele sistemului
25 Routing and Switching Essentials, Scaling Netwo rks, Connecting Networks , disponibile online la
adresa https://www.netacad.com/ , în urma autentificării cu contul de cursant.
3.2 Actorii sistemului
Actorii sistemului sunt reprezentați în mare parte de utilizatorii ap licației :
 administratori de re țele
 ingineri
 specialiști în rețelistică
 studenț i și elevi din domeniul tehnic
 persoane cu cunoștințe minime de rețele de calculatoare sau în curs de învățare
Aplicația este destinată celor care c unosc procesul de subnetiz are, dar doresc să reducă
timpul acordat acestui procedeu și să elimine greșelile umane care pot să apară în timpul
calculelor. De asemenea, sistemul poate fi folosit și pentru verificări, în cazul în care s -a efectuat
deja subnetizarea, dar se dorește con firmarea corectitudinii rezultatelor.
3.3 Cerințe funcționale

1. Aplicația proiectată trebuie să permită utilizatorului selectarea tabului corespunzător IPv4,
respectiv IPv6, in funcție de protocolul folosit pentru subnetizare.

2. Sistemul trebuie sa permita util izatorului introducerea datelor de intrare : adresa de re țea,
prefixul acesteia, numărul de subrețele dorite și numărul de hosturi cerute pentru fiecare
subrețea, cât și o descriere pentru fiecare subrețea.

3. Datele introduse de utilizator trebuie sa fie val idate înaintea prelucrării lor.

4. În cazul în care există câmpuri necompletate sau invalide, aplicația trebuie să afișeze un
mesaj de eroare și să reafișeze formularul pentru completarea câmpurilor cu date
corespunzătoare.

Florentina Băcioiu Cerințele sistemului
26 5. În urma prelucrării datelor intro duse, aplicația trebuie să afișeze datele de ieșire : pentru
fiecare subre țea cerută, se va afișa adresa sa de rețea, range -ul de ip -uri disponibile, adresa
de broadcast (în cazul IPv4) , numărul de hosturi cerute, numărul maxim de hosturi
disponibile, cât ș i descrierea subrețelei.

6. În cazul în care numărul de subrețele dorite și/sau numărul de hosturi necesare depășesc
capacitatea adresei inițiale de rețea introdusă, se va afișa un mesaj corespunzător.

7. Aplicația trebuie să ofere posibilitatea stocarii infor mațiilor primite, alături de date la care a
fost folosită aplicația pentru calculul subrețelelor.

8. În cazul în care nu s -a reușit salvarea datelor returnate, aplicația trebuie să afișeze un mesaj
corespunzător.

3.4 Cerințe nefuncționale

1. Aplicația trebuie să aibă o interfață intuitivă și să fie ușor de utilizat de către useri.

2. Sistemul trebuie să nu se blocheze și să raspundă în timp util cererilor utilizatorilor.

3. Timpul de așteptare al utilizatorului până la primirea datelor de ieșire trebuie să fie direct
proporțional cu cantitatea de informație de prelucrat.

4. Nu trebuie să existe timpi de așteptare suplimentari .

27
4 Proiectarea aplicației . Modelare UML

4.1 Diagramele de clase
Sistemul proiectat este format din două aplicații : un client Java, de tip aplica ție de sktop, și
un web service realizat cu ajutorul frameworkului .NET și a limbajului C#. În continuare, am
realizat diagramele de clase pentru ambele aplicații.
Figurile 4.1, 4.2 și 4.3 sunt părți ale diagramei de clasă reprezentată de clientul care va
consuma web service -ul. Cele trei imagini formează un tot unitar și simbolizează clasele cu
atributele și metodele specifice, cât și legăturile dintre clase. În figura 4.1, SpinnerControl.java
moștenește clasa CustomControl.java. ObjectProperty și ObjectProperty <Integer> sunt clase
specifice tehnologiei JavaFx.

Figură 4.1 Diagrama de activități [partea 1]

Florentina Băcioiu Proiectarea aplicației. Modelare UML
28
Figură 4.2 Diagrama de activități [partea a 2 -a]
În figura 4. 2, este prezentat controllerul aplicației -client, Controller.java. Acesta
implementează clasa Initializable și suprascrie metoda acesteia, void initialize(URL location,
ResourceBundle) . În această metodă, sunt apelate alte două metode: initializeIPv4() și
initializeIPv6() , astfel încât CustomControl să poată fi folosit atât din tabul IPv4 al aplicației, cât
și din tabul IPv6.
Metodele void handleIPv4ButtonClick(ActionEvent actionEvent) și void
handleIPv6ButtonClick(ActionEvent actionEvent) se apelează în u rma apăsării butoanelor
specifice IPv4 și IPv6 de către utilizator, din interfața grafică. De asemenea, vom avea o metodă
de deserializare a obiectelor JSON ce vor fi primite de la serviciul web, numită
deserializeJsonToJavaObjects(String json) . Aceasta es te de tip List <SubnetModel> și returnează
o listă de obiecte de tip SubnetModel.
ScrollPane, ArrayList <Label>, TableView<TableItemModel>, TableView,
ObservableList<TableItemModel>, TableColumn, TableColumn<TableItemModel, String>,
Label sunt clase specific e JavaFX. Ele sunt folosite pentru a declara atributele clasei Controller ,
precum se poate observa în figura 4.2. De exemplu , atributul ipv4ResultPane este de clara t ca un

Florentina Băcioiu Proiectarea aplicației. Modelare UML
29 obiect de tip ScrollPane , atributul labels este declarat ca o listă de tip ArrayList. Analog, sunt
declarate și celelalte. Trebuie menționat faptul că atributele și metodele precedate de semnul “-” au
modificatorul de acces de tip private , iar cele precedate de semnul “+” sunt de tip public .

Figură 4.3 Diagrama de activități [partea a 3 -a]
În figura 4.3 este prezentată clasa SubnetModel.java . Aceasta are o serie de atribute de tip
private , ce se doresc a fi calculate și afișate în interfața grafică : subnetAddress, startIp, endIp,
broadCastAd dress, maxNrOfHosts, neededNrOfHosts și description. Ca metode, sunt simbolizați
metodele de tip get și set pentru fiecare atribut, dar și constructorul fără parametri al clasei,
SubnetModel() . De asemenea, este suprascrisă metoda toString() pentru stabili rea formatului în
care vor fi afișate atributele clasei în momentul instanțierii.
Figura prezintă și clasa EditingCel, ce moștenește clasa TableCell <TableItemModel, String>.
Aceasta are utilitate în editarea celulelor tabelurilor din interfața utilizator. Nu în ultimul rând, este
prezentată clasa principală Main, ce conține metoda principală main() , dar și pe cea start() ,
specifică JavaFX .

Florentina Băcioiu Proiectarea aplicației. Modelare UML
30
Figură 4.4 Diagrama de clase serviciu web

Florentina Băcioiu Proiectarea aplicației. Modelare UML
31
4.2 Diagrama cazurilor de util izare

Figură 4.5 Diagrama cazurilor de utilizare
Figura 4.4 prezintă actorii sistemului și relațiile dintre ei, cât și scenariile de utilizare, relațiile
stabilite între acestea și relațiile dintre actori ș i use -case-uri. După cum se poate observa, există o
relație de generalizare între actorii sistemului : Inginer re țele, Specialist rețele, Student, Elev și
Utilizator. Aceasta simbolizează faptul că primii patru fac parte din aceeași categorie, Utilizator,
definind interacțiunea pe care o au cu sistemul.
Între actorul Utilizator și use -case-ul “Completeaz ă datele de intrare ” există relația de
asociere, ce exprimă interacțiunea dintre cele două elemente. Relațiile de dependență sunt de două

Florentina Băcioiu Proiectarea aplicației. Modelare UML
32 tipuri: include și extend , și se stabilesc numai între use -case-uri, precum se poate vedea în figură.
Astfel, use -case-ul “Vezi op țiuni de protocoale ” este de sine stătător, fiind însă necesar pentru
funcționalitatea use -case-ului “Selecteaz ă protocol ”, între cele două fiin d simbolizată o relație de
tip include . Același tip de relație se regăsește și între use -case-urile “Selecteaz ă protocol ” și
“Completeaz ă date de intrare ”, cel din urmă fiind use -case-ul de bază, care include funcționalitatea
primului. Analog, sunt simboli zate și celelalte relații de tip include între use -case-uri.
De asemenea, în figură se observă și o relație de tip extend , în care cazul de utilizare de bază,
“Vezi informa țiile pentru fiecare subrețea ”, controlează dacă “Export ă PDF ” va fi executat sau n u.
4.3 Diagrama de activități

Figură 4.6 Diagrama de activități

33
5 Tehnologii folosite
5.1 Java

Tehnologia Java reprezintă atât un limbaj de programare, cât și o platformă. În ceea ce
privește limbajul de programar e, acesta este un limbaj high -level, orientat pe obiecte, robust, sigur,
iar aplicațiile realizate cu ajutorul lui sunt portabile, acestea rulând independent de platformă. (18)
De asemenea, o caracteristică importantă a limbaju lui Java este aceea că este open source, iar
programele scrise cu ajutorul său reprezintă proprietatea intelectuală a programatorului, așadar pot
fi comercializate fără a fi necesară plata unei licențe către Oracle. (19)
Un pro gram Java poate fi scris cu ajutorul oricărui editor de text, spre exemplu Notepad,
Notepad++, BlueJ, urmând să fie salvat într -un fișier cu extensia .java. Următorul pas este
compilarea acestui fișier, rezultând un alt fișier, de această dată având extens ia .class. Acest fișier
va fi interpretat de mașina virtuală JVM (Java Virtual Machine) , ce reprezintă un emulator cu rol
de a traduce fișierul .class în limbaj mașină. Datorită JVM, care poate fi instalată pe orice sistem
de operare : UNIX, Linux, Solaris, Windows, fi șierul .class poate fi rulat independent de platformă .
Acest proces poate avea loc și folosind un mediu de integrare, precum Eclipse, Netbeans, IntelliJ
IDEA.

Figură 5.1 Procesul de dezvoltare a unui program Java (18)

Datorită faptului ca Java este un limbaj de programare ce necesită atât compilare, cât și
interpretare, prezintă dezavantajul de a nu rula în timp real și nu este potrivit pentru aplicațiile care
necesi tă acest lucru . Totuși, acest aspect reprezintă un compromis bun, având în vedere eficiența,
siguranța și independența sa de platformă. De asemenea, deși aplicațiile scrise cu ajutorul

Florentina Băcioiu Tehnologii folosite
34 limbajului Java pot rula pe orice fel de sistem, acestea sunt dependent e de existența mașinii virtuale
JVM. Acest lucru este compensat de faptul că JVM este disponibilă gratuit și în mai multe variante,
în funcție de sistemul de operare pe care urmează să fie instalată. (19)

Figură 5.2 Independeța de platformă a limbajului Java (18)
Platforma Java reprezintă o platformă software care rulează deasupra altor platforme
hardware. Ea este formată din două componente: ma șina J VM și API -ul Java Application
Programming Interface. API reprezintă o colecție de componente software grupate în librării ce
sunt cunoscute sub numele de “pachete”. Acestea ofer ă funcționalități utile programatorilor în
dezvoltarea aplicațiilor Java. (18)
Pentru a programa și executa aplicații Java, sunt necesare trei componente : mașina virtuală
JVM, ce poate fi instalată pe calculator prin downloadarea și instalarea pachetului Java Runtime
Environment – JRE de pe site -ul http://java.sun.com . De asemenea, de pe același site, este necesar
să se descarce și să se instaleze pachetul Java Developer Kit – JDK, ce conține compilatorul
javac.exe, executorul java.exe, vizualizatorul de app leturi appletviewer.exe, cât și dezvoltatorul de
documentație javadoc.exe. Nu în ultimul rând, este necesar un editor de text pentru scrierea
programelor. Ca o alternative, există posibilitatea folosirii unui mediu de programare, cunoscut sub
numele de IDE (Integrated Development Environment). (19) Pentru scrierea aplicației Java din

Florentina Băcioiu Tehnologii folosite
35 lucrarea curentă, va fi folosit mediul de programare InteliJ IDEA, ce oferă în același timp o interfață
prietenoasă pentru scrierea și editarea apl icației, dar se ocupă și cu toți pașii descriși anterior,
necesari pentru crearea programului.

Figură 5.3 Mediul de programare IntelliJ IDEA
5.2 JavaFX

Figură 5.4 Logo JavaFX (20)
JavaFX reprezintă un set de pachete grafice și media care facilitează crearea, testarea, alături
de realizarea unui design modern a aplicațiilor Java. Principiul de funcționare a librăriei JavaFX
vizează sep ararea logicii aplicației, reprezentată de partea back -end, de aspectul vizual al acestuia,
cunoscut și sub numele de user interface (UI). Pentru realizarea designului aplicației, JavaFX oferă
posibilitatea folosirii unui limbaj de scripting , FXML, sau a u nei componente numite JavaFX Scene

Florentina Băcioiu Tehnologii folosite
36 Builder. Pentru customizarea părții vizuale a aplicației, se folosesc foile de stil CSS (Cascading
Style Sheets). De asemenea, pentru crearea logicii aplicației, se utilizează cod Java. (21)
5.3 C#. Framework -ul .NET

C# este un limbaj de programare orientat pe obiecte, de nivel înalt, utilizat pentru a lucra
împreună cu frameworkul .NET. Acesta din urmă oferă un mediu cu ajutorul căruia se pot programa
o mare varietate de aplicații ce rulează sub sistemul de operare Windows. Printre ele se numără
paginile web dinamice, aplicațiile WPF (Windows Presentation Foundation), servicii web, sau
aplicații de tip desktop clasice.
Atât Frameworkul .NET cât și limbajul C# sunt se bazează în totalitate pe pri ncipi ile
orientării pe obiecte. Printre avantajele .NET se numără independența limbajelor de programare,
Visual Basic, C# și managed C++ fiind într -o primă fază compilate într -un limbaj intermediar.
Acest lucru asigură interoperabilitatea lor. De asemenea, prezintă suport pentru pagini web
dinamice, acces rapid la datele stocate în bazele de date, prin intermediul componentelor cunoscute
sub numele de ADO.NET.
Prin introducerea conceptului de assembly, în locul DLL -urilor clasice, .NET a restructurat
compl et modul în care codul este împărțit între aplicații. Tot datorită introducerii asssembly -urilor,
securitatea a fost sporită. Acestea conțin informații de securitate ce precizeaza ce procese sau
categorii de useri pot apela anumite metode sau clase. Nu în ultimul rând, .NET are integrat suport
pentru servicii web. (22)

Figură 5.5 Siglă .NET 4.5.1 (23)

Florentina Băcioiu Tehnologii folosite
37 Pentru scrierea, editarea, compilarea și debugging ul programelor scrise cu ajutorul .NET,
este necesară instalarea mediului de integrare Microsoft Visual Studio. Ultima variantă apărută la
momentul actual este Microsoft Visual Studio 2015 și se găsește în trei variante : Community
Edition , Visual Studio Pr ofessional și Enterprise Edition. Dintre acestea, Community Edition este
disponibilă gratuit utilizatorilor. (24)
5.4 Servicii Web

Un serviciu web este o entitate software care acceptă requesturi de o anumită formă de la alte
aplicații software prin intermediul a diferite protocoale de comunicație și produc răspunsuri
specifice. Fiecare serviciu web este independent de celelalte servicii web sau de aplicațiile de la
care primește cereri. Serviciile web au avantajul de a putea fi re utilizate. Ele pot fi accesate de mai
mulți clienți.
Componentele de bază ale unui serviciu web sunt producătorul (providerul) și consumatorul
(requester ). Consumatorul este cel care face requestul și utilizează serviciul web, iar producătorul
conține impl ementarea serviciului web. (25)

Figură 5.6 Componente de bază ale unui serviciu web (25)
5.5 Arhitectura M odel-View-Controller

Model -View -Controller (M VC) este un design pattern foarte cunoscut în programarea
software. Acesta este alcătuit din trei parți fundamentale : Model, reprezentat de date, View, care

Florentina Băcioiu Tehnologii folosite
38 este interfa ța din care se pot vizualiza și modifica datele, și Controller, care face legătura într e
primele două componente.
Modelul este o reprezentare a datelor și nu are o altă funcționalitate. El este independent de
View și Controller, în timp ce Controllerul depinde atât de Model cât și de View. View -ul
informează Controllerul despre acțiunile ut ilizatorului, iar cel din urmă se ocupă cu schimbările
asupra Modelului și updatează View -ul.
Printre avantajele MVC, se numără faptul că modelele pot fi reutilizate fără a fi necesare alte
modificări. Același lucru poate fi posibil și pentru View. De asem enea, separarea interfeței de
logica aplicației facilitează programarea și mentenanța sistemului. (26)

Figură 5.7 Arhitectura MVC (27)

39
6 Implementare a sistemului

Sistemul este alcătuit din două aplicații: serviciul web și clientul Java. Aplicația Java este de
tip desktop și va apela serviciul web pentru a calcula informațiile despre subrețele. Aceasta va
transmite datele de intrare preluate de la util izator, iar serviciul web, pe baza lor și a algoritmului
de calcul, va realiza subnetizarea. Apoi, va trimite răspunsul în format JSON aplicației Java, care
îl va deserializa și îl va afișa în interfața utilizator.
6.1 Aplicația de tip Desktop

Aplicația are o clasă principală, Main, ce conține metoda principală main(String [] args ) și
suprascrie metoda start(), ce are ca parametru un obiect de tip Stage. Aceasta încarcă fișierul
“sample.fxml ”, ce con ține structura interfeței utilizator. Obiectul primaryStage este containerul
principal, căruia ii sunt suprascrise proprietățile. Pe suprafața sa sunt adăugate celelalte elemente
grafice , conform structurii fișierului “sample.fxml ”. Metoda show() este apelată pentru ca scena
principală să fie vizibilă , iar setResiza ble() cu parametrul false pentru ca dimensiunile acesteia să
nu poate fi modificate de către utilizator.
public class Main extends Application {

@Override
public void start(Stage primaryStage) throws Exception{
Parent root = FXMLLoader. load(getClass().getResource( "sample.fxml" ));
primaryStage.setTitle( "Aplicatie pentru subnetizare" );
primaryStage.setScene( new Scene(root, 1350, 700));
primaryStage.show();
primaryStage.setResizable( false);

}

public st atic void main(String[] args) {
launch(args);
}
}

Florentina Băcioiu Implementarea sistemului
40 Fișierul .fxml, are o structură asemănătoare unui fișier .xml, elementele grafice folosite
fiind declarate într -o structură imbricată , precum se poate vedea în figur a 6.1. Elementul principal
este TabPane, care folosește controllerul Controller.java din pachetul sample . Pe suprafața sa, a
fost adăugat un container numit tabs, ce conține cele două taburi corespunzătoare IPv4 și IPv6 ,
fiecare având conținutul său.

Figură 6.1 Structura principală a fișierului sample.fxml

Expandând structura corespunzătoare elementului GridPane din interiorul
<AnchorPane> …</AnchorPane>, se poate observa butonul “Calculeaz ă”, căruia i s -au atribuit un
id și o proprie tate onAction, ce vor fi preluate și folosite de Controller, astfel producerea
evenimentului de apăsare a butonului să se trimită cererea către serviciul web pentru calcularea
subnetizării folosind protocolul IPv4.
<Button GridPane.columnIndex ="5" GridPane.rowIndex ="2" fx:id="ipv4button"
mnemonicParsing ="false" onAction ="#handleIPv4ButtonClick" text="Calculeaza" />

Florentina Băcioiu Implementarea sistemului
41 Un buton asemănător există și pentru tabul IPv6, iar acesta se poate observa expandând
structura corespunzătoare IPv6 :
<Button GridPane.colu mnIndex="5" GridPane.rowIndex ="2" fx:id="ipv6button"
mnemonicParsing ="false" onAction ="#handleIPv6ButtonClick" text="Calculeaza" />

Pentru că am discutat despre Controller, următoarele metode pe care le conține sunt
representative pentru modul în care a cesta manageriază producerea evenimentelor de apăsare a
butoanelor corespunz ătoare IPv4 și IPv6:

public void handleIPv4ButtonClick(ActionEvent actionEvent) { …} și
public void handleIPv6ButtonClick(ActionEvent actionEvent) {…}.

Ambele metode conțin la început următoarea secțiune de cod, în care se instanțiază
obiect ul json de tip JSONObject și se stabilește formatul acestuia.

JSONObject json = new JSONObject();
JSONObject param1 = new JSONObject();
param1.put( "Value1" , "Valoare 1 a" );
param1.put( "Value2", "Valoare 2 a" );
JSONObject param2 = new JSONObject();
param2.put( "Value1" , "Valoare 1 b" );
param2.put( "Value2" , "Valoare 2 b" );
json.put( "input", param1);
json.put( "param", param2);

În continuare, se încearcă stabilirea conexiunii cu serviciul web p rin intermediul
protocolului http :

try (CloseableHttpClient httpClient = HttpClientBuilder. create().build()) {
HttpPost request = new
HttpPost( "http://localhost:18856/SubnetCalculator/GetIp" );
StringEntity params = new StringEntity(json.to JSONString(), "UTF-8");
request.addHeader( "Content -Type", "application/json" );
request.setEntity(params);
…………………………………………………………………………………………………………….. ………
} catch (IOException e) {
System. out.println(e);
}
}

În interiorul blocului try-catch se creeaz ă requestul ca obiect de tip HttpPost, ce primește
ca parametru la inițializare linkul la care se găsește metoda serviciului web ce va fi apelată :

Florentina Băcioiu Implementarea sistemului
42 http://localhost:18856/SubnetCalculator/GetIp . Http este protocolul utilizat, SubnetCalculator
reprezintă clasa serviciului web ce contine metoda GetIp ce va fi apelată.
În locul pu nctelor de suspensie din porțiunea de cod anterioară, se află un alt bloc try -catch,
în care se apelează metoda deserializeJsonToJavaObjects() , ce primește ca parametru obiectul
responseString , de tip String. Obiectul responseString conține raspunsul primi t de la web service.
Apelarea metodei menționate are ca efect deserializarea datelor primi te și stocarea lor într -o listă
de obiecte de tip SubnetModel. După aceea, ele sunt afișate în interfața utilizator.

try (CloseableHttpResponse response = httpClient .execute(request)) {
HttpEntity entity = response.getEntity();
String responseString = EntityUtils. toString (entity, "UTF-8");
List<SubnetModel> responseObjects =
deserializeJsonToJavaObjects(responseString);
ipv4responseColumn .getChildren() .clear();
for(SubnetModel responseObject : responseObjects){
ipv4responseColumn .getChildren().add( new
Label(responseObject.toString()));
}
}
catch(IOException e){
System. out.println(e);
}

Clasa SubnetModel are aceeași structură precum clasa corespondentă din web service și
conține atributele private ce descriu o subrețea. Acestea sunt informațiile ce se doresc a fi afișate
în interfață în urma calculării subnetizării.
public class SubnetModel{

private String subnetAddress ;
private String startIp;
private String endIp;
private String broadCastAddress ;
private int maxNrOfHosts ;
private int neededNrOfHosts ;
private String description ;

public SubnetModel() { }

public String getSubnetAddress() {
return subnetAddress ;
}

public void setSubnetAdd ress(String subnetAddress) {
this.subnetAddress = subnetAddress;
}
………………………………………………………………………………………..

Florentina Băcioiu Implementarea sistemului
43 @Override
public String toString(){ …}
}
De asemenea, după cum se poate observa, există și constructorul fără parametri al clasei, cât
și metodele de tip get și set pentru fiecare atribut. Nu în utlimul rând, în clasă este suprascrisă
metoda toString(), ce returnează un obiect de tip String forma tat în mod convenabil.
@Override
public String toString(){
return String. format("Descrierea subretelei: %s Adresa de retea:
Adresa de broadcast: %s%s Numar de hosturi " + "cerute: %d Range -ul de
ip-uri disponibile: %s -%s Numar maxim de hosturi: %d" ,
getDescription(), getBroadCastAddress(), getSubnetAddress(),
getNeededNrOfHosts(), getStartIp(), getEndIp(), getMaxNrOfHosts());
}

6.2 Serviciul Web

Serviciul web este o aplicație realizată cu ajutorul frameworkului .NET și limbajul C#. Pentru
scrierea sa, am folosit mediul de dezvoltare Microsoft Visual Studio 2013.
Aplicație de tip Web Services conține ca și clientul Java, o clasă SubnetModel. Aceasta are
aceeași structură precum cea din aplicația Java, lucru necesar pentru transmiterea cererilor și
răspu nsurilor în același format între cele două sisteme.
public class SubnetModel
{
public string SubnetAddress { get; set; }
public string StartIp { get; set; }
public string EndIp { get; set; }
public string BroadCastAddres s { get; set; }
public int MaxNrOfHosts { get; set; }
public int NeededNrOfHosts { get; set; }
public string Description { get; set; }
}
Clasa IPv4NetworkCalculator conține metodele folosite pentru realizarea propriu -zisă a
subneti zării:
public IEnumerable <SubnetModel > NextNetworkAddressResult( NetworkAddressModel
na,SubnetHostsDescriptionMappingModel [] subnetHostsDescriptionMappingModel)
{…}

Florentina Băcioiu Implementarea sistemului
44 Aceasta returneaz ă o listă de obiecte de tip SubnetModel, reprezentând informațiile necesar e
pentru a fi transmise ca răspuns clientului. Metoda are ca parametri obiectul na de tip
NetworkAddressModel și vectorul subnetHostsDescriptionMappingModel, de tip
SubnetHostsDescriptionMappingModel .
Structura clasei NetworkAddressModel este prezentată î n porțiunea de cod următoare, ea
modelând un obiect ce conține cele patru seturi de biți dintr -o subrețea, urmați de prefixul rețele i.
Așadar, poate instanția un obiect de forma : 192.168.0.0/24, unde /24 reprezint ă porțiunea de rețea,
iar restul biților po rțiunea de host.
public class NetworkAddressModel : ICloneable
{
public IpModel NetworkAddress { get; set; }

public int Prefix { get; set; }

public NetworkAddressModel()
{
}

public NetworkAddressModel( int _firstByte, int _secondByte, int
_thirdByte, int _fourthByte)
{
NetworkAddress = new IpModel();
this.NetworkAddress.FirstByte = _firstByte;
this.NetworkAddress.SecondByte = _secondByte;
this.NetworkAddre ss.ThirdByte = _thirdByte;
this.NetworkAddress.FourthByte = _fourthByte;

}

public override string ToString()
{
return string.Format( "{0}/{1}" , NetworkAddress, Prefix);
}
}
Clasa SubnetHos tsDescriptionMappingModel conține două atribute : int NumberOfHosts și
string Description . Ea este importantă pentru a se putea păstra o legătură între subrețele le cerute și
descrierile lor introduse de utilizator chiar și după prelucrarea datelor în servic iul web. Subrețele și
numărul de hosturi necesare pentru fiecare sunt introduse în ordine aleatoare de către utilizator în
interfa ța aplicației client.

Florentina Băcioiu Implementarea sistemului
45 Algoritmul de subnetizare necesită sortarea lor în ordinea descrescătoare a hosturilor pentru a
putea f i calculate, iar serviciul web se ocupă și de acest lucru. Întrucât răspunsul este trimis în
ordinea aceasta clientului, și nu in cea introdusă de utilizator, este necesar să se facă această
legătură.
public class SubnetHostsDescriptionMappingModel
{
public int NumberOfHosts { get; set; }
public string Description { get; set; }
}
Controllerul SubnetCalculatorController conține metoda GetIp (). Aceasta returnează obiectul
de tip JSON c are încapsulează răspunsul c u informațiile solicitate d e aplicația Java. Pentru a
specifica faptul c ă se folosește metoda POST, se adaugă atributul [HttpPost] deasupra metodei
GetIp().
[HttpPost ]
public ActionResult GetIp(NetworkAddressModel na,
SubnetHostsDescriptionMappingModel [] nrsOfHosts)
{

return Json(new IPv4NetworkCalculator ().NextNetworkAddressResult(na,
nrsOfHosts), JsonRequestBehavior .AllowGet);
}
Cele dou ă aplicații au fost implementate ca module separate și apoi integrate pentru a funcționa
ca un tot unitar. În acest capitol am pre zentat numai anumite părți din aplicații, dintre cele mai
semnificative. Rezult ele funcționării celor două aplicații împreună sunt prezentate în capitolul
următor.

46
7 Rezultate

Figură 7.1 Fereastra principal ă a aplicației
Figura 7.1 prezintă interfața grafică cu care utilizatorul interacționează. Aceasta este formată
din două taburi, IPv4 și IPv6. By default, în momentul deschiderii aplicației, va fi afișat tabul IPv4.

Figură 7.2 Câmpurile cu date de intrare
În figura 7.2, sunt prezentate câmpurile ce necesită informații preluate de la utilizator,
informații ce vor fi apoi trimise serviciului web, iar pe baza lor se vor calcula subrețelele.

Florentina Băcioiu Rezultate
47 În continuare, est e prezentată un posibil set de date de intrare valide, introduse de utilizator.
Adresa de rețea de început pentru realizarea subnetizării este 192.168.0.0, iar prefixul ales este /24.
Acesta reprezintă porțiunea de rețea din adresa dată, iar restul biților sunt destinați porțiunii de host.
În imagine , numărul de subrețele selectat este cel default, adică 1. Așadar, există o singură celulă
editabilă, în care se pot scrie numărul de hosturi dorite (63 în acest exemplu) și descrierea
corespunzătoare subrețelei , respectiv “Departament IT”.

Figură 7.3 Exemplu de date valide de intrare
În exemplul următor, utilizatorul a selectat trei subrețele pentru a fi subnetizate. Pentru
Departamentul IT sunt necesare 63 hostu ri, pentru Departamentul HR este nevoie de o subrețea cu
120 hosturi, iar pentru cel de Contabilitate se cer 81 hosturi. Este de observat faptul că utilizatorul
nu este constrâns să introducă numărul de hosturi într -o anumită ordine, deși algoritmul de
subnetizare necesită acest lucru. Totuși, serviciul web se va ocupa de aceasta.

Figură 7.4 Exemplu de date cu trei subrețele cerute
În urma apăsării butonului “Calculeaz ă”, datele de intrare sunt trimise către web service, care
le va prelucra și va trimite răspunsul în format JSON. În figura 7.5 este prezentată structura
răspunsului JSON și informațiilor transmise către clientul Java.

Florentina Băcioiu Rezultate
48
Figură 7.5 Răspunsul servic iului web în format JSON

Figură 7.6 Rețelele subnetizate afișate în interfața grafică

49
8 Concluzii

Proiectarea și implementarea aplicației pentru subnetizare au respectat cerințele stabilite
inițial, astfel încât obiectivele propuse au fost îndeplinite. Aplicația realizează subnetizarea
rețelelor, pornind de la o adresă de rețea dată de utilizator. Aceasta oferă posibilitatea alegerii
numărului de subrețele dorite și a hosturilor necesare fiecăreia, în timp ce majoritatea
calculatoarelor de subnetizare existente în acest moment pe piață au în vedere numai calcularea
unei singure subrețele, sau unui număr mai mare de subrețele, însă cu un subnet mask fix.
“Aplica ție pentru subnetizare ” vine în ajutorul administratorilor de rețea, răspunzând
nevoilor acestora de a realiza subnetizarea pentru întreaga rețea, ce este împărțită, în majoritatea
cazurilor, în mai multe subneturi. Așadar, se câștigă timp și este mai comod și elegant să se
calculeze subneturile printr -o singură apăsare pe buton.
De asemenea, sistemul tine cont de Variable Length Subnet Mask (VLSM ), tehnică ce
asigură divizarea spațiului de adrese în subneturi de diferite dimensiuni, pornind de la o adresă
data. Această adres ă este, de multe ori, achiziționată de la un Internet Service Provider (ISP) de
către organizațiile medii și mari, iar costul ei este direct proporțional cu spatial de adrese disponibil.
Așadar, se dorește alocarea ip -urilor într -un mod convenabil, care să fie suficiente pentru asignarea
fiecărui device din subrețele, dar care să facă și economie de adrese, lucru realizabil cu ajutorul
sistemului implementat în această lucrare.
Sistemul este alcătuit dintr -un serviciu web și un client de tip aplicație Desktop, iar
avantajul acestei alegeri este faptul că serviciul web poate fi reutilizat. Așadar, în ceea ce privește
dezvoltările viitoare, se poate lua în considerare implementarea unui client de tip aplicație mobilă
realizată în Android. Din moment ce serviciul web realizat conține funcționalitatea de calcul a
subnetizării, iar logica acesteia nu mai trebuie efectuată , va fi necesară numai realizarea unei
interfețe responsive pentr u telefonul mobil.
În ceea ce privește sistemul deja implementat, acesta ar putea fi transformat într -o aplicație
extinsă de calcule specializate pentru domeniul rețelelor de calculatoare, cât și pentru
managementul informațiilor esențiale despre rețele. Desigur, acest lucru implică și o atenție sporită

Florentina Băcioiu Concluzii
50 părții de securitate, atât a serviciului web, cât și a clienților care îl apelează. De asemenea, ar putea
fi necesară o bază de date pentru stocarea informațiilor.

51
9 Bibli ografie
1. BIRĂESCU, IOANA DANIELA. Bazele rețelelor de calculatoare. 2009.
2. [Interactiv] [Citat: 18 June 2015.] http://shannon.etc.upt.ro/laboratoare/pc/luc6/2_Nivelul_2.htm.
3. [Interactiv] http://www.learncisco.net/courses/ccna/part -1-internetworking/introduction.html.
4. Cisco Netcad. [Interactiv] [Citat: 5 May 2015.] http://static -course –
assets.s3.amazonaws.com/IntroNet50ENU/module1/index.html#1.2.2.1.
5. Cisco Netcad. [Interactiv] [Citat: 12 May 2015.] http://static -course –
assets.s3.amazonaws.com/IntroNet50ENU/module1/index.html#1.2.2.1.
6. Cisco Netcad. [Interactiv] [Citat: 12 May 2015.] http://static -course –
assets.s3.amazonaws.com/IntroNet50ENU/module1/index.html#1.1.2.4.
7. Halberg, Bru ce A. și traducere: Mănăstireanu, M. Rețele de calculatoare.Ghidul începătorului.
s.l. : Rosseti Educational, 2006.
8. Cisco Netcad. [Interactiv] [Citat: 16 May 2015.] http://static -course –
assets.s3.amazonaws.com/IntroNet50ENU/module1/index.html#1.1.2.2.
9. Cisco Netcad. [Interactiv] [Citat: 19 May 2015.] http://static -course –
assets.s3.amazonaws.com/IntroNet50ENU/module4/index.html#4.3.1.2.
10. [Interactiv] [Citat: 21 May 2015.] http://www.hardwaresecrets.com/article/433.
11. Cisco Netcad. [Interactiv] [Cit at: 25 May 2015.] https://static -course –
assets.s3.amazonaws.com/RSE50ENU/module7/index.html#7.1.1.1.
12. Cisco Netcad. [Interactiv] [Citat: 25 May 2015.] https://static -course –
assets.s3.amazonaws.com/RSE50ENU/module7/index.html#7.1.4.1.
13. Cisco Netcad. [Interactiv] [Citat: 25 May 2015.] https://static -course –
assets.s3.amazonaws.com/RSE50ENU/module1/index.html#1.2.1.4.
14. Cisco Netcad. [Interactiv] [Citat: 27 May 2015.] 31 Days Before Your CCNA Exam, Second
Edition, Allan Johnson, Cisco Press.
15. Cisco N etcad. [Interactiv] [Citat: 28 May 2015.] http://static -course –
assets.s3.amazonaws.com/IntroNet50ENU/module6/index.html#6.1.4.3.
16. elf.cs.pub.ro. [Interactiv] [Citat: 30 June 2015.] http://elf.cs.pub.ro/rl/2011 -2012/lab/03/home.
17. Ioniță, Anca Daniela. Modelarea UML in ingineria sistemelor de programe. s.l. : ALL. ISBN: 973 –
571-463-9 .

Florentina Băcioiu Bibliografie
52 18. —. acs.curs.pub.ro. [Interactiv] [Citat: 21 March 2015.]
http://acs.curs.pub.ro/2014/pluginfile.php/6981/mod_resource/content/1/Curs%202%20ISP%20201
4.pdf.
19. Oracle Java Documentation. [Interactiv] [Citat: 28 June 2015.]
https://docs.oracle.com/javase/tutorial/getStarted/intro/definition.html.
20. Telecom Academy. [Interactiv] [Citat: 28 June 2015.] http://telacad.ro/cursant/main.
21. jaxenter.com. [Interactiv] [Citat : 28 June 2015.] http://jaxenter.com/wp –
content/uploads/2013/03/javafx.1.png.
22. Oracle Java Documentation. [Interactiv] [Citat: 28 June 2015.]
http://docs.oracle.com/javase/8/javafx/get -started -tutorial/jfx -overview.htm#JFXST784.
23. Nagel, Christian, Gl ynn, Jay and Skinner, Morgan. Professional C# 5.0 and .NET 4.5.1.
Indianapolis : John Wiley & Sons, Inc, 2014. 978 -1-118-83303 -2.
24. aspitalia.com. [Interactiv] [Citat: 28 June 2015.] http://www.aspitalia.com/focuson/1305/Speciale –
Visual -Studio -2013 -.NET -Framework -4.5.1 -One-ASP.NET.aspx.
25. Microsoft Visual Studio. [Interactiv] [Citat: 28 June 2015.] https://www.visualstudio.com/vs –
2015 -product -editions.
26. Baltopoulos, Ioannis G. Introduction to Web Services. [Presentation] Geneva, Switzerland :
Imperia l College London, Department of Computer Science, 2005.
27. Dalling, Tom. www.tomdalling.com. [Online] [Cited: June 30, 2015.]
http://www.tomdalling.com/blog/software -design/model -view -controller -explained/.
28. developer.chrome.com. [Interactiv] [Citat: 3 0 June 2015.]
https://developer.chrome.com/apps/app_frameworks.