Dan Schrager

FONDUL SOCIAL EUROPEAN
Investeşte în oameni!
Programul Operaţional Sectorial pentru Dezvoltarea Resurselor Umane 2007 – 2013
Proiect POSDRU/107/1.5/S/76813 – Burse doctorale: investitii in cercetare-inovare-dezvoltare pentru viitor (DocInvest)
UNIVERSITATEA POLITEHNICA DIN BUCUREŞTI

Facultatea de Automatică şi Calculatoare
Departamentul Calculatoare
TEZĂ DE DOCTORAT
REZUMAT
Transferul rapid, în paralel, al datelor în reţele WAN
Fast Parallel Data Streaming Transfers in WAN Networks
Autor: Ing. Dan Schrager
Conducător de doctorat: Prof.dr.ing. Valentin Cristea
Bucureşti, 2013
CUPRINS
1. INTRODUCERE .................................................................................................................4
1.1. MOTIVAREA CERCETĂRII .................................................................................... 4
1.2. OBIECTIVELE CERCETĂRII .................................................................................. 5
2. STUDIU COMPARATIV AL TEHNICILOR ŞI APLICAŢIILOR DE TRANSFER DE
DATE ÎN REŢEA .......................................................................................................................7
2.1. TRANSFERURILE DE DATE ŞI MEDIUL GRID ................................................... 7
2.1.1. Serviciul FTS ....................................................................................................... 7
2.2. SISTEMUL PROTOCOALELOR DE COMUNICAŢIE ÎN REŢEA ....................... 8
2.2.1. Protocolul TCP..................................................................................................... 8
2.2.2. Performanţele TCP............................................................................................... 9
2.2.3. Performanţa conexiunilor TCP multiple .............................................................. 9
2.3. DIVERSE IMPLEMENTĂRI ALE TCP .................................................................. 10
2.3.1. TCP Sack ........................................................................................................... 10
2.3.2. TCP Vegas ......................................................................................................... 10
2.3.3. HighSpeed TCP ................................................................................................. 11
2.3.4. Fast TCP............................................................................................................. 11
2.3.5. MPTCP .............................................................................................................. 11
2.3.6. MulTCP.............................................................................................................. 12
2.4. MANAGEMENTUL ACTIV AL COZILOR DIN RUTERE (AQM) ..................... 12
2.4.1. Algoritmul RED ................................................................................................. 12
2.4.2. Algoritmul BLUE .............................................................................................. 12
2.4.3. Algoritmul SFB .................................................................................................. 13
2.5. PROTOCOALE NON-TCP ...................................................................................... 13
2.5.1. XCP .................................................................................................................... 13
2.5.2. SCTP .................................................................................................................. 13
2.5.3. DCCP ................................................................................................................. 14
2.6. APLICAŢII DE TRANSFER RAPID....................................................................... 14
2.6.1. XFTP .................................................................................................................. 14
2.6.2. Psockets.............................................................................................................. 15
2.6.3. Globus GridFTP ................................................................................................. 15
2.6.4. RBUDP .............................................................................................................. 15
2.6.5. SABUL .............................................................................................................. 16
2.6.6. GridFTP Overlay ............................................................................................... 16
2.7. SUMAR..................................................................................................................... 16
2
3. ARHITECTURA SISTEMULUI DE TRANSFER DE DATE ........................................17

3.1. ARHITECTURĂ ....................................................................................................... 17
3.2. CAPABILITĂŢI CLIENT-SERVER SUPLIMENTARE ........................................ 19
3.3. MODELUL COZILOR DE TIP FORK-JOIN .......................................................... 19
3.3.1. Performanţa sistemului ...................................................................................... 20
3.4. SUMAR..................................................................................................................... 21
4. ALGORITMI EFICIENŢI DE TRANSMISIE PARALELĂ ...........................................21
4.1. CARACTERISTICI ALE ALGORITMILOR DE TRANSFER .............................. 21
4.1.1. Importanţa suportului pentru multi-path ............................................................ 21
4.1.2. Specificaţii pentru multi-path ............................................................................ 22
4.2. FAZELE ALGORITMULUI DE TRANSFER......................................................... 22
4.2.1. Transmisia fără ponderare.................................................................................. 22
4.2.2. Controlul transmisiei cu ponderare ................................................................... 23
4.2.3. Strategii de optimizare a ponderării transmisiei ................................................ 25
4.2.4. Pseudocodul algoritmului de transmisie (cu ponderare opţională) .................... 25
4.3. SUMAR..................................................................................................................... 26
5. METODOLOGIE DE VALIDARE ŞI REZULTATE EXPERIMENTALE....................27
5.1. CONSIDERAŢII METODOLOGICE ...................................................................... 27
5.1.1. Platforme de test ................................................................................................ 28
5.2. PERFORMANŢA ÎN FLUX CONTINUU ŞI CEA ORIENTATĂ FIŞIER ............ 29
5.2.1. Cazul transferurilor de directoare ...................................................................... 30
5.3. PERFORMANŢELE TRANSMISIEI ÎN FLUX CONTINUU ................................ 30
5.3.1. Experimente în regim static ............................................................................... 31
5.3.2. Experimente în regim dinamic ........................................................................... 33
5.3.3. Cazul transferurilor de tip split-TCP.................................................................. 34
5.4. ANALIZA REZULTATELOR EXPERIMENTALE ............................................... 35
5.4.1. Consideraţii cantitative ...................................................................................... 35
5.4.2. Analiza regimului ponderat şi neponderat ......................................................... 35
5.5. SUMAR..................................................................................................................... 37
6. CONCLUZII ŞI DIRECŢII DE CERCETARE VIITOARE ............................................37
6.1. CONTRIBUŢIILE TEZEI ........................................................................................ 38
6.2. DISEMINAREA CERCETĂRII ............................................................................... 39
6.3. DIRECŢII DE CERCETARE VIITOARE ............................................................... 39
BIBLIOGRAFIE - SELECTIVĂ ..............................................................................................40
3
1. INTRODUCERE
În contextul actual al dezvoltării grid şi cloud computing cercetarea ştiinţifică se

bazează pe partajarea datelor şi a resurselor distribuite între domenii administrative separate
de distanţe geografice considerabile. De aceea, capacitatea de a transfera cantitaţi mari de
date în reţele de tip WAN este o cerinţa importantă pentru aplicaţii de tip HPC.
De exemplu, experimentul Atlas [1] transferă 10 PB de date anual. Cercetarea de la
Virgo [2] stocheaza sute de TB de date anual, transferate in reţele cu latenţa scăzută. În alte
domenii ştiinţifice, ca de pildă vizualizarea in timp real a datelor instrumentate de la distantă
sau realizarea de transmisii video sau videoconferinţe de definiţie foarte înaltă, reţele optice
de cercetare (e.g. GLIF [3] sau OptIPuter [4]) sunt folosite pentru transferuri în flux de date
cu viteză superioară.
TCP [5] este protocolul cel mai folosit în Internet deoarece asigură un serviciu
important şi anume transferul garantat al datelor sub formă de fluxuri continui de octeţi. TCP
nu impune restricţii de implementare, aşa încît funcţionează atît in reţele obişnuite (Ethernet)
cît şi avînd HBDP şi BER mari. Succesul TCP se datorează algoritmilor săi de control al
congestiei în reţea. Aceştia controlează faza iniţială a transmisiei, de slow-start, în care
capacitatea reţelei este evaluată rapid prin dublarea ferestrei de congestie (cwnd) la fiecare
RTT, cît şi faza următoare, de creştere liniară a cwnd cu cîte un pachet la fiecare RTT.
Conform studiilor din [6], performanţa TCP este invers proporţională cu RTT şi
dependentă într-o măsură foarte mare de rata de pierdere a pachetelor, ceea ce face dificilă
utilizarea întregii laţimi de banda disponibile în reţele moderne (e.g. cu tehnologie bazată pe
fibră optică).
Optimizarea transferurilor unor volume de date foarte mari în scopul atingerii unei
eficienţe mărite a condus la crearea de noi variaţii ale TCP (e.g. SACK [7], Vegas [8],
HighSpeed [9], FAST [10], MulTCP [11], MPTCP [12]) care adresează unele dintre
limitările sale iniţiale, cauzate de algoritmul său de evitare a congestiei in reţea.
Controlul congestiei la nivelul infrastructurii de reţea a condus la elaborarea unor
algoritmi care să asigure managementul activ al cozilor din rutere (e.g. RED [13], BLUE
[14], SFB [15]) în sensul înlocuirii simplei abandonări a pachetelor (drop-tail) cu marcarea
acestora în mod probabilistic înainte ca să fie depaşită capacitatea maximă a cozilor.
Dintre protocoalele de transport non-TCP, XCP [16] necesită modificări ale ruterelor
din reţea, iar alte protocoale, precum SCTP [17] sau DCCP [18] au fost dezvoltate pentru
uzul aplicaţiilor pentru care transmisia garantată a TCP nu este neapărat necesară (e.g.
telefonie mobilă, multimedia, jocuri video interactive).
La nivel de aplicaţie există numeroase soluţii de îmbunătaţire a performanţelor
transferurilor în reţea. Dintre acestea, unele folosesc UDP pentru transferul propriu-zis al
datelor şi TCP pentru canalul de control (e.g. RBUDP [19], SABUL [20]). Altele se bazează
pe implementarea paralelismului la nivel de reţea prin folosirea de conexiuni TCP multiple în
acelaşi timp (e.g. XFTP [21], Psockets [22], GridFTP [23]). O altă tehnică (split-TCP, în
[24]) este aceea a împărţirii unei conexiuni TCP în două sau mai multe segmente în serie,
fiecare optimizînd local parametrul RTT, dat fiind faptul că fluxurile TCP cu RTT mare sunt
dezavantajate în competiţia contra conexiunilor cu RTT mic [25].
1.1. MOTIVAREA CERCETĂRII
Aşa cum rezultă din studiul prezentat în capitolul 2, soluţiile de transfer existente
prezintă atît avantaje cît şi un număr de limitări intrinsece.
4
Schimbările aduse protocolului TCP au de obicei o durată de standardizare

îndelungată. În cazul TCP Sack au trecut opt ani între momentul cînd a fost propus pentru
prima dată şi adoptarea în forma sa definitivă. MPTCP este dezvoltat în continuare încă din
anul 2009 sub forma unei implementări în nucleul sistemului de operare Linux. Astfel de
abordări, pe lîngă durata mare de definitivare, au evidente dificultăţi de diseminare în reţea
pentru că necesită actualizări ale sistemului de operare.
Coabitarea diverselor variante îmbunătaţite ale TCP cu TCP clasic este şi ea uneori
problematică. De exemplu, TCP Vegas, din cauză că are o abordare conservativă în utilizarea
resurselor comune din reţea [26], este mai rar folosit în Internet. Alte soluţii, precum
HighSpeed TCP sau FAST TCP, din cauza agresivităţii în reţelele HBDP, produc o partajare
neechitabilă a resurselor necesare aplicaţiilor care folosesc conexiuni TCP (paralele) în medii
grid pentru transferul unor seturi de date mari.
Protocoalele de tip non-TCP precum XCP necesită modificări ale felului în care
congestia din reţea este suportată la nivel de rutere intermediare şi schimbări de protocol atît
la nivel de transmiţător cît şi de receptor. Asemenea cerinţe sunt dificil de implementat şi
costisitoare, constituind un obstacol pentru diseminare, cu excepţia reţelelor ştiinţifice
dedicate sau capabile de QoS. Alte protocoale noi, ca SCTP şi DCCP, necesită aplicaţii noi
sau cel puţin rescrise pentru a fi utilizate. În plus, maşinile intermediare din reţea (e.g. NAT)
au dificultăţi de acceptare a protocoalelor noi care pot fi astfel blocate.
Cu toate că au o şansă mai bună de diseminare, bibliotecile de funcţii de reţea
trebuiesc să fie incluse în noi aplicaţii, iar aplicaţiile de reţea deja existente sunt uneori prea
specializate şi de obicei orientate doar către transferul de fişiere de dimensiuni cunoscute.
Existenţa limitărilor menţionate mai sus a motivat cercetarea din această dizertaţie cu
scopul de a se prezenta o abordare care să aducă o serie de avantaje principale, şi anume:
 O arhitectură flexibilă:
o capabilă de transferul rapid, în paralel, al datelor în modul streaming la nivel de
octet.
o care extinde paradigma programării cu pipes în reţea ce interconectează la distanţă
procese de tip producător /consumator de date.
 Decuplarea algoritmilor de transfer rapid de detaliile de acces la date, care să permită atît
transferul fişierelor obişnuite cît şi al datelor de dimensiuni nedeterminate.
 Reutilizarea aplicaţiilor de acces la sisteme de stocare specializate sau a comenzilor de
sistem locale, eliminîndu-se dependenţa de aplicaţii de transfer monolitice.
 Suport pentru multi-path şi split-TCP la nivel de aplicaţie.
 Uşurinţă a diseminării - prin implementare sub forma unei aplicaţii de reţea de tip client-
server complete, gata de utilizat în producţia în medii grid.
1.2. OBIECTIVELE CERCETĂRII
Conform tezei mele:

Este posibil şi recomandabil a se realiza o implementare a paradigmei de
programare cu pipes extinsă de la nivelul local al sistemului de operare la
nivel de Internet, asigurîndu-se totodată transferul rapid, în paralel, al
datelor în reţea.
Obiectivele cercetării care vor valida această teză sunt cuprinse în următorii paşi:
Realizarea unui studiu comparativ al principalelor tehnici şi aplicaţii de transfer a
datelor în retea care reflectă stadiul actual al cunoaşterii în domeniu (cuprins în capitolul 2).
Acesta motivează interesul existent pentru transferul rapid al datelor prin prezentarea unui
studiu de caz (proiectul Atlas) în contextul dezvoltării continui a mediilor grid.
5
La nivelul de transport al protocoalelor de reţea se prezintă protocolul TCP, deoarece

este cel mai folosit la transmiterea sigură a datelor în reţele variate, împreună cu
performanţele sale determinate de algoritmii săi de control al congestiei, precum şi metoda de
mărire a ratei sale de transfer globale prin folosirea de conexiuni multiple în paralel.
Interesul pentru TCP justifică includerea analizei unei serii de variante ale sale care
vizează îmbunătăţirea algoritmilor de congestie. Controlul congestiei în reţea este studiat şi la
nivelul ruterelor prin includerea de algoritmi de management activ al cozilor din rutere. O
altă clasă de protocoale de transport non-TCP este de asemenea studiată, acestea răspunzînd
mai bine nevoilor unor aplicaţii specifice (e.g. VoIP, multimedia, jocuri video). Grupul larg al
aplicaţiilor şi bibliotecilor de funcţii de transfer în reţea al fişierelor este de asemenea
prezentat.
Crearea unei arhitecturi care să suporte un sistem de prelucrare paralelă a datelor
de transferat în reţea, bazat pe modelul teoretic al cozilor sincronizate de tip fork-join,
combinat cu utilizarea interfeţei de comunicare interprocesuale de tip pipe de la nivelul local
al sistemului de operare (descrisă in capitolul 3). Această arhitectură implementează
conceptul general de pipes extinse cu o transmisie rapidă bazată pe multiple conexiuni TCP
simultane în reţea. Problema transmisiei în flux continuu (streaming) sincronizat este
rezolvată prin folosirea memoriei partajate între un proces (părinte) de control şi multiple
procese (fii), cîte unul per conexiune, ce asigură paralelismul în reţea.
Arhitectura adoptată realizează separarea între detaliile accesului la date (de exemplu,
memorate pe sisteme de stocare specializate) şi algoritmii de transfer eficient a datelor în
reţea, asigurîndu-se astfel un control centralizat al ratei de transmisie. De asemenea, o serie
de caracteristici, importante pentru modelul de tip client-server de acces la date, sunt
suportate, referitoare, între altele, la aspecte legate de autentificarea utilizatorilor, securitatea
controlului şi opţional cifrarea datelor, traversarea cu uşurinţă a maşinilor intermediare de tip
firewall sau NAT.
Conceperea unor algoritmi eficienţi de transmisie paralelă prin streaming la nivel de
octet (prezentaţi în capitolul 4). Eficienţa se referă la eliminarea completă a reordonărilor la
recepţie şi la o soluţie de alocare statică a memoriei (partajate) folosită la alocarea zonelor
tampon de transmisie în reţea. De asemenea, graţie controlului centralizat al transmisiei, este
posibil şi suportul la nivel de aplicaţie pentru multi-path, important pentru maşinile cu adrese
multiple de IP, multihomed, interconectate pe căi multiple în reţea (e.g. aflate în centre de
calcul moderne cu redundanţă de reţea sau smartphones). Astfel, a fost proiectat un algoritm
de transmisie cu ponderare capabil să optimizeze rata de transfer globală atît în condiţii
statice cît şi dinamice de trafic, de debit inegal per conexiune TCP, conceput ca un sistem
automat de control proporţional şi integral (PI).
Elaborarea unei metodologii de validare experimentală a flexibilităţii arhitecturii
adoptate şi a eficienţei şi consistenţei algoritmilor de transfer în reţele cu rată de transmisie
de până la 8 Gbps (conţinută în capitolul 5). Aceasta se bazează pe folosirea unei aplicaţii
client-server complete, ce implementează arhitectura şi algoritmii corespunzători. Analiza
rezultatelor experimentale demonstrează că transferul prin streaming este la fel de rapid ca
transferul de tip file striping, permiţîndu-se efectuarea cu simplitate a unei varietaţi de
operaţii de transmisie altfel dificil de paralelizat la nivel de reţea, de exemplu sincronizări de
directoare (cu tar), transferuri de regiuni de fişiere sau reluarea transferurilor din punctul de
întrerupere (cu dd), transferuri de tip split-TCP, etc, indiferent daca dimensiunea datelor de
transmis este cunoscută aprioric sau nu. Corectitudinea algoritmului ponderat a fost de
asemenea evaluată în raport de abilitatea sa de a utiliza lăţimea de banda disponibilă a
transmisiei pe căi paralele, în mod cumulativ.
Prezentarea concluziilor tezei (în capitolul 6). Se concluzionează asupra contribuţiilor
acestei teze şi se sugerează direcţii de cercetare viitoare în domeniul transferului de date în
reţea.
6
2. STUDIU COMPARATIV AL TEHNICILOR ŞI APLICAŢIILOR DE

TRANSFER DE DATE ÎN REŢEA
2.1. TRANSFERURILE DE DATE ŞI MEDIUL GRID
Mediile grid sunt importante în contextul realizării de transferuri de date pe scară

largă. Definit în general ca un sistem distribuit de elemente de calcul (CE) şi elemente de
stocare a datelor (SE) conectate de o reţea de viteză mare, conceptul de grid provine din
extinderea în mod natural a grupurilor (cluster) de calculatoare existente la începutul anilor
'90 (e.g. SHIFT de la CERN) în ideea de a avea cluster-e conectate via Internet.
Arhitectura grid a fost definită pentru prima oară în [27] în anul 1998, unde accesul la
o vastă putere de calcul este asemănat cu uşurinţa accesului la reţeaua electrică (power grid)
sau la o reţea de telefonie. În practică, utilizatorii care rulează aplicaţii în grid interacţionează
cu un software intermediar (middleware) care controlează accesul şi buna funcţionare a
mediilor grid. Unul din primii furnizori de middleware a fost proiectul GLOBUS care
distribuie un set complet de componenete (toolkit) GT4 [28]. Alte grupuri redistribuie acest
middleware pentru a uşura operaţiile de instalare a noi locaţii grid (e.g. cu PACMAN [29]).
Unul din proiectele cele mai reprezentative pentru fizica particulelor este Atlas. Atlas
este un detector de particule general care face parte din LHC (Large Hadron Collider) de la
CERN. În condiţii de funcţionare normală, detectorul produce date pe o scară foarte largă, de
la 80 TB/s la frecvenţa de 40 Mhz (date primare) şi pînă la numai 400 MB/s la frecvenţa de
200 Hz, în urma mai multor filtrări succesive [30]. Împreună cu datele obţinute prin simulare
Monte Carlo şi cele necesare calibrării detectorului, totalul datelor produse anual de Atlas
este de ordinul ~10 PB.
Achiziţionarea unui astfel de volum de date necesită un model ierarhic, structurat pe
mai multe nivele (tiers), bazat pe grid, care să aducă împreună resursele instituţiilor
participante (~175 în anul 2011), separate de distanţe geografice mari, dar interconectate cu
reţele rapide. Verificarea modelului s-a făcut prin executarea mai multor teste (challenges) -
dintre care Atlas DC1 este unul la care am contribuit personal [31] [32].
Problema managementului datelor este rezolvată la nivel de grid middleware cu
ajutorul unor servicii de transfer generalizate care în particular folosesc aplicaţii performante
pentru transmisia datelor la distantă (e.g. GridFTP, prezentat pe larg în secţiunea 2.6.3). Un
astfel de serviciu este prezentat in secţiunea următoare.
2.1.1. Serviciul FTS
FTS [33] (File Transfer Service) este un serviciu de transfer al datelor definit de
arhitectura gLite, actualmente parte a EMI [34] (European Middleware Initiative). Serviciul
este responsabil de transferul seturilor de date între diversele centre, permiţînd controlul
resurselor de reţea în scopul efectuării de transferuri de fişiere cu locaţie precizată la nivel
fizic şi opţional de fişiere logice (LFN, Logical File Name) catalogabile.
Din punct de vedere conceptual, FTS controlează un set de canale configurabile între
nodurile din reţea. Fiecare canal este unidirecţional aşa încît este posibil ca instanţe diferite
ale FTS să controleze fiecare dintre cele două sensuri ale unui canal.
Arhitectura FTS este modulară avînd o serie de componente extensibile. Astfel,
clienţii (aplicaţii care efectuează transferuri de date) accesează via protocolul SOAP un
serviciu Web de tip Tomcat (compliant WSDL), putîndu-se construi clienţi diferiţi. Acesta
interfaţează o bază de date (MySQL sau Oracle) care conţine schema FTS. Iar agenţii FTS
efectuează transferurile de fişiere propriu-zise (via canalele FTS) în acord cu setările din baza
de date.
7
In concluzie, din prezentarea de mai sus a mediilor grid din punct de vedere al
complexităţii şi amplorii transferurilor de date necesare, rezultă aşadar importanţa adoptării
unor mecanisme perfecţionate de transmisie care să permită transferarea cu eficienţă, într-un
timp cît mai scurt, a datelor în reţea.
2.2. SISTEMUL PROTOCOALELOR DE COMUNICAŢIE ÎN REŢEA
Protocoalele standardizează felul în care datele sunt reprezentate atunci cînd sunt
transferate intre maşinile conectate la o reţea [35]. Ele adresează probleme complexe legate
de erori hardware, congestie în reţea, pierdere ori întîrziere de pachete (termen folosit în sens
larg, ca unitate primară de transfer în reţea), date corupte, date duplicate sau sosite într-o
ordine aleatorie, etc.
Din punct de vedere logic, protocoalele sunt implementate pe mai multe nivele
suprapuse de software, fiecare tratînd probleme specifice. Comunicaţia la fiecare nivel de
protocol se bazează pe principiul că obiectele transmise sunt identice cu acelea primite. În
practică, tehnica folosită de protocoalele de comunicaţie se bazează pe multiplexare şi
demultiplexare.
Funcţionalitatea inclusă la fiecare nivel face obiectul unor modele standardizate.
Astfel, modelul ISO/OSI [36] este format din 7 nivele (Physical Hardware, Data Link,
Network, Transport, Session, Presentation, Application). Cercetarea în domeniul TCP/IP a
condus la un al doilea model, mai simplu dar mai des folosit, conţinînd doar 4 nivele logice
(plus nivelul hardware), şi anume: Aplicaţie, Transport, Internet şi Interfaţa de reţea. Între
cele două modele există diferenţe conceptuale. Astfel, modelul ISO implementează detecţia
erorilor de transmisie la fiecare nivel, în mod independent, în timp ce modelul TCP/IP asigură
fiabilitatea de tip end-to-end, cu majoritatea verificărilor grupate într-un singur nivel, cel de
transport.
2.2.1. Protocolul TCP
TCP [5], [37] este protocolul care standardizează felul în care se realizează transmisia
fiabilă a fluxurilor de date în Internet, fiind o parte constitutiva a modelului TCP/IP. TCP
asigură o conexiune bidirecţională, permiţînd schimbul eficient de date indiferent de
caracteristicile reţelelor de transport. Deoarece TCP este implementat de obicei la nivelul
sistemului de operare, el poate fi folosit de orice aplicaţie printr-o interfaţă de acces uniformă.
TCP divide datele în segmente (înglobate în datagrame IP) şi menţine o fereastră de
transmisie specializată, la nivel de octet. Dimensiunea ferestrei variază în timp, funcţie de
spaţiul disponibil la recepţie, informarea făcîndu-se prin segmentele de confirmare. În acest
mod este controlat în mod eficient debitul transmisiei.
Confirmările TCP sunt de tip cumulativ, în sensul că precizează următorul octet pe
care receptorul se aşteaptă să-l primească. Această strategie nu ţine seama de ordinea, posibil
aleatorie, a segmentelor primite şi poate conduce la o retransmisie ineficientă, fie excesivă,
fie redusă la retransmisia simplă, ceea ce anulează avantajul ferestrei de transmisie. O
posibilă corecţie este algoritmul de retransmisie rapidă, care declanşează retransmisia înainte
de timeout a segmentului următor unuia pentru care s-au primit deja multiple confirmări
(patru cel puţin).
Mecanismele de transmisie precedente nu sunt suficiente deoarece nu se ţine cont de
congestia în reţea, cauzată de maşini intermediare (gateways) ce nu pot face faţă traficului
impus. De aceea TCP consideră că majoritatea pierderilor sunt datorate congestiei şi
introduce un nou parametru şi anume fereastra de congestie (cwnd), independent de
capacitatea existentă la recepţie, care limitează superior ferestra de transmisie admisibilă.
Algoritmul AIMD înjumătăţeşte fereastra de congestie (pîna la unu) la pierderea unui
8
segment (pachet) şi în acelaşi timp măreşte exponenţial (dublează) timeout-ul segmentelor de

transmis. La încheierea congestiei, ori la deschiderea unei noi conexiuni, pentru a se evita
instabilitatea cauzată de mărirea prea rapidă a ratei de transmisie, se aplică algoritmul Slow-
Start, aditiv, care setează fereastra de congestie la un segment şi apoi o măreşte cu cîte un
segment pentru fiecare confirmare primită. Această creştere este limitată de parametrul
ssthresh (valoare de prag, de obicei jumătate din valoarea iniţială), care odată atins
marchează intrarea în faza de evitare a congestiei, în care incrementarea se face numai dacă
toate segmentele din fereastră au fost deja confirmate.
2.2.2. Performanţele TCP
Deşi capabil să se adapteze unui domeniu larg de tipuri de reţele, TCP atinge
un debit de transfer maxim determinat de algoritmii săi de evitare a congestiei. Conform
studiilor din [6] acesta (notat BW) este aproximat de ecuaţia:
(2.1)
unde p este rata de pierdere a pachetelor, iar C este o constantă dependentă de parametrii
algoritmului TCP.
Conform studiului din [38], influenţa termenilor din ecuaţia (2.1) este diferită. Astfel,
MSS are valorile cele mai statice pentru o conexiune TCP dată, fiind calculabil în baza MTU
(care reprezintă dimensiunea maximă a unui pachet transmisibil fără fragmentare pe parcurs).
Valorile obişnuite ale MTU sunt egale cu 1500 octeţi, dar există şi cazuri de reţele Ethernet
cu valori de pînă la 9000 octeţi (jumbo frame), ceea ce poate mări BW de pînă la 6 ori.
RTT este mai dinamic decît MSS dar mai puţin variabil decît p, fiind limitat inferior
de viteza de propagare a luminii şi putînd creşte din cauza prezenţei ruterelor intermediare
sau din cauza efectelor produse de prelucrările specifice din cozile de aşteptare sau congestia
din reţea.
Rata de pierdere a pachetelor p are variabilitatea cea mai mare, avînd două cauze
principale de producere: congestia normală din reţea şi un set complex de cauze aleatorii,
independente de traficul din reţea, reprezentînd erori hardware şi software se pot produce la
nivel de calculatoare sau la nivelul ruterelor din reţea.
În afara erorilor mai sus mentionaţe, există o rată de eroare intrinsecă fiecărui mediu
de transmisie – BER, cu valori maxime admisibile standardizate de IEEE pentru fiecare tip de
reţea. De exemplu, într-o reţea cu BW = 1 Gbps, MSS = 1500, RTT = 100 ms, C = 1.2 (TCP
clasic), substituind în ecuaţia (2.1), rezultă un p de ordinul , ceea ce corespunde unui
BER de ordinul , dificil de atins chiar şi pentru fibre optice.
Rezultă deci că efectele produse de p din motive aleatorii, nedatorate congestiei, sunt
în măsură să afecteze în mod negativ performanţele conexiunilor TCP individuale, ţinîndu-se
cont de caracteristicile algoritmului AIMD care înjumătăţeşte cwnd şi deci micşorează rata de
transfer atunci cînd pachetele sunt pierdute.
2.2.3. Performanţa conexiunilor TCP multiple
O soluţie la problema descrisă mai sus o reprezintă folosirea mai multor conexiuni
TCP simultane, soluţie adoptată de mai multe din aplicaţiile de transfer descrise în secţiunea
nr. 2.4.
În mod colectiv, N conexiuni în paralel se comportă asemănător unei conexiuni cu
MSS de N ori mai mare, cel puţin în faza de slow-start. Aceasta rezultă din însumarea
ecuaţiei (2.1) pentru fiecare din conexiunile i participante, cu . Considerînd
parametrii MSS şi RTT aceiaşi pentru fiecare dintre conexiunile realizate între aceleaşi două
calculatoare şi estimînd că în absenţa congestiei chiar şi rata de pierdere a pachetelor este
9
distribuită uniform între conexiuni (fenomen favorizat de metodele moderne de management

al cozilor din rutere, exemplificate în secţiunea 2.5), deci , rata de transfer globală
devine:
(2.2)
Alt mod de a interpreta ecuaţia (2.2) se referă la competiţia între conexiuni cu RTT
mare, specifice reţelelor HBDP şi conexiunile locale cu RTT mic; simplificînd cu N atît la
numărător cît şi la numitor, devine evident că ansamblul conexiunilor TCP paralele se
comportă ca avînd un RTT de N ori mai mic.
Segmente care nu sunt pierdute din cauza congestiei, dar care tot produc diminuarea
ratei de transfer, deoarece semnalizează înjumătaţirea cwnd, nu afectează toate cele N
conexiuni în acelaşi timp, aşa încît scăderea debitului este mai mică în cazul transmisiei
paralele.
Din experimentele efectuate în [38] mai rezultă că rata globală de transfer creşte liniar
cu numărul de conexiuni TCP simultane, pînă cînd se atinge un regim de saturaţie, cînd
reţeaua nu mai are capacitate disponibilă de transfer. Mărirea mai departe a numărului de
conexiuni poate produce efecte nedorite, de diminuare a debitului total din cauza congestiei
excesive.
2.3. DIVERSE IMPLEMENTĂRI ALE TCP
Cercetarea în acest domeniu a vizat îmbunătăţirea mecanismelor de retransmisie şi de

control a congestiei în TCP clasic, reprezentat în principal de TCP Tahoe (implementat de
BSD 4.3 [39] în 1988) şi TCP Reno (care cuprinde în plus şi algoritmul Fast Recovery
implementat de BSD 4.3 în anul 1990). Schimbările privesc de obicei pe transmiţătorul
datelor, pentru a se păstra compatibilitatea cu TCP. Implementările sunt realizate în sistemul
de operare şi de aceea prezintă dificultăţi de diseminare.
2.3.1. TCP Sack
TCP SACK este descris în forma sa definitivă în RFC 2018 [7] din anul 1996, însă a
fost propus pentru prima dată încă din anul 1988 în RFC 1072 [40]. Mecanismul de
confirmări selective al SACK este o strategie care corectează comportamentul TCP în cazul
pierderilor multiple de segmente de date.
Din punct de vedere tehnic sunt folosite două opţiuni TCP noi, Sack-Permitted şi Sack
propriu-zisă.
Comportamentul TCP SACK în cazul congestiei este dezbatut în [41], rezultînd că
sporeşte într-adevăr semnificativ performanţele transferului de date, în special în cazul
reţelelor WAN foarte încărcate sau chiar şi în absenţa congestiei, în situaţia mai multor erori
grupate.
2.3.2. TCP Vegas
TCP Vegas [8] este o implementare alternativă a TCP care nu îi schimbă specificaţiile
generale, avînd avantajul de a modifica numai modul în care datele sunt transmise (nu şi
recepţia, ca în cazul TCP SACK). Comparativ cu TCP Reno, debitul transferurilor de date
este mărit cu 37% pînă la 71%, iar retransmisia segmentelor pierdute este redusă cu o cincime
şi chiar pînă la o jumătate.
10
TCP Vegas foloseşte trei tehnici distincte pentru a obţine rezultatele menţionate mai
sus: un nou mecanism de efectuare a retransmisiilor mai devreme, la momentul oportun; un
mecanism de detectare proactivă a congestiei; un mecanism Slow-Start modificat.
Cu toate că TCP Vegas a demonstrat o viteză superioară şi stabilă, fără a afecta latenţa
sau a concura inechitabil alte conexiuni, este mai rar folosit în Internet, tocmai din cauza
abordării conservative în ceea ce priveşte utilizarea resurselor de reţea, aşa cum se arată şi în
studiul comparativ [26] cu TCP Reno.
2.3.3. HighSpeed TCP
HighSpeed TCP [9] este o modificare experimentală a mecanismului de control a

congestiei al TCP pentru conexiuni cu fereastră de congestie mare. Obiectivul principal este
obţinerea unui debit de transfer mărit în condiţiile în care rata de pierdere a pachetelor nu este
excepţional de redusă.
Tehnica folosită de HighSpeed TCP presupune modificarea formulei de calcul a cwnd
funcţie de rata de pierdere a pachetelor ( ) aşa cum rezultă din algoritmul
AIMD al TCP. Se folosesc trei parametri, Low_Window, High_Window şi High_P, precum şi
Low_P care conduc la o formulă logaritmică, în cazul unui debit estimat
de 10 Gbps, cu valori tabelate din motive practice.
Din punct de vedere al performanţei, HighSpeed TCP este superior lui TCP
Reno/Tahoe insă inferior lui TCP Vegas. Aşa cum se arată în [42], aceasta se datorează lipsei
unei estimări corecte a debitului disponibil (folosită de Vegas), ceea ce produce mărirea sau
micşorarea cwnd într-un mod arbitrar în cazul HighSpeed TCP.
2.3.4. Fast TCP
FAST TCP [10] este o implementare actualmente comerciala a unui mecanism de

congestie bazat pe estimarea întîrzierilor din cozile de aşteptare (din rutere) de pe parcursul
unei conexiuni TCP. Se adresează reţelelor de tip HBDP cu latenţă ridicată şi are ca obiectiv
atenuarea dificultaţilor pe care TCP le are la funcţionarea în reţele cu cwnd mare.
Tehnica folosită de FAST TCP îmbină estimarea continuă a întîrzierilor din cozi cu
detecţia pierderilor de pachete în vederea asigurării unui număr constant de pachete în cozile
din reţea. Spre deosebire de TCP Vegas, care ajustează rata de transfer în paşi egali, FAST
TCP realizează ajustări variabile ale ratei de transfer, mai mari, respectiv mai mici,
proporţional cu distanţa faţă de situaţia de echilibru.
Comparativ cu TCP Vegas, HighSpeed TCP şi TCP Reno, FAST TCP este superior în
ceea ce priveşte debitul atins, concurenţa echitabilă, stabilitatea şi viteza de reacţie la
schimbarea condiţiilor de trafic în reţea. Cu toate acestea şi FAST TCP este presupus a
prezenta ca şi TCP Vegas aceleaşi probleme de coabitare în reţele în care TCP Reno este
prevalent.
2.3.5. MPTCP
MPTCP (Multipath TCP) este o extensie a TCP capabilă să folosească simultan trasee
diferite în reţea pentru interconectarea calculatoarelor cu interfeţe de reţea multiple şi adrese
de reţea (IP) diferite. La ora actuală (2013) este prezentat într-un document IETF [12]
avansat, fiind dezvoltat încă din anul 2009.
Tehnica folosită de MPTCP este transparentă pentru aplicaţiile de reţea deoarece este
implementat sub forma unei noi biblioteci de sockets la nivelul sistemului de operare. Aşa
cum se arată în [43] protocolul MPTCP este implementat cu ajutorul a noi opţiuni TCP în
scopul asigurării traversării nestînjenite a unei diversităţi de maşini intermediare din reţea, de
11
tip NAT, PEP, firewall, IDS, etc. Transmisia datelor se poate face pe oricare dintre
conexiunile participante, iar implementarea minimizează necesarul de memorie şi procesare
prin aplicarea unor strategii de retransmisie oportunistică, de penalizare a căilor mai lente şi
de autoconfigurare a mărimii buffer-elor de reţea.
Performanţa MPTCP a fost studiată în laborator în medii wireless cu aplicaţii folosind
protocolul HTTP, obţinîndu-se rezultate bune comparativ cu TCP Reno în [44].
2.3.6. MulTCP
MulTCP [11] reprezintă o modificare a algoritmului de control a congestiei care

conduce la simularea unei colecţii de mai multe conexiuni virtuale TCP. Acest comportament
este benefic şi în cazul reţelelor de tip HBDP.
Tehnica folosită de MulTCP se bazează pe introducerea unui factor N în scopul
obţinerii unui debit de transfer echivalent cu acela a N conexiuni simultane. Parametrizarea
funcţie de N se aplică la toate fazele prin care trece o conexiune TCP, prin modificarea
corespunzătoare a parametrilor cwnd si ssthresh.
Performanţele atinse de MulTCP au fost estimate prin simulare şi rezultatele
demonstrează echivalenţa sa cu N conexiuni paralele de tip TCP SACK.
2.4. MANAGEMENTUL ACTIV AL COZILOR DIN RUTERE (AQM)
O altă metodă de a controla congestia din reţea este implicarea activă a ruterelor în
controlul acesteia. În mod tradiţional, ruterele folosesc o politică de tip drop-tail în
managementul cozilor de pachete asociate cu interfeţele de reţea deservite, în sensul că
pachetele care depăşesc capacitatea existentă a cozilor sunt abandonate.
În locul acestei politici se pot aplica scheme bazate pe marcarea sau abandonarea
pachetelor în mod probabilistic, înainte de a se atige capacitatea maximă a cozilor. Marcarea
pachetelor se face cu ajutorul unei extensii a protocolului IP (sau TCP), ECN, standardizată
de RFC 3168 [45], în care un bit CE (Congestion Experienced) este actualizat în antetul
pachetelor IP atunci cînd congestia iminentă este detectată de rutere.
2.4.1. Algoritmul RED
Algoritmul RED [13] (Random Early Detection) aplică o politică de detecţie a

congestiei incipiente prin notificarea mai devreme a surselor, ceea ce le permite să-şi reducă
rata de transmisie înainte ca să fie depăşite cozile din reţea şi pachetele să fie pierdute.
Tehnica folosită de RED se bazează pe păstrarea unei lungimi medii a cozii calculată
dupa o formulă EWMA (Exponential Weighted Moving Average) ce este utilizată pentru
detectarea congestiei.
Algoritmul are ca obiective principale minimizarea pierderii pachetelor şi a
întîrzierilor din rutere, evitarea sincronizării globale a surselor, menţinerea unui grad mare de
utilizare a debitului disponibil şi evitarea dezavantajării surselor cu transmisie bruscă.
2.4.2. Algoritmul BLUE
Algoritmul BLUE [14] foloseşte o schemă de management automatizată, care nu

necesită parametri de reglaj şi care funcţionează mai bine decit RED chiar şi cu tampoane
mai mici.
Tehnica BLUE se bazează în mod direct pe pierderea pachetelor şi pe gradul de
utilizare al reţelei, spre deosebire de schemele bazate pe gradul de ocupare al cozilor din
12
rutere. Algoritmul BLUE păstrează o unică probabilitate, , utilizată pentru marcarea (sau
abandonarea) pachetelor.
Algoritmul BLUE a fost comparat prin simulare cu RED (în [14]) obţinîndu-se
performanţe superioare sau cel puţin egale sub toate aspectele.
2.4.3. Algoritmul SFB
Algoritmul SFB [15] (Stochastic Fair BLUE) reprezintă o variantă îmbunătăţită a

algoritmului BLUE prin adăugarea unui filtru Bloom [46] care permite controlul echităţii
utilizării reţelei de către fluxurile individuale folosindu-se resurse de stare puţine şi zone
tampon minime.
Filtrul Bloom este utilizat la contabilizarea distribuţiei pachetelor la N x L containere
(bins) cu ajutorul a L functii hash aplicate antetelor IP ale acestora.
Ca urmare, un flux care ignoră starea congestiei din reţea produce convergenţa rapidă
a la valoarea 1 pentru toate cele L containere unde a fost distribuit, în timp ce o conexiune
TCP are şansa de a fi distribuită şi în alte containere cu probabilitate mai mică decit 1.
2.5. PROTOCOALE NON-TCP
Protocoalele non-TCP îşi aduc o contribuţie pozitivă la rezolvarea problemelor legate

de îmbunătăţirea răspunsului TCP la congestie sau la rezolvarea unor probleme specifice
nivelului de transport din reţea. În general însă, prezintă şi ele dificultăţi de diseminare, aşa
cum se va vedea în continuare.
2.5.1. XCP
XCP [16] (eXplicit Control Protocol) este un protocol nou care controlează congestia
mai bine decît protocolul TCP şi asigură eficienţa, echitatea şi stabilitatea transmisiei în reţele
HBDP. Acest protocol introduce şi un concept nou, acela al separării controlului eficienţei de
cel al echităţii transmisiei.
Noul protocol generalizează bitul ECN de la nivelul ruterelor prin includerea unui
antet de congestie în fiecare pachet transmis în reţea. Ruterele calculează eficienţa în baza
unei formule MIMD cu (doi) parametri invarianţi la numărul şi debitul relativ al fluxurilor
participante, determinaţi pe criterii de asigurare a stabilităţii. Controlul echităţii este bazat pe
un algoritm AIMD, cu excesul de debit disponibil împărţit egal între fluxuri, iar scăderea
debitului fiecărui flux este proporţională cu debitul său curent; în plus se asigură convergenţa
rapidă prin tehnica de realocare/amestecare a debitului între fluxuri.
Comparativ cu TCP, XCP este stabil şi eficient independent de debit, RTT şi numărul
de fluxuri. Rezultatele simulării demonstrează că XCP este mai performat decît TCP atît în
reţele normale cît şi mai ales HBDP. XCP are şanse de răspîndire doar în reţele dedicate
cercetării ştiinţifice şi mai puţin în Internet în general şi aceasta din cauza costurilor de
implementare prohibitive.
2.5.2. SCTP
SCTP [17] (Stream Control Transmission Protocol) este un protocol definit pentru
prima oară în RFC 2960 [47] în anul 2000 şi definitivat în anul 2007 prin RFC 4960 [48]. El
a fost dezvoltat iniţial cu scopul de a se permite funcţionarea protocoalelor de
telecomunicaţie, în special pentru aplicaţii VoIP, de transfer a vocii în reţele IP. Îmbină
caracteristici ale UDP, în sensul că este orientat spre transmisia de mesaje (chunks), dar se
aseamănă şi cu TCP prin aceea că transmisia mesajelor este garantată.
13
Comparativ cu TCP, SCTP foloseşte un algoritm de retransmisie bazat pe confirmări

selective, asemănător lui TCP SACK, iar mecanismele sale de mărire a cwnd în funcţie de
numărul de octeţi recepţionaţi (nu funcţie de numărul de confirmări, precum la TCP) îi
îmbunătăţesc precizia controlului congestiei [49].
În experimentele iniţiale SCTP a demonstrat o bună coabitare cu traficul TCP fără a
se inregistra degradări ale performanţelor din cauza noului protocol. În [50] sunt evaluate prin
simulare strategii de retransmisie ale SCTP-CMT [51], concluzionîndu-se că este important
să se ţină seama de rata de pierdere a mesajelor în alegerea căii optime pentru retransmisie.
Cu toate acestea şi protocolul SCTP are probleme de diseminare din cauză că necesită
aplicaţii noi sau cel puţin rescrise care să-l poată folosi şi fiindcă traficul SCTP poate fi blocat
de maşini intermediare de tip NAT.
2.5.3. DCCP
DCCP [18] (Datagram Congestion Control Protocol) este un protocol nou la nivelul
de transport al reţelei, de tip unicast, care asigură controlul congestiei dar fără o transmisie
garantată a datelor. A fost proiectat pentru a răspunde mai bine nevoilor unor clase de
aplicaţii specifice, de exemplu de telefonie pe Internet, de transmisie multimedia sau jocuri
video interactive. Pentru acestea retransmisiile de tip TCP sunt în majoritatea cazurilor
inadecvate, utilizatorii preferînd o transmisie la timp uneia complete.
DCCP este construit pe baza protocolului UDP căruia îi adaugă o serie de trăsături
similare cu TCP: un sistem de numerotare secvenţială a mesajelor; un mecanism de control al
conexiunilor, bazat pe conceptul de semi-conexiune; mecanisme de control a congestiei,
modularizate (e.g. CCID 2 [52], agresiv şi CCID 3 [53], adaptiv).
Performanţele DCCP au fost studiate în [54] prin compararea cu UDP şi TCP în cazul
unei aplicaţii CBR (Constant Bit Rate), rezultînd că DCCP combină o rată de pierdere a
pachetelor redusă cu o rată bună de transmitere a pachetelor importante. În raport cu SCTP,
DCCP este presupus a obţine rezultate mai bune deoarece nu este afectat de apariţia de
întîrzieri arbitrare ce pot fi cauzate de transmisia garantată a SCTP.
2.6. APLICAŢII DE TRANSFER RAPID
La nivelul aplicaţiilor de reţea există o multitudine de soluţii, bazate pe tehnici de

folosire a conexiunilor TCP în paralel, pe UDP pentru transferul datelor sau pe tehnici de
împărţire în mai multe porţiuni succesive a unei conexiuni TCP pe criterii de îmbunătăţire a
ratei de transfer globale. Diseminarea acestora este facilă deoarece avem de-a face cu
software situat în afara sistemului de operare, aspect care a stat şi la baza abordării din
această teză.
2.6.1. XFTP
XFTP [21] este o aplicaţie de tip client-server care extinde protocolul FTP descris în
RFC 959 [55] cu o implementare multisocket.
Extensia de protocol se referă numai la modul activ al FTP (comenzile MULT şi
MPRT) si este implementată prin folosirea a n conexiuni simultane, multiplexate asincron, cu
zone tampon pentru evitarea blocajelor, într-un singur proces. Fişierele transferate sunt
împărţite în m părţi egale (de cîte 8K, cu ), fiecare fiind transmisă împreună cu
numărul său de ordine printr-una din conexiunile disponibile şi apoi reordonată la sosire.
În ciuda inconvenientelor legate de folosirea unui grad mai redus de paralelism (un
singur proces) şi a necesităţii de a se efectua reordonări la recepţie, XFTP a reuşit să obţină o
14
utilizare de 90% a capacităţii unei linii T1 (via satelit, cu o viteză de pînă la 1.544 Mbps), faţă
de numai 24% în cazul FTP.
2.6.2. Psockets
PSockets [22] este o bibliotecă de funcţii scrisă în C++ care ajută aplicaţiile să obţină
o utilizare optimală a reţelei fără a trebui să ajusteze fereastra de transmisie, descrisă de RFC
1323 [56].
Tehnica folosită se bazează pe împărţirea egală a datelor într-un număr de părţi
determinat de numărul de conexiuni deschise simultan şi transmiterea acestora în mod
asincron, în paralel. Biblioteca Psockets ascunde detaliile legate de numărul de sockets
efectiv întrebuinţaţi şi felul în care datele sunt segmentate şi apoi reconstituite la recepţie. În
acest fel se elimină inconvenientul reordonării la recepţie, existent în cazul metodei folosite
de XFTP. De notat că ideea unei transmisii fără reordonare a fost adoptată de asemenea în
prezenta teză.
PSockets este uşor de folosit de către aplicaţiile interesate în obţinerea unor debite de
transfer cît mai mari deoarece oferă funcţii cu o interfaţă (API) identică (e.g. send, receive) cu
aceea a bibliotecii de reţea obişnuite (Berkeley sockets [39]).
2.6.3. Globus GridFTP
Globus GridFTP [23] este o aplicaţie client-server pentru transferul de fişiere

proiectată special pentru mediile Grid, făcînd parte din GT4. Ea răspunde principalei cerinţe
de asigurare a transferului unor seturi de date masive, sub formă de fişiere, între servere aflate
într-o reţea WAN ce acoperă distanţe geografice considerabile.
Protocolul GridFTP [57] este bazat pe FTP şi extensiile sale standardizate de IETF, pe
RFC 2228 [58] pentru securitate şi RFC 2389 [59] pentru negociere, la care se adaugă o serie
de comenzi noi şi opţiuni aferente. Ca urmare, protocolul GridFTP are capabilităţi extinse:
transfer simultan între mai multe servere, folosirea de conexiuni în paralel, transfere parţiale
de fişiere (regiuni), negociere automată a parametrilor de transfer (fereastră, tampon) şi
repornirea şi recuperarea transferurilor întrerupte de erori fatale de reţea.
Arhitectura GridFTP este modularizată, fiind compusă din module independente:
interpretorul de protocol (PI) de la nivelul serverului şi cel de client; procesul de transfer de
date DTP, format din trei module succesive, de acces la date, de procesare a datelor şi de
scriere/citire a datelor în reţea.
Comparativ cu alte servere FTP, GridFTP obţine performanţe bune atît în privinţa
vitezei de transfer cît şi a scalabilităţii în cazul servirii mai multor clienţi cvasi simultan.
2.6.4. RBUDP
RBUDP [19] (Reliable Blast UDP) este o aplicaţie de transfer a datelor în reţele de
mare capacitate, dedicate sau capabile de QoS (e.g. reţele optice). Transferul datelor propriu-
zise se face cu UDP, iar traficul de control este semnalizat cu TCP.
Astfel, într-o primă fază, datele de transferat sunt transmise cu datagrame UDP şi o
viteză specificată de utilizator, aleasă aşa încît să nu depăşească capacitatea maximă a reţelei.
Receptorul păstrează evidenţa pachetelor pierdute (sub formă de hartă de biţi, bitmap) pe care
apoi o comunică, via TCP, transmiţătorului. Acesta retransmite numai pachetele UDP
pierdute şi întreg procesul se repetă pînă la eliminarea tuturor pierderilor. Se observă aşadar
că RBUDP nu foloseşte mecanisme de control a congestiei şi nici vreun algoritm de tip slow-
start precum TCP. Totodată acesta grupează toate confirmările la încheierea secvenţei de
transmisie UDP, eliminîndu-se astfel confirmările de pe parcurs, consumatoare de timp.
15
Rezultatele experimentale demonstrează că RBUDP poate transfera cantităţi mari de

date cu viteză apropiată de capacitatea maximă de transmisie a reţelei.
2.6.5. SABUL
SABUL [20] (Simple Available Bandwidth Utilization Library) este o bibliotecă C++
disponibilă în sursă, cu funcţii de reţea pentru aplicaţii de transfer performante, în medii Grid.
Datele sunt transferate via UDP, iar controlul transmisiei se face via TCP. SABUL
implementează un algoritm de control a congestiei, funcţie de rata de transfer şi un mecanism
de transmisie sigură a datelor.
Tehnica folosită de SABUL se bazează pe un algoritm de tip AIMD de control al ratei
de transfer prin recalcularea, o dată la fiecare 10 ms, a intervalului de timp între două
transmisii consecutive de pachete de date. În plus, rata de transfer este limitată de o fereastră
virtuală de transmisie, a cărei valoare maximă trebuie să fie setată de către aplicaţie.
Comparativ cu RBUDP, SABUL obţine rezultate performante nu numai în reţele
private ci şi în cele publice, deoarece nu limitează în mod drastic capacitatea traficului TCP
de a folosi reţeaua în mod normal. Rezultatele obţinute prin simulare şi experimente în reţele
reale arată că SABUL este echitabil în raport cu alte fluxuri coexistente, în sensul atingerii
unor viteze egale de transfer, indiferent de viteza iniţială a fiecăruia.
2.6.6. GridFTP Overlay
În [24] se prezintă un număr de componente care îmbunătăţesc capacitatea de transfer

a GridFTP prin folosirea de multiple conexiuni în serie, segmentate (de tip split-TCP), în
locul unei singure conexiuni directe.
Arhitectura acestui sistem include mai multe servere de tip GT4. Astfel, un modul
Split-DSI îndeplineşte funcţia de releu de transmisie la nivelul unui server intermediar
GridFTP. Un serviciu BTC raportează debitele de transfer, înregistrate în cursul transferurilor
GridFTP obişnuite, către serviciul MDS4 [60]. În final, serviciul Split-Choice sugerează unui
client servere intermediare GridFTP prin adăugarea acestora la URL-ul iniţial al transferului.
În acest mod conectarea se face mai întîi la un server intermediar, implementîndu-se efectiv
conexiuni de tip split-TCP.
Rezultatele experimentale au arătat imbunătăţiri ale debitului global de transfer de
pînă la 500%, cu o medie de 125%, comparativ cu transferurile GridFTP directe.
2.7. SUMAR
Acest capitol a făcut o prezentare cuprinzătoare a rezultatelor cercetării în domeniul

