Alcune correzioni, con dei riferimenti ad argomenti trattati secoli fa

e che adeso risaltano fuori nella nuova sezione sulla gestione dei
socket.

diff --git a/network.tex b/network.tex
index e5d7405440926727b90784be2ad8bf6e51ea1e87..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


@@ -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.

diff --git a/sockctrl.tex b/sockctrl.tex
index c32676605b954b6edc0c4fb3bc380b643104ea26..ec5d9d763d8c1b0695d62cba79a00cb4e33bb331 100644 (file)
--- a/sockctrl.tex
+++ b/sockctrl.tex
@@ -4135,7 +4135,9 @@ pagina di manuale (accessibile con \texttt{man 7 tcp}), sono i seguenti:
   possibile ottimizzare il server in modo che sia in grado di accettare
   connessioni più rapidamente.
 
   possibile ottimizzare il server in modo che sia in grado di accettare
   connessioni più rapidamente.
 

-\item[\texttt{tcp\_adv\_win\_scale}] 
+\item[\texttt{tcp\_adv\_win\_scale}] permette di impostare il valore di scala
+  usato nell'opzione \textit{window scale} del protocollo TCP (vedi
+  sez.~\ref{sec:TCP_TCP_opt}) 

 
 \item[\texttt{tcp\_app\_win}] 
 \item[\texttt{tcp\_bic\_low\_window}] 
 
 \item[\texttt{tcp\_app\_win}] 
 \item[\texttt{tcp\_bic\_low\_window}] 

diff --git a/tcpsock.tex b/tcpsock.tex
index a82be2a8942abc3dc381fed7f3f719c4497e15e8..7261246389bdf1e8ac4b3f8fb13b51d263fdfa93 100644 (file)
--- a/tcpsock.tex
+++ b/tcpsock.tex
@@ -125,10 +125,14 @@ varr
 \subsection{Le opzioni TCP.}
 \label{sec:TCP_TCP_opt}
 
 \subsection{Le opzioni TCP.}
 \label{sec:TCP_TCP_opt}
 

-Ciascun segmento SYN contiene in genere delle opzioni per il protocollo TCP
-(le cosiddette \textit{TCP options}, che vengono inserite fra l'header e i
-dati) che servono a comunicare all'altro capo una serie di parametri utili a
-regolare la connessione. Normalmente vengono usate le seguenti opzioni:
+Ciascun segmento SYN contiene in genere delle opzioni per il protocollo TCP,
+le cosiddette \textit{TCP options},\footnote{da non confondere con le opzioni
+  dei socket TCP che tratteremo in sez.~\ref{sec:sock_tcp_udp_options}, in
+  questo caso si tratta delle opzioni che vengono trasmesse come parte di un
+  pacchetto TCP, non delle funzioni che consentono di impostare i relativi
+  valori.} che vengono inserite fra l'header e i dati, e che servono a
+comunicare all'altro capo una serie di parametri utili a regolare la
+connessione.  Normalmente vengono usate le seguenti opzioni:

 
 \begin{itemize}
 \item \textit{MSS option}, dove MMS sta per \itindex{Maximum~Segment~Size}
 
 \begin{itemize}
 \item \textit{MSS option}, dove MMS sta per \itindex{Maximum~Segment~Size}


@@ -136,7 +140,7 @@ regolare la connessione. Normalmente vengono usate le seguenti opzioni:
   connessione annuncia all'altro il massimo ammontare di dati che vorrebbe
   accettare per ciascun segmento nella connessione corrente. È possibile
   leggere e scrivere questo valore attraverso l'opzione del socket
   connessione annuncia all'altro il massimo ammontare di dati che vorrebbe
   accettare per ciascun segmento nella connessione corrente. È possibile
   leggere e scrivere questo valore attraverso l'opzione del socket

-  \const{TCP\_MAXSEG} (vedi sez.~\ref{sec:TCP_TCP_opt}).
+  \const{TCP\_MAXSEG} (vedi sez.~\ref{sec:sock_tcp_udp_options}}).

   
 \item \textit{window scale option}, il protocollo TCP implementa il controllo
   di flusso attraverso una \itindex{advertised~window} \textit{advertised
   
 \item \textit{window scale option}, il protocollo TCP implementa il controllo
   di flusso attraverso una \itindex{advertised~window} \textit{advertised


@@ -158,7 +162,9 @@ regolare la connessione. Normalmente vengono usate le seguenti opzioni:
     inserendola anche lui nel suo SYN di risposta dell'apertura della
     connessione.} per la connessione corrente (espresso come numero di bit cui
   spostare a sinistra il valore della finestra annunciata inserito nel
     inserendola anche lui nel suo SYN di risposta dell'apertura della
     connessione.} per la connessione corrente (espresso come numero di bit cui
   spostare a sinistra il valore della finestra annunciata inserito nel

-  pacchetto).
+  pacchetto). Con Linux è possibile impostare questo valore a livello di
+  sistema con una opportuna \textit{sysctl} (vedi
+  sez.~\ref{sec:sock_ipv4_sysctl}). 

 
 \item \textit{timestamp option}, è anche questa una nuova opzione necessaria
   per le connessioni ad alta velocità per evitare possibili corruzioni di dati
 
 \item \textit{timestamp option}, è anche questa una nuova opzione necessaria
   per le connessioni ad alta velocità per evitare possibili corruzioni di dati