src/SUMMARY.md

@@ -5,8 +5,11 @@
 # Cursuri
 ----
 - [ Introducere](curs1/curs.md)
+- [ Nivelul Fizic](curs2/curs.md)
 - [ DataLink ](curs3/Cursul3_Serb_Razvan_Gabriel.md)
 - [ Detecția și corectarea erorilor](curs4/curs.md)
+- [ Protocolul UDP. Nivelul Transport](curs7/curs.md)
+- [ Protocolul TCP](curs9/curs.md)
 - [ Congestion Control](curs11/curs.md)
 - [ World Wide Web](curs12/Cursul12_Serb_Razvan_Gabriel.md)
 - [ Domain Name System (DNS)](curs13/Cursul13_Tunaru_Stefania_Emilia.md)

src/curs2/curs.md

 # 2. Legătura de date. Servicii şi funcţii. Detecţia şi corectarea erorilor (checksum). Controlul transmisiei.
 
+### Nivelul Fizic
+
+Orice _rețea_ implică existența unei **conexiuni** stabilite între entitățile aflate la capetele canalului de comunicare (_sender_ & _receiver_); această conexiune facilitează transmisia datelor, fiind implementată (low-level) printr-o serie de medii fizice, cu proprietăți distincte:
+
+1. **Mediu electric** (*e.g.* Ethernet)
+
+   - se folosesc cabluri ce conțin perechi de fire electrice
+
+   - biții mesajului sunt encodați/reprezentați **cu ajutorul variației de tensiune prin cele două fire** (la capătul dinspre *sender* se amplasează un senzor ce măsoară diferența de potențial dintre cele două fire)
+
+   - se stabilește o corespondență (**mapare**) între biți și tensiunea asociată acestora (*e.g.* 1 $\rightarrow$ 5V; 0 $\rightarrow$ 0V)
+
+     <img src="./time-seq.png" alt="image-20240308190244288" style="zoom:67%;" />
+
+   _**Obs:**_ Firele electrice sunt folosite, în general,
+
+   - **pe distanțe scurte, cu viteze mari de transmisie**
+
+   - **pe distanțe lungi, cu viteze scăzute**
+
+     
+
+2. **Fibră optică**
+
+   - constituită dintr-o bucată subțire de plexiglas, înconjurată de un material cu indice de refracție mare
+   - mesajul este transmis prin intermediul unui semnal laser, ce se refractă de-a lungul fibrei până la destinație
+   - encodarea mesajului poate fi realizată în diverse moduri (*e.g.* variând lungimea de undă a laserului)
+   - acest mediu prezintă o utilizare generalizată
+
+
+
+3. **Unde electromagnetice**
+   - se folosește o antenă ce generează un semnal variat prin inducție electromagnetică
+   - encodarea este realizată prin variația fazei sau a frecvenței semnalului
+   - receptorul trebuie să reconstituie mesajul transmis
+
+
+
+Indiferent de tipul mediului fizic, apare necesitatea unei înțelegeri privind frecvența de transmisie a informației (**$\Rightarrow$​** **introducerea protocoalelor**).
+
+>  **Bandwidth** = viteza de transmisie a unui link [bits / sec]
+
+---
+
+***Problemă***:
+
+​	*Transmisia informațiilor între două entități implică existența unor semnale de ceas **sincronizate***.
+
+​	Desincronizarea acestora din urmă (**clock slip**) poate conduce la apariția unor biți în plus/minus față de codificarea mesajului inițial.
+
+***Soluții***:
+
+1. Folosirea ceasurilor atomice (scumpe).
+
+2. Utilizarea unei perechi de fire pentru transmisia datelor, respectiv a unei alteia pentru semnalul de ceas. Citirea mesajului începe odată cu detectarea acestuia din urmă.
+
+3. **Encodare Manchester** - semnalul de ceas este încorporat în semnalul util, simbolurile fiind encodate prin **tranziții**.
+
+   - utilizată în cadrul Ethernet
+
+   - $\uparrow \iff 1 ; \\\downarrow \iff 0;$
+
+     
+
+---
+
+Rețelele sunt construite printr-un layering de niveluri; fiecare dintre acestea implementează noi funcționalități pornind de la interfața oferită de nivelul inferior.
+
+*Obs:* Nivelurile de rețea se doresc a fi generice, oferind un protocol independent de cele subiacente și ușor de introdus în orice sistem.
+
+<img src="./phy-transmission.png" alt="image-20240308220100927" style="zoom:67%;" />
+
+### Nivelul DataLink
+
+- se ocupă de *framing* = încadrarea mesajului prin introducerea unor octeți speciali (flag) ce specifică începutul și sfârșitul acestuia $\Rightarrow$ **FLAG | MESAJ | FLAG**
+
+  - FLAG = 01111110
+
+  - pentru a acoperi cazul în care flag-ul este inclus în mesaj, nivelul fizic implementează protocolul de **bit stuffing** $\iff$ pentru mesajul 01111110, va fi trimis șirul 011111010.
+
+  - nivelul fizic al receptorului va elimina bitul de 0 suplimentar
+
+  - *vezi* **HDLC** = high-level datalink control
+
+   <img src="./time-seq-2.png" alt="image-20240308220100927" style="zoom:67%;" />
+
+
+  **API Datalink:**
+
+  ​	send(char buf[SIZE], int len)
+
+  ​	$\downarrow$
+
+  ​	recv(char buf[SIZE], int len)
+
+   
+
 Resurse:
 * https://www.computer-networking.info/2nd/html/principles/reliability.html
 * https://www.youtube.com/playlist?list=PLowKtXNTBypH19whXTVoG3oKSuOcw_XeW primele 6 clipuri.

