Quattro chiacchiere sullo scheduling standard di unix (nice &C).

[gapil.git] / network.tex

diff --git a/network.tex b/network.tex
index de8376f830c29db41bae36c0b933a046d434bbca..7c0fbc798f1b492b0e55c014acf15b40305b393f 100644 (file)
--- a/network.tex
+++ b/network.tex
@@ -74,8 +74,10 @@ livelli, secondo quanto riportato in \ntab.
 
 \begin{table}[htb]
   \centering
 
 \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}& \\ 
     \hline
     Livello 7&\textit{Application} &\textsl{Applicazione}& \\ 
     Livello 6&\textit{Presentation} &\textsl{Presentazione}& \\ 


@@ -90,7 +92,7 @@ livelli, secondo quanto riportato in \ntab.
 \label{tab:net_osilayers}
 \end{table}
 
 \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,
 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,


@@ -101,7 +103,7 @@ della Difesa Americano.
 
 \begin{figure}[!htbp]
   \centering
 
 \begin{figure}[!htbp]
   \centering

-  \includegraphics[width=8cm]{img/iso_tcp_comp.eps}
+  \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}
   \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}


@@ -120,8 +122,10 @@ operativo rispetto alla divisione fra user space e kernel space spiegata in
 
 \begin{table}[htb]
   \centering
 
 \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. \\ 
     \hline
     Livello 1&\textit{Application} &\textsl{Applicazione}& 
     Telnet, FTP, etc. \\ 


@@ -165,13 +169,13 @@ La comunicazione fra due stazioni avviene secondo le modalit
 lo scambio di informazione su ciascuno livello.
 \begin{figure}[!htb]
   \centering
 lo scambio di informazione su ciascuno livello.
 \begin{figure}[!htb]
   \centering

-  \includegraphics[width=6cm]{img/tcp_data_flux.eps}  
+  \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}
 
   \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}
 

-La struttura della comuniczione pertanto si può riassumere nei seguenti passi:
+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
 \begin{itemize}
 \item Le singole applicazioni si scambieranno i dati secondo un loro formato
   specifico, implementando un protocollo di applicazione (esempi possono


@@ -192,7 +196,7 @@ La struttura della comuniczione pertanto si pu
 \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
 \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).
+  comunicazione (ad esempio Ethernet per una scheda di rete).

 \end{itemize}
 
 
 \end{itemize}
 
 


@@ -223,11 +227,11 @@ interconnessioni.
 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.
 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}
 
 
 \section{Il protocollo TCP/IP}


@@ -259,6 +263,7 @@ concentrandoci per le ragioni esposte sul livello di trasporto. All'interno di
 questo privilegeremo poi il protocollo TCP, per il ruolo centrale che svolge
 nella maggior parte delle applicazioni.
 
 questo privilegeremo poi il protocollo TCP, per il ruolo centrale che svolge
 nella maggior parte delle applicazioni.
 

+

 \subsection{Il quadro generale}
 
 Benché si parli di TCP/IP questa famiglia di protocolli è composta anche da
 \subsection{Il quadro generale}
 
 Benché si parli di TCP/IP questa famiglia di protocolli è composta anche da


@@ -268,7 +273,7 @@ alcune dalle principali applicazioni che li usano.
 
 \begin{figure}[!htbp]
   \centering
 
 \begin{figure}[!htbp]
   \centering

-  \includegraphics[width=10cm]{img/tcpip_overview.eps}  
+  \includegraphics[width=15cm]{img/tcpip_overview}  

   \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}


@@ -307,7 +312,7 @@ I vari protocolli mostrati in figura sono i seguenti:
   \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
   \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
   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


@@ -462,9 +467,9 @@ cadere facilmente in timeout.
 
 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
 
 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
 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,
 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,


@@ -505,18 +510,18 @@ delle applicazioni.
 Un elenco di questi limiti è il seguente, insieme ad un breve accenno alle
 loro origini ed alle eventuali implicazioni che possono avere:
 \begin{itemize}
 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
   \tabref{tab:IP_ipv4head}).
   l'header. Questo è dovuto al fatto che la dimensione è indicata da un campo
   apposito nell'header di IP che è lungo 16 bit (vedi
   \tabref{tab:IP_ipv4head}).

-\item La dimensione massima di un pacchetto normale di IPv6 è di 65575 bytes,
+\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}.
   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 è
   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}
 
   sono riportati in \ntab.
 \end{itemize}
 


@@ -524,8 +529,8 @@ 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à
 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
+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]
 possono essere trasmessi attraverso l'interfaccia.
 
 \begin{table}[!htb]


@@ -543,7 +548,7 @@ possono essere trasmessi attraverso l'interfaccia.
     X.25 & 576 \\
     \hline
   \end{tabular}
     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}
     reti diverse.}
   \label{tab:net_mtu_values}
 \end{table}


@@ -566,7 +571,7 @@ Nell'header di IPv4 
 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,
 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
 
 Dato che i router IPv6 non possono effettuare la frammentazione la ricezione
 di un pacchetto di dimensione eccessiva per la ritrasmissione genererà sempre


@@ -590,8 +595,13 @@ 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: