Passata generale di ispell

[gapil.git] / network.tex

diff --git a/network.tex b/network.tex
index 38861150f79d9dee8f5c632303f5b48c4560a247..49c6a5f5825aff98a3adfb5a4ccf3df00b957dda 100644 (file)
--- a/network.tex
+++ b/network.tex
@@ -90,7 +90,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 +101,7 @@ della Difesa Americano.
 
 \begin{figure}[!htbp]
   \centering
 
 \begin{figure}[!htbp]
   \centering

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


@@ -165,13 +165,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}  
+  \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 +192,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}
 
 


@@ -259,6 +259,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


@@ -307,7 +308,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 +463,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 +506,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}
 


@@ -543,7 +544,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 +567,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