Sistemati i riferimenti
[gapil.git] / network.tex
index f6b571ba196abee09037536fcb40247c489c758f..879f9708bda4d2ccc59f534e7806865604d9aaab 100644 (file)
@@ -350,17 +350,15 @@ quest'ultimo viene comunemente chiamato modello DoD (\textit{Department of
   Defense}), dato che fu sviluppato dall'agenzia ARPA per il Dipartimento
 della Difesa Americano.
 
   Defense}), dato che fu sviluppato dall'agenzia ARPA per il Dipartimento
 della Difesa Americano.
 
-
 \begin{figure}[!htbp]
   \centering
 \begin{figure}[!htbp]
   \centering
-  
+  \includegraphics[width=8cm]{img/iso_tcp_comp.eps}
   \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}
 
 
   \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}
 
 \subsection{Il modello DoD (TCP/IP)}
 \label{sec:net_tcpip_overview}
 
@@ -388,7 +386,6 @@ operativo rispetto alla divisione fra user space e kernel space spiegata in
 \label{tab:net_layers}
 \end{table}
 
 \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
 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
@@ -414,41 +411,40 @@ compongono, il TCP \textit{Trasmission Control Protocol} e l'IP
 \end{description}
 
 
 \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
   \centering
-  
+  \includegraphics[width=6cm]{img/tcp_data_flux.eps}  
   \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}
 
   \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 comuniczione 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 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.
+\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}
 
 
 \subsection{Criteri generali del design di TCP/IP}
@@ -523,7 +519,7 @@ alcune dalle principali applicazioni che li usano.
 
 \begin{figure}[!htbp]
   \centering
 
 \begin{figure}[!htbp]
   \centering
-  
+  \includegraphics[width=10cm]{img/tcpip_overview.eps}  
   \caption{Panoramica sui vari protocolli che compongono la suite TCP/IP.}
   \label{fig:net_tcpip_overview}
 \end{figure}
   \caption{Panoramica sui vari protocolli che compongono la suite TCP/IP.}
   \label{fig:net_tcpip_overview}
 \end{figure}
@@ -647,7 +643,7 @@ contenuta dell'RFC~768, ma in sostanza esso 
 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
 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
 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
@@ -763,7 +759,7 @@ loro origini ed alle eventuali implicazioni che possono avere:
 \item La dimensione massima di un pacchetti IP è di 65535 bytes, compreso
   l'header. Questo è dovuto al fatto che la dimensione è indicata da un campo
   apposito nell'header di IP che è lungo 16 bit (vedi
 \item La dimensione massima di un pacchetti IP è di 65535 bytes, 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}).
+  \tabref{tab:IP_ipv4head}).
 \item La dimensione massima di un pacchetto normale di IPv6 è di 65575 bytes,
   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
 \item La dimensione massima di un pacchetto normale di IPv6 è di 65575 bytes,
   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
@@ -775,12 +771,21 @@ loro origini ed alle eventuali implicazioni che possono avere:
   sono riportati in \ntab.
 \end{itemize}
 
   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
 \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 \\
     Hyperlink & 65535 \\
     Token Ring IBM (16 Mbit/sec) & 17914 \\
     Token Ring IEEE 802.5 (4 Mbit/sec) & 4464 \\
@@ -794,14 +799,6 @@ loro origini ed alle eventuali implicazioni che possono avere:
   \label{tab:net_mtu_values}
 \end{table}
 
   \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
 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