%% license is included in the section entitled "GNU Free Documentation
%% License".
%%
-\chapter{Socket TCP elementari}
-\label{cha:elem_TCP_sock}
+\chapter{Socket TCP}
+\label{cha:TCP_socket}
In questo capitolo iniziamo ad approfondire la conoscenza dei socket TCP,
iniziando con una descrizione delle principali caratteristiche del
\end{itemize}
La MSS è generalmente supportata da quasi tutte le implementazioni del
-protocollo, le ultime due opzioni (trattate nell'RFC~1323) sono meno comuni;
+protocollo, le ultime due opzioni (trattate
+nell'\href{http://www.ietf.org/rfc/rfc1323.txt}{RFC~1323}) sono meno comuni;
vengono anche dette \textit{long fat pipe options} dato che questo è il nome
che viene dato alle connessioni caratterizzate da alta velocità o da ritardi
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 richiede quattro; ancora una volta si può fare
-riferimento al codice degli esempi \figref{fig:TCP_cli_code} e
-\figref{fig:TCP_serv_code}, in questo caso la successione degli eventi è la
-seguente:
+riferimento al codice degli esempi \figref{fig:TCP_daytime_client_code} e
+\figref{fig:TCP_daytime_iter_server_code}, in questo caso la successione degli
+eventi è la seguente:
\begin{enumerate}
\item Un processo ad uno dei due capi chiama la funzione \func{close}, dando
\func{shutdown}.
La emissione del FIN avviene quando il socket viene chiuso, questo però non
-avviene solo per la chiamata della funzione \func{close} (come faremo in
-\figref{fig:TCP_serv_code}), ma anche alla terminazione di un processo (come
-vedremo in \figref{fig:TCP_cli_code}). Questo vuol dire ad esempio che se un
-processo viene terminato da un segnale tutte le connessioni aperte verranno
-chiuse.
+avviene solo per la chiamata esplicita della funzione \func{close}, ma anche
+alla terminazione di un processo, quando tutti i file vengono chiusi. Questo
+comporta ad esempio che se un processo viene terminato da un segnale tutte le
+connessioni aperte verranno chiuse.
Infine occorre sottolineare che, benché nella figura (e nell'esempio che
-vedremo più avanti in \secref{sec:TCPsimp_echo}) sia stato il client ad
-eseguire la chiusura attiva, nella realtà questa può essere eseguita da uno
-qualunque dei due capi della comunicazione (come nell'esempio di
-\figref{fig:TCP_serv_code}), e anche se il caso più comune resta quello del
-client, ci sono alcuni servizi, il principale dei quali è l'HTTP, per i quali
-è il server ad effettuare la chiusura attiva.
+vedremo più avanti in \secref{sec:TCP_echo}) sia stato il client ad eseguire
+la chiusura attiva, nella realtà questa può essere eseguita da uno qualunque
+dei due capi della comunicazione (come nell'esempio di
+\figref{fig:TCP_daytime_iter_server_code}), e anche se il caso più comune
+resta quello del client, 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}
limite sul tempo di vita, si stima che un pacchetto IP non possa restare nella
rete per più di MSL secondi.
-Ogni implementazione del TCP deve scegliere un valore per la MSL (l'RFC~1122
-raccomanda 2 minuti, Linux usa 30 secondi), questo comporta una durata dello
-stato \texttt{TIME\_WAIT} che a seconda delle implementazioni può variare fra
-1 a 4 minuti.
+Ogni implementazione del TCP deve scegliere un valore per la MSL
+(l'\href{http://www.ietf.org/rfc/rfc1122.txt}{RFC~1122} raccomanda 2 minuti,
+Linux usa 30 secondi), questo comporta una durata dello stato
+\texttt{TIME\_WAIT} che a seconda delle implementazioni può variare fra 1 a 4
+minuti.
Lo stato \texttt{TIME\_WAIT} viene utilizzato dal protocollo per due motivi
principali:
possibili server attivi intende parlare. Sia TCP che UDP definiscono un gruppo
di \textsl{porte conosciute} (le cosiddette \textit{well-known port}) che
identificano una serie di servizi noti (ad esempio la porta 22 identifica il
-servizio \texttt{ssh}) effettuati da appositi server che rispondono alle
+servizio \textit{ssh}) effettuati da appositi server che rispondono alle
connessioni verso tali porte.
D'altra parte un client non ha necessità di usare un numero di porta
usate solo per la durata della connessione, e l'unico requisito che deve
essere soddisfatto è che ognuna di esse sia assegnata in maniera univoca.
-La lista delle porte conosciute è definita dall'RFC~1700 che contiene l'elenco
-delle porte assegnate dalla IANA (la \textit{Internet Assigned Number
+La lista delle porte conosciute è definita
+dall'\href{http://www.ietf.org/rfc/rfc1700.txt}{RFC~1700} che contiene
+l'elenco delle porte assegnate dalla IANA (la \textit{Internet Assigned Number
Authority}) ma l'elenco viene costantemente aggiornato e pubblicato su
internet (una versione corrente si può trovare all'indirizzo
\texttt{ftp://ftp.isi.edu/in-notes/iana/assignements/port-numbers}); inoltre
sono i candidati naturali ad essere usate come porte effimere.
\end{enumerate}
-In realtà rispetto a quanto indicato nell'RFC~1700 i vari sistemi hanno fatto
-scelte diverse per le porte effimere, in particolare in
+In realtà rispetto a quanto indicato
+nell'\href{http://www.ietf.org/rfc/rfc1700.txt}{RFC~1700} i vari sistemi hanno
+fatto scelte diverse per le porte effimere, in particolare in
\figref{fig:TCP_port_alloc} sono riportate quelle di BSD e Linux. Nel caso di
Linux poi la scelta fra i due intervalli possibili viene fatta dinamicamente a
seconda della memoria a disposizione del kernel per gestire le relative
I sistemi Unix hanno inoltre il concetto di \textsl{porte riservate} (che
corrispondono alle porte con numero minore di 1024 e coincidono quindi con le
porte conosciute). La loro caratteristica è che possono essere assegnate a un
-socket solo da un processo con i privilegi di root, per far si che solo
+socket solo da un processo con i privilegi di amministratore, per far si che solo
l'amministratore possa allocare queste porte per far partire i relativi
servizi.
\label{sec:TCP_port_cliserv}
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
-\secref{sec:TCP_cunc_daytime}) esamineremo cosa accade con le connessioni nel
-caso di un server TCP che deve gestire connessioni multiple.
+che fare con un'applicazione client/server (come quelle che scriveremo in
+\secref{sec:TCP_daytime_application} e \secref{sec:TCP_echo_application})
+esamineremo cosa accade con le connessioni nel caso di un server TCP che deve
+gestire connessioni multiple.
Se eseguiamo un \cmd{netstat} su una macchina di prova (il cui indirizzo sia
\texttt{195.110.112.152}) potremo avere un risultato del tipo:
Per specificare un indirizzo generico, con IPv4 si usa il valore
\const{INADDR\_ANY}, il cui valore, come accennato in
\secref{sec:sock_sa_ipv4}, è pari a zero; nell'esempio
-\figref{fig:TCP_serv_code} si è usata un'assegnazione immediata del tipo:
-\includecodesnip{listati/serv_addr_sin_addr.c}
+\figref{fig:TCP_daytime_iter_server_code} si è usata un'assegnazione immediata
+del tipo: \includecodesnip{listati/serv_addr_sin_addr.c}
Si noti che si è usato \func{htonl} per assegnare il valore
\const{INADDR\_ANY}, anche se, essendo questo nullo, il riordinamento è
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 \secref{sec:TCP_cli_sample} usando le funzioni illustrate in
+nell'esempio \secref{sec:TCP_daytime_client}, usando le funzioni illustrate in
\secref{sec:sock_addr_func}.
Nel caso di socket TCP la funzione \func{connect} avvia il \textit{three way
si trovano automaticamente nello stato \texttt{ESTABLISHED}, e vengono
utilizzati per lo scambio dei dati, che avviene su di essi, fino alla chiusura
della connessione. Si può riconoscere questo schema anche nell'esempio
-elementare di \figref{fig:TCP_serv_code}, dove per ogni connessione il socket
-creato da \func{accept} viene chiuso dopo l'invio dei dati.
+elementare di \figref{fig:TCP_daytime_iter_server_code}, dove per ogni
+connessione il socket creato da \func{accept} viene chiuso dopo l'invio dei
+dati.
\subsection{Le funzioni \func{getsockname} e \func{getpeername}}
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
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
direttamente in un processo figlio, come vedremo nell'esempio di server
-concorrente di \ref{sec:TCP_cunc_daytime}, lancia per ciascuna connessione un
-altro programma, usando \func{exec}.\footnote{questa ad esempio è la modalità
- con cui opera il \textsl{super-server} \cmd{inetd}, che può gestire tutta
- una serie di servizi diversi, eseguendo su ogni connessione ricevuta sulle
- porte tenute sotto controllo, il relativo server.}
+concorrente di \secref{sec:TCP_daytime_cunc_server}, lancia per ciascuna
+connessione un altro programma, usando \func{exec}.\footnote{questa ad esempio
+ è la modalità con cui opera il \textsl{super-server} \cmd{inetd}, che può
+ gestire tutta una serie di servizi diversi, eseguendo su ogni connessione
+ ricevuta sulle porte tenute sotto controllo, il relativo 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
-\section{Un esempio di applicazione}
-\label{sec:TCP_application}
+\section{Un esempio elementare: il servizio \textit{daytime}}
+\label{sec:TCP_daytime_application}
Avendo introdotto le funzioni di base per la gestione dei socket, potremo
-vedere in questa sezione un esempio di applicazione elementare. Prima di
-passare agli esempi del client e del server, inizieremo riprendendo con
-maggiori dettagli una caratteristica delle funzioni di I/O, già accennata in
+vedere in questa sezione un primo esempio di applicazione elementare che
+implementa il servizio \textit{daytime} su TCP, secondo quanto specificato
+dall'\href{http://www.ietf.org/rfc/rfc0867.txt}{RFC~867}. Prima di passare
+agli esempi del client e del server, inizieremo riesaminando con maggiori
+dettagli una peculiarità delle funzioni di I/O, già accennata in
\secref{sec:file_read} e \secref{sec:file_write}, che nel caso dei socket è
-particolarmente rilevante, per poi passare agli esempi, sia di server
-iterativo, che di server concorrente.
+particolarmente rilevante. Passeremo poi ad illustrare gli esempi
+dell'implementazione, sia dal lato client, che dal lato server, che si è
+realizzato sia in forma iterativa che concorrente.
\subsection{Il comportamento delle funzioni di I/O}
problema si avverte solo quando si incontra la fine del file. In generale non
è così, e con i socket questo è particolarmente evidente.
-Quando ci si trova ad affrontare questo comportamento tutto quello che si deve
-fare è semplicemente ripetere la lettura (o la scrittura) per la quantità di
-byte restanti, tenendo conto che le funzioni si possono bloccare se i dati non
-sono disponibili: è lo stesso comportamento che si può avere scrivendo più di
-\const{PIPE\_BUF} byte in una pipe (si riveda quanto detto in
-\secref{sec:ipc_pipes}).
\begin{figure}[htb]
\footnotesize \centering
\label{fig:sock_FullRead_code}
\end{figure}
+Quando ci si trova ad affrontare questo comportamento tutto quello che si deve
+fare è semplicemente ripetere la lettura (o la scrittura) per la quantità di
+byte restanti, tenendo conto che le funzioni si possono bloccare se i dati non
+sono disponibili: è lo stesso comportamento che si può avere scrivendo più di
+\const{PIPE\_BUF} byte in una pipe (si riveda quanto detto in
+\secref{sec:ipc_pipes}).
+
Per questo motivo, seguendo l'esempio di R. W. Stevens in \cite{UNP1}, si sono
definite due funzioni, \func{FullRead} e \func{FullWrite}, che eseguono
lettura e scrittura tenendo conto di questa caratteristica, ed in grado di
pertanto si ritorna senza aver concluso la lettura di tutti i byte richiesti.
-\subsection{Un primo esempio di client}
-\label{sec:TCP_cli_sample}
+\subsection{Il client \textit{daytime}}
+\label{sec:TCP_daytime_client}
-Il primo esempio di applicazione delle funzioni viste finora è relativo alla
-creazione di un client elementare per il servizio \textit{daytime}, un
-servizio standard che restituisce l'ora locale della macchina a cui si
-effettua la richiesta, e che è assegnato alla porta 13.
+Il primo esempio di applicazione delle funzioni di base illustrate in
+precedenza è relativo alla creazione di un client elementare per il servizio
+\textit{daytime}, un servizio elementare, definito
+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.
-In \figref{fig:TCP_cli_code} è riportata la sezione principale del codice del
-nostro client. Il sorgente completo del programma
-(\file{ElemDaytimeTCPClient.c}, che comprende il trattamento delle opzioni ed
-una funzione per stampare un messaggio di aiuto) è allegato alla guida nella
+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{minipage}[c]{15cm}
- \includecodesample{listati/ElemDaytimeTCPClient.c}
+ \includecodesample{listati/TCP_daytime.c}
\end{minipage}
\normalsize
- \caption{Esempio di codice di un client elementare per il servizio daytime.}
- \label{fig:TCP_cli_code}
+ \caption{Esempio di codice di un client elementare per il servizio
+ \textit{daytime}.}
+ \label{fig:TCP_daytime_client_code}
\end{figure}
Il programma anzitutto (\texttt{\small 1--5}) include gli header necessari;
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}
e come si vede tutto funziona regolarmente.
-\subsection{Un primo esempio di server}
-\label{sec:TCP_serv_sample}
+\subsection{Un server \textit{daytime} iterativo}
+\label{sec:TCP_daytime_iter_server}
Dopo aver illustrato il client daremo anche un esempio di un server
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_serv_code}, il sorgente completo
-(\file{ElemDaytimeTCPServer.c}) è allegato insieme agli altri file degli
-esempi.
+\figref{fig:TCP_daytime_iter_server_code}, il sorgente completo
+(\file{TCP\_iter\_daytimed.c}) è allegato insieme agli altri file degli esempi.
\begin{figure}[!htbp]
\footnotesize \centering
\begin{minipage}[c]{15cm}
- \includecodesample{listati/ElemDaytimeTCPServer.c}
+ \includecodesample{listati/TCP_iter_daytimed.c}
\end{minipage}
\normalsize
\caption{Esempio di codice di un semplice server per il servizio daytime.}
- \label{fig:TCP_serv_code}
+ \label{fig:TCP_daytime_iter_server_code}
\end{figure}
Come per il client si includono (\texttt{\small 1--9}) gli header necessari a
non è necessario preoccuparsi di gestire la loro terminazione.
-\subsection{Un esempio di server \textit{daytime} concorrente}
-\label{sec:TCP_cunc_daytime}
+\subsection{Un server \textit{daytime} concorrente}
+\label{sec:TCP_daytime_cunc_server}
-Il server \texttt{daytime} dell'esempio in \secref{sec:TCP_cli_sample} è 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
-\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.
-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}
- \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.}
- \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
complessi.
+
+\section{Un esempio più completo: il servizio \textit{echo}}
+\label{sec:TCP_echo_application}
+
+L'esempio precedente, basato sul servizio \textit{daytime}, è un esempio molto
+elementare, in cui il flusso dei dati va solo nella direzione dal server al
+client. In questa sezione esamineremo un esempio di applicazione client/server
+un po' più complessa, che usi i socket TCP per una comunicazione in entrambe
+le direzioni.
+
+Ci limiteremo a fornire una implementazione elementare, che usi solo le
+funzioni di base viste finora, 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.
+
+
+\subsection{Il servizio \textit{echo}}
+\label{sec:TCP_echo}
+
+
+Nella ricerca di un servizio che potesse fare da esempio per una comunicazione
+bidirezionale, si è deciso, seguendo la scelta di Stevens in \cite{UNP1}, di
+usare il servizio \textit{echo}, che si limita a restituire in uscita quanto
+immesso in ingresso. Infatti, nonostante la sua estrema semplicità, questo
+servizio costituisce il prototipo ideale per una generica applicazione di rete
+in cui un server risponde alle richieste di un client. Nel caso di una
+applicazione più complessa quello che si potrà avere in più è una elaborazione
+dell'input del client, che in molti casi viene interpretato come un comando,
+da parte di un server che risponde fornendo altri dati in uscita.
+
+Il servizio \textit{echo} è uno dei servizi standard solitamente provvisti
+direttamente dal superserver \cmd{inetd}, ed è definito
+dall'\href{http://www.ietf.org/rfc/rfc0862.txt}{RFC~862}. Come dice il nome il
+servizio deve riscrivere indietro sul socket i dati che gli vengono inviati in
+ingresso. L'RFC descrive le specifiche del servizio sia per TCP che UDP, e per
+il primo stabilisce che una volta stabilita la connessione ogni dato in
+ingresso deve essere rimandato in uscita fintanto che il chiamante non ha
+chiude la connessione. Al servizio è assegnata la porta riservata 7.
+
+Nel nostro caso l'esempio sarà costituito da un client che legge una linea di
+caratteri dallo standard input e la scrive sul server. A sua volta il server
+leggerà la linea dalla connessione e la riscriverà immutata all'indietro. Sarà
+compito del client leggere la risposta del server e stamparla sullo standard
+output.
+
+
+\subsection{Il client: prima versione}
+\label{sec:TCP_echo_client}
+
+Il codice della prima versione del client per il servizio \textit{echo},
+disponibile nel file \file{TCP\_echo1.c}, è 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}
+ \includecodesample{listati/TCP_echo1.c}
+ \end{minipage}
+ \normalsize
+ \caption{Codice della prima versione del client \textit{echo}.}
+ \label{fig:TCP_echo_client_1}
+\end{figure}
+
+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 con l'usuale controllo
+degli errori, alla preparazione (\texttt{\small 14--17}) della struttura
+dell'indirizzo, che stavolta usa la porta 7 riservata al servizio
+\textit{echo}, infine si converte (\texttt{\small 18--22}) l'indirizzo
+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, per gestire il funzionamento del protocollo si usa
+la funzione \code{ClientEcho}, il cui codice si è riportato a parte in
+\figref{fig:TCP_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.
+
+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},
+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.
+
+Si usa poi (\texttt{\small 6}) la funzione \func{FullWrite}, vista in
+\secref{sec:sock_io_behav}, per scrivere i dati sul socket, gestendo
+automaticamente l'invio multiplo qualora una singola \func{write} non sia
+sufficiente. 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}.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15.6cm}
+ \includecodesample{listati/ClientEcho.c}
+ \end{minipage}
+ \normalsize
+ \caption{Codice della prima versione della funzione \texttt{ClientEcho} per
+ la gestione del servizio \textit{echo}.}
+ \label{fig:TCP_client_echo_sub}
+\end{figure}
+
+Quando si concluderà l'invio di dati mandando un end-of-file sullo standard
+input si avrà il ritorno di \func{fgets} con un puntatore nullo (si riveda
+quanto spiegato in \secref{sec:file_line_io}) e la conseguente uscita dal
+ciclo; al che la subroutine ritorna ed il nostro programma client termina.
+
+Si può effettuare una verifica del funzionamento del client abilitando il
+servizio \textit{echo} nella configurazione di \cmd{initd} sulla propria
+macchina ed usandolo direttamente verso di esso in locale, vedremo in
+dettaglio più avanti (in \secref{sec:TCP_echo_startup}) il funzionamento del
+programma, usato però con la nostra versione del server \textit{echo}, che
+illustriamo immediatamente.
+
+
+\subsection{Il server: prima versione}
+\label{sec:TCPsimp_server_main}
+
+La prima versione del server, contenuta nel file \file{TCP\_echod.c}, è
+riportata in \figref{fig:TCP_echo_server_code}. Come abbiamo fatto per il
+client anche il server è stato diviso in un corpo principale, costituito dalla
+funzione \code{main}, che è molto simile a quello visto nel precedente esempio
+per il server del servizio \textit{daytime} di
+\secref{sec:TCP_daytime_cunc_server}, e da una funzione ausiliaria
+\code{ServEcho} che si cura della gestione del servizio.
+
+\begin{figure}[!htbp]
+ \footnotesize \centering
+ \begin{minipage}[c]{15.6cm}
+ \includecodesample{listati/TCP_echod.c}
+ \end{minipage}
+ \normalsize
+ \caption{Codice del corpo principale della prima versione del server
+ per il servizio \textit{echo}.}
+ \label{fig:TCP_echo_server_code}
+\end{figure}
+
+In questo caso però, rispetto a quanto visto nell'esempio di
+\figref{fig:TCP_daytime_cunc_server_code} si è preferito scrivere il server
+curando maggiormente alcuni dettagli, per tenere conto anche di alcune
+esigenze generali (che non riguardano direttamente la rete), come la
+possibilità di lanciare il server anche in modalità interattiva e la cessione
+dei privilegi di amministratore non appena questi non sono più necessari.
+
+La sezione iniziale del programma (\texttt{\small 8--21}) è la stessa del
+server di \secref{sec:TCP_daytime_cunc_server}, ed ivi descritta in dettaglio:
+crea il socket, inizializza l'indirizzo e esegue \func{bind}; dato che
+quest'ultima funzione viene usata su una porta riservata, il server dovrà
+essere eseguito da un processo con i privilegi di amministratore, pena il
+fallimento della chiamata.
+
+Una volta eseguita la funzione \func{bind} però i privilegi di amministratore
+non sono più necessari, per questo è sempre opportuno rilasciarli, in modo da
+evitare problemi in caso di eventuali vulnerabilità del server. Per questo
+prima (\texttt{\small 22--26}) si esegue \func{setgid} per assegnare il
+processo ad un gruppo senza privilegi,\footnote{si è usato il valore 65534,
+ ovvero -1 per il formato \ctyp{short}, che di norma in tutte le
+ distribuzioni viene usato per identificare il gruppo \texttt{nogroup} e
+ l'utente \texttt{nobody}, usati appunto per eseguire programmi che non
+ richiedono nessun privilegio particolare.} e poi si ripete (\texttt{\small
+ 27--30}) l'operazione usando \func{setuid} per cambiare anche
+l'utente.\footnote{si tenga presente che l'ordine in cui si eseguono queste
+ due operazioni è importante, infatti solo avendo i privilegi di
+ amministratore si può cambiare il gruppo di un processo ad un'altro di cui
+ non si fa parte, per cui chiamare prima \func{setuid} farebbe fallire una
+ successiva chiamata a \func{setgid}. Inoltre si ricordi (si riveda quanto
+ esposto in \secref{sec:proc_perms}) che usando queste due funzioni il
+ rilascio dei privilegi è irreversibile.} Infine (\texttt{\small 30--36}),
+qualora sia impostata la variabile \var{demonize}, prima (\texttt{\small 31})
+si apre il sistema di logging per la stampa degli errori, e poi
+(\texttt{\small 32--35}) si invoca \func{daemon} per eseguire in background il
+processo come demone.
+
+A questo punto il programma riprende di nuovo lo schema già visto usato dal
+server per il servizio \textit{daytime}, con l'unica differenza della chiamata
+alla funzione \code{PrintErr}, riportata in \figref{fig:TCP_PrintErr}, al
+posto di \func{perror} per la stampa degli errori.
+
+Si inizia con il porre (\texttt{\small 37--41}) in ascolto il socket, e poi si
+esegue indefinitamente il ciclo principale (\texttt{\small 42--58}).
+All'interno di questo si ricevono (\texttt{\small 43--46}) le connessioni,
+creando (\texttt{\small 47--50}) un processo figlio per ciascuna di esse.
+Quest'ultimo (\texttt{\small 51--55}), chiuso (\texttt{\small 52}) il
+\textit{listening socket}, esegue (\texttt{\small 53}) la funzione di gestione
+del servizio \code{ServEcho}, ed al ritorno di questa (\texttt{\small 54})
+esce.
+
+Il padre invece si limita (\texttt{\small 56}) a chiudere il \textit{connected
+ socket} per ricominciare da capo il ciclo in attesa di nuove connessioni. In
+questo modo si ha un server concorrente. La terminazione del padre non è
+gestita esplicitamente, e deve essere effettuata inviando un segnale al
+processo.
+
+Avendo trattato direttamente la gestione del programma come demone, si è
+dovuto anche provvedere alla necessità di poter stampare eventuali messaggi di
+errore attraverso il sistema del \textit{syslog} trattato in
+\secref{sec:sess_daemon}. Come accennato questo è stato fatto utilizzando come
+\textit{wrapper} la funzione \code{PrintErr}, il cui codice è riportato in
+\figref{fig:TCP_PrintErr}.
+
+In essa ci si limita a controllare se è stato impostato (valore attivo per
+default) l'uso come demone, nel qual caso (\texttt{\small 3}) si usa
+\func{syslog} per stampare il messaggio di errore fornito come argomento sui
+log di sistema. Se invece si è in modalità interattiva (attivabile con
+l'opzione \texttt{-i}) si usa semplicemente la funzione \func{perror} per
+stampare sullo standard error.
+
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15.6cm}
+ \includecodesample{listati/PrintErr.c}
+ \end{minipage}
+ \normalsize
+ \caption{Codice della funzione \code{PrintErr} per la
+ generalizzazione della stampa degli errori sullo standard input o
+ attraverso il \texttt{syslog}.}
+ \label{fig:TCP_PrintErr}
+\end{figure}
+
+La gestione del servizio \textit{echo} viene effettuata interamente nella
+funzione \code{ServEcho}, il cui codice è mostrato in
+\figref{fig:TCP_ServEcho}, la comunicazione viene gestita all'interno del
+ciclo (\texttt{\small 6--8}). I dati inviati dal client vengono letti dal
+socket con una semplice \func{read} (che ritorna solo in presenza di dati in
+arrivo), la riscrittura viene invece gestita dalla funzione \func{FullWrite}
+(descritta in \figref{fig:sock_FullWrite_code}) che si incarica di tenere
+conto automaticamente della possibilità che non tutti i dati di cui è
+richiesta la scrittura vengano trasmessi con una singola \func{write}.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15.6cm}
+ \includecodesample{listati/ServEcho.c}
+ \end{minipage}
+ \normalsize
+ \caption{Codice della prima versione della funzione \code{ServEcho} per la
+ gestione del servizio \textit{echo}.}
+ \label{fig:TCP_ServEcho}
+\end{figure}
+
+Nella funzione si è anche inserita la possibilità (\texttt{\small 7--14}) di
+inviare dei messaggi di debug (abilitabile con l'uso dell'opzione \texttt{-d}
+che imposta opportunamente \var{debugging}), gestendo entrambi i casi in cui
+la stampa deve essere effettuata tramite \func{syslog} (\texttt{\small 11}) o
+direttamente sullo standard output (\texttt{\small 13}).
+
+Quando il client chiude la connessione il ricevimento del FIN fa ritornare la
+\func{read} con un numero di byte letti pari a zero, il che causa l'uscita dal
+ciclo e il ritorno della funzione, che a sua volta causa la terminazione del
+processo figlio.
+
+
+\subsection{L'avvio e il funzionamento normale}
+\label{sec:TCP_echo_startup}
+
+Benché il codice dell'esempio precedente sia molto ridotto, esso ci permetterà
+di considerare in dettaglio tutte le problematiche che si possono incontrare
+nello scrivere un'applicazione di rete. Infatti attraverso l'esame delle sue
+modalità di funzionamento normali, all'avvio e alla terminazione, e di quello
+che avviene nelle varie situazioni limite, da una parte potremo approfondire
+la comprensione del protocollo TCP/IP e dall'altra ricavare le indicazioni
+necessarie per essere in grado di scrivere applicazioni robuste, in grado di
+gestire anche i casi limite.
+
+Il primo passo è compilare e lanciare il server (da root, per poter usare la
+porta 7 che è riservata), alla partenza esso eseguirà l'apertura passiva con
+la sequenza delle chiamate a \func{socket}, \func{bind}, \func{listen} e poi
+si bloccherà nella \func{accept}. A questo punto si potrà controllarne lo
+stato con \cmd{netstat}:
+\begin{verbatim}
+[piccardi@roke piccardi]$ netstat -at
+Active Internet connections (servers and established)
+Proto Recv-Q Send-Q Local Address Foreign Address State
+...
+tcp 0 0 *:echo *:* LISTEN
+...
+\end{verbatim} %$
+che ci mostra come il socket sia in ascolto sulla porta richiesta, accettando
+connessioni da qualunque indirizzo e da qualunque porta e su qualunque
+interfaccia locale.
+
+A questo punto si può lanciare il client, esso chiamerà \func{socket} e
+\func{connect}; una volta completato il three way handshake la connessione è
+stabilita; la \func{connect} ritornerà nel client\footnote{si noti che è
+ sempre la \func{connect} del client a ritornare per prima, in quanto
+ questo avviene alla ricezione del secondo segmento (l'ACK del server) del
+ three way handshake, la \func{accept} del server ritorna solo dopo
+ un altro mezzo RTT quando il terzo segmento (l'ACK del client) viene
+ ricevuto.} e la \func{accept} nel server, ed usando di nuovo
+\cmd{netstat} otterremmo che:
+\begin{verbatim}
+Active Internet connections (servers and established)
+Proto Recv-Q Send-Q Local Address Foreign Address State
+tcp 0 0 *:echo *:* LISTEN
+tcp 0 0 roke:echo gont:32981 ESTABLISHED
+\end{verbatim}
+mentre per quanto riguarda l'esecuzione dei programmi avremo che:
+\begin{itemize}
+\item il client chiama la funzione \code{ClientEcho} che si blocca sulla
+ \func{fgets} dato che non si è ancora scritto nulla sul terminale.
+\item il server eseguirà una \func{fork} facendo chiamare al processo figlio
+ la funzione \code{ServEcho}, quest'ultima si bloccherà sulla \func{read}
+ dal socket sul quale ancora non sono presenti dati.
+\item il processo padre del server chiamerà di nuovo \func{accept}
+ bloccandosi fino all'arrivo di un'altra connessione.
+\end{itemize}
+e se usiamo il comando \cmd{ps} per esaminare lo stato dei processi otterremo
+un risultato del tipo:
+\begin{verbatim}
+[piccardi@roke piccardi]$ ps ax
+ PID TTY STAT TIME COMMAND
+ ... ... ... ... ...
+ 2356 pts/0 S 0:00 ./echod
+ 2358 pts/1 S 0:00 ./echo 127.0.0.1
+ 2359 pts/0 S 0:00 ./echod
+\end{verbatim} %$
+(dove si sono cancellate le righe inutili) da cui si evidenzia la presenza di
+tre processi, tutti in stato di \textit{sleep} (vedi
+\tabref{tab:proc_proc_states}).
+
+Se a questo punto si inizia a scrivere qualcosa sul client non sarà trasmesso
+niente fin tanto che non si prema il tasto di a capo (si ricordi quanto detto
+in \secref{sec:file_line_io} a proposito dell'I/O su terminale), solo allora
+\func{fgets} ritornerà ed il client scriverà quanto immesso sul socket, per
+poi passare a rileggere quanto gli viene inviato all'indietro dal server, che
+a sua volta sarà inviato sullo standard output, che nel caso ne provoca
+l'immediatamente stampa a video.
+
+
+\subsection{La conclusione normale}
+\label{sec:TCP_echo_conclusion}
+
+Tutto quello che scriveremo sul client sarà rimandato indietro dal server e
+ristampato a video fintanto che non concluderemo l'immissione dei dati; una
+sessione tipica sarà allora del tipo:
+\begin{verbatim}
+[piccardi@roke sources]$ ./echo 127.0.0.1
+Questa e` una prova
+Questa e` una prova
+Ho finito
+Ho finito
+\end{verbatim} %$
+che termineremo inviando un EOF dal terminale (usando la combinazione di tasti
+ctrl-D, che non compare a schermo); se eseguiamo un \cmd{netstat} a questo
+punto avremo:
+\begin{verbatim}
+[piccardi@roke piccardi]$ netstat -at
+tcp 0 0 *:echo *:* LISTEN
+tcp 0 0 localhost:33032 localhost:echo TIME_WAIT
+\end{verbatim} %$
+con il client che entra in \texttt{TIME\_WAIT}.
+
+Esaminiamo allora in dettaglio la sequenza di eventi che porta alla
+terminazione normale della connessione, che ci servirà poi da riferimento
+quando affronteremo il comportamento in caso di conclusioni anomale:
+
+\begin{enumerate}
+\item inviando un carattere di EOF da terminale la \func{fgets} ritorna
+ restituendo un puntatore nullo che causa l'uscita dal ciclo di
+ \code{while}, così la \code{ClientEcho} ritorna.
+\item al ritorno di \code{ClientEcho} ritorna anche la funzione \code{main}, e
+ come parte del processo terminazione tutti i file descriptor vengono chiusi
+ (si ricordi quanto detto in \secref{sec:proc_term_conclusion}); questo causa
+ la chiusura del socket di comunicazione; il client allora invierà un FIN al
+ server a cui questo risponderà con un ACK. A questo punto il client verrà a
+ trovarsi nello stato \texttt{FIN\_WAIT\_2} ed il server nello stato
+ \texttt{CLOSE\_WAIT} (si riveda quanto spiegato in
+ \secref{sec:TCP_conn_term}).
+\item quando il server riceve il FIN la \func{read} del processo figlio che
+ gestisce la connessione ritorna restituendo 0 causando così l'uscita dal
+ ciclo e il ritorno di \code{ServEcho}, a questo punto il processo figlio
+ termina chiamando \func{exit}.
+\item all'uscita del figlio tutti i file descriptor vengono chiusi, la
+ chiusura del socket connesso fa sì che venga effettuata la sequenza finale
+ di chiusura della connessione, viene emesso un FIN dal server che riceverà
+ un ACK dal client, a questo punto la connessione è conclusa e il client
+ resta nello stato \texttt{TIME\_WAIT}.
+\end{enumerate}
+
+
+\subsection{La gestione dei processi figli}
+\label{sec:TCP_child_hand}
+
+Tutto questo riguarda la connessione, c'è però da tenere conto dell'effetto
+del procedimento di chiusura del processo figlio nel server (si veda quanto
+esaminato in \secref{sec:proc_termination}). In questo caso avremo l'invio del
+segnale \const{SIGCHLD} al padre, ma dato che non si è installato un
+gestore e che l'azione predefinita per questo segnale è quella di essere
+ignorato, non avendo predisposto la ricezione dello stato di terminazione,
+otterremo che il processo figlio entrerà nello stato di zombie\index{zombie}
+(si riveda quanto illustrato in \secref{sec:sig_sigchld}), come risulterà
+ripetendo il comando \cmd{ps}:
+\begin{verbatim}
+ 2356 pts/0 S 0:00 ./echod
+ 2359 pts/0 Z 0:00 [echod <defunct>]
+\end{verbatim}
+
+Dato che non è il caso di lasciare processi zombie\index{zombie}, occorrerà
+ricevere opportunamente lo stato di terminazione del processo (si veda
+\secref{sec:proc_wait}), cosa che faremo utilizzando \const{SIGCHLD} secondo
+quanto illustrato in \secref{sec:sig_sigchld}. Una prima modifica al nostro
+server è pertanto quella di inserire la gestione della terminazione dei
+processi figli attraverso l'uso di un gestore. Per questo useremo la funzione
+\code{Signal} della nostra libreria personale, che abbiamo illustrato in
+\figref{fig:sig_Signal_code}, per installare il gestore che riceve i segnali
+dei processi figli terminati già visto in \figref{fig:sig_sigchld_handl}.
+Basterà allora aggiungere il seguente codice:
+\includecodesnip{listati/sigchildhand.c}
+\noindent
+all'esempio illustrato in \figref{fig:TCP_echo_server_code}.
+
+In questo modo però si introduce un altro problema,
+
+
+
+\subsection{I vari scenari critici}
+\label{sec:TCP_echo_critical}
+
+
+
+
+
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "gapil"
projects / gapil.git / blobdiff