Aplicații paralele și distribuite

 Aplicatii paralele
 Dezvoltarea algoritmilor paraleli
 Performanțele algoritmilor paraleli
 Aplicații distribuite
 Modelul funcțional al aplicațiilor distribuite: modelul MVC (Model View Controler)
 Modele arhitecturale ale aplicațiilor distribuite:
 Modelul client-server: two-tier, three-thier
 Servicii și servere în sistemele distribuite
 Sistemul Web – protocolul HTTP
 Sisteme peer-to-peer – protocolul BitTorrent

Prof. Felicia Ionescu Aplicatii paralele si distribuite 1

 Aplicații paralele și distribuite
 Calcul (procesare) concurentă – mai multe sarcini de calcul (task-uri) care se
executa concurent pe mai multe procesoare într-un sistem paralel sau distribuit:
 Calcul paralel (aplicatie paralela) - constă dintr-o singura aplicatie intens
computationala, partitionata in mai multe sarcini de calcul (task-uri) care se executa
concurent într-un sistem paralel sau distribuit (curs Calcul paralel, anul IV, INF)
 Calcul distribuit (aplicatie distribuita) - se refera la executia concurenta a mai multor
componente (programe, sarcini de calcul - task-uri) inerent distribuite in unitati distincte
ale unui sistem distribuit, care pot colabora și exploata resurse comune
 Algoritmi concurenti:
 Algoritmi paraleli – algoritmi care descriu aplicatii paralele
 Algoritmi distribuiti – algoritmi care descriu aplicatii distribuite
 Programare concurentă:
 Programare paralelă – programe care implementează algoritmi paraleli
 Programare distribuită – programe care implementează aplicatii distribuite
 Convergenta (intrepătrunderea) notiunilor paralel-distribuit:
 Aplicatiile paralele se pot desfasura atat in calculatoare (sisteme) paralele cat si in
sisteme distribuite
 Aplicatiile distribuite pot include task-uri intens computationale (aplica ții paralele)
 În sistemele paralele și distribuite se execută calculul de inaltă performanta - HPC
(High Performance Computing), stocarea și prelucrarea volumelor mari de date,
aplicații colaborative etc.
Prof. Felicia Ionescu Aplicatii paralele si distribuite 2
 Algoritmi paraleli
 Pentru rezolvarea unei probleme folosind concurent mai multe procesoare ale
unui sistem distribuit, se descompune problema în mai multe parţi → task-uri
 Un task este o parte a unui algoritm şi reprezintă o sarcină de calcul, compusă
din operaţii de calcul și operații de comunicare cu alte task-uri [Grama-2003]
 În fazele de analiză și proiectare a algoritmilor, se definesc task-urile (și subtask-uri ale
acestora) şi se identifică dependenţele dintre ele;
 În faza de programare, task-urile sunt implementate ca procese sau thread-uri, care se
execută pe procesoarele sistemului, comunică și se sncronizează între ele
 Definiții:
 Un algoritm secvențial este compus dintr-unul sau mai multe task-uri, care se execută
secvențial (unul după celalalt)
 Un algoritm paralel este compus din mai multe task-uri dintre care toate sau o parte
care pot fi executate concurent (simultan, în acelasi timp) pe mai multe procesoare ale
unui sistem paralel sau distribuit
 Task-urile unui algoritm secvențial se execută consecutiv, adică unul după altul,
indiferent dacă se execută pe un calculator secvențial sau într-un sistem paralel
 Un algoritm secvențial executat într-un sistem paralel sau distribuit nu foloseşte decât
un procesor al sistemului, deci nu îmbunăţeşte performanțele de execuție
 Pentru a se accelera execuţia prin folosirea concurentă a mai multor procesoare
dintr-un sistem paralel, este necesar un algoritm paralel de rezolvare a problemei
Prof. Felicia Ionescu Aplicatii paralele si distribuite 3
 Dezvoltarea algoritmilor paraleli
Dezvoltarea algoritmilor paraleli (paralelizarea algoritmilor) se poate face:
 În general, pornind de la un algoritm secvențial cunoscut
 Se poate realiza și direct, fără a utiliza un alg secv cunoscut (de la zero - from scratch)
Paralelizarea poate fi: explicită sau implicită (automată)
 Paralelizarea explicită: programatorul descompune sarcina de calcul în mai multe task-uri,
analizează dependenţele între task-uri și definește maparea task-urilor în procese
 Paralelizarea explicită manuală: programatorul scrie codul programului paralel folosind biblioteci care
oferă o interfață de progr. paralelă; de exemplu: bibl POSIX- PTHREAD, MPI, PVM etc.
 Paralelizarea explicită semi-automată: programatorul scrie codul programului în care introduce
directive de paralelizare care sunt interpret de un compilator paralel – ex: bibl OpenMP, Parallel R etc
 Paralelizarea implicită (automată) - compilatoare cu paralelizare automată analizează
programul secvenţial şi generează codul programului paralel – ex. compilatoare VFC -
Vienna Fortran Compiler, Par4all
Etapele de dezvoltare a algoritmilor paraleli: proiectarea, analiza, programarea
(implementarea), instalarea, execuția, ttestarea programelor paralele
 În etapa de proiectare se desc problema de calcul în mai multe task-uri, se identifică
depend între ele; se definesc regiunile paralele, comunicațiile și sincronizarea între task-uri
 În etapa de programare (implementare): se creează programul paralel compus din mai
multe procese sau thread-uri, folosind limbaje, biblioteci şi sisteme de dezvoltare
 Instalarea, testarea și execuția programului paralel: procesele multiple ale unui program
paralel sunt instalate și executate în sistemul paralel/distribuit țintă; se pot face măsurători
ale performanțelor de execuție paralelă
 Analiza algoritmilor paraleli:
 După faza de proiectare se estimează și se analizează performan țele estimate ale algoritmului paralel
proiectat (cât de “bun” este algoritmul: accelerarea, eficien ța etc.)
 După execuția programelor și efectuarea măsurătorilor experimentale, se analizează performan țele
obținute și se compară cu cele estimate

Prof. Felicia Ionescu Aplicatii paralele si distribuite 4

 Performanțele algoritmilor paraleli (1)
Cei mai importanți indicatori de performanță ai algoritmilor paraleli sunt:
 Timpul de execuție paralelă (TP) este timpul estimat (ca număr de operații de bază) sau
măsurat (în unități de timp) necesar completării tuturor operațiilor algoritmului
 Accelerarea paralelă S = TS / TP : raportul dintre timpul de execuție secv TS și timpul de
execuție paralelă TP – arată de câte ori este mai rapidă execuția paralelă decât de cea secv;
timpul TS se mai numește și complexitatea sau dimensiunea probl. W, deci W = TS
 Costul paralel CP = pTP : timpul total consumat de toate procesoarele utilizate
 Costul suplimentar de calcul paralel CO = CP – TS : reprezintă timpul suplimentar total,
consumat de toate procesoarele, în plus faţă de timpul necesar celui mai rapid algoritm
secvenţial cunoscut
 Eficiența E = S / p : raportul dintre accelerare și numărul de procesoare utilizate – arată
fracția medie de utilizare a procesoarelor pentru algoritmul respectiv
Proiectarea alg paraleli are ca scop optimiz unuia sau mai multor indicatori de perf
(timp minim de execuție, acc max, eficiență max) și obț. de algoritmi cost-optimali
 Un algoritm este cost optimal dacă eficiența lui nu scade (rămâne constantă sau crește)
atunci când numărul de procesoare utilizate crește
Condiția ca un algoritm să fie cost-optimal este ca dim probl (W) să aibă ca
limită asimptotică inferioară limita asimpt superioară (g) a costului supl (CO)
 Ordinul exact sau limita asimptotică inferioară h(p) a lui W în funcție de nr de
procesoare, necesară pentru ca algoritmul să fie cost-optimal se numește funcție de
izoeficiență și este o măsură a scalabilității sist paralel: W = Θ(h(p)) sau W = Ω (h(p))
 Cu cât funcția de izoeficiență h(p) este mai mică, cu atât sistemul paralel este mai scalabil,
