Alcune correzioni, con dei riferimenti ad argomenti trattati secoli fa

[gapil.git] / network.tex

diff --git a/network.tex b/network.tex
index 15459e0073ceb56bbf195a5ddffc4db4b07cedb1..869907f298fa011311dd658583a9c38ad96c9fb4 100644 (file)
--- 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.
 
 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
 
 È 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
 
 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:
 
 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
 \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}
 
 \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
 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
 
 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


@@ -663,10 +662,10 @@ scartare i duplicati.
 
 Il protocollo provvede anche un controllo di flusso (\textit{flow control}),
 cioè specifica sempre all'altro capo della trasmissione quanti dati può
 
 Il protocollo provvede anche un controllo di flusso (\textit{flow control}),
 cioè specifica sempre all'altro capo della trasmissione quanti dati può

-ricevere tramite una \textit{advertised window} (letteralmente
-\textsl{finestra annunciata)}, che indica lo spazio disponibile nel buffer di
-ricezione, cosicché nella trasmissione non vengano inviati più dati di quelli
-che possono essere ricevuti.
+ricevere tramite una \itindex{advertised~window} \textit{advertised window}
+(letteralmente ``\textsl{finestra annunciata}''), che indica lo spazio
+disponibile nel buffer di ricezione, cosicché nella trasmissione non vengano
+inviati più dati di quelli che possono essere ricevuti.

 
 Questa finestra cambia dinamicamente diminuendo con la ricezione dei dati dal
 socket ed aumentando con la lettura di quest'ultimo da parte
 
 Questa finestra cambia dinamicamente diminuendo con la ricezione dei dati dal
 socket ed aumentando con la lettura di quest'ultimo da parte


@@ -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}).
   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
   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
 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
 
 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}
 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.
 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,16 +779,15 @@ 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}.
 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 MSS \textit{Maximum Segment Size} che annuncia
-all'altro capo della connessione la dimensione massima dimensione del segmento
-di dati che può essere ricevuto, così da evitare la frammentazione. Di norma
-viene impostato alla dimensione della MTU dell'interfaccia meno la lunghezza
-delle intestazioni di IP e TCP, in Linux il default, mantenuto nella costante
+Infine TCP definisce una \itindex{Maximum~Segment~Size} \textit{Maximum
+  Segment Size} (da qui in avanti abbreviata in MSS) che annuncia all'altro
+capo della connessione la dimensione massima dimensione del segmento di dati
+che può essere ricevuto, così da evitare la frammentazione. Di norma viene
+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.
 \const{TCP\_MSS} è 512.

+\itindend{Maximum~Transfer~Unit}

 
 
 %%% Local Variables: 
 
 
 %%% Local Variables: