Usate le nuove macro per le referenze, e trovato un formato sensato per

[gapil.git] / elemtcp.tex

diff --git a/elemtcp.tex b/elemtcp.tex
index 94612fa7759e2fd4415015a93c33a0dca7adfaf2..d3178839f56981b5b2cb2403be16ae75b37e9d97 100644 (file)
--- a/elemtcp.tex
+++ b/elemtcp.tex
@@ -3,9 +3,10 @@
 
 In questo capitolo inizieremo ad approndire la conoscenza dei socket TCP,
 tratteremo qui dunque il funzionamento delle varie funzioni che si sono usate
 
 In questo capitolo inizieremo ad approndire la conoscenza dei socket TCP,
 tratteremo qui dunque il funzionamento delle varie funzioni che si sono usate

-nei due esempi elementari forniti in precedenza (vedi \ref{sec:net_cli_sample}
-e \ref{sec:net_serv_sample}), previa una descrizione delle principali
-caratteristiche del funzionamento di una connessione TCP.
+nei due esempi elementari forniti in precedenza (vedi
+\secref{sec:net_cli_sample} e \secref{sec:net_serv_sample}), previa una
+descrizione delle principali caratteristiche del funzionamento di una
+connessione TCP.

 
 La seconda parte del capitolo sarà poi dedicata alla scrittura di una prima
 semplice applicazione client/server completa, che implementi il servizio
 
 La seconda parte del capitolo sarà poi dedicata alla scrittura di una prima
 semplice applicazione client/server completa, che implementi il servizio


@@ -31,8 +32,8 @@ l'uso del programma \texttt{netstat}.
 Il processo che porta a creare una connessione TCP è chiamato \textit{three
   way handushake}; la successione tipica degli eventi (la stessa che si
 verifica utilizzando il codice dei due precedenti esempi elementari
 Il processo che porta a creare una connessione TCP è chiamato \textit{three
   way handushake}; la successione tipica degli eventi (la stessa che si
 verifica utilizzando il codice dei due precedenti esempi elementari

-\ref{fig:net_cli_code} e \ref{fig:net_serv_code}) che porta alla creazione di
-una connessione è la seguente:
+\figref{fig:net_cli_code} e \figref{fig:net_serv_code}) che porta alla
+creazione di una connessione è la seguente:

  
 \begin{itemize}
 \item Il server deve essere preparato per accettare le connessioni in arrivo;
  
 \begin{itemize}
 \item Il server deve essere preparato per accettare le connessioni in arrivo;


@@ -55,7 +56,7 @@ una connessione 
     \texttt{SYN}, \texttt{ACK}, \texttt{URG}, \texttt{FIN}, alcuni di essi,
     come \texttt{SYN} (che sta per \textit{sincronize}) corrispondono a
     funzioni particolari del protocollo e danno il nome al segmento, (per
     \texttt{SYN}, \texttt{ACK}, \texttt{URG}, \texttt{FIN}, alcuni di essi,
     come \texttt{SYN} (che sta per \textit{sincronize}) corrispondono a
     funzioni particolari del protocollo e danno il nome al segmento, (per

-    maggiori dettagli vedere \ref{cha:tcp_protocol})}, in sostanza viene
+    maggiori dettagli vedere \capref{cha:tcp_protocol})}, in sostanza viene

   inviato al server un pacchetto IP che contiene solo gli header IP e TCP (con
   il numero di sequenza iniziale e il flag \texttt{SYN}) e le opzioni di TCP.
   
   inviato al server un pacchetto IP che contiene solo gli header IP e TCP (con
   il numero di sequenza iniziale e il flag \texttt{SYN}) e le opzioni di TCP.
   


@@ -126,7 +127,7 @@ regolare la connessione. Normalmente vengono usate le seguenti opzioni:
   connesione corrente. È possibile leggere e scrivere questo valore attraverso
   l'opzione del socket \texttt{TCP\_MAXSEG}.
   
   connesione corrente. È possibile leggere e scrivere questo valore attraverso
   l'opzione del socket \texttt{TCP\_MAXSEG}.
   