transferului de date în reţea, desigur fără a se putea prezenta totalitatea acestora, din cauza
volumului imens existent.
În tabela 2.1 se prezintă modelul bazat pe mecanismul de pipelines rapide, alături de
tehnicile şi aplicaţiile prezentate mai sus, în raport cu principalele criterii de comparaţie care
au stat la baza alegerii soluţiei adoptate.
Din punct de vedere al capacităţii de a folosi în mod eficient căi multiple în reţea,
avînd eventual şi capacitate de transfer diferită, aplicaţia proiectată, bazată pe pipelines
extinse, se aseamănă cu MPTCP, care însă fiind implementat la nivelul sistemului de operare
(Linux), suferă, asemeni majorităţii extensiilor aduse protocolului TCP, dificultăţi de
diseminare şi standardizare.
Comparativ cu grupul de aplicaţii sau biblioteci de funcţii de transfer în reţea, care
folosesc conexiuni TCP multiple în paralel, grup din care face parte, soluţia concepută este
16
orientată către transferul în flux continuu de date (streaming) şi ca urmare nu este limitată la
transferul fişierelor de dimensiuni determinate.
Tabela 2.1. Comparaţie sinoptică între metodele de transfer în reţea
Uşurinţa Reutilizare Suport Suport Transfer

diseminării aplicaţii/comenzi pentru pentru în flux de
Multi-Path Split-TCP date
TCP Sack DA (opţiune) NU NU - -
TCP Vegas NU (kernel) NU NU - -
HighSpeed TCP NU (kernel) NU NU - -
Fast TCP NU (comercial) NU NU - -
MPTCP NU (kernel) NU DA - -
MulTCP NU NU NU - -
XCP NU (rutere) NU NU - -
SCTP NU(rescriere NU DA - -
aplicaţii)
DCCP NU(aplicaţii noi) NU NU - NU(doar
mesaje)
XFTP DA NU NU NU NU
Psockets DA (bibliotecă) - NU NU -
Globus GridFTP DA (grid) NU NU NU NU
RBUDP NU NU NU NU -
(QoS/dedicate)
SABUL DA (bibliotecă) - NU NU -
GridFTP Overlay DA NU NU DA NU
Pipelines extinse DA DA DA DA DA
(client/server)
3. ARHITECTURA SISTEMULUI DE TRANSFER DE DATE
3.1. ARHITECTURĂ
În figura 3.1 se prezintă arhitectura sistemului de streaming în paralel, cu o structură

simetrică, specifică modelului client-server de transfer în reţea. Atît la nivel de client cît şi de
server sunt prezente următoarele componente:
 un proces părinte specializat în citirea, respectiv scrierea dintr-un pipe prin care se
accesează exclusiv input-ul sau output-ul proceselor externe producătoare sau consumatoare
de date.
 un număr de N procese fii, specializate în scrierea, respectiv citirea datelor din reţea
sub formă de conexiuni TCP, cîte una per proces.
 un segment de memorie partajată între procese, care asigură sincronizarea, tratarea şi
raportarea erorilor şi care conţine şi toate zonele tampon pentru transferul datelor între pipe şi
reţea; de asemenea, conţine şi structuri de date care servesc la raportarea timpilor de
17
transmisie per proces.
Fig. 3.1. Arhitectura sistemului de streaming în paralel
Procesul părinte implementează algoritmii principali de control al transmisiei de date,

prin ponderarea numărului de octeţi alocaţi pentru scriere fiecărui proces fiu, în funcţie de
viteza sa de transmisie curentă. Procesele fii calculează şi raportează lăţimea de bandă a
transmisiei de care sunt capabili sub forma timpului, exprimat în microsecunde, necesar
golirii zonei tampon alocate.
Un model orientat spre transferul de fişiere, în care un număr de procese simultane
independente accesează atît reţeaua cît şi direct fişierul de transmis (file striping), este
comparabil cu arhitectura de tip streaming în paralel, rezultînd superioritatea celei din urmă,
pentru următoarele considerente:
 interfaţa cu sistemul de operare este de tip pipeline, ceea ce conferă generalitate în

privinţa selecţiei sursei sau a destinaţiei transferului de date. Astfel, oricare procese
producătoare sau consumatoare de date pot fi interconectate cu rapiditate şi la distanţă,
indiferent dacă sunt comenzi de sistem sau aplicaţii specializate în accesul la sistemul local
de stocare a datelor sau aplicaţii HPC care generează date în cantităţi neprecizate; modelul
bazat pe striping este limitat la accesul fişierelor de dimensiuni cunoscute.
 există o separare completă între accesul la date şi algoritmii de transmisie a acestora
cu viteza în reţea, algoritmii fiind încapsulaţi într-o aplicaţie de transfer performantă. Aceasta
reprezintă un avantaj deoarece aceeaşi aplicaţie eficientă poate fi folosită la transferul datelor
în reţea indiferent de complexitatea detaliilor de acces la date, în vreme ce aplicaţiile bazate
pe striping devin monolitice şi necesită înglobarea cunoştinţelor necesare accesului nemijlocit
la fişierele de transmis aflate eventual în sisteme de stocare nestandard (e.g. sisteme de
memorare pe bandă magnetică care presupun operaţii pregătitoare pentru acces).
 controlul transmisiei de date este centralizat şi permite întrebuinţarea eficace a căilor
multiple în reţea sau/şi de capacitate diferită (multi-path), la nivel de aplicaţie, prin adaptarea
dinamică la variaţiile ratelor de transfer individuale. Desigur că aceasta nu este posibil pentru
modelul bazat pe striping deoarece acolo procesele de transmisie în reţea sunt necorelate.
Arhitectura adoptată realizează de asemenea o combinare efectivă între modul de

comunicaţie bazat pe pipes şi transmisia paralelă a datelor în reţea ceea ce îi conferă
avantajele ambelor metode: reutilizare, eleganţă (prin adoptarea paradigmei de programare cu
pipes sub sistemul de operare Unix) şi rapiditate a transmisiei în reţea (cu multiple conexiuni
TCP simultane).
18
3.2. CAPABILITĂŢI CLIENT-SERVER SUPLIMENTARE
Avînd în vedere faptul că algoritmii de transfer consideraţi sunt incluşi într-o aplicaţie
cu arhitectură client-server, o serie de aspecte specifice au fost luate în considerare, cu scopul
de a se crea o aplicaţie robustă care să răspundă cerinţelor moderne de transfer a datelor în
reţea. Aceasta a servit, pe de o parte, aplicării unei metodologii experimentale realiste, iar pe
de altă parte a răspuns şi cerinţelor concrete ale primilor utilizatori ai acestui sistem de
transfer în medii grid. Astfel:
 Protocolul de control al transferului este de tip binar. De asemenea, este şi criptat
RSA ceea ce ii conferă un grad mare de securitate.
 Autentificarea corectă a utilizatorilor a fost extinsă cu un modul similar celui folosit
de ssh, care foloseşte aceleaşi chei publice şi private, în vederea autentificării fără
introducerea de parole, ceea ce simplifică exploatarea în regim de loturi de prelucrare, fără
intervenţie umană. Autentificarea în medii grid este de asemenea posibilă atunci cînd serverul
este iniţiat de către client la distanţă, cu o versiune a ssh capabilă de autentificare GSI (GSI-
OpenSSH [61]) sau prin utilizarea unei versiuni compilate cu un modul GSI opţional.
 Sub aspectul securităţii este de menţionat şi faptul că datele transferate pot fi la rîndul
lor cifrate, în mod opţional, prin codificare RC4.
 Traversarea facilă a reţelelor protejate de firewalls sau maşini NAT se poate face prin
conectarea tuturor conexiunilor TCP paralele de date la un singur port, aflat în regim de
ascultare. Numărul de port al destinaţiei poate fi acelaşi cu numărul portului de control al
serverului. Aceasta se realizează prin comunicarea între procese cu semnale care produc
suspendarea temporară a regimului de ascultare a serverului principal. Reordonarea corectă a
conexiunilor acceptate, independent de IP-ul (posibil local) ori portul sursă se face printr-un
schimb cifrat de mesaje.
 Parcurgerea comenzilor şi a opţiunilor din linia de comandă a clientului se face cu un
mini-interpretor. Dintre comenzile acceptate, comanda pipe avînd ca argument aplicaţia de
executat la distanţă (de către server) asigură şi suportul pentru conexiuni de tip split-TCP.
 De asemenea, interpretorul poate efectua şi selecţii cu expresii regulate ale mai multor
fişiere sau/şi subdirectoare şi poate executa în mod recursiv (şi chiar şi cu opţiunea de
excludere a fişierelor deja transferate) transmisia fisierelor dorite în modul file striping, în
mod optimizat (simultan).
 Transferul în flux continuu (streaming la nivel de octet), efectuat totodată cu o rată a
transmisiei maximizată, permite reutilizarea comenzilor Unix cu execuţie la distanţă prin
includerea în mod natural în script-uri de sistem. De exemplu, comanda dd poate fi folosită
pentru reluarea unui transfer întrerupt. Comanda tar poate fi folosită la sincronizarea rapidă a
subdirectoarelor la distanţă.
3.3. MODELUL COZILOR DE TIP FORK-JOIN
Aşa cum rezultă din arhitectura adoptată, aceasta este bazată pe modelul teoretic al
cozilor sincronizate, cunoscute şi sub numele de cozi de tip fork-join [62]. Acest model este
specific procesărilor paralele şi distribuite, de exemplu cu aplicabilitate la sisteme de discuri
de tip RAID [63], sau chiar la managementul proceselor de fabricaţie sau al accesului la
magazii industriale.
Conform literaturii matematice de specialitate din [64], modelul fork-join, poate fi
văzut ca un model simplu de cozi într-un sistem de procesare paralelă. Este format dintr-un
număr N de procesoare (servere) paralele, fiecare dispunînd de o coadă proprie locală.
Prelucrările de executat (job-uri) sunt formate din N proceduri (tasks) care sunt alocate
cozilor diferitelor procesoare, fenomen cunoscut sub numele de faza de fork. O prelucrare
19
este considerată ca fiind încheiată dacă toate procedurile componente au fost la rîndul lor
terminate, aceasta fiind aşa-zisă fază de join.
Se observă urmatoarea analogie cu modelul teoretic fork-join: datele citite de către
procesul părinte dintr-un pipeline de sistem (văzut ca un punct unic de interfaţă cu sistemul
de operare) sunt împărţite, într-o ordine prestabilită (ciclică, de tip round-robin), între cele N
procese fii, prin intermediul segmentului de memorie partajată şi al zonelor tampon conţinute,
fiecare de dimensiune maximă B, în faza de fork. Faza de join se execută în fapt la receptorul
de date, care are o structură simetrică, şi unde datele sunt recompuse, în aceeaşi ordine, din
elementele lor constitutive şi apoi părăsesc sistemul prin alt pipeline, de scriere. De notat
faptul că fiecare iteraţie a transmisiei în flux continuu reprezintă o prelucrare formată din N
proceduri individuale, de transmisie şi recepţie a datelor în reţea, care trebuie să fie
completată în întregime înainte ca urmatoarea prelucrare să fie posibilă.
3.3.1. Performanţa sistemului
Performanţele atinse de sistemul de transfer de tip fork-join sunt determinate de

timpul total scurs între momentul iniţial al fork-ului şi cel final, de join, sau, altfel zis, depind
de rata de transmisie globală R. În mod evident, aceasta depinde de ratele de transmisie ale
conexiunilor TCP individuale, corespunzătoare celor N procese fii, notate , cu .
Notînd în continuare , considerînd timpii
individuali de transfer , cu , şi şi ţinînd cont de
constrîngerile de sincronizare impuse de transmisia ordonată în flux continuu a datelor, R este
determinat de ecuaţia:
(3.1)
din care rezultă dependenţa de rata de transfer cea mai defavorabilă.

Ecuaţia (3.1) prezintă deci o problemă în cazul ratelor de transfer inegale (cazul
suportului pentru multi-path), de aceea am decis să adaptez gradul de utilizare al zonelor
tampon individuale funcţie de viteza de transfer maximă măsurată, conform formulei
ponderate:
(3.2)
Deoarece acum:
(3.3)
ecuaţia (3.1) devine:
(3.4)
ceea ce constituie o aproximare ideală a lui R ca fiind suma ratelor de transmisie individuale,
cu condiţia ca timpii de transfer individuali să fie corect măsuraţi.
Se observă aşadar că soluţia teoretică de îmbunătăţire a ratei de transfer globale care a
fost considerată pentru suportul căilor cu rată inegală (multi-path), este de tipul rutării
preferenţiale către cozile mai libere, în baza informaţiilor legate de timpii de tranziţie
individuali, folosiţi pentru a estima gradul de încărcare al fiecărei conexiuni TCP
componente.
20
3.4. SUMAR
În acest capitol am prezentat arhitectura de sistem de transfer a datelor adoptată şi am

arătat care sunt trăsăturile sale remarcabile ce o recomandă pentru efectuarea transmisiilor de
date în paralel cu rapiditate dar şi cu uşurinţă. De exemplu, generalitatea prin utilizarea de
pipes extinse, încapsularea algoritmilor de transfer, suportul centralizat pentru controlul ratei
de transfer şi transmisia multi-path la nivel de aplicaţie.
Caracteristici suplimentare, dar semnificative pentru calitatea aplicaţiei de transfer de
tip client-server implementate au fost de asemenea discutate în secţiunea 3.3, cu referire, între
altele, la autentificarea utilizatorilor, securitatea controlului şi a datelor, suportul pentru split-
TCP, traversarea uşoară a maşinilor intermediare cu rol de firewall sau NAT.
Deoarece arhitectura se bazează pe modelul cozilor de tip fork-join, o prezentare
teoretică şi o justificare a performanţelor de transfer în regim de multi-path este de asemenea
inclusă, rezultînd posibilitatea ponderării transmisiei în mod eficient cu scopul obţinerii unei
rate de transfer globale apropiată de suma ratelor maxime de transfer ale căilor componente.
Referitor la abilitatea arhitecturii considerate de a reutiliza comenzi şi aplicaţii locale
de acces la sisteme de stocare specializate, este interesant de exemplificat: cazul accesului la
CASTOR [65] (robotul de memorare pe bandă magnetica de la Cern), cu comanda rftar [66]
(acces de tip tar) şi comanda rfcat [67] (acces de tip cat); sau controlul facil al ratei de
transfer globale prin intercalarea comenzii pmr [68] cu parametrul -l ce limitează viteza de
transmisie printr-un pipe la o valoare precizată în linia de comandă.
4. ALGORITMI EFICIENŢI DE TRANSMISIE PARALELĂ
4.1. CARACTERISTICI ALE ALGORITMILOR DE TRANSFER
Principala cerinţă a algoritmilor de transfer consideraţi este transmisia datelor în reţea

în flux continuu - streaming - dar totodată şi cu viteza ridicată. Aşa cum se poate deduce din
diagrama bloc a sistemului prezentată în figura nr. 3.1 de mai sus, soluţia adoptată
interconectează, la ambele extremităţi ale transferului de date, o structură de tip pipe, serială
în natură, cu un ansamblu de conexiuni TCP paralele, ce conferă viteza dorită în reţea. În
acest mod sistemul de comunicaţie interprocesuală prin pipes este extins de la nivel local la
comunicarea de tip punct-la-punct în reţea, asigurîndu-se în acelaşi timp o rată de transfer
corespunzătoare ansamblului de conexiuni TCP simultan folosite.
Ca urmare, algoritmii trebuie să rezolve în mod eficient probleme legate de
sincronizare, fără a se diminua semnificativ viteza maximă de transfer a datelor. Termenul de
comparaţie va fi modelul simplificat, capabil doar de transferul fişierelor de dimensiuni
cunoscute şi divizate în părţi egale, transmise în paralel, dar independent (file striping).
4.1.1. Importanţa suportului pentru multi-path
Tendinţa actuală de dezvoltare a Internet-ului este de proliferare a maşinilor cu adrese

