X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=network.tex;h=dc24c665d7a4420441aa3b607b115a902f621909;hp=6da5a497bcd25476e5fa5cc6943ca18aef248280;hb=4826742c87d76af810c8a30e5495135fb43b8091;hpb=caa4d2b308da07b9522599555d07db6f67351601

diff --git a/network.tex b/network.tex
index 6da5a49..dc24c66 100644
--- a/network.tex
+++ b/network.tex
@@ -2,15 +2,15 @@
 \label{cha:network}
 
 In questo capitolo sarà fatta un'introduzione ai contetti generali che servono
-come prerequisiti per capire la programmazione di rete, partiremo con due
-semplici esempi per poi passare ad un esame a grandi linee dei protocolli di
-rete e di come questi sono organizzati e interagiscono.
+come prerequisiti per capire la programmazione di rete, per evitare un
+capitolo puramente teorico partiremo con due semplici esempi per poi passare
+ad un esame a grandi linee dei protocolli di rete e di come questi sono
+organizzati e interagiscono.
 
 In particolare, avendo assunto l'ottica di un'introduzione mirata alla
-programmazione, ci concentreremo sul protocollo più diffuso, TCP/IP, che è
-quello che sta alla base di internet, ed in particolare prenderemo in esame in
-questa introduzione i concetti più importanti da conoscere ai fini della
-programmazione.
+programmazione, ci concentreremo sul protocollo più diffuso, il TCP/IP, che è
+quello che sta alla base di internet, con un'ottica improntata a sottolineare
+i concetti più importanti da conoscere ai fini della programmazione.
 
 \section{Il modello client-server}
 \label{sec:net_cliserv}
@@ -35,18 +35,18 @@ generale anche per programmi che non fanno necessariamente uso della rete,
 come il sistema a finestre.
 
 Normalmente si dividono i server in due categorie principali, e vengono detti
-\textit{concorrenti} o \textit{iterativi}, sulla base del loro comportamento.
+\textsl{concorrenti} o \textsl{iterativi}, sulla base del loro comportamento.
 
-Un server iterativo risponde alla richiesta inviando i dati e resta occupato
-(non rispondendo ad ulteriori richieste) fintanto che non ha concluso la
-richiesta. Una volta completata la richiesta il server diventa di nuovo
+Un \textsl{server iterativo} risponde alla richiesta inviando i dati e resta
+occupato (non rispondendo ad ulteriori richieste) fintanto che non ha concluso
+la richiesta. Una volta completata la richiesta il server diventa di nuovo
 disponibile.
 
-Un server concorrente al momento di trattare la richiesta crea un processo
-figlio incaricato di fornire i servizi richiesti, per poi porsi in attesa di
-ulteriori richieste. In questo modo più richieste possono essere soddisfatte
-contemporaneamente; una volta che il processo figlio ha concluso il suo lavoro
-viene terminato, mentre il server originale resta sempre attivo.
+Un \textsl{server concorrente} al momento di trattare la richiesta crea un
+processo figlio incaricato di fornire i servizi richiesti, per poi porsi in
+attesa di ulteriori richieste. In questo modo più richieste possono essere
+soddisfatte contemporaneamente; una volta che il processo figlio ha concluso
+il suo lavoro viene terminato, mentre il server originale resta sempre attivo.
 
 
 \subsection{Un primo esempio di client}
@@ -130,7 +130,7 @@ Il programma anzitutto include gli header necessari (\texttt{\small 1--5});
 dopo la dichiarazione delle variabili (\texttt{\small 9--12}) si è omessa
 tutta la parte relativa al trattamento degli argomenti passati dalla linea di
 comando (effettuata con le apposite routines illustrate in
-\ref{cha:parameter_options}).
+\capref{cha:parameter_options}).
 
 Il primo passo (\texttt{\small 14--18}) è creare un \textit{socket} IPv4
 (\texttt{AF\_INET}), di tipo TCP \texttt{SOCK\_STREAM} (in sostanza un canale
@@ -369,7 +369,7 @@ Cos
 anche la corrispondenza fra i rispettivi livelli (che comunque è
 approssimativa) e su come essi vanno ad inserirsi all'interno del sistema
 operativo rispetto alla divisione fra user space e kernel space spiegata in
-\ref{sec:intro_unix_struct}.
+\secref{sec:intro_unix_struct}.
 
 \begin{table}[htb]
   \centering
@@ -397,7 +397,7 @@ compongono, il TCP \textit{Trasmission Control Protocol} e l'IP
 \begin{description}
 \item \textbf{Applicazione} É relativo ai programmi di interfaccia utente, in
   genere questi vengono realizzati secondo il modello Client-Server (vedi
-  \ref{sec:net_cliserv}.
+  \secref{sec:net_cliserv}.
 \item \textbf{Trasporto} Fornisce la comunicazione tra le due stazioni
   terminali su cui girano gli applicativi, regola il flusso delle
   informazioni, e può fornire un trasporto affidabile, cioè con recupero
@@ -559,7 +559,7 @@ I vari protocolli mostrati in figura sono i seguenti:
   da ICMPv6.
 \item \textsl{ICMP} \textit{Internet Group Management Protocol}. É un
   protocollo usato per il \textit{multicasting} (vedi
-  \ref{sec:xxx_multicast}), che è opzionale in IPv4.
+  \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
@@ -636,22 +636,22 @@ grandi linee nei seguenti punti:
 \end{itemize}
 
 Maggiori dettagli riguardo a caratteristiche, notazioni e funzionamento del
-protocollo IP sono forniti nell'appendice \ref{cha:ip_protocol}.
+protocollo IP sono forniti nell'appendice \capref{cha:ip_protocol}.
 
  
 \subsection{UDP: User Datagram Protocol)}
 \label{sec:net_udp}
 
 UDP è un protocollo di trasporto molto semplice, la sua descizione completa è
-contenuta dell'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 \ref{sec:appA_udp}), 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.
+contenuta dell'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 \secref{sec:appA_udp}), 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
@@ -746,7 +746,7 @@ controllo di flusso e della gestione della sequenzialit
 effettuato per entrambe le direzioni di comunicazione.
 
 Una descrizione più accurata del protocollo è fornita in appendice
-\ref{cha:tcp_protocol}.
+\capref{cha:tcp_protocol}.
 
 \subsection{Limiti e dimensioni riguardanti la trasmissione dei dati}
 \label{sec:net_lim_dim}
@@ -763,7 +763,7 @@ loro origini ed alle eventuali implicazioni che possono avere:
 \item La dimensione massima di un pacchetti IP è di 65535 bytes, compreso
   l'header. Questo è dovuto al fatto che la dimensione è indicata da un campo
   apposito nell'header di IP che è lungo 16 bit (vedi
-  \ref{sec:appA_ipv4head}).
+  \secref{sec:appA_ipv4head}).
 \item La dimensione massima di un pacchetto normale di IPv6 è di 65575 bytes,
   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
@@ -797,8 +797,8 @@ 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 \ref{cha:ip_protcol}}), in blocchi più piccoli che possono
-essere trasmessi attraverso l'interfaccia.
+  opzione, si veda \secref{cha:ip_protcol}}), in blocchi più piccoli che
+possono essere trasmessi attraverso l'interfaccia.
 
 La MTU più piccola fra due stazioni viene in genere chiamata \textit{path
   MTU}, che dice qual'è la lunghezza massima oltre la quale un pacchetto