-\item \textit{window scale option} come spiegato in \ref{cha:tcp_protocol} il
+\item \textit{window scale option} come spiegato in \capref{cha:tcp_protocol} il

   protocollo TCP implementa il controllo di flusso attraverso una
   \textsl{finestra annunciata} (\textit{advertized window}) con la quale
   ciascun capo della comunicazione dichiara quanto spazio disponibile ha in
   protocollo TCP implementa il controllo di flusso attraverso una
   \textsl{finestra annunciata} (\textit{advertized window}) con la quale
   ciascun capo della comunicazione dichiara quanto spazio disponibile ha in


@@ -164,8 +165,8 @@ elevati. In ogni caso linux supporta pienamente entrambe le opzioni.
 
 Mentre per creare una connessione occorre un interscambio di tre segmenti, la
 procedura di chiusura ne richede quattro; ancora una volta si può fare
 
 Mentre per creare una connessione occorre un interscambio di tre segmenti, la
 procedura di chiusura ne richede quattro; ancora una volta si può fare

-riferimento al codice degli esempi \ref{fig:net_cli_code} e
-\ref{fig:net_serv_code}, in questo caso la successione degli eventi è la
+riferimento al codice degli esempi \figref{fig:net_cli_code} e
+\figref{fig:net_serv_code}, in questo caso la successione degli eventi è la

 seguente:
 
 \begin{enumerate}
 seguente:
 
 \begin{enumerate}


@@ -218,17 +219,17 @@ pi
 
 La emissione del FIN avviene quando il socket viene chiuso, questo però non
 avviene solo per la chiamata della funzione \texttt{close} (come in
 
 La emissione del FIN avviene quando il socket viene chiuso, questo però non
 avviene solo per la chiamata della funzione \texttt{close} (come in

-\ref{fig:net_serv_code}), ma anche alla terminazione di un processo (come in
-\ref{fig:net_cli_code}). Questo vuol dire ad esempio che se un processo viene
-terminato da un segnale tutte le connessioni aperte verranno chiuse.
+\figref{fig:net_serv_code}), ma anche alla terminazione di un processo (come
+in \figref{fig:net_cli_code}). Questo vuol dire ad esempio che se un processo
+viene terminato da un segnale tutte le connessioni aperte verranno chiuse.

 
 Infine è da sottolineare che, benché nella figura (e nell'esempio che vedremo
 
 Infine è da sottolineare che, benché nella figura (e nell'esempio che vedremo

-in \ref{sec:TCPel_echo_example}) sia il client ad eseguire la chiusura attiva,
-nella realtà questa può essere eseguita da uno qualunque dei due capi della
-comunicazione (come in fatto in precedenza da \ref{fig:net_serv_code}), e
-benché quello del client sia il caso più comune ci sono alcuni servizi, il
-principale dei quali è l'HTTP, per i quali è il server ad effettuare la
-chiusura attiva.
+in \secref{sec:TCPel_echo_example}) sia il client ad eseguire la chiusura
+attiva, nella realtà questa può essere eseguita da uno qualunque dei due capi
+della comunicazione (come in fatto in precedenza da
+\figref{fig:net_serv_code}), e benché quello del client sia il caso più comune
+ci sono alcuni servizi, il principale dei quali è l'HTTP, per i quali è il
+server ad effettuare la chiusura attiva.

 
 \subsection{Un esempio di connessione}
 \label{sec:TCPel_conn_dia}
 
 \subsection{Un esempio di connessione}
 \label{sec:TCPel_conn_dia}


@@ -242,7 +243,7 @@ che vengono riportati del comando \texttt{netstat} nel campo \textit{State}.
 
 Una descrizione completa del funzionamento del protocollo va al di là degli
 obiettivi di questo libro; un approfondimento sugli aspetti principali si
 
 Una descrizione completa del funzionamento del protocollo va al di là degli
 obiettivi di questo libro; un approfondimento sugli aspetti principali si