multiple de IP, descrise de RFC 1122 [69] ca fiind de tip multihomed, adică avînd mai multe
interfeţe logice de reţea asociate cu una sau mai multe interfeţe fizice, conectate la rîndul lor
la aceeaşi reţea sau la reţele diferite. De exemplu, serverele pot fi conectate la furnizori de
servicii de Internet (ISP) diferiţi, dispozitive mobile ca tablete sau telefoane inteligente
21
(smartphone) sunt capabile de moduri de conectare radio diferite (e.g. LTE, GPRS,
Bluetooth, wireless).
Centrele de calcul moderne, compuse dintr-un număr considerabil de calculatoare
(mii, chiar sute de mii) sunt un caz special de interconectare, care nu se încadrează în clasa
multihomed, în care o singură interfaţă logica este conectată la mai multe interfeţe fizice,
creîndu-se astfel multiple căi alternative între maşini ce pot mări atît rata de transfer cît şi
siguranţa transmisiei. Aşa cum se arată în [70] [71], redundanţa la nivel de căi între oricare
două noduri se explică prin utilizarea unei topologii ierarhice de tip arbore cu rădăcini
multiple (multi-rooted tree), iar rutarea între noduri se bazează pe algoritmul ECMP, descris
de RFC 2992 [72]. Deoarece ECMP alocă în mod static (prin hashing) conexiunile la rutele
disponibile , fără să ţină seama de încărcarea reţelei şi nici de ratele de transfer implicate, se
pot produce coliziuni la nivel de conector (switch) de reţea şi degradări ale performanţelor de
transfer.
De aceea, suportul pentru utilizarea de căi multiple în reţea, cu viteze de transmisie
inegale, este important fiindcă ajută la îmbunătăţirea performanţelor de transfer, redirectîndu-
se traficul către căile cele mai libere şi pentru că reuşeşte să valorifice în mod eficient gradul
mare de paralelism existent în centrele moderne de calcul.
4.1.2. Specificaţii pentru multi-path
În situaţia în care există multiple canale de comunicaţie (e.g. intranet, VPN, WAN),
capabile de viteze de transfer diferite şi folosite simultan prin repartizarea unui număr nenul
de conexiuni TCP fiecăruia, se pune problema ponderării transmisiei datelor în vederea
maximizării debitului total. În absenţa ponderării, din cauza constrîngerilor de sincronizare a
fluxului, viteza globală tinde spre viteza celei mai lente conexiuni multiplicată cu numărul de
conexiuni folosite, aşa cum rezultă din ecuaţia (3.1). Cu ajutorul ponderării volumului de date
furnizat fiecărei conexiuni, funcţie de capacitatea sa curentă estimată, viteza globală este
superioară şi se apropie mai mult de suma vitezelor maxime ale fiecărui canal participant la
transfer, conform ecuaţiei (3.4).
Desemnarea adreselor de IP, sursă şi destinaţie, ce urmează a fi interconectate, se
poate face, la nivelul liniei de comandă (cu parametrul –j care enumeră, în ordinea dorită,
orice combinaţie de adrese sau nume IP) atît pentru client cît şi pentru server, cu scopul de a
se controla în mod explicit selecţia altfel implicită a acestora (conform algoritmului descris
de RFC 3484 [73] cu privire la alegerea adreselor IP implicite). În acest fel asocierea
conexiunilor TCP la canalele existente este determinată exclusiv în baza adreselor IP.
De asemenea, mai trebuie precizat că algoritmul cu ponderare a transmisiei proiectat
are o trăsătură importantă, şi anume se adaptează la modificarea dinamică a debitelor de
transfer per canal, fiind conceput ca un sistem de control de tip PID (proporţional-integral-
derivativ) [74] [75].
4.2. FAZELE ALGORITMULUI DE TRANSFER
4.2.1. Transmisia fără ponderare
Transmisia în flux continuu (streaming), fără ponderare, este formată dintr-un ciclu
infinit de scriere/citire în/din reţea, încheiat la terminarea proceselor externe
producator/consumator de date interconectate prin sistemul propus de pipes extinse (mai
precis atunci cînd citirea, respectiv scrierea din/în pipe-ul local, efectuată de procesul părinte
corespunzător, nu mai este posibilă) sau la întîlnirea unei erori fatale de reţea.
Asigurarea unui transfer corect în reţea, în condiţii de streaming, unde mărimea
datelor de transmis nu este disponibilă, se face prin adoptarea unei convenţii de transmisie cu
22
o ordine prestabilită, ciclică (round-robin), variind între 1 şi N (numărul total de conexiuni

TCP concurente), aplicată în mod coordonat atît la transmisie cît şi la recepţie. Această
soluţie este recunoscută ca fiind optimală în cazul conexiunilor TCP cu rate de transfer egale
(servicii identice, descrise în [76]). În speţă, aceasta conduce la alocări statice de memorie
(partajată) şi la eliminarea reordonarilor de date la recepţie.
Implementarea este realizată exclusiv în cadrul procesului părinte care exercită în
acest mod un control centralizat al transmisiei. Atît procesul părinte (cititor/scriitor de pipe)
cît şi cei N fii ai săi (scriitori/cititori de reţea) folosesc memoria partajată (vectorul spades) în
scopul sincronizării operaţiilor de scriere/citire a zonelor tampon de date (din vectorul
buckets, de asemenea partajat) corespunzătoare fiecărei conexiuni TCP concurente, operaţii
executate la fiecare pas al ciclului de transmisie. Sincronizarea se referă la faptul că procesul
părinte nu are voie să acceseze o zonă tampon pînă cînd acesta nu a fost transferată de
procesul fiu corespunzător, iar acestuia nu ii este permisă începerea transferului pînă cînd
respectiva zonă nu a fost deja pregătită, scrisă sau citită, de procesul părinte.
La rîndul lor, procesele fii sunt responsabile, în principal, de transmisia corectă a
datelor, aplicarea opţională (on-the-fly) a compresiei sau/şi criptării datelor precum şi
sesizarea şi raportatea erorilor de reţea.
4.2.2. Controlul transmisiei cu ponderare
Scopul principal al operaţiilor de ponderare a gradului de umplere a zonelor tampon

este acela al egalizării într-o măsură cît mai bună a timpilor de transmisie per zonă. Se evită
în acest mod întîrzierile cauzate de supra alocarea conexiunilor prea lente. Prin reducerea
gradului de utilizare a zonelor tampon corespunzătoare conexiunilor lente şi menţinerea la
nivel maxim a celor servite de conexiuni rapide se atinge un echilibru ce maximizează rata de
transfer globală.
Ponderarea debitului de transfer are loc atunci cînd este folosită opţiunea mpath şi
bineînţeles doar atunci cînd N este mai mare decît 1. Modificările aduse algoritmului
neponderat privesc numai partea de trimitere a datelor, recepţia datelor ramînînd
neschimbată. Aceasta constituie un avantaj, din punct de vedere al păstrării compatibilităţii cu
versiuni mai vechi ale aplicaţiei în care nu exista suport pentru multi-path.
O primă versiune
Într-o primă versiune a algoritmului de transmisie cu ponderare s-a încercat
identificarea conexiunilor mai lente fără măsurători ale timpilor de transfer individuali.
Astfel, o conexiune corespunzătoare unei zone tampon pentru care sunt necesare încă operaţii
de sincronizare a accesului este considerată prea lentă dacă cel puţin una dintre celelalte
conexiuni a încheiat deja transferul datelor din zona tampon asociată; la următoarea iteraţie i
se vor aloca mai puţine date de transmis. Această soluţie are inconvenientul identificării, în
cazul cel mai nefavorabil, a cel mult o singură conexiune lentă per iteraţie, deoarece
verificările se fac în ordine, de către procesul părinte, iar o primă conexiune prea lentă poate
masca pe toate celelalte, care au răgazul necesar încheierii transmisiei. În plus, nu există nici
suficiente informaţii pentru determinarea corectă a gradului de diminuare a utilizării zonelor
tampon ale conexiunilor lente. De aceea, am adoptat soluţia prezentată în continuare, bazată
pe un algoritm de tip PID.
Algoritmul cu ponderarea transmisiei
Contribuţia proceselor fii la algoritmul ponderat se rezumă numai la raportarea
timpilor medii , necesari transmiterii datelor din zonele tampon. Rezultatele măsurătorilor
(calculate în microsecunde cu funcţia de bibliotecă clock_gettime) sunt returnate în vectorul
speeds aflat de asemenea în memoria partajată.
În esenţă, ponderarea transmisiei se referă la ponderarea gradului de utilizare al
zonelor tampon în conformitate cu formula (3.2) de mai înainte. De notat faptul că pentru a se
23
obţine o ponderare corectă, timpii individuali de transfer ai zonelor tampon (folosiţi la

calculul noilor dimensiuni) trebuie să fie măsuraţi numai cu zone tampon egal folosite - la
capacitatea lor maximă şi pe o durată de timp suficient de mare pentru a se asigura rezultate
valide, în regim TCP stabil.
Alterarea prin eventuală micşorare a dimensiunilor zonelor tampon lasă nemodificată
alocarea iniţială a memoriei partajate (adresa de start a zonelor tampon rămîne neschimbată)
şi deci nu sunt necesare coordonări suplimentare, consumatoare de timp în reţea, cu
receptorul datelor.
Din punct de vedere al teoriei controlului sistemelor, algoritmul de transmisie cu
ponderare îmbracă forma controlului proporţional simplu (P-only), aşa cum rezultă din
diagrama din figura 4.1 de mai jos. Se observă că senzorul calculează media timpilor de
transmisie individuali care este comparată cu referinţa iniţială, iar dacă valoarea mediei a
crescut cu mai mult de 33%, controlorul determină reevaluarea gradului de folosirea a
zonelor tampon, ceea ce reglează corespunzător ratele de transfer individuale şi timpii
aferenţi, asigurîndu-se astfel optimizarea continuă a performanţei globale de transfer, în
condiţiile existenţei perturbaţiei reprezentată de variabilitatea ratei de transfer per conexiune.
Asemeni oricărui sistem automat de control, algoritmul ponderat execută în mod
repetitiv o procedură de tip măsurare-calculare-acţiune care însă conţine şi o serie de
optimizări ce sporesc performanţa cît şi stabilitatea sistemului. De exemplu, pentru a se
controla mai bine situaţia în care algoritmul cu ponderare este aplicat unui transfer de date cu
rate egale per conexiune, s-a introdus şi calcularea dispersiei timpilor individuali de transfer
în evaluarea funcţiei de eroare a sistemului de control (aşa cum se detaliază mai jos),
obţinîndu-se o funcţionare asemănătoare algoritmului neponderat (cu zone tampon utilizate la
maximum şi fără secvenţe de măsurare inutile).
Fazele propriu-zise ale transferului ponderat sunt controlate de o variabilă de stare,
lmd, care este decrementată în cadrul ciclului principal de transmisie, conform următoarelor
etape succesive:
 pentru valori strict pozitive ale lmd, se efectuează măsurarea timpilor de transmisie
individuali, , în condiţiile în care zonele tampon sunt utilizate la volumul maxim (B). Într-
o primă versiune, numărul de paşi dedicaţi măsurării a fost fix (şi egal cu 7); ulterior, ca
urmare a extinderii experimentelor în reţele cu capacitate de transfer mărită (pînă la 8 Gbps),
am adoptat un număr de paşi variabil, calculat dupa o formulă invers proporţională cu
numărul de conexiuni N (cel mult 12, dar nu mai mic decît 2).
 pentru lmd = 0, se determină gradul de umplere al zonelor tampon, calculat
proporţional cu raportul , unde pmint este timpul cel mai scurt de
transmisie al unei zone tampon, iar (*pspeed) este timpul de transmisie al zonei tampon
curente, în acord cu formula (3.2). Factorul 1.3 produce o uşoară supra-alocare, utilă în
situaţia în care în viitor respectiva conexiune devine capabilă de debite de transfer superioare,
altfel greu detectabile (din cauză de starvation). În termeni ai teoriei sistemelor, reprezintă un
filtru al controlului.
 următorii 9 paşi ( ) sunt de aşteptare, pentru a permite protocolului
TCP să atingă o stare stabilă (de evitare a congestiei).
 în continuare se intră într-o buclă de feedback, în care, la fiecare trei paşi (
) se reevaluează condiţia de efectuare a unei noi reponderări a transmisiei. În
versiunea sa îmbunătăţită, intrarea în bucla de feedback este evitată dacă media timpilor de
transfer individuali sau dispersia acestora este mai mare decît valorile respective calculate
mai înainte, la terminarea fazei de măsurare; astfel, dacă atît media cît şi dispersia au crescut
(în urma ponderării dimensiunilor utile ale zonelor tampon) , atunci se consideră că sunt de
preferat zone tampon maxime, egale; iar dacă fie media ori dispersia sunt mărite, atunci se
reia ciclul principal cu faza primă, de măsurare, direct. Ieşirea din bucla de feedback se
produce atunci cînd media timpilor de transfer individuali creşte cu mai mult de 33%,
moment în care se reia ciclul principal cu etapa iniţială de măsurare (cu zone tampon egale).
24
Fig. 4.1. Controlul proporţional, P-only, al transmisiei ponderate
4.2.3. Strategii de optimizare a ponderării transmisiei
Pentru a îmbunătăţi atît precizia de calcul a timpilor de transfer per conexiune, cît şi
stabilitatea şi rata globală de transfer ale transmisiei, am recurs la cîteva strategii practice,
rezultate în urma numeroaselor experimente efectuate. Astfel, am inclus un mecanism
(simplu) de alarmă care să declanşeze reponderarea transmisiei cu scopul de a corecta
cazurile mai rare în care rata de transfer globală a devenit determinată (în mod eronat) de rata
de transfer a conexiunii celei mai lente. Asemenea cazuri se produc în urma unei estimări
greşite a timpilor de transfer per zonă atunci cînd, de exemplu, protocolul TCP este încă în
faza de slow-start.
De asemenea, am renunţat, din prima versiune a algoritmilor, la scăderea mediei
timpilor de transfer ca motiv de declanşare a reponderării (păstrînd numai creşterea), pentru a
se îmbunătăţi stabilitatea, în sensul evitării fazelor de măsurare nenecesare. Am apreciat că
scăderea mediei este de fapt un răspuns pozitiv al sistemului care nu mai are nevoie de un
control suplimentar. În sensul teoriei sistemelor, am aplicat un filtru asupra funcţiei de
control.
Totodată am introdus o estimare continuă a referinţei din bucla de feedback, calculată
ca fiind media ultimelor trei valori ale mediei timpilor de transfer individuali (în loc de
valoarea fixă iniţială). Această abordare transformă sistemul de control într-unul de tip PI
(proporţional-integral) în care funcţia de eroare este însumată în timp. În acest mod se
corectează fluctuaţiile specifice controlului proporţional simplu, P-only, cauzate de faptul că
la echilibru funcţia de eroare prezintă o valoare (offset) nenulă.
4.2.4. Pseudocodul algoritmului de transmisie (cu ponderare opţională)
În implementarea propriu-zisă atît transmisia cît şi recepţia datelor sunt codificate în

acelaşi ciclu, din motive de eficienţă (e.g. codul dedicat sincronizării este acelaşi, indiferent
de sensul transferului). Pentru claritate, algoritmul 4.1 redă numai cazul transmisiei, cu
ponderare opţională, aşa cum este executat de procesul părinte, în pseudocod.
ALGORITMUL 4.1 Transmisie cu ponderare - opţională

Necesită: Memorie partajată iniţializată cu N zone tampon
1: shaping = mpath && N > 1
2: lmd = 6 * 4 / requestedstreamnumber
3: loop
25
4: Repetă pînă la terminare date sau eroare reţea

5: for i = 0 to N - 1 do
6: Aşteaptă golirea zonei i
7: if shaping then
8: if lmd = -1 then
9: if mint = -1 then
10: Setează grad de umplere maxim
11: else
12: Calculează gradul de umplere al zonei i
13: end if
14: else if lmd >= 0 then
15: Setează grad de umplere maxim
16: end if
17: if lmd = 0 then
18: Citeşte şi calculează minimul timpului de golire al zonelor în mint
19: end if
20: if (lmd = 0) or (lmd = -12) then
21: Calculează media st şi dispersia stsq a timpilor de golire ai zonelor
22: end if
23: if (lmd > 0) or (lmd <= -9) then
24: Comandă măsurarea timpilor de transmisie
25: end if
26: end if
27: Transferă date din pipe în zona i
28: end for
29: if shaping then
30: if 0 = lmd then
31: Salvează media msig6 şi dispersia msd a timpilor măsuraţi cu zone egale
32: end if
33: if lmd = -12 then
34: Calculează media sig6 şi dispersia sd a timpilor curenţi
35: if (sig6 > msig6) and (sd > msd) then
36: Continuă cu zone egale, maxime, mint = -1
37: end if
38: if (sig6 > msig6) or (sd > msd) then
39: continue {Reponderare}
40: end if
41: if psig6 = -1then psig6 = sig6, continue {Start feedback} end if
42: if 3 * sig6 > 4 * psig6 then
43: lmd = 6 * 4 / requestedstreamnumber
44: continue {Reponderare}
45: end if
46: end if
47: --lmd, continue
48: end if
49: end loop
4.3. SUMAR
Acest capitol a prezentat principalii algoritmi de transmisie a datelor în flux continuu

proiectaţi. Aceştia se bazează pe folosirea de conexiuni TCP multiple, în vederea obţinerii
26
unei rate de transfer în reţea performante, conectate la structuri de intercomunicaţie între

procese de tip pipe, la nivelul local al sistemului de operare.
Trăsăturile caracteristice acestor algoritmi se referă la realizarea unei sincronizări de
flux eficiente care să nu introducă întîrzieri semnificative în comparaţie cu metoda obişnuită
de transfer bazată pe file striping. Suportul algoritmilor pentru multi-path este justificat în
contextul existenţei maşinilor multihomed, al dispozitivelor mobile moderne cu acces radio
multiplu (e.g. GPRS, wireless) sau al centrelor de calcul cu trasee multiple între nodurile
componente.
Au fost prezentate fazele principale ale algoritmului de transmisie ponderată, văzute
prin prisma unui sistem de control de tip PID, pseudocodul algoritmului, precum şi
principalele strategii de îmbunătăţire a acestuia, care l-au încadrat în clasa de algoritmi de
control PI (proporţional şi integral). Parametrii de reglaj proiectaţi , în special cei privitori la
bucla de feedback şi sensibilitatea acesteia la variaţiile debitului vor fi validaţi în capitolul
următor dedicat experimentelor în reţea.
5. METODOLOGIE DE VALIDARE ŞI REZULTATE

EXPERIMENTALE
În acest capitol se validează modelul de transfer a datelor în reţea, cu viteză, prin

pipes, în flux continuu (byte streaming) şi se demonstrează calităţile sale superioare, legate în
special de generalitatea abordării, prin studierea comparativă cu modelul de transfer bazat pe
transmisia fişierelor în paralel (file striping clasic).
Pentru a demonstra că file striping se reduce de fapt la un caz particular de streaming,
în care dimensiunea datelor de transmis este cunoscută în avans (egală cu mărimea fişierului
de transferat) a fost necesar să verific că rata de transfer prin streaming nu este penalizată
semnificativ de constrîngerile de sincronizare specifice, nici chiar în cazul unor reţele cu
capacitate de transfer mai mare (de pînă la 8 Gbps) - ceea ce am realizat prin experimentele
descrise în secţiunea 5.2.
De asemenea, a fost important de demonstrat calitatea suportului centralizat pentru
multi-path la nivel de aplicaţie, facilitat de separarea între detaliile de acces la date aflate în
sisteme de stocare locale (eventual specializate, e.g. CASTOR) şi algoritmii noi, de transfer,
în flux, în reţea (conform arhitecturii de sistem din capitolul 3) - ceea ce am prezentat prin
experimentele din secţiunea 5.3.
5.1. CONSIDERAŢII METODOLOGICE
Pentru a evalua performanţele algoritmilor de transfer am creat o aplicaţie (bbftpPRO

[77]) care implementează cele trei categorii de algoritmi descrişi în capitolele anterioare, şi
anume algoritmul orientat spre transferul simplu de fişiere în paralel (file striping),
algoritmul simplu de transfer de date cu viteza în flux continuu (streaming) şi algoritmul cu
ponderarea ratei de transmisie în flux continuu (pentru suport de multi-path).
Integrarea algoritmilor în aceeaşi aplicaţie a permis configurarea cu precizie a
parametrilor de reţea, în speţă a protocolului TCP, în mod identic pentru fiecare din modelele
27
de transfer experimentate. În plus, instrumentarea a fost de asemenea comună, ceea ce a