src/curs7/curs.md

+# Cursul 7 - Protocolul UDP. Nivelul Transport
+
+<p align="center">
+<img src="./schema-udp.png" alt="image-20240308190244288" style="zoom:67%;" />
+</p>
+
+Nivelul Rețea prezintă următoarele neajunsuri:
+
+- **nu** garantează transmiterea datelor
+- **nu** poate detecta erori de transmisie
+- **nu** păstrează ordinea de transmisie a pachetelor
+
+Protocoalele de *nivel Transport* își propun remedierea acestor puncte slabe: implementarea lor individualizează procesele locale și ramifică transmisia informației de la host la host prin introducerea **porturilor**.
+
+Fiecare proces poate fi identificat printr-un **port unic**, asociat socket-ului deschis de către acesta din urmă. Astfel, este soluționată problema *partajării concurente a resurselor de rețea* (un proces **nu** așteaptă încheierea comunicației inițiate de către alte procese).
+
+*Obs:* ID-ul unui port este reprezentat pe *2 octeți*. Totodată, există porturi rezervate anumitor protocoale și servicii de sistem (ID-uri alocate între 0-1024).
+
+---
+
+### Protocolul UDP
+
+- cel mai simplu protocol de transport
+- oferă light-checking pentru erori
+- **<u>nu</u> stabilește o conexiune client-server!**
+  - se trimit direct datagrame
+  - idee utilă atunci când nu este necesar / este prea costisitor să păstrăm o conexiune activă între entități
+
+- **nu** se garantează ordinea/corectitudinea pachetelor trimise (nu există a astfel de etapă de verificare)
+- prezintă overhead **mic** **$\Rightarrow$** ieftin de implementat, dar *nesigur*
+  - *ex:* Header UDP - 8 bytes ***VS*** Header TCP - 20 bytes
+- implementat de către Kernel-ul de Linux prin intermediul **Socket API**-ului; Network-Stack-ul devine responsabil de parsarea datagramelor UDP
+
+<p align="center">
+<img src="./udp-header.png" alt="image-20240308190244288" style="zoom:67%;" />
+</p>
+
+
+Schiță a implementării unui *protocol de nivel Transport din Kernel* (pseudocod):
+
+```c++
+vector <int> sockets;
+pair <int, int> ports(socket, port);
+
+// (1)
+int create_unique_id() {
+    int new_id = sockets[sockets.size() - 1] + 1;
+    
+    sockets.push(new_id);
+    
+    return new_id;
+}
+
+// (2)
+void bind(int socket, int port) {
+    ports.push((socket, port));
+}
+
+// (3)
+void send(int socket, void *data, ... dest) {
+    UDP_packet pkt;
+    
+    pkt.data = data;
+    pkt.port_dst = dest.port;
+    pkt.port_src = ...;	// random source port!
+    
+    send_ip(pkg, dest.ip);
+}
+
+// (4)
+int recv(int socket) {
+    pkt = packets.pop(port);
+    UDP_packet p = (UDP_packet) pkt;
+    
+    verify_checksum(pkt);
+    
+    return p.data;
+}
+```
+
+
+
+*Concluzii UDP:*
+
+- avantajos datorită vitezei
+
+- complexitate redusă & cost scăzut de implementare
+
+- pe baza lui se pot dezvolta alte protocoale
+
+  
+
+### Îmbunătățiri posibile
+
+**1)** **Stop-and-Wait**
+
+- se adaugă următoarele câmpuri la header-ul pachetelor: *sequence_number*, *type* (fiecare pe câte 2 octeți)
+- sender-ul trimite o datagramă UDP, așteaptă confirmarea receiver-ului printr-un pachet ACK, apoi trimite următoarea datagramă ș.a.m.d.
+- în cazul în care se pierde un pachet ACK, sender-ul așteaptă un interval de timp, după care retrimite pachetul inițial
+- *dezavantaj:* protocolul este unul **lent**
+
+**2) Select-and-Go**
+
+- folosește fereastra glisantă
+- se trimite un număr de datagrame egal cu dimensiunea ferestrei (fiecare pachet va avea un seq_number asociat)
+- pentru fiecare datagramă se așteaptă un ACK de confirmare cu seq_number-ul corespunzător
+- dacă se pierde un pachet, ACK-urile primite vor avea seq_number-ul pachetului precedent; pachetul pierdut va fi retrimis, iar fereastra glisantă se va deplasa mai departe
\ No newline at end of file

