Sistemati i riferimenti

[gapil.git] / elemtcp.tex

diff --git a/elemtcp.tex b/elemtcp.tex
index 50d8994d103814fbee5ea5cbb21a783de907cfa8..9cfcb35fc356cfdfca660d1f7fff2638c244cbdb 100644 (file)
--- a/elemtcp.tex
+++ b/elemtcp.tex
@@ -8,16 +8,12 @@ nei due esempi elementari forniti in precedenza (vedi
 descrizione delle principali caratteristiche del funzionamento di una
 connessione TCP.
 
 descrizione delle principali caratteristiche del funzionamento di una
 connessione TCP.
 

-Infine riscriveremo il precedente esempio elementare di server
-\texttt{daytime} in una forma appena più evoluta (come server concorrente) e
-con alcune caratteristiche aggiuntive che mettano in luce quanto andremo ad
-illustrare.

 
 \section{Il funzionamento di una connessione TCP}
 \label{sec:TCPel_connession}
 
 Prima di entrare nei dettagli delle funzioni usate nelle applicazioni che
 
 \section{Il funzionamento di una connessione TCP}
 \label{sec:TCPel_connession}
 
 Prima di entrare nei dettagli delle funzioni usate nelle applicazioni che

-utilizzano i socket TCP, è fondamentale spiegare alcune basi del funzionamento
+utilizzano i sokcet TCP, è fondamentale spiegare alcune basi del funzionamento

 del TCP; la conoscenza del funzionamento del protocollo è infatti essenziale
 per capire il modello di programmazione ed il funzionamento delle API.
 
 del TCP; la conoscenza del funzionamento del protocollo è infatti essenziale
 per capire il modello di programmazione ed il funzionamento delle API.
 


@@ -90,7 +86,7 @@ la connessione.
 
 \begin{figure}[htb]
   \centering
 
 \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}
   \caption{Il \textit{three way handshake} del TCP}
   \label{fig:TCPel_TWH}
 \end{figure}


@@ -192,7 +188,6 @@ seguente:
   con un ACK.
 \end{enumerate}
 
   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 è
 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 è


@@ -201,10 +196,10 @@ accorpati in un singolo segmento. In \nfig\ si 
 sequenza di scambio dei segmenti che stabilisce la connessione.
 
 \begin{figure}[htb]
 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
 \end{figure}
 
 Come per il SYN anche il FIN occupa un byte nel numero di sequenza, per cui


@@ -225,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
 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.
 \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.


@@ -272,7 +267,7 @@ ad assumere per i due lati, server e client.
 
 \begin{figure}[htb]
   \centering
 
 \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}
   \caption{Schema dello scambio di pacchetti per un esempio di connessione}
   \label{fig:TPCel_conn_example}
 \end{figure}


@@ -332,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
 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
 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


@@ -478,7 +473,7 @@ disposizione del kernel per gestire le relative tabelle.
 
 \begin{figure}[!htb]
   \centering
 
 \begin{figure}[!htb]
   \centering

-  
+  \includegraphics[width=10cm]{img/tcpip_overview.eps}  

   \caption{Allocazione dei numeri di porta}
   \label{fig:TCPel_port_alloc}
 \end{figure}
   \caption{Allocazione dei numeri di porta}
   \label{fig:TCPel_port_alloc}
 \end{figure}


@@ -802,7 +797,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

-\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
 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


@@ -907,7 +902,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
 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
 
 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


@@ -1029,8 +1024,8 @@ l'invio dei dati.
 \subsection{La funzione \texttt{close}}
 \label{sec:TCPel_func_close}
 
 \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
 descriptor.
 
 L'azione standard di questa funzione quando applicata a socket è di marcarlo


@@ -1071,8 +1066,7 @@ parte di un client un processo figlio che si incarichi della gestione della
 comunicazione.
 
 
 comunicazione.
 
 

-
-\subsection{Un esempio di server \textit{daytime}}
+\subsection{Un esempio di server \textit{daytime} concorrente}

 \label{sec:TCPel_cunc_daytime}
 
 Per illustrare il meccanismo usato in generale per creare un server
 \label{sec:TCPel_cunc_daytime}
 
 Per illustrare il meccanismo usato in generale per creare un server


