X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=blobdiff_plain;f=network.tex;h=869907f298fa011311dd658583a9c38ad96c9fb4;hb=b52f6b91fcc6e0bc4a1522462f61f5f62e684bfe;hp=e7859a0395b3afe27e33eff89df2a07c7398c7f3;hpb=1df343113e14ea885c3c3fdb985b2cb84230bd62;p=gapil.git

diff --git a/network.tex b/network.tex
index e7859a0..869907f 100644
--- a/network.tex
+++ b/network.tex
@@ -350,15 +350,15 @@ possa sopportare il carico in transito, ma permettere ai singoli nodi di
 scartare pacchetti se il carico è temporaneamente eccessivo, o se risultano
 errati o non recapitabili.
 
-L'incarico di rendere il recapito pacchetti affidabile non spetta allo livello
-di collegamento, ma ai livelli superiori. Pertanto il protocollo IP è per sua
-natura inaffidabile, in quanto non è assicurata né una percentuale di
-successo né un limite sui tempi di consegna dei pacchetti.
+L'incarico di rendere il recapito pacchetti affidabile non spetta al livello
+di rete, ma ai livelli superiori. Pertanto il protocollo IP è per sua natura
+inaffidabile, in quanto non è assicurata né una percentuale di successo né un
+limite sui tempi di consegna dei pacchetti.
 
 È il livello di trasporto che si deve occupare (qualora necessiti) del
 controllo del flusso dei dati e del recupero degli errori; questo è realizzato
-dal protocollo TCP. La sede principale di "intelligenza" della rete è pertanto
-al livello di trasporto o ai livelli superiori.
+dal protocollo TCP. La sede principale di "\textit{intelligenza}" della rete è
+pertanto al livello di trasporto o ai livelli superiori.
 
 Infine le singole stazioni collegate alla rete non fungono soltanto da punti
 terminali di comunicazione, ma possono anche assumere il ruolo di
@@ -423,7 +423,6 @@ relazioni reciproche e con alcune dalle principali applicazioni che li usano.
 
 I vari protocolli riportati in fig.~\ref{fig:net_tcpip_overview} sono i
 seguenti:
-
 \begin{basedescript}{\desclabelwidth{1.7cm}\desclabelstyle{\nextlinelabel}}
 \item[\textsl{IPv4}] \textit{Internet Protocol version 4}. È quello che
   comunemente si chiama IP. Ha origine negli anni '80 e da allora è la base su
@@ -575,17 +574,17 @@ protocollo IP sono forniti nell'appendice sez.~\ref{sec:ip_protocol}.
 \subsection{User Datagram Protocol (UDP)}
 \label{sec:net_udp}
 
-UDP è un protocollo di trasporto molto semplice, la sua descrizione completa è
+UDP è un protocollo di trasporto molto semplice; la sua descrizione completa è
 contenuta dell'\href{http://www.ietf.org/rfc/rfc0768.txt}{RFC~768}, ma in
-sostanza esso è una semplice interfaccia a IP 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
-sez.~\ref{sec:udp_protocol}), 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 nello stesso ordine in cui sono
-stati spediti.
+sostanza esso è una semplice interfaccia al protocollo IP 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 sez.~\ref{sec:udp_protocol}), 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 nello stesso
+ordine in cui sono stati spediti.
 
 Pertanto il problema principale che si affronta quando si usa UDP è la
 mancanza di affidabilità, se si vuole essere sicuri che i pacchetti arrivino a
@@ -702,7 +701,7 @@ alle eventuali implicazioni che possono avere, 
   l'intestazione. Questo è dovuto al fatto che la dimensione è indicata da un
   campo apposito nell'header di IP che è lungo 16 bit (vedi
   fig.~\ref{fig:IP_ipv4_head}).
-\item La dimensione massima di un pacchetto normale di IPv6 è di 65575 byte,
+\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
@@ -753,9 +752,9 @@ sensi, con diverse tipologie di rete coinvolte.
 Una delle differenze fra IPv4 e IPv6 é che per IPv6 la frammentazione può
 essere eseguita solo alla sorgente, questo vuol dire che i router IPv6 non
 frammentano i pacchetti che ritrasmettono (anche se possono frammentare i
-pacchetti che generano loro stessi), mentre i router IPv4 si. In ogni caso una
-volta frammentati i pacchetti possono essere riassemblati solo alla
-destinazione.
+pacchetti che generano loro stessi), al contrario di quanto fanno i router
+IPv4. In ogni caso una volta frammentati i pacchetti possono essere
+riassemblati solo alla destinazione.
 
 Nell'header di IPv4 è previsto il flag \texttt{DF} che specifica che il
 pacchetto non deve essere frammentato; un router che riceva un pacchetto le
@@ -769,9 +768,9 @@ di tipo \textit{packet too big}.
 Dato che il meccanismo di frammentazione e riassemblaggio dei pacchetti
 comporta inefficienza, normalmente viene utilizzato un procedimento, detto
 \textit{path MTU discovery} che permette di determinare il \textit{path MTU}
-fra due stazioni; per la realizzazione del procedimento si usa il flag DF di
-IPv4 e il comportamento normale di IPv6 inviando delle opportune serie di
-pacchetti (per i dettagli vedere
+fra due stazioni; per la realizzazione del procedimento si usa il flag
+\texttt{DF} di IPv4 e il comportamento normale di IPv6 inviando delle
+opportune serie di pacchetti (per i dettagli vedere
 l'\href{http://www.ietf.org/rfc/rfc1191.txt}{RFC~1191} per IPv4 e
 l'\href{http://www.ietf.org/rfc/rfc1981.txt}{RFC~1981} per IPv6) fintanto che
 non si hanno più errori.
@@ -780,7 +779,6 @@ Il TCP usa sempre questo meccanismo, che per le implementazioni di IPv4 
 opzionale, mentre diventa obbligatorio per IPv6.  Per IPv6 infatti, non
 potendo i router frammentare i pacchetti, è necessario, per poter comunicare,
 conoscere da subito il \textit{path MTU}.
-\itindend{Maximum~Transfer~Unit}
 
 Infine TCP definisce una \itindex{Maximum~Segment~Size} \textit{Maximum
   Segment Size} (da qui in avanti abbreviata in MSS) che annuncia all'altro
@@ -789,6 +787,7 @@ che pu
 impostato alla dimensione della MTU dell'interfaccia meno la lunghezza delle
 intestazioni di IP e TCP, in Linux il default, mantenuto nella costante
 \const{TCP\_MSS} è 512.
+\itindend{Maximum~Transfer~Unit}
 
 
 %%% Local Variables: