Cercetare româneascã in informaticã intr-o prezentare Google TechTalks

(o incercare de popularizare)

Am avut multe discuţii cu colegii mai tineri de la IEAT despre natura cercetãrii aplicative interesante (din punctul meu de vedere) in informaticã. Mã bucur cã pot oferi un exemplu (in parte) românesc, prilejuit de o prezentare  din seria GoogleTechTalks.

Costin Raiciu este lector (?) – nu sunt sigur de funcţia exactã – la catedra de calculatoare a Universitãţii Politehnice din Bucureşti. Are un doctorat de la University College London şi s-a ocupat cu problema modificãrii protocolului TCP prin incorporarea unor drumuri multiple.

Pentru neinformaticienii care desigur mã citesc 🙂 poate suna intimidant. Voi incerca sã schiţez in continuare o explicaţie mai pe inţelesul lor, cerându-mi scuze de la informaticieni pentru omisiuni/exagerãri 🙂

Funcţionarea reţelelor de calculatoare, de care toţi depindem din ce in ce mai mult este asiguratã de o serie de protocoale de comunicare. Acestea sunt organizate ierarhic: protocoalele de la „baza ierarhiei” rezolvã probleme „de nivel mai jos”. Cele de pe nivele superioare presupun faptul cã aceste probleme simple sunt rezolvate şi se concentreazaã pe rezolvarea unor probleme mai dificile. Arhitectura descrisã mai sus este explicatã intuitiv de poza urmãtoare, preluatã pe Wikipedia, şi descriind aşa-numitul model OSI (Open Systems Interconnect):

Un exemplu de probleme rezolvate de „nivelele de jos” este urmãtoarea: cum comunicãm fãrã erori cu un vecin de-al nostru in reţea ? Abia când am rezolvat aceastã problemã ne putem gândi la probleme mai complicate precum „comunicarea la distanţã”, folosind mai multe noduri intermediare, precum in jocul de copii telefonul fãrã fir 🙂

TCP (Transmission Control Protocol) este unul din aceste protocoale. Este foarte important (şi) prin faptul cã este unul „vizibil” pentru programatorii care dezvoltã noi programe). A fost dezvoltat la inceputul anilor ’70 de cãtre (medaliatul Turing) Vint Cerf şi colaboratorii sãi.

TCP incearcã sã rezolve probleme precum urmãtoarele:

  • cum gestionãm „stabilirea unei convorbiri” şi lista „conversaţiilor in curs” ?
  • cum controlãm „viteza de transmisie” ? Ce facem când ” conversaţia are intreruperi (nu primim toatã informaţia transmisã)” ?

Pentru a rezolva aceste probleme TCP vede o „conexiune” intre douã puncte drept un unic drum intre ele.

Acest lucrul este o abstractizare: in realitate pachetele de informaţii aparţinând unei singure conexiuni pot cãlãtori  pe cãi diferite intre sursã şi destinaţie. Şi chiar o pot face in practicã, având in vedere o cerinţã pe care le avem de la reţelele de calculatoare – ca traficul sã poatã „ocoli” regiuni ale reţelei in cazul in care acestea inceteazã sã funcţioneze.

Pe de altã parte algoritmii pe care i-a adoptat TCP pentru rezolvarea problemelor depind de aceastã metaforã, aceea a unui unic „fir” care conecteazã transmiţãtorul cu receptorul. Explicaţia este simplã: gestionarea acestor cãi este realizatã de un alt protocol situat pe un nivel inferior care oferã iluzia faptului cã am avea parte de un singur drum.

Cercetãrile pe care se bazeazã prezentarea lui Costin Raiciu propun abandonarea acestei metafore, extinzând protocolul in aşa fel incât „noul TCP” sã poatã gestiona explicit mai multe fluxuri intre cele douã noduri.

De ce am dori sã modificãm un protocol atât de vechi şi robust[1] ? Simplu: evoluţia tehnologiei (conectivitatea in regim mobil e un exemplu) aduce in prim-plan aspecte noi, care nu erau relevante in anii ’70. Un exemplu (din prezentare), poate nu neapãrat cel mai important din punct de vedere tehnic, dar uşor de inţeles ţine de accesul pe care il putem avea la mai multe conexiuni la internet, cu preţuri şi caracteristici tehnice diferite (cablu versus 3G, de exemplu). Posibilitatea de a „combina mai multe cãi de a trimite informaţia” este (cel puţin la nivel de principiu) un avantaj de care ar trebui sã putem profita.

