Riorganizzate varie parti, rimetto in linea la nuova versione
[gapil.git] / elemtcp.tex
index 270b9a585b2860879aa999d66bb2ec38c324663c..3c4b2169d1637903a2e7feefd4e2d8ec852e7d0b 100644 (file)
@@ -86,7 +86,7 @@ la connessione.
 
 \begin{figure}[htb]
   \centering
-  
+  \includegraphics[width=10cm]{img/three_way_handshake.eps}  
   \caption{Il \textit{three way handshake} del TCP}
   \label{fig:TCPel_TWH}
 \end{figure}
@@ -188,7 +188,6 @@ seguente:
   con un ACK.
 \end{enumerate}
 
-
 Dato che in questo caso sono richiesti un FIN ed un ACK per ciascuna direzione
 normalmente i segmenti scambiati sono quattro; normalmente giacché in alcune
 situazioni il FIN del passo 1) è inviato insieme a dei dati. Comunque non è
@@ -197,10 +196,10 @@ accorpati in un singolo segmento. In \nfig\ si 
 sequenza di scambio dei segmenti che stabilisce la connessione.
 
 \begin{figure}[htb]
-  \centering
-  
-  \caption{Il \textit{three way handshake} del TCP}
-  \label{fig:TCPel_TWH}
+  \centering  
+  \includegraphics[width=10cm]{img/tcp_close.eps}  
+  \caption{La chiusura di una connessione TCP}
+  \label{fig:TCPel_close}
 \end{figure}
 
 Come per il SYN anche il FIN occupa un byte nel numero di sequenza, per cui
@@ -221,9 +220,9 @@ 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
-più avanti in \secref{sec:TCPsimp_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
+più avanti in \secref{sec:TCPsimp_echo}) 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.
@@ -268,7 +267,7 @@ ad assumere per i due lati, server e client.
 
 \begin{figure}[htb]
   \centering
-  
+  \includegraphics[width=9cm]{img/tcp_connection.eps}  
   \caption{Schema dello scambio di pacchetti per un esempio di connessione}
   \label{fig:TPCel_conn_example}
 \end{figure}
@@ -328,8 +327,8 @@ 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
-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.
+IP (per maggiori dettagli vedi \secref{sec:IP_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
 tempo di vita, si stima che un pacchetto IP non possa restare nella rete per
@@ -474,7 +473,7 @@ disposizione del kernel per gestire le relative tabelle.
 
 \begin{figure}[!htb]
   \centering
-  
+  \includegraphics[width=10cm]{img/tcpip_overview.eps}  
   \caption{Allocazione dei numeri di porta}
   \label{fig:TCPel_port_alloc}
 \end{figure}
@@ -682,18 +681,21 @@ indirizzo di origine l'indirizzo di destinazione specificato dal SYN del
 client. 
 
 Per specificare un indirizzo generico con IPv4 si usa il valore
-\texttt{INADDR\_ANY}, il cui valore, come visto anche negli esempi precedenti
+\macro{INADDR\_ANY}, il cui valore, come visto anche negli esempi precedenti
 è pari a zero, nell'esempio \figref{fig:net_serv_code} si è usata
 un'assegnazione immediata del tipo:
-\begin{verbatim}
-   serv_add.sin_addr.s_addr = htonl(INADDR_ANY);   /* connect from anywhere */
-\end{verbatim}
 
-Si noti che si è usato \texttt{htonl} per assegnare il valore
-\texttt{INADDR\_ANY}; benché essendo questo pari a zero il riordinamento sia
-inutile; ma dato che tutte le costanti \texttt{INADDR\_} sono definite
+\footnotesize
+\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
+  serv_add.sin_addr.s_addr = htonl(INADDR_ANY);   /* connect from anywhere */
+\end{lstlisting}
+\normalsize
+
+Si noti che si è usato \func{htonl} per assegnare il valore
+\macro{INADDR\_ANY}; benché essendo questo pari a zero il riordinamento sia
+inutile; ma dato che tutte le costanti \macro{INADDR\_} sono definite
 secondo l'ordinamento della macchina è buona norma usare sempre la funzione
-\texttt{htonl}.
+\macro{htonl}.
 
 L'esempio precedete funziona con IPv4 dato che l'indirizzo è rappresentabile
 anche con un intero a 32 bit; non si può usare lo stesso metodo con IPv6,
@@ -703,12 +705,14 @@ assegnazione.  Per questo nell'header \texttt{netinet/in.h} 
 variabile \texttt{in6addr\_any} (dichiarata come \texttt{extern}, ed
 inizializzata dal sistema al valore \texttt{IN6ADRR\_ANY\_INIT}) che permette
 di effettuare una assegnazione del tipo:
-\begin{verbatim}
+\footnotesize
+\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
    serv_add.sin6_addr = in6addr_any;   /* connect from anywhere */
-\end{verbatim}
+\end{lstlisting}
+\normalsize
 
 
-\subsection{La funzione \texttt{connect}}
+\subsection{La funzione \func{connect}}
 \label{sec:TCPel_func_connect}
 
 La funzione \texttt{connect} è usata da un client TCP per stabilire la
@@ -798,7 +802,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
-\figref{fig:appB:tcp_state_diag} la funzione \texttt{connect} porta un socket
+\figref{fig: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
@@ -903,7 +907,7 @@ numero di connessioni per cui un tale valore non 
 comunque una risposta univoca per la scelta del valore, per questo non
 conviene specificarlo con una costante (il cui cambiamento richiederebbe la
 ricompilazione del server) ma usare piuttosto una variabile di ambiente (vedi
-\secref{sec:xxx_env_var}).  
+\secref{sec:proc_environ}).  
 
 Lo Stevens tratta accuratamente questo argomento, con esempi presi da casi
 reali su web server, ed in particolare evidenzia come non sia più vero che il
@@ -1025,8 +1029,8 @@ l'invio dei dati.
 \subsection{La funzione \texttt{close}}
 \label{sec:TCPel_func_close}
 
-La funzione standard unix \texttt{close} (vedi \secref{sec:fileunix_close})
-che si usa sui file può essere usata con lo stesso effetto anche sui socket
+La funzione standard unix \texttt{close} (vedi \secref{sec:file_close}) che si
+usa sui file può essere usata con lo stesso effetto anche sui socket
 descriptor.
 
 L'azione standard di questa funzione quando applicata a socket è di marcarlo
@@ -1138,7 +1142,7 @@ int main(int argc, char *argv[])
   \end{lstlisting}
   \caption{Esempio di codice di un server concorrente elementare per il 
     servizio daytime.}
-  \label{fig:TCPelem_serv_code}
+  \label{fig:TCPel_serv_code}
 \end{figure}
 
 Come si può vedere (alle linee \texttt{\small 21--25}) la funzione