Corretti i commenti ai listati in una forma piu' leggibile (spero).

[gapil.git] / elemtcp.tex

diff --git a/elemtcp.tex b/elemtcp.tex
index c57bbcf6f8aa0080bd5cb92878eb8c37b59242ba..b074cb0fbb39a6712b371d3d2a440349284f9a26 100644 (file)
--- a/elemtcp.tex
+++ b/elemtcp.tex
@@ -9,7 +9,7 @@
 %% License".
 %%
 \chapter{Socket TCP}
 %% License".
 %%
 \chapter{Socket TCP}

-\label{cha:elem_TCP_sock}
+\label{cha:TCP_socket}

 
 In questo capitolo iniziamo ad approfondire la conoscenza dei socket TCP,
 iniziando con una descrizione delle principali caratteristiche del
 
 In questo capitolo iniziamo ad approfondire la conoscenza dei socket TCP,
 iniziando con una descrizione delle principali caratteristiche del


@@ -1108,7 +1108,6 @@ scritti nella struttura puntata da \param{name}. Si tenga presente che se si 
 utilizzato un buffer troppo piccolo per \param{name} l'indirizzo risulterà
 troncato.
 
 utilizzato un buffer troppo piccolo per \param{name} l'indirizzo risulterà
 troncato.
 

-

 La funzione si usa tutte le volte che si vuole avere l'indirizzo locale di un
 socket; ad esempio può essere usata da un client (che usualmente non chiama
 \func{bind}) per ottenere numero IP e porta locale associati al socket
 La funzione si usa tutte le volte che si vuole avere l'indirizzo locale di un
 socket; ad esempio può essere usata da un client (che usualmente non chiama
 \func{bind}) per ottenere numero IP e porta locale associati al socket


@@ -1146,7 +1145,8 @@ restituisce l'indirizzo remoto del socket, cio
 capo della connessione.  Ci si può chiedere a cosa serva questa funzione dato
 che dal lato client l'indirizzo remoto è sempre noto quando si esegue la
 \func{connect} mentre dal lato server si possono usare, come vedremo in
 capo della connessione.  Ci si può chiedere a cosa serva questa funzione dato
 che dal lato client l'indirizzo remoto è sempre noto quando si esegue la
 \func{connect} mentre dal lato server si possono usare, come vedremo in

-\figref{fig:TCP_cunc_serv_code}, i valori di ritorno di \func{accept}.
+\figref{fig:TCP_daytime_cunc_server_code}, i valori di ritorno di
+\func{accept}.

 
 Il fatto è che in generale quest'ultimo caso non è sempre possibile.  In
 particolare questo avviene quando il server, invece di gestire la connessione
 
 Il fatto è che in generale quest'ultimo caso non è sempre possibile.  In
 particolare questo avviene quando il server, invece di gestire la connessione


@@ -1299,11 +1299,12 @@ nell'\href{http://www.ietf.org/rfc/rfc0867.txt}{RFC~867}, che restituisce
 l'ora locale della macchina a cui si effettua la richiesta, e che è assegnato
 alla porta 13.
 
 l'ora locale della macchina a cui si effettua la richiesta, e che è assegnato
 alla porta 13.
 

-In \figref{fig:TCP_cli_code} è riportata la sezione principale del codice del
-nostro client. Il sorgente completo del programma (\file{TCP_daytime.c}, che
-comprende il trattamento delle opzioni ed una funzione per stampare un
-messaggio di aiuto) è allegato alla guida nella sezione dei codici sorgente e
-può essere compilato su una qualunque macchina GNU/Linux.
+In \figref{fig:TCP_daytime_client_code} è riportata la sezione principale del
+codice del nostro client. Il sorgente completo del programma
+(\file{TCP\_daytime.c}, che comprende il trattamento delle opzioni ed una
+funzione per stampare un messaggio di aiuto) è allegato alla guida nella
+sezione dei codici sorgente e può essere compilato su una qualunque macchina
+GNU/Linux.

 
 \begin{figure}[!htb]
   \footnotesize \centering
 
 \begin{figure}[!htb]
   \footnotesize \centering