-trova in \ref{cha:tcp_protocol}, ma per una trattazione esauriente il miglior
+trova in \capref{cha:tcp_protocol}, ma per una trattazione esauriente il miglior

 riferimento resta (FIXME citare lo Stevens); qui ci limiteremo a descrivere
 brevemente un semplice esempio di connessione e le transizioni che avvengono
 nei due casi appena citati (creazione e terminazione della connessione).
 riferimento resta (FIXME citare lo Stevens); qui ci limiteremo a descrivere
 brevemente un semplice esempio di connessione e le transizioni che avvengono
 nei due casi appena citati (creazione e terminazione della connessione).


@@ -289,7 +290,7 @@ caso contrario si avrebbe prima l'emissione di un ACK e poi l'invio della
 risposta.
 
 Infine si ha lo scambio dei quattro segmenti che terminano la connessione
 risposta.
 
 Infine si ha lo scambio dei quattro segmenti che terminano la connessione

-secondo quanto visto in \ref{sec:TCPel_conn_term}; si noti che il capo della
+secondo quanto visto in \secref{sec:TCPel_conn_term}; si noti che il capo della

 connessione che esegue la chiusura attiva entra nello stato
 \textsl{TIME\_WAIT} su cui torneremo fra poco.
 
 connessione che esegue la chiusura attiva entra nello stato
 \textsl{TIME\_WAIT} su cui torneremo fra poco.
 


@@ -329,7 +330,7 @@ La MSL 
 sulla rete; questo tempo è limitato perché ogni pacchetto IP può essere
 ritrasmesso dai router un numero massimo di volte (detto \textit{hop limit}).
 Il numero di ritrasmissioni consentito è indicato dal campo TTL dell'header di
 sulla rete; questo tempo è limitato perché ogni pacchetto IP può essere
 ritrasmesso dai router un numero massimo di volte (detto \textit{hop limit}).
 Il numero di ritrasmissioni consentito è indicato dal campo TTL dell'header di

-IP (per maggiori dettagli vedi \ref{sec:appA_xxx}), e viene decrementato ad
+IP (per maggiori dettagli vedi \secref{sec:appA_xxx}), e viene decrementato ad

 ogni passaggio da un router; quando si annulla il pacchetto viene scartato.
 Siccome il numero è ad 8 bit il numero massimo di ``salti'' è di 255, pertanto
 anche se il TTL (da \textit{time to live}) non è propriamente un limite sul
 ogni passaggio da un router; quando si annulla il pacchetto viene scartato.
 Siccome il numero è ad 8 bit il numero massimo di ``salti'' è di 255, pertanto
 anche se il TTL (da \textit{time to live}) non è propriamente un limite sul


@@ -422,7 +423,7 @@ In un ambiente multitasking in un dato momento pi
 usare sia UDP che TCP, e ci devono poter essere più connessioni in
 contemporanea. Per poter tenere distinte le diverse connessioni entrambi i
 protocolli usano i \textsl{numeri di porta}, che fanno parte, come si può
 usare sia UDP che TCP, e ci devono poter essere più connessioni in
 contemporanea. Per poter tenere distinte le diverse connessioni entrambi i
 protocolli usano i \textsl{numeri di porta}, che fanno parte, come si può

-vedere in \ref{sec:sock_sa_ipv4} e \ref{sec:sock_sa_ipv6} pure delle strutture
+vedere in \secref{sec:sock_sa_ipv4} e \secref{sec:sock_sa_ipv6} pure delle strutture

 degli indirizzi del socket.
 
 Quando un client contatta un server deve poter identificare con quale dei vari
 degli indirizzi del socket.
 
 Quando un client contatta un server deve poter identificare con quale dei vari


@@ -508,7 +509,7 @@ campi \textit{Local Address} e \textit{Foreing Address}.
 
 Per capire meglio l'uso delle porte e come vengono utilizzate quando si ha a
 che fare con un'applicazione client/server (come quella che scriveremo in
 
 Per capire meglio l'uso delle porte e come vengono utilizzate quando si ha a
 che fare con un'applicazione client/server (come quella che scriveremo in