adică sunt nec. creșteri mici ale dimens. probl (W) pentru ca eficiența să nu scadă

Prof. Felicia Ionescu Aplicatii paralele si distribuite 5

 Performanțele algoritmilor paraleli (2)
Pentru algoritmii perfect paraleli în sistemele cu memorie partajată se poate
considera un model de cost suplimentar foarte simplu, în care singura sursă de cost
supl este operația de creeare/term a thread-urilor, pentru care rezultă CO = kr p2;
Chiar și pentru acest model simplu, se estimează și se confirmă experimental că
paralelizarea este cu atât mai eficientă cu cât algoritmul are complexitate mai mare
 Din graficele de pe pag. urm. se observă că, pentru un anumit nr. de procesoare utilizate
(p), aceeași accelerare S se obține pentru valori ale lui n mult mai mari pentru alg. în O(n)
(ad. OpenMP a doi vectori) decât pt. alg. în O(n3) (înmulțirea OpenMP a două matrice)
Acest model se poate extinde și la alți algoritmi paraleli în sisteme cu memorie
partajată, în care mai intervin și alte surse de cost suplimentar (bariere de
sincronizare, excludere mutuală), dar se păstrează expresia CO= k*p2, unde k este o
const care înglobează toate aceste costuri supl - ex. reducerea paralelă OpenMP
Pentru algoritmi mai complexi, cu multiple dependențe între task-uri, în care intervin
costuri suplimentare generate de operații suplimentare, încărcarea neechilibrată a
procesoarelor, părți din sarcina de calcul care nu se pot paraleliza (legea lui
Amdahl), perf sunt, în general, mai reduse – ex. sortarea prin combinare OpenMP
În sist cu transfer de mesaje modelul de cost supl este mai complex, deoarece
intervine costul de comunicație a datelor, care depinde de dimensiunea datelor de
intrare (n), nr de procesoare (p) și caract. rețelei de comunic (tw); în general, perf
sunt mai scăzute decât în sist cu mem partajată (ex. reducerea paralelă MPI)
În execuția practică a algoritmilor mai intervin și alte surse de cost suplimentar, care
depind de caracteristicile sistemul paralel/distribuit real pe care se execută
algoritmii: comutarea proceselor/thread-urilor, accesul concurent la memorie etc.
Prof. Felicia Ionescu Aplicatii paralele si distribuite 6
 Performanțele algoritmilor paraleli (3)

Prof. Felicia Ionescu Aplicatii paralele si distribuite 7

 Aplicații distribuite
 Definiţie: O aplicaţie distribuită A este compusă dintr-o mulţime de componente
funcţionale A1, A2,…Ai,…An (n > 1) care interacţionează între ele:
 fiecare componentă are o stare internă şi execută operaţii prin care se poate modifica
starea proprie, poate fi o sarcina de lucru secventiala sau paralela si poate fi compusă
dintr-unul sau mai multe procese
 componentele Ai (1 ≤ i ≤ n) sunt entităţi autonome care pot fi asignate pe maşini
(calculatoare) diferite
 componentele Ai (1 ≤ i ≤ n) schimbă informaţii între ele prin intermediul reţelei de
comunicaţie, folosind interfețe bine precizate
 O aplicaţie distribuită implică:
 Proiectarea si executia unui algoritm distribuit si (posibil) a unor algoritmi paraleli
 Executia concurenta a componentelor distribuite pe diferite mașini (calculatoare)
conectate prin rețele de comunicație (într-un sistem distribuit)
 Toleranţă la defecte

Prof. Felicia Ionescu Aplicatii paralele si distribuite 8

 Modele de aplicaţii distribuite
 Din punct de vedere functional, aplicaţiile distribuite sunt modelate prin 3 niveluri:
 Nivelul de prezentare (view – presentation layer) – interfaţa cu utilizatorul
 Nivelul de logica aplicaţiei (controller – business layer) – execuţia algoritmilor de calcul
 Nivelul de date (model – data layer) – datele aplicaţiei stocate în baze de date
 Acest model functional se mai numește modelul MVC (Model-View-Controller)
 Din punct de vedere arhitectural, nivelurile funcționale pot fi distribuite între aplicaţii
client şi server pe două sau mai multe niveluri arhitecturale
 Modelul pe două niveluri (two-tier - client-server)
 Modele pe trei sau mai multe niveluri (three-tier, multi-tier)
 Modelul two-tier (client-server) - este cel mai simplu
 Oricare dintre nivelurile funcționale (prezentare, logica, datele) se poate împărți între
client și server
 Toate (sau o parte) din operațiile de prezentare se executa pe client
 Toate (sau o parte) din operațiile cu baza de date se executa pe server
 Majoritatea aplicaţiilor Internet respectă acest model: Web, e-mail, FTP, Telnet, Gopher

Prof. Felicia Ionescu Aplicatii paralele si distribuite 9

 Modelul two-tier client-server (1)
 Scheme de distribuire a funcţionalităţilor între client şi server:
 Cazul 1: accesarea la distanţă a datelor
 Cazul 2: prezentarea la distanţă a datelor (de ex. sistemul X Window) – client “slab”
(“thin client”)
 Cazul 3: aplicaţii distribuite de prelucrare cooperativă a datelor
 Cazul 4: accesarea la distanță a datelor (cu posibile replicări) – client “gras” (“fat client”)

Prof. Felicia Ionescu Aplicatii paralele si distribuite 10

 Modelul two-tier client-server (2)
 Modelul client-server two-tier poate fi folosit pentru aplicaţii simple cu:
 cerinţe de prelucrare (execuţie) reduse
 date stocate în baze de date centalizate
 dimensiunea bazei de date staţionară
 număr de clienţi aproximativ constant
 Dacă cerinţele de execuţie cresc, se pot folosi clienţi puternici (“fat clients”) care
să preia majoritatea sarcinilor de execuţie (cazul 4)
 Dar clienţii puternici prezintă dezavantaje:
 Cerinţa de a se executa pe maşini performante
 Inabilitate de a se adapta la schimbări ale execuţiei algoritmilor (dacă se modifică
algoritmul, trebuie reinstalaţi toţi clienţii)
 Inabilitate de a accesa baze de date multiple
 SOLUŢIA  modelul three-tier sau multi-tier

Prof. Felicia Ionescu Aplicatii paralele si distribuite 11

 Modelul three-tier
 Permite o mai bună distribuire și separare a sarcinilor de calcul
 Se pot efectua modificări într-unul din niveluri, fără ca celelalte niveluri să fie afectate;
de ex. poate fi modificat un client, fără să fie afectată baza de date
 Nivelul de mijloc (intermediar - middle tier) are rol și de client şi de server
Prezentare Logica aplicaţiei Baza de date

Nivel Nivel de mijloc Nivel server

client Server de aplicaţie de date

Prof. Felicia Ionescu Aplicatii paralele si distribuite 12

 Modelul multi-tier
 Modelul multi-tier
 Conține mai multe
niveluri de mijloc
(intermediare)
 Fiecare nivel
intermediar este atât
client cât și server

Prof. Felicia Ionescu Aplicatii paralele si distribuite 13

 Sistemul Web
 World Wide Web (Web) este un sistem distribuit global, bazat pe reprezentarea
informațiilor în format hipertext, compus dintr-o rețea de servere și clienți care se
execută în Internet, în care utilizatorii conversează, caută, descarcă informații etc.
 Web-ul nu este sinonim cu Internet-ul, ci o modalitate de utilizare a acestuia; Internet-ul
reprezintă infrastructura (rețea de rețele de calculatoare) în care se execută Web-ul
 Reprezentarea informațiilor în hipertext (limbajul HTML – HyperText Markup Language)
permite parcurgerea nelineară a documentelor, prin înlănțuirea acestora, ceea permite
trecerea de la un document la altul, conform dorinței utilizatorului
 Informațiile în sistemul Web sunt memorate și publicate în locații numite Web sites,
