Capitol 1- teorie

1.Care este diferena dintre un sistem de capt i o gazd? Enumerai tipurile de sisteme
terminale (de capt). Este un server WEB sistem terminal?
R: Nu este nicio diferenta. Pe tot parcursul testului, cuvintele host si end system sunt
folosite alternativ.Sistemele terminale includ PCs, statii de lucru, servere Web, servere mail,
Internet-connected PDAs, WebTVs, etc.
2. Cuvntul protocol este adesea utilizat pentru a descrie relaiile diplomatice. Dai un
exemplu de protocol diplomatic.
R: S presupunem c Alice, ambasador a rii A dorete s-l invite pe Bob, ambasador al
rii B la cina. Alice nu-l suna pur si simplu pe Bob i-i spune, "vino la cina noastra acum ". n
schimb, ea l suna pe Bob i ii sugereaz o dat i or. Bob poate sa rspunda prin a spune ca
nu e disponibil la acea data, dar el este disponibil alt dat. Alice i Bob continua s trimit
"mesaje" nainte i napoi pn cnd sunt de acord cu o dat i or. Bob apoi apare la
ambasada la data stabilita, sperm, nu mai mult de 15 minute nainte sau dup ora stabilita.
Protocoale diplomatice permit, de asemenea,pentru oricare dintre Alice sau Bob sa anuleze
politicos angajamentul n cazul n care au scuze rezonabile.
3. Ce este un program client? Ce este un program server? Cere i primete un program
de tip server servicii de la un program client?
R: Un program networking are de obicei dou programe, fiecare rulnd pe o gazd diferit,
comunicand ntre ele. Programul care iniiaz comunicarea este clientul. De obicei, programul
client cere si primete servicii din programul server.
4. Enumerai 6 tehnologii de acces. Clasificai-le pe fiecare fie ca acces rezidenial, acces
la nivelul companiei, sau acces mobil.
1. Dial-up modem la liniile telefonice: rezidential;
2. DSL la liniile telefonice: rezidential sau acces la nivelul unei companii mici;
3. Cablu la HFC: rezidential;
4. 100 Mbps switched Etherent: companie;
5. Wireless LAN: acces mobil;
6. Acces telefon mobil (de exemplu, WAP): mobil
5. Viteza de transmise n HFC este dedicat sau partajat ntre utilizatori? Exist
posibilitatea apariiei coliziunilor n canalul HFC pentru descrcare (downstream)? De ce
sau de ce nu?
R:Lime de band HFC este mprit intre utilizatori. Pe canalul de
descarcare(downstream), toate pachetele provin de la o singur surs, i anume, terminalul(the
head end??). Astfel, nu exist coliziuni pe canalul descarcare.
6. Enumerai tehnologiile de acces rezidenial din oraul vostru. Pentru fiecare tip de
acces furnizai viteza permis pentru descrcare, pentru ncrcare i preul lunar.
R:Posibilitile actuale includ: dial-up, DSL, cablu modem, fibre-to-the-home.
7.Care este viteza de transmisie a reelelor locale de tip Ethernet? Pentru o vitez dat
se poate ca fiecare utilizator din LAN s transmit continuu la acea vitez?
R:LAN Ethernet au rate de transmisie de 10 Mbps, 100 Mbps, 1 Gbps i 10 Gbps.
Pentru un X Mbps Ethernet (unde X = 10, 100, 1000 sau 10000), un utilizator poate
transmite continuu la rata X Mbps daca acel utilizator este singura persoana care trimite date.
Dac exist mai mult de un utilizator activ, atunci fiecare utilizator nu poate transmite continuu la
X Mbps.
8. Care sunt mediile fizice pe care poate lucra Ethernet-ul?
R:Ethernet cel mai frecvent ruleaza pe srm de cupru perechi rasucite(over twisted-pair
copper wire) i cablu coaxial "subire".De asemenea, poate rula pe link-uri fibre optice i cablu
coaxial gros.
9. Modem-urile cu apel, HFC, DSL i FFTH sunt utilizate pentru accesul rezidenial. Pentru
fiecare dintre aceste tehnologii specificai gama vitezelor de comunicaie i comentai
dac viteza respectiv este partajat sau dedicat.
R:Modemuri dial-up: pn la 56 Kbps, lime de band este dedicata, ISDN: pn la 128
kbps, lime de band este dedicata; ADSL: canal de descarcare(downstream) este 0.5-8 Mbps,
canal de incarcare(upstream) este de pn la 1 Mbps, lime de band este dedicata, HFC,
canalul descarcare este de 10-30 Mbps i canal incarcare este, de obicei, mai puin de ctiva
Mbps, lime de band este partajat. FTTH: 2 -10Mbps ncrcare, 10-20 Mbps descrcare, de
lime de band nu este partajata.
10.Descriei cele mai populare tehnologii fr fir de acces la Internet din ziua de astzi.
Comparai-le.
R:Exist dou tehnologii de acces la Internet fr fir cele mai populare astzi:
a) LAN Wireless
ntr-o reea LAN fr fir, utilizatorii wireless transmit / primesc pachete la / de la o staie de
baza(punct de acces fr fir), pe o raz de civa zeci de metri. Staia de baz este de obicei
conectat la Internet prin cablu i astfel servete pentru a conecta utilizatorii wireless la reeaua
cablat.
b) reele de acces wireless wide-area
n aceste sisteme, pachetele sunt transmise prin aceeai infrastructur wireless utilizate pentru
telefonie mobila, cu staia de baz fiind astfel gestionate de un furnizor de telecomunicaii.
Aceasta ofer acces wireless la utilizatori pe o raz de zeci de kilometri de staia de baz.
11.Care sunt avantajele unei reele cu comutare de circuite fa de o reea cu comutare
de pachete?
R:O reea cu comutare de circuite poate garanta o anumit cantitate de lime de band end-
to-end pe durata unui apel. Cele mai multe reele de pachete comutate de astzi (inclusiv
Internet) nu pot face nicio garanie end-to-end a limii de band.
12.Ce avantaje are TDM fa de FDM ntr-o reea cu comutare de circuite?
R:ntr-o reea cu comutarea de pachete, pachetele din diferite surse fluxeaza pe un link
neurmand un tipar fix, predefinit. n circuitul de comutare TDM, fiecare gazd ocupa acelai slot
pe un cadru TDM rotativ(revolving).
14.Presupunei c exist exact un pachet comutat ntre o gazd emitoare i o gazd
receptoare. Vitezele de comunicaie ntre gazda emitoare i switch i switch i gazda
receptoare sunt R1 i respectiv R2. Presupunei ca switch-ul utilizeaz
comutarea de pachete de tipul memoreaz i trimite mai departe, care este ntrzierea
total capt-la-capt la trimiterea unui pachet de lungime L? (se ignor coada, ntrzierea
de propagare i ntrzierea de propagare).
R:La momentul t0 gazd care trimite ncepe s transmit. La momentul t1 = L/R1, gazda care
trimite completeaza transmisia i ntregul pachet este primit la router (fara ntrziere de
propagare). Deoarece router are ntregul pachet n momentul t1,poate ncepe s transmit
pachetul la gazda care primete n momentul t1. La momentul t2 = T1 + L/R2, router-ul
completeaz transmisia i ntregul pachet este primit de gazda care primeste (din nou, fr
ntrziere de propagare). Astfel, ntrzierea cap-la-capt este L/R1 + L/R2.
15.Care este cheia pentru a distinge ntre tier 1 ISP i tier 2 ISP?
R:Un Tier-1 ISP se conecteaz la toate celelalte Tier-1 ISP;un tier-2 ISP se conecteaz la
numai cteva din tier-1 ISP. De asemenea, un tier-2 ISP este un client al unuia sau mai multor
tier-1.
16.Presupunei c un utilizatorii partajeaz o legtur de 2 Mbps. Presupunei de
asemenea c fiecare utilizator transmite continuu la 1 Mbs atunci cnd transmite, dar
fiecare transmite doar 20% din timp.
a). Dac se utilizeaz comutarea cu circuite ci utilizatori pot fi suportai?
b). Pentru restul problemei se presupune utilizarea de pachete comutate. De ce nu exist
o ntrziere n coad dac transmit n acelai timp doi sau mai puini utilizatori?
c). Gsii probabilitatea ca un anumit utilizator s transmit.
d). Presupunei acum c exist trei utilizatori. Gsii probabilitatea ca la un moment de
timp dat s transmit toi utilizatorii. Gsii fracia de timp pe durata creia coada de
ateptare crete.
R:a).2 utilizatori pot fi susinuti, deoarece fiecare utilizator necesit jumtate din limea de
band.
b)Din moment ce fiecare utilizator are nevoie de 1Mbps la transmitere, n cazul n care
doi sau mai puini utilizatori transmit simultan, se va cere un maxim de 2Mbps. Deoarece lime
de band disponibila a link-ului partajat este 2Mbps, nu va fi nici o ntrziere de ateptare
nainte de link. ntruct, n cazul n care trei utilizatori transmit simultan, limea de band
necesar va fi 3Mbps, care este mai mult dect limea de band disponibil a link-ul partajat.
In acest caz, va exista ntrziere de ateptare nainte link-ul.
c) Probabilitatea c un utilizator dat transmite = 0.2

d) Probabilitatea ca toti cei trei utilizatori transmit simultan =

=0.008.Deoarece coada crete atunci cnd toi utilizatorii transmit,
fraciunea de timp n care coada creste (care este egal cu probabilitatea
c toti cei trei utilizatori transmit simultan) este 0.008.
17.Considerai trimiterea unui pachet de la o gazd surs la una destinaie pe o rut fix.
Enumerai componentele ntrzierii capt-la-capt. Care dintre acestea sunt constante i
care sunt variabile?
R:Componentele ntrzierii sunt ntrzieri de procesare, ntrzieri de transmitere, intarzieri de
propagare , i ntrzieri de ateptare. Toate aceste ntrzieri sunt constante, cu excepia
intarzierii de ateptare, care este variabila.
18.Vizitai applet-ul Transmission Versus Propagation delay de pe site-ul autorilor
(http://wps.aw.com/aw_kurose_network_5/111/28536/7305312.cw/index.html). Pe baza
vitezei, ntrzierii de propagare i mrimea pachetului, gsii o combinaie pentru care
emitorul termin transmisia nainte ca primul bit din pachet s ajung
la receptor. Gsii alt combinaie pentru care primul bit din pachet atinge receptorul
nainte ca emitorul s termine transmisia.
R:Java Applet
19.Ct de mult i trebuie unui pachet de 1000 de octei s se propage pe o legtur lung
de 2500 Km cu o vitez de propagare de 2,5 108 m/s i o vitez de transmisie de 2 Mbps?
Mai general, ct timp este necesar pentru un pachet de lungime L s se
propage pe o distan d cu viteza de R bps?
R:10msec; d/s; no; no
20.Presupunei c gazda A dorete s trimit un fiier mare la gazda B. Calea dintre A i
B care trei legturi avnd vitezele de comunicaie R1 = 500 kbps, R2 = 2 Mbps i R3 = 1
Mbps.
a). Presupunnd c nu exist un alt trafic pe reea, care este viteza de transfer
(throughput) pentru fiier?
b). Presupunei c fiierul are 4 milioane de octei. Diviznd mrimea fiierului viteza
fluxului de transfer, aproximai ct timp va dura transferul fiierului la gazda B?
c). Repetai a i b, dar cu R2 redus la 100 Kb/s.
R:a) 500 kbps
b) 64 seconds
c) 100kbps; 320 seconds
21.Presupunei c sistemul de capt A dorete s trimit un fiier mare la sistemul de
capt B. La un nivel foarte nalt descriei cum sistemul de capt A creeaz pachete pentru
fiier. Atunci cnd unul dintre aceste pachete ajunge la un comutator de pachete, ce
informaie din pachet folosete comutatorul pentru a determina legtura la care este
trimis mai departe pachetul? De ce este comutatorul de pachete n Internet analog cu
conducerea de la un ora la altul i ntrebnd direcia n care se afl destinaia?
R:Sistemul de capat A sparge fiierul mare n buci. Pentru fiecare bucat, se adaug antet
genernd mai multe pachete din file. Antetul n fiecare pachet include adresa de destinatie:
sistemul de capat B. Comutatorul de pachete utilizeaz adresa destinaie pentru a determina
legtur de ieire. A intreba ce drum s ia este analog cu a intreba un pachet care legtur de
ieire ar trebui s fie transmisa mai departe, avnd n vedere pachetul de
adresa.
22.Vizitai applet-ul Queing and Loss de pe site-ul autorilor. Care este viteza maxim de
emisie i viteza minim de emisie? Cu aceast vitez, care este intensitatea traficului?
Rulai applet-ul cu aceste viteze i determinai ct timp este necesar pentru ca s apar
pierderea de pachete. Repetai apoi experimentul a doua oar i determinai din nou ct
timp este necesar s apar pierderea de pachete? Sunt valorile diferite? De ce sau de ce
nu?
R:Java Applet
23.Enumerai cinci sarcini pe care trebuie s le ndeplineasc un nivel. Este posibil ca
una (sau mai multe) dintre aceste sarcini s fie realizate de dou sau mai multe niveluri?
R:Cinci sarcini generice sunt: de control al erorilor, controlul fluxului, segmentarea i
reasamblarea, multiplexare, i configurarea conexiunii. Da, aceste sarcini pot fi
copiate(duplicate) n diferite niveluri. De exemplu,controlul erorilor este adesea realizat de mai
multe nieveluri.
24.Care sunt cele cinci niveluri din stiva protocolului Internet? Care este pricipala
responsabilitate pentru fiecare dintre aceste niveluri?
R:Cele cinci straturi din stiva protocoalului Internet sunt - de sus n jos -nivelul aplicaie, nivelul
transport,nivelul reea, nivelul legtur si nivelul fizic. Principalele responsabiliti sunt
prezentate n seciunea 1.5.1.
25.Ce este un mesaj de la nivelul aplicaie? Dar un segment de la nivelul transport? Dar o
datagram de la nivelul reea? Dar un cadru de la nivelul legtur de date?
R:Mesajul la nivel de aplicaie: date pe care o aplicatie vrea s le trimit i le trece pe
nivelul transport; segmentul de la nivelul transport: generate de nivelul transport i
ncapsuleaza mesajul de la nivel aplicaie cu antetul de la nivel transport; datagrama de la nivel
aplicatie: incapsuleaza segmentul de la nivel transport cu un antet de la nivel retea;cadru de la
nivel legatura de date: ncapsuleaz datagrama de la nivel reea cu un antet de la nivel legatura
de date.
26.Care nivel din stiva protocolului Internet include procesul de rutare? Care nivel
include procesul de comutare a legturii de date? Ce niveluri are un proces gazd?
R:Nivelul procesului de rutare de la 1 la 3. (Acesta este un pic de minciun alba, aa cum
routerele moderne, uneori, acioneaz ca firewall-uri sau componente cache, iar nivelul de
proces 4 de asemeni).nivelul care include procesuld e comutare a legaturii de dare de la 1 la 2.
Procese gazda:toate cele cinci niveluri.
27.Care este diferena ntre un virus, un vierme i un cal Troian?
R:a) Virus.Necesit o form de interaciune uman s se rspndeasc. Exemplu
clasic:virusi la nivelul e-mail.
b).Viermi: Nu are nevoie de reproducere prin utilizator. Viermii n gazdele infectate
scaneaz adrese IP i numerele port, n cutarea de procese vulnerabile pentru a le infecta.
 c) cal troian: Ascuns,parti intortocheate ale unor altfel de sofware folositoare(Hidden,
devious part of some otherwise useful software).
28.Descriei cum poate fi creat un botnet, i cum poate fi folosit ntr-un atac de tip DDoS?
R:Crearea unui botnet necesit un atacator pentru a gsi vulnerabilitate n unele aplicaii sau
sistem (de exemplu, exploatnd vulnerabilitatea buffer overflow care ar putea exista ntr-o
aplicatie). Dup ce a gasit vulnerabilitatea, atacatorul are nevoie sa scaneze gazdele care
sunt vulnerabile.Obiectivul este de fapt sa compromite o serie de sisteme profitnd de
vulnerabilitatea deosebit. Orice sistem care este parte a unui botnet poate
scana automat mediul nconjurtor i propaga exploatand vulnerabilitatea.O
proprietate important a unui astfel de botnet este c iniiatorul botnet-ului poate remotely
control?? i emite comenzi catre toate nodurile botnet-ului. Prin urmare, devine
posibil pentru atacator s emit o comand pentru toate nodurile, care vizeaza un singur
nod (de exemplu, toate nodurile din botnet pot fi comandate de ctre atacator sa
trimits un mesaj TCP SYN catre int, care ar putea duce la o avalansa de atacuri SYN TCP
catre int).
29.Presupunei c Bob i Alice trimit pachete ntre ei pe o reea de calculatoare.
Presupunei c poziia lui Truddy n reea este astfel nct ea poate captura toate
pachetele trimise de Alice i trimite ce vrea Bob; ea poate de asemenea s captureze
toate pachetele trimise de Bob i s trimit ce dorete Alice. Enumerai unele lucruri
maliioase (rutcioase) pe care le poate face Truddy din aceast poziie.
R:Trudy poate pretinde a fi Bob catre Alice (i vice-versa) i parial sau complet poate
modifica mesajul/mesajele s fie trimise de la Bob la Alice. De exemplu, ea poate cu uurin
schimba expresia "Alice, i datorez 1,000 dolari" in "Alice, i datorez 10.000 de dolari".
Mai mult, Trudy poate pierde chiar pachetele care sunt trimise de ctre Bob la Alice
(i viceversa), chiar dac pachetele de la Bob la Alice sunt criptate.
Capitolul 2 - Intrebari

1. Enumerai cinci aplicaii Internet, care nu sunt private, i protocoalele de la nivelul

aplicaie pe care le utilizeaz.
Web: HTTP, fiiere de transfer : FTP, autentificare de la distan: Telnet, News Network: NNTP,
e-mail: SMTP.
2. Care este diferena ntre arhitectura reelei i arhitectura aplicaiei?
Network architecture refers to the organization of the communication process into layers (e.g.,
the five-layer Internet architecture). Application architecture, on the other hand, is designed by
an application developer and dictates the broad structure of the application (e.g., client-server or
P2P)
Arhitectur de reea se refer la organizarea procesului de comunicare n straturi (de exemplu,
arhitectura de Internet in cinci straturi). Arhitectura aplicaiei, pe de alt parte, este proiectata de
ctre un dezvoltator de aplicaii i dicteaz structura larg de aplicare (de exemplu, client-server
sau P2P).
3. Care proces este client i care server n cazul unei sesiuni de comunicaie ntre o
pereche de procese?
The process which initiates the communication is the client; the process that waits to be contacted is
the server.
Procesul care iniiaz comunicarea este clientul; proces ul care ateapt s fie contactat este
serverul.
4. Pentru o aplicaie P2P care partajeaz fiiere sunt de acord cu fraza Nu exist
nici o noiune privind partea de client i de server n cadrul unei sesiuni de
comunicaie. De ce sau de ce nu?
No. As stated in the text, all communication sessions have a client side and a server side. In a
P2P file-sharing application, the peer that is receiving a file is typically the client and the peer
that is sending the file is typically the server.
Nu. Aa cum se menioneaz n text, toate sesiunile de comunicare au o partea de client i o parte
de server. ntr-o aplicaie P2P file-sharing, in mod egal primete un fiier care este de obicei
clientul i in aceeasi masura trimite fisierul este de obicei serverul.
5. Ce informaie se utilizeaz de ctre un proces care se execut pe o gazd, pentru
a identifica un proces executat pe alt gazd?
The IP address of the destination host and the port number of the destination socket.
Adresa IP a gazdei destinaie i numrul de port de la priza de destinaie.
6. Presupunei c dorii s realizai ct mai rapid posibil o tranzacie de la un client
cu acces de la distan la un server. Vei utiliza UDP sau TCP. De ce?
You would use UDP. With UDP, the transaction can be completed in one roundtrip time (RTT) -
the client sends the transaction request into a UDP socket, and the server sends the reply back to
the client's UDP socket. With TCP, a minimum of two RTTs are needed - one to set-up the TCP
connection, and another for the client to send the request, and for the server to send back the
reply.
Ar trebui s utilizai UDP. Cu UDP, tranzacia poate fi finalizat ntr-un timp dus-ntors
(roundtrip) (RTT) - clientul trimite cererea de tranzacie ntr-un socket UDP, iar serverul trimite
rspuns napoi la priza UDP clientului. Cu TCP, este nevoie de un minim de dou RTT - o s
seteze conexiunea TCP, i un altul pentru ca clientul sa trimita cererea, i pentru ca serverul sa
trimita napoi rspunsul.
7. Referitor la figura 2.4, s-a vzut c nici una dintre aplicaiile listate n figur nu
necesit att integritatea datelor (pierderea de date) ct i constrngeri temporale.
Putei concepe o aplicaie care nu suport pierderea de date dar care are i
constrngeri temporale?
There are no good examples of an application that requires no data loss and timing. If you know
of one, send an e-mail to the authors.
Nu exist exemple bune de o aplicaie care fara nici o pierdere de date i care nu necesita
sincronizare. Dac tii de una, trimite un e-mail pentru autori.
8. Enumerai 4 clase generalizate de servicii pe care le poate furniza nivelul
transport. Pentru fiecare clas precizai dac aceasta este furnizat de UDP sau
TCP (sau ambele).
a) Reliable data transfer
TCP provides a reliable byte-stream between client and server but UDP does not.
b) A guarantee that a certain value for throughput will be maintained
Neither
c) A guarantee that data will be delivered within a specified amount of time
Neither
d) Security
Neither
a) transfer de date fiabile
TCP ofera un byte-stream fiabil ntre client i server, dar UDP nu.
b) O garanie c o anumit valoare pentru transfer va fi meninut
nici una
c) o garanie c datele vor fi livrate ntr-o perioad de timp specificat
niciuna
d) Securitate
niciuna
9. Reamintim c TCP poate fi extins cu SSL pentru a furniza servicii de securitate de
tip proces-la-proces. SSL operaz la nivelul aplicaie sau la nivelul transport? Ce
trebuie s fac un dezvoltator de aplicaii dac dorete ca TCP-ul s fie extins cu
SSL?

