1 \chapter{Introduzione alla rete}
4 In questo capitolo sarà fatta un'introduzione ai contetti generali che servono
5 come prerequisiti per capire la programmazione di rete ed esamineremo a grandi
6 linee i protocolli di rete e come questi sono organizzati e interagiscono.
8 In particolare, avendo assunto l'ottica di un'introduzione mirata alla
9 programmazione, ci concentreremo sul protocollo più diffuso che è quello che
10 sta alla base di internet, ed in particolare sulle parti più importanti ai
11 fini della programmazione.
14 \section{Il modello client-server}
15 \label{sec:net_cliserv}.
17 La differenza principale fra un'applicazione di rete e un programma normale è
18 che quest'ultima per definizione concerne la comunicazione fra ``processi''
19 diversi (che in generale non girano neanche sulla stessa macchina). Questo già
20 prefigura un cambiamento completo rispetto all'ottica del ``programma''
21 monolitico all'interno del quale vengono eseguite tutte le istruzioni, e
22 presuppone un sistema operativo ``multitasking'' in grado di eseguire processi
25 Il concetto fondamentale si basa la programmazione di rete sotto Linux (e
26 sotto Unix in generale) è il modello \textit{client-server} in cui un
27 programma di servizio, il \textit{server} riceve un connessione e risponde a
28 un programma di utilizzo, il \textit{client}, provvedendo a quest'ultimo un
29 definito insieme di servizi.
31 Esempi di questo modello sono il WEB, ftp, telnet, ssh e praticamente ogni
32 servizio che viene fornito tramite la rete, ma il modello è utilizzato in
33 generale anche per programmi che non fanno necessariamente uso della rete,
34 come il sistema a finestre.
36 Normalmente si dividono i server in due categorie principali,
37 \textit{concorrenti} e \textit{iterativi}, sulla base del loro comportamento.
39 Un server iterativo risponde alla richiesta inviando i dati e resta occupato
40 (non rispondendo ad ulteriori richieste) fintanto che non ha concluso la
41 richiesta. Una volta completata la richiesta il server diventa di nuovo
44 Un server concorrente al momento di trattare la richiesta crea un processo
45 figlio incaricato di fornire i servizi richiesti, per poi porsi in attesa di
46 ulteriori richieste. In questo modo più richieste possono essere soddisfatte
47 contemporaneamente, una volta che il processo figlio ha concluso il suo lavoro
48 viene terminato, mentre il server originale resta sempre attivo.
51 \subsection{Un primo esempio di client}
52 \label{sec:net_cli_sample}
54 Per evitare di rendere l'esposizione dei concetti generali puramente teorica
55 iniziamo con il mostrare un semplice esempio di client TCP. In \nfig è
56 riportata la sezione principale del codice del nostro client elementare per il
57 servizio \textit{daytime}, un servizio standard che restituisce l'ora locale
58 della macchina a cui si effettua la richesta.
63 #include <sys/types.h> /* predefined types */
64 #include <unistd.h> /* include unix standard library */
65 #include <arpa/inet.h> /* IP addresses conversion utiliites */
66 #include <sys/socket.h> /* socket library */
67 #include <stdio.h> /* include standard I/O library */
69 int main(int argc, char *argv[])
73 struct sockaddr_in serv_add;
77 if ( (sock_fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
78 perror("Socket creation error");
81 /* initialize address */
82 memset((void *) &serv_add, 0, sizeof(serv_add)); /* clear server address */
83 serv_add.sin_family = AF_INET; /* address type is INET */
84 serv_add.sin_port = htons(13); /* daytime post is 13 */
85 /* build address using inet_pton */
86 if ( (inet_pton(AF_INET, argv[optind], &serv_add.sin_addr)) <= 0) {
87 perror("Address creation error");
90 /* extablish connection */
91 if (connect(sock_fd, (struct sockaddr *)&serv_add, sizeof(serv_add)) < 0) {
92 perror("Connection error");
95 /* read daytime from server */
96 while ( (nread = read(sock_fd, buffer, MAXLINE)) > 0) {
98 if (fputs(buffer, stdout) == EOF) { /* write daytime */
99 perror("fputs error");
105 perror("Read error");
112 \caption{Esempio di codice di un semplice client per il servizio daytime.}
113 \label{fig:net_cli_code}
117 Scopo di questo esempio è fornire un primo approccio alla programmazione di
118 rete, per questo motivo non ci dilungheremo nel trattare il significato dei
119 termini o il funzionamento delle varie funzioni utilizzate. Tutto questo sarà
120 esaminato in dettaglio nel seguito, per cui qui ci limiteremo a citarli senza
121 ulteriori spiegazioni.
123 Il listato completo del programma (che comprende il trattamento delle opzioni
124 e una funzione per stampare un messaggio di aiuto) è allegato alla guida nella
125 sezione dei codici sorgente e può essere compilato su una qualunque macchina
128 Il programma anzitutto include gli header necessari (\texttt{\small 1--5});
129 dopo la dichiarazione delle variabili (\texttt{\small 9--12}), si è omessa
130 tutta la parte relativa al trattamento degli argomenti passati dalla linea di
131 comando effettuata con le apposite routines illustrate in
132 \ref{cha:parameter_options}.
134 Il primo passo (\texttt{\small 14--18}è creare un \textit{socket} internet
135 (\texttt{AF\_INET}), di tipo TCP \texttt{SOCK\_STREAM}), la funzione ritorna
136 un descrittore, analogo a quello dei file, che viene usato per identificare il
137 socket in tutte le chiamate successive. Nel caso la chiamata fallisca si
138 stampa un errore con la relativa routine e si esce.
140 Il passo seguente (\texttt{\small 19--27}) è quello di costruire una apposita
141 struttura \texttt{sockaddr\_in} in cui sarà inserito l'indirizzo del server ed
142 il numero della porta del servizio. Il primo passo è inizializzare tutto a
143 zero, poi si setta il tipo di protocollo e la porta (usando la funzione
144 \texttt{htons} per convertire il formato dell'intero a quello usato nella
145 rete), infine si utilizza la funzione \texttt{inet\_pton} per convertire
146 l'indirizzo numerico passato dalla linea di comando.
148 Usando la funzione \texttt{connect} (\texttt{\small 28--32}) si provvede poi a
149 stabilire la connessione con il server. Un valore negativo
151 \subsection{Un primo esempio di server}
152 \label{sec:net_serv_sample}
154 Dopo aver visto il client facciamo vedere adesso anche il corrispettivo
155 server, in questo modo sarà possibile fare delle prove
163 \caption{Esempio di codice di un semplice server per il servizio daytime.}
164 \label{fig:net_serv_code}
169 \section{I protocolli di rete}
170 \label{sec:net_protocols}
172 Parlando di reti di computer si parla in genere di un insieme molto vasto ed
173 eterogeneo di mezzi di comunicazione che vanno dal cavo telefonico, alla fibra
174 ottica, alle comunicazioni via satellite; per rendere possibile la
175 comunicazione attraverso un così variegato insieme di mezzi sono stati
176 adottati una serie di protocolli, il più famoso dei quali, quello alla base
177 del funzionamento di internet, è il cosiddetto TCP/IP.
179 \subsection{Il modello ISO/OSI}
180 \label{sec:net_iso_osi}
182 Una caratteristica comune dei protocolli di rete è il loro essere strutturati
183 in livelli sovrapposti; in questo modo un livello superiore esegue richieste
184 al livello sottostante e da questo riceve responsi, mentre livelli uguali su
185 macchine diverse conversano tramite lo stesso protocollo. Questo modello di
186 funzionamento è stato stato standardizzato dalla \textit{International
187 Standards Organization} (ISO) che ha preparato fin dal 1984 il Modello di
188 Riferimento \textit{Open Systems Interconnection} (OSI), strutturato in sette
189 livelli, secondo la tabella in \ntab.
193 \begin{tabular}{l c c l}
194 \textbf{Livello} & \multicolumn{2}{c}{\textbf{Nome}} & \\
196 Livello 7&\textit{Application} &\textsl{Applicazione}& \\
197 Livello 6&\textit{Presentation} &\textsl{Presentazione}& \\
198 Livello 5&\textit{Session} &\textsl{Sessione}& \\
199 Livello 4&\textit{Transport} &\textsl{Trasporto}& \\
200 Livello 3&\textit{Network} &\textsl{Rete}& \\
201 Livello 2&\textit{DataLink} &\textsl{Collegamento Dati}& \\
202 Livello 1&\textit{Connection} &\textsl{Connessione Fisica}& \\
205 \caption{I sette livelli del protocollo ISO/OSI.}
206 \label{tab:net_osilayers}
209 Il modello ISO/OSI è stato sviluppato corrispondentemente alla definizione
210 della serie di protocolli X.25 per la commutazione di pacchetto. Ma nonostante
211 il lavoro dettagliato di standardizzazione il modello si è rivelato
212 sostanzialmente troppo complesso e poco flessibile rispetto a quello,
213 precedente, su cui si basa TCP/IP che è diventato uno standard de facto;
214 quest'ultimo viene comunemente chiamato modello DoD (\textit{Department of
215 Defense}), dato che fu sviluppato dall'agenzia ARPA per il Dipartimento
216 della Difesa Americano.
218 \subsection{Il modello DoD (TCP/IP)}
219 \label{sec:net_tcpip_overview}
221 Così come ISO/OSI anche TCP/IP è stato strutturato in livelli (riassunti in
222 \ntab); un confronto fra i due è riportato in \nfig dove viene evidenziata
223 anche la corrispondenza fra i rispettivi livelli (che comunque è
224 approssimativa) e su come essi vanno ad inserirsi all'interno del sistema
225 operativo rispetto alla divisione fra user space e kernel space spiegata in
226 \ref{sec:intro_unix_struct}.
230 \begin{tabular}{l c c l}
231 \textbf{Livello} & \multicolumn{2}{c}{\textbf{Nome}} & \textbf{Esempi} \\
233 Livello 1&\textit{Application} &\textsl{Applicazione}&
235 Livello 2&\textit{Transport} &\textsl{Trasporto}& TCP, UDP \\
236 Livello 3&\textit{Network} &\textsl{Rete}& IP, (ICMP, IGMP) \\
237 Livello 4&\textit{Link} &\textsl{Connessione}&
238 device driver \& scheda di interfaccia \\
241 \caption{I quattro livelli del protocollo TPC/IP.}
242 \label{tab:net_layers}
246 Come si può notare TCP/IP è più semplice del modello ISO/OSI e strutturato in
247 soli quattro livelli. Il suo nome deriva dai due principali protocolli che lo
248 compongono, il TCP \textit{Trasmission Control Protocol} e l'IP
249 \textit{Internet Protocol}. Le funzioni dei vari livelli sono le seguenti:
252 \item \textbf{Applicazione} É relativo ai programmi di interfaccia utente, in
253 genere questi vengono realizzati secondo il modello Client-Server (vedi
254 \ref{sec:net_cliserv}.
255 \item \textbf{Trasporto} Fornisce la comunicazione tra le due stazioni
256 terminali su cui girano gli applicativi, regola il flusso delle
257 informazioni, e può fornire un trasporto affidabile, cioè con recupero
258 errori. Il protocollo principale di questo livello è il TCP.
259 \item \textbf{Rete} Si occupa dello smistamento dei singoli pacchetti su una
260 rete complessa e interconnessa, a questo stesso livello operano i protocolli
261 per il reperimento delle informazioni necessarie allo smistamento, per lo
262 scambio di messaggi di controllo e per il monitoraggio della rete. Il
263 protocollo su cui si basa questo livello è IP (sia nella attuale versione,
264 IPv4 che nella nuova IPv6).
265 \item \textbf{Connessione} È responsabile per l'interfacciamento al
266 dispositivo elettronico che effettua la comunicazione fisica, gestendo
267 l'invio e la ricezione dall'hardware dei pacchetti.
271 La comunicazione fra due stazioni avviene pertanto secondo le modalità
274 Le singole applicazioni si scambieranno i dati secondo un loro formato
275 specifico, implementando un protocollo di applicazione (esempi possono essere
276 HTTP, POP, telnet, SMTP, etc).
278 Questi dati vengono inviati al livello di trasporto usando un'interfaccia
279 opportuna (i \textit{socket}, che esamineremo in dettaglio in seguito), i
280 quali li spezzerà in pacchetti di dimensione opportuna e li incapsulerà
281 all'interno del suo protocollo di trasporto aggiungendo ad ogni pacchetto le
282 informazioni necessarie alla gestione di quest'ultimo. Questo processo viene
283 svolto dirattamente nel kernel ad esempio dallo stack TCP nel caso il
284 protocollo di trasporto sia questo.
286 Una volta composto il pacchetto nel formato adatto al protocollo di trasporto
287 usato questo sarà passato al successivo livello, quello del collegamento che
288 si occupa di inserire le opportune informazioni per poter effettuare
289 l'instradamento nella rete ed il recapito alla destinazione finale. In genere
290 questo è il livello di IP (Internet Protocol), a cui vengono inseriti i numeri
291 IP che identificano i computer su internet.
293 L'ultimo passo è il trasferimento del pacchetto al driver della interfaccia di
294 trasmissione che si incarica di incapsularlo nel relativo protocollo di
295 trasmissione fisica usato dall'hardware usato per la comunicazione (ad esempio
296 ethernet per una scheda di rete).
299 \subsection{Criteri generali del design di TCP/IP}
300 \label{sec:net_tcpip_design}
302 La filosofia architetturale di TCP/IP è semplice: costruire una rete che
303 possa sopportare il carico in transito, ma permettere ai singoli nodi di
304 scartare pacchetti se il carico è temporaneamente eccessivo, o se risultano
305 errati o non recapitabili.
307 L'incarico di rendere il recapito pacchetti affidabile non spetta allo livello
308 di collegamento, ma ai livelli superiori. Pertanto il protocollo IP è per sua
309 natura inaffidabile, in quanto non è assicurata né una percentuale di
310 successo né un limite sui tempi di consegna dei pacchetti.
312 È il livello di trasporto che si deve occupare (qualora necessiti) del
313 controllo del flusso dei dati e del recupero degli errori; questo è realizzato
314 dal protocollo TCP. La sede principale di "intelligenza" della rete è pertanto
315 al livello di trasporto o superiore.
317 Infine le singole stazioni collegate alla rete non fungono soltanto da punti
318 terminali di comunicazione, ma possono anche assumere il ruolo di router, per
319 l'interscambio di pacchetti da una rete ad un'altra. Questo rende possibile la
320 flessibilità della rete che è in grado di adattarsi ai mutamenti delle
323 La caratteristica essenziale che rende tutto ciò possibile è la strutturazione
324 a livelli tramite l'incapsulamento. Ogni pacchetto di dati viene incapsulato
325 nel formato del livello successivo, fino al livello della connessione fisica.
326 In questo modo il pacchetto ricevuto ad un livello $n$ dalla stazione di
327 destinazione è esattamente lo stesso spedito dal livello $n$ dalla sorgente.
328 Questo rende facile il progettare il software facendo riferimento unicamente a
329 quanto necessario ad un singolo livello, con la confidenza che questo poi sarà
330 trattato uniformemente da tutti i nodi della rete.
333 \section{Il protocollo TCP/IP}
334 \label{sec:net_tpcip}
336 Come già affermato il protocollo TCP/IP è un insieme di protocolli diversi,
337 che operano su 4 livelli diversi. Per gli interessi della programmazione di
338 rete però sono importanti principalmente i due livelli centrali, e soprattutto
339 quello di trasporto, su cui è innestata l'interfaccia fra kernel space e user
342 Il livello 4 infatti è normalmente gestito dal kernel, e si accede ad esso
343 solo quando si vogliono fare applicazioni di sistema per il controllo della
344 rete (locale) a basso livello, un uso quindi molto specialistico. Il livello 1
345 invece dipende dalle singole applicazioni ed è di nuovo troppo specifico per
346 essere affrontato qui.
348 In questa sezione daremo una breve descrizione dei vari protocolli di TCP/IP,
349 ma ci concentreremo principalmente sul livello di trasposto e in particolare
350 sul protocollo TCP sia per il ruolo centrale che esso svolge nella maggior
351 parte delle applciazioni, sia per la sua complessità che necessita di maggiori
354 \subsection{Il quadro generale}
356 Benché si parli di TCP/IP questa famiglia di protocolli è composta anche da
357 altri membri. In \nfig si è riportato una figura di quadro che mostra un
358 panorama sull'intera famiglia, e di come i vari protocolli vengano usati dalle
361 La figura è da fare ...
363 I vari protocolli mostrati in figura sono i seguenti:
366 \item \textsl{IPv4} \textit{Internet Protocol version 4}. È quello che
367 comunemente si chiama IP. Ha origine negli anni '80 e da allora è la base su
368 cui è cotriuta internet. Usa indirizzi a 32 bit e provvede la trasmissione
369 dei pacchetti TCP, UDP, ICMP e IGMP.
370 \item \textsl{IPv6} \textit{Internet Protocol version 6}. È stato progettato a
371 metà degli anni '90 per rimpiazzare IPv4. Ha indirizzi a 128 bit e effettua
372 lo stesso servizio di trasporto di IPv4 per i pacchetti TCP, UDP e ICPMv6.
373 \item \textsl{TCP} \textit{Trasmission Control Protocol}. È un protocollo
374 orientato alla connessione che provvede un trasporto affidabile e
375 bidirezionale di un flusso di dati. I socket TCP sono esempi di
376 \textit{stream socket}. Il protocollo ha cura di tutti gli aspetti del
377 trasporto, come l'acknoweledgment, i timout, la ritrasmissione, etc. È usato
378 dalla maggior parte delle applicazioni. Può essere usato sia con IPv4 che
380 \item \textsl{UDP} \textit{User Datagram Protocol}. È un protocollo senza
381 connessione a pacchetti. I socket UDP sono esempi di \textit{datagram
382 socket}. Contrariamente al TCP in protocollo non è affidabile e non c'è
383 garanzia che i pacchetti raggiungano la loro destinazione, né sull'eventuale
384 ordine di arrivo. Può essere usato sia con IPv4 che con IPv6.
385 \item \textsl{ICMP} \textit{Internet Control Message Protocol}. Gestisce gli
386 errori e trasporta l'informazione di controllo fra stazioni remote e
387 instradatori (\textit{router} e \textit{host}). I messaggi sono normalmente
388 generati dal software del kernel che gestisce la comunicazione TCP/IP, anche
389 se può venire usato direttamente da alcuni programmi come \texttt{ping}. A
390 volte ci si riferisce ad esso come ICPMv4 per distinguerlo da ICMPv6.
391 \item \textsl{ICMP} \textit{Internet Group Management Protocol}. É un
392 protocollo usato per il \textit{multicasting} (vedi
393 \ref{sec:xxx_multicast}), che è opzionale in IPv4.
394 \item \textsl{ARP} \textit{Address Resolution Protocol}. È il protocollo che
395 mappa un indirizzo IP in un indirizzo hardware (come un indirizzo
396 internet). È usato in reti di tipo broadcast come ethernet, token ring o
397 FDDI ma non serve in connessioni punto-punto.
398 \item \textsl{RARP} \textit{Reverse Address Resolution Protocol}. È il
399 protocollo che mappa un indirizzo hardware in un indirizzo IP. Viene usato a
400 volte per durante il boot per assegnare un indirizzo IP ad una macchina.
401 \item \textsl{ICMPv6} \textit{Internet Control Message Protocol, version 6}.
402 Combina per IPv6 le funzionalità di ICMPv4, IGMP e ARP.
403 \item \textsl{NETLINK} \textit{Netlink}.
404 Provvede l'interfaccia di accesso alla comunicazione a basso livello.
407 Gran parte delle applicazioni comunicano usando TCP o UDP, ed alcune si
408 rifanno ad IP (ed i suoi correlati ICMP e IGMP); benché sia TCP che UDP siano
409 basati su IP e sia possibile intervenire a questo livello con i \textit{raw
410 socket} questa tecnica è molto meno diffusa e a parte applicazioni
411 particolari si preferisce sempre usare i servizi messi a disposizione dai due
412 protocolli precedenti. Per questo motivo a parte alcuni brevi accenni su IP
413 in questa sezione ci concentreremo sul livello di trasporto.
415 \subsection{Internet Protocol (IP)}
418 Quando si parla di IP ci si riferisce in genere alla versione attualmente in
419 uso che è la versione 4 (e viene pertanto chiamato IPv4). Questa versione
420 venne standardizzata nel 1981 dall'RFC~719.
422 Internet protocol nasce per disaccoppiare le applicazioni della struttura
423 hardware delle reti di trasmissione, e creare una interfaccia di trasmissione
424 dei dati indipendente dal sottostante substrato di rete, che può essere
425 realizzato con le tecnologie più disparate (Ethernet, Token Ring, FDDI, etc.).
426 Il compito di IP è pertanto quello di trasmettere i pacchetti da un computer
427 all'altro della rete; le caratteristiche essenziali con cui questo viene
428 realizzato in IPv4 sono due:
431 \item \textit{Universal addressing} la comunicazione avviene fra due host
432 identificati univocamente con un indirizzo a 32 bit che può appartenere ad
433 una sola interfaccia di rete.
434 \item \textit{Best effort} viene assicurato il massimo impegno nella
435 trasmissione, ma non c'è nessuna garanzia per i livelli superiori né sulla
436 percentuale di successo né sul tempo di consegna dei pacchetti di dati.
439 Negli anni '90 la crescita vertiginosa del numero di macchine connesse a
440 internet ha iniziato a far emergere i vari limiti di IPv4, per risolverne i
441 problemi si è perciò definita una nuova versione del protocollo, che (saltando
442 un numero) è diventata la versione 6. IPv6 nasce quindi come evoluzione di
443 IPv4, mantendone inalterate le funzioni che si sono dimostrate valide,
444 eliminando quelle inutili e aggiungendone poche altre per mantenere il
445 protocollo il più snello e veloce possibile.
447 I cambiamenti apportati sono comunque notevoli e si possono essere riassunti a
448 grandi linee nei seguenti punti:
450 \item l'espansione delle capacità di indirizzamento e instradamento, per
451 supportare una gerarchia con più livelli di indirizzamento, un numero di
452 nodi indirizzabili molto maggiore e una autoconfigurazione degli indirizzi
453 \item l'introduzione un nuovo tipo di indirizzamento, l'\textit{anycast} che
454 si aggiungono agli usuali \textit{unycast} e \textit{multicast}
455 \item la semplificazione del formato della testata, eliminando o rendendo
456 opzionali alcuni dei campi di IPv4, per eliminare la necessità di
457 riprocessamento della stessa da parte dei router e contenere l'aumento di
458 dimensione dovuto ai nuovi indirizzi
459 \item un supporto per le opzioni migliorato, per garantire una trasmissione
460 più efficiente del traffico normale, limiti meno stringenti sulle dimensioni
461 delle opzioni, e la flessibilità necessaria per introdurne di nuove in
463 \item il supporto per delle capacità di qualità di servizio (QoS) che permetta
464 di identificare gruppi di dati per i quali si può provvedere un trattamento
465 speciale (in vista dell'uso di internet per applicazioni multimediali e/o
469 Per maggiori dettagli riguardo al protocollo si può consultare
473 \subsection{UDP: User Datagram Protocol)}
476 UDP è un protocollo di trasporto molto semplice, la sua descizione completa è
477 contenuta dell'RFC~768, ma in sostanza esso è una semplice interfaccia a IP dal
478 livello di trasporto. Quando un'applicazione usa UDP essa scrive un pacchetto
479 di dati (il cosiddetto \textit{datagram} che da il nome al protocollo) su un
480 socket, al pacchetto viene aggiunto un header molto semplice (per una
481 descrizione più accurata vedi \ref{sec:appA_udp}), e poi viene passato al
482 livello superiore (IPv4 o IPv6 che sia) che lo spedisce verso la destinazione.
483 Dato che né IPv4 né IPv6 garantiscono l'affidabilità niente assicura che il
484 pacchetto arrivi a destinazione, né che più pacchetti arrivino nello stesso
485 ordine in cui sono stati spediti.
487 Pertanto il problema principale che si affronta quando si usa UDP è la
488 mancanza di affidabilità, se si vuole essere sicuri che i pacchetti arrivino a
489 destinazione occorrerà provvedere con l'applicazione all'interno della quale
490 si dovrà inserire tutto quanto necessario a gestire la notifica di
491 ricevimento, la ritrasmissione, il timeout.
493 Si tenga conto poi che in UDP niente garantisce che i pacchetti arrivino nello
494 stesso ordine in cui sono stati trasmessi, e può anche accadere che i
495 pacchetti vengano duplicati nella trasmissione, e non solo perduti. Di tutto
496 questo di nuovo deve tenere conto l'applicazione.
498 Un'altro aspetto di UDP è che se un pacchetto raggiunge correttamente la
499 destinazione esso viene passato all'applicazione ricevente in tutta la sua
500 lunghezza, la trasmissione avviene perciò per \textit{record} la cui lunghezza
501 viene anche essa trasmessa all'applicazione all'atto del ricevimento.
503 Infine UDP è un protocollo che opera senza connessione
504 (\textit{connectionless}) in quanto non è necessario stabilire nessun tipo di
505 relazione tra origine e destinazione dei pacchetti. Si hanno così situazioni
506 in cui un client può scrivere su uno stesso socket pacchetti destinati a
507 server diversi, o un server ricevere su un socket paccetti provenienti da
508 client diversi. Il modo più semplice di immaginarsi il funzionamento di UDP è
509 quello della radio, in cui si può ``trasmettere a'' e ``ricevere da'' più
510 stazioni usando la stessa frequenza.
512 Nonostante gli evidenti svantaggi comportati dall'inaffidabilità UDP ha il
513 grande pregio della velocità che in certi casi è essenziale; inoltre si presta
514 bene per le applicazioni in cui la connessione non è necessaria e
515 costituirebbe solo un peso di prestazioni mentre una perdita di pacchetti può
516 essere tollerata, come quelle che usano il multicasting.
518 \subsection{TCP: Transport Control Protocol)}
521 Il TCP è un protocollo molto complesso, definito nell'RFC~739 e completamente
522 diverso da UDP; alla base del suo design infatti non stanno semplicità e
523 velocità, ma la ricerca della massima affidabilità possibile nella
524 trasmissione dei dati.
526 La prima differenza con UDP è che TCP provvede sempre una conessione diretta
527 fra un client e un server, attraverso la quale essi possono comunicare; per
528 questo il paragone più appropriato per questo protocollo è quello del
529 collegamento telefonico, in quanto prima viene stabilita una connessione fra
530 due stazioni su cui poi viene effettuata una comunicazione diretta.
532 Caratteristica fondamentale di TCP è l'affidabilità; quando i dati vengono
533 inviati attraverso una connessione ne viene richiesto un ``ricevuto''
534 (il cosiddetto \textit{acknowlegment}), se questo non arriva essi verranno
535 ritrasmessi facendo un determinato numero di tentativi intervallati da un
536 periodo di tempo crescente, fintanto che la connessione sarà considerata
537 fallita o caduta la connessione (con un errore di \textit{time-out}), dopo un
538 periodo di tempo che dipende dall'implementazione e che può variare far i
539 quattro e i dieci minuti.
541 Inoltre per tenere conto delle diverse condizioni in cui può trovarsi la linea
542 di comunicazione TCP comprende anche un algoritmo di calcolo dinamico del
543 tempo di andata e ritorno dei pacchetti (il cosiddetto RTT,
544 \textit{round-trip time}) fra un client e un server che lo rende in grado di
545 adattarsi alle condizioni della rete per non generare inutili ritrasmissioni o
546 cadere facilmente in timeout.
548 Inoltre TCP è in grado di preservare l'ordine dei dati assegnando un numero di
549 sequenza ad ogni byte che trasmette. Ad esempio se un'applicazione scrive 3000
550 bytes su un socket TCP, questi potranno essere spezzati dal protocollo in due
551 segmenti (le unità di dati passate da TCP a IP vengono chiamate
552 \textit{segment}) di 1500 bytes, di cui il primo conterrà il numero di
553 sequenza $1-1500$ e il secondo il numero $1501-3000$. In questo modo anche se
554 i segmenti arrivano a destinazione in un ordine diverso, o se alcuni arrivano
555 più volte a causa di ritrasmissioni dovute alla perdita dei ricevuto,
556 all'arrivo sarà comunque possibile riordinare i dati e scartare i duplicati.
558 Il protocollo provvede anche un controllo di flusso (\textit{flow control}),
559 cioè specifica sempre all'altro capo della trasmissione quanti dati può
560 ricevere tramite una \textit{advertised window} (letteralmente finestra
561 annunciata), che indica lo spazio disponibile nel buffer di ricezione,
562 cosicchè nella trasmissione non vengano inviati più dati di quelli che possono
565 Questa finestra cambia dinamicamente diminuendo con la ricezione dei dati dal
566 socket ed aumentando con la lettura di quest'ultimo da parte
567 dell'applicazione, se diventa nulla il buffer di ricezione è pieno e non
568 verranno accettati altri dati. Si noti che UDP non provvede niente di tutto
569 ciò per cui nulla impedisce che vengano trasmessi pacchetti ad un rate che il
570 ricevitore non può sostenere.
572 Infine attraverso TCP la trasmissione è sempre bidirezionale (in inglese
573 \textit{full-duplex}), è cioè possibile sia trasmettere che ricevere allo
574 stesso tempo, il che poi comporta che quanto dicevamo a proposito del
575 controllo di flusso e della gestione della sequenzialità dei dati viene
576 effettuato per entrambe le direzioni di comunicazione.
580 \subsection{Creazione e terminazione della connessione TCP}
582 Per capire il funzionamento delle funzioni della interfaccia dei socket che
583 operano con TCP (come \texttt{connect}, \texttt{accept} e \texttt{close} che
584 vedremo più avanti) è fodamentale capire come funziona la creazione e la
585 conclusione di una connessione TCP.
590 \subsection{Le porte}