-\ref{sec:TCPel_echo_example}) esaminaremo cosa accade con le connessioni nel
+\secref{sec:TCPel_echo_example}) esaminaremo cosa accade con le connessioni nel

 caso di un server TCP che deve gestire connessioni multiple.
 
 Se esguiamo un \texttt{netstat} su una macchina di prova (che supponiamo avere
 caso di un server TCP che deve gestire connessioni multiple.
 
 Se esguiamo un \texttt{netstat} su una macchina di prova (che supponiamo avere


@@ -600,14 +601,14 @@ alla porta 21101 al secondo.
 
 In questa sezione descriveremo in dettaglio le varie funzioni necessarie per
 l'uso dei socket TCP già citate in precedenza (e utilizzate nei due esempi
 
 In questa sezione descriveremo in dettaglio le varie funzioni necessarie per
 l'uso dei socket TCP già citate in precedenza (e utilizzate nei due esempi

-\ref{sec:net_cli_sample} e \ref{sec:net_serv_sample}) con l'eccezione della
-funzione \texttt{socket} che è già stata esaminata in dettaglio in
-\ref{sec:sock_socket}.
+\secref{sec:net_cli_sample} e \secref{sec:net_serv_sample}) con l'eccezione
+della funzione \texttt{socket} che è già stata esaminata in dettaglio in
+\secref{sec:sock_socket}.

 
 In \nfig\ abbiamo un tipico schema di funzionamento di un'applicazione
 client-server che usa i socket TCP: prima il server viene avviato ed in
 seguito il client si connette, in questo caso, a differenza di quanto accadeva
 
 In \nfig\ abbiamo un tipico schema di funzionamento di un'applicazione
 client-server che usa i socket TCP: prima il server viene avviato ed in
 seguito il client si connette, in questo caso, a differenza di quanto accadeva

-con gli esempi elementari del Cap.~\ref{cha:network} si assume che sia il
+con gli esempi elementari del Cap.~\capref{cha:network} si assume che sia il

 client ad effettuare delle richieste a cui il server risponde, il client
 notifica poi di avere concluso inviando un end-of-file a cui il server
 risponderà anche lui chiudendo la connessione per aspettarne una nuova.
 client ad effettuare delle richieste a cui il server risponde, il client
 notifica poi di avere concluso inviando un end-of-file a cui il server
 risponderà anche lui chiudendo la connessione per aspettarne una nuova.


@@ -621,7 +622,7 @@ risponder
 \end{figure}
 
 Useremo questo schema per l'esempio di implementazione del servizio
 \end{figure}
 
 Useremo questo schema per l'esempio di implementazione del servizio

-\texttt{echo} che illustreremo in \ref{sec:TCPel_echo_example}. 
+\texttt{echo} che illustreremo in \secref{sec:TCPel_echo_example}. 

 
 
 \subsection{La funzione \texttt{bind}}
 
 
 \subsection{La funzione \texttt{bind}}


@@ -642,7 +643,7 @@ Il prototipo della funzione, definito in \texttt{sys/socket.h}, 
   Il primo argomento è un file descriptor ottenuto da una precedente chiamata
   a \texttt{socket}, mentre il secondo e terzo argomento sono rispettivamente
   l'indirizzo (locale) del socket e la dimensione della struttura che lo
   Il primo argomento è un file descriptor ottenuto da una precedente chiamata
   a \texttt{socket}, mentre il secondo e terzo argomento sono rispettivamente
   l'indirizzo (locale) del socket e la dimensione della struttura che lo

-  contiene, secondo quanto già trattato in \ref{sec:sock_sockaddr}.
+  contiene, secondo quanto già trattato in \secref{sec:sock_sockaddr}.

 
   La funzione restituisce zero in caso di successo e -1 per un errore, in caso
   di errore. La variabile \texttt{errno} viene settata secondo i seguenti
 
   La funzione restituisce zero in caso di successo e -1 per un errore, in caso
   di errore. La variabile \texttt{errno} viene settata secondo i seguenti