identificate prin adrese URL (Uniform Resource Locator)
 Serverele Web sunt programe care se execută în locații Web (Web sites), publică
documente (pagini Web) și răspund cererilor clienților Web (browser-e Web)
 Un server Web primește cereri de la clienți (browsere Web) în protocol HTTP (HyperText
Transfer Protocol) și răspunde acestora trimițându-le documentele cerute
 Ex de servere Web: Apache (Tomcat), IIS (Internet Information Service – pt Windows)
 Browser-ele Web sunt clienții din sist Web; acestea trimit o cerere către un server
Web la o adresă exprimată printr-un URL, apoi formatează și afișează doc. primit
 Există numeroase browser-e: Mozilla Firefox, Microsoft Internet Explorer (Windows),
Crome (de la Google), Opera etc.
 Aplicațiile Web reprezintă extensii dinamice ale serverelor Web; se pot clasifica
în aplicații Web orientate pe prezentare (prin care se generează pagini Web
interactive cu conținut dinamic, ca răspuns la cererile clientilor) și orientate pe
servicii (servicii Web)
Prof. Felicia Ionescu Aplicatii paralele si distribuite 14
 Protocolul HTTP (1)
 Protocolul HTTP (Hypertext Transfer Protocol) este un protocol de comunica ție
bazat pe TCP/IP, utilizat pentru transferul datelor (documente în diferite formate:
HTML, imagini, rezultate ale interog[rilor etc.) în Web
 Arhitectura aplicațiilor care folosesc HTTP este în modelul client-server:
 Un client HTTP este un program (Web Browser sau alt program) care transmite
mesaje de cerere (request) către un server HTTP
 Un server HTTP este un program (Web server cum sunt: Apache Web Server,
Internet Information Server IIS, etc.) care acceptă conexiuni de la clien ți, cărora
le returnează mesaje de răspuns (response)
 Caracteristicile de bază ale HPPT:
 HTTP este protocol fără conexiune (connectionless): clien ții se deconectează de la sever
după trimiterea cererii, a șteptând răspunsul; serverul prelucrează cererea și restabile ște
conexiunea cu clientul pentru a trimite răspunsul
 HTTP este independent de formatul datelor tranmise, atâta timp cât și clientul și serverul
știu cum să prelucreze con ținutul primit, prin parametrul MIME-type
 HTTP este protocol fără stare (stateless): nici clientul nici serverul nu păstrează informa ții
de la o cerere la alta
 Versiuni:
 HTTP/1.0 – deschide o nouă conexiune pentru fiecare transfer
 HTTP/1.1 – conexiunea poate fi utilizată pentru mai mult de un transfer

Prof. Felicia Ionescu Aplicatii paralele si distribuite 15

 Protocolul HTTP (2)
 Protocolul HTTP folosește formatul URI (Uniform Resource Identifier) pentru a
specifica adresa resursei accesate; formatul URI poate fi scris:
URI = "http:" "//" host [ ":" port ] [ path [ "?" query ]]
unde: host este adresa serverului, portul implicit este 80 (dacă nu este specificat)
path este calea către resursa în server, query este partea de interogare
Exemplu: Cererea HTTP: http://www.oreily.com/index.html
Se transmite către server ca un mesaj de forma:
GET /index.html HTTP/1.1
Host: www.oreilly.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12)...
Accept:text/xml,application/xml,application/xhtml+xml,text/html...
Accept-Language: us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-15,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Mesajul conține:
 Prima linie cu numele metodei (GET), calea (path) și versiunea HTTP
 A doua linie conține adresa host-ului (Host)
 Urmează 8 headere: Connection este header general, restul sunt header-e request

Prof. Felicia Ionescu Aplicatii paralele si distribuite 16

 Protocolul HTTP (3)
 Un mesaj HTTP de cerere (request) este compus din următoarele părți:
 Linia de start, care conține metoda HTTP, identificatorul resursei (Request-URI) și
versiunea HTTP
 Zero sau mai multe header-e (generale, de cerere sau de entitate), fiecare pe o linie