Ca lucrurile sã meargã bine din punct de vedere practic avem nevoie de o evoluţie, nu o revoluţie 🙂 Cu alte cuvinte nu putem presupune cã toate calculatoarele interconectate pe glob vor incepe sã foloseascã imediat noul protocol. Dimpotrivã el trebuie sã poatã coexista cu tehnologia deja existentã.

In concluzie, orice modificare adusã protocolului original trebuie sã rãspundã urmãtoarelor cerinţe:

1. noua variantã de protocol trebuie sã poatã crea şi controla explicit mai multe fluxuri intre aceeaşi pereche sursã-destinaţie.

2. acest lucru trebuie sã fie „invizibil” pentru aplicaţiile deja existente şi, pe cât posibil, sã nu degradeze performanţa celorlaltor utilizatori, ale cãror aplicaţii folosesc protocolul obişnuit.

In mare, aceste aspecte „inginereşti”, precum şi aspectele protocolului original (de exemplu controlul vitezei de transmisie – in eng. congestion control -) care sunt afectate de introducerea mai multor cãi de comunicare, fac obţinerea unei astfel de extensii o problemã interesantã şi un subiect de cercetare pentru informatician. Ca sã vã faceţi o idee, iatã doar câteva probleme care pot apãrea (din cele mai uşor de explicat – nu neapãrat cele mai interesante):

  • din punctul de vedere al aplicaţiei pe care TCP o deserveşte avem in continuare de a face cu un unic flux de date. El trebuie, prin urmare, „reasamblat” la destinatar din sub-fluxurile componente. Având in vedere acest lucru cum gestionãm transmisia informaţiei – local, pe fiecare sub-flux in parte sau centralizat ?
  • sub-fluxurile componente ale unei transmisii pot intâlni condiţii diferite in reţea, lucru care le poate face sã aibã viteze diferite. Cum alocãm dinamic transmiterea informaţiei intre fluxurile componente ca sã pãstrãm „integritatea transmisiei” ?

Nu mai insist asupra aspectelor tehnice concrete din prezentare, ele fiind oarecum greu de explicat intr-o manierã de popularizare. Mã mãrginesc sã spun cã

  • rezultatele obţinute au avut impact ştiinţific, fiind prezentate la conferinţe foarte bune, cum sunt SIGCOMM, NSDI sau Internet Measurement Conference, nu in unele de interes local. De asemenea o parte din conceptele implicate sunt deja standardizate sau in curs de standardizare (in limbaj tehnic: subiect al unor Internet Draft-uri ale IETF).
  • cercetãrile pe care le popularizez aici ridicã probleme algoritmice fascinante pentru teoreticieni ca mine 🙂 Un exemplu special ţine de aspectele de decizie strategicã ridicate de model. Având in vedere recentele mele preocupãri in  domeniul teoriei algoritmice a jocurilor, poate cã afirmaţia de mai sus poate fi inţeleasã ceva mai bine 🙂

Enjoy !

NOTE:

  1. [INAPOI] Strict vorbind, protocolul TCP a cunoscut destule variante şi modificãri faţã de varianta iniţialã. Soluţia propusã aici, conteazã, pe de altã parte, drept o modificare arhitecturalã importantã.
Anunțuri
Acest articol a fost publicat în popularizarea_ştiinţei. Pune un semn de carte cu legătura permanentă.

Lasă un răspuns

Completează mai jos detaliile tale sau dă clic pe un icon pentru a te autentifica:

Logo WordPress.com

Comentezi folosind contul tău WordPress.com. Dezautentificare / Schimbă )

Poză Twitter

Comentezi folosind contul tău Twitter. Dezautentificare / Schimbă )

Fotografie Facebook

Comentezi folosind contul tău Facebook. Dezautentificare / Schimbă )

Fotografie Google+

Comentezi folosind contul tău Google+. Dezautentificare / Schimbă )

Conectare la %s