@@ -685,7 +686,7 @@ client.
 
 Per specificare un indirizzo generico con IPv4 si usa il valore
 \texttt{INADDR\_ANY}, il cui valore, come visto anche negli esempi precedenti
 
 Per specificare un indirizzo generico con IPv4 si usa il valore
 \texttt{INADDR\_ANY}, il cui valore, come visto anche negli esempi precedenti

-è pari a zero, nell'esempio \ref{fig:net_serv_sample} si è usata
+è pari a zero, nell'esempio \figref{fig:net_serv_sample} si è usata

 un'assegnazione immediata del tipo:
 \begin{verbatim}
    serv_add.sin_addr.s_addr = htonl(INADDR_ANY);   /* connect from anywhere */
 un'assegnazione immediata del tipo:
 \begin{verbatim}
    serv_add.sin_addr.s_addr = htonl(INADDR_ANY);   /* connect from anywhere */


@@ -724,7 +725,7 @@ connessione con un server TCP, il prototipo della funzione, definito in
   Il primo argomento è un file descriptor ottenuto da una precedente chiamata
   a \texttt{socket}, mentre il secondo e terzo argomento sono rispettivamente
   l'indirizzo e la dimensione della struttura che contiene l'indirizzo del
   Il primo argomento è un file descriptor ottenuto da una precedente chiamata
   a \texttt{socket}, mentre il secondo e terzo argomento sono rispettivamente
   l'indirizzo e la dimensione della struttura che contiene l'indirizzo del

-  socket, già descritta in \ref{sec:sock_sockaddr}.
+  socket, già descritta in \secref{sec:sock_sockaddr}.

 
   La funzione restituisce zero in caso di successo e -1 per un errore, in caso
   di errore. La variabile \texttt{errno} viene settata secondo i seguenti
 
   La funzione restituisce zero in caso di successo e -1 per un errore, in caso
   di errore. La variabile \texttt{errno} viene settata secondo i seguenti


@@ -755,8 +756,8 @@ connessione con un server TCP, il prototipo della funzione, definito in
 
 La struttura dell'indirizzo deve essere inizializzata con l'indirizzo IP e il
 numero di porta del server a cui ci si vuole connettere, come mostrato
 
 La struttura dell'indirizzo deve essere inizializzata con l'indirizzo IP e il
 numero di porta del server a cui ci si vuole connettere, come mostrato

-nell'esempio \ref{sec:net_cli_sample} usando le funzioni illustrate in
-\ref{sec:sock_addr_func}.
+nell'esempio \secref{sec:net_cli_sample} usando le funzioni illustrate in
+\secref{sec:sock_addr_func}.

 
 Nel caso di socket TCP la funzione \texttt{connect} avvia il three way
 handshake, e ritorna solo quando la connessione è stabilita o si è verificato
 
 Nel caso di socket TCP la funzione \texttt{connect} avvia il three way
 handshake, e ritorna solo quando la connessione è stabilita o si è verificato


@@ -802,7 +803,7 @@ da errori o problemi nella chiamata della funzione sono le seguenti:
 \end{enumerate}
 
 Se si fa riferimento al diagramma degli stati del TCP riportato in
 \end{enumerate}
 
 Se si fa riferimento al diagramma degli stati del TCP riportato in

-\ref{fig:appB:tcp_state_diag} la funzione \texttt{connect} porta un socket
+\figref{fig:appB:tcp_state_diag} la funzione \texttt{connect} porta un socket

 dallo stato \texttt{CLOSED} (lo stato iniziale in cui si trova un socket
 appena creato) prima allo stato \texttt{SYN\_SENT} e poi, al ricevimento del
 ACK, nello stato \texttt{ESTABLISHED}. Se invece la connessione fallisce il
 dallo stato \texttt{CLOSED} (lo stato iniziale in cui si trova un socket
 appena creato) prima allo stato \texttt{SYN\_SENT} e poi, al ricevimento del
 ACK, nello stato \texttt{ESTABLISHED}. Se invece la connessione fallisce il