SSL operates at the application layer. The SSL socket takes unencrypted data from the
application layer, encrypts it and then passes it to the TCP socket. If the
application developer wants TCP to be enhanced with SSL, she has to include the SSL code
in the application.
SSL opereaz la nivelul de aplicaie.Socket SSL preia datele necriptate din stratul de cerere,
il cripteaz i apoi il trece in priza TCP. Dac dezvoltatorul de aplicaii vrea ca TCP s fie
mbuntit cu SSL, el trebuie s includ codul SSL n aplicare.
10. Care este scopul protocolului cu confirmare (handshaking protocol)?
A protocol uses handshaking if the two communicating entities first exchange control packets
before sending data to each other. SMTP uses handshaking at the application layer whereas
HTTP does not.
Un protocol foloseste handshaking n cazul n care intre cele dou entiti de comunicare primul
schimb al pachetelor de control trimite date la fiecare celellalte. SMTP utilizeaz handshaking
la stratul de aplicaie n timp ce HTTP nu.
11. De ce ruleaz HTTP, FTP, SMTP i POP3 pe TCP mai degrab dect pe UDP?
The applications associated with those protocols require that all application data be received in
the correct order and without gaps. TCP provides this service whereas UDP does not.
Aplicaiile asociate cu aceste protocoale cer ca toate datele de aplicare s fie primite n ordinea
corect i fr lacune. TCP ofer acest serviciu n timp UDP nu
12. Peresupunei c exist un site e-commerce care dorete s pstreze nregistrrile
vnzrilor pentru fiecare client. Descriei modul n care se realizeaz acest lucru
utiliznd cookies.
When the user first visits the site, the site returns a cookie number. This cookie number is stored
on the users host and is managed by the browser. During each subsequent visit (and purchase),
the browser sends the cookie number back to the site. Thus the site knows when this user (more
precisely, this browser) is visiting the
Atunci cnd utilizatorul viziteaz prima data site-ul, acesta returneaz un numr de cookie. Acest
numr cookie este stocat pe gazda utilizatorului i este gestionat de ctre browser. n timpul
fiecrei vizite ulterioare (si a cumprarii), browser-ul trimite numrul cookie napoi la site.
Astfel, site-ul cnd acest utilizator (mai exact, acest browser), viziteaza site-ul.
13. Descriei cum cache-ul unei pagini Web (Wen caching) poate reduce ntrzierea
privind cererea unui obiect. Va reduce acest cache ntrzierea pentru toate
obiectele cerute de un utilizator sau doar pentru unele? De ce?
Web caching can bring the desired content closer to the user, perhaps to the same LAN to
which the users host is connected. Web caching can reduce the delay for all objects, even objects
that are not cached, since caching reduces the traffic on links.
Web caching poate aduce coninutul dorit "aproape" utilizatorului, probabil la aceeai reea
LAN la care este conectat gzda utilizatorului. Cache-ul poate reduce ntrziere pentru toate
obiectele, chiar i obiecte care nu sunt n cache, deoarece caching reduce traficul pe link-uri.
14. Utilizai telnet ntr-un server Web i trimitei un mesaj multilinie. Includei n
mesajul cerere linia header If-modified-since: pentru a fora un mesaj de rspuns
cu codul 304 Not Modified.
Issued the following command (in Windows command prompt) followed by the HTTP GET
message to the utopia.poly.edu web server:
> telnet utopia.poly.edu 80
Since the index.html page in this web server was not modified since Fri, 18 May 2007 09:23:34
GMT, the following output was displayed when the above commands were issued on Sat, 19
May 2007. Note that the first 4 lines are the GET message and header lines input by the user and
the next 4 lines (starting from HTTP/1.1 304 Not Modified) is the response from the web server.
A emis urmtoarea comand (n Windows command prompt), urmata de HTTP GET mesajul la
"utopia.poly.edu" server de web:
> Telnet utopia.poly.edu 80
Deoarece pagina index.html din acest server de web nu a fost modificat inca din vineri
2007-5-18 09:23:34 GMT, urmtoarea ieire a fost afiata cnd toate comenzile de mai
sus au fost emise pe 19/05/2007. Reinei c n primele 4 linii sunt mesaje GET si linii
antet introduse de ctre utilizator i n urmtoarele 4 linii (ncepnd de la HTTP/1.1 304
nemodificate) este rspunsul de la serverul de web.

15. De ce se spune c protocolul FTP trimite informaia n afara benzii?

FTP uses two parallel TCP connections, one connection for sending control information (such as
a request to transfer a file) and another connection for actually transferring the file. Because the
control information is not sent over the
same connection that the file is sent over, FTP sends control information out of band.
FTP utilizeaz dou conexiuni paralele TCP, o conexiune pentru transmiterea de informaii de
control (cum ar fi o cerere pentru a transfera un fiier) i o alt conexiune pentru transferul
efectiv a fiierului. Pentru ca informaiile de control nu sunt trimise n aceeai conexiune fisierul
este trimis dupa, FTP trimite informaii de control n afara benzii.
 16. Presupunei c Alice, cu un cont de e-mail bazat pe Web (cum at fi Hotmail sau
gmail) trimite un mesaj lui Bob, care acceseaz mail-ul su de la serverul su de
mail utiliznd POP3. Discutai cum se preia mesajul de la gazda Alice i se depune
la gazda Bob. Asigurai-v c enumerai seria de protocoale de la nivelul aplicaie
care sunt utilizate pentru a muta mesajul ntre cele dou gazde.
Message is sent from Alices host to her mail server over HTTP. Alices mail server then sends
the message to Bobs mail server over SMTP. Bob then transfers the message from his mail
server to his host over POP3.
Mesajul este trimis de la gazda Alice la serverul ei de e-mail pe HTTP. Serverul de mail a lui
Alice trimite apoi un mesaj la serverul de mail lui Bob pe SMTP. Bob transfer apoi mesajul de
pe serverul gazdei sale pe POP3. .
17. Tiprii header-ul (capul de tabel) unui mesaj de e-mail pe care l-ai recepionat
recent. Cte linii header de tip Received: sunt? Analiza-i fiecare dintre acestelinii
headerdinmesaj.
Received: from 65.54.246.203 (EHLO bay0-omc3-
s3.bay0.hotmail.com) (65.54.246.203) by
mta419.mail.mud.yahoo.com with SMTP;
Sat, 19 May 2007 16:53:51 -0700
Received: from hotmail.com ([65.55.135.106]) by
bay0-omc3-s3.bay0.hotmail.com with
Microsoft SMTPSVC(6.0.3790.2668);
Sat, 19 May 2007 16:52:42 -0700
Received: from mail pickup service by hotmail.com
with Microsoft SMTPSVC; Sat, 19 May
2007 16:52:41 -0700
Message-ID: <BAY130-
F26D9E35BF59E0D18A819AFB9310@p
hx.gbl>
Received: from 65.55.135.123 by
by130fd.bay130.hotmail.msn.com with
HTTP; Sat, 19 May 2007 23:52:36 GMT
From: "prithula dhungel"
<prithuladhungel@hotmail.com>
To: prithula@yahoo.com
Bcc:
Subject: Test mail
Date: Sat, 19 May 2007 23:52:36 +0000
Mime-Version: 1.0
Content-Type: Text/html; format=flowed
Return-Path: prithuladhungel@hotmail.com
Figure: A sample mail message header
Received: This header field indicates the sequence in which the SMTP servers send
and receive the mail message including the respective timestamps.
In this example there are 4 Received: header lines. This means the mail message passed
through 5 different SMTP servers before being delivered to the receivers mail box. The
last (forth) Received: header indicates the mail message flow from the SMTP server of
the sender to the second SMTP server in the chain of servers. The senders SMTP server
 is at address 65.55.135.123 and the second SMTP server in the chain is
by130fd.bay130.hotmail.msn.com.
The third Received: header indicates the mail message flow from the second SMTP
server in the chain to the third server, and so on.
Finally, the first Received: header indicates the flow of the mail message from the forth
SMTP server to the last SMTP server (i.e. the receivers mail server) in the chain.
Primit: Acest antet indic succesiunea n care serverele SMTP trimit i primesc mesaje e-
mail, inclusiv marcajele de timp respective.
n acest exemplu, exist 4 linii de antet "Received:". Aceasta nseamn c mesajul e-mail
a trecut prin 5 servere SMTP nainte de a fi livrate la box-mail-ul destinatarului. Ultimul
(al patrulea) antet "Receveid:" indic fluxul de masaje mail de pe serverul SMTP a
expeditorului la al doilea server SMTP n lanul de servere. Serverul SMTP a
expeditorului este la adresa 65.55.135.123 i al doilea serverul SMTP n lanul este
by130fd.bay130.hotmail.msn.com.
Al treilea antent"receveid:" indic fluxul de mesaje e-mail de la al doilea serverul SMTP
din lan la al treilea server, i aa mai departe.
n cele din urm, primul antet "primite:" indic fluxul de mesaje e-mail de la al patrulea
server SMTP la ultimul server (adic serverul de mail al receptorului) n lan.
Message-ID: Mesajul a fost dat acestui numar BAY130-
F26D9E35BF59E0D18A819AFB9310@phx.gbl (de bay0-omc3-s3.bay0.hotmail.com
Message-id este un ir unic atribuit de ctre sistemul de pot electronic atunci cnd
mesajul este creat pentru prima dat. .
De la: Aceasta indic adresa de e-mail a expeditorului de e-mail. n exemplul dat,
expeditorul este "prithuladhungel@hotmail.com"
Pentru : Acest cmp indic adresa de e-mail a destinatarului de e-mail. n exemplu,
receptorul este "prithula@yahoo.com"
Subiect: Aceasta d subiectul e-mail-ului (dac este cazul specificat de expeditor). n
exemplu, subiectul specificat de expeditor este "e-mail de testare".
Return-Path: This specifies the email address to which the mail will be sent if the
receiver of this mail wants to reply to the sender. This is also used by the senders mail
server for bouncing back undeliverable mail messages of mailer-daemon error messages.
In the example, the return path is prithuladhungel@hotmail.com.
Data: data i ora la care mail-ul a fost trimis de ctre expeditor. n exemplu, expeditorul a
trimis e-mail pe data de 19 mai 2007, la 23:52:36 GMT.
MIME-versiune: MIME versiunea utilizat pentru e-mail. n exemplu, aceasta este de
1,0.
Content-Type: tip de coninut n corpul mesajului e-mail. n exemplu, este "text / html".
Return-Path: Aceasta specifica adresa de e-mail la care e-mail va fi trimis n cazul n care
receptorul acestui e-mail vrea s rspunda expeditorului. Acest lucru este, de asemenea,
folosit de ctre serverul de mail al expeditorului mesajele de-mail nu pot fi livrate de
mailer-daemon mesaje de eroare. n exemplu, calea de ntoarcere este
"prithuladhungel@hotmail.com".
18. Care este diferena n POP3, din perspectiva utilizatorului, ntre modul download-
and-delete i dwonload-and-keep?

With download and delete, after a user retrieves its messages from a POP server, the messages
are deleted. This poses a problem for the nomadic user, who may want to access the messages
from many different machines (office PC, home PC, etc.). In the download and keep
configuration, messages are not deleted after the user retrieves the messages. This can also be
inconvenient, as each time the user retrieves the stored messages from a new machine, all of non-
deleted messages will be transferred to the new machine (including very old messages).
Cu descrcarea i tergerea, dup ce un utilizator preia mesajele de pe un server POP, mesajele
sunt terse. Acest fapt reprezint o problem pentru utilizator nomazi, care ar putea dori s
acceseze mesajele de la mai multe masini diferite (PC de birou, PC-ul acas, etc). n download si
in keep configuration, mesajele nu sunt terse dup ce utilizatorul preia mesajele. Acest lucru
poate fi, de asemenea, incomod, ca de fiecare dat cnd utilizatorul preia mesajele stocate la o
main nou, toate mesajele non-terse vor fi transferate la noua main (inclusiv mesaje foarte
vechi).
19. Este posibil ca la nivelul unei organizaii serverul de mail i cel de Web s aib
exact acelai alias pentru numele gazdei (de exemplu foo.com)? Care va fi tipul
pentru RR care conine numele gazdei al serverului de mail?
Yes an organizations mail server and Web server can have the same alias for a host name. The
MX record is used to map the mail servers host name to its IP address.
Da serverul de mail al organizaiei i serverul Web poate avea aceleai alias-uri pentru un nume
de gazd. nregistrarea MX este folosita pentru a mapa numele de gazd al serverului de mail de
la adresa IP.
20. Presupunei c n BitTorrent, Alice ofer lui Bob blocuri de date (chunks) la un
interval de 30 de secunde. Va trebui Bob s ntoarc favoarea i s-i ofere blocuri
de date lui Alice n acelai interval? De ce sau de ce nu?
It is not necessary that Bob will also provide chunks to Alice. Alice has to be in the top 4
neighbors of Bob for Bob to send out chunks to her; this might not occur even if Alice is
provides chunks to Bob throughout a 30-second interval.
Nu este necesar ca Bob sa ofere de asemenea chunks lui Alice. Alice trebuie s fie n primii 4
vecinii ai lui Bob pentru ca Bob sa-i trimita chunks ei ;acest lucru s-ar putea s nu apar chiar
dac Alice ofer chunks lui Bob de-a lungul a 30-lea cel de-al doilea interval.
21. Considerai un nou partener Alice care se altur la BitTorrent fr a procesa nici
un chunk. Fr nici un chunk, ea nu poate deveni un ncrctor (uploader) de vrf
dintre cei 4 pentru nici un partener deoarece nu are nimic de ncrcat. Cum va
prelua atunci Alice primul chunk?
Alice will get her first chunk as a result of she being selected by one of her neighbors as a result
of an optimistic unchoke, for sending out chunks to her.
Alice va primi primul chunk, ca urmare a a fost selectat de ctre unul dintre vecinii ei, ca urmare
a unui "unchoke optimist," pentru a-i trimite chunk-uri ei.
22. Ce este overlay network. Include rutere? Care sunt marginile ntr-o astfel de
reea? Cum se creeaz i se menine o query-flooding overlay network
(interogare prin inundare)?
The overlay network in a P2P file sharing system consists of the nodes participating in the file
sharing system and the logical links between the nodes. There is a logical link (an edge in
graph theory terms) from node A to node B if there is a semi-permanent TCP connection between
A and B. An overlay network does not include routers. With Gnutella, when a node wants to join
the Gnutella network, it first discovers (out of band) the IP address of one or more nodes
already in the network. It then sends join messages to these nodes. When the node receives
confirmations, it becomes a member of the of Gnutella network. Nodes maintain their logical
links with periodic refresh messages.
Reeaua de acoperire ntr-un sistem de partajare de fiiere P2P este format din nodurile
participante la sistemul de partajare de fiiere i legturile logice ntre noduri. Exist o legtur
logic (un "avantaj" n ceea ce privete teoria grafurilor) de la nodul A la nodul B, n cazul n
care exist o conexiune semi-permanenta TCP ntre A i B. O reea de suprapunere nu include
routere. Cu Gnutella, atunci cnd un nod dorete s adere la reeaua Gnutella, se descoper mai
nti ("n afara benzii"), adresa IP a unuia sau mai multor noduri deja n reea. Acesta trimite apoi
se alture mesaje de la aceste noduri. Cnd nodul primete confirmri, ea devine un membru al
reelei Gnutella. Nodurile menin legturile logice cu mesaje de remprosptare periodic.
23. n ce mod o mesagerie instantanee cu index centralizat este un hibrid ntre
arhitecturile client-serve i P2P?
It is a hybrid of client server and P2P architectures:
a)There is a centralized component (the index) like in the case of a client server system.
b)Other functions (except the indexing) do not use any kind of central server. This is similar to
what exists in a P2P system.
24. Presupunei o DHT cu o topologie suprapus de tip plas (adic, fiecare partener
urmrete toi partenerii din sistem). Care sunt avantajele i dezavantajele unui
DHT circular (fr surtturi)?
Mesh DHT: The advantage is to a route a message to the peer closest to the key, only one hop
is required; the disadvantage is that each peer must track all other peers in the in the
DHT. Circular DHT: the advantage is that each peer needs to track only a few other peers;
the disadvantage is that O(N) hops are needed to route a message to a peer responsible for
the key.
Mesh DHT: Avantajul este ca pentru trasa un mesaj egal cu cel mai apropiat key, este necesar
doar un hop, dezavantajul este c fiecare la egal la egal trebuie s urmrii toate celelalte colegii
din in DHT. Circular DHT: avantaj este c fiecare egal nevoie pentru a urmri doar cteva alte
colegii; dezavantajul este c O (n) hamei sunt necesare pentru a ruta un mesaj de la un egal
responsabile pentru cheie.
Este un hibrid intre un client-server i arhitecturi P2P:
Este o component centralizata (index) ca i n cazul unui sistem client-server.
Alte funcii (cu excepia indexarii), nu folosesc nici un fel de server central. Acest lucru este
similar cu ceea ce exist ntr-un sistem P2P.
25. Skype utilizeaz tehnica P2P pentru dou funcii importante. Care sunt acestea?
a) User location
b) NAT traversal
26. Enumerai cel puin 4 aplicaii diferite care sunt n mod natural potrivite pentru
arhitecturi P2P (Indicaie: fiiere distribuite i mesageria instantanee sunt dou
dintre ele).
a) File Distribution
b) Instant Messaging
c) Video Streaming
d) Distributed Computing
a) distribuie fiier
b) Instant Messaging
c) Video Streaming
d) Distributed Computing
27. Serverul UDP descris n seciunea 2.8 are nevoie numai de un socket, n timp ce
serverul TCP descris n seciunea 2.7 are nevoie de dou socket-uri. De ce? Cte
socket-uri trebuie s utilizeze serverul TCP pentru ca s suporte n conexiuni
simultane, fiecare de la un alt client gazd?
With the UDP server, there is no welcoming socket, and all data from different clients enters the
server through this one socket. With the TCP server, there is a welcoming socket, and each time a
client initiates a connection to the server, a new socket is created. Thus, to support n
simultaneous connections, the server would need n+1 sockets.
Cu serverul UDP, nu exist nici un soclu primitor, i toate datele de la diferii clieni intr la
server prin acest soclu . Cu serverul TCP, exist un soclu primitor, i de fiecare dat cnd un
client iniiaz o conexiune la server, este creat un nou soclu. Astfel, pentru a sprijini n conexiuni
simultane, serverul va avea nevoie de n +1 prize.
28. De ce trebuie ca programul server s fie executat nainte de programul client
pentru aplicaia client-server pe TCP descris n seciunea 2.7? De ce trebuie ca
programul client s fie executat nainte de programul server pentru aplicaia
client-server pe UDP descris n seciunea 2.8?
For the TCP application, as soon as the client is executed, it attempts to initiate a TCP connection
with the server. If the TCP server is not running, then the client will fail to make a connection.
For the UDP application, the client does not initiate connections (or attempt to communicate with
the UDP server) immediately upon execution
Pentru aplicarea TCP, de ndat ce clientul este executat, se ncearc a iniia o conexiune TCP
cu serverul. Dac TCP Server nu se execut, atunci clientul va eua pentru a face o conexiune.
Pentru aplicarea UDP, clientul nu iniiaza conexiuni (sau ncearca sa comunice cu serverul UDP)
imediat dup executare.
P1. Adevrat sau fals?
a. Un utilizator cere o pagin Web care const din text i imagini. Pentru
aceast pagin, clientul va trimite un mesaj de tip cerere i va recepiona
patru mesaje de tip rspuns.
b. Dou pagini distincte (de exemplu www.mit.edu/research.html i
www.mit.edu/students.html) pot trimite peste aceeai conexiune
persistent.
c. Fr o conexiune persistent ntre (navigator) browser i serverul de
origine, este posibil ca un singur segment TCP s transporte dou mesaje
distincte HTTP de tip cerere.
d. The Date: este header n mesajul HTTP de rspuns, indicnd momentul n
care obiectul din mesajul rspuns a fost modificat ultima.
e. Mesajul de rspuns HTTP nu are nici o dat gol corpul mesajului.
a) F
b) T
c) F
d) F
e

