1 \chapter{Introduzione alla programmazione di rete}
4 In questo capitolo sarà fatta un'introduzione ai contetti generali che servono
5 come prerequisiti per capire la programmazione di rete, partiremo con due
6 semplici esempi per poi passare ad un esame a grandi linee dei protocolli di
7 rete e di come questi sono organizzati e interagiscono.
9 In particolare, avendo assunto l'ottica di un'introduzione mirata alla
10 programmazione, ci concentreremo sul protocollo più diffuso, TCP/IP, che è
11 quello che sta alla base di internet, ed in particolare prenderemo in esame in
12 questa introduzione i concetti più importanti da conoscere ai fini della
15 \section{Il modello client-server}
16 \label{sec:net_cliserv}
18 La differenza principale fra un'applicazione di rete e un programma normale è
19 che quest'ultima per definizione concerne la comunicazione fra ``processi''
20 diversi (che in generale non girano neanche sulla stessa macchina). Questo già
21 prefigura un cambiamento completo rispetto all'ottica del ``programma''
22 monolitico all'interno del quale vengono eseguite tutte le istruzioni, e
23 presuppone un sistema operativo ``multitasking'' in grado di eseguire processi
26 Il concetto fondamentale si basa la programmazione di rete sotto Linux (e
27 sotto Unix in generale) è il modello \textit{client-server} in cui un
28 programma di servizio, il \textit{server} riceve un connessione e risponde a
29 un programma di utilizzo, il \textit{client}, provvedendo a quest'ultimo un
30 definito insieme di servizi.
32 Esempi di questo modello sono il WEB, ftp, telnet, ssh e praticamente ogni
33 servizio che viene fornito tramite la rete, ma il modello è utilizzato in
34 generale anche per programmi che non fanno necessariamente uso della rete,
35 come il sistema a finestre.
37 Normalmente si dividono i server in due categorie principali, e vengono detti
38 \textit{concorrenti} o \textit{iterativi}, sulla base del loro comportamento.
40 Un server iterativo risponde alla richiesta inviando i dati e resta occupato
41 (non rispondendo ad ulteriori richieste) fintanto che non ha concluso la
42 richiesta. Una volta completata la richiesta il server diventa di nuovo
45 Un server concorrente al momento di trattare la richiesta crea un processo
46 figlio incaricato di fornire i servizi richiesti, per poi porsi in attesa di
47 ulteriori richieste. In questo modo più richieste possono essere soddisfatte
48 contemporaneamente; una volta che il processo figlio ha concluso il suo lavoro
49 viene terminato, mentre il server originale resta sempre attivo.
52 \subsection{Un primo esempio di client}
53 \label{sec:net_cli_sample}
55 Per evitare di rendere l'esposizione dei concetti generali sulla rete
56 puramente teorica iniziamo con il mostrare un semplice esempio di client TCP.
57 In \nfig\ è riportata la sezione principale del codice del nostro client
58 elementare per il servizio \textit{daytime}, un servizio standard che
59 restituisce l'ora locale della macchina a cui si effettua la richesta.
64 #include <sys/types.h> /* predefined types */
65 #include <unistd.h> /* include unix standard library */
66 #include <arpa/inet.h> /* IP addresses conversion utiliites */
67 #include <sys/socket.h> /* socket library */
68 #include <stdio.h> /* include standard I/O library */
70 int main(int argc, char *argv[])
74 struct sockaddr_in serv_add;
78 if ( (sock_fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
79 perror("Socket creation error");
82 /* initialize address */
83 memset((void *) &serv_add, 0, sizeof(serv_add)); /* clear server address */
84 serv_add.sin_family = AF_INET; /* address type is INET */
85 serv_add.sin_port = htons(13); /* daytime post is 13 */
86 /* build address using inet_pton */
87 if ( (inet_pton(AF_INET, argv[optind], &serv_add.sin_addr)) <= 0) {
88 perror("Address creation error");
91 /* extablish connection */
92 if (connect(sock_fd, (struct sockaddr *)&serv_add, sizeof(serv_add)) < 0) {
93 perror("Connection error");
96 /* read daytime from server */
97 while ( (nread = read(sock_fd, buffer, MAXLINE)) > 0) {
99 if (fputs(buffer, stdout) == EOF) { /* write daytime */
100 perror("fputs error");
106 perror("Read error");
113 \caption{Esempio di codice di un client elementare per il servizio daytime.}
114 \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 nello spiegare 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
123 Il sorgente completo del programma (\texttt{SimpleDaytimeTCPClient.c}, che
124 comprende il trattamento delle opzioni e una funzione per stampare un
125 messaggio di aiuto) è allegato alla guida nella sezione dei codici sorgente e
126 può essere compilato su una qualunque macchina linux.
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} IPv4
135 (\texttt{AF\_INET}), di tipo TCP \texttt{SOCK\_STREAM} (in sostanza un canale
136 di comunicazione attraverso internet, questi termini verranno spiegati con
137 precisione più avanti). La funzione \texttt{socket} ritorna un descrittore,
138 analogo a quello dei file, che viene usato per identificare il socket in tutte
139 le chiamate successive. Nel caso la chiamata fallisca si stampa un errore con
140 la relativa routine e si esce.
142 Il passo seguente (\texttt{\small 19--27}) è quello di costruire una apposita
143 struttura \texttt{sockaddr\_in} in cui sarà inserito l'indirizzo del server ed
144 il numero della porta del servizio. Il primo passo è inizializzare tutto a
145 zero, per poi inserire il tipo di protocollo e la porta (usando per
146 quest'ultima la funzione \texttt{htons} per convertire il formato dell'intero
147 usato dal computer a quello usato nella rete), infine si utilizza la funzione
148 \texttt{inet\_pton} per convertire l'indirizzo numerico passato dalla linea di
151 Usando la funzione \texttt{connect} sul socket creato in precedenza
152 (\texttt{\small 28--32}) si provvede poi a stabilire la connessione con il
153 server specificato dall'indirizzo immesso nella struttura possata come secondo
154 argomento, il terzo argomento è la dimensione di detta struttura. Dato che
155 esistono diversi tipi di socket, si è dovuto effettuare un cast della
156 struttura inizializzata in precedenza, che è specifica per i socket IPv4. Un
157 valore di ritorno negativo implica il fallimento della connessione.
159 Completata con successo la connessione il passo successivo (\texttt{\small
160 34--40}) è leggere la data dal socket; il server invierà sempre una stringa
161 di 26 caratteri della forma \verb|Wed Apr 4 00:53:00 2001\r\n|, che viene
162 letta dalla funzione \texttt{read} e scritta su \texttt{stdout}.
164 Dato il funzionamento di TCP la risposta potrà tornare in un unico pacchetto
165 di 26 byte (come avverrà senz'altro nel caso in questione) ma potrebbe anche
166 arrivare in 26 pacchetti di un byte. Per questo nel caso generale non si può
167 mai assumere che tutti i dati arrivino con una singola lettura, pertanto
168 quest'ultima deve essere effettuata in un loop in cui si continui a leggere
169 fintanto che la funzione \texttt{read} non ritorni uno zero (che significa che
170 l'altro capo ha chiuso la connessione) o un numero minore di zero (che
171 significa un errore nella connessione).
173 Si noti come in questo caso la fine dei dati sia specificata dal server che
174 chiude la connessione; questa è una delle tecniche possibili (è quella usata
175 pure dal protocollo HTTP), ma ce ne possono essere altre, ad esempio FTP marca
176 la conclusione di un blocco di dati con la sequenza ASCII \verb|\r\n|
177 (carriage return e line feed), mentre il DNS mette la lunghezza in testa ad
178 ogni blocco che trasmette. Il punto essenziale è che TCP non provvede nessuna
179 indicazione che permetta di marcare dei blocchi di dati, per cui se questo è
180 necessario deve provvedere il programma stesso.
182 \subsection{Un primo esempio di server}
183 \label{sec:net_serv_sample}
185 Dopo aver illustrato il client daremo anche un esempio di un server
186 elementare, in grado di rispondere al precedente client. Il listato è
187 nuovamente mostrato in \nfig, il sorgente completo
188 (\texttt{SimpleDaytimeTCPServer.c}) è allegato insieme agli altri file nella
189 directory \texttt{sources}.
191 \begin{figure}[!htbp]
194 #include <sys/types.h> /* predefined types */
195 #include <unistd.h> /* include unix standard library */
196 #include <arpa/inet.h> /* IP addresses conversion utiliites */
197 #include <sys/socket.h> /* socket library */
198 #include <stdio.h> /* include standard I/O library */
202 int main(int argc, char *argv[])
205 * Variables definition
207 int list_fd, conn_fd;
209 struct sockaddr_in serv_add;
210 char buffer[MAXLINE];
216 if ( (list_fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
217 perror("Socket creation error");
220 /* initialize address */
221 memset((void *)&serv_add, 0, sizeof(serv_add)); /* clear server address */
222 serv_add.sin_family = AF_INET; /* address type is INET */
223 serv_add.sin_port = htons(13); /* daytime port is 13 */
224 serv_add.sin_addr.s_addr = htonl(INADDR_ANY); /* connect from anywhere */
226 if (bind(list_fd, (struct sockaddr *)&serv_add, sizeof(serv_add)) < 0) {
227 perror("bind error");
230 /* listen on socket */
231 if (listen(list_fd, BACKLOG) < 0 ) {
232 perror("listen error");
235 /* write daytime to client */
237 if ( (conn_fd = accept(list_fd, (struct sockaddr *) NULL, NULL)) <0 ) {
238 perror("accept error");
241 timeval = time(NULL);
242 snprintf(buffer, sizeof(buffer), "%.24s\r\n", ctime(&timeval));
243 if ( (write(conn_fd, buffer, strlen(buffer))) < 0 ) {
244 perror("write error");
253 \caption{Esempio di codice di un semplice server per il servizio daytime.}
254 \label{fig:net_serv_code}
257 Come per il client si includono gli header necessari a cui è aggiunto quello
258 per trattare i tempi, e si definiscono alcune costanti e le variabili
259 necessarie in seguito (\texttt{\small 1--18}), come nel caso precedente si
260 sono omesse le parti relative al trattamento delle opzioni da riga di comando.
262 La creazione del socket (\texttt{\small 22--26}) è analoga al caso precedente,
263 come pure l'inizializzazione della struttura \texttt{sockaddr\_in}, anche in
264 questo caso si usa la porta standard del servizio daytime, ma come indirizzo
265 IP si il valore predefinito \texttt{INET\_ANY} che corrisponde ad un indirizzo
266 generico (\texttt{\small 27--31}).
268 Si effettua poi (\texttt{\small 32--36}) la chiamata alla funzione
269 \texttt{bind} che permette di associare la precedente struttura al socket, in
270 modo che quest'ultimo possa essere usato per accettare connessioni su una
271 qualunque delle interfacce di rete locali.
273 Il passo successivo (\texttt{\small 37--41}) è mettere ``in ascolto'' il
274 socket, questo viene effettuato con la funzione \texttt{listen} che dice al
275 kernel di accettare connessioni per il socket specificato, la funzione indica
276 inoltre, con il secondo parametro, il numero massimo di connessioni che il
277 kernel accetterà di mettere in coda per il suddetto socket.
279 Questa ultima chiamata completa la preparazione del socket per l'ascolto (che
280 viene chiamato anche \textit{listening descriptor}) a questo punto il processo
281 è mandato in sleep (\texttt{\small 44--47}) con la successiva chiamata alla
282 funzione \texttt{accept}, fin quando non arriva e viene accettata una
283 connessione da un client.
285 Quando questo avviene \texttt{accept} ritorna un secondo descrittore di
286 socket, che viene chiamato \textit{connected descriptor} che è quello che
287 viene usato dalla successiva chiamata alla \texttt{write} per scrivere la
288 risposta al client, una volta che si è opportunamente (\texttt{\small 48--49})
289 costruita la stringa con la data da trasmettere. Completata la trasmissione il
290 nuovo socket viene chiuso (\texttt{\small 54}).
291 Il tutto è inserito in un loop infinito (\texttt{\small 42--55}) in modo da
292 poter ripetere l'invio della data ad una successiva connessione.
294 È impostante notare che questo server è estremamente elementare, infatti a
295 parte il fatto di essere dipendente da IPv4, esso è in grado di servire solo
296 un client alla volta, è cioè un \textsl{server iterativo}, inoltre esso è
297 scritto per essere lanciato da linea di comando, se lo si volesse utilizzare
298 come demone di sistema (che è in esecuzione anche quando non c'è nessuna shell
299 attiva e il terminale da cui lo si è lanciato è stato sconnesso),
300 occorrerebbero delle opportune modifiche.
302 \section{I protocolli di rete}
303 \label{sec:net_protocols}
305 Visto un primo esempio di programmazione, passiamo ora ad una introduzione più
306 dettagliata del funzionamento delle reti e dei relativi protocolli.
308 Parlando di reti di computer si parla in genere di un insieme molto vasto ed
309 eterogeneo di mezzi di comunicazione che vanno dal cavo telefonico, alla fibra
310 ottica, alle comunicazioni via satellite; per rendere possibile la
311 comunicazione attraverso un così variegato insieme di mezzi sono stati
312 adottati una serie di protocolli, il più famoso dei quali, quello alla base
313 del funzionamento di internet, è il protocollo TCP/IP.
315 \subsection{Il modello ISO/OSI}
316 \label{sec:net_iso_osi}
318 Una caratteristica comune dei protocolli di rete è il loro essere strutturati
319 in livelli sovrapposti; in questo modo un livello superiore esegue richieste
320 al livello sottostante e da questo riceve responsi, mentre livelli uguali su
321 macchine diverse conversano tramite lo stesso protocollo. Questo modello di
322 funzionamento è stato stato standardizzato dalla \textit{International
323 Standards Organization} (ISO) che ha preparato fin dal 1984 il Modello di
324 Riferimento \textit{Open Systems Interconnection} (OSI), strutturato in sette
325 livelli, secondo la tabella in \ntab.
329 \begin{tabular}{l c c l}
330 \textbf{Livello} & \multicolumn{2}{c}{\textbf{Nome}} & \\
332 Livello 7&\textit{Application} &\textsl{Applicazione}& \\
333 Livello 6&\textit{Presentation} &\textsl{Presentazione}& \\
334 Livello 5&\textit{Session} &\textsl{Sessione}& \\
335 Livello 4&\textit{Transport} &\textsl{Trasporto}& \\
336 Livello 3&\textit{Network} &\textsl{Rete}& \\
337 Livello 2&\textit{DataLink} &\textsl{Collegamento Dati}& \\
338 Livello 1&\textit{Connection} &\textsl{Connessione Fisica}& \\
341 \caption{I sette livelli del protocollo ISO/OSI.}
342 \label{tab:net_osilayers}
345 Il modello ISO/OSI è stato sviluppato corrispondentemente alla definizione
346 della serie di protocolli X.25 per la commutazione di pacchetto. Ma nonostante
347 il lavoro dettagliato di standardizzazione il modello si è rivelato
348 sostanzialmente troppo complesso e poco flessibile rispetto a quello,
349 precedente, su cui si basa TCP/IP che è diventato uno standard de facto;
350 quest'ultimo viene comunemente chiamato modello DoD (\textit{Department of
351 Defense}), dato che fu sviluppato dall'agenzia ARPA per il Dipartimento
352 della Difesa Americano.
355 \begin{figure}[!htbp]
358 \caption{Struttura a livelli dei protocolli OSi e TCP/IP, con la
359 relative corrispondeze e la divisione fra kernel e user space.}
360 \label{fig:net_osi_tcpip_comp}
365 \subsection{Il modello DoD (TCP/IP)}
366 \label{sec:net_tcpip_overview}
368 Così come ISO/OSI anche TCP/IP è stato strutturato in livelli (riassunti in
369 \ntab); un confronto fra i due è riportato in \curfig\ dove viene evidenziata
370 anche la corrispondenza fra i rispettivi livelli (che comunque è
371 approssimativa) e su come essi vanno ad inserirsi all'interno del sistema
372 operativo rispetto alla divisione fra user space e kernel space spiegata in
373 \ref{sec:intro_unix_struct}.
377 \begin{tabular}{l c c l}
378 \textbf{Livello} & \multicolumn{2}{c}{\textbf{Nome}} & \textbf{Esempi} \\
380 Livello 1&\textit{Application} &\textsl{Applicazione}&
382 Livello 2&\textit{Transport} &\textsl{Trasporto}& TCP, UDP \\
383 Livello 3&\textit{Network} &\textsl{Rete}& IP, (ICMP, IGMP) \\
384 Livello 4&\textit{Link} &\textsl{Connessione}&
385 device driver \& scheda di interfaccia \\
388 \caption{I quattro livelli del protocollo TPC/IP.}
389 \label{tab:net_layers}
393 Come si può notare TCP/IP è più semplice del modello ISO/OSI e strutturato in
394 soli quattro livelli. Il suo nome deriva dai due principali protocolli che lo
395 compongono, il TCP \textit{Trasmission Control Protocol} e l'IP
396 \textit{Internet Protocol}. Le funzioni dei vari livelli sono le seguenti:
399 \item \textbf{Applicazione} É relativo ai programmi di interfaccia utente, in
400 genere questi vengono realizzati secondo il modello Client-Server (vedi
401 \ref{sec:net_cliserv}.
402 \item \textbf{Trasporto} Fornisce la comunicazione tra le due stazioni
403 terminali su cui girano gli applicativi, regola il flusso delle
404 informazioni, e può fornire un trasporto affidabile, cioè con recupero
405 errori. Il protocollo principale di questo livello è il TCP.
406 \item \textbf{Rete} Si occupa dello smistamento dei singoli pacchetti su una
407 rete complessa e interconnessa, a questo stesso livello operano i protocolli
408 per il reperimento delle informazioni necessarie allo smistamento, per lo
409 scambio di messaggi di controllo e per il monitoraggio della rete. Il
410 protocollo su cui si basa questo livello è IP (sia nella attuale versione,
411 IPv4 che nella nuova IPv6).
412 \item \textbf{Connessione} È responsabile per l'interfacciamento al
413 dispositivo elettronico che effettua la comunicazione fisica, gestendo
414 l'invio e la ricezione dall'hardware dei pacchetti.
418 La comunicazione fra due stazioni avviene pertanto secondo le modalità
422 \begin{figure}[!htbp]
425 \caption{Strutturazione del flusso dei dati nella comunicazione fra due
426 applicazioni attraverso i protocolli della suite TCP/IP.}
427 \label{fig:net_tcpip_data_flux}
430 Le singole applicazioni si scambieranno i dati secondo un loro formato
431 specifico, implementando un protocollo di applicazione (esempi possono essere
432 HTTP, POP, telnet, SMTP, etc).
434 Questi dati vengono inviati al livello di trasporto usando un'interfaccia
435 opportuna (i \textit{socket}, che esamineremo in dettaglio in seguito), i
436 quali li spezzerà in pacchetti di dimensione opportuna e li incapsulerà
437 all'interno del suo protocollo di trasporto aggiungendo ad ogni pacchetto le
438 informazioni necessarie alla gestione di quest'ultimo. Questo processo viene
439 svolto dirattamente nel kernel ad esempio dallo stack TCP nel caso il
440 protocollo di trasporto sia questo.
442 Una volta composto il pacchetto nel formato adatto al protocollo di trasporto
443 usato questo sarà passato al successivo livello, quello del collegamento che
444 si occupa di inserire le opportune informazioni per poter effettuare
445 l'instradamento nella rete ed il recapito alla destinazione finale. In genere
446 questo è il livello di IP (Internet Protocol), a cui vengono inseriti i numeri
447 IP che identificano i computer su internet.
449 L'ultimo passo è il trasferimento del pacchetto al driver della interfaccia di
450 trasmissione che si incarica di incapsularlo nel relativo protocollo di
451 trasmissione fisica usato dall'hardware usato per la comunicazione (ad esempio
452 ethernet per una scheda di rete).
455 \subsection{Criteri generali del design di TCP/IP}
456 \label{sec:net_tcpip_design}
458 La filosofia architetturale di TCP/IP è semplice: costruire una rete che
459 possa sopportare il carico in transito, ma permettere ai singoli nodi di
460 scartare pacchetti se il carico è temporaneamente eccessivo, o se risultano
461 errati o non recapitabili.
463 L'incarico di rendere il recapito pacchetti affidabile non spetta allo livello
464 di collegamento, ma ai livelli superiori. Pertanto il protocollo IP è per sua
465 natura inaffidabile, in quanto non è assicurata né una percentuale di
466 successo né un limite sui tempi di consegna dei pacchetti.
468 È il livello di trasporto che si deve occupare (qualora necessiti) del
469 controllo del flusso dei dati e del recupero degli errori; questo è realizzato
470 dal protocollo TCP. La sede principale di "intelligenza" della rete è pertanto
471 al livello di trasporto o superiore.
473 Infine le singole stazioni collegate alla rete non fungono soltanto da punti
474 terminali di comunicazione, ma possono anche assumere il ruolo di router, per
475 l'interscambio di pacchetti da una rete ad un'altra. Questo rende possibile la
476 flessibilità della rete che è in grado di adattarsi ai mutamenti delle
479 La caratteristica essenziale che rende tutto ciò possibile è la strutturazione
480 a livelli tramite l'incapsulamento. Ogni pacchetto di dati viene incapsulato
481 nel formato del livello successivo, fino al livello della connessione fisica.
482 In questo modo il pacchetto ricevuto ad un livello $n$ dalla stazione di
483 destinazione è esattamente lo stesso spedito dal livello $n$ dalla sorgente.
484 Questo rende facile il progettare il software facendo riferimento unicamente a
485 quanto necessario ad un singolo livello, con la confidenza che questo poi sarà
486 trattato uniformemente da tutti i nodi della rete.
489 \section{Il protocollo TCP/IP}
490 \label{sec:net_tpcip}
492 Come appena mostrato il protocollo TCP/IP è un insieme di protocolli diversi,
493 che operano su 4 livelli diversi. Per gli interessi della programmazione di
494 rete però sono importanti principalmente i due livelli centrali, e soprattutto
497 La principale interfaccia di programmazione di rete, quella dei socket, è
498 infatti un'interfaccia nei confronti di quest'ultimo. Questo avviene perché al
499 di sopra del livello di trasporto i programmi hanno a che fare solo con
500 dettagli specifici delle applicazioni, mentre al di sotto vengono curati tutti
501 i dettagli relativi alla comunicazione. È pertanto naturale definire una API
502 su questo confine tanto più che è proprio li (come evidenziato in \pfig) che
503 nei sistemi unix (e non solo) viene inserita la divisione fra kernel space e
506 In realtà in un sistema unix è possibile accedere anche agli altri livelli
507 inferiori (e non solo a quello di trasporto) con opportune interfacce (la cosa
508 è indicata in \pfig\ lasciando uno spazio fra UDP e TCP), ma queste vengono
509 usate solo quando si vogliono fare applicazioni di sistema per il controllo
510 della rete a basso livello, un uso quindi molto specialistico, e che non
511 rientra in quanto trattato qui.
513 In questa sezione daremo una breve descrizione dei vari protocolli di TCP/IP,
514 concentrandoci per le ragioni esposte sul livello di trasposto. All'interno di
515 questo privilegeremo poi il protocollo TCP, per il ruolo centrale che svolge
516 nella maggior parte delle applicazioni.
518 \subsection{Il quadro generale}
520 Benché si parli di TCP/IP questa famiglia di protocolli è composta anche da
521 altri membri. In \nfig\ si è riportato uno schema che mostra un panorama sui
522 vari prottocolli della famiglia, e delle loro relazioni reciproche e con
523 alcune dalle principali applicazioni che li usano.
525 \begin{figure}[!htbp]
528 \caption{Panoramica sui vari protocolli che compongono la suite TCP/IP.}
529 \label{fig:net_tcpip_overview}
532 I vari protocolli mostrati in figura sono i seguenti:
535 \item \textsl{IPv4} \textit{Internet Protocol version 4}. È quello che
536 comunemente si chiama IP. Ha origine negli anni '80 e da allora è la base su
537 cui è cotriuta internet. Usa indirizzi a 32 bit e provvede la trasmissione
538 dei pacchetti TCP, UDP, ICMP e IGMP.
539 \item \textsl{IPv6} \textit{Internet Protocol version 6}. È stato progettato a
540 metà degli anni '90 per rimpiazzare IPv4. Ha indirizzi a 128 bit e effettua
541 lo stesso servizio di trasporto di IPv4 per i pacchetti TCP, UDP e ICPMv6.
542 \item \textsl{TCP} \textit{Trasmission Control Protocol}. È un protocollo
543 orientato alla connessione che provvede un trasporto affidabile e
544 bidirezionale di un flusso di dati. I socket TCP sono esempi di
545 \textit{stream socket}. Il protocollo ha cura di tutti gli aspetti del
546 trasporto, come l'acknoweledgment, i timeout, la ritrasmissione, etc. È
547 usato dalla maggior parte delle applicazioni. Può essere usato sia con IPv4
549 \item \textsl{UDP} \textit{User Datagram Protocol}. È un protocollo senza
550 connessione a pacchetti. I socket UDP sono esempi di \textit{datagram
551 socket}. Contrariamente al TCP in protocollo non è affidabile e non c'è
552 garanzia che i pacchetti raggiungano la loro destinazione, né sull'eventuale
553 ordine di arrivo. Può essere usato sia con IPv4 che con IPv6.
554 \item \textsl{ICMP} \textit{Internet Control Message Protocol}. Gestisce gli
555 errori e trasporta l'informazione di controllo fra stazioni remote e
556 instradatori (\textit{host} e \textit{router}). I messaggi sono normalmente
557 generati dal software del kernel che gestisce la comunicazione TCP/IP, anche
558 se ICMP può venire usato direttamente da alcuni programmi come
559 \texttt{ping}. A volte ci si riferisce ad esso come ICPMv4 per distinguerlo
561 \item \textsl{ICMP} \textit{Internet Group Management Protocol}. É un
562 protocollo usato per il \textit{multicasting} (vedi
563 \ref{sec:xxx_multicast}), che è opzionale in IPv4.
564 \item \textsl{ARP} \textit{Address Resolution Protocol}. È il protocollo che
565 mappa un indirizzo IP in un indirizzo hardware (come un indirizzo
566 internet). È usato in reti di tipo broadcast come ethernet, token ring o
567 FDDI ma non serve in connessioni punto-punto.
568 \item \textsl{RARP} \textit{Reverse Address Resolution Protocol}. È il
569 protocollo che mappa un indirizzo hardware in un indirizzo IP. Viene usato a
570 volte per durante il boot per assegnare un indirizzo IP ad una macchina.
571 \item \textsl{ICMPv6} \textit{Internet Control Message Protocol, version 6}.
572 Combina per IPv6 le funzionalità di ICMPv4, IGMP e ARP.
573 \item \textsl{NETLINK} \textit{Netlink}.
574 Provvede l'interfaccia di accesso alla comunicazione a basso livello.
577 Gran parte delle applicazioni comunicano usando TCP o UDP, ed alcune si
578 rifanno ad IP (ed i suoi correlati ICMP e IGMP); benché sia TCP che UDP siano
579 basati su IP e sia possibile intervenire a questo livello con i \textit{raw
580 socket} questa tecnica è molto meno diffusa e a parte applicazioni
581 particolari si preferisce sempre usare i servizi messi a disposizione dai due
582 protocolli precedenti. Per questo motivo a parte alcuni brevi accenni su IP
583 in questa sezione ci concentreremo sul livello di trasporto.
585 \subsection{Internet Protocol (IP)}
588 Quando si parla di IP ci si riferisce in genere alla versione attualmente in
589 uso che è la versione 4 (e viene pertanto chiamato IPv4). Questa versione
590 venne standardizzata nel 1981 dall'RFC~719.
592 Internet Protocol nasce per disaccoppiare le applicazioni della struttura
593 hardware delle reti di trasmissione, e creare una interfaccia di trasmissione
594 dei dati indipendente dal sottostante substrato di rete, che può essere
595 realizzato con le tecnologie più disparate (Ethernet, Token Ring, FDDI, etc.).
596 Il compito di IP è pertanto quello di trasmettere i pacchetti da un computer
597 all'altro della rete; le caratteristiche essenziali con cui questo viene
598 realizzato in IPv4 sono due:
601 \item \textit{Universal addressing} la comunicazione avviene fra due host
602 identificati univocamente con un indirizzo a 32 bit che può appartenere ad
603 una sola interfaccia di rete.
604 \item \textit{Best effort} viene assicurato il massimo impegno nella
605 trasmissione, ma non c'è nessuna garanzia per i livelli superiori né sulla
606 percentuale di successo né sul tempo di consegna dei pacchetti di dati.
609 Negli anni '90 la crescita vertiginosa del numero di macchine connesse a
610 internet ha iniziato a far emergere i vari limiti di IPv4, per risolverne i
611 problemi si è perciò definita una nuova versione del protocollo, che (saltando
612 un numero) è diventata la versione 6. IPv6 nasce quindi come evoluzione di
613 IPv4, mantendone inalterate le funzioni che si sono dimostrate valide,
614 eliminando quelle inutili e aggiungendone poche altre per mantenere il
615 protocollo il più snello e veloce possibile.
617 I cambiamenti apportati sono comunque notevoli e si possono essere riassunti a
618 grandi linee nei seguenti punti:
620 \item l'espansione delle capacità di indirizzamento e instradamento, per
621 supportare una gerarchia con più livelli di indirizzamento, un numero di
622 nodi indirizzabili molto maggiore e una autoconfigurazione degli indirizzi
623 \item l'introduzione un nuovo tipo di indirizzamento, l'\textit{anycast} che
624 si aggiunge agli usuali \textit{unycast} e \textit{multicast}
625 \item la semplificazione del formato della testata, eliminando o rendendo
626 opzionali alcuni dei campi di IPv4, per eliminare la necessità di
627 riprocessamento della stessa da parte dei router e contenere l'aumento di
628 dimensione dovuto all'ampiamento degli indirizzi
629 \item un supporto per le opzioni migliorato, per garantire una trasmissione
630 più efficiente del traffico normale, limiti meno stringenti sulle dimensioni
631 delle opzioni, e la flessibilità necessaria per introdurne di nuove in
633 \item il supporto per delle capacità di qualità di servizio (QoS) che
634 permettano di identificare gruppi di dati per i quali si può provvedere un
635 trattamento speciale (in vista dell'uso di internet per applicazioni
636 multimediali e/o ``real-time'')
639 Per maggiori dettagli riguardo al protocollo si può consultare
643 \subsection{UDP: User Datagram Protocol)}
646 UDP è un protocollo di trasporto molto semplice, la sua descizione completa è
647 contenuta dell'RFC~768, ma in sostanza esso è una semplice interfaccia a IP dal
648 livello di trasporto. Quando un'applicazione usa UDP essa scrive un pacchetto
649 di dati (il cosiddetto \textit{datagram} che da il nome al protocollo) su un
650 socket, al pacchetto viene aggiunto un header molto semplice (per una
651 descrizione più accurata vedi \ref{sec:appA_udp}), e poi viene passato al
652 livello superiore (IPv4 o IPv6 che sia) che lo spedisce verso la destinazione.
653 Dato che né IPv4 né IPv6 garantiscono l'affidabilità niente assicura che il
654 pacchetto arrivi a destinazione, né che più pacchetti arrivino nello stesso
655 ordine in cui sono stati spediti.
657 Pertanto il problema principale che si affronta quando si usa UDP è la
658 mancanza di affidabilità, se si vuole essere sicuri che i pacchetti arrivino a
659 destinazione occorrerà provvedere con l'applicazione all'interno della quale
660 si dovrà inserire tutto quanto necessario a gestire la notifica di
661 ricevimento, la ritrasmissione, il timeout.
663 Si tenga conto poi che in UDP niente garantisce che i pacchetti arrivino nello
664 stesso ordine in cui sono stati trasmessi, e può anche accadere che i
665 pacchetti vengano duplicati nella trasmissione, e non solo perduti. Di tutto
666 questo di nuovo deve tenere conto l'applicazione.
668 Un'altro aspetto di UDP è che se un pacchetto raggiunge correttamente la
669 destinazione esso viene passato all'applicazione ricevente in tutta la sua
670 lunghezza, la trasmissione avviene perciò per \textit{record} la cui lunghezza
671 viene anche essa trasmessa all'applicazione all'atto del ricevimento.
673 Infine UDP è un protocollo che opera senza connessione
674 (\textit{connectionless}) in quanto non è necessario stabilire nessun tipo di
675 relazione tra origine e destinazione dei pacchetti. Si hanno così situazioni
676 in cui un client può scrivere su uno stesso socket pacchetti destinati a
677 server diversi, o un server ricevere su un socket paccetti provenienti da
678 client diversi. Il modo più semplice di immaginarsi il funzionamento di UDP è
679 quello della radio, in cui si può ``trasmettere a'' e ``ricevere da'' più
680 stazioni usando la stessa frequenza.
682 Nonostante gli evidenti svantaggi comportati dall'inaffidabilità UDP ha il
683 grande pregio della velocità che in certi casi è essenziale; inoltre si presta
684 bene per le applicazioni in cui la connessione non è necessaria e
685 costituirebbe solo un peso di prestazioni mentre una perdita di pacchetti può
686 essere tollerata, ad esempio quelle che usano il multicasting.
688 \subsection{TCP: Transport Control Protocol)}
691 Il TCP è un protocollo molto complesso, definito nell'RFC~739 e completamente
692 diverso da UDP; alla base del suo design infatti non stanno semplicità e
693 velocità, ma la ricerca della massima affidabilità possibile nella
694 trasmissione dei dati.
696 La prima differenza con UDP è che TCP provvede sempre una conessione diretta
697 fra un client e un server, attraverso la quale essi possono comunicare; per
698 questo il paragone più appropriato per questo protocollo è quello del
699 collegamento telefonico, in quanto prima viene stabilita una connessione fra
700 due i due capi della comunicazione su cui poi viene quest'ultima viene
703 Caratteristica fondamentale di TCP è l'affidabilità; quando i dati vengono
704 inviati attraverso una connessione ne viene richiesto un ``ricevuto''
705 (il cosiddetto \textit{acknowlegment}), se questo non arriva essi verranno
706 ritrasmessi per un determinato numero di tentativi, intervallati da un
707 periodo di tempo crescente, fino a che sarà considerata fallita o caduta la
708 connessione (e generato un errore di \textit{time-out}), dopo un periodo di
709 tempo che dipende dall'implementazione e che può variare far i
710 quattro e i dieci minuti.
712 Inoltre per tenere conto delle diverse condizioni in cui può trovarsi la linea
713 di comunicazione TCP comprende anche un algoritmo di calcolo dinamico del
714 tempo di andata e ritorno dei pacchetti (il cosiddetto RTT,
715 \textit{round-trip time}) fra un client e un server che lo rende in grado di
716 adattarsi alle condizioni della rete per non generare inutili ritrasmissioni o
717 cadere facilmente in timeout.
719 Inoltre TCP è in grado di preservare l'ordine dei dati assegnando un numero di
720 sequenza ad ogni byte che trasmette. Ad esempio se un'applicazione scrive 3000
721 bytes su un socket TCP, questi potranno essere spezzati dal protocollo in due
722 segmenti (le unità di dati passate da TCP a IP vengono chiamate
723 \textit{segment}) di 1500 bytes, di cui il primo conterrà il numero di
724 sequenza $1-1500$ e il secondo il numero $1501-3000$. In questo modo anche se
725 i segmenti arrivano a destinazione in un ordine diverso, o se alcuni arrivano
726 più volte a causa di ritrasmissioni dovute alla perdita dei ricevuto,
727 all'arrivo sarà comunque possibile riordinare i dati e scartare i duplicati.
729 Il protocollo provvede anche un controllo di flusso (\textit{flow control}),
730 cioè specifica sempre all'altro capo della trasmissione quanti dati può
731 ricevere tramite una \textit{advertised window} (letteralmente finestra
732 annunciata), che indica lo spazio disponibile nel buffer di ricezione,
733 cosicchè nella trasmissione non vengano inviati più dati di quelli che possono
736 Questa finestra cambia dinamicamente diminuendo con la ricezione dei dati dal
737 socket ed aumentando con la lettura di quest'ultimo da parte
738 dell'applicazione, se diventa nulla il buffer di ricezione è pieno e non
739 verranno accettati altri dati. Si noti che UDP non provvede niente di tutto
740 ciò per cui nulla impedisce che vengano trasmessi pacchetti ad un rate che il
741 ricevitore non può sostenere.
743 Infine attraverso TCP la trasmissione è sempre bidirezionale (in inglese
744 \textit{full-duplex}), è cioè possibile sia trasmettere che ricevere allo
745 stesso tempo, il che poi comporta che quanto dicevamo a proposito del
746 controllo di flusso e della gestione della sequenzialità dei dati viene
747 effettuato per entrambe le direzioni di comunicazione.
753 \chapter{Socket TCP elementari}
755 Esamineremo in questo capitolo quanto necessario per capire come scrivere un
756 client e un server TCP, riprendendo quanto visto in \ref{sec:net_cli_sample} e
757 \ref{sec:net_cli_server}.
761 \subsection{Creazione e terminazione della connessione TCP}
763 Per capire il funzionamento delle funzioni della interfaccia dei socket che
764 operano con TCP (le varie \texttt{connect}, \texttt{accept}, \texttt{close}
765 che abbiamo visto negli esempi iniziali e su cui torneremo più avatni) è
766 fodamentale capire come funziona la creazione e la conclusione di una
772 \subsection{Le porte}