@@ -1350,9 +1351,10 @@ ritorna (\texttt{\small 31}).
 
 Completata con successo la connessione il passo successivo (\texttt{\small
   34--40}) è leggere la data dal socket; il protocollo prevede che il server
 
 Completata con successo la connessione il passo successivo (\texttt{\small
   34--40}) è leggere la data dal socket; il protocollo prevede che il server

-invii sempre una stringa alfanumerica di 26 caratteri, nella forma giorno
-della settimana, mese, ora minuto e secondo, anno, seguita dai caratteri di
-terminazione \verb|\r\n|, cioè qualcosa del tipo:
+invii sempre una stringa alfanumerica, il formato della stringa non è
+specificato dallo standard, per cui noi useremo il formato usato dalla
+funzione \func{ctime}, seguito dai caratteri di terminazione \verb|\r\n|, cioè
+qualcosa del tipo:

 \begin{verbatim}
 Wed Apr 4 00:53:00 2001\r\n
 \end{verbatim}
 \begin{verbatim}
 Wed Apr 4 00:53:00 2001\r\n
 \end{verbatim}


@@ -1399,7 +1401,7 @@ elementare, che sia anche in grado di rispondere al precedente client. Come
 primo esempio realizzeremo un server iterativo, in grado di fornire una sola
 risposta alla volta. Il codice del programma è nuovamente mostrato in
 \figref{fig:TCP_daytime_iter_server_code}, il sorgente completo
 primo esempio realizzeremo un server iterativo, in grado di fornire una sola
 risposta alla volta. Il codice del programma è nuovamente mostrato in
 \figref{fig:TCP_daytime_iter_server_code}, il sorgente completo

-(\file{TCP_iter_daytimed.c}) è allegato insieme agli altri file degli esempi.
+(\file{TCP\_iter\_daytimed.c}) è allegato insieme agli altri file degli esempi.

 
 \begin{figure}[!htbp]
   \footnotesize \centering
 
 \begin{figure}[!htbp]
   \footnotesize \centering


@@ -1477,36 +1479,37 @@ non 
 \subsection{Un server \textit{daytime} concorrente}
 \label{sec:TCP_daytime_cunc_server}
 
 \subsection{Un server \textit{daytime} concorrente}
 \label{sec:TCP_daytime_cunc_server}
 

-Il server \texttt{daytime} dell'esempio in \secref{sec:TCP_daytime_client} è un
-tipico esempio di server iterativo, in cui viene servita una richiesta alla
-volta; in generale però, specie se il servizio è più complesso e comporta uno
-scambio di dati più sostanzioso di quello in questione, non è opportuno
-bloccare un server nel servizio di un client per volta; per questo si ricorre
-alle capacità di multitasking del sistema.
+Il server \texttt{daytime} dell'esempio in
+\secref{sec:TCP_daytime_iter_server} è un tipico esempio di server iterativo,
+in cui viene servita una richiesta alla volta; in generale però, specie se il
+servizio è più complesso e comporta uno scambio di dati più sostanzioso di
+quello in questione, non è opportuno bloccare un server nel servizio di un
+client per volta; per questo si ricorre alle capacità di multitasking del
+sistema.

 
 Come accennato anche in \secref{sec:proc_gen} una delle modalità più comuni di
 funzionamento da parte dei server è quella di usare la funzione \func{fork}
 per creare, ad ogni richiesta da parte di un client, un processo figlio che si
 incarichi della gestione della comunicazione.  Si è allora riscritto il server
 
 Come accennato anche in \secref{sec:proc_gen} una delle modalità più comuni di
 funzionamento da parte dei server è quella di usare la funzione \func{fork}
 per creare, ad ogni richiesta da parte di un client, un processo figlio che si
 incarichi della gestione della comunicazione.  Si è allora riscritto il server

-\texttt{daytime} dell'esempio precedente in forma concorrente, inserendo anche
+\textit{daytime} dell'esempio precedente in forma concorrente, inserendo anche

 una opzione per la stampa degli indirizzi delle connessioni ricevute.
 
 una opzione per la stampa degli indirizzi delle connessioni ricevute.
 