Citii RFC 959 pentru FTP. Enumerai comenzile clientului care sunt suportate de
RFC.
Access control commands:
USER, PASS, ACT, CWD, CDUP, SMNT, REIN, QUIT.
Transfer parameter commands:
PORT, PASV, TYPE STRU, MODE.
Service commands:
RETR, STOR, STOU, APPE, ALLO, REST, RNFR, RNTO, ABOR, DELE, RMD,
MRD, PWD, LIST, NLST, SITE, SYST, STAT, HELP, NOOP.

P3 Considerai un client HTTP care dorete s preia un document Web de la un URL

dat. Adresa IP a serverului HTTP este iniial necunoscut. Ce protocoale de la nivelul
transport i aplicaie sunt necesare n afar de HTTP?
Application layer protocols: DNS and HTTP
Obinei specificaia HTTP/1.1 RFC 2616. Rspundei la urmtoarele ntrebri:
a. Explicai mecanismul utilizat pentru semnalizarea ntre client i server
pentru a indica c este nchis conexiunea persistent. Poate clientul,
serverul, sau ambele s semnalizeze nchiderea conexiunii?
b. Ce servicii de criptare sunt furnizate de HTTP?
c. Poate un client s deschid trei sau mai multe conexiuni simultane cu un
server dat?
d. Att serverul sau clientul poate nchide o conexiune de transport ntre ele
dac unul dintre ele detecteaz c respectiva conexiune este n ateptare
(idle) de ceva timp. Este posibil ca o parte s nceap nchiderea
conexiunii n timp ce cealalt parte transmite date pe conexiune? Explicai.
a)Conexiunile permanente sunt discutate in sectiunea 8 a RFC 2616. Sectiunea 8.1.2 si
8.1.2.1 ale RFC indica faptul ca ori clientul ori serverul poate indica celuilalt ca va inchide
conexiunea permanenta (persistent connection ). Se realizeaza prin includerea connection-token
"close" in headerul campului Connection a http request/reply.
b)HTTP nu furnizeaza nici un serviciu de criptare(encryption services).
c)(din RFC 2616) Clientii care utilizeaza conexiuni permanente ar trebui sa limiteze
numarul de conexiuni simultane pe care le mentin pe un anumit server. Un singur utilizator nu ar
trebui sa mentina mai mult de doua conexiuni cu orice server sau proxy.
d)Da(Din RFC 2616) Un client ar putea fi inceput sa trimita o noua cerere in acelasi timp in
care serverul a decis sa inchida conexiunea inactiva. Din punctual de vedere al serverului,
conexiunea este inchisa cat timp a fost inactiva, dar din punctual de vedere al clientului, o cerere este
in progres.
P7 Presupunei c n browser-ul vostru de Web ai dat clic pe o legtur pentru a obine
o pagin Web. Adresa IP pentru URL-ul asociat nu este n cache-ul gazdei locale, astfel
c apare o cutare DNS pentru a obine IP-ul. Presupunei c sunt vizitate n servere
DNS nainte ca gazda voastr s primeasc adresa DNS; vizitele succesive implic
RTT de la RTT1, ,RTTn. n continuare presupunei c pagina Web asociat cu
legtura conine exact un obiect, constnd din ceva text HTML. S notm cu RTT0 RTT-
ul ntre gazda local i serverul care conine obiectul. Presupunnd c timpul de
transmisie a obiectului este 0, ct timp se consum de la momentul cnd clientul d clic
pe legtur pn cnd clientul recepioneaz obiectul?
Timpul total pentru aflarea adresei IP este RTT1+RTT2++RTTn. Odata ce adresa IP este
cunoscuta, RTT0 trece pentru a seta conexiunea TCP si un alt RTT0 trece pentru a solicita si
receptiona small object. Timpul total de raspuns este 2RTT0+ RTT1+RTT2++RTTn.
P8 Referitor la problema 7, presupunei c fiierul HTML face referin 8 obiecte foarte
mici. Neglijnd timpul de transmisie, ct timp se consum cu:
a. HTTP non-persistent fr conexiuni TCP paralele?
 b. HTTP non=persistent cu browser-ul configurat pentru cinci conexiuni
paralele?
c. HTTP persistent?
a)RTT1++RTTn+2RTT0+8*2RTT0=18RTT0+RTT1++RTTn.
b) RTT1++RTTn+2RTT0+2*2RTT0=6RTT0+RTT1++RTTn.
c) RTT1++RTTn+2RTT0+RTT0=3RTT0+RTT1++RTTn.
P9 Considerai figura 2.12, pentru care exist o reea instituional conectat la Internet.
Presupunei c mrimea medie a unui obiect este de 850000 bii i c media cererilor
de la browser-ele instituiei este de 16 cereri pe secund. Presupunei de asemenea c
timpul necesar pentru ca ruterul din Internet s trimit mai departe cererea HTTP ctre
legtur i s primeasc rspuns este n medie de trei secunde (vezi seciune 2.2.5).
Modelai timpul mediu total de rspuns ca suma dintre ntrzierea de acces medie
(adic, ntrzierea de la ruterul Internet la ruterul instituional) i media ntrzierii n
Internet. Pentru ntrzierea medie de acces utilizai /(1-), unde este timpul mediu
necesar pentru a trimite un obiect pe legtura de acces i este viteza de sosire a
obiectelor la legtura de acces.
a. Gsii timpul mediu total de rspuns.
b. Presupunei acum c este instalat un cache n reeaua LAN instituional.
Presupunei c rata pentru lips este 0,4. Gsii timpul total de rspuns.

a)Timpul de transmitere a unui obiect de marimea L printr-o legatura sau rata R este L/R. Timpul
mediu este media marimii obiectului divizat prin R:
= (850,000 bits)/(15,000,000 bits/sec) = .0567 sec
b) Intensitatea traficului pe link-ul de acces este redus cu 60% fiindca 60% din cereri sunt satisfcute
n cadrul reelei instituionale. Astfel ntrzierea medie de acces este (0.0567 sec) / [1 - (0.4) (0.907)]
= 0.089 secunde. Timpul de rspuns este aproximativ zero, n cazul n care cererea este satisfcut
de cache (ceea ce se ntmpl cu probabilitatea 0.6), timpul mediu de rspuns este de 0.089 sec + 3
sec = 3.089 sec pentru lipsurile din cache(cache misses) (ceea ce se ntmpl in 40% din timp). Deci,
timpul mediu de rspuns este (0.6) (0 sec) + (.4) (3.089 sec) = 1.24 secunde. Astfel timpul mediu de
rspuns este redus de la 3,6 pn la 1,24 sec sec.
Se consider scenariul introdus n problema P10. Presupunei acum c legtura
este partajat de Bob cu ali patru utilizatori. Bob utilizeaz instane paralele ale HTTP-
ului non-persistent, iar ceilali patru utilizatori utilizeaz HTTP non-persistent fr
descrcri paralele.
a. l ajut pe Bob conexiunile paralele s preia pagina Web mult mai repede?
De ce sau de ce nu?
b. Dac toi cei cinci utilizatori deschid cinci instane paralele de HTTP non-
persistent, atunci vor fi nc benefice conexiunile paralele ale lui Bob? De
ce sau de ce nu?
a). Da, pentru c Bob are mai multe conexiuni, astfel nct el poate obine proporional lime de
band adunata din latimea de banda a legaturii.
b) Da, Bob nc mai trebuie s efectueze descrcarea n paralel, n caz contrar el va primi mai putina
lime de band dect alti patru utilizatori. De fapt, toi utilizatorii pot avea tendina de a deschide
mai multe conexiuni, n scopul de a obine mai multa lime de band.
P12 Scriei un program TCP simplu pentru un server care accept liniile de intrare de la
un client i le tiprete pe ieirea standard a serverului (se poate face prin modificarea
programului TCPServer.java din carte). Compilai i executai programul. Pe oricare alt
calculator ce conine un browser Web, setai serverul proxy n browser cu gazda care
ruleaz programul server; configurai de asemenea portul corespunztor. Browser-ul
trebuie s trimit acum mesajul GET de cerere ctre server, iar acesta trebuie s
afieze mesajul pe ieirea sa standard. Utilizai aceast platform pentru a determina
dac browser-ul genereaz mesaje de tip GET condiional pentru obiecte din cache-ul
local.
TCPServer.java
import java.io.*;
import java.net.*;
class TCPServer {
public static void main(String argv[]) throws Exception
{
String clientSentence;
ServerSocket welcomeSocket = new ServerSocket(6789);
while(true) {
Socket connectionSocket = welcomeSocket.accept();
BufferedReader inFromClient = new BufferedReader(new
InputStreamReader(connectionSocket.getInputStream( ) ) );
clientSentence = inFromClient.readLine();
System.out.println(RECEIVED FROM CLIENT : + clientSentence + \n);
}
}
}
P13 Care este diferena dintre MAIL FROM: n SMTP i From: din mesajul de mail
insui?
The MAIL FROM: in SMTP este un mesaj de la un client SMTP care identifica expeditorul
mesajului mail catre serverul SMTP. The From:in mesajul mail insusi nu este un mesaj SMTP, ci mai
degraba doar o linie in corpul mesajului mail.
P14 Cum marcheaz SMTP sfritul unui mesaj? Dar HTTP? Poate HTTP utiliza
aceeai metod ca SMTP pentru a marca sfritul mesajului? Explicai.
SMTP utilizeaza o linie (line) continand doar o perioada pentru a marca sfarsitul corpului mesajului.
HTTP utilizeaza Content-Length header field pentru a indica lungimea mesajului(message body).
Nu, HTTP nu poate folosi metoda utilizata de SMTP, deoarece mesajul HTTP poate fi informative
binara, iar in SMTP, mesajul trebuie se fie in format 7-bit ASCII.
P15 Citii RFC 5321 pentru SMTP. Pentru ce se folosete MTA? Considerai urmtorul
email recepionat ca spam (modificat dintr-un email spam real). Presupunnd c numai
iniiatorul acestui email spam este tendenios i toate celelalte gazde sunt oneste,
identificai gazda tendenioas care a generat acest email spam.

MTA stands for Mail Transfer Agents. A mail is forwarded by a source to a MTA and then it follows
a sequence of MTAs to reach the receivers mail reader.
We see that this spam email follows a chain of MTAs. An honest MTA should report where it
receives the message. Notice that in this email, asusus-4b96 ([58.88.21.177]) does not
report where it receives the email. As we assume that the only the originator is dishonest, so
asusus-4b96 ([58.88.21.177]) must be the originator.
P16 Citii RFC-ul pentru POP3, RFC 1939. Care este scopul comenzii UIDL din POP3?
UIDL abreviaza unique-ID listing.Cand un client POP3 trimite comanda UIDL, serverul raspunde
cu un ID unic de mesaj pentru toate mesajele prezente in mailbox-ul utilizatorilor. Aceasta comanda
este folositoare pentru download and keep. Prin pastrarea unui fisier care listeaza mesajele primite
in sesiunile anterioare(retrieved in earlier sessions), clientul poate folosi comanda UIDL pentru a
determina ce mesaje de pe server au fost deja vazute.

P17 Considerai c accesai email-ul vostru cu POP3.

a. Presupunei c ai configurat clientul de mail POP pentru a opera n
modul download-and-delete. Completai urmtoarea tranzacie:
 b. Presupunei c ai configurat clientul de mail POP pentru a opera n modul
download-and-keep. Completai urmtoarea tranzacie:
c. Presupunei c ai configurat clientul de mail POP pentru a opera n
modul download-and-keep. Utiliznd transcrierea de la punctul b,
presupunei c ai preluat mesajele 1 i 2, ieii din POP, i cinci minute
mai trziu accesai din nou POP pentru a prelua mesaje noi. Presupunei
c n acest interval de cinci minute nu ai primit nici un mesaj. Furnizai o
transcriere a acestei a doua sesiuni POP.
a) C: dele 1
C: retr 2
S: (blah blah
S: ..blah)
S: .
C: dele 2
C: quit
S: +OK POP3 server signing off
b) C: retr 2
S: blah blah
S: ..blah
S: .
C: quit
S: +OK POP3 server signing off
1 C: list
S: 1 498
S: 2 912
S: .
C: retr 1
S: blah ..
S: .blah
S: .
C: retr 2
S: blah blah
S: ..blah
S: .
C: quit
S: +OK POP3 server signing off
P18
a. Ce este o baz de date whois?
 b. Utilizai diferite baze de date whois de pe Internet pentru a obine numele
a dou servere DNS. Indicai ce baz de date whois ai utilizat.
c. Utilizai nslookup de pe gazda voastr local pentru a trimite interogri
DNS la trei servere: serverul vostru DNS local i dou servere DNS pe
care le-ai gsit la punctul b. ncercai interogri pentru rapoarte de tip A,
NS i MX. Descriei sumar ce ai gsit.
d. Utilizai nslookup pentru a gsi un server Web care are adrese IP multiple.
Are serverul din instituia voastr (coal sau companie) adrese IP
multiple?
e. Utilizai baza de date whois ARIN pentru a determina gama de adrese IP
utilizat de universitatea voastr.
f. Descriei modul n care un atacator poate utiliza baza de date whois i
instrumentul nslookup pentru a realiza recunoaterea instituiei nainte de
a lansa un atac?
g. Discutai de ce baza de date whois trebuie s fie public.
1 For a given input of domain name (such as ccn.com), IP address or network administrator
name, whois database can be used to locate the corresponding registrar, whois server, DNS server,
and so on.
1 NS4.YAHOO.COM from www.register.com; NS1.MSFT.NET from ww.register.com
1 Local Domain: www.mindspring.com
Web servers : www.mindspring.com
207.69.189.21, 207.69.189.22,
207.69.189.23, 207.69.189.24,
207.69.189.25, 207.69.189.26, 207.69.189.27,
207.69.189.28
Mail Servers : mx1.mindspring.com (207.69.189.217)
mx2.mindspring.com (207.69.189.218)
mx3.mindspring.com (207.69.189.219)
mx4.mindspring.com (207.69.189.220)
Name Servers: itchy.earthlink.net (207.69.188.196)
scratchy.earthlink.net (207.69.188.197)
www.yahoo.com
Web Servers: www.yahoo.com (216.109.112.135, 66.94.234.13)
Mail Servers: a.mx.mail.yahoo.com (209.191.118.103)
b. mx.mail.yahoo.com (66.196.97.250)
c. mx.mail.yahoo.com (68.142.237.182, 216.39.53.3)
d. mx.mail.yahoo.com (216.39.53.2)
e. mx.mail.yahoo.com (216.39.53.1)
f. mx.mail.yahoo.com (209.191.88.247, 68.142.202.247)
g. mx.mail.yahoo.com (209.191.88.239, 206.190.53.191)
Name Servers: ns1.yahoo.com (66.218.71.63)
ns2.yahoo.com (68.142.255.16)
ns3.yahoo.com (217.12.4.104)
ns4.yahoo.com (68.142.196.63)
ns5.yahoo.com (216.109.116.17)
ns8.yahoo.com (202.165.104.22)
ns9.yahoo.com (202.160.176.146)
www.hotmail.com
Web Servers: www.hotmail.com (64.4.33.7, 64.4.32.7)
Mail Servers: mx1.hotmail.com (65.54.245.8, 65.54.244.8, 65.54.244.136)
mx2.hotmail.com (65.54.244.40, 65.54.244.168, 65.54.245.40)
mx3.hotmail.com (65.54.244.72, 65.54.244.200, 65.54.245.72)
mx4.hotmail.com (65.54.244.232, 65.54.245.104, 65.54.244.104)
Name Servers: ns1.msft.net (207.68.160.190)
ns2.msft.net (65.54.240.126)
ns3.msft.net (213.199.161.77)
ns4.msft.net (207.46.66.126)
ns5.msft.net (65.55.238.126)
d) The yahoo web server has multiple IP addresses
www.yahoo.com (216.109.112.135, 66.94.234.13)
e) The address range for Polytechnic University: 128.238.0.0 128.238.255.255
f) An attacker can use the whois database and nslookup tool to determine the IP address ranges, DNS
server addresses, etc., for the target institution.

P19 n aceast problem se utilizeaz instrumentul dig pentru gazdele ce utilizeaz

Unix sau Linux pentru a explora ierarhia serverelor DNS. Reamintim c n figura 2.21 un
server DNS din partea de sus a ierarhiei DNS deleg o interogare DNS ctre un server
din partea de jos a ierarhiei, trimind napoi ctre client numele acestui server DNS.
Prima dat citii manualul pentru dig i apoi rspundei la urmtoarele ntrebri:
a. Pornind de la un server DNS din rdcin (de la unul din serverele
rdcin [a-m].root.servers.net) iniiai o secven de interogri pentru
adresele IP ale serverelor Web din departamantul vostru utiliznd dig.
Prezentai lista numelor serverelor DNSdin canalul de delegare ca
rspuns la interogarea voastr.

b. Repetai a pentru cteva site-uri Web cunoscute precum google.com,

yahoo.com, sau amazon.com
a) The following delegation chain is used for gaia.cs.umass.edu
a.root-servers.net
E.GTLD-SERVERS.NET
ns1.umass.edu(authoritative)
Prima comanda:
dig +norecurse @a.root-servers.net any gaia.cs.umass.edu
;; AUTHORITY SECTION:
edu. 172800 IN NS E.GTLD-SERVERS.NET.
edu. 172800 IN NS A.GTLD-SERVERS.NET.
edu. 172800 IN NS G3.NSTLD.COM.
edu. 172800 IN NS D.GTLD-SERVERS.NET.
edu. 172800 IN NS H3.NSTLD.COM.
edu. 172800 IN NS L3.NSTLD.COM.
edu. 172800 IN NS M3.NSTLD.COM.
edu. 172800 IN NS C.GTLD-SERVERS.NET.
Among all returned edu DNS servers, we send a query to the first one.
dig +norecurse @E.GTLD-SERVERS.NET any gaia.cs.umass.edu
umass.edu. 172800 IN NS ns1.umass.edu.
umass.edu. 172800 IN NS ns2.umass.edu.
umass.edu . 172800 IN NS ns3.umass.edu.
Among all three returned authoritative DNS servers, we send a query to the first one.
dig +norecurse @ns1.umass.edu any gaia.cs.umass.edu
gaia.cs.umass.edu. 21600 IN A 128.119.245.12
b) Raspunsul pentru google.com ar putea fi:
a.root-servers.net
E.GTLD-SERVERS.NET
ns1.google.com(authoritative)
P20 Presupunei ca putei accesa cache-ul serverului DNS local din cadrul
departamentului din care facei parte. Putei propune o modalitate de determinare
aproximativ a serverelor Web (din afara departamentului) care sunt cele mai populare
ntre utilizatori din departament? Explicai.
Noi periodic putem lua o captura a DNS caches in acele servere DNS locale. Serverul Web care apare
cel mai frecvent in DNS caches este cel mai popular server. Aceasta este din cauza ca daca mai multi
utilizatori sunt interesati intr-un server Web, atunci cererile DNS pentru acel server sunt mult mai
frecvent trimise de utilizatori. De aceea, acel server Web va aparea in DNS caches mai des.
P21 Presupunei ca departamentul din care facei parte are un server DNS local pentru
toate computerele din departament. Tu foloseti un computer obinuit (nu ca
administrator de sistem/reea). Putei propune o modalitate de determinare cu o
probabilitate mare dac un server Web a fost accesat cu cteva secunde n urma de
un computer din departament? Explicai.
Yes, we can use dig to query that Web site in the local DNS server.
For example, dig cnn.com will return the query time for finding cnn.com. If cnn.com is just
accessed a couple of seconds ago, an entry for cnn.com is cached in the local DNS cache, so the
query time is 0 msec. Otherwise, the query time is large.
P22 Se consider distribuirea la N peer-uri a unui fiier F=15Gbit. Serverul are o rat
de ncrcare de 30Mbps, i fiecare peer are o rat de descrcare di=2Mbps i o rat de
ncrcare u. Pentru N=10,100,1000 i u=300kbps, 700Kbps, 2Mpbs, realizai un grafic
n care sa fie reprezentat timpul minim de distribuie pentru fiecare combinaie N i u,
pentru ambele distribuii: client server i P2P.
Pentru calcularea timpului minim de distributie pentru distributia client-server, utilizam urmatoarea
formula
Dcs=max{NF/us, F/dmin}
Similar, pentru calcularea timpului minim de distributie pentru distributia P2P, utilizam urmatoarea
formula:
P23 Se consider distribuirea unui fiier de F bii la N peer-uri folosind arhitectura client-
server. S presupunem un model fluid n care serverul poate transmite simultan la mai
multe servere,cu o rat diferit pentru fiecare peer, att timp cat trata combinat de
transmisie nu depete us.
a. Presupunei ca us/Ndmin. Specificai o schem de distribuie care are
timpul de distribuie NF/ us.
b. Presupunei ca us/Ndmin. Specificai o schem de distribuie care are
timpul de distribuie F/ dmin.
c. Concluzionai ca timpul minim de distribuie este dat, in general, de
max{NF/us, F/dmin}.
a)Consideram o schema de distributie in care serverul trimite fisierul catre fiecare client, in
parallel, la o rata din rata us/N. De notat ca aceasta rata este mai putin decat rata de descarcare a
fiecarui client, deoarece prin presupunere us/N<=dmin. De aceea fiecare client poate recepta de
asemenea la o rata us/N. Fiindca fiecare client receptioneaza la o rata us/N, timpul pentru fiecare
client pentru a primi intregul fisier este F/( us/N)=NF/ us. Deoarece toti clientii primesc fisierul in
NF/ us, timpul de distributie(the overall distribution time) este de asemenea NF/ us.
b) Consider a distribution scheme in which the server sends the file to each client, in parallel, at a
rate of dmin. Note that the aggregate rate, N dmin, is less than the servers link rate us, since by
assumption us/N dmin. Since each client receives at rate dmin, the time for each client to receive the
entire file is F/ dmin. Since all the clients receive the file in this time, the overall distribution time is
also F/ dmin.
c)Din sectiunea Section 2.6 noi stim ca
DCS max {NF/us, F/dmin} (Equation 1)
Presupunand us/N dmin. Atunci din Equation 1 noi avem DCS NF/us . Dar din (a) noi avem DCS
NF/us . Combinarea acestor doua rezulta:
DCS = NF/us when us/N dmin. (Equation 2)
Similar putem stii:
DCS =F/dmin when us/N dmin (Equation 3).
Combinand Equation 2 si Equation 3 ne da rezultatul dorit.
24 Se consider distribuirea unui fiier de F bii la N peer-uri folosind arhitectura
P2P. S presupunem un model fluid. Pentru simplitate, presupunei c dmin este
foarte mare, astfel nct limea de band a peer-ului nu este niciodat
strangulat.
a. Presupunei c us(us+u1++uN)/N. Specificai o schem de
distribuie care are timpul de distribuie F/us.
b. Presupunei c us(us+u1++uN)/N. Specificai o schem de
distribuie care are timpul de distribuie NF/(us+u1++uN).
c. Concluzionai ca timpul minim de distribuie este dat, in general, de
max{ F/us, NF/(us+u1++uN)}.
a) Define u = u1 + u2 + .. + uN. By assumption
us <= (us + u)/N Equation 1
Divide the file into N parts, with the i th part having size (ui/u)F. The server transmits the ith part to
peer i at rate ri = (ui/u)us. Note that r1 + r2 + .. + rN = us, so that the aggregate server rate does not
exceed the link rate of the server. Also have each peer i forward the bits it receives to each of the N-1
peers at rate ri. The aggregate forwarding rate by peer i is (N-1)r i. We have
(N-1)ri = (N-1)(usui)/u <= ui,
where the last inequality follows from Equation 1. Thus the aggregate forwarding rate of peer i is less
than its link rate ui.
In this distribution scheme, peer i receives bits at an aggregate rate of

Thus each peer receives the file in F/u s.

b)Again define u = u1 + u2 + .. + uN. By assumption
us >= (us + u)/N Equation 2
Let ri = ui/(N-1) and
rN+1 = (us u/(N-1))/N
In this distribution scheme, the file is broken into N+1 parts. The server sends bits from the i th part to
the ith peer (i = 1, ., N) at rate ri. Each peer i forwards the bits arriving at rate r i to each of the other
N-1 peers. Additionally, the server sends bits from the (N+1) st part at rate rN+1 to each of the N peers.
The peers do not forward the bits from the (N+1) st part.
The aggregate send rate of the server is
r1+ . + rN + N rN+1 = u/(N-1) + us u/(N-1) = us
Thus, the servers send rate does not exceed its link rate. The aggregate send rate of peer i is
(N-1)ri = ui
Thus, each peers send rate does not exceed its link rate.
In this distribution scheme, peer i receives bits at an aggregate rate of

Thus each peer receives the file in NF/(u s+u).

(For simplicity, we neglected to specify the size of the file part for i = 1, ., N+1. We now provide
that here. Let = (us+u)/N be the distribution time. For i = 1, , N, the i th file part is Fi = ri bits.
The (N+1)st file part is FN+1 = rN+1 bits. It is straightforward to show that F 1+ .. + FN+1 = F.)
c) The solution to this part is similar to that of 17 (c). We know from section 2.6 that
u)}, NF/(umax{F/uDssPP+>=2
Combining this with (a) and (b) gives the desired result.
P 25 Se consider o reea format din N peer+uri active, cu fiecare pereche de
peer-uri avnd o conexiune TCP activ. In plus, presupunei c conexiunile TCP
trec prin M rutere. Cte noduri i legturi intre le exista in reeaua considerat.
There are N nodes in the overlay network. There are N(N-1)/2 edges.
Exist N noduri n overlay network. Exist N (N-1) / 2 muchii.
P 26 Presupunei ca Bob se altur unui torrent BitTorrent, dar nu vrea sa ncarce
date la nici un alt peer (aa-numita free-riding).
a. Bob susine c el poate primii o copie complet a fiierului care este
partajat n grup. Este posibila afirmaia lui Bob? De ce da sau de ce
nu?
b. Bob susine in continuare c free-riding poate fi mult mai eficient
dac se folosete o colecie de mai multe computere (cu adrese IP
distincte) din cadrul departamentului. Cum se poate realiza acest
lucru?
a) Da.Prima sa afirmatie este posibila, atat timp cat acolo sunt destui peers care sa ramana in
grup pentru o perioada indelungata. Bob poate intotdeauna sa receptioneze date prin
optimistic unchoking de la alti peers.
b) A doua sa afirmatie este de asemenea adevarata. El poate rula un client pe fiecare masina, si
sa permita fiecarui client sa faca free-riding, si sa combine acele parti colectate de la
diferite masini intr-un singur fisier. El poate chiar scrie un mic program sa permita ca masini
diferite doar sa ceara diferite parti de fisier.
P 27 In aceast problem suntem interesai de determinarea eficienei unui sistem
de tip BitTorrent P2P. Se ia in considerare dou peer-uri Bob i Alice. Ei se altur
unui torrent cu un total de M peer-uri (inclusiv Bob i Alice) care partajeaz in
fiier format din N blocuri. S presupunem ca la un anumit moment de timp t,
prile care sunt deinute de un peer sunt alese la ntmplare i uniform din toate
cele N pri, i nici un peer nu are toate cele N peer-uri. Rspundei la urmtoarele
ntrebri:
a. Care este probabilitatea ca Bob s aib toate prile pe care le are
Alice, dat fiind faptul c numrul de buci pe care le deine Bob i
Alice sunt notate cu nb i na?
b. Elimin partea condiionat in a, pentru a gsi probabilitatea ca Bob
s dein toate prile pe care le deine Alice, dat fiind faptul c Alice
deine na pri?
c. Presupunei c fiecare peer in BitTorrent care 5 vecini. Care este
probabilitatea ca Bob s aib date de care este interesat cel puin
unul din cei 5 vecini?

P 28 n exemplul DHT circular prezentat in seciunea 2.6.2, s presupunem c

peer-ul 3 nva ca peer-ul 5 a plecat. Cum i va actualiza peer-ul 3 informaiile de
stare ale succesorului su? Care peer este acum primul succesor? Dar cel de-al
doilea succesor?
Peer 3 afla ca peer 5 tocmai a parasit sistemul, deci peer 3 intreaba primul sau successor(peer 4)
despre identificatorul imediatului sau successor(peer 8). Atunci peer 3 va face ca peer 8 ca si al
doilea successor al sau.
De notat ca peer 8 stie ca peer 5 a fost original primul successor al peer 4, deci peer 3 ar astepta
pana peer 4 termina inlocuirea primului sau successor.
P 29 n exemplul DHT circular prezentat in seciunea 2.6.2, s presupunem c 6
noi peer-uri vor s se alture la DHT i iniial, peer-ul 6 cunoate doar adresa IP a
peer-ului 15. Ce pai sunt urmai?
Peer 6 ar trimite prima data catre peer 15 un mesaj, spunand care va fi predecesorul si
succesorul lui peer 6. Acest mesaj este trimis prin DHT pana ajunge la peer 5, care realizeaza ca
va fi predecesorul lui peer 6 si ca sucesorul sau current, peer 8, va deveni sucesorul lui 6. In
continuare, peer 5 trimite aceste informatii despre successor si predecessor inapoi la 6. Peer 6
poate acum sa se alature DHT prin facerea lui peer 8 in succesorul sau si prin notificarea lui peer
5 despre faptul ca ar trebui sa schimbe imediatul sau successor in peer 6
P 30 Se considera un DHT circular cu noduri si chei de identificare in intervalul
[0,63]. Se presupune c exista 8 peer-uri cu identificatorii 0, 8, 16, 24, 32,40,48, i
56.
a. Presupunei c fiecare peer poate avea un peer scurttur. Pentru
fiecare din cele 8 peer-uri, determinai peer-ul scurttur astfel nct
numrul de mesaje trimis pentru fiecare cerere (ncepnd de la
oricare peer) este minim.
b. Repetai (a) , dar nu permitei unui peer s aib dou peer-uri
scurttur.
a). Our assumption about keys and queries:
1. All keys are uniformly at random distributed in the key range, and all 8 peers are responsible for
the same number of queries on average.
2. The queries generated by a peer are for keys uniformly at random distributed in the key range.
That is, the query for any key is generated with the same probability.
Because of the homogeneity of peers and queries, we know that all peers will choose a shortcut peer
with the same number of overlay hops away.
We also assume that by default, a peer node only knows about its immediate successor peer and its
immediate predecessor node. (Unlike the case where a peer must know its second immediate
successor in order to deal with peer churn).
We further assume that a peer can forward query to its predecessor.
And if there are multiple routing paths exist for a query, a peer always chooses the shortest path.
Note the number of messages sent for a query for a key is equal to the number of routing hops
needed from the query generating peer to the peer that is holding the key.
Note that in our description, a routing hop is different from an overlay hop. An overlay hop simply
means a logical hop between two adjacent peers along the DHT overlay ring. But a routing hop can
span multiple overlay hops (or multiple consecutive adjacent peers) if shortcut is allowed.
Thus, minimizing the number of messages sent for any query (starting from any peer) is equivalent to
minimizing the average or total number of routing hops traversed from one peer to all other peers.
Without loss of generality, lets look at peer 0.
To solve this problem, we look at all possibilities: a node shortcuts to a peer two overlay hops away
in DHT id ring; or three overlay hops away; or four overlay hops away, so on. We can find that the
best configuration is for a peer to choose a shortcut peer with 4 overlay hops away. Best in the
sense that the average number of messages per query (or the total number of routing hops for all
queries for all keys in the key space) is minimized. The computation is shown in the following table.
Each column (except the last column) shows the number of messages needed for routing a query
within a range.
We see that the total number of messages needed is 11 when every peer shortcuts to another peer
with 4 overlay hops (i.e., span 4 consecutive adjacent peers) away.

b). Follow the same reasoning as in part a).

We can find that the best configuration is for a peer to choose two shortcut peers with 3 and 6
overlay hops away, or two shortcut peers with 5 and 6 overlay hops away.

P 31 Deoarece un ntreg in intervalul [0,2n-1] poate fi reprezentat ca un numr pe n

bii in DHT,atunci fiecare cheie poate fi reprezentat ca k=(k0, k1, , kn-1) i
fiecare identificator de peer poate fi reprezentat ca p=(p0, p1, , pn-1). S definim
distana XOR dintre o cheie i un identificator ca:

Descriei cum poate fi folosit aceast metric pentru a asigna perechi

(cheie,valoare) la peer-uri. (Pentru a nva modalitatea de construirea a unui
DHT folosind aceast metric, consultai [Maymounkov 2002], unde este
descris Kademlia DHT ).
For each key, we first calculate the distances (according to d(k,p)) between itself and all peers, and
then store this key into the peer that is closed to this key (with smallest distance value).
Then, as in circular DHT described in textbook, we arrange those peers in a ring. In this ring, there
are many clusters of keys, and each cluster is centered at a particular peer. Each key in a peers
cluster is closer to this peer than to all other peers. Some of the keys in this cluster can be larger than
this peers ID. Note that a peer is responsible for the keys in its cluster, instead of being responsible
for only keys that are preceding it (i.e, keys have smaller value than the ID of this peer) in the key
range.
Each peer keeps a routing table of n lists of entries. Each entry contains the information of one other
peer. These lists are arranged sequentially, and the k-th (1<=k<=n) list contains peers with IDs that
differ from that of this peer in k-th significant bit but match with all k-1 bits more significant than k,
including the most significant bit, the second most significant bit, so on, until the (k-1)-th most
significant bit. Note here we use longest-prefix matching. Also note that with this arrangement, it is
possible that half of the IDs in the ID range can be put into the first list.
If i>j, then a peer in i-th list is closer to this node than a peer in j-th list.
The query routing can be done as follows. A peer first tries to match the bits of the key with its own
IDs bits, and finds the right list in its routing table, and then forwards the query to any one entry in
the list. A right list is a list that has the longest prefix matching with the target key. Once a peer
receives the target key, it also checks its routing table, and forwards the search query to a peer in the
right list, so on, so forth, until a peer that is responsible for the key is located, or returns no such
key if no further routing is possible.

P32 Luai in considerare o versiune generalizat a sistemului descris in problema

precedent. n loc de utilizarea numerelor binare, vom trata cheile i identificatorii
peer-ulu ca numere n baza b, unde b > 2, dup care vom utiliza metrica din
problema precedent pentru o proiecta in DHT (prin nlocuirea lui 2 cu b).
Comparai acest DHT bazat pe numere n baza b cu DHT bazat pe numere binare.
n cel mai defavorabil caz, care DHT genereaz mai multe mesaje pentru o
interogare? De ce?
This is a generalized Kademlia DHT, and also similar to Pastrys prefix-matching DHT.
The DHT based on binary numbers generates more messages, log2N in the worst case. This new DHT
generates logbN messages in the worst case.

P 33Pentru un DHT dintr-o reea nu este necesar ca s existe o potrivire cu

reeaua fizic, in sensul ca dou peer-uri vecine pot fi foarte departe, de exemplu
un peer poate fi in Asia i unul in America de Nord. Dac asignam identificatori
aleatoriu la noii peer-uri care intr in reea, va cauza aceast schem de asignare
o astfel de nepotrivire? Explicai. Si cum va afecta aceast nepotrivire
performana DHT-ului?
Yes, that assignment scheme of keys to peers does not consider underlying network at all, so it very
likely causes mismatch.
The mismatch may potentially degrade the search performance. For example, consider a logical path
p1 (consisting of only two logical links): ABC, where A and B are neighboring peers, and B and C
are neighboring peers. Suppose that there is another logical path p2 from A to B (consisting of 3
logical links): ADEC.
It might be the case that A and B could be very far away physically, and B and C could be very far
away physically. But A, D, E, and C are very close physically. In other words, a shorter logical path
corresponds to a longer physical path than does a longer logical path.

P 34 Instalai i compilai programele Java TCPClient i UDPClient pe de o gazd,

i TCPServer i UDPServer pe o alt gazd.
a. S presupunem c executai TCPClient nainte de a executa
TCPServer. Ce se ntmpl? De ce?
b. S presupunem c executai UDPClient nainte de a executa
UDPServer. Ce se ntmpl? De ce?
Ce se ntmpl dac folosii porturi diferite pentru client i server?
b) UDPClient doesn't establish a TCP connection with the server. Thus, everything should work fine
if you first run UDPClient, then run UDPServer, and then type some input into the keyboard.
c) If you use different port numbers, then the client will attempt to establish a TCP connection with
the wrong process or a non-existent process. Errors will occur.
a) if you run TCPClient first, then the client will attempt to a TCP connection with a non-existent
server process. A TCP connection will not be made

P 35 S presupunem c n UDPClient.java vom nlocui linia DatagramSocket

clientSocket = new DatagramSocket (); cu DatagramSocket clientSocket = new
DatagramSocket (5432). Va deveni necesar s schimbm UDPServer.java? Care
sunt numerele de porturi pentru socket-uri din UDPClient i UDPServer? Care au
fost ele nainte de a face aceast schimbare?
With the original line, UDPClient does not specify a port number when it creates the socket. In this
case, the code lets the underlying operating system choose a port number. With the replacement line,
when UDPClient is executed, a UDP socket is created with port number 5432 .
UDPServer needs to know the client port number so that it can send packets back to the correct client
socket. Glancing at UDPServer, we see that the client port number is not hard-wired into the server
code; instead, UDPServer determines the client port number by unraveling the datagram it receives
from the client (using the .getPort() method). Thus UDP server will work with any client port
number, including 5432. UDPServer therefore does not need to be modified.
Before:
Client socket = x (chosen by OS)
Server socket = 9876
After:
Client socket = 5432
Capitolul 3

1. Presupunei c nivelul reea furnizeaz urmtoarele servicii. Nivelul reea

din cadrul gazdei surs accept segmente avnd mrimea maxim de 1200
octei, i o adres a gazdei destinaie furnizat de la nivelul transport.
Nivelul reea garanteaz furnizarea segmentului ctre nivelul transport de
la gazda destinaie. Presupunei c pe gazda destinaie pot rula multe
procese pentru aplicaii de reea.
a. Proiectai cel mai simplu protocol posibil la nivelul transport care
preia datele aplicaiei i le transport la gazda destinaie.
Presupunei c sistemul de operare al gazdei destinaie asigneaz un
 numr de port pe 4 octei pentru fiecare proces aplicaie care este n
execuie.
b. Modificai acest protocol astfel nct s furnizeze o adres de
revenire la procesul destinaie.
c. Are nivelul transport, din protocoalele voastre, de fcut ceva n
nucleul reelelor de calculatoare?
a) Numim acest protocol Simple Transport Protocol (STP). In partea
expeditorului, STP accepta din procesul de trimitere un segment de date
ce nu depaseste 1196 bytes, adresa gazdei si portul destinatie. STP
adauga unde header de 4 biti fiecarui segment in care se mai gaseste si
portul destinatiei. STP acorda nivelului retea adresa gazdei si segmental
rezultat. Nivelul retea livreaza STP-ului gazda destinatie. STP examineaza
portul din segment, extrage datele din segment, si trimite datele procesului
care este identificat de port.
b) Segementul are acum 2 campuri pt heade: un camp cu portul sursa si
unul cu portul destinatie. In partea expeditorului, STP accepta un segment
de date ce nu depasesc 1192 bytes, adresa gazdei, portul sursa si portul
destinatie. STP creaza un segment ce contine datele aplicatiei, portul
sursa si portul destinatie. Apoi acorda segmentul si adresa gazedei
destinatie nivelului retea. Dupa primirea segmentului, STP-ul in partea
receptorului acorda procesului aplicatiei datele si portul sursa.
c) Nu, nivelul retea nu trebuie sa faca nimic in nucleu; nivelul transport se
afla sin sistemele de capat.
2. S considerm o planet unde fiecare aparine unei familii de ase
persoane, fiecare familie locuiete n propria cas, fiecare cas are o
adres unic, i fiecare persoan din cas are un nume unic. Presupunei
c aceast planet are un serviciu de mail care furnizeaz scrisori de la o
cas surs la una destinaie. Serviciul de mail necesit ca (i) scrisoarea s
fie ntr-un plic i ca (II) adresa casei destinaie (nimic mai mult) s fie scris
clar pe plic. Presupunei c fiecare familia are un membru delegat care
colecteaz i distribuie scrisori pentru ceilali membrii ai familiei. Scrisorile
nu furnizeaz n mod necesar o indicaie privind destinatarul scrisorii.
a. Utiliznd soluia de la problema 1 ca inspiraie, descriei un protocol
astfel ca delegatul s poat furniza scrisoarea de la membrul familiei
care a trimis-o la un membru al familie care a recepionat-o.
b. n protocolul vostru, trebuie ca serviciul de mail s deschid plicul i
s examineze scrisoarea cu scopul de ai ndeplini serviciul?
a) Pentru a trimite o scrisoare, este necesat sa stim membri familiei pentru a da
delegatului scrisoarea, adresa casei destinatie si numele destinatarului.
Delegatul scrie numele destinatarului la inceputul scrisorii. Apoi delegatul pune
scrisoare intr-un plic si scrie adresa casei destinatie. Apoi delegatul trimite
scrisoarea catre serviciul de mail planetar. La re receptor, delegatul primeste
scrisoarea de la serviciul mail si scoate scrisoarea din plic apoi ia la cunostinta
numele scris la inceputul scrisorii. Apoi delegatul da scrisoarea membrului din
familiei caruia ii apartine scrisoarea.
 b) Nu, serviciul e-mail nu deschide plicul scrisorii, este doar examinata adresa de