src/curs9/curs.md

+# Cursul 9 - Protocolul TCP
+
+TCP = *Transmission Control Protocol*
+
+<p align="center">
+<img src="./tcp-1.png" alt="image-20240308190244288" style="zoom:67%;" />
+</p>
+
+Obiective ale protocolului TCP:
+
+- transmisie sigură, în ordine
+
+- trimiterea pachetelor *o singură dată*
+
+- format = șir de octeți (protocolul nu mai e orientat pe pachete)
+
+  - **recv()** poate primi doar o parte din octeți, caz în care se repetă operația
+
+- congestion-control
+
+- demultiplexare
+
+  
+
+***În comparație cu UDP...***
+
+- *nu se garantează ordinea sau siguranța transmisiei*
+- *format = datagrame* (totul sau nimic)
+- *demultiplexare*
+
+
+
+### Paralelă - Socket APIs
+
+<p align="center">
+<img src="./udp1.png" alt="image-20240308190244288" style="zoom:67%;" />
+</p>
+
+
+<p align="center">
+<img src="./tcp4.png" alt="image-20240308190244288" style="zoom:67%;" />
+</p>
+
+---
+
+### Stabilirea conexiunii TCP
+
+*Obs:* Conexiunea TCP este **bidirecțională** și se bazează pe **sincronizarea numerelor de secvență**.
+
+
+<p align="center">
+<img src="./twh.png" alt="image-20240308190244288" style="zoom:67%;" />
+</p>
+
+*Schiță a procesului de comunicație:*
+
+- **a) stabilirea conexiunii**
+
+  
+<p align="center">
+<img src="./tcp2.png" alt="image-20240308190244288" style="zoom:67%;" />
+</p>
+
+
+
+- **b) transmisia pachetelor**
+
+  
+<p align="center">
+<img src="./tcp3.png" alt="image-20240308190244288" style="zoom:67%;" />
+</p>
+
+Tipuri diferite de pachete ACK:
+
+- ACK cumulativ $\rightarrow$ garantează siguranța primirii (*reliability*)
+- SACK (selective ACK)
\ No newline at end of file