terminată cu CRLF
 O linie goală (terminată cu CRLF), semnificând terminarea header-elor
 Opțional, corpul mesajului HTTP (message-body, entity-body sau documentul)
 Request-URI conține:
 Calea resursei în server (path)
 Interogarea (query) adresata resursei
 Metodele unei cereri pot fi:
 GET – este utilizată pentru găsirea unei informații folosind un URI dat
 HEAD – la fel ca GET, dar se cere numai secțiunea de header-e, nu și corpul mesajului
 POST – este utilizată pentru transmiterea de date către server; de exemplu un fi șier de
încărcat pe server sau un formular (form) cu date ale clientului
 PUT – înlocuiește valoarea unei resurse cu un nou conținut, transmis în cerere
 DELETE – sterge resursa adresata pe server prin URI-ul dat
 CONNECT – stabileste un tunel catre serverul cu adresa din URI-ul dat
 OPTIONS – descrierea opțiunilor de comunica'ie cu resursa adresată prin URI-ul dat
 TRACE – testeaza conexiunea loop-back
Prof. Felicia Ionescu Aplicatii paralele si distribuite 17
 Protocolul HTTP (4)
 Header-ele pot de diferite categorii:
 Heder-e generale
 Header-e de cerere
 Header-e de răspuns
 Header-e de entitate – conțin informații despre documentul conținut în mesaj
(entity-body) sau, dacă acesta este absent, despre resursa identificată
 Corpul mesajului (message body sau entity body) este o parte opțională a unui
mesaj HTTP și, dacă este prezent, conține:
 Pentru mesaj HTTP Request: datele transmise odată cu cererea, de exemplu date de
încărcat (upload) pe server
 Pentru mesaj HTTP Response: datele de răspuns ale serverului, cel mai frecvent un
document HTML pe care browser-ul îl afișează
 Dacă este prezent corpul mesajului, atunci headere-le Content-Type și
Content-Length specifică informații privind corpul mesajului (tipul de date și numărul
de octeți – lungimea)
 Interogarea (query) poate fi inclusă în Request-URI (pentru GET) sau în
message-body (pentru POST, PUT)
 URL-encoding: adresele URL pot folosi numai setul ASCII de caractere; toate
celelalte caractere sunt nesigure și se codează cu caracterul % urmat de două cifre
hexazecimale; de exemplu: spațiu se codează %20; semnul : se codează cu %3A ;
slash / se codează cu %2F etc

Prof. Felicia Ionescu Aplicatii paralele si distribuite 18

 Protocolul HTTP (5)
 Un mesaj de răspuns HTTP (HTTP response) este compus din:
 O linie de stare conținând versiunea HTTP, codul numeric al stării și semnifica ția codului
 Zero sau mai multe header-e (generale, de răspuns sau de entitate), fiecare pe o linie
terminată cu CRLF
 O linie goală (terminată cu CRLF), semnificând terminarea header-elor
 Opțional, corpul mesajului (message body)
 Semnificația codului returnat: 200- OK, 3xx – Redirection, 4xx- Client Error etc.
 Header-e de răspuns:
 Conțin diferite informații: data calendaristică, serverul care a prelucrat cererea etc.
 Cel mai imporant header dintr-un mesaj de răspuns este Content-Type care
specifică tipul media al corpului mesajului (documentului), ceea ce permite
clientului să știe ce să facă cu documentul respectiv
 Cele mai comune tipuri media (MIME-type) sunt:
 Text (text/plain, text/html)
 Date structurate (application/xml, application/json)
 Imagini (image/jpeg, image/png)

Prof. Felicia Ionescu Aplicatii paralele si distribuite 19

 Protocolul HTTP (6)
 Răspunsul serverului din exemplul dat la cererea HTTP GET cu URI
http://www.oreilly.com/index.html

