X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=network.tex;h=96462f990972c5dc23c24d7964f967e1b7480c22;hp=c96d96b402fa9b0d26fc1c870f5ffa5186b66fb8;hb=250b32a55733b307d2eae8afb50b64af1b7c0bc8;hpb=3925d42aafd1c1ac743c2f0a748981c26335915d

diff --git a/network.tex b/network.tex
index c96d96b..96462f9 100644
--- a/network.tex
+++ b/network.tex
@@ -1,6 +1,6 @@
 %% network.tex
 %%
-%% Copyright (C) 2000-2006 Simone Piccardi.  Permission is granted to
+%% Copyright (C) 2000-2007 Simone Piccardi.  Permission is granted to
 %% copy, distribute and/or modify this document under the terms of the GNU Free
 %% Documentation License, Version 1.1 or any later version published by the
 %% Free Software Foundation; with the Invariant Sections being "Un preambolo",
@@ -8,6 +8,7 @@
 %% license is included in the section entitled "GNU Free Documentation
 %% License".
 %%
+
 \chapter{Introduzione alla programmazione di rete}
 \label{cha:network}
 
@@ -316,7 +317,7 @@ la procedura si pu
   pagine web, viene di solito definito ed implementato quello che viene
   chiamato un protocollo di applicazione (esempi possono essere HTTP, POP,
   SMTP, ecc.), ciascuno dei quali è descritto in un opportuno standard (di
-  solito attraverso un RFC\footnote{L'acronimo RFC sta per \textit{Request For
+  solito attraverso un RFC\footnote{l'acronimo RFC sta per \textit{Request For
       Comment} ed è la procedura attraverso la quale vengono proposti gli
     standard per Internet.}).
 \item I dati delle applicazioni vengono inviati al livello di trasporto usando
@@ -350,15 +351,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 +424,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 +575,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
@@ -617,7 +617,7 @@ grande pregio della velocit
 presta bene per le applicazioni in cui la connessione non è necessaria, e
 costituirebbe solo un peso in termini di prestazioni, mentre una perdita di
 pacchetti può essere tollerata: ad esempio le applicazioni di streaming e
-quelle che usano il \textit{multicast}. \itindex{multicast}
+quelle che usano il \itindex{multicast} \textit{multicast}.
 
 \subsection{Transport Control Protocol (TCP)}
 \label{sec:net_tcp}
@@ -663,10 +663,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ò
-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
@@ -702,7 +702,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 +753,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 +769,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 +780,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
@@ -790,6 +789,8 @@ 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: 
 %%% mode: latex