%% elemtcp.tex
%%
-%% Copyright (C) 2000-2002 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2003 Simone Piccardi. Permission is granted to
%% copy, distribute and/or modify this document under the terms of the GNU Free
%% Documentation License, Version 1.1 or any later version published by the
%% Free Software Foundation; with the Invariant Sections being "Prefazione",
%% 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
client, inoltre anche il server deve inviare il suo SYN al client (e
trasmettere il suo numero di sequenza iniziale) questo viene fatto
ritrasmettendo un singolo segmento in cui sono impostati entrambi i flag SYN
- ACK.
+ e ACK.
\item una volta che il client ha ricevuto l'acknowledge dal server la funzione
\func{connect} ritorna, l'ultimo passo è dare dare il ricevuto del SYN del
\end{figure}
Si è accennato in precedenza ai \textsl{numeri di sequenza} (che sono anche
-riportati in \figref{fig:TCP_TWH}); per gestire una connessione affidabile
+riportati in \figref{fig:TCP_TWH}): per gestire una connessione affidabile
infatti il protocollo TCP prevede nell'header la presenza di un numero a 32
bit (chiamato appunto \textit{sequence number}) che identifica a quale byte
nella sequenza del flusso corrisponde il primo byte della sezione dati
\subsection{La terminazione della connessione}
\label{sec:TCP_conn_term}
-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_daytime_client_code} e
-\figref{fig:TCP_daytime_iter_server_code}, in questo caso la successione degli
-eventi è la seguente:
+Mentre per la creazione di una connessione occorre un interscambio di tre
+segmenti, la procedura di chiusura ne richiede normalmente quattro. 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
l'avvio a quella che viene chiamata \textsl{chiusura attiva} (o
\textit{active close}). Questo comporta l'emissione di un segmento FIN, che
- significa che si è finito con l'invio dei dati sulla connessione.
+ serve ad indicare che si è finito con l'invio dei dati sulla connessione.
-\item L'altro capo della connessione riceve il FIN ed esegue la
- \textsl{chiusura passiva} (o \textit{passive close}); al FIN, come ad ogni
- altro pacchetto, viene risposto con un ACK. Inoltre il ricevimento del FIN
+\item L'altro capo della connessione riceve il FIN e dovrà eseguire la
+ \textsl{chiusura passiva} (o \textit{passive close}). Al FIN, come ad ogni
+ altro pacchetto, viene risposto con un ACK, inoltre il ricevimento del FIN
viene segnalato al processo che ha aperto il socket (dopo che ogni altro
eventuale dato rimasto in coda è stato ricevuto) come un end-of-file sulla
- lettura, questo perché il ricevimento di un FIN significa che non si
+ lettura: questo perché il ricevimento di un FIN significa che non si
riceveranno altri dati sulla connessione.
-
-\item Dopo un certo tempo anche il secondo processo chiamerà la funzione
- \func{close} sul proprio socket, causando l'emissione di un altro segmento
- FIN.
+
+\item Una volta rilevata l'end-of-file anche il secondo processo chiamerà la
+ funzione \func{close} sul proprio socket, causando l'emissione di un altro
+ segmento FIN.
\item L'altro capo della connessione riceverà il FIN conclusivo e risponderà
con un ACK.
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
+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.
(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:
+minuti. Lo stato \texttt{TIME\_WAIT} viene utilizzato dal protocollo per due
+motivi principali:
\begin{enumerate}
\item implementare in maniera affidabile la terminazione della connessione
in entrambe le direzioni.
Se il TCP deve poter chiudere in maniera pulita entrambe le direzioni della
connessione allora deve essere in grado di affrontare la perdita di uno
qualunque dei quattro segmenti che costituiscono la chiusura. Per questo
-motivo lo stato \texttt{TIME\_WAIT} deve essere mantenuto anche dopo l'invio
-dell'ultimo ACK per poter essere in grado di poterne gestire l'eventuale
-ritrasmissione in caso di perdita.
+motivo un socket deve rimanere attivo nello stato \texttt{TIME\_WAIT} anche
+dopo l'invio dell'ultimo ACK, per potere essere in grado di gestirne
+l'eventuale ritrasmissione, in caso esso venga perduto.
Il secondo motivo è più complesso da capire, e necessita di una spiegazione
-degli scenari in cui accade che i pacchetti si possano perdere nella rete o
-restare intrappolati, per poi riemergere in un secondo tempo.
+degli scenari in cui può accadere che i pacchetti TCP si possano perdere nella
+rete o restare intrappolati, per poi riemergere in un secondo tempo.
Il caso più comune in cui questo avviene è quello di anomalie
nell'instradamento; può accadere cioè che un router smetta di funzionare o che
un terzo router che li rispedisce al primo, si creano cioè dei circoli (i
cosiddetti \textit{routing loop}) in cui restano intrappolati i pacchetti.
-Se uno di questi pacchetti intrappolati è un segmento TCP chi l'ha inviato,
+Se uno di questi pacchetti intrappolati è un segmento TCP, chi l'ha inviato,
non ricevendo un ACK in risposta, provvederà alla ritrasmissione e se nel
frattempo sarà stata stabilita una strada alternativa il pacchetto ritrasmesso
giungerà a destinazione.
Ma se dopo un po' di tempo (che non supera il limite dell'MSL, dato che
-altrimenti verrebbe ecceduto il TTL) l'anomalia viene a cessare il circolo di
+altrimenti verrebbe ecceduto il TTL) l'anomalia viene a cessare, il circolo di
instradamento viene spezzato i pacchetti intrappolati potranno essere inviati
alla destinazione finale, con la conseguenza di avere dei pacchetti duplicati;
questo è un caso che il TCP deve essere in grado di gestire.
Allora per capire la seconda ragione per l'esistenza dello stato
\texttt{TIME\_WAIT} si consideri il caso seguente: si supponga di avere una
connessione fra l'IP \texttt{195.110.112.236} porta 1550 e l'IP
-\texttt{192.84.145.100} porta 22, che questa venga chiusa e che poco dopo si
+\texttt{192.84.145.100} porta 22 (affronteremo il significato delle porte
+nella prossima sezione), che questa venga chiusa e che poco dopo si
ristabilisca la stessa connessione fra gli stessi IP sulle stesse porte
(quella che viene detta, essendo gli stessi porte e numeri IP, una nuova
\textsl{incarnazione} della connessione precedente); in questo caso ci si
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
-connessioni verso tali porte.
+servizio 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
specifico, per cui in genere vengono usate le cosiddette \textsl{porte
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
+internet (una versione aggiornata si può trovare all'indirizzo
\texttt{ftp://ftp.isi.edu/in-notes/iana/assignements/port-numbers}); inoltre
in un sistema unix-like un analogo elenco viene mantenuto nel file
\file{/etc/services}, con la corrispondenza fra i vari numeri di porta ed il
\item \textsl{le porte conosciute}. I numeri da 0 a 1023. Queste sono
controllate e assegnate dalla IANA. Se è possibile la stessa porta è
assegnata allo stesso servizio sia su UDP che su TCP (ad esempio la porta 22
- è assegnata a ssh su entrambi i protocolli, anche se viene usata solo dal
+ è assegnata a SSH su entrambi i protocolli, anche se viene usata solo dal
TCP).
\item \textsl{le porte registrate}. I numeri da 1024 a 49151. Queste porte non
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
-l'amministratore possa allocare queste porte per far partire i relativi
+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.
-Si tenga conto poi che ci sono alcuni client (in particolare \cmd{rsh} e
-\cmd{rlogin}) che richiedono una connessione su una porta riservata anche
-dal lato client come parte dell'autenticazione. Questo viene fatto tramite la
-funzione \func{rresvport} assegnando al socket una porta libera
-nell'intervallo fra 512 e 1023.
+Si tenga conto poi che ci sono alcuni client, in particolare \cmd{rsh} e
+\cmd{rlogin}, che richiedono una connessione su una porta riservata anche dal
+lato client come parte dell'autenticazione, contando appunto sul fatto che
+solo l'amministratore può usare queste porte. Data l'assoluta inconsistenza in
+termini di sicurezza di un tale metodo, al giorno d'oggi esso è in completo
+disuso.
Data una connessione TCP si suole chiamare \textit{socket pair}\footnote{da
non confondere con la coppia di socket della omonima funzione
\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 quelle che scriveremo in
+che fare con un'applicazione client/server (come quelle che descriveremo 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.
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN
\end{verbatim}
-essendo presenti e attivi un server ssh, un server di posta e un DNS per il
+essendo presenti e attivi un server SSH, un server di posta e un DNS per il
caching locale.
-Questo ci mostra ad esempio che il server ssh ha compiuto un'apertura passiva,
+Questo ci mostra ad esempio che il server SSH ha compiuto un'apertura passiva,
mettendosi in ascolto sulla porta 22 riservata a questo servizio, e che si è
posto in ascolto per connessioni provenienti da uno qualunque degli indirizzi
associati alle interfacce locali. La notazione \texttt{0.0.0.0} usata da
porta 21101 al secondo.
-\section{Le funzioni dei socket TCP}
+\section{Le funzioni di base per la gestione dei socket}
\label{sec:TCP_functions}
-In questa sezione descriveremo in dettaglio le varie funzioni necessarie per
-l'uso dei socket TCP, con l'eccezione della funzione \func{socket} che è già
-stata esaminata in dettaglio nel capitolo precedente in
-\secref{sec:sock_socket}.
+In questa sezione descriveremo in maggior dettaglio le varie funzioni che
+vengono usate per la gestione di base dei socket TCP, non torneremo però sulla
+funzione \func{socket}, che è già stata esaminata accuratamente nel capitolo
+precedente in \secref{sec:sock_socket}.
\subsection{La funzione \func{bind}}
l'indirizzo (locale) del socket e la dimensione della struttura che lo
contiene, secondo quanto già trattato in \secref{sec:sock_sockaddr}.
-Con il TCP la chiamata \func{bind} permette di specificare l'indirizzo, la
-porta, entrambi o nessuno dei due. In genere i server utilizzano una porta
+Con i socket TCP la chiamata \func{bind} permette di specificare l'indirizzo,
+la porta, entrambi o nessuno dei due. In genere i server utilizzano una porta
nota che assegnano all'avvio, se questo non viene fatto è il kernel a
scegliere una porta effimera quando vengono eseguite la funzioni
\func{connect} o \func{listen}, ma se questo è normale per il client non lo è
Normalmente un client non specifica mai l'indirizzo di un socket, ed il kernel
sceglie l'indirizzo di origine quando viene effettuata la connessione, sulla
-base dell'interfaccia usata per trasmettere i pacchetti, (che dipende dalle
+base dell'interfaccia usata per trasmettere i pacchetti, (che dipenderà dalle
regole di instradamento usate per raggiungere il server). Se un server non
specifica il suo indirizzo locale il kernel userà come indirizzo di origine
l'indirizzo di destinazione specificato dal SYN del client.
Stabilisce una connessione fra due socket.
\bodydesc{La funzione restituisce zero in caso di successo e -1 per un
- errore, in caso di errore \var{errno} assumerà i valori:
+ errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
\item[\errcode{ECONNREFUSED}] non c'è nessuno in ascolto sull'indirizzo
remoto.
\func{accept} passa gli errori di rete pendenti sul nuovo socket come codici
di errore per \func{accept}, per cui l'applicazione deve tenerne conto ed
eventualmente ripetere la chiamata alla funzione come per l'errore di
-\errcode{EAGAIN}. Un'altra differenza con BSD è che la funzione non fa
-ereditare al nuovo socket i flag del socket originale, come
-\const{O\_NONBLOCK},\footnote{ed in generale tutti quelli che si possono
- impostare con \func{fcntl}, vedi \secref{sec:file_fcntl}.} che devono essere
-rispecificati ogni volta. Tutto questo deve essere tenuto in conto se si
-devono scrivere programmi portabili.
+\errcode{EAGAIN} (torneremo su questo in \secref{sec:TCP_echo_critical}).
+Un'altra differenza con BSD è che la funzione non fa ereditare al nuovo socket
+i flag del socket originale, come \const{O\_NONBLOCK},\footnote{ed in generale
+ tutti quelli che si possono impostare con \func{fcntl}, vedi
+ \secref{sec:file_fcntl}.} che devono essere rispecificati ogni volta. Tutto
+questo deve essere tenuto in conto se si devono scrivere programmi portabili.
Il meccanismo di funzionamento di \func{accept} è essenziale per capire il
funzionamento di un server: in generale infatti c'è sempre un solo socket in
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
Infatti con i socket è comune che funzioni come \func{read} o \func{write}
possano restituire in input o scrivere in output un numero di byte minore di
quello richiesto. Come già accennato in \secref{sec:file_read} questo è un
-comportamento normale per l'I/O su file, ma con i normali file di dati il
-problema si avverte solo quando si incontra la fine del file. In generale non
-è così, e con i socket questo è particolarmente evidente.
+comportamento normale per le funzioni di I/O, ma con i normali file di dati il
+problema si avverte solo in lettura, quando si incontra la fine del file. In
+generale non è così, e con i socket questo è particolarmente evidente.
\begin{figure}[htb]
Nel caso della lettura, se il numero di byte letti è zero, significa che si è
arrivati alla fine del file (per i socket questo significa in genere che
l'altro capo è stato chiuso, e quindi non sarà più possibile leggere niente) e
-pertanto si ritorna senza aver concluso la lettura di tutti i byte richiesti.
+pertanto si ritorna senza aver concluso la lettura di tutti i byte
+richiesti. Entrambe le funzioni restituiscono 0 in caso di successo, ed un
+valore negativo in caso di errore, \texttt{FullRead} restituisce il numero di
+byte non letti in caso di end-of-file prematuro.
\subsection{Il client \textit{daytime}}
\label{sec:TCP_daytime_client}
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
+\secref{sec:TCP_functions} è 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{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
\func{socket} ritorna il descrittore che viene usato per identificare il
socket in tutte le chiamate successive. Nel caso la chiamata fallisca si
stampa un errore (\texttt{\small 16}) con la funzione \func{perror} e si esce
-(\texttt{\small 16}) con un codice di errore.
+(\texttt{\small 17}) con un codice di errore.
Il passo seguente (\texttt{\small 19--27}) è quello di costruire un'apposita
struttura \struct{sockaddr\_in} in cui sarà inserito l'indirizzo del server ed
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}
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
\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
-\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
Si noti come il figlio operi solo sul socket connesso, chiudendo
immediatamente (\texttt{\small 32}) il socket \var{list\_fd}; mentre il padre
-continua ad operare solo sul socket in ascolto chiudendo (\texttt{\small 47})
+continua ad operare (\texttt{\small 47}) solo sul socket in ascolto chiudendo
\var{sock\_fd} al ritorno dalla \func{fork}. Per quanto abbiamo detto in
\secref{sec:TCP_func_close} nessuna delle due chiamate a \func{close} causa
l'innesco della sequenza di chiusura perché il numero di riferimenti al file
complessi.
+
\section{Un esempio più completo: il servizio \textit{echo}}
\label{sec:TCP_echo_application}
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, 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.
-
-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.
-
-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.
+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 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 del client per il servizio \textit{echo},
+disponibile nel file \file{TCP\_echo\_first.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/EchoServerWrong.c}
+ \includecodesample{listati/TCP_echo_first.c}
\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}
-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 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{read}\footnote{si è fatta l'assunzione implicita che i dati siano
+ contenuti tutti in un solo segmento, così che la chiamata a \texttt{read} li
+ restituisca sempre tutti; avendo scelto una dimensione ridotta per il buffer
+ questo sarà sempre vero, vedremo più avanti come superare il problema di
+ rileggere indietro tutti e soli i dati disponibili, senza bloccarsi.} 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
\normalsize
\caption{Codice della prima versione della funzione \texttt{ClientEcho} per
la gestione del servizio \textit{echo}.}
- \label{fig:TCPsimpl_client_echo_sub}
+ \label{fig:TCP_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}).
+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.
-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}.
+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.
-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.
-
-\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
-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 rimandare indietro sulla connessione i dati che gli vengono
-inviati; l'RFC descrive le specifiche 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; il servizio opera sulla porta 7.
+La prima versione del server, contenuta nel file \file{TCP\_echod\_first.c}, è
+riportata in \figref{fig:TCP_echo_server_first_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.
-Nel nostro caso l'esempio sarà costituito da un client che legge una linea di
-caratteri dallo standard input e la scrive sul server, il server leggerà la
-linea dalla connessione e la riscriverà all'indietro; sarà compito del client
-leggere la risposta del server e stamparla sullo standard output.
+\begin{figure}[!htbp]
+ \footnotesize \centering
+ \begin{minipage}[c]{15.6cm}
+ \includecodesample{listati/TCP_echod_first.c}
+ \end{minipage}
+ \normalsize
+ \caption{Codice del corpo principale della prima versione del server
+ per il servizio \textit{echo}.}
+ \label{fig:TCP_echo_server_first_code}
+\end{figure}
-La prima versione del server, \file{ElemEchoTCPServer.c}, si compone di un
-corpo principale, costituito dalla funzione \code{main}. Questa si incarica
-di creare il socket, metterlo in ascolto di connessioni in arrivo e creare un
-processo figlio a cui delegare la gestione di ciascuna connessione. Questa
-parte, riportata in \figref{fig:TCPsimpl_serv_code}, è analoga a quella vista
-nel precedente esempio esaminato in \secref{sec:TCP_daytime_cunc_server}.
+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 (\texttt{\small 2}) se è stato impostato
+(valore attivo per default) l'uso come demone, nel qual caso (\texttt{\small
+ 3}) si usa \func{syslog} (vedi \secref{sec:sess_daemon}) 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
+(\texttt{\small 5}) semplicemente la funzione \func{perror} per stampare sullo
+standard error.
\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{15.6cm}
- \includecodesample{listati/ElemEchoTCPServer.c}
+ \includecodesample{listati/PrintErr.c}
\end{minipage}
\normalsize
- \caption{Codice della funzione \code{main} della prima versione del server
- per il servizio \textit{echo}.}
- \label{fig:TCPsimpl_serv_code}
+ \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 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
-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
-% processo figlio, il quale si incarica di lanciare la funzione
-% \texttt{SockEcho}.
-
-Il codice della funzione \code{ServEcho} è invece mostrata in
-\figref{fig:TCPsimpl_server_elem_sub}, la comunicazione viene gestita
-all'interno del ciclo (linee \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
+La gestione del servizio \textit{echo} viene effettuata interamente nella
+funzione \code{ServEcho}, il cui codice è mostrato in
+\figref{fig:TCP_ServEcho_first}, e la comunicazione viene gestita all'interno
+di un ciclo (\texttt{\small 6--13}). I dati inviati dal client vengono letti
+(\texttt{\small 6}) dal socket con una semplice \func{read}, di cui non si
+controlla lo stato di uscita, assumendo che ritorni solo in presenza di dati
+in arrivo. La riscrittura (\texttt{\small 7}) 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]
+\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{15.6cm}
- \includecodesample{listati/ServEcho.c}
+ \includecodesample{listati/ServEcho_first.c}
\end{minipage}
\normalsize
\caption{Codice della prima versione della funzione \code{ServEcho} per la
gestione del servizio \textit{echo}.}
- \label{fig:TCPsimpl_server_elem_sub}
+ \label{fig:TCP_ServEcho_first}
\end{figure}
-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.
-
-
+In caso di errore di scrittura (si ricordi che \func{FullWrite} restituisce un
+valore nullo in caso di successo) si provvede (\texttt{\small 8--10}) a
+stampare il relativo messaggio con \func{PrintErr}. 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
+(\texttt{\small 12}) della funzione, che a sua volta causa la terminazione del
+processo figlio.
\subsection{L'avvio e il funzionamento normale}
-\label{sec:TCPsimpl_startup}
+\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
+di considerare in dettaglio le varie 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
\subsection{La conclusione normale}
-\label{sec:TCPsimpl_conclusion}
+\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
\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.
+ restituendo un puntatore nullo che causa l'uscita dal ciclo di \code{while},
+ così la funzione \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
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:TCPsimpl_child_hand}
+\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
2359 pts/0 Z 0:00 [echod <defunct>]
\end{verbatim}
-Poiché non è possibile lasciare processi zombie\index{zombie} che pur inattivi
-occupano spazio nella tabella dei processi e a lungo andare saturerebbero le
-risorse del kernel, 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}.
-
-La 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}, illustrata in
-\figref{fig:sig_Signal_code}, per installare il semplice gestore che
-riceve i segnali dei processi figli terminati già visto in
-\figref{fig:sig_sigchld_handl}; aggiungendo il seguente codice:
-\includecodesnip{listati/sigchildhand.c}
+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} (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:TCPsimpl_serv_code}, e linkando il tutto
-alla funzione \code{sigchld\_hand}, si risolverà completamente il problema
-degli zombie\index{zombie}.
+all'esempio illustrato in \figref{fig:TCP_echo_server_first_code}.
+
+In questo modo però si introduce un altro problema. Si ricordi infatti che,
+come spiegato in \secref{sec:sig_gen_beha}, quando un programma si trova in
+stato di \texttt{sleep} durante l'esecuzione di una system call, questa viene
+interrotta alla ricezione di un segnale. Per questo motivo, alla fine
+dell'esecuzione del gestore del segnale, se questo ritorna, il programma
+riprenderà l'esecuzione ritornando dalla system call interrotta con un errore
+di \errcode{EINTR}.
+
+Vediamo allora cosa comporta tutto questo nel nostro caso: quando si chiude il
+client, il processo figlio che gestisce la connessione terminerà, ed il padre,
+per evitare la creazione di zombie, riceverà il segnale \const{SIGCHLD}
+eseguendo il relativo gestore. Al ritorno del gestore però l'esecuzione nel
+padre ripartirà subito con il ritorno della funzione \func{accept} (a meno di
+un caso fortuito in cui il segnale arriva durante l'esecuzione del programma
+in risposta ad una connessione) con un errore di \errcode{EINTR}. Non avendo
+previsto questa eventualità il programma considera questo un errore fatale
+terminando a sua volta con un messaggio del tipo:
+\begin{verbatim}
+[root@gont sources]# ./echod -i
+accept error: Interrupted system call
+\end{verbatim}%#
+
+Come accennato in \secref{sec:sig_gen_beha} le conseguenze di questo
+comportamento delle system call possono essere superate in due modi diversi,
+il più semplice è quello di modificare il codice di \func{Signal} per
+richiedere il riavvio automatico delle system call interrotte secondo la
+semantica di BSD, usando l'opzione \const{SA\_RESTART} di \func{sigaction};
+rispetto a quanto visto in \figref{fig:sig_Signal_code}. Definiremo allora la
+nuova funzione \func{SignalRestart}\footnote{anche questa è definita, insieme
+ alle altre funzioni riguardanti la gestione dei segnali, nel file
+ \file{SigHand.c}, il cui contento completo può essere trovato negli esempi
+ allegati.} come mostrato in \figref{fig:sig_SignalRestart_code}, ed
+installeremo il gestore usando quest'ultima.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15.6cm}
+ \includecodesample{listati/SignalRestart.c}
+ \end{minipage}
+ \normalsize
+ \caption{La funzione \funcd{SignalRestart}, che installa un gestore di
+ segnali in semantica BSD per il riavvio automatico delle system call
+ interrotte.}
+ \label{fig:sig_SignalRestart_code}
+\end{figure}
+
+Come si può notare questa funzione è identica alla precedente \func{Signal},
+illustrata in \figref{fig:sig_Signal_code}, solo che in questo caso invece di
+inizializzare a zero il campo \var{sa\_flags} di \struct{sigaction}, lo si
+inizializza (\texttt{\small 5}) al valore \const{SA\_RESTART}. Usando questa
+funzione al posto di \func{Signal} nel server non è necessaria nessuna altra
+modifica: le system call interrotte saranno automaticamente riavviate, e
+l'errore \errcode{EINTR} non si manifesterà più.
+
+La seconda soluzione è più invasiva e richiede di controllare tutte le volte
+l'errore restituito dalle varie system call, ripetendo la chiamata qualora
+questo corrisponda ad \errcode{EINTR}. Questa soluzione ha però il pregio
+della portabilità, infatti lo standard POSIX dice che la funzionalità di
+riavvio automatico delle system call, fornita da \const{SA\_RESTART}, è
+opzionale, per cui non è detto che essa sia disponibile su qualunque sistema.
+Inoltre in certi casi,\footnote{Stevens in \cite{UNP1} accenna che la maggior
+ parte degli Unix derivati da BSD non fanno ripartire \func{select}; altri
+ non riavviano neanche \func{accept} e \func{recvfrom}, cosa che invece nel
+ caso di Linux viene sempre fatta.} anche quando questa è presente, non è
+detto possa essere usata con \func{accept}.
+
+
+La portabilità nella gestione dei segnali però viene al costo di una
+riscrittura parziale del server, la nuova versione di questo, in cui si sono
+introdotte una serie di nuove opzioni che ci saranno utili per il debug, è
+mostrata in \figref{fig:TCP_echo_server_code_second}, dove si sono riportate
+la sezioni di codice modificate nella seconda versione del programma, il
+sorgente completo di quest'ultimo si trova nel file
+\file{TCP\_echod\_second.c} dei sorgenti allegati alla guida.
+
+La prima modifica effettuata è stata quella di introdurre una nuova opzione a
+riga di comando, \texttt{-c}, che permette di richiedere il comportamento
+compatibile nella gestione di \const{SIGCHLD} al posto della semantica BSD
+impostando la variabile \var{compat} ad un valore non nullo. Questa è
+preimpostata al valore nullo, cosicché se non si usa questa opzione il
+comportamento di default del server è di usare la semantica BSD.
+
+Una seconda opzione aggiunta è quella di inserire un tempo di attesa fisso
+specificato in secondi fra il ritorno della funzione \func{listen} e la
+chiamata di \func{accept}, specificabile con l'opzione \texttt{-w}, che
+permette di impostare la variabile \var{waiting}. Infine si è introdotta una
+opzione \texttt{-d} per abilitare il debugging che imposta ad un valore non
+nullo la variabile \var{debugging}. Al solito si è omessa da
+\figref{fig:TCP_echo_server_code_second} la sezione di codice relativa alla
+gestione di tutte queste opzioni, che può essere trovata nel sorgente del
+programma.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15.6cm}
+ \includecodesample{listati/TCP_echod_second.c}
+ \end{minipage}
+ \normalsize
+ \caption{La sezione nel codice della seconda versione del server
+ per il servizio \textit{echo} modificata per tener conto dell'interruzione
+ delle system call.}
+ \label{fig:TCP_echo_server_code_second}
+\end{figure}
+
+Vediamo allora come è cambiato il nostro server; una volta definite le
+variabili e trattate le opzioni il primo passo (\texttt{\small 9--13}) è
+verificare la semantica scelta per la gestione di \const{SIGCHLD}, a seconda
+del valore di \var{compat} (\texttt{\small 9}) si installa il gestore con la
+funzione \func{Signal} (\texttt{\small 10}) o con \texttt{SignalRestart}
+(\texttt{\small 12}), essendo quest'ultimo il valore di default.
+
+Tutta la sezione seguente, che crea il socket, cede i privilegi di
+amministratore ed eventualmente lancia il programma come demone, è rimasta
+invariata e pertanto è stata omessa in
+\figref{fig:TCP_echo_server_code_second}; l'unica modifica effettuata prima
+dell'entrata nel ciclo principale è stata quella di aver introdotto, subito
+dopo la chiamata (\texttt{\small 17--20}) alla funzione \func{listen}, una
+eventuale pausa con una condizione (\texttt{\small 21}) sulla variabile
+\var{waiting}, che viene inizializzata, con l'opzione \code{-w Nsec}, al
+numero di secondi da aspettare (il valore preimpostato è nullo).
+
+Si è potuto lasciare inalterata tutta la sezione di creazione del socket
+perché nel server l'unica chiamata ad una system call critica, che può essere
+interrotta dall'arrivo di \const{SIGCHLD}, è quella ad \func{accept}, che è
+l'unica funzione che può mettere il processo padre in stato di sleep nel
+periodo in cui un figlio può terminare; si noti infatti come le altre
+\textit{slow system call}\footnote{si ricordi la distinzione fatta in
+ \secref{sec:sig_gen_beha}.} o sono chiamate prima di entrare nel ciclo
+principale, quando ancora non esistono processi figli, o sono chiamate dai
+figli stessi e non risentono di \const{SIGCHLD}.
+
+Per questo l'unica modifica sostanziale nel ciclo principale (\texttt{\small
+ 23--42}), rispetto precedente versione di \figref{fig:TCP_ServEcho_first}, è
+nella sezione (\texttt{\small 26--30}) in cui si effettua la chiamata di
+\func{accept}. Quest'ultima viene effettuata (\texttt{\small 26--27})
+all'interno di un ciclo di \code{while}\footnote{la sintassi del C relativa a
+ questo ciclo può non essere del tutto chiara. In questo caso infatti si è
+ usato un ciclo vuoto che non esegue nessuna istruzione, in questo modo
+ quello che viene ripetuto con il ciclo è soltanto il codice che esprime la
+ condizione all'interno del \code{while}.} che la ripete indefinitamente
+qualora in caso di errore il valore di \var{errno} sia \errcode{EINTR}. Negli
+altri casi si esce in caso di errore effettivo (\texttt{\small 27--29}),
+altrimenti il programma prosegue.
+
+Si noti che in questa nuova versione si è aggiunta una ulteriore sezione
+(\texttt{\small 31--39}) di aiuto per il debug del programma, che eseguita con
+un controllo (\texttt{\small 31}) sul valore della variabile \var{debugging}
+impostato dall'opzione \texttt{-d}. Qualora questo sia nullo, come
+preimpostato, non accade nulla. altrimenti (\texttt{\small 32}) l'indirizzo
+ricevuto da \var{accept} viene convertito in una stringa che poi
+(\texttt{\small 33--38}) viene opportunamente stampata o sullo schermo o nei
+log.
+
+
+
+
+\section{I vari scenari critici}
+\label{sec:TCP_echo_critical}
+
+Con le modifiche viste in \secref{sec:TCP_child_hand} il nostro esempio
+diventa in grado di affrontare la gestione ordinaria delle connessioni, ma un
+server di rete deve tenere conto che, al contrario di quanto avviene per i
+server che operano nei confronti di processi presenti sulla stessa macchina,
+la rete è di sua natura inaffidabile, per cui è necessario essere in grado di
+gestire tutta una serie di situazioni critiche che non esistono per i processi
+locali.
+
+
+\subsection{La terminazione precoce della connessione}
+\label{sec:TCP_conn_early_abort}
+
+La prima situazione critica è quella della terminazione precoce, causata da un
+qualche errore sulla rete, della connessione effettuata da un client. Come
+accennato in \secref{sec:TCP_func_accept} la funzione \func{accept} riporta
+tutti gli eventuali errori di rete pendenti su una connessione sul
+\textit{connected socket}. Di norma questo non è un problema, in quanto non
+appena completata la connessione, \func{accept} ritorna e l'errore sarà
+rilevato in seguito, dal processo che gestisce la connessione, alla prima
+chiamata di una funzione che opera sul socket.
+
+È però possibile, dal punto di vista teorico, incorrere anche in uno scenario
+del tipo di quello mostrato in \figref{fig:TCP_early_abort}, in cui la
+connessione viene abortita sul lato client per un qualche errore di rete con
+l'invio di un segmento RST, prima che nel server sia stata chiamata la
+funzione \func{accept}.
+
+\begin{figure}[htb]
+ \centering
+ \includegraphics[width=10cm]{img/tcp_client_early_abort}
+ \caption{Un possibile caso di terminazione precoce della connessione.}
+ \label{fig:TCP_early_abort}
+\end{figure}
+
+Benché questo non sia un fatto comune, un evento simile può essere osservato
+con dei server molto occupati. In tal caso, con una struttura del server
+simile a quella del nostro esempio, in cui la gestione delle singole
+connessioni è demandata a processi figli, può accadere che il three way
+handshake venga completato e la relativa connessione abortita subito dopo,
+prima che il padre, per via del carico della macchina, abbia fatto in tempo ad
+eseguire la chiamata ad \func{accept}. Di nuovo si ha una situazione analoga
+a quella illustrata in \figref{fig:TCP_early_abort}, in cui la connessione
+viene stabilita, ma subito dopo si ha una condizione di errore che la chiude
+prima che essa sia stata accettata dal programma.
+
+Questo significa che, oltre alla interruzione da parte di un segnale, che
+abbiamo trattato in \secref{sec:TCP_child_hand} nel caso particolare di
+\const{SIGCHLD}, si possono ricevere altri errori non fatali all'uscita di
+\func{accept}, che come nel caso precedente, necessitano semplicemente la
+ripetizione della chiamata senza che si debba uscire dal programma. In questo
+caso anche la versione modificata del nostro server non sarebbe adatta, in
+quanto uno di questi errori causerebbe la terminazione dello stesso. In Linux
+i possibili errori di rete non fatali, riportati sul socket connesso al
+ritorno di \func{accept}, sono \errcode{ENETDOWN}, \errcode{EPROTO},
+\errcode{ENOPROTOOPT}, \errcode{EHOSTDOWN}, \errcode{ENONET},
+\errcode{EHOSTUNREACH}, \errcode{EOPNOTSUPP} e \errcode{ENETUNREACH}.
+
+Si tenga presente che questo tipo di terminazione non è riproducibile
+terminando il client prima della chiamata ad \func{accept}, come si potrebbe
+fare usando l'opzione \texttt{-w} per introdurre una pausa dopo il lancio del
+demone, in modo da poter avere il tempo per lanciare e terminare una
+connessione usando il programma client. In tal caso infatti, alla terminazione
+del client, il socket associato alla connessione viene semplicemente chiuso,
+attraverso la sequenza vista in \secref{sec:TCP_conn_term}, per cui la
+\func{accept} ritornerà senza errori, e si avrà semplicemente un end-of-file
+al primo accesso al socket. Nel caso di Linux inoltre, anche qualora si
+modifichi il client per fargli gestire l'invio di un segmento di RST alla
+chiusura dal socket (come suggerito da Stevens in \cite{UNP1}), non si ha
+nessun errore al ritorno di \funcd{accept} quanto un errore di
+\errcode{ECONNRESET} al primo tentativo di accesso al socket.
+
+
+
+\subsection{Il crollo del server}
+\label{sec:TCP_server_crash}
+
+Un secondo caso critico è quello in cui si ha il crollo del server. In tal
+caso si suppone che il processo del server termini per un errore fatale, cosa
+che potremo simulare inviandogli un segnale di terminazione. La conclusione
+del processo comporta la chiusura di tutti i file aperti, compresi tutti i
+socket relativi a connessioni stabilite; questo significa che al momento del
+crollo del servizio il client riceverà un FIN dal server in corrispondenza
+della chiusura del socket.
+
+
projects / gapil.git / blobdiff