pe plic.
3. Considerai o conexiune TCP ntre o gazd A i o gazd B. Presupunei c
segmentele TCP care cltoresc de la gazda A la gazda B au portul surs
cu numrul x i portul destinaie cu numrul y. Care sunt numerele de port
surs i destinaie pentru segmentele care cltoresc de la gazda B la
gazda A.
Postul sursa Y si portul destinatie X
4. Descriei de ce un dezvoltator de aplicaii poate s decid s aleag s
ruleze o aplicaie pe UDP mai degrab dect pe TCP.
Un dezvoltator de aplicatii nu ar vrea ca aplicatia sa sa utilizeze controlul
congestiei TCP, care ar putea accelera ratele de transmisie alea aplicatiei in
timpul congestiei. De multe ori dezvoltatorii telefoniei IP sau aplicatii de tip
videoconferinta aleg UDP deoarece vor sa evite controlul congestiei TCP. De
asemenea unele aplicatii nu au nevoie de transfer de date fiabil furnozate de
TCP.
5. De ce traficul video i audio este trimis, n aplicaiile INTERNET DE
ASTZI, mai degrab pe TCP dect pe UDP (rspunsul nu are nimic comun
cu congestia).
De cand multe firewall-uri sunt configurate sa blocheze traficul UDP, utilizand TCP pt.
traficul video si audio este lasat sa treaca prin firewall.

6. Este posibil ca aplicaia s asigure un transfer fiabil chiar dac ruleaz pe

UDP? Dac da, cum?
Da. Dezvoltatorii de aplicatii pot sa asigure transfer fiabil de date intr-un nivel a
aplicatiei. Dar asta necesita un effort suplimentar pentru depanare (debugging).
7. Presupunei c un proces de pe gazda C are un socket UDP cu numrul
6789. Presupunei c att gazda A ct i gazda B trimit fiecare un segment
la gazda C cu numrul de port destinaie 6789. Vor fi aceste socket-uri
direcionate la gazda C la acelai socket? Dac da, cum va ti procesul de
pe gazda C c aceste dou socket-uri au origini de la dou gazde diferite?
Da. Ambele segmente v-or fi directionate catre acelasi socket. Pentru fiecare segment
obtinut in interfata socket, sistemul de operare va furniza un process cu adresa IP pt a
determina originea fiecarui segment individual.
8. Presupunei c un server Web ruleaz pe gazda C pe portul 80. Presupunei
c aceste server Web utilizeaz o conexiune persistent, i a primit cereri
de la dou gazde diferite A i B. Sunt aceste cereri trimise spre acelai
socket la gazda C? Dac sunt trimise ctre socket-uri diferite, au ambele
socket-uri portul 80? Discutai i explicai.
Pentru fiecare conexiune persistenta, serverul WEB creaza conexiuni socket separate.
Fiecare conexiune este identificata de 4 perechi de tuple (adresa IP sursa, portul sursa,
adresa IP destinatie si portul destinatie). Cand gazda C primeste si datagrama IP,
examineaza aceste 4 campuri in datagram/segment pt. adetermina ce socket sa preia
sarcina segmentului TCP. Astfel cererile de la A si B trec prin socket-uri diferite.
Identificatorul pentru cei 2 are 80 pentru portul destinatie; Oricum identificatorul pentru
acete socket-uri are valori diferite pentru adresele IP sursa. Spre deosebire de UDP
cand trece spre nivelul transport sarcina (payload) procesului aplicatiei nu specifica
adresa IP a sursei, implicit specificat de identificatorul de socket.
9. De ce trebuie introduse numerele de secven n protocolul rdt?
Numerele de secventa sunt cerute pentru ca un receptor sa gaseasca cand un pachet
care ajunge contine date noi sa este o retransmisie.
10. De ce trebuie introduse timer-e n protocolul rdt?
Pentru a controla pierderile intr-un canal. Daca ACK pentru un pachet transmis nu este
primit in durata de timp a timer-ului pachetului, pachetul se presupune ca a fost pierdut.
Prin urmare pachetul este retransmis.
11. Presupunei c ntrzierea ntre emitor i receptor, dat de RTT, este
constant i este cunoscut de emitor. Presupunnd c pachetul poate fi
pierdut, va fi necesar n continuare timer-ul n cadrul protocolului rdt 3.0.
Discutai i explicai.
Un timer tot este necesar in protocolul RTD 3.0. Daca timer-ul roud trip este cunoscut
acesta v-a fi singurul avantaj, expeditorul stie sigur ca nici un pachet sau ACK pentru
pachetele pierdute, comparand cu scenariul real, unde ACK ar putea fi in drum spre
expeditor, chiar dup ace timer-ul a expirat. Oricum , pentru a detecta o pierdere, pentru
fiecare pachet, durata constanta a timerului va fi necesara la expeditor.
12. Vizitai applet-ul Java Go-Back-N de pe site-ul Web al crii.
a. Facei ca sursa s trimit cinci pachete, i terminai animaia nainte
ca oricare dintre cele cinci pachete s ajung la destinaie. Apoi
distruge (kill) primul pachet i reluai animaia. Descriei ce se
ntmpl.
b. Repet experimentul, dar acum las primul pachet s ajung la
destinaie i distruge (kill) prima confirmare. Descrie nc o data ce
se ntmpl.
c. n final, ncearc s trimii 6 pachete. Ce se ntmpl?
Java Applet
13. Repeta R12 dar acum cu Selective Repeat Java applet. Cum difer Selective
Repeat i Go-Back-N diferite?
Java Applet
14. Adevrat sau fals?
a. Gazda A trimite gazdei B un fiier mare pe o conexiune TCP.
Presupunem c gazda B nu are nici o data pe care s o trimit gazdei
A. Gazda B nu-i va trimite confirmri gazdei A deoarece gazda B nu
poate trimite confirmri succesive (piggyback) pentru date .
b. Mrimea ferestrei de recepie rwnd a TCP-ului nu se schimb pe
parcursul duratei conexiunii.
c. Presupunem c gazda A i trimite gazdei B un fiier mare pe o
conexiune TCP. Numrul de octei nerecunoscui pe care A i trimite
nu pot depi mrimea buffer-ului de recepie.
d. Presupunem c gazda A i trimite gazdei B un fiier mare despre o
conexiune TCP. Dac numrul de secven un segment al acestei
conexiuni este m, atunci numrul de secven pentru segmentul
ulterior va fi neaprat m+1.
e. Segmentul TCP are un cmp n antetul lui pentru rwnd.
 f. Presupunem c ultimul SampleRTT ntr-o conexiune TCP este egal
cu 1 sec. Valoarea curent a TimeoutInterval pentru conexiune va fi
neaprat >= 1 sec.
g. Presupunem c gazda A trimite un segment cu numrul de secven
38 i 4 octei de date pe o conexiune TCP ctre gazda B. n acelai
segment, numrul de confirmare (ACK) este neaprat 42.
a) Fals
b) Fals
c) Adevarat
d) Fals
e) True
f) Fals
g) Fals
15. Presupunei c gazda A trimite 2 segmente TCP napoi gazdei B pe o
conexiune TCP. Primul segment are numrul de secven 90; al doilea are
numrul de secven 110.
a. Ct de multe date sunt n primul segment?
b. Presupunem c primul segment este pierdut dar al doilea segment
ajunge la B. n confirmarea pe care gazda B o trimite gazdei A, care
va fi numrul de confirmare?
a) 20 bytes;
b) Ack number = 90;
16. Lum n considerare exemplul Telnet discutat n seciunea 3.5. La cteva
secunde dup ce utilizatorul scrie litera C acesta scrie litera R. Dup ce
scrie litera R, cte segmente sunt trimise, i ce este n numerele de
secven i cmpurile de confirmare ale segmentelor?

3 segemente . Prmul segement : seq = 43, ack = 80 ;

Al doilea segment: seq = 80, ack = 44;
 Al treilea segment: seq = 44, ack = 81.
17. Presupunem c exist dou conexiuni TCP pe o legtur cu trafic ngustat
(bottleneck) cu viteza de Rbps . Ambele conexiuni au un fiier uria de
trimis (n aceeai direcie, peste link-ul bottleneck). Transmiterea fiierelor
ncepe n acelai timp. Ce vitez de transmisie ar vrea TCP-ului sa dea
fiecrei conexiuni?
R/2
18. Adevrat sau fals? Consider controlul congestie n TCP. Cnd timpul
expir la expeditor, valoarea ssthresh este fixat la jumtate fa de
valoarea anterioar.
Fals, este setat la jumatate din valoarea curenta a ferestrei de congestive.
3. P1. Presupunem c clientul A iniiaz o sesiune Telnet cu Serverul S.
Aproximativ n acelai timp, clientul B iniiaz de asemenea o sesiune
Telnet cu serverul S. Furnizai numere de port surs i destinaie posibile:
a. Segmentele trimise de la A la S,
b. Segmentele trimise de la B la S,
c. Segmentele trimise de la S la A,
d. Segmentele trimise de la S la B.
e. Dac A i B sunt gazde diferite, este posibil ca numrul portului
surs n segmentele de la A la S s fie la fel ca cel de la B la S?
f. Dar dac sunt aceleai gazde?

4. P2. Consider figura 3.5. Care sunt valorile porturilor pentru surse i destinaii
pentru segmentele care sunt trimise de la server napoi la procesele clienilor?
Care sunt adresele de IP n datagramele nivelului reea care transport
segmentele nivelului transport?
Presupunem adresele IP ale gazdelor A,B,C sunt a,b,c (a,b,c sunt distincte)
Gazda A: Port sursa=80, adresa IP sursa = b, port destinatie=26145, adresa IP dest=a
Spre gazda C, process stanga: port sursa=80, IP sursa=b,port dest=7532, IP dest=c
Spre gazda C,process dreapta: port sursa=80, IP sursa=b,port dest=26145, IP dest=c
5. P3. UDP i TCP utilizeaz complementul fa de 1 pentru sumele lor de
control. Presupunem c avei urmtorii 3 octei de cte 8 bii:
01010011,01010100,01110100. Care este complementul fa de 1 a sumei
acestor octei? ( De notat c, dei UDP i TCP folosesc cuvinte pe 16-bit n
calculul sumelor de control, pentru aceasta problem eti rugat s consideri
sume pe 8 bii) De ce folosete UDP-ul complementul fa de 1 al sumei i
nu doar suma? Cum detecteaz receptorul erorile utiliznd schema cu
complement fa de 1? Este posibil ca o eroare la un 1 bit s treac
nedetectat? Dar o eroare la 2 bii?

Pentru detectia erorilor, receptorul adauga 4 cuvinte(words) (cele trei cuvinte originale si
checksum). Daca suma contine un zero, receptorul stie ca a fost identificata o eroare.
Toate erorile de un singur bit (one-bit errors) vor fi detectate, dar erorile de doi biti (two-
bit errors) se poate sa nu fie detectate (ex. Daca ultimul bit al primului cuvant este
convertit la 0 si ultimul bit al celui de-al doilea cuvant este convertit la 1).
 6. P4.
a. Presupunei c avei urmtorii 2 octei: 01011100 i 01010110. Care
este complementul fa de 1 pentru suma acestor 2 octei?
Adunand cei doi octeti obtinem: 10110010. Complement fata de 1: 01001101
b. Presupunei c avei urmtorii 2 octeti: 11011010 i 00110110. Care
este complementul fa de 1 pentru suma acestor 2 octei?
Adunand cei doi octeti obtinem: 00010001. Complementul fata de 1: 11101110
c. Pentru octetii de la subpunctul a) dai un exemplu n care un octet
este comutat n fiecare din ceilali 2 octei i totui complementul
fa de 1 a sumei celor doi octei nu se schimb.
Primul octet: 01011110 Al doilea octet: 01010100
7. P5. S presupunem c receptorul UDP calculeaz suma de control Internet
pentru un segmentul UDP primit i constat c aceasta corespunde valorii
transportate n cmpul din antet alocat sumei de control. Poate receptorul
sa fie absolut sigur c nu au aprut erori de bii? Explicai.
Nu receptorul nu poate fi sigur ca nu au aparut erori de biti. Aceasta din cauza modului
in care este calculat checksum pentru pachet. Daca bitii corespunzatori (vor fi adunati
impreuna) celor doua cuvinte de 16-biti din pachet au fost 0 si 1 atunci chiar daca acesti
biti se transforma in 1 si 0, suma ramane aceeasi.Prin urmare, complementul fata de 1
pe care-l calculeaza receptorul va fi acelasi. Asta inseamna ca checksum va verifica
chiar daca au fost erori la transmitere.
8. P6. Luai n considerare motivaia pentru corectarea protocolului rdt2. 1.
Artai c receptorul, prezentat n figura 3.57, atunci cnd funcioneaz cu
emitorul prezentat n figura 3.11, poate conduce la situaia n care
emitorul i receptorul intr ntr-o stare de blocaj (deadlock), n care
fiecare ateapt un eveniment care nu apare niciodat.
 Presupune
m ca expeditorul (sender) este in starea Wait for call 1 from above si
receptorul(receptorul din problema de la tema acasa) este in starea Wait for 1 from
below. Expeditorul trimite un pachet cu nr de secventa 1, si in tranzitie la Wait for ACK
or NAK 1, asteptand un ACK sau NAK. Presupunem ca receptorul primeste pachetul
cu nr de secventa 1 corect, trimite un ACK, si tranzitia spre starea Wait for 0 from
below asteptand pentru un pachet de date cu nr de secventa 0. Oricum, ACK este
corupt(ACK is corrupted). Cand expeditorul rdt2.1 primeste ACK corupt, retrimite
pachetul cu nr de secventa 1.Oricum receptorul asteapta un pachet cu nr de secventa 0
si (asa cum se arata in problema de tema acasa) intotdeauna trimite un NAK atunci
cand NU primeste un pachet cu numarul de secventa 0. Prin urmare expeditorul va
trimite intotdeauna un pachet cu nr de secventa 1 si receptorul va trimite un NAK pt acel
pachet. Astfel niciunul din cei doi nu vor progresa din starea in care se afla.
9. P7. n protocolul rdt3. 0, pachetele ACK care vin de la receptor ctre
emitor nu au numere de secven (dei acestea au un cmp ACK care s
conin numrul de secven al pachetului pe care l recunosc). De ce
aceste pachete ACK nu au nevoie de numere de secven?
Vedem ca expeditorul are nevoie de nr de secventa astfel incat receptorul sa poata
spuna daca un pachet este duplicat a unui pachet pe care l-a primit deja.In cazul ACKs,
expeditorul nu are nevoie de aceasta informatie(ex un nr de secventa pe un ACK)
pentru a spune daca a detectat un pachet duplicat. Un ACK este evident la receptorul
rdt3.0, intr-ucat atunci cand a primit ACK original trece la urmatoarea stare. ACK
duplicat nu este ACK de care expeditorul are nevoie si prin urmare este ignorat de
expeditorul rdt3.0
10. P8. Desenai FSM pentru partea de receptor a protocolului rdt3. O. (wtf!?)
Partea expeditorului pt protocolul rdt3.0 difera de partea expeditorului de la protocolul
2.2 prin faptul ca a fost adaugat un timeout. Am observat ca timeout introdus adauga
posibilitatea pachetelor duplicate de la expeditor la receptor. Totusi receptorul in
protocolul rdt2.2 poate deja manipula pachetele duplicat.(partea receptorului in
pachetele duplicate in rdt2.2 va aparea daca receptorul trimite un ACK pt pachetul care
a fost pierdut, si expeditorul retransmite vechea data). Prin urmare receptorul in
protocolul rdt2.2 va lucra ca si receptorul din protocolul rdt3.0
11. P9. Furnizai o explicare a funcionrii protocolului rdt3.0 pentru cazul
cnd pachetele de date i pachetele confirmare sunt eronate. Explicarea
Dvs. ar trebui s fie similar cu cea utilizata n Figura 3.16.

Presupunem ca protocolul a fost operational pentru ceva timp. Expeditorul se afla in

starea Wait for call from above(top left hand corner) si receptorul este in starea Wait
for 0 from below. Scenariu pt data corupta si ACK corrupt sunt explicate in imaginile
 12. P10. Luai n considerare un canal care poate pierde pachetele, dar are o
ntrziere maxim care este cunoscut. Modificai protocolul rdt2. 1 pentru
a include un timeout la expeditor i retransmisia. Informativ, argumentai
de ce protocolul dumneavoastr poate s comunice n mod corect pe
acest canal.
Adaugam un timer a carui valoare este mai mare decat propagarea intarzierii round-trip
cunoscuta (the known round-trip propagation delay). Adaugam un eveniment timeout la
Wait for ACK sau NAK0 si Wait for ACK or NAK1.Daca apare evenimentul timeout,
cel mai recent pachet transmis este retransmis. Sa vedem de ce acest protocol va
continua sa lucreze cu receptorul rdt2.1
Presupunem ca timeout-ul este cauzat de o pierdere de pachete,ex , un pachet
pe sender-to-receiver channel. In acest caz, receptorul nu primeste niciodata
teansmisia anterioara si, de la viepoint receptorului, daca timeout retransmisiei
este primit, arata exact la fel ca si cand orignalul transmisiei este primit
Presupunem ca un ACK este pierdut. Receptorul va retransmite eventual
pachetul pe un timeout. Dar o retransmisie este exact aceeasi actiune care se
efectueaza daca un lan ACK este deformat. Desi reactia expeditorului este
aceeasi cu o pierdere, ca si cu o deformare a ACK. Receptorul rdt 2.1 poate deja
manipula cazul unui ACK deformat.
13. P11. Expeditorul din rdt3 0 pur i simplu ignor (n sensul c, ca nu
iniiaz nici o aciune) toate
 pachetele primite, care sunt fie n eroare sau au valoare greita n domeniul
cmpul acknum
a unui pachet confirmare. S presupunem c, n astfel de circumstane,
este simplu pentru rdt3.0 s retransmit pachetele de date curente. Ar mai
funciona protocolul? (Sugestie: Luai n considerare ce s-ar ntmpla dac
ar exista doar erori la nivel de bit; nu exist pierderi de pachete, dar pot s
apar timeout-uri premature. Luai n considerare de cte ori este trimis al
n-lea pachet (nth), cnd n se apropie de infinit.)
Protocolul va continua sa functioneze, intrucat o retransmisie se va produce daca
pachetul este primit cu erori a fost pierdut ( si din punctul de vedere al
receptorului, nu stie niciodata care din aceste evenimente, daca oricare va
aparea)
Pentru a ajunge la cel mai subtil punct a acestei probleme, unul trebuie sa
permita pentru a permite aparitia timeout-ului. In acest caz, daca fiecare extra
copie a unui pachet este ACK si fiecare extra ACK primit determina o alta extra
copie a pachetului curent ce va fi transmis, numarul de pachete n ce este
transmis va creste limita in timp ce n se apropie de infinit
14. P12. Luai n considerare protocolul rdt 3.0. Desenai o diagram care s
arate c, dac conexiunea la nivelul reea dintre expeditor i receptor poate
reordona mesaje (adic, dou mesaje care se propaga n mediul dintre
expeditor i receptor pot fi reordonate), atunci protocolul alternativ-bit nu
va funciona corect (asigurai-v c identificai n mod clar sensul n care
aceasta nu funcioneaz corect). Diagrama ar trebui s aib expeditorul n
stnga i receptorul n dreapta, cnd axa timp ruleaz n josul paginii,
artnd mesajele schimbate de tip data (D) i confirmare (A). Asigurai-v
c indicai numrul de secven asociat cu oricare segment de date sau
confirmare.

15. P13. Luai n considerare un protocol de transfer de date de ncredere care

folosete doar recunoateri negative. S presupunem c expeditorul
trimite datele doar rareori. Ar fi protocolul NAK de preferat fa de un
protocol care utilizeaz ACK-uri? De ce? Acum, s presupunem c
expeditorul are o mulime de date pentru a trimite i conexiunea capt-la-
 capt (end-to-end) are puine pierderi. n acest al doilea caz, ar fi un