-In \figref{fig:TCP_cunc_serv_code} è mostrato un estratto del codice, in cui
-si sono tralasciati il trattamento delle opzioni e le parti rimaste invariate
-rispetto al precedente esempio (cioè tutta la parte riguardante l'apertura
-passiva del socket). Al solito il sorgente completo del server, nel file
-\file{ElemDaytimeTCPCuncServ.c}, è allegato insieme ai sorgenti degli altri
-esempi.
+In \figref{fig:TCP_daytime_cunc_server_code} è mostrato un estratto del
+codice, in cui si sono tralasciati il trattamento delle opzioni e le parti
+rimaste invariate rispetto al precedente esempio (cioè tutta la parte
+riguardante l'apertura passiva del socket). Al solito il sorgente completo del
+server, nel file \file{TCP\_cunc\_daytimed.c}, è allegato insieme ai sorgenti
+degli altri esempi.

 
 \begin{figure}[!htb]
   \footnotesize \centering
   \begin{minipage}[c]{15cm}
 
 \begin{figure}[!htb]
   \footnotesize \centering
   \begin{minipage}[c]{15cm}

-    \includecodesample{listati/ElemDaytimeTCPCuncServ.c}
+    \includecodesample{listati/TCP_cunc_daytimed.c}

   \end{minipage} 
   \normalsize
   \caption{Esempio di codice di un server concorrente elementare per il 
     servizio daytime.}
   \end{minipage} 
   \normalsize
   \caption{Esempio di codice di un server concorrente elementare per il 
     servizio daytime.}

-  \label{fig:TCP_cunc_serv_code}
+  \label{fig:TCP_daytime_cunc_server_code}

 \end{figure}
 
 Stavolta (\texttt{\small 21--25}) la funzione \func{accept} è chiamata
 \end{figure}
 
 Stavolta (\texttt{\small 21--25}) la funzione \func{accept} è chiamata


@@ -1577,6 +1580,7 @@ torneremo su questo pi
 complessi.
 
 
 complessi.
 
 

+

 \section{Un esempio più completo: il servizio \textit{echo}}
 \label{sec:TCP_echo_application}
 
 \section{Un esempio più completo: il servizio \textit{echo}}
 \label{sec:TCP_echo_application}
 


@@ -1587,54 +1591,58 @@ un po' pi
 le direzioni, implementando il servizio standard \textit{echo}, così come
 definito dall'\href{http://www.ietf.org/rfc/rfc0862.txt}{RFC~862}.  
 
 le direzioni, implementando il servizio standard \textit{echo}, così come
 definito dall'\href{http://www.ietf.org/rfc/rfc0862.txt}{RFC~862}.  
 

-Si è scelto di usare questo servizio, seguendo l'esempio di \cite{UNP1},
-perché costituisce il prototipo ideale di una generica applicazione di rete in
-cui un server risponde alle richieste di un client; nel caso di una
-applicazione più complessa si potrà avere in più una elaborazione dell'input
-del client da parte del server nel fornire le risposte in uscita.
+Si è scelto, seguendo l'esempio di \cite{UNP1}, di usare questo servizio, che
+si limita a restituire in uscita quanto immesso in ingresso, perché nonostante
+la sua estrema semplicità costituisce il prototipo ideale di una generica
+applicazione di rete in cui un server risponde alle richieste di un client;
+nel caso di una applicazione più complessa si potrà avere in più una
+elaborazione dell'input del client da parte del server nel fornire le risposte
+in uscita.

 
 

-Ci limiteremo ad un esempio elementare, che usi solo le funzioni di base, ma
-prenderemo in esame, oltre al comportamento in condizioni normali, anche tutti
-i possibili scenari particolari (errori, sconnessione della rete, crash del
-client o del server durante la connessione) che possono avere luogo durante
-l'impiego di un'applicazione di rete.  
+Ci limiteremo per ora ad una implementazione elementare, che usi solo le
+funzioni di base, ma prenderemo in esame, oltre al comportamento in condizioni
+normali, anche tutti i possibili scenari particolari (errori, sconnessione
+della rete, crash del client o del server durante la connessione) che possono
+avere luogo durante l'impiego di un'applicazione di rete, partendo da una
+versione primitiva che dovrà essere rimaneggiata di volta in volta per poter
+tenere conto di tutte le evenienze che si possono manifestare nella vita reale
+di un'applicazione di rete, fino ad arrivare ad un'implementazione completa.

 
 

-Partiremo da un'implementazione elementare che dovrà essere rimaneggiata di
-volta in volta per poter tenere conto di tutte le evenienze che si possono
-manifestare nella vita reale di un'applicazione di rete, fino ad arrivare ad
-un'implementazione completa.

 
 \subsection{Il client: prima versione}
 \label{sec:TCP_echo_client}
 
 
 \subsection{Il client: prima versione}
 \label{sec:TCP_echo_client}
 

-Il codice del client è riportato in \figref{fig:TCPsimpl_client_elem}, anche
-esso ricalca la struttura del precedente client per il servizio
-\texttt{daytime} (vedi \secref{sec:TCP_daytime_client}) ma, come per il
-server, lo si è diviso in due parti, inserendo la parte relativa alle
-operazioni specifiche previste per il protocollo \textit{echo} in una funzione
-a parte.
+Il codice della prima versione client per il servizio \textit{echo} è
+riportato in \figref{fig:TCP_echo_client_1}. Esso ricalca la struttura del
+precedente client per il servizio \textit{daytime} (vedi
+\secref{sec:TCP_daytime_client}), e la prima parte (\texttt{\small 10--27}) è
+sostanzialmente identica, a parte l'uso di una porta diversa.

 
 \begin{figure}[!htb]
   \footnotesize \centering
   \begin{minipage}[c]{15.6 cm}
 
 \begin{figure}[!htb]
   \footnotesize \centering
   \begin{minipage}[c]{15.6 cm}

-    \includecodesample{listati/EchoServerWrong.c}
+    \includecodesample{listati/TCP_echo_client.c}

   \end{minipage} 
   \normalsize
   \caption{Codice della prima versione del client \textit{echo}.}
   \end{minipage} 
   \normalsize
   \caption{Codice della prima versione del client \textit{echo}.}

-  \label{fig:TCPsimpl_client_elem}
+  \label{fig:TCP_echo_client_1}

 \end{figure}
 
 \end{figure}
 

-La funzione \code{main} si occupa della creazione del socket e della
-connessione (linee \texttt{\small 10--27}) secondo la stessa modalità spiegata
-in \secref{sec:TCP_daytime_client}, il client si connette sulla porta 7
-all'indirizzo specificato dalla linea di comando (a cui si è aggiunta una
-elementare gestione delle opzioni non riportata in figura).
-
-Completata la connessione, al ritorno di \func{connect}, la funzione
-\code{ClientEcho}, riportata in \figref{fig:TCPsimpl_client_echo_sub}, si
-preoccupa di gestire la comunicazione, leggendo una riga alla volta dallo
-\file{stdin}, scrivendola sul socket e ristampando su \file{stdout} quanto
-ricevuto in risposta dal server.
+Al solito si è tralasciata la sezione relativa alla gestione delle opzioni a
+riga di comando; una volta dichiarate le variabili, si prosegue
+(\texttt{\small 10--13}) con della creazione del socket, la preparazione
+(\texttt{\small 14--17}) la struttura per l'indirizzo, con la relativa
+conversione (\texttt{\small 18--22}) di quanto specificato a riga di comando.
+
+A questo punto (\texttt{\small 23--27}) si può eseguire la connessione al
+server secondo la stessa modalità usata in \secref{sec:TCP_daytime_client}.
+Completata la connessione, al ritorno di \func{connect}, si usa la funzione
+\code{ClientEcho}, il cui codice è riportato in
+\figref{fig:TCPsimpl_client_echo_sub}. Questa si preoccupa di gestire tutta la
+comunicazione, leggendo una riga alla volta dallo standard input \file{stdin},
+scrivendola sul socket e ristampando su \file{stdout} quanto ricevuto in
+risposta dal server. Al ritorno dalla funzione (\texttt{\small 30--31}) anche
+il programma termina.

 
 \begin{figure}[!htb]
   \footnotesize \centering
 
 \begin{figure}[!htb]
   \footnotesize \centering