HTTP/1.1 200 OK
Date: Fri, 17 Nov 2006 15:36:32 GMT
Server: Apache
Last-Modified: Fri, 17 Nov 2006 09:05:32 GMT
Etag: "7359b7-a7fa-455d8264
Accept-Ranges: bytes
Content-Length: 43302
Content-Type: text/html
X-Cache: MISS from www.oreilly.com
Keep-Alive: timeout=15, max=1000
Connection: Keep-Alive

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"
lang="en">
<head> ...
<title>oreilly.com -- Welcome to O'Reilly Media, Inc.</title>
...

Prof. Felicia Ionescu Aplicatii paralele si distribuite 20

 Sisteme peer-to-peer – protocolul BitTorrent
 BitTorrent este un protocol pentru transmiterea și partajarea fișierelor, folosit
pentru distribuirea volumelor mari de date în Internet
 BitTorrent este cel mai utilizat protocol de transfer în Internet, cu un volum de
trafic estimat la 40-70% din întreg traficul Internet
 Protoculul BitTorrent permite descărcarea unui fișier folosind un group (swarm –
roi) de servere în locul unuia singur, ceea ce îl face eficient și în rețele cu lărgime
de bandă scăzută
 Fișierele transmise prin protocolul BitTorrent se segmentează în piese de
dimensiuni care pot varia între 32 kB și 16 MB
 Un utilizator care dorește să încarce (upload) un fișier, creează un mic fișier de
descriere a acestuia (file.torrent) pe care îl distribuie prin mijloace convenționale
(e-mail, portaluri web etc.) și apoi face disponibil fișierul într-un nod (numit tracker)
care devine transmițătorul inițial (însămânțătorul - initial seeder)
 Un utilizator care are fișierul torrent se poate conecta la un nod transmițător (ca
pereche – peer), și primește una câte una piesele fișierului dorit; de îndată ce are
o piesă complet descărcată, orice participant (peer) poate deveni seeder
 În felul acesta se creează un grup (roi) de servere care participă (peer-to-peer) la
transmiterea unui fișier între mai mulți participanți
 Pentru a participa în grup, un utilizator se conectează folosind un client BitTorrent,
care “știe” să aplice acest protocol; exită mai multe astfel de programe client
(uTorrent, Transmmision BitTorrent Client etc.)
Prof. Felicia Ionescu Aplicatii paralele si distribuite 21
 Protocolul BitTorrent
 Fiecare piesă a fișierului de transmis este protejată printr-o cheie critografică care
se obține printr-un algoritm de hashing și este memorată în fișierul torrent
 La recepție, clientul BitTorrent calculează (cu același algoritm) cheia hash a piesei
recepționate și o compară cu cea memorată în fișierul torrent; chiar și cea mai
mică modificare a conținutului unei piese are ca și consecință modificarea cheii
hash și permite depistarea modificării (intenționate sau accidentale) a piesei
 În mod tipic, piesele se recepționează într-o ordine ne-secvențială și sunt
reordonate după recepție de către clientul BitTorrent
 Eficiența schimbului de date depinde foarte mult de politica folosită de clienti
pentru a determina cărui solicitant (peer) să-i transmită o anumită piesă
 În general, clienții preferă să transmită acelor participanți care, la rândul lor le transmit
piesele pe care le au disp, dar o astfel de politică limitează posibilitatea de alăturare și
altor participanți în grup, dat fiind că noii veniti încă nu au nimic de transmis
 De aceea fiecare client rezervă o parte a largimii de bandă pe care transferă pentru a
deservi, în mod aleator, noi veniți, care pot deveni apoi buni participanți în grup
 Torentele pot fi implicate în piraterie în Internet (distribuirea neautorizată de
materiale protejate prin copywright), dar nu este singura lor utilizare; de exemplu:
 CBC (Canada Broadcasting Corp) folosește BitTorrent pentru distribuirea unor transmisii
 Facebook și Twitter folosesc BitTorrent pentru transm. actualizărilor (updates) serverelor
 Amazon S3 (Simple Store Service) oferă o interfață construită pe baza prot. BitTorrent

Prof. Felicia Ionescu Aplicatii paralele si distribuite 22



Prof. Felicia Ionescu Aplicatii paralele si distribuite 23