conferit încredere în rezultatele obţinute, de măsurare a ratelor de transfer în reţea în fiecare
din cazurile considerate.
În această fază a cercetării am preferat să nu folosesc sisteme de simulare a reţelelor
pentru validarea algoritmilor de transfer, din urmatoarele două motive principale:
 pentru a grăbi implementarea într-o formă direct utilizabilă, avînd în vedere faptul că
tehnologia mea a fost adoptată devreme (ceea ce, la rîndul său, m-a încurajat să cercetez şi să
dezvolt mai departe noii algoritmi) - de exemplu, de către departamentul de fizica particulelor
de la Institutul Weizmann [78], de către cercetătorii de la experimentul VIRGO [2], de către
centrul grid US Atlas MWT2 [79]. Astfel, în figura 5.1 se prezintă performanţele obţinute de
către cei din urmă, pe o legatură de tip Starlight de 10 Gbps şi un transfer inter-cluster, disc-
la-disc, între universităţile din Chicago şi Indiana (membre ale MWT2).
 deşi un simulator de reţea este capabil să configureze cu uşurinţă o topologie de reţea
completă, prin natura sa, aşa cum rezultă din descrierea din capitolele anterioare, performanţa
algoritmilor de transfer se bazează în esenţă pe elemente de sincronizare a fluxului de date şi
pe ponderarea debitului transmisiei, ambele operaţii complexe, dar independente de o
configuraţie concretă de reţea, fiind deci mai uşor de implementat în afara nivelului de
transport (în cazul de faţă la nivel de aplicaţie).
Fig. 5.1. Transfer disc-la-disc, într-o reţea Starlight de 10 Gbps

5.1.1. Platforme de test
Măsurătorile au fost realizate prin transferuri de date între perechi de calculatoare

situate în trei categorii de reţele şi anume:
 o reţea MAN orăşenească, servită de un ISP cu lăţimea de bandă maximă egală cu 100
Mbps.
 o reţea locală ad-hoc, cu debit maxim de 1 Gbps.
 o reţea de tip IPoIB, cu transmisie de IP în reţea Infiniband, cu viteze de transfer
maxime de pînă la 8 Gbps; nodurile acestei reţele aparţin unui cluster performant, avînd
calculatoare de tip Opteron, cu 12 procesoare (cores) şi hyper-threading (cu 24 procesoare per
nod) cu frecvenţa de lucru de 3GHz şi avînd fiecare 32GB de memorie internă.
În acest mod am putut studia performanţele algoritmilor de transfer în condiţiile cele
mai variate aflate la dispoziţie. De exemplu, am obţinut o rată de transfer în flux continuu,
memorie-la-memorie, de peste 14 Gbps, folosind interfaţa de loopback a computerelor din
cluster-ul performant.
De asemenea, pe durata transferurilor am monitorizat reţeaua cu ajutorul programului
System Monitor, atunci cind a fost posibil, iar în lipsa acestuia, s-au cules datele raportate de
programul pmr, referitoare la viteza de transfer instantanee (în regim de flux continuu), în
vederea prezentării de date grafice calitative în completarea celor cantitative.
28
5.2. PERFORMANŢA ÎN FLUX CONTINUU ŞI CEA ORIENTATĂ FIŞIER
Într-o primă serie de experimente am fost interesat să constat dacă folosirea de pipes
pentru transferul în flux continuu are vreun impact asupra performanţelor de transfer, în
comparaţie cu transferul orientat către transmisia de fişiere prin file striping.
Deoarece în file striping este obligatorie folosirea de fişiere de dimensiuni cunoscute
şi pentru a elimina latenţa produsă de discurile de sistem, am întrebuinţat fişiere în memorie
(de tip tmpfs) în cazul reţelelor rapide (de 1 Gbps şi 8 Gbps). În fiecare situaţie, mărimea
fişierelor transmise a fost adecvată capacităţii de transport a reţelei, în sensul atingerii unui
regim de transfer stabil TCP, iar numărul de conexiuni paralele a fost variat pînă la atingerea
saturaţiei în reţea. Transmisia în flux continuu a fost realizată prin interconectarea cu pipes
extinse la distanţă a comenzii de sistem cat.
În figura 5.2 se prezintă rata de transfer medie obţinută în cazul transferurilor unui
fişier de pe disc, de 300 MB, folosindu-se 1 pînă la 4 conexiuni TCP simultane, în reţeaua de
100 Mbps, în ambele moduri, atît file striping cît şi file streaming. Viteza de transfer medie a
unui fişier în memorie de 400 MB, cu numărul de conexiuni TCP paralele variind între 1 şi
14, în reţeaua de 1 Gbps, este prezentată în figura 5.3 (striping şi streaming). Rezultatele
transferului unui fişier în memorie de 10 GB, cu o variaţie a numărului de conexiuni TCP
între 1 şi 24, în reţeaua de 8 Gbps, sunt prezentate în figura 5.4 (viteze medii, striping şi
streaming).
Fig. 5.2. Striping şi streaming în

paralel, reţea de 100 Mbps

paralel, reţea de 1 Gbps

paralel, reţea de 8 Gbps
29
5.2.1. Cazul transferurilor de directoare
O altă serie de experimente semnificative pentru posibilităţile celor două moduri de

transfer au fost transferurile unor subdirectoare în întregime, cu ierarhie, număr şi dimensiuni
ale fişierelor conţinute variabile.
De notat faptul că metoda bazată pe file striping a beneficiat atît de o implementare
internă eficientă a algoritmului de parcurgere recursivă a directoarelor, care minimizează
necesarul de comunicaţii de control în reţea (e.g. pentru listări de subdirectoare), cît şi de
posibilitatea combinării transferului simultan al mai multor fişiere (mai mici) în paralel.
Aceasta o recomandă, desigur, ca un element de referinţă valid în comparaţia cu sistemul de
transfer prin streaming.
De fiecare dată, durata totală a transferurilor a fost în medie de două pînă la patru ori
mai mică cînd datele au fost transferate interconectînd prin pipes extinse procese de tip
tar/un-tar, faţă de modul de transfer recursiv, fişier după fişier, prin striping.
5.3. PERFORMANŢELE TRANSMISIEI ÎN FLUX CONTINUU
În vederea evaluării performanţelor algoritmilor de transfer în flux continuu cu şi fără

ponderare a debitului, a fost necesară crearea unei topologii de reţea prevăzută cu un număr
de canale virtuale independente şi rate de transfer diferite, dar bazată pe utilizarea capacităţii
de transfer existentă la nivelul reţelei fizice, aşa cum este exemplificat în figura 5.5.
Cu toate că, din motive obiective, nu a fost posibilă adăugarea de interfeţe multiple de
reţea la calculatoare prevăzute doar cu o singură placă de reţea activă (ceea ce le-ar fi conferit
caracteristici multihomed veritabile), iar ruta între perechile de participanţi la transferul de
date a fost în fapt fixă, acest mod de testare, bazat pe căi de transfer suprapuse dar
independente sub aspectul capacităţii de transmisie, a satisfăcut condiţiile necesare unei
evaluări corecte a algoritmilor consideraţi deoarece aceştia sunt, în esenţă, sensibili la rata de
transfer a conexiunilor individuale.
Fig. 5.5. Topologie cu 3 canale virtuale independente într-o reţea IPoIB de 8 Gbps
Setările necesare au fost realizate cu programul de control al traficului tc, prin crearea
de aliasuri cu mai multe adrese de IP distincte ce au fost apoi asociate atît în mod static cît şi
în mod dinamic la canale cu rate de transfer maxime diferite.
Astfel, în fiecare dintre cele trei reţele testate, am constituit un număr de cîte trei
canale, avînd o rată de transfer maximă de 10, 20 şi 30 Mbps pentru reţeaua de 100 Mbps, de
100, 200 şi 300 Mbps în reţeaua de 1 Gbps şi respectiv de 1, 2 şi 3 Gbps în cea de-a treia
reţea, de capacitate totală egală cu 8 Gbps.
Această configuraţie a fost aleasă pe considerentul de a nu se folosi în total mai mult
decît 75% din capacitatea fizică totală a reţelei, pentru a se realiza un regim de funcţionare
sigură în condiţiile traficului bazat pe conexiuni TCP. Apreciez de asemenea că valorile alese
pentru debitele per canal sunt şi suficient de distincte pentru a se ilustra abilitatea algoritmilor
de a folosi într-o bună măsură întreaga lăţime de bandă a transmisiei, în concordanţă cu
30
valorile teoretice estimate de ecuaţia (3.4) de mai sus, în condiţii cît mai apropiate de un
regim de funcţionare reală optimizată.
5.3.1. Experimente în regim static
Transferurile au fost de tipul memorie-la-memorie şi fiecare măsurare s-a făcut pe

durata a 60 de secunde, timp ales astfel încît să se poată atinge un regim TCP de echilibru
stabil. Am variat numărul de canale folosite simultan (între 2 şi 3), numărul de conexiuni
TCP concurente şi distribuţia acestora per canal.
Astfel, în reţeaua de 100 Mbps şi cea de 1 Gbps, am alocat cîte o conexiune fiecărui
canal, în mod circular, pînă cînd toate conexiunile au fost alocate. În reţeaua de 8 Gbps s-au
alocat cîte două conexiuni per canal care să utilizeze debitul considerabil al acestei reţele.
Fiecare testare s-a făcut fără şi cu ponderarea transmisiei. De notat faptul că
distribuirea în mod circular a conexiunilor la canale a servit şi la o bună ilustrare grafică a
răspunsului diferit al celor doi algoritmi respectivi. Totodată, am avut grijă ca numărul total
de conexiuni TCP să nu fie nici excesiv de mare, ceea ce ar fi produs efecte negative legate
de saturarea reţelei sau chiar diminuarea ratei de transfer globale din cauza declanşării
congestiei în reţea, aşa cum s-a precizat în secţiunea 2.2.3.
În figura 5.6 se prezintă rata de transfer medie pentru două canale, de 20 şi 10 Mbps,
cu 2 pînă la 8 conexiuni TCP paralele, în reţeaua de 100 Mbps. Figura 5.7 prezintă rata de
transfer medie pentru trei canale, de 30, 20 şi 10 Mbps, cu 3 pînă la 9 conexiuni TCP
paralele, în aceeaşi reţea. Cazul reţelei de 1 Gbps se prezintă în figura 5.8 cuprinzînd rata de
transfer medie pentru două canale, de 200 şi 100 Mbps, cu 2 pînă la 8 conexiuni TCP
concurente şi în figura 5.9, în care se arată rata de transfer medie pentru trei canale, de 300,
200 şi 100 Mbps, cu 3 pînă la 9 conexiuni TCP concurente. Rezultatele obţinute în reţeaua de
8 Gbps sunt înfăţişate în figura 5.10, în care se arată rata de transfer medie pentru două
canale, de 2 şi 1 Gbps, cu 4 pînă la 24 conexiuni TCP simultane şi în figura 5.11 în care se
prezintă rata de transfer medie pentru trei canale, de 3, 2 şi 1 Gbps, cu 6 pînă 24 conexiuni
TCP simultane.
Fig. 5.6. Două canale,

20+10 Mbps
Fig. 5.7. Trei canale,

30+20+10 Mbps
31

200+100 Mbps

300+200+100 Mbps

2+1 Gbps

3+2+1 Gbps
32
5.3.2. Experimente în regim dinamic
Am fost de asemenea interesat şi de testarea în regim dinamic a algoritmilor de

transfer în flux continuu. Astfel, fără a întrerupe transmisia de date, am mărit şi micşorat
alternativ, la fiecare 20 de secunde, rata de transfer a conexiunilor individuale prin asocierea
acestora la canale cu debit diferit. Acest interval de timp a fost ales suficient de mare raportat
la durata tranziţiei între regimurile de funcţionare stabilă, egală cu aproximativ 4 secunde (în
cazul modului ponderat), pentru a se putea ilustra în mod concludent caracterul stabil al
transmisiei (ponderate) în regim dinamic, cu ajutorul metodelor de monitorizare menţionate.
Figura 5.12 prezintă traficul de reţea monitorizat cu System Monitoring, surprinzînd
transmisia fără (stînga) şi respectiv cu ponderare (dreapta) a 4 conexiuni TCP concurente,
două alocate unui canal de 10 Mbps şi alte două alocate alternativ, unui canal de 20 Mbps şi
respectiv de 30 Mbps, în reţeaua de 100 Mbps.
În reţeaua de 1 Gbps, traficul de reţea monitorizat tot cu System Monitoring,
reprezentînd transmisia fără (stînga) şi cu ponderare (dreapta) a 8 conexiuni TCP paralele, 4
alocate unui canal de 100 Mbps şi alte 4 alocate alternativ, unui canal de 200 Mbps şi
respectiv de 300 Mbps, este infăţişat în figura 5.13.
În reţeaua de 8 Gbps, instrumentarea s-a făcut cu programul pmr, intercalat în
sistemul de transmisie printr-un pipe (local), colectîndu-se valorilor ratei de transmisie
raportate de acesta o dată per secundă. Figura 5.14 arată rata de transfer atît a transmisiei fără
cît şi cu ponderare, a 12 conexiuni TCP simultane, 6 alocate unui canal de 1 Gbps şi celelalte
6 alocate alternativ, unui canal de 2 Gbps şi respectiv de 3 Gbps.
Fig. 5.12. Patru conexiuni TCP, 10+20|30 Mbps
Fig. 5.13. Opt conexiuni TCP, 100+200|300 Mbps
Fig. 5.14. Douăsprezece conexiuni TCP, 1+2|3 Gbps
33
5.3.3. Cazul transferurilor de tip split-TCP
Pentru a verifica abilitatea aplicaţiei de a efectua transferuri de date în flux continuu,

de tip split-TCP, în care un transfer direct între două calculatoare este înlocuit cu o cale
formată din două sau mai multe segmente distincte, separate de calculatoare intermediare cu
rol de releu de transmisie, a fost constituită o reţea de test specială, cu topologia reprezentată
în figura 5.15. Astfel, între calculatorul sursă S şi destinaţia D se află atît o cale directă, cu o
rată de transfer maximă de 25 Mbps, cît şi o cale compusă din două segmente, primul de la S
la R (un calculator releu) avînd o rată de transfer maximă de 65 Mbps şi cel de-al doilea, de la
R la D, cu rata maximă de 1 Gbps.
Fig. 5.15. Topologie de reţea de tip split-TCP
Testarea s-a făcut în regim de transferuri memorie-la-memorie, cu durata de 60 de

secunde, variindu-se numărul de conexiuni TCP paralele între 1 şi 8, iar rata de transfer
medie obţinută în fiecare caz este prezentată în figura 5.16, care conţine şi rata transmisiei
între S şi R, pentru comparaţie. Procesele implicate în transferul de date sunt:
 cat /dev/zero | Client(S) | ... | Server(D) | cat >/dev/null ; transfer direct.

 cat /dev/zero | Client(S) | ... | Server(R) | Client(R) | ... | Server(D) | cat >/dev/null ;
transfer via R.
unde pipe-ul extins în reţea este reprezentat cu simbolul ”| ... |”, iar pipe-ul normal (local, la
nivelul sistemului de operare) cu simbolul ”|”. Se observă ca releul R execută atît procesul
server de conectare cu S, cît şi un proces client, de conectare cu D, comunicarea
interprocesuala a datelor făcîndu-se cu un pipe normal.
Fig. 5.16. Transferuri directe şi split-TCP
34
5.4. ANALIZA REZULTATELOR EXPERIMENTALE
Analiza rezultatelor unui număr variat de experimente efectuate în reţele reale

demonstrează abilitatea algoritmilor de transfer în paralel de a realiza transmisii de date în
flux continuu, cu viteză ridicată, în condiţiile existenţei constrîngerilor de sincronizare şi
validează modelele teoretice care stau la baza utilizării căilor multiple, de viteză inegală, în
condiţii atît statice cît şi dinamice.
5.4.1. Consideraţii cantitative
Din punct de vedere cantitativ algoritmii de transmisie în flux continuu apar a fi la fel
de rapizi ca şi cei bazaţi pe file striping atunci cînd conexiunile TCP concurente urmează căi
identice sau cel puţin cu aceeaşi rată de transfer maximă. În acest caz sincronizarea fluxului
la nivelul zonelor tampon nu introduce întîrzieri notabile deoarece timpii de golire ai zonelor
sunt practic egali.
Aceasta rezultă din figurile 5.2, 5.3 şi 5.4 în care rata medie de transfer creşte
aproximativ liniar cu numărul de conexiuni TCP paralele pînă la atingerea unei valori de
saturaţie de aproximativ 90% din laţimea de bandă disponibilă, în concordanţă cu
peformanţele teoretice ale protocolului TCP, pentru ambii algoritmi la fel şi în toate cele trei
tipuri de reţele considerate.
La o examinare mai atentă, în cazul reţelelor rapide, de 1 Gbps şi 8 Gbps, pentru care
fiecare microsecundă contează, transmisia de tip file striping apare să aibă un avantaj iniţial
(pentru mai puţine conexiuni simultane) faţă de cea în flux continuu. Aceasta se explică prin
faptul că există operaţii suplimentare de sincronizare ce nu pot fi excluse la transmisia în flux
continuu, dar absente în cazul transmisiei de tip file striping. Cu toate acestea, cînd parametrii
de transmisie sunt corect configuraţi (e.g. zone tampon de dimensiuni sporite) şi pentru un
număr mai mare de conexiuni simultane, rata medie de transfer devine sensibil egală, astfel
încît penalitatea introdusă de sincronizare devine neglijabilă.
Diferenţe semnificative apar atunci cînd operaţiile de transfer nu sunt continui, aşa
cum am constat la sincronizarea în reţea a directoarelor cu multe fişiere mici. În aceste cazuri,
numărul de conexiuni concurente nu a contat practic, ci numai gradul mare de fragmentare al
transmisiei TCP, în special pentru multele fişiere mici, transferate pe rînd prin file striping,
ceea ce explică durata totală mult mai mare decît pentru tar/un-tar.
De asemenea, cazul split-TCP experimentat demonstrează avantajul ce se poate
obţine, sub aspectul unei rate de transfer superioare, atunci cînd există mecanisme de
înlocuire a unui transfer direct cu altul via unul sau mai multe relee intermediare. Calea
optimă este cea al cărei segment cel mai lent are o rată de transfer maximă în raport cu
celelalte căi posibile. Astfel, din figura 5.16 rezultă că transferul S->R->D atinge o rată medie
de transfer de care este de aproape trei ori mai mare decît rata medie a
transferului direct, S->D, de numai . În fapt, viteza S->R->D este aproximativ
egală cu viteza S->R ( ), ceea ce arată şi overhead-ul redus introdus de releul R
(segmentl R->S fiind de 1 Gbps, deci cu întîrzieri de propagare neglijabile).
5.4.2. Analiza regimului ponderat şi neponderat
Rezultatele cele mai semnificative privesc comparaţia între algoritmii de flux