protocol NAK de preferat n locul unui protocol care folosete ACK-uri?
De ce?
In protocolul NAK, pierderea pachetului x este detectata numai de catre receptor
atunci cand primeste pachetul x+1. Receptorul primeste x-1 si apoi x+1, numai
cand x+1 este primit receptorul realizeaza ca pachetul x lipseste. Daca este o
mare intarziere de transmisie intre pachetul x si x+1 atunci va fi o lunga perioada
de timp pana ce pachetul x va putea fi recuperat in cadrul protocolului NAK.
Pe de alta parte daca data este transmisa des atunci recuperarea in cadru
protocolului NAK se face rapid. Mai mult daca erorile sunt rare atunci Nak sunt
transmise ocazional (cand e nevoie), si ACK nu este niciodata trimis o
reducere semnificativa a feedback in NAK asupra ACK se intampla.
16. P14. Luai n considerare exemplul de cross-country prezentat n Figura 3.
17. Ct de mare ar fi dimensiunea ferestrei pentru ca utilizarea canalului s
fie mai mare de 95 la sut? Presupunei c mrimea unui pachet este de
1500 octei, incluznd att antetul cat i datele.
Este nevoie de 12 microsecunde(sau 0.012milisecunde) pentru a trimite un
pachet, 1500*8/109=12 microsecunde. Pentru ca expeditorul sa fie ocupata 95%
din timp, trebuie sa avem util=0.95=(0.012n)/30.012 sau n=2376 pachete

17. P15. Presupunei c o aplicaie utilizeaz rdt 3.0 ca protocol la nivelul

transport. Deoarece protocolul stop-and-wait are utilizarea canalului foarte
sczut (prezentat n exemplul crosscountry), designerii acestei aplicaii
las receptorul s trimit napoi un numr de (mai mult de dou) ACK 0 i
ACK 1 alternative chiar dac datele corespunztoare nu au ajuns nc la
receptor. Ar crete utilizarea canalului aceasta decizie de proiectare? De
ce? Exist probleme posibile cu aceast abordare? Explicai.
Da. Aceasta determina expeditorul sa trimita un numar de date pipeline in canal(a
number of pipelined data into the chanell)
Da. Aici exista o potentiala problema. Daca segmentele de date sunt pierdute in canal,
atunci expeditorul rdt3.0 nu va retransmite acele segmente, numai daca exista
mecanisme aditionale in aplicatie care sa le recupereze din segmentele pierdute.
18. P16. n protocolul SR generic pe care l-am studiat n seciunea 3.4.4,
expeditorul transmite un mesaj de ndat ce acesta este disponibil (dac
este n fereastra) fr s mai atepte o confirmare. S presupunem acum c
vrem un protocol SR care trimite dou mesaje o dat. Aceasta nseamn c,
expeditorul va trimite o pereche de mesaje i va trimite urmtoarea pereche
de mesaje numai atunci cnd se tie c ambele mesajele din prima pereche
au fost primite corect. S presupunem c, canalul poate pierde mesajele,
dar nu va corupe sau reordona mesajele. Proiectai un protocol de
ncredere, unidirecional, cu controlul erorilor pentru transferul de mesaje.
Dai o descriere a FSM-ului transmitor i receptor. Descriei formatul
pachetelor trimise ntre transmitor i receptor i viceversa. Dac utilizai
orice procedura de apel, altele dect cele din seciunea 3.4 (de exemplu,
udt_send (), start_timer (), rdt_rev (), i aa mai departe) descriei clar
aciunile lor. Dai un exemplu (o cronologie a expeditorului i receptorului),
care prezint modul n care protocolul dvs. recupereaz un pachet pierdut.
In solutia noastra, expeditorul va astepta pana cand va primi un ACK pentru o
pereche de mesaje(seqnum si seqnum+1) inainte sa treaca la urm pereche de
mesaje. Pachetele de date au un camp de date si transporta doi biti de secventa
(carry a two-bit sequence number). Numerele de secventa valide sunt: 0,1,2 si 3.
ACK mesajului transporta numarul de secventa al pachetului de date pe care-l
recunoaste.FSM pentru receptor si expeditor sunt desenati in figura2. Observati
ca starea expeditorului ramane daca (i)niciun ACK a fost primit de la perechea
curenta,(ii)un ACK pentru seqnum (numai) a fost primit, sau un ACK pt
seqnum+1(numai) a fost primit. In figura presupunem ca seqnum este initial 0 si
ca expeditorul a trimis primele 2 mesaje de date.
 Expeditor Receptor
Make pair(0,1)
Send packet 0
Packet 0 drops
Send packet 1
Receive packet 1
Buffer packet 1
Send ACK 1
Receive ACK 1
(timeout)
Resend packet 0
Receive packet 0
Deliver pair (0,1)
Send ACK 0
Receive ACK 0
19. P17. Luai n considerare un scenariu n care gazda A vrea s trimit
simultan pachete la gazda B i C. A este conectat la gazda B i C printr-un
canal cu difuzare (broadcast) pachetul trimis de ctre A este trimis de
ctre canal att B ct i la C. S presupunem c acest canal cu difuzare ce
conecteaz A, B, i C poate, n mod independent pierde i corupe pachete
(i astfel, de exemplu, un pachet trimis de la A ar putea fi corect primit de
ctre B, dar nu i de ctre C). Proiectai un protocol stop-and-wait pentru
controlul erorilor, pentru transferul fiabil de la A la B i C, astfel nct A nu
va obine noi date de la nivelul superior pn cnd se tie c att C ct i B
au primit corect pachetul actual. Dai o descriere a FSM pentru A i C. (FSM
pentru B ar trebui s fie, n esen, acelai ca i pentru C.) De asemenea,
dai o descriere a formatului pachetului (pachetelor) utilizat
Aceasta problema este o problema schimbata a protocolului stop si wait (rdt3.0).
Deoarece canalul poate pierde mesaje si deoarece expeditorul poate retrimite un mesaj
pe care receptorul l-a primit deja ( sau din cauza unui timeout prematur sau deoarece
un alt receptor are inca de primit date corect ), este nevoie de numere de secventa. In
rdt3.0 o secventa 0-bit va fi suficienta.
Expeditorul si receptorul sunt reprezentati in figura3. In aceasta problema, starea
expeditorului indica daca expeditorul a primit un ACK de la B (numai) , de la C (numai)
sau de la niciunul (nici B nici C). Starea receptorului indica care numar de secventa este
asteptat de catre receptor.

20. P18. Luai n considerare un scenariu n care gazda A i gazda B vor s

trimit mesaje gazdei C. Gazdele A i C sunt conectate printr-un canal care
poate pierde i corupe (dar nu reordona) mesajele. Gazdele B i C sunt
conectate printr-un alt canal (independent de canalul de conectare ntre A
i C), cu aceleai proprieti. Nivelul de transport de la gazda C ar trebui sa
alterneze n livrarea de mesaje de la A i B la nivelul de mai sus (astfel,
acesta ar trebui prima data s furnizeze date de la un pachet de la A, apoi
date de la un pachet de la B i aa mai departe). Proiectai un protocol de
control al erorilor de tip stop-and-wait, pentru transferul fiabil de pachete
 de la A i B la C, cu furnizare alternativ la C aa cum s-a descris anterior.
Descriei FSM de la A i C. (Sugestie: FSM pentru B ar trebui s fie n
esen, aceleai ca pentru A.) De asemenea, descriei formatului pachetului
(pachetelor) utilizate.

Fig4. Receiver side FSM pt 3.17

Expeditorul FSM este exact acelasi ca cel dat in figura 3.15
21. P19. Luai n considerare protocolul GBN cu o dimensiune a ferestrei la
expeditor de 3 i un o gam de 1024 de numere de secven. S
presupunem c la momentul t, urmtorul pachet pe care receptorul l
ateapt are un numr de secven de valoare k. Presupunei c mediul nu
reordoneaz mesajele. Rspundei la urmtoarele ntrebri:
a. Care sunt posibilele seturi de numere de secven n interiorul
ferestrei expeditorului la momentul t? Justificai rspunsul.
b. Care sunt toate valorile posibile ale cmpului ACK n toate mesajele
posibile care se propaga napoi la expeditor la momentul t?
Justificai rspunsul.
a. Avem o fereastra cu dimensiunea N=3. Presupunem ca receptorul are pachetul
k-1, si are ACK acela si toate celelate pachete precedente. Daca toate aceste
ACK au fost primite de catre expeditor, atunci fereastra expeditorului este [k,k+N-
1]. Presupunem in continuare ca niciun ACK nu a fost primit la expeditor. In acest
 caz fereastra expeditorului contine k-1 si N pachete incluzand k-1(the senders
window contains k-1 and the N packets up to and including k-1). Fereastra
expeditorului [k-N,k-1].Cu aceste argumente, fereastra expeditorului este de
marime 3 si incepe in gama [k-N,k]
b. Daca receptorul asteapta pentru pachetul k, atunci a primit (and ACKed) pachetul
k-1 si N-1 pachete inainte de asta. Daca niciunul din cele N ACK nu au fost inca
primite de catre expeditor, atunci ACK mesajelor cu valorile [k-N,k-1] pot fi
propagate inapoi. Deoarece expeditorul a trimis pachetele [k-N,k-1] trebuie sa fie
cazul cand expeditorul a receptionat deja un ACK pentru k-N-1. Dupa ce
receptorul a trimis un ACK pentru k-N-1 nu va trimite niciodata un ACK care este
mai putin de k-N-1. Astfel valoarea ACK poate fin in intervalul [k-N-1,k-1]
22. P20. S presupunem c avem dou entiti de reea, A i B. B are o surs
de mesaje de date care vor fi trimise la A n conformitate cu urmtoarele
convenii. Cnd A primete o cerere de la nivelul superior pentru a obine
un mesaj cu datele urmtoare (D) de la B, A trebuie s trimit un mesaj de
tip cerere (R) la B pe canalul A-la-B. Numai atunci cnd B primete un
mesaj R poate trimite napoi la A un mesaj de date (D) pe canalul B-A . A ar
trebui s trimit exact o copie a fiecrui mesaj D ctre nivelul superior.
Mesajele R pot fi pierdute (dar nu corupte), n canalul A-la-B; mesajele D,
odat expediate, sunt livrate totdeauna corect. ntrzierea de-a lungul
ambelor canale este necunoscuta i variabil.
Proiectai un protocol care ncorporeaz mecanismele pentru a compensa
pierderea-deterioarea pe canalul A-la-B i implementeaz trecerea
mesajelor ctre nivelul superior al entitii A, dup cum s-a discutat
anterior. Utilizai numai acele mecanisme care sunt absolut necesare.
Deoarece canalul A-B poate pierde mesajele cerute, A va avea nevoie de timeout si sa
retransmita mesajul cerut (pentru a putea recupera din pierderi). Deoarece intarzierile
canalului sunt variabile si necunoscute, este posibil ca A sa trimita cereri duplicate (ex
retrimite un mesaj cerere care a fost primit deja de B). Pentru a putea detecta cererile
duplicate, protocolul va folosi numere de secventa.Un nr de secventa de 1-bit va fi
suficient pentru un protocol request/response de tip stop-and-wait.
A (solicitantul) are 4 stari:
Wait for Request 0 from above. Solicitantul asteapta pentru o cerere from
above pentru a solicita o unitate de data. Cand primeste o cerere from above,
trimite o cerere, R0 catre B, porneste un timer si face tranzitia catre starea Wait
for D0. Cand se afla in starea Wait for Request 0 from above, A ignora tot ceea
ce primeste de la B.
Wait for D0. Solicitantul asteapta pentru un mesaj D0 de la B. Un timer ruleaza
tot timpul in aceasta stare. Daca timer expira, A trimite alt R0, reporneste timer-ul
si ramane in aceasta stare. Daca un mesaj D0 este primit de la B, A opreste
timpul si trece in starea Wait for Request 1 from above. Daca primeste un
mesaj D1 in aceasta stare il ignora
Wait for request 1 from above. Solicitantul asteapta pentru o cerere from above
pentru a solicita o unitate de date.Cand primeste o solicitare from above, trimite
un mesaj cerere R1 la B, porneste un timer si face o tranzitie in starea Wait for
 D1. Cand se afla in starea Wait for Request 1 from above A ignora orice
primeste de la B.
Wait for D1.Solicitantul asteapta un mesaj de date D1 de la B. Un timer ruleaza
intotdeauna in aceasta stare.Daca timer expira, A trimite alt mesaj R1,
restarteaza timer si ramane in stare. Daca un mesaj D1 este primit de la B , A
opreste timer si trece in starea Wait for request 0 from above.Daca A primeste
un mesaj de date D0 in aceasta stare este ignorat.
Furnizorul de date(B) are doua stari:
Send D0. In aceasta stare B continua sa raspunda la mesajul primit R0
trimitand D0 si apoi ramanand in aceasta stare. Daca B receptioneaza un mesaj
R1 atunci stie ca mesajul D0 a fost receptionat corect. Astfel descarca data D0
(intrucat a fost primit in cealalta parte) si apoi trece in starea Send D1 unde va
folosi D1 pentru a trimite urmatoarea bucata de date ceruta.
Send D1. In aceasta stare, B continua sa raspunda la mesajul R1 primit
trimitand D1 si apoi ramane in aceasta stare. Daca B a primit un mesaj R1atunci
stie ca mesajul sau D1 a fost primit corect si astfel trece in starea Send D1.
23. P21. Considerai protocoalele GBN i SR. S presupunem c spaiul
numerelor de secven este de dimensiune k. Care este cea mai mare
fereastra care va prevenii, pentru fiecare dintre aceste protocoale, apariia
unor probleme cum ar fi cele din figura 3.27?

Pentru a evita scenariul din figura 3.27 ne dorim sa evitam marginea de conducere a
ferestrei receptorului(the leading edge of the receivers window) (ex cea cu nr de
secventa cel mai mare ) infasurrata in spatiul nr de secventa si suprapusa cu marginea
apropiata (the trailing edge) (cea cu nr de secventa cel mai mic in fereastra
expeditorului). Spatiul nr de secventa trebuie sa fie destul de mare pt a se potrivi cu
intreaga fereastra a receptorului si cu intreaga fereastra a expeditorului fara aceasta
conditie de suprapunere. Deci ne dorim sa determinam cat de larga trebuie sa fie o
gama de nr de secventa pt a putea acoperi oricand fereastra receptorului si a
expeditorului.
Presupunem ca cel mai mic nr de secventa pe care receptorul il asteapta este pachetul
m. In acest caz, fereastra sa este [m,m+1] si a primit (si a ACKed) pachetul m-1 si w-1
pachete inainte, w este dimensiunea ferestrei. Daca niciun w ACK nu a fost inca primit
de catre expeditor atunci mesajele cu ACK de valoare [m-w,m-1] se pot propaga inapoi.
Daca niciun ACKs cu aceste numere ACK nu au fost primite de expeditor atunci
fereastra expeditorului va fi [m-w,m-1].
Astfel cea mai mica margine a ferestrei expeditorului este m-w si the leading edge of
the receivers window este m+w-1. In order for the leading edge of the receiver's
window to not overlap with the trailing edge of the sender's window, the sequence
number space must thus be big enough to accommodate 2w sequence numbers. That
is, the sequence number space must be at least twice as large as the window size, .
wk2
24. P22. Rspundei adevrat sau Fals la urmtoarele ntrebri i justificai
scurt rspunsul dvs.:
a. Cu protocolul SR, este posibil pentru expeditor s primeasc un ACK
pentru un pachet care se ncadreaz n afara ferestrei sale curente.
b. Cu GBN, este posibil pentru expeditor s primeasc un ACK pentru
un pachet care cade n afara a ferestrei curente.
c. protocolul alternativ-bit este aceeai ca protocolul SR cu o fereastr
pentru expeditor i receptor avnd dimensiunea 1.
d. protocol alternativ-bit este aceeai ca protocolul GBN cu o fereastr
pentru expeditor i receptor avnd dimensiunea 1.
a. Adevarat. Presupunem ca expeditorul are o fereastra de marime 3 si trimite
pachetele 1,2,3 la timpul t0. La t1 (t1>t0) ACKS receptorului 1,2,3. La t2 (t2>t1)
expeditorul termina??? ( times out ) si retrimite 1,2,3. La t3 receptorul primeste
duplicatele si reconfirma 1,2,3. La t4 expeditorul primeste ACK pe care receptorul
le-a trimis la t1 si avanseaza fereastra la 4,5,6. La t5 expeditorul primeste ACK
1,2,3 pe care receptorul le-a trimis la t2. Aceste ACK se afla in afara ferestrei.
b. Adevarat. Acelasi scenariu va in cazul a.
c. Adevarat
d. Adevarat.Observam ca o fereastra de marime 1, SR, GBN si protocolul bit
alternativ sunt functional echivalente. Fereastra de marime 1 se opune
posibilitatii de a trimite pachetele in inordine(fara fereastra). Un ACK cumulativ
este doar un ACK ordonta in aceasta situatie, intrucat se poate referi doar la
pachetul fara fereastra.

25. P23. Am spus c o aplicaie poate alege UDP pentru protocolul de transport
deoarece UDP ofer controlul fin de la nivelul aplicaie (dect TCP) a
datelor care sunt trimise ntr-un segment i cnd sunt trimise.
 a. De ce are o aplicaie mai mult control asupra datelor trimise ntr-un
segment?
b. De ce are o aplicaie mai mult control asupra momentului cnd este
trimis un segment?
a. Consideram trimiterea unei aplicatii pe un protocol de transport. Cu TCP,
aplicatia scrie datele la in buffer de conexiune (connection send buffer) si TCP va
lua octeti fara a pune un singur mesaj in segmental TCP; TCP poate pune unul
sau mai multe mesaje intr-un segment. UDP, pe de alta parte, incapsuleaza intr-
un segment tot ceea ce primeste de la aplicatie; deci daca aplicatia da UDP-ului
un mesaj aplicatie, acest mesaj va fi incarcatura utila a segmentului UDP. Astfel,
cu UDP, o aplicatie are mai mare control asupra datelor trimise intr-un segment.
b. Cu TCP, prin controlul fluxului si a congestiei, pot aparea intarzieri importante de
la timpul in care o aplicatie scrie data in send buffer si pana cand data este
transmisa nivelului retea. UDP nu are intarzieri in timpul controlului fluxului si a
congestiei.
26. P24. Luai n considerare un transfer al unui fiier enorm de octei L de la
gazda la A la B. Presupunei c MSS este de 536 octei.
a. Care este valoarea maxim pentru L, astfel nct numerele de
secven TCP s nu fie epuizate? Amintii-v c locaia din antet care
conine numrul de secven pentru TCP are mrimea de 4 octei.
b. Pentru L obinut n (a), gsii ct timp este necesar pentru a transmite
fiierul. Presupunei c se adaug un total de 66 de octei
corespunztori nivelurilor transport, reea, i legtur de date, pentru
fiecare segment nainte ca pachetul rezultat s fie trimis pe o
legtur cu viteza de 155 Mbps. Ignorai controlul fluxului i controlul
congestiei, astfel ca A s poat trimite segmentele n mod continuu
unul dup altul.
Sunt 232 = 4.294.967.296 nr de secventa posibile
a. Nr de secventa nu se incrementeaza cu unul cu fiecare segment. Mai degraba,
se incrementeaza cu nr de octeti de date trimise. Deci marimea MSS este
irelevanta marimea maxima a unui fisier ce poate fi trimis de la A la B este nr
de octeti reprezentati de 232 = 4.19 GB

b. Nr de segmente este = 8.012.999,66 octeti din header sunt adunati la fiecare

segment un total de 528.857.934 octeti de header. Nr total de octeti trimisi
este 232+528.857.934 = 4.824 * 10 9. Astfel vor fi necesare 249 de secunde
pentru a transmite un fisier pe o legatura de 155Mbps
27. P25. Gazda A i B comunic printr-o conexiune TCP, i gazda B deja a
primit de la A toi octeii pn la octetul 126. Presupunei c gazda A trimite
dou segmente la gazda B back-to-back. Primul i cel de-al doilea conin 70
i, respectiv, 50 de octei de date. n primul segment, numrul de secven
este de 127, numrul de port surs este 302, i numrul portului destinaie
este 80. Gazda B trimite o confirmare de primire ori de cte ori primete un
segment de la gazda A.
 a. n al doilea segment transmis de la gazda la A la B, care este numrul