@@ -1647,27 +1655,28 @@ ricevuto in risposta dal server.
   \label{fig:TCPsimpl_client_echo_sub}
 \end{figure}
 
   \label{fig:TCPsimpl_client_echo_sub}
 \end{figure}
 

-La funzione utilizza due buffer per gestire i dati inviati e letti sul socket
-(\texttt{\small 3}).  La comunicazione viene gestita all'interno di un ciclo
-(linee \texttt{\small 5--10}), i dati da inviare sulla connessione vengono
-presi dallo \file{stdin} usando la funzione \func{fgets} che legge una
-linea di testo (terminata da un \texttt{CR} e fino al massimo di
-\const{MAXLINE} caratteri) e la salva sul buffer di invio, la funzione
-\func{FullWrite} (\texttt{\small 3}) scrive detti dati sul socket (gestendo
-l'invio multiplo qualora una singola \func{write} non basti, come spiegato
-in \secref{sec:sock_io_behav}).
+La funzione \code{ClientEcho} utilizza due buffer (\texttt{\small 3}) per
+gestire i dati inviati e letti sul socket.  La comunicazione viene gestita
+all'interno di un ciclo (\texttt{\small 5--10}), i dati da inviare sulla
+connessione vengono presi dallo \file{stdin} usando la funzione \func{fgets},
+trattata in \secref{sec:file_line_io}, che legge una linea di testo (terminata
+da un \texttt{CR} e fino al massimo di \const{MAXLINE} caratteri) e la salva
+sul buffer di invio, la funzione \func{FullWrite}, già vista in
+\figref{fig:sock_FullWrite_code}, scrive (\texttt{\small 6}) i dati sul socket
+(gestendo l'invio multiplo qualora una singola \func{write} non basti, come
+spiegato in \secref{sec:sock_io_behav}).

 
 