continuu cu şi fără ponderarea transmisiei, ce folosesc canale cu rată de transfer diferită. Din
analiza regimului static cît şi mai ales a celui dinamic rezultă că algoritmii cu ponderare
folosesc în măsură mai mare debitul existent şi că au capacitate superioară de adaptabilitate
dinamică la schimbările de debit de reţea.
35
Analiza regimului static

În cazul reţelei de 100 Mbps: datele prezentate în figura 5.6 arată că pentru două
canale (de 20 şi 10 Mbps) rata medie de transfer este cu 18.1% mai mare în cazul ponderării,
cu un maxim de +33.8% pentru 4 conexiuni concurente. Gradul de utilizare a debitului total
disponibil, de 30 Mbps, este în medie doar de 70.1% fără ponderare şi de 82.9% cu
ponderare.
Pentru trei canale (de 30, 20 şi 10 Mbps), datele prezentate în figura 5.7 arată ca rata
medie de transfer este cu 34.5% mai mare în cazul ponderării, cu un maxim de +66.9%
pentru 3 conexiuni paralele. De asemenea, gradul de utilizare a debitului total disponibil, de
60 Mbps, este în medie de 56.6% fără ponderare şi de 76.3% cu ponderare.
În cazul reţelei de 1 Gbps: datele prezentate în figura 5.8 arată că pentru două canale
(de 200 şi 100 Mbps) rata medie de transfer este cu 16.6% mai mare în cazul ponderării, cu
un maxim de +32.7% pentru 4 conexiuni concurente. Gradul de utilizare a debitului total
disponibil, de 300 Mbps , este în medie de doar 68.5% fără ponderare şi de 79.9% cu
ponderare.
Pentru trei canale (de 300, 200 şi 100 Mbps), datele prezentate în figura 5.9 arată că
rata medie de transfer este cu 31.8% mai mare în cazul ponderării, cu un maxim de +64.5%
pentru 6 conexiuni paralele. Totodată, gradul de utilizare a debitului total disponibil, de 600
Mbps, este în medie de 54.5% fără ponderare si de 71.8% cu ponderare.
În cazul reţelei de 8 Gbps: datele prezentate în figura 5.10 arată că pentru două
canale (de 2 şi 1 Gbps) rata medie de transfer este cu 19.4% mai mare în cazul ponderării, cu
un maxim de +39.1% pentru 8 conexiuni paralele. Gradul de utilizare a debitului total
disponibil, de 3 Gbps , este în medie de doar 70.3% fără ponderare şi de 84% cu ponderare.
Pentru trei canale (de 3, 2 şi 1 Gbps), datele prezentate în figura 5.11 arată că rata
medie de transfer este cu 27.2% mai mare în cazul ponderării, cu un maxim de +50.5%
pentru 18 conexiuni paralele. Totodată, gradul de utilizare a debitului total disponibil, de 6
Gbps, este în medie de 53.4% fără ponderare şi de 67.9% cu ponderare.
Din punct de vedere calitativ merită subliniat faptul că se poate observa o distincţie
clară între nivelul ratelor de transfer atinse de algoritmul cu ponderare faţă de cel fără
ponderare atunci cînd se ia în considerare distribuţia mai mult sau mai puţin favorabilă a
conexiunilor la canalele existente. În timp ce primul menţine o rată de transfer ridicată şi
aproximativ constantă (cu o tendinţă firească de creştere uşoară pentru mai multe conexiuni
simultane) cel din urmă este afectat vizibil de o distribuţie nefavorabilă, aşa cum se poate
remarca din alura ratei medii de transfer, în formă de dinţi de fierăstrău, aparentă în toate
cazurile experimentate în regim static.
Analiza regimului dinamic

În absenţa ponderării, rata de transfer rămîne aproximativ constantă: în jurul valorii de
20 Mbps în reţeaua de 100 Mbps, conform figurii 5.12; în jurul valorii de 200 Mbps în
reţeaua de 1 Gbps, conform figurii 5.13; şi în jurul valorii de 1.95 Gbps în reţeaua de 8 Gbps,
conform figurii 5.14.
Aceste valori corespund ratei medii de transfer a conexiunii celei mai lente
multiplicată cu numărul de conexiuni participante la transfer, în concordanţă cu prevederile
teoretice din formula (3.1) de mai înainte:
 .

 .
În contrast, algoritmul de transfer cu ponderare este sensibil la variaţiile debitului total

disponibil, de ±33% la fiecare 20 de secunde, observîndu-se, în mod corespunzător, două
nivele distincte ale ratei de transfer cu o scurtă perioadă de tranziţie de secunde:
 în figura 5.12, pentru reţeaua de 100 Mbps, cele două nivele sunt unul de ~28 Mbps şi
36
celălalt de ~37 Mbps.

 în figura 5.13, pentru reţeaua de 1 Gbps, cele două nivele sunt de aproape 300 Mbps
şi respectiv 400 Mbps.
 în figura 5.14, pentru reţeaua de 8 Gbps, cele două nivele sunt de ~2.62 Gbps şi
respectiv ~3.48 Gbps, ambele reprezentînd din debitul total disponibil al canalelor
utilizate.
Aceste valori reprezintă o bună aproximaţie a sumei debitelor maxime ale canalelor
folosite pentru transfer, conform formulei (3.4) de mai sus.
5.5. SUMAR
Acest capitol a fost dedicat prezentării şi analizării unei serii de experimente care să
valideze arhitectura sistemului şi algoritmii de transfer cu viteză a datelor în reţea proiectaţi.
Astfel, metodologia adoptată s-a bazat pe folosirea unei aplicaţii de tip client-server
construită conform arhitecturii descrisă pe larg în capitolul 3 şi care implementează
principalii algoritmi de transfer (descrişi în capitolul 4) împreună cu o instrumentare comună
care a facilitat evaluarea lor comparativă.
Testarea a avut loc prin experimente desfăşurate în reţele reale, avînd o capacitate de
transmisie de 100 Mbps, 1 Gbps şi 8 Gbps, pentru a se putea verifica consistenţa algoritmilor
de transfer în condiţii cît mai variate cu putinţă.
Din compararea algoritmilor de streaming cu aceia de file striping, ambii executaţi în
paralel, cu multiple conexiuni TCP simultane, a rezultat că efectul constrîngerilor de
sincronizare a fluxului de date este nesemnificativ, astfel încît atît transferul datelor de
dimensiuni necunoscute cît şi al fişierelor se poate face la fel de bine numai prin streaming.
Aceasta reprezintă un avantaj, pus în evidenţă în cazul unor operaţii de salvare sau
sincronizare a directoarelor, efectuat cu viteză sporită prin tar/un-tar.
De asemenea, a fost verificat şi mecanismul ce permite efectuarea de transferuri de
date de tip split-TCP, rezultînd că propagarea datelor de-a lungul mai multor calculatoare cu
rol de releu de transmisie se face cu operaţii suplimentare neglijabile şi într-un mod recursiv,
alternîndu-se interconectările prin pipes locale cu acelea prin pipes extinse, iar rezultatele pot
fi remarcabile în privinţa vitezei de transfer atinse, faţă de aceea a unor căi directe dar mai
lente.
Suportul pentru transmisia pe căi multiple, de tip multi-path, a fost determinat printr-o
serie de experimente efectuate atît în regim static cît şi dinamic. A rezultat o bună
concordanţă cu estimările ratei de transfer globale prevăzută de modelul teoretic al cozilor de
tip fork-join, aflat la baza arhitecturii de sistem adoptate. De asemenea, răspunsul la variaţii
dinamice ale ratelor de transfer ale conexiunilor individuale a demonstrat corectitudinea
conceperii algoritmului de transmisie cu ponderare ca un sistem de control de tip PID.
6. CONCLUZII ŞI DIRECŢII DE CERCETARE VIITOARE
Prezenta teză tratează problema transferurilor de date în reţea, importantă în contextul

sistemelor de calcul de tip grid şi cloud computing. Este prezentat un model eficient de
37
transmisie a datelor cu viteză, folosindu-se multiple conexiuni TCP în paralel şi în acelaşi

timp generalizat şi simplificat prin utilizarea conceptului de pipes extinse.
Astfel, capitolul 2 al tezei este dedicat studierii stadiului actual al cunoaşterii în
domeniul transferurilor de date în reţea. Se prezintă cazul complex al proiectului Atlas pentru
a se ilustra necesitatea utilizării unor sisteme de transmisie care să facă faţă volumului imens
de date ce trebuie replicate între centre de cercetare ştiinţifică, în medii grid.
La baza transmisiei sigure a datelor în reţea se află protocolul TCP, analizat în
contextul modelului TCP/IP, sub aspectul performanţelor obţinute şi al justificării
întrebuinţării conexiunilor TCP simultane pentru mărirea ratei de transfer globale.
Se realizează de asemenea un studiu comparativ: al principalelor variante ale TCP
care vizează îmbunătăţirea algoritmilor săi de control al congestiei; al metodelor de
management activ al ruterelor din reţea; al unor protocoale non TCP care răspund mai bine
cerinţelor unor aplicaţii specializate; şi al clasei largi de aplicaţii şi biblioteci de funcţii de
transfer în reţea.
Au rezultat o serie de limitări ale soluţiilor existente, referitoare, între altele, la durata
mare a standardizării modificărilor de protocol, la dificultatea şi costul diseminării
protocoalelor noi, non TCP, dar şi avantaje, valorificate în prezenta teză, ca de exemplu
uşurinţa diseminării în cazul aplicaţiilor de transfer situate în afara nivelului de transport
(care este de obicei implementat în nucleul sistemului de operare).
Ca urmare, arhitectura sistemului adoptat, de transfer a datelor în reţea, este bazată pe
o aplicaţie de tip client-server, specializată în transmisia cu viteză sub formă de streaming în
paralel, la nivel de octet. Aşa cum se arată în capitolul 3, se obţine o rată de transfer
performantă prin utilizarea modelului de prelucrare paralelă al cozilor de tip fork-join,
sincronizate, ce permit prin ponderarea transmisiei şi suportul pentru multi-path la nivel de
aplicaţie.
Deoarece interfaţa aplicatiei cu sistemul de operare este de tip pipe, paradigma
programării cu pipes este generalizată de la nivelul local la acela al Internetului, în sens larg,
cumulîndu-se avantajul reutilizării comenzilor şi al aplicaţiilor de acces la sisteme de stocare
specializate cu transmisia cu o rată de transfer maximizată a datelor în reţea.
Viteza sporită de transfer, în modul streaming, a aplicaţiei se datorează conceperii
unor algoritmi de transmisie eficienţi, descrişi în capitolul 4. Aceştia realizează o sincronizare
eficientă a fluxurilor individuale atît în regim neponderat, cînd toate conexiunile TCP
paralele urmează căi identice, cît şi în regim ponderat, necesar pentru optimizarea ratei
globale a transmisiei de tip multi-path.
Algoritmul de transmisie ponderată este proiectat ca un sistem de control automat al
ratei de transfer globale, de tip proporţional şi integral, ceea ce asigură o rată maximă, în
condiţiile existenţei unei variaţii dinamice a lăţimii de bandă disponibile pentru conexiunile
TCP individuale (e.g. în centre de calcul moderne care au căi multiple între oricare dintre
nodurile din reţea).
Consistenţa şi eficienţa algoritmilor de transfer, cît şi flexibilitatea arhitecturii
adoptate au fost verificate printr-o serie de experimente de transfer a datelor desfăşurate în
cele mai variate platforme de test disponibile, avînd rate de transmisie maxime cuprinse între
100 Mbps, 1 Gbps şi 8 Gbps.
Din analiza rezultatelor experimentale, prezentată în capitolul 5, se poate determina că
suportul pentru multi-path este eficace atît în regim static cît şi dinamic, în bună concordanţă
cu estimările teoretice din secţiunea 3.4.1, iar regimul de streaming este la fel de rapid
precum cel de tip file striping, avînd în plus avantajul implementării modelului de transfer
prin pipes extinse în reţea.
6.1. CONTRIBUŢIILE TEZEI
Principalele contribuţii ale acestei teze sunt următoarele:

38
 Un studiu comparativ al tehnicilor şi aplicaţiilor de transfer de date în reţea care a

analizat atît avantajele cît şi dezavantajele metodelor actuale de transmisie rapidă a datelor în
reţea, servind ca punct de plecare al prezentei cercetări în domeniu.
 O arhitectură de sistem de transfer a datelor bazată pe conceptul îmbinării vitezei
sporite de transmisie în reţea, prin utilizarea de mai multe conexiuni TCP simultane, cu
generalizarea paradigmei de programare prin pipes extinse.
 Un set de algoritmi eficienţi de transmisie a datelor în flux continuu (streaming) şi de
transfer a datelor pe căi diferite, avînd viteze individuale inegale (multi-path), care
optimizează rata globală de transport a datelor la nivel de aplicaţie.
 O evaluare comprehensivă a consistenţei şi eficienţei algoritmilor de transfer în reţele
reale şi de test şi a validităţii arhitecturii de sistem adoptate.
 O aplicaţie de transfer a datelor în reţea completă, care implementează arhitectura şi
algoritmii proiectaţi împreună cu o serie de caracteristici specifice modelului client-server,
importante în expoatarea în regim de producţie. De amintit faptul că, între alţii, institutul
Weizmann şi proiectul VIRGO folosesc în mod curent aplicaţia pentru transferul de date.
6.2. DISEMINAREA CERCETĂRII
Rezultatele cercetării din această teză au fost diseminate sub forma următoarelor
publicaţii şi rapoarte ştiinţifice:
1. D. Schrager, “Study of Techniques and Applications for Fast Data Transfers in
HBDP Networks,” in Proceedings of 12th International Symposium on Parallel and
Distributed Computing, ISPDC2013, Bucharest, Romania, Jun. 2013.
2. D. Schrager, “New Solutions for Fast Data Transfers in HBDP Networks,” UPB
Scientific Bulletin, Series C, Electrical Engineering and Computer Science, ISSN-L 2286 -
3540, 2013.
3. D. Schrager şi F. Rădulescu, “Efficient Algorithms for Fast Data Transfers Using
Long and Large Pipes in WAN Networks,” in Proceedings of 19th International Conference
on Control Systems and Computer Science, CSCS19, Bucharest, Romania, May 2013.
4. D. Schrager şi F. Rădulescu, “An Improved Application Level Multi-Path
Streaming Algorithm for HBDP Networks,” in Proceedings of 5th International Conference
on Computational Collective Intelligence Technologies and Applications, ICCCI2013,
Craiova, Romania, Sep. 2013.
5. The ATLAS DC1 Task Force, incl. D. Schrager, “ATLAS Data Challenge 1,”
Nov. 2003.
6. Incl. D. Schrager, “Full Supersymmetry Simulation for ATLAS in DC1,” ATL-
COM-PHYS-2003-0xx, Dec. 2003.
6.3. DIRECŢII DE CERCETARE VIITOARE
Studiul în acest domeniu poate fi extins şi cu alţi algoritmi de transfer care să asigure
o stabilitate şi eficienţă îmbunătăţită, în special în cazul suportului pentru multi-path.
De asemenea, o serie de automatizări, care să asigure o transparenţă mai mare pentru
utilizatori, ar putea fi adăugate aplicaţiei de transfer, de exemplu prin proiectarea unui modul
de control al căilor multiple din reţea care să realizeze şi o selecţie implicită a adreselor de IP
disponibile la sursa şi destinaţia transferului de date.
O altă posibilitate de cercetare o reprezintă validarea modelului de transfer a datelor şi
prin efectuarea de simulări, în reţele cu o topologie şi capacitate variabilă, în scopul unei mai
bune evaluări a performanţelor transmisiilor de tip split-TCP sau multi-path.
39
Continuarea cercetării din acestă teză va fi utilă pentru toate domeniile interesate de
transmiterea unor cantităţi de date masive, cu rapiditate şi uşurinţă, în condiţiile diversificării
şi dezvoltării continui a capacităţii reţelelor în viitor.
BIBLIOGRAFIE - SELECTIVĂ
[1] “ATLAS Experiment,” [Online]. Available: http://www.atlas.ch/.

