\label{cha:network}
In questo capitolo sarà fatta un'introduzione ai concetti generali che servono
-come prerequisiti per capire la programmazione di rete, per evitare un
-capitolo puramente teorico partiremo con due semplici esempi per poi passare
-ad un esame a grandi linee dei protocolli di rete e di come questi sono
-organizzati e interagiscono.
+come prerequisiti per capire la programmazione di rete, non tratteremo quindi
+aspetti specifici ma faremo una breve introduzione al modello più comune usato
+nella programmazione di rete, per poi passare ad un esame a grandi linee dei
+protocolli di rete e di come questi sono organizzati e interagiscono.
In particolare, avendo assunto l'ottica di un'introduzione mirata alla
programmazione, ci concentreremo sul protocollo più diffuso, il TCP/IP, che è
-quello che sta alla base di internet, con un'ottica improntata a sottolineare
-i concetti più importanti da conoscere ai fini della programmazione.
+quello che sta alla base di internet, avendo cura di sottolineare i concetti
+più importanti da conoscere per la scrittura dei programmi.
\section{Il modello client-server}
\label{sec:net_cliserv}
presuppone un sistema operativo ``multitasking'' in grado di eseguire processi
diversi.
-Il concetto fondamentale si basa la programmazione di rete sotto Linux (e
-sotto Unix in generale) è il modello \textit{client-server} in cui un
-programma di servizio, il \textit{server} riceve un connessione e risponde a
+Un concetto fondamentale su cui si basa la programmazione di rete sotto Linux
+(e sotto Unix in generale) è il modello \textit{client-server} in cui un
+programma di servizio, il \textit{server}, riceve una connessione e risponde a
un programma di utilizzo, il \textit{client}, provvedendo a quest'ultimo un
definito insieme di servizi.
il suo lavoro viene terminato, mentre il server originale resta sempre attivo.
-\subsection{Un primo esempio di client}
-\label{sec:net_cli_sample}
-
-Per evitare di rendere l'esposizione dei concetti generali sulla rete
-puramente teorica iniziamo con il mostrare un esempio di un client TCP
-elementare. Scopo di questo esempio è fornire un primo approccio alla
-programmazione di rete, tutto questo sarà esaminato in dettaglio nei capitoli
-successivo; qui ci limiteremo a introdurre la nomenclatura senza fornire
-definizioni precise e dettagli di funzionamento che saranno trattati
-estensivamente più avanti.
-
-In \nfig\ è riportata la sezione principale del codice del nostro client
-elementare per il servizio \textit{daytime}, un servizio standard che
-restituisce l'ora locale della macchina a cui si effettua la richiesta.
-
-
-\begin{figure}[!htb]
- \footnotesize
- \begin{lstlisting}{}
-#include <sys/types.h> /* predefined types */
-#include <unistd.h> /* include unix standard library */
-#include <arpa/inet.h> /* IP addresses conversion utiliites */
-#include <sys/socket.h> /* socket library */
-#include <stdio.h> /* include standard I/O library */
-
-int main(int argc, char *argv[])
-{
- int sock_fd;
- int i, nread;
- struct sockaddr_in serv_add;
- char buffer[MAXLINE];
- ...
- /* create socket */
- if ( (sock_fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
- perror("Socket creation error");
- return -1;
- }
- /* initialize address */
- memset((void *) &serv_add, 0, sizeof(serv_add)); /* clear server address */
- serv_add.sin_family = AF_INET; /* address type is INET */
- serv_add.sin_port = htons(13); /* daytime post is 13 */
- /* build address using inet_pton */
- if ( (inet_pton(AF_INET, argv[optind], &serv_add.sin_addr)) <= 0) {
- perror("Address creation error");
- return -1;
- }
- /* extablish connection */
- if (connect(sock_fd, (struct sockaddr *)&serv_add, sizeof(serv_add)) < 0) {
- perror("Connection error");
- return -1;
- }
- /* read daytime from server */
- while ( (nread = read(sock_fd, buffer, MAXLINE)) > 0) {
- buffer[nread]=0;
- if (fputs(buffer, stdout) == EOF) { /* write daytime */
- perror("fputs error");
- return -1;
- }
- }
- /* error on read */
- if (nread < 0) {
- perror("Read error");
- return -1;
- }
- /* normal exit */
- return 0;
-}
- \end{lstlisting}
- \caption{Esempio di codice di un client elementare per il servizio daytime.}
- \label{fig:net_cli_code}
-\end{figure}
-
-Il sorgente completo del programma (\texttt{SimpleDaytimeTCPClient.c}, che
-comprende il trattamento delle opzioni e una funzione per stampare un
-messaggio di aiuto) è allegato alla guida nella sezione dei codici sorgente e
-può essere compilato su una qualunque macchina Linux.
-
-Il programma anzitutto include gli header necessari (\texttt{\small 1--5});
-dopo la dichiarazione delle variabili (\texttt{\small 9--12}) si è omessa
-tutta la parte relativa al trattamento degli argomenti passati dalla linea di
-comando (effettuata con le apposite routines illustrate in
-\capref{cha:parameter_options}).
-
-Il primo passo (\texttt{\small 14--18}) è creare un \textit{socket} IPv4
-(\texttt{AF\_INET}), di tipo TCP \texttt{SOCK\_STREAM} (in sostanza un canale
-di comunicazione attraverso internet, questi termini verranno spiegati con
-precisione più avanti). La funzione \texttt{socket} ritorna un descrittore,
-analogo a quello dei file, che viene usato per identificare il socket in tutte
-le chiamate successive. Nel caso la chiamata fallisca si stampa un errore con
-la relativa routine e si esce.
-
-Il passo seguente (\texttt{\small 19--27}) è quello di costruire una apposita
-struttura \texttt{sockaddr\_in} in cui sarà inserito l'indirizzo del server ed
-il numero della porta del servizio. Il primo passo è inizializzare tutto a
-zero, per poi inserire il tipo di protocollo e la porta (usando per
-quest'ultima la funzione \texttt{htons} per convertire il formato dell'intero
-usato dal computer a quello usato nella rete), infine si utilizza la funzione
-\texttt{inet\_pton} per convertire l'indirizzo numerico passato dalla linea di
-comando.
-
-Usando la funzione \texttt{connect} sul socket creato in precedenza
-(\texttt{\small 28--32}) si provvede poi a stabilire la connessione con il
-server specificato dall'indirizzo immesso nella struttura passata come secondo
-argomento, il terzo argomento è la dimensione di detta struttura. Dato che
-esistono diversi tipi di socket, si è dovuto effettuare un cast della
-struttura inizializzata in precedenza, che è specifica per i socket IPv4. Un
-valore di ritorno negativo implica il fallimento della connessione.
-
-Completata con successo la connessione il passo successivo (\texttt{\small
- 34--40}) è leggere la data dal socket; il server invierà sempre una stringa
-di 26 caratteri della forma \verb|Wed Apr 4 00:53:00 2001\r\n|, che viene
-letta dalla funzione \texttt{read} e scritta su \texttt{stdout}.
-
-Dato il funzionamento di TCP la risposta potrà tornare in un unico pacchetto
-di 26 byte (come avverrà senz'altro nel caso in questione) ma potrebbe anche
-arrivare in 26 pacchetti di un byte. Per questo nel caso generale non si può
-mai assumere che tutti i dati arrivino con una singola lettura, pertanto
-quest'ultima deve essere effettuata in un loop in cui si continui a leggere
-fintanto che la funzione \texttt{read} non ritorni uno zero (che significa che
-l'altro capo ha chiuso la connessione) o un numero minore di zero (che
-significa un errore nella connessione).
-
-Si noti come in questo caso la fine dei dati sia specificata dal server che
-chiude la connessione; questa è una delle tecniche possibili (è quella usata
-pure dal protocollo HTTP), ma ce ne possono essere altre, ad esempio FTP marca
-la conclusione di un blocco di dati con la sequenza ASCII \verb|\r\n|
-(carriage return e line feed), mentre il DNS mette la lunghezza in testa ad
-ogni blocco che trasmette. Il punto essenziale è che TCP non provvede nessuna
-indicazione che permetta di marcare dei blocchi di dati, per cui se questo è
-necessario deve provvedere il programma stesso.
-
-\subsection{Un primo esempio di server}
-\label{sec:net_serv_sample}
-
-Dopo aver illustrato il client daremo anche un esempio di un server
-elementare, in grado di rispondere al precedente client. Il listato è
-nuovamente mostrato in \nfig, il sorgente completo
-(\texttt{SimpleDaytimeTCPServer.c}) è allegato insieme agli altri file nella
-directory \texttt{sources}.
-
-\begin{figure}[!htbp]
- \footnotesize
- \begin{lstlisting}{}
-#include <sys/types.h> /* predefined types */
-#include <unistd.h> /* include unix standard library */
-#include <arpa/inet.h> /* IP addresses conversion utiliites */
-#include <sys/socket.h> /* socket library */
-#include <stdio.h> /* include standard I/O library */
-#include <time.h>
-#define MAXLINE 80
-#define BACKLOG 10
-int main(int argc, char *argv[])
-{
-/*
- * Variables definition
- */
- int list_fd, conn_fd;
- int i;
- struct sockaddr_in serv_add;
- char buffer[MAXLINE];
- time_t timeval;
- ...
- /* create socket */
- if ( (list_fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
- perror("Socket creation error");
- exit(-1);
- }
- /* initialize address */
- memset((void *)&serv_add, 0, sizeof(serv_add)); /* clear server address */
- serv_add.sin_family = AF_INET; /* address type is INET */
- serv_add.sin_port = htons(13); /* daytime port is 13 */
- serv_add.sin_addr.s_addr = htonl(INADDR_ANY); /* connect from anywhere */
- /* bind socket */
- if (bind(list_fd, (struct sockaddr *)&serv_add, sizeof(serv_add)) < 0) {
- perror("bind error");
- exit(-1);
- }
- /* listen on socket */
- if (listen(list_fd, BACKLOG) < 0 ) {
- perror("listen error");
- exit(-1);
- }
- /* write daytime to client */
- while (1) {
- if ( (conn_fd = accept(list_fd, (struct sockaddr *) NULL, NULL)) <0 ) {
- perror("accept error");
- exit(-1);
- }
- timeval = time(NULL);
- snprintf(buffer, sizeof(buffer), "%.24s\r\n", ctime(&timeval));
- if ( (write(conn_fd, buffer, strlen(buffer))) < 0 ) {
- perror("write error");
- exit(-1);
- }
- close(conn_fd);
- }
- /* normal exit */
- exit(0);
-}
- \end{lstlisting}
- \caption{Esempio di codice di un semplice server per il servizio daytime.}
- \label{fig:net_serv_code}
-\end{figure}
-
-Come per il client si includono gli header necessari a cui è aggiunto quello
-per trattare i tempi, e si definiscono alcune costanti e le variabili
-necessarie in seguito (\texttt{\small 1--18}), come nel caso precedente si
-sono omesse le parti relative al trattamento delle opzioni da riga di comando.
-
-La creazione del socket (\texttt{\small 22--26}) è analoga al caso precedente,
-come pure l'inizializzazione della struttura \texttt{sockaddr\_in}, anche in
-questo caso si usa la porta standard del servizio daytime, ma come indirizzo
-IP si il valore predefinito \texttt{INET\_ANY} che corrisponde ad un indirizzo
-generico (\texttt{\small 27--31}).
-
-Si effettua poi (\texttt{\small 32--36}) la chiamata alla funzione
-\texttt{bind} che permette di associare la precedente struttura al socket, in
-modo che quest'ultimo possa essere usato per accettare connessioni su una
-qualunque delle interfacce di rete locali.
-
-Il passo successivo (\texttt{\small 37--41}) è mettere ``in ascolto'' il
-socket, questo viene effettuato con la funzione \texttt{listen} che dice al
-kernel di accettare connessioni per il socket specificato, la funzione indica
-inoltre, con il secondo parametro, il numero massimo di connessioni che il
-kernel accetterà di mettere in coda per il suddetto socket.
-
-Questa ultima chiamata completa la preparazione del socket per l'ascolto (che
-viene chiamato anche \textit{listening descriptor}) a questo punto il processo
-è mandato in sleep (\texttt{\small 44--47}) con la successiva chiamata alla
-funzione \texttt{accept}, fin quando non arriva e viene accettata una
-connessione da un client.
-
-Quando questo avviene \texttt{accept} ritorna un secondo descrittore di
-socket, che viene chiamato \textit{connected descriptor} che è quello che
-viene usato dalla successiva chiamata alla \texttt{write} per scrivere la
-risposta al client, una volta che si è opportunamente (\texttt{\small 48--49})
-costruita la stringa con la data da trasmettere. Completata la trasmissione il
-nuovo socket viene chiuso (\texttt{\small 54}).
-Il tutto è inserito in un loop infinito (\texttt{\small 42--55}) in modo da
-poter ripetere l'invio della data ad una successiva connessione.
-
-È importante notare che questo server è estremamente elementare, infatti a
-parte il fatto di essere dipendente da IPv4, esso è in grado di servire solo
-un client alla volta, è cioè un \textsl{server iterativo}, inoltre esso è
-scritto per essere lanciato da linea di comando, se lo si volesse utilizzare
-come demone di sistema (che è in esecuzione anche quando non c'è nessuna shell
-attiva e il terminale da cui lo si è lanciato è stato sconnesso),
-occorrerebbero delle opportune modifiche.
\section{I protocolli di rete}
\label{sec:net_protocols}
-Visto un primo esempio di programmazione, passiamo ora ad una introduzione più
-dettagliata del funzionamento delle reti e dei relativi protocolli.
-
Parlando di reti di computer si parla in genere di un insieme molto vasto ed
eterogeneo di mezzi di comunicazione che vanno dal cavo telefonico, alla fibra
ottica, alle comunicazioni via satellite; per rendere possibile la
funzionamento è stato stato standardizzato dalla \textit{International
Standards Organization} (ISO) che ha preparato fin dal 1984 il Modello di
Riferimento \textit{Open Systems Interconnection} (OSI), strutturato in sette
-livelli, secondo quanto riportato in \ntab.
+livelli, secondo quanto riportato in \tabref{tab:net_osilayers}.
\begin{table}[htb]
\centering
- \begin{tabular}{l c c l}
- \textbf{Livello} & \multicolumn{2}{c}{\textbf{Nome}} & \\
+ \begin{tabular}{|l|c|c|l|}
+ \hline
+ \textbf{Livello} & \multicolumn{2}{|c|}{\textbf{Nome}} & \\
+ \hline
\hline
Livello 7&\textit{Application} &\textsl{Applicazione}& \\
Livello 6&\textit{Presentation} &\textsl{Presentazione}& \\
\label{tab:net_osilayers}
\end{table}
-Il modello ISO/OSI è stato sviluppato corrispondentemente alla definizione
+Il modello ISO/OSI è stato sviluppato in corrispondenza alla definizione
della serie di protocolli X.25 per la commutazione di pacchetto. Ma nonostante
il lavoro dettagliato di standardizzazione il modello si è rivelato
sostanzialmente troppo complesso e poco flessibile rispetto a quello,
Defense}), dato che fu sviluppato dall'agenzia ARPA per il Dipartimento
della Difesa Americano.
-
\begin{figure}[!htbp]
\centering
-
+ \includegraphics[width=12cm]{img/iso_tcp_comp}
\caption{Struttura a livelli dei protocolli OSI e TCP/IP, con la
relative corrispondenze e la divisione fra kernel e user space.}
\label{fig:net_osi_tcpip_comp}
\end{figure}
-
\subsection{Il modello DoD (TCP/IP)}
\label{sec:net_tcpip_overview}
\begin{table}[htb]
\centering
- \begin{tabular}{l c c l}
- \textbf{Livello} & \multicolumn{2}{c}{\textbf{Nome}} & \textbf{Esempi} \\
+ \begin{tabular}{|l|c|c|l|}
+ \hline
+ \textbf{Livello} & \multicolumn{2}{|c|}{\textbf{Nome}} & \textbf{Esempi} \\
+ \hline
\hline
Livello 1&\textit{Application} &\textsl{Applicazione}&
Telnet, FTP, etc. \\
\label{tab:net_layers}
\end{table}
-
Come si può notare TCP/IP è più semplice del modello ISO/OSI e strutturato in
soli quattro livelli. Il suo nome deriva dai due principali protocolli che lo
compongono, il TCP \textit{Trasmission Control Protocol} e l'IP
\end{description}
-La comunicazione fra due stazioni avviene pertanto secondo le modalità
-illustrate in \nfig.
-
-
-\begin{figure}[!htbp]
+La comunicazione fra due stazioni avviene secondo le modalità illustrate in
+\nfig, dove si è riportato il flusso dei dati reali e i protocolli usati per
+lo scambio di informazione su ciascuno livello.
+\begin{figure}[!htb]
\centering
-
+ \includegraphics[width=10cm]{img/tcp_data_flux}
\caption{Strutturazione del flusso dei dati nella comunicazione fra due
applicazioni attraverso i protocolli della suite TCP/IP.}
\label{fig:net_tcpip_data_flux}
\end{figure}
-Le singole applicazioni si scambieranno i dati secondo un loro formato
-specifico, implementando un protocollo di applicazione (esempi possono essere
-HTTP, POP, telnet, SMTP, etc).
-
-Questi dati vengono inviati al livello di trasporto usando un'interfaccia
-opportuna (i \textit{socket}, che esamineremo in dettaglio in seguito), i
-quali li spezzerà in pacchetti di dimensione opportuna e li incapsulerà
-all'interno del suo protocollo di trasporto aggiungendo ad ogni pacchetto le
-informazioni necessarie alla gestione di quest'ultimo. Questo processo viene
-svolto direttamente nel kernel ad esempio dallo stack TCP nel caso il
-protocollo di trasporto sia questo.
-
-Una volta composto il pacchetto nel formato adatto al protocollo di trasporto
-usato questo sarà passato al successivo livello, quello del collegamento che
-si occupa di inserire le opportune informazioni per poter effettuare
-l'instradamento nella rete ed il recapito alla destinazione finale. In genere
-questo è il livello di IP (Internet Protocol), a cui vengono inseriti i numeri
-IP che identificano i computer su internet.
-
-L'ultimo passo è il trasferimento del pacchetto al driver della interfaccia di
-trasmissione che si incarica di incapsularlo nel relativo protocollo di
-trasmissione fisica usato dall'hardware usato per la comunicazione (ad esempio
-ethernet per una scheda di rete).
+La struttura della comunicazione pertanto si può riassumere nei seguenti passi:
+\begin{itemize}
+\item Le singole applicazioni si scambieranno i dati secondo un loro formato
+ specifico, implementando un protocollo di applicazione (esempi possono
+ essere HTTP, POP, telnet, SMTP, etc).
+\item Questi dati vengono inviati al livello di trasporto usando
+ un'interfaccia opportuna (i \textit{socket}, che esamineremo in dettaglio in
+ seguito). Qui verranno spezzati in pacchetti di dimensione opportuna e
+ incapsulati nel protocollo di trasporto, aggiungendo ad ogni pacchetto le
+ informazioni necessarie per la sua gestione. Questo processo viene
+ svolto direttamente nel kernel ad esempio dallo stack TCP nel caso il
+ protocollo di trasporto sia questo.
+\item Una volta composto il pacchetto nel formato adatto al protocollo di
+ trasporto usato questo sarà passato al successivo livello, quello di rete,
+ che si occupa di inserire le opportune informazioni per poter effettuare
+ l'instradamento nella rete ed il recapito alla destinazione finale. In
+ genere questo è il livello di IP (Internet Protocol), a cui vengono inseriti
+ i numeri IP che identificano i computer su internet.
+\item L'ultimo passo è il trasferimento del pacchetto al driver della
+ interfaccia di trasmissione che si incarica di incapsularlo nel relativo
+ protocollo di trasmissione fisica usato dall'hardware usato per la
+ comunicazione (ad esempio Ethernet per una scheda di rete).
+\end{itemize}
\subsection{Criteri generali del design di TCP/IP}
La caratteristica essenziale che rende tutto ciò possibile è la strutturazione
a livelli tramite l'incapsulamento. Ogni pacchetto di dati viene incapsulato
nel formato del livello successivo, fino al livello della connessione fisica.
-In questo modo il pacchetto ricevuto ad un livello $n$ dalla stazione di
-destinazione è esattamente lo stesso spedito dal livello $n$ dalla sorgente.
-Questo rende facile il progettare il software facendo riferimento unicamente a
-quanto necessario ad un singolo livello, con la confidenza che questo poi sarà
-trattato uniformemente da tutti i nodi della rete.
+In questo modo il pacchetto ricevuto ad un livello \textit{n} dalla stazione
+di destinazione è esattamente lo stesso spedito dal livello \textit{n} dalla
+sorgente. Questo rende facile il progettare il software facendo riferimento
+unicamente a quanto necessario ad un singolo livello, con la confidenza che
+questo poi sarà trattato uniformemente da tutti i nodi della rete.
\section{Il protocollo TCP/IP}
questo privilegeremo poi il protocollo TCP, per il ruolo centrale che svolge
nella maggior parte delle applicazioni.
+
\subsection{Il quadro generale}
+\label{sec:net_tcpip_general}
Benché si parli di TCP/IP questa famiglia di protocolli è composta anche da
altri membri. In \nfig\ si è riportato uno schema che mostra un panorama sui
\begin{figure}[!htbp]
\centering
-
+ \includegraphics[width=15cm]{img/tcpip_overview}
\caption{Panoramica sui vari protocolli che compongono la suite TCP/IP.}
\label{fig:net_tcpip_overview}
\end{figure}
se ICMP può venire usato direttamente da alcuni programmi come
\texttt{ping}. A volte ci si riferisce ad esso come ICPMv4 per distinguerlo
da ICMPv6.
-\item \textsl{ICMP} \textit{Internet Group Management Protocol}. É un
+\item \textsl{IGMP} \textit{Internet Group Management Protocol}. É un
protocollo usato per il \textit{multicasting} (vedi
\secref{sec:xxx_multicast}), che è opzionale in IPv4.
\item \textsl{ARP} \textit{Address Resolution Protocol}. È il protocollo che
mappa un indirizzo IP in un indirizzo hardware (come un indirizzo
- internet). È usato in reti di tipo broadcast come ethernet, token ring o
+ internet). È usato in reti di tipo broadcast come Ethernet, Token Ring o
FDDI ma non serve in connessioni punto-punto.
\item \textsl{RARP} \textit{Reverse Address Resolution Protocol}. È il
protocollo che mappa un indirizzo hardware in un indirizzo IP. Viene usato a
nodi indirizzabili molto maggiore e una autoconfigurazione degli indirizzi
\item l'introduzione un nuovo tipo di indirizzamento, l'\textit{anycast} che
si aggiunge agli usuali \textit{unycast} e \textit{multicast}
-\item la semplificazione del formato della testata, eliminando o rendendo
- opzionali alcuni dei campi di IPv4, per eliminare la necessità di
- riprocessamento della stessa da parte dei router e contenere l'aumento di
- dimensione dovuto all'ampliamento degli indirizzi
+\item la semplificazione del formato dell'intestazione (\textit{header}) dei
+ pacchetti, eliminando o rendendo opzionali alcuni dei campi di IPv4, per
+ eliminare la necessità di riprocessamento della stessa da parte dei router e
+ contenere l'aumento di dimensione dovuto all'ampliamento degli indirizzi
\item un supporto per le opzioni migliorato, per garantire una trasmissione
più efficiente del traffico normale, limiti meno stringenti sulle dimensioni
delle opzioni, e la flessibilità necessaria per introdurne di nuove in
dal livello di trasporto. Quando un'applicazione usa UDP essa scrive un
pacchetto di dati (il cosiddetto \textit{datagram} che da il nome al
protocollo) su un socket, al pacchetto viene aggiunto un header molto semplice
-(per una descrizione più accurata vedi \secref{sec:appA_udp}), e poi viene
+(per una descrizione più accurata vedi \secref{sec:xxx_udp}), e poi viene
passato al livello superiore (IPv4 o IPv6 che sia) che lo spedisce verso la
destinazione. Dato che né IPv4 né IPv6 garantiscono l'affidabilità niente
assicura che il pacchetto arrivi a destinazione, né che più pacchetti arrivino
Inoltre TCP è in grado di preservare l'ordine dei dati assegnando un numero di
sequenza ad ogni byte che trasmette. Ad esempio se un'applicazione scrive 3000
-bytes su un socket TCP, questi potranno essere spezzati dal protocollo in due
+byte su un socket TCP, questi potranno essere spezzati dal protocollo in due
segmenti (le unità di dati passate da TCP a IP vengono chiamate
-\textit{segment}) di 1500 bytes, di cui il primo conterrà il numero di
+\textit{segment}) di 1500 byte, di cui il primo conterrà il numero di
sequenza $1-1500$ e il secondo il numero $1501-3000$. In questo modo anche se
i segmenti arrivano a destinazione in un ordine diverso, o se alcuni arrivano
più volte a causa di ritrasmissioni dovute alla perdita dei ricevuto,
Un elenco di questi limiti è il seguente, insieme ad un breve accenno alle
loro origini ed alle eventuali implicazioni che possono avere:
\begin{itemize}
-\item La dimensione massima di un pacchetti IP è di 65535 bytes, compreso
+\item La dimensione massima di un pacchetti IP è di 65535 byte, compreso
l'header. Questo è dovuto al fatto che la dimensione è indicata da un campo
apposito nell'header di IP che è lungo 16 bit (vedi
- \secref{sec:appA_ipv4head}).
-\item La dimensione massima di un pacchetto normale di IPv6 è di 65575 bytes,
+ \figref{fig:IP_ipv4_head}).
+\item La dimensione massima di un pacchetto normale di IPv6 è di 65575 byte,
il campo apposito nell'header infatti è sempre a 16 bit, ma la dimensione
dell'header è fissa e di 40 byte e non è compresa nel valore indicato dal
suddetto campo. Inoltre IPv6 ha la possibilità di estendere la dimensione di
un pacchetto usando la \textit{jumbo payload option}.
-\item Molte reti fisiche hanno un MTU (\textit{maximum tranfer unit}) che
+\item Molte reti fisiche hanno un MTU (\textit{maximum transfer unit}) che
dipende dal protocollo specifico usato al livello di link. Il più comune è
- quello dell'ethernet che è pari a 1500 bytes, una serie di valori possibili
+ quello dell'Ethernet che è pari a 1500 byte, una serie di valori possibili
sono riportati in \ntab.
\end{itemize}
+Quando un pacchetto IP viene inviato su una interfaccia di rete e le sue
+dimensioni eccedono la MTU viene eseguita la cosiddetta
+\textit{frammentazione}, i pacchetti cioè vengono spezzati (sia da IPv4 che da
+IPv6, anche se i pacchetti frammentati sono gestiti con modalità
+diverse,\footnote{il primo usa un flag nell'header, il secondo una opportuna
+ opzione, si veda \secref{cha:ip_protocol}.}) in blocchi più piccoli che
+possono essere trasmessi attraverso l'interfaccia.
+
\begin{table}[!htb]
\centering
\begin{tabular}[c]{|l|c|}
\hline
\textbf{Rete} & \textbf{MTU} \\
\hline
+ \hline
Hyperlink & 65535 \\
Token Ring IBM (16 Mbit/sec) & 17914 \\
Token Ring IEEE 802.5 (4 Mbit/sec) & 4464 \\
X.25 & 576 \\
\hline
\end{tabular}
- \caption{Valori della MTU (\textit{maximum tranfer unit}) per una serie di
+ \caption{Valori della MTU (\textit{maximum transfer unit}) per una serie di
reti diverse.}
\label{tab:net_mtu_values}
\end{table}
-Quando un pacchetto IP viene inviato su una interfaccia di rete e le sue
-dimensioni eccedono la MTU viene eseguita la cosiddetta
-\textit{frammentazione}, i pacchetti cioè vengono spezzati (sia da IPv4 che da
-IPv6, anche se i pacchetti frammentati sono gestiti con modalità
-diverse\footnote{il primo usa un flag nell'header, il secondo una opportuna
- opzione, si veda \secref{cha:ip_protcol}}), in blocchi più piccoli che
-possono essere trasmessi attraverso l'interfaccia.
-
La MTU più piccola fra due stazioni viene in genere chiamata \textit{path
MTU}, che dice qual'è la lunghezza massima oltre la quale un pacchetto
inviato da una stazione ad un'altra verrebbe senz'altro frammentato. Si tenga
pacchetto non deve essere frammentato; un router che riceva un pacchetto le
cui dimensioni eccedano quelle dell'MTU della rete di destinazione genererà un
messaggio di errore ICMPv4 di tipo \textit{destination unreachable,
- fragentation needed but DF bit set}.
+ fragmentation needed but DF bit set}.
Dato che i router IPv6 non possono effettuare la frammentazione la ricezione
di un pacchetto di dimensione eccessiva per la ritrasmissione genererà sempre
Infine TCP definisce una \textit{maximum segment size} MSS che annuncia
-all'altro capo la dimensione massima del segmento di dati
+all'altro capo la dimensione massima del segmento di dati.
+
+%\subsection{Il passaggio dei dati in TCP}
+%\label{sec:net_tcp_pass}
-\subsection{Il passaggio dei dati in TCP}
-\label{sec:net_tcp_pass}
+%\subsection{Il passaggio dei dati in UDP}
+%\label{sec:net_udp_pass}
-\subsection{Il passaggio dei dati in UDP}
-\label{sec:net_udp_pass}
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End:
projects / gapil.git / blobdiff