de secven, numrul portului surs, i numrul portului destinaie?
b. Dac, primul segment ajunge nainte celui de-al doilea segment, care
este numrul de confirmare, numrul portului surs, i numrul
portului destinaie, n confirmarea primului segment care sosete?
c. Dac al doilea segment ajunge nainte de primul segment, care este
numrul de confirmare n confirmarea primului segment care
sosete?
d. S presupunem c cele dou segmente trimise de A ajung n ordine
la B. Prima confirmare este pierdut i recunoaterea celui de-al
doilea ajunge dup primul timeout. Desenai o diagram de timp,
care prezint aceste segmente i toate clelate segmente i confirmri
transmise. (Presupunem nu exist nici o pierdere suplimentar de
pachete). Pentru fiecare segment din figur, furnizai numrul de
secven, numrul de octei de date; pentru fiecare confirmare pe ai
adugat-o, precizai numrul de confirmare.
a. In al doilea segment de la Gazda A la B nr de secventa este 197, nr port sursa
302 si port destinatie 80.
b. Daca primul segment ajunge inainte celui de-al doilea, in confirmarea sosirii
primului segment, nr de confirmare este 197, port sursa 80 port destinatie 302.
c. Daca al doilea segment ajunge inaintea primului, in confirmarea primului
segment , nr de confirmare este 127, indicand ca inca asteapta pt octetul 127 si
inaintare.

d.

28. P26. Gazdele A i B sunt conectate direct pe o legtur de 100 Mbps.

Exist o conexiune TCP ntre cele dou gazde, i gazda A va trimite la
gazda B un fiier enorm. Gazda A poate trimite datele sale de la nivelul
aplicaie la socket-ul TCP la o vitez maxim de 120 Mbps dar gazda B
poate citi din buffer-ul de recepie TCP la o vitez maxim de 60 Mbps.
Descrie efectul controlului fluxului la nivelul TCP.
Deoarece capacitea legaturii esre 100Mbps, deci rata de transmisie a gazdei A poate fi
100Mbps. Totusi, gazda A trimte date in receiver buffer mai rapid decat poate gazda B
sa preia datele din buffer. Receiver buffer se umple la o rata de aproximativ 40Mbps.
Cand buffer este plin, gazda B trimite semnal pt A sa inceteze trimiterea datelor setand
RcvWindow=0.Astfel A opreste trimiterea pana ce primeste un segment TCP cu
RcvWindow>0. A va repeta start si stop trimitere functie de RcvWindow primit de la B. In
medie cea mai mare rata la care A trimite date lui B in aceasta conexiune nu este mai
mare de 60Mbps.
29. P27. SYN cookies au fost discutate n seciunea 3.5.6.
a. De ce este necesar pentru server utilizarea unui numr special de
secven iniial n SYNACK?
b. S presupunem c un atacator tie c o gazd int folosete SYN
cookies. Poate atacatorul s creeze conexiuni pe-jumtate deschise
sau complet deschise prin simpla trimitere a unui pachet ACK la
int? De ce sau de ce nu?
c. S presupunem c un atacator colecteaz o cantitate mare de
numere de secven iniiale trimise de server. Poate atacatorul fora
serverul pentru a crea mai multe conexiuni complet deschise prin
trimiterea de ACK-uri cu acele numere de secven iniiale? De ce?
a. Serverul primeste nr de secventa special inititial (obtinut din hash sursa si
destinatie IP si porturi) pentru a se apara impotriva atacului de tip SYN FLOOD.
b. Nu, atacatorul nu poate crea conexiuni half-open sau fully open prin simpla
trimitere si pachetelor ACK la tinta. Conexiunile half-open nu sunt posibile
deoarece un server ce foloseste SYN cookies nu mentine variabilele de
conexiune si bufferele pt orice conexiune pana ce nu se stabileste o full
conection. Pentru a stabili o full conection un atacator ar trebui sa stie nr de
secventa initial special ce corespunde IP sursa a atacului (spoofed). Acest nr de
secventa cere nr secret pe care fiecare server il foloseste. Deoarece nu stie nr
secret nu poate sa ghiciasca nr de secventa initial
c. Nu, serverul poate doar sa adauge intr-un time stamp in computing acele nr de
secventa si sa aleaga un timp de viata pt acele nr de secventa si sa renunte la nr
de secventa initiale expirate chiar daca atacatorul le inlocuieste
30. P28. Luai n considerare reeaua afiat n Scenariul 2 din Seciunea 3.6.
1. S presupunem c ambele gazde A i B care trimit au valori fixe pentru
timeout.
a. Argumentai de ce o cretere a dimensiunii unui buffer finit de la un
ruter ar putea reduce, eventual, fluxul de ieire (out).
b. Acum, s presupunem c ambele gazde ajusteze dinamic valorile lor
timeout (ceea ce face TCP), pe baza ntrzierii date de buffer-ele de la
ruter. Creterea mrimii buffer-ului ar ajuta la creterea fluxului. De
ce?
Daca valorile timeout sunt fixe, atunci expeditorii pot da timeout premature. Astfel unele
pachete sunt retransmise chiar daca nu sunt pierdute.Daca valorile pt timeout sunt
estimate (cum face TCP), atunci cresterea marimii bufferului cu siguranta ajuta la
cresterea ratei de transfer a acelui router. Dar ar putea aparea o problema. Intarzierile
din coada ar putea fi foarte mari, similar cu ceea ce este descries in scenariul 1

31. P29. Considerai procedura TCP pentru estimarea RTT. S presupunem c

= 0,1. Fie SampleRTT1 cel mai recent eantion RTT, fie SampleRTT2
eantionul urmtor cel mai recent i aa mai departe.
a. Pentru o anumita conexiune TCP, s presupunem c au fost
returnate patru confirmri Cu RTT-urile corespunztoare
SampleRTT4, SampleRTT3, SampleRTT2 i SarnpleRTT1. Exprimai
RTT n funcie de cei patru termeni.
b. Generalizai formula pentru n eantioane ale RTT.
c. Pentru formula din (b) s presupunem c n tinde la infinit. Comentai
de ce aceast procedur de mediere este denumit procedur de
mediere exponenial,
a.

b.

c.
32. P30. n seciunea 3.5.3, am discutat despre estimarea TCP pentru RTT. De
ce credei c TCP evit msurarea valorii SampleRTT pentru segmentele
retransmise?
Sa ne uitam la ce ar putea fi gresit la masurile TCP SampleRTT pentru retransmiterea
unui segment. Presupunem ca sursa trimite pachetul P1, timer pt P1 a experitat, si
sursa trimite apoi P2, o noua copie a aceluiasi pachet. Mai departe presupunem ca
sursa masoara SampleRTT pentru P2 [the source measures SampleRTT for P2]
(pachetul retransmis). In final presupunem ca la putin timp dupa transmiterea lui P2
apare o confirmare pentru P1. Sursa va prelua din greseala aceasta confirmare ca fiind
pentru P2 si va calcula o valoarea incorecta pentru SampleRTT.
33. P31. Care este relaia dintre variabila SendBase din seciunea 3.5.4 i
variabila LastByteRcvd din seciunea 3.5.5?
La orice moment de timp t, SendBase-1 este nr de secventa al ultimului octet pe care
expeditorul il cunoaste ca fiind primit corect, si in ordide de catre receptor. De fapt
ultimul octet primit (corect si in ordine) la receptor la timpul t poate fi mai mare daca
sunt confirmari in teava (pipe).Astfel SendBase 1 LastByteRcvd
 34. P32. Care este relaia dintre variabila LastByteRcvd din seciunea 3.5.5 i
variabila y din seciunea 3.5.4?
Cand la momentul t, expeditorul primeste o confirmare cu valoarea y, expeditorul stie
sigur ca receptorul a primit tot pana la y-1. De fapt ultimul octet primit (corect si in
ordine) la receptor la momentul t poate fi mai mare y SendBase sau daca sunt alte
confirmari in teava (pipe). Astfel y-1 LastByteRvcd.
35. P33. n Seciunea 3.5.4, am vzut c TCP ateapt pn cnd aceasta a
primit trei ACK dublate nainte de efectuarea unei retransmisii rapide. De
ce credei c designerii TCP nu au ales s efectueze o retransmisie rapid
dup primul ACK dublat pentru un segment primit ?
Presupunem ca pachetele n,n+1 si n+2 sunt trimise, si ca pachetul n a primit un ACKed.
Daca pachetele n+1 si n+2 sunt reordonate in timpul end-to-end-path (ex sunt primate
in ordinea n+2,n+1) atunci primirea pachetului n+2 va genera un duplicat ack pentru n si
va triggera o retransmisie sub o politica de a astepta numai pentru al doilea ACK
duplicat ce va fi retransmis. Asteptarea celui de-al treilea ACK duplicat, trebuie sa fie
cazul in care doua pachete au fost primite corect dupa pachetul n, in timp ce n+1 nu a
fost primit. Proiectantii schemei pentru triplu ACK duplicat s-au gandit ca asteptarea
pentru doua pachete (decat 1) era compromisul cel mai bun intre triggerarea unei
transmisii rapide cand este nevoie, dar nu retransmisia premature in fata reordonarii
pachetelor.
36. P34. Comparai GBN, SR, i TCP (nu ACK ntrziat). S presupunem c
valorile timeout pentru toate cele trei protocoale sunt suficient de lungi
astfel nct pot fi primite 5 segmente consecutive de date i confirmrile
lor corespunztoare (n cazul n care nu sa-au pierdut n canal) de ctre
gazda primitoare (Host B) i, respectiv, de gazda care a trimis (Host A). S
presupunem c gazd A trimite 5 segmente de date la gazda B, i
segmentul 2 (trimis de la A) este pierdut. n final, toate cele 5 segmente de
date au fost primite n mod corect de ctre gazd B.
Observam ca este un tip in textbook
Part b, 5 nu apare in .RTT
Daca valorile timeout pentru toate trei protocoalele sunt mult mai lungi decat .RTT

Daca valorile timeout pentru toate trei protocoale sunt mult mai lungi decat 5*RTT
a. Ct de multe segmente a trimis gazda A n total i cte ACK-uri a trimis
gazda B n total? Care sunt numerele lor de secven? Rspundei la
aceast ntrebare pentru toate cele trei protocoale.
b. n cazul n care valorile timeout pentru toate cele trei protocoale sunt mai
lungi de 5 RTT, atunci care protocol furnizeaz cu succes toate cele cinci
segmente de date n cel mai scurt interval de timp?
a. GoBackN:
A trimite 9 segmente in total.Initial trimite segmentele 1,2,3,4,5 si mai tarziu retrimite
segmentele 2,3,4,5.
B trimite 8 ACKs. 4 ACK cu nr de secventa 1, si 4ACK cu nr de secventa 2,3,4,5
Selective Repeat:
A trimite 6 segmente in total. Initial trimite segmentele 1,2,3,4,5 si apoi retrimite
segmental 2
 B trimite 5 ACK. 4 ACK cu nr de secventa 1,3,4,5 si un ACK cu nr de secventa 2
TCP:
A trimite 6 segmente in total. Initial sunt trimise segmentele 1,2,3,4,5 si apoi
retransmis segmental 2.
B trimite 5 ACK. 4 ACK cu nr de secventa 2. Un ACK cu nr de secventa 6. Observam
ca TCP trimite intotdeauna un ACK cu nr de secventa asteptat.
b. TCP. Asta deoarece TCP foloseste retransmisia rapida fara a astepta timeout.
53. P35. n descrierea TCP-ului n figura 3.53, valoarea pragului, ssthresh, este
setat ca ssthresh = cwnd / 2 n mai multe locuri i valoarea ssthresh este
menionat ca fiind stabilit la jumtate din dimensiunea ferestrei atunci
cnd a avut loc un eveniment de tip pierdere de pachet. Trebuie ca rata la
care expeditorul trimite, atunci cnd a avut loc un eveniment de tip
pierdere, s fie aproximativ egal cu cwnd segmente/ RTT? Explic
rspunsul tu. Daca rspunsul tu este nu, poi sugera un mod diferit n
care ar trebui s fie setat ssthresh?

Da, rata de transmisie este intotdeauna aproximativ cwnd/RTT.

54. P36. Luai n considerare Figura 3.46 (b). Dac crete peste R /2, poate
crete peste R / 3? Explicai. Acum, ia n considerare Figura 3.46 (c).
Dac crete peste R / 2, poate crete peste R/4 n ipoteza c un
pachet va fi transmis n medie de dou ori de la router la receptor"?
Explicai.
In cazul in care rata de transmisie soseste de R/2 ca in figura, atunci rata totala ajunsa
in coada creste capacitatea cozii, rezulta o crestere in pierderi cand rata totala ceste.
Cand rata ajunsa este egala cu R/2, unul din fiecare 3 pachete care pleca din coada
este retransmis. Cu pierderile in crestere, chiar si o fractiune mai mare de pachete care
parasesc coada va fi retransmise. Avand in vedere ca rata maxima de plecare din
coada pentru una din sesiuni este R/2, si avand in vedere ca o treime sau mai mult va fi
retransmis pe masura ce creste rata de sosire, rata de transfer nu poate creste dincolo
de out. Daca jumatate din pachetele care pleaca din coada sunt retransmisii si rata
maxima de transmisie a pachetelor care pleca pe sesiune este R/2, atunci valoarea
maxima a out este (R/2)/2 sau R/4.
55. P37. Luai n considerare Figura 3.58. Presupunnd c TCP Reno este
protocolul care determin comportamentul din figur, rspundei la
urmtoarele ntrebri. n toate cazurile, trebuie s furnizai o scurt
discuie care s justifice rspunsul dvs.
a. Identificai intervalele de timp atunci cnd opereaz startul lent n
TCP.
b. Identificai intervalele de timp atunci cnd opereaz evitare congestie
n TCP.
c. Dup runda 16 de transmisie, este pierderea segmentului detectat
de un triplu ACK dublat (acelai ACK dublat de trei ori) sau de ctre
un timeout?
d. Dup runda 22 de transmisie, este detectat pierderea segmentului
de un triplu ACK dublat sau de ctre un timeout?
e. Care este valoarea iniial a ssthresh la prima rund de transmisie?
f. Care este valoarea ssthresh la runda 18 de transmisie?
g. Care este valoarea ssthresh la runda 24 de transmisie?
h. n timpul crei runde de transmisie este trimis al 70-lea segment?
i. Presupunnd c o pierdere de pachet este detectat dup runda 26
de primirea unui triplu ACK dublat, care va fi valoarea mrimii
ferestrei de congestie i valoarea pentru ssthresh?
j. S presupunem c TCP Tahoe este utilizat (n loc de TCP Reno), i
presupunei c n runda 16 este recepionat un triplu ACK dublat.
Care este valoarea pentru ssthresh i dimensiunea ferestrei de
congestie n runda 19?
k. Din nou, s presupunem c TCP Tahoe este utilizat, i exist un
eveniment timeout n runda 22. Cte pachete au fost trimise de la
runda 17 pn la runda 22, inclusiv?

a) Startul lent al TCP-ului opereaza intre intervalele [1,6] si [23,26];

b) Evitarea congestiei TCP opereaza intre intervalele [6,16] si [17,22];
c) Dupa a 16 - a retransmisie, pierderea de pachete este recunoscuta
de un triplu duplicat ACK. Daca a fost un timeout, marimea ferestrei
de congestive va ajunge la 1;
d) Dupa a 22 a retransmisie, segmentele pierdute sunt detectate de
timeout, si de cand fereastra de congestive este setata pe 1;
e) Pragul initial este 32, de cand marimea ferestrei opreste startu lent,
si evitarea congestiei incepe;
f) Pragul initial este setat la jumatate din valoarea ferestrei de
congestie cand se detecteaza pierderi de pachete. Cand se
detecteaza pierderi de pachete in timpul retransmisiei a 16 a,
fereastra de congestie este setata la 42. De cand pragul este 21 in
timpul celei dea a 18-a retransmisie ;
g) Pragul este setat la jumatate din valoarea ferestrei de congestie
cand se detecteaza pierderi de pachete. Cand se detecteaza
pierderi in timpul retransmisiei 22, fereastra de congestie este
setata la 26. De cand pragul este setat la 13 in timpul retrasmisiei
24.
 h) In timpul primei retransmisiei, pachetul 1 este trimis; pachetele 2-3
sunt transmise in cea de-a 2-a retransmisii; pachetele 4-7 trimise in
cea de-a 3-a retransmisii; pachetele 8-15 in cea de a -4-a
transmisii; pachetele 16-31 in a 5 a transmisii; pachetele 32-63 cea
de-a 6 a transmisii; pachetele 64-96 in a 7 a transmisie. Astfel
pachetul 70 este transmis in transmisia 7.
i) Pragul ferestrei de congestie va fi setat la jumatate din valoarea
curenta a ferestrei de congestie (8) cand apar pierderi. Astfel
valoarea pragului si ferestrei va fi 4;
j) Pragul este 21, si marimea ferestrei de congestie este 1;
k) Runda 17, 1 pachet; runda 18, 2 pachete; runda 19, 4 pachete;
runda 20, 8 pachete; runda 21, 16 pachete; runda 22, 21 pachete.
Deci numarul total este 52.
56. P38. Figura 3.56, ilustreaz convergena algoritmului TCP AIMD.
Presupunei c n loc de o scdere multiplicativ, TCP a sczut
dimensiunea ferestrei cu o sum constant. Algoritmul AIAD rezultat
converge ctre un algoritm cu partajare egal? Justificai rspunsul
utiliznd o diagram similar cu aceea din figura 3.56.

Facand referinta la figura 5, raportul descresterii liniare de pierderi intre conexiunea 1 si

conexiunea 2 este acelasi ca raport al cresterii liniare: unitate. In acest caz, transferal
nu se va muta nicioadata de pe linia de segment AB. In fugura raportul descrestrii liniare
dintre conexiunea 1 si conexiunea 2 este 2:1. Asta este oricand vaem pierderi,
conexiunea 1 isi micsoreaza fereastra de 2 ori mai mult decat conexiunea 2. Putem
eventual sa vedem dupa multe pierderi si o crestere ulterioara, transferal conexiunii 1
va merge spre 0, si o latime de banda maxima alocata pentru link-ul conexiunii 2.
 57. P39. n seciunea 3.5.4, am discutat despre dublarea interval de timp
pentru timeout dup un eveniment de tip timeout. Acest mecanism este o
form de control a congestiei. De ce are nevoie TCP de un mecanism de
control al congestiei bazat pe fereastr (cum studiat n seciunea 3.7), n
plus fa de acest mecanism de dublare-interval-timeout?
Daca protocolul TCP ar fi fost un protocol stop-and-wait, atunci dublarea intervalului
timeout ar ajunge ca mechanism de control al congestiei. Oricum TCP foloseste
pipelining (si asta deoarece nu exista un protocol stop-and-wait), ceea ce permite
expeditorului sa aiba segmente remarcabile (outstanding) multiple fara confirmare.
Dublarea intervalului pentru timeout nu previne un expeditor TCP sa trimita un numar
mare de pachete first-time-transmitted in retea,chiar atunci cand calea end-to-end este
in mare congeestie. Astfel este nevoie de un mechanism de control al congestiei pentru
a opri fluxul de date primite de la aplicatia anterioara atunci cand sunt semne ale unei
retele in congestie.
58. P40. Gazda A trimite un fiier enorm la gazda B printr-o conexiune TCP. n
ceea ce privete aceasta conexiune nu exist nici o pierdere de pachete si
timer-ele nu expir niciodat. Se noteaz cu R bps viteza de transmisie a
legturii de la gazda A la Internet. S presupunem c un proces din gazda
A este capabil de a trimite date n socket-ul TCP la o rat de Sbps , unde S
= 10 x R. Presupunem mai departe c buffer-ul de recepie TCP este
suficient de mare pentru a deine ntregul fiier, i buffer-ul de emisie
poate deine doar un procent din fiier. Ce mpiedica procesul din gazda A
s trimit date continuu ctre socket-ul su TCP la viteza Sbps? Controlul
fluxului n TCP? Controlul congestiei n TCP? Sau altceva? Elaboreaz.
In aceasta problema, nu exista pericolul de inundare a receptorului, de cand bufferul
receptorului poate memora intregul fisier. De asemenea, deoarece nu exista pierderi si
acknowledgements sunt returnate inainte sa expire timer-ele, controlul congestiei TCP
nu gatuie expeditorul. Oricum procesul din gazda A nu va trimite date catre socket
deoarece bufferul de trimitere se va umple. Odata ce bufferul de trimitere devine plin,
procesul trimite datele la o rata medie de transefer de R<<S.
59. P41. Luai n considerare trimiterea unui fiier mare de la o gazd la alta
printr-o conexiune TCP, care nu are nici o pierdere.
a. S presupunem c TCP folosete AIMD pentru controlul congestiei,
fr a ncepe lent. Presupunnd c cwnd crete cu 1 MSS este
recepionat un lot de ACK i presupunnd un timp dus-ntors
 aproximativ constant, ct de mult dureaz ca cwnd s creasc de la 5