[2] “VIRGO Detector,” [Online]. Available: https://wwwcascina.virgo.infn.it/.
[3] “GLIF Facility,” [Online]. Available: http://www.glif.is/.
[4] “OptIPuter,” [Online]. Available: http://www.optiputer.net/.
[5] J. Postel, Transmission Control Protocol, RFC 793, Sep. 1981.
[6] M. Mathis, J. Semke and J. Mahdavi, “The macroscopic behavior of the TCP congestion
avoidance algorithm,” Computer Communications Review, Jul. 1997.
[7] M. Mathis, J. Mahdavi, S. Floyd and A. Romanow, TCP Selective Acknowledgment,
RFC 2018, Oct. 1996.
[8] L. Brakmo and L. Peterson, “TCP Vegas: End to End Congestion Avoidance on a
Global Internet,” IEEE Journal on Selected Areas in Communications, vol. 13, no. 8,
Oct. 1995.
[9] S. Floyd, “HighSpeed TCP for Large Congestion Windows,” RFC 3649, Dec. 2003.
[10] C. Jin, D. Wei and S. Low, “FAST TCP: Motivation, Architecture, Algorithms,
Performance,” in Proceedings of IEEE Infocom, Hong Kong, Mar. 2004.
[11] J. Crowcroft and P. Oechslin, “Differentiated End-to-End Internet Services Using a
Weighted Proportional Fair Sharing TCP,” ACM SIGCOMM Computer Communication
Review, vol. 28, no. 3, pp. 53 - 69, Jul. 1998.
[12] A. Ford, C. Raiciu, M. Handley and O. Bonaventure, “TCP Extensions for Multipath
Operation with Multiple Addresses draft-ietf-mptcp-multiaddressed-09,” IETF draft,
Jun. 2012.
[13] S. Floyd and V. Jacobson, “Random Early Detection gateways for Congestion
Avoidance,” in IEEE/ACM Transactions on Networking, Aug. 1993.
[14] W. Feng, D. Kandlur, D. Saha and K. Shin, “BLUE: A New Class of Active Queue
Management Algorithms,” University of Michigan, CSE-TR-387-99, Apr. 1999.
[15] W.-c. Feng, D. D. Kandlur, D. Saha and K. G. Shin, “Stochastic Fair Blue: A Queue
Management Algorithm for Enforcing Fairness,” in INFOCOM, Apr. 2001.
[16] D. Katabi, “Decoupling Congestion Control and Bandwidth Allocation Policy with
Application to High Bandwidth-Delay Product Networks,” Massachusetts Institute of
Technology, PhD Thesis, Mar. 2003.
40
[17] A. Jungmaier, M. Schopp and M. Tuexen, “Performance Evaluation of the Stream

Control Transmission Protocol,” in 3rd International Conference on ATM (ICATM
2000), Heidelberg, Germany, Jun, 2000.
[18] E. Kohler, M. Handley and S. Floyd, “Designing DCCP: congestion control without
reliability,” in Proceedings of the 2006 conference on Applications, technologies,
architectures, and protocols for computer communications SIGCOMM '06, New York,
[19] E.
Oct.He, J. Leigh, O. Yu and T. DeFanti, “Reliable Blast UDP : Predictable High
2006.
Performance Bulk Data Transfer,” in Proceedings of IEEE International Conference on
Cluster Computing, Beijing, China, 2002.
[20] Y. Gu and R. Grossman, “SABUL: A Transport Protocol for Grid Computing,” Journal
of Grid Computing, vol. 1, no. 4, pp. 377-386, 2003.
[21] M. Allman, S. Ostermann and H. Kruse, “Data Transfer Efficiency over Satellite
Circuits Using A Multi-Socket Extension to the File Transfer Protocol (FTP),” in
Proceedings of ACTS Results Conference, NASA Lewis Research, 1995.
[22] H. Sivakumar, S. Bailey and R. L. Grossman, “PSockets: The case for application-level
network striping for data intensive applications using high speed wide area networks,” in
Proceedings of IEEE/ACM SC2000 Conference, Dallas, TX, 2000.
[23] W. Allcock, J. Bresnahan, R. Kettimuthu, M. Link, C. Dumitrescu, I. Raicu and I.
Foster, “The Globus Striped GridFTP Framework and Server,” in SC 05: Proceedings of
the 2005 ACM/IEEE conference on Supercomputing, Seattle, WA, Nov. 2005.
[24] P. Rizk, C. Kiddle and R. Simmonds, “A GridFTP Overlay Network Service,” in
Proceedings of 7th IEEE/ACM International Conference on Grid Computing, Sep. 2006.
[25] T. V. Lakshman and U. Madhow, “The Performance of TCP/IP for Networks with High
Bandwidth-Delay Products and Random Loss,” IEEE/ACM Transactions on
Networking, vol. 5, no. 3, Jun. 1997.
[26] J. Mo, R. La, V. Anantharam and J. Walrand, “Analysis and Comparison of TCP Reno
and Vegas,” in Proceedings of INFOCOM ’99, Eighteenth Annual Joint Conference of
the IEEE Computer and Communications Societies, New York, NY, Mar. 1999.
[27] I. Foster and C. Kesselman, The Grid 2: Blueprint for a New Computing Infrastructure,
San Francisco, CA: Morgan Kaufmann Publishers Inc., 2003.
[28] I. Foster, “Globus Toolkit version 4: Software for service-oriented systems,” in
Proceedings of IFIP International Conference on Network and Parallel Computing,
Beijing, China, 2005.
[29] “PACMAN,” [Online]. Available:
http://www.globus.org/grid_software/packaging/pacman.php. [Accessed Aug. 2013].
[30] F. Luehring, Grid Computing for Atlas, Indiana University HEP Seminar, Mar. 2006.
[31] The ATLAS DC1 Task Force, incl. D. Schrager, “ATLAS Data Challenge 1,” Nov.
2003.
[32] Incl. D. Schrager, “Full Supersymmetry Simulation for ATLAS in DC1,” ATL-COM-
PHYS-2003-0xx, Dec. 2003.
[33] “File Transfer Service,” [Online]. Available: http://egee-jra1-dm.web.cern.ch/egee-jra1-
dm/FTS/. [Accessed Aug. 2013].
[34] “European Middleware Initiative,” [Online]. Available: http://www.eu-emi.eu/home.
[Accessed Aug. 2013].
[35] D. E. Comer, Internetworking with TCP/IP, Englewood Cliffs, NJ: Prentice Hall, 1991.
41
[36] H. Zimmermann, “OSI Reference Model - The ISO Model of Architecture for Open
Systems Interconnection,” IEEE Transactions on Communications, Vols. COM-28, no.
4, Apr. 1980.
[37] M. Allman, V. Paxon and W. Stevens, “TCP Congestion Control,” RFC 2581, Apr.
1999.
[38] T. J. Hacker, Improving End-to-End Reliable Transport Using Parallel Transmission
Control Protocol Sessions, PhD thesis, University of Michigan, 2004.
[39] S. J. Leffler, M. K. McKusick, M. J. Karels and J. S. Quarterman, The Design and
Implementation of the 4.3BSD UNIX Operating System, Reading, MA: Addison-
Wesley, 1989.
[40] V. Jacobson and R. Braden, “TCP Extensions for Long-Delay Paths,” RFC 1072, Oct.
1988.
[41] K. Fall and S. Floyd, “Simulation-based comparisons of Tahoe, Reno and SACK TCP,”
ACM SIGCOMM Computer Communication Review, vol. 26, no. 3, pp. 5-21, Jul. 1996.
[42] J. Xu, Performance evaluation of TCP over optical channels and heterogeneous
networks, Univ. of South Florida, MSc Thesis, Mar. 2004.
[43] S. Barre, Implementation and Assessment of Modern Host-based Multipath Solutions,
PhD Thesis, Louvain School of Engineering, Louvain-la-Neuve, Belgium, Oct. 2011.
[44] C. Raiciu, C. Paasch, S. Barre, A. Ford, M. Honda, F. Duchene, O. Bonaventure and M.
Handley, “How Hard Can It Be? Designing and Implementing a Deployable Multipath
TCP,” in Proceedings of USENIX Symposium of Networked Systems Design and
Implementation (NSDI’12), Apr. 2012.
[45] K. Ramakrishnan, S. Floyd and D. Black, “The Addition of Explicit Congestion
Notification (ECN) to IP,” RFC 3168, Sep. 2001.
[46] B. Bloom, “Space/time Trade-offs in Hash Coding with Allowable Errors,”
Communications of the ACM, vol. 13, no. 7, Jul. 1970.
[47] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M.
Kalla, L. Zhang and V. Paxson, Stream Control Transmission Protocol, RFC 2960, Oct.
2000.
[48] R. Stewart, Stream Control Transmission Protocol, RFC 4960, Sep. 2007.
[49] C. Caini, R. Firrincieli, M. Marchese, T. d. Cola, M. Luglio, C. Roseti, N. Celandroni
and F. Potorti, “Transport layer protocols and architectures for satellite networks,”
International Journal of Satellite Communications and Networking, vol. 25, no. 1, pp. 1-
26, 2007.
[50] J. R. Iyengar, P. Amer and R. Stewart, “Performance Implications of a Bounded Receive
Buffer In Concurrent Multipath Transfer,” Computer Communications, vol. 30, no. 4, p.
818–829, Feb. 2007.
[51] J. Iyengar, P. Amer and R. Stewart, “Concurrent Multipath Transfer Using SCTP
Multihoming Over Independent End-to-End Paths,” IEEE/ACM Transactions on
Networking, vol. 14, no. 5, p. 951–964, Oct. 2006.
[52] S. Floyd and E. Kohler, “Profile for Datagram Congestion Control Protocol (DCCP)
Congestion Control ID 2: TCP-like Congestion Control,” RFC 4341, Mar. 2006.
[53] S. Floyd, E. Kohler and J. Padhye, “Profile for Datagram Congestion Control Protocol
(DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC),” RFC 4342,
Mar. 2006.
42
[54] J. Lai and E. Kohler, “A Congestion-Controlled Unreliable Datagram API,” [Online].

Available: http://www.read.cs.ucla.edu/dccp/nsdiabstract.pdf. [Accessed Aug. 2013].
[55] J. Postel and J. Reynolds, “FILE TRANSFER PROTOCOL (FTP),” RFC 959, Oct.
1985.
[56] V. Jacobson, R. Braden and D. Borman, “TCP Extensions for High Performance,” RFC
1323, May 1992.
[57] W. Allcock, J. Bester, J. Bresnahan, A. Chervenak, L. Liming and S. Tuecke, “GridFTP:
Protocol Extensions to FTP for the Grid,” Global Grid Forum Recommendation
Document GFD-R-P.020, 2005.
[58] M. Horowitz and S. Lunt, “FTP Security Extensions,” RFC 2228, Oct. 1997.
[59] P. Hethmon and R. Elz, “Feature negotiation mechanism for the File Transfer Protocol,”
RFC 2389, Aug. 1998.
[60] J. Schopf, M. DArcy, N. Miller, L. Pearlman and I. Kesselman, “Monitoring and
discovery in a webservices framework: Functionality and performance of the globus
toolkits mds4,” Globus, Tech. Rep. ANL/MCSP1248-04-5, 2005.
[61] “GSI-Enabled OpenSSH,” [Online]. Available: http://grid.ncsa.illinois.edu/ssh/.
[Accessed Aug 2013].
[62] L. Flatto and S. Hahn, “Two parallel queues created by arrivals with two demands,”
SIAM J. Appl. Math., vol. 44, no. 5, pp. 1041-1053, 1984.
[63] H. P. Anvin, “The mathematics of RAID-6,” 2011.
[64] O. J. Boxma, J. Koole and Z. Liu, “Queueing-theoretic solution methods for models of
parallel and distributed systems,” National Research Institute for Mathematics and
Computer Science, CWI, Amsterdam, Jul. 1994.
[65] “CASTOR,” [Online]. Available: http://castor.web.cern.ch/.
[66] D. Schrager, “rftar,” [Online]. Available:
http://castorold.web.cern.ch/castorold/DIST/CERN/savannah/CONTRIB.pkg/Dan.Schra
ger@weizmann.ac.il/.
[67] LCG Grid Deployment Team, “rfcat,” [Online]. Available:
http://linux.die.net/man/1/rfcat.
[68] H. Orsila, “pmr,” [Online]. Available: http://zakalwe.fi/~shd/foss/pmr/.
[69] R. Braden, “Requirements for Internet Hosts -- Communication Layers,” RFC 1122,
Oct. 1989.
[70] M. Al-Fares, S. Radhakrishnan, B. Raghavan, N. Huang and A. Vahdat, “Hedera:
Dynamic flow scheduling for data center networks,” in USENIX Symposium on
Networked Systems Design and Implementation (NSDI), Apr. 2010.
[71] C. Raiciu, S. Barre, C. Pluntke, A. Greenhalgh, D.Wischik and M. Handley, “Improving
data center performance and robustness with multipath TCP,” in SIGCOMM, Toronto,
Canada, Aug. 2011.
[72] C. Hopps, “Analysis of an Equal-Cost Multi-Path Algorithm,” RFC 2992, Nov. 2000.
[73] R. Draves, “Default Address Selection for Internet Protocol version 6 (IPv6),” RFC
3484, Feb. 2003.
[74] K. J. Astrom and T. Hagglund, PID Controllers: Theory, Design, and Tuning, Instrument
Society of America, 1995.
[75] D. J. Cooper, “Practical Process Control: Proven Methods and Best Practices for
Automatic PID Control,” [Online]. Available: http://www.controlguru.com/. [Accessed
July 2013].
43
[76] J. Walrand, An Introduction to Queueing Networks, Englewood Cliffs: Prentice-Hall,

1988.
[77] D. Schrager, “bbftpPRO,” [Online]. Available: http://bbftppro.myftp.org/.
[78] “WIS,” [Online]. Available: http://www.weizmann.ac.il/particle/.
[79] “MWT2,” [Online]. Available: http://mwt2.usatlasfacility.org/.
44

Dan Schrager

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Dan Schrager

Încărcat de

Drepturi de autor:

Formate disponibile

FONDUL SOCIAL EUROPEAN

UNIVERSITATEA POLITEHNICA DIN BUCUREŞTI

Transferul rapid, în paralel, al datelor în reţele WAN

Fast Parallel Data Streaming Transfers in WAN Networks

Autor: Ing. Dan Schrager

Conducător de doctorat: Prof.dr.ing. Valentin Cristea

3. ARHITECTURA SISTEMULUI DE TRANSFER DE DATE ........................................17

În contextul actual al dezvoltării grid şi cloud computing cercetarea ştiinţifică se

1.1. MOTIVAREA CERCETĂRII

Schimbările aduse protocolului TCP au de obicei o durată de standardizare

1.2. OBIECTIVELE CERCETĂRII

Conform tezei mele:

La nivelul de transport al protocoalelor de reţea se prezintă protocolul TCP, deoarece

2. STUDIU COMPARATIV AL TEHNICILOR ŞI APLICAŢIILOR DE

2.1. TRANSFERURILE DE DATE ŞI MEDIUL GRID

Mediile grid sunt importante în contextul realizării de transferuri de date pe scară

2.1.1. Serviciul FTS

2.2. SISTEMUL PROTOCOALELOR DE COMUNICAŢIE ÎN REŢEA

2.2.1. Protocolul TCP

segment (pachet) şi în acelaşi timp măreşte exponenţial (dublează) timeout-ul segmentelor de

2.2.2. Performanţele TCP

2.2.3. Performanţa conexiunilor TCP multiple

distribuită uniform între conexiuni (fenomen favorizat de metodele moderne de management

2.3. DIVERSE IMPLEMENTĂRI ALE TCP

Cercetarea în acest domeniu a vizat îmbunătăţirea mecanismelor de retransmisie şi de

2.3.1. TCP Sack

2.3.2. TCP Vegas

2.3.3. HighSpeed TCP

HighSpeed TCP [9] este o modificare experimentală a mecanismului de control a

2.3.4. Fast TCP

FAST TCP [10] este o implementare actualmente comerciala a unui mecanism de

MulTCP [11] reprezintă o modificare a algoritmului de control a congestiei care

2.4. MANAGEMENTUL ACTIV AL COZILOR DIN RUTERE (AQM)

2.4.1. Algoritmul RED

Algoritmul RED [13] (Random Early Detection) aplică o politică de detecţie a

2.4.2. Algoritmul BLUE

Algoritmul BLUE [14] foloseşte o schemă de management automatizată, care nu

2.4.3. Algoritmul SFB

Algoritmul SFB [15] (Stochastic Fair BLUE) reprezintă o variantă îmbunătăţită a

2.5. PROTOCOALE NON-TCP

Protocoalele non-TCP îşi aduc o contribuţie pozitivă la rezolvarea problemelor legate

Comparativ cu TCP, SCTP foloseşte un algoritm de retransmisie bazat pe confirmări

2.6. APLICAŢII DE TRANSFER RAPID

La nivelul aplicaţiilor de reţea există o multitudine de soluţii, bazate pe tehnici de

2.6.3. Globus GridFTP

Globus GridFTP [23] este o aplicaţie client-server pentru transferul de fişiere

Rezultatele experimentale demonstrează că RBUDP poate transfera cantităţi mari de

2.6.6. GridFTP Overlay

În [24] se prezintă un număr de componente care îmbunătăţesc capacitatea de transfer

Acest capitol a făcut o prezentare cuprinzătoare a rezultatelor cercetării în domeniul

Tabela 2.1. Comparaţie sinoptică între metodele de transfer în reţea

Uşurinţa Reutilizare Suport Suport Transfer

3. ARHITECTURA SISTEMULUI DE TRANSFER DE DATE

În figura 3.1 se prezintă arhitectura sistemului de streaming în paralel, cu o structură

transmisie per proces.

Fig. 3.1. Arhitectura sistemului de streaming în paralel

Procesul părinte implementează algoritmii principali de control al transmisiei de date,

 interfaţa cu sistemul de operare este de tip pipeline, ceea ce conferă generalitate în

Arhitectura adoptată realizează de asemenea o combinare efectivă între modul de

3.2. CAPABILITĂŢI CLIENT-SERVER SUPLIMENTARE

3.3. MODELUL COZILOR DE TIP FORK-JOIN

3.3.1. Performanţa sistemului

Performanţele atinse de sistemul de transfer de tip fork-join sunt determinate de