-I dati che vengono riletti indietro con una \func{FullRead} sul buffer di
-ricezione e viene inserita la terminazione della stringa (\texttt{\small
-  7--8}) e per poter usare la funzione \func{fputs} per scriverli su
-\file{stdout}. 
+I dati vengono riletti indietro (\texttt{\small 7}) con una \func{FullRead}
+sul buffer di ricezione e viene inserita (\texttt{\small 8}) la terminazione
+della stringa e per poter usare (\texttt{\small 9}) la funzione \func{fputs}
+per scriverli su \file{stdout}.

 
 

-Un end of file inviato su \file{stdin} causa il ritorno di \func{fgets}
-con un puntatore nullo e l'uscita dal ciclo, al che la subroutine ritorna ed
-il client esce.
+Un end-of-file inviato su \file{stdin} (ad esempio con la pressione di
+\texttt{C-d}) causa il ritorno di \func{fgets} con un puntatore nullo e la
+conseguente uscita dal ciclo, al che la subroutine ritorna ed il client esce.

 
 
 
 

-\subsection{La struttura del server}
+\subsection{Il server: prima versione}

 \label{sec:TCPsimp_server_main}
 
 Il servizio \textit{echo} è uno dei servizi standard solitamente provvisti
 \label{sec:TCPsimp_server_main}
 
 Il servizio \textit{echo} è uno dei servizi standard solitamente provvisti


@@ -1705,7 +1714,7 @@ nel precedente esempio esaminato in \secref{sec:TCP_daytime_cunc_server}.
 La struttura di questa prima versione del server è sostanzialmente identica a
 quella dell'esempio citato, ed ad esso si applicano le considerazioni fatte in
 \secref{sec:TCP_daytime_cunc_server}. Le uniche differenze rispetto
 La struttura di questa prima versione del server è sostanzialmente identica a
 quella dell'esempio citato, ed ad esso si applicano le considerazioni fatte in
 \secref{sec:TCP_daytime_cunc_server}. Le uniche differenze rispetto

-all'esempio in \figref{fig:TCP_daytime_iter_server_code} sono che in questo
+all'esempio in \figref{fig:TCP_daytime_cunc_server_code} sono che in questo

 caso per il socket in ascolto viene usata la porta 7 e che tutta la gestione
 della comunicazione è delegata alla funzione \code{ServEcho}.
 %  Per ogni connessione viene creato un
 caso per il socket in ascolto viene usata la porta 7 e che tutta la gestione
 della comunicazione è delegata alla funzione \code{ServEcho}.
 %  Per ogni connessione viene creato un