@@ -1143,7 +1137,7 @@ int main(int argc, char *argv[])
   \end{lstlisting}
   \caption{Esempio di codice di un server concorrente elementare per il 
     servizio daytime.}
   \end{lstlisting}
   \caption{Esempio di codice di un server concorrente elementare per il 
     servizio daytime.}

-  \label{fig:net_cli_code}
+  \label{fig:TCPel_serv_code}

 \end{figure}
 
 Come si può vedere (alle linee \texttt{\small 21--25}) la funzione
 \end{figure}
 
 Come si può vedere (alle linee \texttt{\small 21--25}) la funzione


@@ -1243,27 +1237,32 @@ quella connessione.
 La funzione \texttt{getpeername} si usa tutte le volte che si vuole avere
 l'indirizzo remoto di un socket. 
 
 La funzione \texttt{getpeername} si usa tutte le volte che si vuole avere
 l'indirizzo remoto di un socket. 
 

-Benché nell'esempio precedente si siano usati i valori di ritorno di
-\texttt{accept} per ottenere l'indirizzo del client remoto, in generale questo
-non è possibile. In particolare questo avviene quando il server invece di far
-gestire la connessione direttamente al figlio, come nell'esempio precedente,
-lancia un opportuno programma per ciascuna connessione usando \texttt{exec}
-(come ad esempio fa il \textsl{super-server} \texttt{inetd} che gestisce tutta
-una serie di servizi lanciando per ogni connessione l'opportuno server).
+Ci si può chiedere a cosa serva questa funzione dato che dal lato client
+l'indirizzo remoto è sempre noto quando si esegue la \texttt{connect} mentre
+dal lato server si possono usare, come si è fatto nell'esempio precedente, i
+valori di ritorno di \texttt{accept}.
+
+In generale però questa ultima possibilità è sempre possibile. In particolare
+questo avviene quando il server invece di far gestire la connessione
+direttamente a un processo figlio, come nell'esempio precedente, lancia un
+opportuno programma per ciascuna connessione usando \texttt{exec} (questa ad
+esempio è la modailità con cui opera il \textsl{super-server} \texttt{inetd}
+che gestisce tutta una serie di servizi lanciando per ogni connessione
+l'opportuno server).

 
 In questo caso benché il processo figlio abbia una immagine della memoria che
 è copia di quella del processo padre (e contiene quindi anche la struttura
 
 In questo caso benché il processo figlio abbia una immagine della memoria che
 è copia di quella del processo padre (e contiene quindi anche la struttura

-ritornata da \texttt{accept}) all'esecuzione di \texttt{exec} viene caricata
+ritornata da \texttt{accept}), all'esecuzione di \texttt{exec} viene caricata

 in memoria l'immagine del programma eseguito che a questo punto perde ogni
 in memoria l'immagine del programma eseguito che a questo punto perde ogni

-riferimento; ma il socket descriptor resta aperto. Allora se una opportuna
+riferimento. Il socket descriptor però resta aperto. Allora se una opportuna

 convenzione è seguita per rendere noto al programma eseguito qual'è il socket
 connesso (\texttt{inetd} ad esempio fa sempre in modo che i file descriptor 0,
 convenzione è seguita per rendere noto al programma eseguito qual'è il socket
 connesso (\texttt{inetd} ad esempio fa sempre in modo che i file descriptor 0,

-1 e 2 corrispondano al socket connesso) quest'ultimo potrà usare
+1 e 2 corrispondano al socket connesso) quest'ultimo potrà usare la funzione

 \texttt{getpeername} per determinare l'indirizzo remoto del client.
 
 \texttt{getpeername} per determinare l'indirizzo remoto del client.
 

-Infine è da chiarire che come per \texttt{accept} il terzo parametro che è
-specificato dallo standard POSIX 1003.1g come di tipo \texttt{socklen\_t *} in
-realtà deve sempre corrispondere ad un \texttt{int *} come prima dello
-standard perché tutte le implementazioni dei socket BSD fanno questa
-assunzione.
+Infine è da chiarire (si legga la man page) che come per \texttt{accept} il
+terzo parametro che è specificato dallo standard POSIX 1003.1g come di tipo
+\texttt{socklen\_t *} in realtà deve sempre corrispondere ad un \texttt{int *}
+come prima dello standard perché tutte le implementazioni dei socket BSD fanno
+questa assunzione.