MSS la 11 MSS (presupunnd c nu apare nici o pierdere de
evenimente)?
b. Care este fluxul mediu (n funcie de MSS i RTT), pentru aceast
conexiune pe o durat de = 6 RTT?
a) Este nevoie de 1 RTT pentru a creste CongWin la 6 MSS; 2 RTT pentru a creste
la 7 MSS; 3 RTT pt a creste la 8 MSS; 4 RTT pt a creste la 9 MSS; 5 RTT pt a
creste la 10 MSS; si 6 RTT pt a creste la 11 MSS.
b) In primul RTT 5 MSS sau trimis; In al doilea RTT 6 MSS sau trimis; in al treilea
RTT sau trimis 7 MSS; in al patrulea RTT 8 MSS sau trimis; in al cincilea RTT 9
MSS sau trimis; in al saselea RTT 10 MSS sau trimis. Acei 6 timpi RTT
5+6+7+8+9+10=45 MSS sau trimis. Putem spune ca timpul mediu de transfer
este de 6 RTT (45 MSS)/(6 RTT) = 7.5 MSS/RTT.
60. P42. S ne reamintim descrierea macroscopic al fluxului n TCP. n
perioada de timp ct viteza pe conexiune variaz de la W/(2xRTT) la W/RTT
se pierde doar un pachet (la captul perioadei).
a. Artai c viteza (rata) de pierdere (fractiunea de pachete pierdute)

este egal cu L = loss rate = .

b. Utilizai rezultatul anterior pentru a arta c dac o conexiune are
rata de pierdere L, atunci rata medie este dat aproximativ de

Rata de pierdere, L, este raportul numarului de pachete pierdute din numarul de

parchete trimise. Intr-un ciclu, 1 pachet este pierdut. Numarul de pachete trimise intr-un
ciclu este:
 61. P43. Considerai ca o singur conexiune TCP (Reno) utilizeaz o legtur
de 10Mbps care nu buffer-eaz datele. Presupunei c aceast legtur
este singura congestionat ntre gazdele emitor i receptor. Presupunei
c emitorul TCP are de transmis un fiier imens la receptor, iar buffer-ul
receptorului este mult mai mare dect fereastra de congestie. Facem de
asemenea urmtoarele presupuneri: Fiecare segment TCP are mrimea de
1500 octei; ntrzierea de propagare n ambele sensuri este de 100 msec;
i aceast conexiune TCP este ntotdeauna n faza de evitare a congestiei,
ca urmare, ignorai startul lent.
a. Care este mrimea maxim a ferestrei (n segmente) pe care o poate
atinge aceast conexiune TCP?
b. Care este mrimea medie a ferestrei (n segmente) i fluxul mediu (n
bps) al acestei conexiuni TCP?
c. Ct de mult i va lua acestei conexiuni TCP pentru a atinge din nou
valoarea maxim a ferestrei dup recuperarea unui pachet pierdut?
a) Let W denota marimea maxima a ferestrei masurata in segmente. Atunci ,
W*MSS/RTT = 10Mbps , ca pachet va fi pierdut daca rata de transmisie ajunge la
capacitatea link-ului. Avem W*1500*8/0.1=10*10^6 , atunci W are 84 de
segmente.
b) Ca fereastra de congestive marimea ei variaza de la W/2 la W, atunci marimea
medie a ferestrei este 0.75W=63 segmente . Transferul mediu este 63*1500* 8/0.1
=7.56Mbps.
c) 84/2 * 0.1 = 4.2 secunde, ca numar de RTT (congetia TCP comanda cresterea
marimii ferestrei de la w/2 la w) este data de W/2. Reapeleaza ca marimea
ferestrei sa fie marita cu 1 la fiecare RTT
62. P44. Considerai scenariul descris n problema precedent. Presupunei c
legtura de 10 Mbps poate buffer-a un numr finit de segmente.
Argumentai de ce pentru a menine legtura ntotdeauna ocupat cu
trimiterea datelor, trebuie s alegem o mrime a buffer-ului care este cel
puin produsul dintre viteaza C a legturii i ntrzierea de propagare cu
dou ci ntre emitor i receptor.
Let W denota marimea maxima a ferestrei. Let S denota marimea maxima a buffer-ului.
Pentru simplitate, presupunem ca emitatorul TCP trimite pachete de date din cerc in
cerc, fiecare cerc corespunde cu un RTT. Daca marimea ferestrei ajunge la W, atunci
apar pierderi. Atunci emitatorul va injumatati fereastra de congetie la jumatate, si
asteapta ACK pentru W/2 inainte de a trimite segmentele de date din nou. In loc sa
asigure link-ul intotdeauna ocupat cu trimiterea datelor, este nevoie sa tinem link-ul
ocupat cu trimiterea datelor in perioada W/(2*C)(este intervalul de timp unde emitatorul
asteapta ACK pentru W/2). Acel S/C nu trebuie sa fie mai mic decat W/(2*C) asta este
S>=W/2.
Let Tp denota o singura cale de propagare a intarzierilor dintre emitator si receptor.
Cand marimea minima a ferestrei atinge W/2 si buffer-ul este gol, trebuie sa fim siguri
ca link-ul este si el ocupat cu trimiterea datelor. Astfel trebuie sa avem W/2(2Tp)>=C,
astfel W/2>=C*2Tp.
Astfel S>=C*2Tp.
63. P45. Repetai problema 43, dar nlocuii legtura de 10 Mbps cu o legtur
cu 10 Gbps. De notat c n rspunsul vostru de la punctul c, ai realizat c
este necesar un timp foarte lung pentru ca mrimea ferestrei de congestie
s ating maximul mrimii ferestrei dup recuperarea unui pachet pierdut.
Dai o soluie pentru a rezolva aceast soluie.
a) Let W denota marimea maxima a ferestrei. Atunci W*MSS/RTT = 10 Gbps, ca
pachete vor fi pierdute daca rata de transfer ajunge la capacitatea link-ului. Astfel
avem W*1500*8/0.1=10*10^9, atunci W=83334 segmente.
b) Ca si fereastra de congestive marimea variaza de la W/2 la Wm atunci marimea
medie a ferestrei este 0.75W=62501 segmente. Traficul mediu este
62501*1500*8/0.1=7.5Gbps.
c) 83334/2*0.1/60=69 minute. In loc sa acceleram procesul de crestere al ferestrei,
putem accelera marimea ferestrei cu o valoare mult mai mare, in loc de cresterea
marimii ferestrei cu cate 1 la fiecare RTT. Unele protocoale sunt propuse sa
resolve aceasta problema, precum ScalableTCP sau HighSpeedTCP.
64. P46. Se noteaz cu T (msurat pe baza lui RTT) intervalul de timp necesar
unei conexiuni TCP pentru a crete mrimea ferestrei de control de la W/2
la W, unde W este mrimea maxim a ferestrei de control. Argumentai de
ce T este o funcie de fluxul (viteza de transmisie) mediu.

Ca transfer mediu TCP, B este dat de: deci stim asta,

L=(1.22*MSS/(B*RTT))^2
De cand doua pierderi de pachete consecutive, sunt 1/L pachete trimise de emitatorul
TCP, astfel T=(1/L)*MSS/B. Astfel, putem gasi ca T=B*RTT^2/(1.22^2*MSS), T este
functie de B.
65. P47. Considerai un algoritm AIMD TCP simplificat unde mrimea ferestrei
de congestie este msurat n numrul de segmente i nu n octei. n
cazul creterii prin adunare (additive increase) mrimea ferestrei de
congestie crete cu 1 n fiecare RTT. n cazul descreterii prin multiplicare,
mrimea ferestrei de congestie descrete cu jumtate (dac rezultatul nu
este un ntreg, se rotunjete la valoarea mai mic a urmtorului ntreg).
Presupunei c dou conexiuni TCP C1 i C2 partajeaz o singur legtur
congestionat care are viteza de 30 de segmente / secund. Presupunei
 c att C1 ct i C2 sunt n faza de evitare a congestiei. RTT ul conexiunii
C1 este de 100 msec, iar cel al conexiunii C2 este de 200 msec.
Presupunei c atunci cnd viteza datelor pe legtur depete viteza
legturii, toate conexiunile TCP sufer pierderi de segmente.
a. Dac att C1 ct i C2 la timpul t0 au o fereastr de congestie de 10
segmente, care este fereastra lor de congestie dup 2200 msec?
b. n cazul unei execuii lungi, aceste dou conexiuni vor avea aceeai
partajare a lrgimii de band al conexiunii congestionate? Explicai.
a) Diferenta dintre C1 si C2 este ca RTT-ul lui C1 este jumatate din cel al lui C2.
Astfel C1 isi ajusteaza marimea ferestrei dupa 100 msec, dat C2 ajusteaza
marimea ferestrei dupa 200 msec.
Sa presupunem ca ori de cate ori avem pierderi C1 primeste dupa 100 msec si
C2 dupa 200 msec.
Mai departe avem modul simplificat de TCP
Dupa fiecare RTT, o conexiune determina daca trebuie sa mareasca sau nu
marimea ferestrei. Pentru C1, calculam media totala a ratei de transmisie a datelor
din link-ul anterior cu 100 msec. Daca acea rata depaseste capacitatea link-ului,
daca presupunem ca C1 detecteaza o pierdere si isi reduce marimea ferestrei. Dat
pentru C2 , calculam media totala a ratei de transmisie a datelor din link-ul
anteriod cu 200 msec. Daca rata depaseste capacitatea link-ului, atunci presupunem
ca C2 a detectat pierderi si isi reduce fereastra la jumatate.
Retineti ca este posibil ca rata de transfer medie in ultimele 100 msec este mai
mare decat capacitatea link-ului, dar media ratei de transmisie in ultimele 200 msec
este mai mica sau egala cu capacitatea link-ului, atunci in acest caz, presupunem ca
C1 va avea pierderi si C2 nu.
Tabelulurmatordescrieevolutiamarimiiferestreisirateledetransferbazarepe
ipotezeledemaisus.
Time (msec) Window Size Average data sending Window Average data
(num. of segments rate (segments per Size(num. of sending rate
sent in next second, segments sent (segments per
100msec) =Window/0.1) in next second,
200msec) =Window/0.2)
0 10 100 (in [0-100]msec] 10 50 (in [0-
100]msec)
100 5 50 (in [100- 50 (in [100-200]msec)
(decreases 200]msec]
window size as
the avg. total
sending rate to the
link in last
100msec is 150=
100+50)
200 2 20 5 25
(decreases window (decreases window
size as the avg. total size as the avg. total
sending rate to the sending rate to the
link in last 100msec link in last 200msec
is 100= 50+50) is 125= (100+50)/2
+ (50+50)/2)

300 1 10 25
(decreases window size as the
avg. total sending rate to the link
in last 100msec is 45= (20+25)
400 1 10 2 10
(no further decrease, (decreases window
as window size is size as the avg. total
already 1) sending rate to the
link in last 200msec
is 40= (20+10)/2 +
(25+25)/2)
500 2 20 10
600 3 30 3 15
700 1 10 15
800 2 20 1 5
900 3 30 5
1000 1 10 2 10
(decreases window (increases window
size as the avg. total size as the avg. total
sending rate to the sending rate to the
link in last 100msec link in last 200msec
is 35= (30+5) is 30= (20+30)/2 +
(5+5)/2)

1100 2 20 10
1200 3 30 3 15
1300 1 10 15
1400 2 20 1 5
1500 3 30 5
1600 1 10 2 10
1700 2 20 10
1800 3 30 3 15
1900 1 10 15
2000 2 20 1 5
2100 3 30 5
2200 1 10 2 10
Bazate pe datele din tabelul de mai sus, gasim ca dupa 2200 msec, vedem ca fereastra
lui C1 este de un sement si a lui C2 de 2 segmente.
b) Nu. Pe termen lung latimea de banda a lui C1 este de doua ori cat C2, deoarece
C1 are RTT mai scurt, doar jumatate din C2, deci C2 poate sa isi ajusteze
marimea ferestrei de 2 ori mai repede decat C2. Daca de uitam mai sus in table
vedem cicluri la fiecare 600 ms , e.g de la 1400 ms pana la 1900 ms inclusive.
 Intr-un ciclu rata de transmisie a lui C1 este (20+30+10+20+30+10)/6=120, care
este de 2 ori mai mare ca a lui C2 ca este (5+5+10+15+15)/6=60.
66. P48. Considerai reeaua descris n problema precedent. Presupunei
acum c cele dou conexiuni C1 i C2 au acelai RTT de 100 msec.
Presupunei c la momentul t0, fereastra de congestie a conexiunii C! este
de 15 segmente, iar a conexiunii C2 este de 10 segmente.
a. Care sunt ferestrele lor de congestie dup 2200 msec?
b. n cazul unei execuii lungi aceste dou conexiuni vor avea aceeai
partajare a lrgimii de band al conexiunii congestionate?
c. Spunem c dou conexiuni sunt sincronizate dac ambele conexiuni
ating mrimea maxim i minim a ferestrei n acelai timp. n cazul
unei execuii lungi se sincronizeaz eventual aceste conexiuni? Dac
da, care este mrimea maxim a ferestrelor lor?
d. Va ajuta aceast sincronizare la mbuntirea utilizrii legturii
partajate? De ce? Dai o idee pentru a rupe aceast sincronizare.
a) utemcalculamarimeaferestrelorintimpinurmatorultable.AmbeleCsiCau
aceeasimarimeaaferestreidupa00msec.
C1 C2
Time (msec) Window Size Data sending Window Data sending
(num. of speed (segments Size(num. of speed (segments
segments sent in per second, segments sent in per second,
next 100msec) =Window/0.1) next 100msec) =Window/0.1)
0 15 150 (in [0- 10 100 (in [0-
100]msec] 100]msec)
100 7 70 5 50
200 3 30 2 20
300 1 10 1 10
400 2 20 2 20
500 1 10 1 10
600 2 20 2 20
700 1 10 1 10
800 2 20 2 20
900 1 10 1 10
1000 2 20 2 20
1100 1 10 1 10
1200 2 20 2 20
1300 1 10 1 10
1400 2 20 2 20
1500 1 10 1 10
1600 2 20 2 20
1700 1 10 1 10
1800 2 20 2 20
1900 1 10 1 10
2000 2 20 2 20
2100 1 10 1 10
2200 2 20 2 20
b) Da, asta este datorita algoritmului AIMD din TCP si ambele conexiuni au acelasi
RTT.
 c) Da, asta se vede clar din tabelul de mai sus. Marimea maxima a ferestrelor este
2.
d) Nu, acesta sincronizare nu va ajuta la imbunatatirea utilizarii lunk-ului, aceste 2
conexiuni se comporta ca o singura conexiune oscilaland intre marimea max si
min a ferestrei. Astfel, lunk-ul nu este utilizat la maxim. O cale posibila de oprire a
sincronizarii este adaugarea unui buffer finit link-ului si pierderea aleatorie a
pachetelor din buffer inainte de buffer overflow. Aceasta cauzeaza diferite
conexiuni sa taie din marimea ferestrei in timpuri diferite. Sunt multe AQM (Active
Queue Management) tehnici, precum RED (Random Early Detect), Pi
(Proportional and Integral AQM), AVQ (Adaptive Virtual Queue), si REM
(Random Exponential Marking), etc.
67. P49. Considerai o modificare a algoritmul TCP de control al congestiei. n
loc de creterea prin adunare, s utilizm creterea prin multiplicare. Un
emitor TCP i crete fereastra sa printr-o cantitate pozitiv mic (0< a <l)
ori de cte ori primete o confirmare valid. Gsii relaia funcional ntre
viteza de pierdere L i maximul ferestrei de congestie W. Argumentai de
ce, pentru acest TCP modificat, indiferent de viteza medie a TCP-ului,
conexiunea TCP petrece ntotdeauna aceeai cantitate de timp pentru a
crete mrimea ferestrei de control de la W/2 la W.
De retinut ca W reprezinta marimea maxima a ferestrei.
Pentru inceput putem gasi numarul total de segmente trimise in intervalul cand TCP isi
schimba marimea ferestrei de la W/2 pana la W inclusiv. Asta este data de:
S= W/2 + (W/2)*(1+) + (W/2)*(1+)^2 + (W/2)*(1+)^3 + + (W/2)*(1+)^k
Gasim k= log(1+)2, then S=W*(2+1)/(2).
Rata de pierderi L este data de:
L= 1/S = (2) / (W*(2+1) ).
Timpul ca ii trebuie TCP-ului sa mareasca fereastra de la W/2 la W este dat de:
k*RTT= (log(1+)2) * RTT,
este clar independent de rata medie de transfer TCP.
De retinut rata media de transfer TCP este data de:
B=MSS * S/((k+1)*RTT) = MSS / (L*(k+1)*RTT).
Reinei c acest lucru este diferit de TCP care are un randament mediu:

unde radacina patrata a lui L apare des.

68. P50. n discuia privind viitorul TCP din seciunea 3.7 s-a notat c pentru a
atinge un flux de 10 Gbps, TCP poate doar tolera probabilitatea de pierdere
a unui segment avnd valoarea de 2x10**-10 (sau echivalent, o pierdere la
5.000.000.000 segmente). Artai deviaia de la valoarea 2x10**-10 pentru
valori cuprinse ntre 1 i 5.000.000 pentru valorile RTT i MSS date n
seciunea 3.7. Dac TCP trebuie s suporte o conexiune de 100 Gbps, care
va fi tolerana la pierderi?
SA presupunem ca avem 1500-bytes pachete si 100 ms round-trip time. De la rata

medie de transfer TCP avem ecuatia :

69. P51. n discuia asupra controlului congestiei n TCP din seciunea 3.7, am
presupus implicit c emitorul TCP are ntotdeauna date de transmis.
Considerai acum cazul n care emitorul TCP trimite o cantitate mare de
date dup care ntr n ateptare (idle) la momentul t1. TCP rmne idle
pentru o perioad relativ lung de timp dup care vrea s transmit mai
multe date ncepnd cu t2. Care sunt avantajele i dezavantajele utilizrii
de ctre TCP a valorilor cwnd i ssthresh de la momentul t1 atunci cnd
pornete din nou la momentul t2? Ce alternativ recomandai? De ce?
Un avantaj in utilizarea valorilor CWND si SSTHRESH la t2, TCP-ul nu ar trebui sa
treaca lent prin inceputul lent si evitarea congestiei pana la valoarea de transfer obtinuta
la t1. Un dezavantaj este ca aceste valori nu pot fi precise. In particular, daca calea ar
devenit congestionata intre t1 si t2, expeditorul va trimite o fereastra in valoare de
segmente in calea deja congestionata.
70. P52. n aceast problem se va investiga modul n care UDP i TCP ofer
posibilitatea autentificrii la punctele de capt.
a. Considerai un server DNS care recepioneaz o cerere printr-un
pachet UDP i rspunde la acea cerere cu un pachet UDP ( ca
exemplu, cum face un server DNS). Dac un client cu adresa IP X
imit adresa Y, unde va trimite serverul rspunsul?
b. Presupunei c un server primete un SYN cu Y adresa IP surs, i
dup ce rspunde cu un SYNACK, recepioneaz un ACK cu adresa
surs Y cu numrul de recunoatere corect. Presupunei c serverul
alege un numr de secven iniial aleatoriu i nu exist un man-in-
the-middle , poate serverul fi sigur c clientul este ntr-adevr Y (i
nu este o alt adres X care imit adresa Y)?
a) Serverul va trimite raspuns catre Y.
b) Serverul poate fi sigur c acesta este ntr-adevr la Y. Daca ar fi la o alta adresa
decat (spoofin) Y, SYNACK-ul va fi trimis catre adresa Y, si TCP-ul din
gazda nu va trimite segmentul TCP ACK inapoi. Chiar daca atacatorii vor trimite
un timer TCP ACK corespunzator, nu va sti secventa de numere corecta a
serverului (de cand serverul utilizeaza numere de secventa aleatorii).
71. P53. n aceast problem se va considera ntrzierea introdus de faza
startului lent n TCP. Considerm un client i un server Web conectai
direct pe o conexiune de vitez R. Presupunei c clientul dorete s preia
 un obiect a crui mrime este egal cu exact 15 S, unde S este mrimea
maxim a segmentului (MSS). Notai timpul dus-ntors ntre client i server
cu RTT (se presupune a fi constant). Ignornd header-ele protocolului,
determinai timpul pentru a prelua obiectul (incluznd timpul de stabilire a
conexiunii) cnd:
a. 4 S/R > S/R + RTT > 2S/R
b. S/R + RTT > 4 S/R
c. S/R > RTT.
a) Facand referinta la figura de mai jos vedem intarzierile care sunt:
RTT + RTT + S/R + RTT + S/R + RTT + 12S/R = 4RTT + 14 S/R
b) Intarzieri similar si in acest caz:
RTT+RTT + S/R + RTT + S/R + RTT + S/R + RTT + 8S/R = 5RTT +11 S/R
c) Intarzieri similar si in acest caz:
RTT + RTT + S/R + RTT + 14 S/R = 3 RTT + 15 S/R