serie di flag usati per gestire la connessione, come SYN, ACK, URG, FIN,
alcuni di essi, come SYN (che sta per \textit{syncronize}) corrispondono a
funzioni particolari del protocollo e danno il nome al segmento, (per
- maggiori dettagli vedere \secref{sec:tcp_protocol}).} di dati che vengono
+ maggiori dettagli vedere sez.~\ref{sec:tcp_protocol}).} di dati che vengono
scambiati) che porta alla creazione di una connessione è la seguente:
\begin{enumerate}
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
+ \func{connect} ritorna, l'ultimo passo è dare il ricevuto del SYN del
server inviando un ACK. Alla ricezione di quest'ultimo la funzione
\func{accept} del server ritorna e la connessione è stabilita.
\end{enumerate}
Il procedimento viene chiamato \textit{three way handshake} dato che per
-realizzarlo devono essere scambiati tre segmenti. In \figref{fig:TCP_TWH}
+realizzarlo devono essere scambiati tre segmenti. In fig.~\ref{fig:TCP_TWH}
si è rappresentata graficamente la sequenza di scambio dei segmenti che
stabilisce la connessione.
\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 fig.~\ref{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
aspetta di ricevere con il pacchetto successivo; dato che il primo pacchetto
SYN consuma un byte, nel \textit{three way handshake} il numero di acknowledge
è sempre pari al numero di sequenza iniziale incrementato di uno; lo stesso
-varrà anche (vedi \figref{fig:TCP_close}) per l'acknowledgement di un FIN.
+varrà anche (vedi fig.~\ref{fig:TCP_close}) per l'acknowledgement di un FIN.
\subsection{Le opzioni TCP.}
\label{sec:TCP_TCP_opt}
connessione corrente. È possibile leggere e scrivere questo valore
attraverso l'opzione del socket \const{TCP\_MAXSEG}.
-\item \textit{window scale option}, %come spiegato in \secref{sec:tcp_protocol}
+\item \textit{window scale option}, %come spiegato in sez.~\ref{sec:tcp_protocol}
il protocollo TCP implementa il controllo di flusso attraverso una
\textsl{finestra annunciata} (\textit{advertized window}) con la quale
ciascun capo della comunicazione dichiara quanto spazio disponibile ha in
giacché in alcune situazioni il FIN del passo 1) è inviato insieme a dei dati.
Inoltre è possibile che i segmenti inviati nei passi 2 e 3 dal capo che
effettua la chiusura passiva, siano accorpati in un singolo segmento. In
-\figref{fig:TCP_close} si è rappresentato graficamente lo sequenza di
+fig.~\ref{fig:TCP_close} si è rappresentato graficamente lo sequenza di
scambio dei segmenti che conclude la connessione.
\begin{figure}[htb]
è chiuso il socket dal lato che esegue la chiusura attiva; esistono tuttavia
situazioni in cui si vuole poter sfruttare questa possibilità, usando una
procedura che è chiamata \textit{half-close}; torneremo su questo aspetto e su
-come utilizzarlo in \secref{sec:TCP_shutdown}, quando parleremo della funzione
-\func{shutdown}.
+come utilizzarlo in sez.~\ref{sec:TCP_shutdown}, quando parleremo della
+funzione \func{shutdown}.
La emissione del FIN avviene quando il socket viene chiuso, questo però non
avviene solo per la chiamata esplicita della funzione \func{close}, ma anche
connessioni aperte verranno chiuse.
Infine occorre sottolineare che, benché nella figura (e nell'esempio che
-vedremo più avanti in \secref{sec:TCP_echo}) sia stato il client ad eseguire
+vedremo più avanti in sez.~\ref{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
+fig.~\ref{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.
Come abbiamo visto le operazioni del TCP nella creazione e conclusione di una
connessione sono piuttosto complesse, ed abbiamo esaminato soltanto quelle
-relative ad un andamento normale. In \secref{sec:TCP_states} vedremo con
+relative ad un andamento normale. In sez.~\ref{sec:TCP_states} vedremo con
maggiori dettagli che una connessione può assumere vari stati, che ne
caratterizzano il funzionamento, e che sono quelli che vengono riportati dal
comando \cmd{netstat}, per ciascun socket TCP aperto, nel campo
Non possiamo affrontare qui una descrizione completa del funzionamento del
protocollo; un approfondimento sugli aspetti principali si trova in
-\secref{sec:tcp_protocol}, ma per una trattazione completa il miglior
+sez.~\ref{sec:tcp_protocol}, ma per una trattazione completa il miglior
riferimento resta \cite{TCPIll1}. Qui ci limiteremo a descrivere brevemente un
semplice esempio di connessione e le transizioni che avvengono nei due casi
appena citati (creazione e terminazione della connessione).
\texttt{ESTABLISHED} (chiusura passiva) la transizione è verso lo stato
\texttt{CLOSE\_WAIT}.
-In \figref{fig:TCP_conn_example} è riportato lo schema dello scambio dei
+In fig.~\ref{fig:TCP_conn_example} è riportato lo schema dello scambio dei
pacchetti che avviene per una un esempio di connessione, insieme ai vari stati
che il protocollo viene ad assumere per i due lati, server e client.
restituisce una risposta (che di nuovo supponiamo stare in un singolo
segmento). Si noti che l'acknowledge della richiesta è mandato insieme alla
risposta: questo viene chiamato \textit{piggybacking} ed avviene tutte le
-volte che che il server è sufficientemente veloce a costruire la risposta; in
+volte che il server è sufficientemente veloce a costruire la risposta; in
caso contrario si avrebbe prima l'emissione di un ACK e poi l'invio della
risposta.
Infine si ha lo scambio dei quattro segmenti che terminano la connessione
-secondo quanto visto in \secref{sec:TCP_conn_term}; si noti che il capo della
+secondo quanto visto in sez.~\ref{sec:TCP_conn_term}; si noti che il capo della
connessione che esegue la chiusura attiva entra nello stato
\texttt{TIME\_WAIT}, sul cui significato torneremo fra poco.
in questo stato lasciando attiva una connessione ormai conclusa; la risposta è
che non deve essere fatto, ed il motivo cercheremo di spiegarlo adesso.
-Come si è visto nell'esempio precedente (vedi \figref{fig:TCP_conn_example})
+Come si è visto nell'esempio precedente (vedi fig.~\ref{fig:TCP_conn_example})
\texttt{TIME\_WAIT} è lo stato finale in cui il capo di una connessione che
esegue la chiusura attiva resta prima di passare alla chiusura definitiva
della connessione. Il tempo in cui l'applicazione resta in questo stato deve
sulla rete; questo tempo è limitato perché ogni pacchetto IP può essere
ritrasmesso dai router un numero massimo di volte (detto \textit{hop limit}).
Il numero di ritrasmissioni consentito è indicato dal campo TTL dell'header di
-IP (per maggiori dettagli vedi \secref{sec:ip_protocol}), e viene decrementato
-ad ogni passaggio da un router; quando si annulla il pacchetto viene scartato.
-Siccome il numero è ad 8 bit il numero massimo di ``\textsl{salti}'' è di 255,
-pertanto anche se il TTL (da \textit{time to live}) non è propriamente un
-limite sul tempo di vita, si stima che un pacchetto IP non possa restare nella
-rete per più di MSL secondi.
+IP (per maggiori dettagli vedi sez.~\ref{sec:ip_protocol}), e viene
+decrementato ad ogni passaggio da un router; quando si annulla il pacchetto
+viene scartato. Siccome il numero è ad 8 bit il numero massimo di
+``\textsl{salti}'' è di 255, pertanto anche se il TTL (da \textit{time to
+ live}) non è propriamente un limite sul tempo di vita, si stima che un
+pacchetto IP non possa restare nella rete per più di MSL secondi.
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,
durata di questo stato.
Il primo dei due motivi precedenti si può capire tornando a
-\figref{fig:TCP_conn_example}: assumendo che l'ultimo ACK della sequenza
+fig.~\ref{fig:TCP_conn_example}: assumendo che l'ultimo ACK della sequenza
(quello del capo che ha eseguito la chiusura attiva) venga perso, chi esegue
la chiusura passiva non ricevendo risposta rimanderà un ulteriore FIN, per
questo motivo chi esegue la chiusura attiva deve mantenere lo stato della
sia UDP che TCP, e ci devono poter essere più connessioni in contemporanea.
Per poter tenere distinte le diverse connessioni entrambi i protocolli usano i
\textsl{numeri di porta}, che fanno parte, come si può vedere in
-\secref{sec:sock_sa_ipv4} e \secref{sec:sock_sa_ipv6} pure delle strutture
+sez.~\ref{sec:sock_sa_ipv4} e sez.~\ref{sec:sock_sa_ipv6} pure delle strutture
degli indirizzi del socket.
Quando un client contatta un server deve poter identificare con quale dei vari
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
-tabelle.
+fig.~\ref{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 tabelle.
\begin{figure}[!htb]
\centering
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 descriveremo in
-\secref{sec:TCP_daytime_application} e \secref{sec:TCP_echo_application})
+sez.~\ref{sec:TCP_daytime_application} e sez.~\ref{sec:TCP_echo_application})
esamineremo cosa accade con le connessioni nel caso di un server TCP che deve
gestire connessioni multiple.
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}.
+precedente in sez.~\ref{sec:sock_socket}.
\subsection{La funzione \func{bind}}
Il primo argomento è un file descriptor ottenuto da una precedente chiamata a
\func{socket}, mentre il secondo e terzo argomento sono rispettivamente
l'indirizzo (locale) del socket e la dimensione della struttura che lo
-contiene, secondo quanto già trattato in \secref{sec:sock_sockaddr}.
+contiene, secondo quanto già trattato in sez.~\ref{sec:sock_sockaddr}.
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
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_daytime_iter_server_code} si è usata un'assegnazione immediata
-del tipo: \includecodesnip{listati/serv_addr_sin_addr.c}
+sez.~\ref{sec:sock_sa_ipv4}, è pari a zero; nell'esempio
+fig.~\ref{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 è
inutile. Si tenga presente comunque che tutte le costanti \val{INADDR\_}
-(riportate in \tabref{tab:TCP_ipv4_addr}) sono definite secondo
+(riportate in tab.~\ref{tab:TCP_ipv4_addr}) sono definite secondo
l'\textit{endianess} della macchina, ed anche se esse possono essere
invarianti rispetto all'ordinamento dei bit, è comunque buona norma usare
sempre la funzione \func{htonl}.
connessione.
\item[\errcode{ENETUNREACH}] la rete non è raggiungibile.
\item[\errcode{EINPROGRESS}] il socket è non bloccante (vedi
- \secref{sec:file_noblocking}) e la connessione non può essere conclusa
+ sez.~\ref{sec:file_noblocking}) e la connessione non può essere conclusa
immediatamente.
\item[\errcode{EALREADY}] il socket è non bloccante (vedi
- \secref{sec:file_noblocking}) e un tentativo precedente di connessione non
- si è ancora concluso.
+ sez.~\ref{sec:file_noblocking}) e un tentativo precedente di connessione
+ non si è ancora concluso.
\item[\errcode{EAGAIN}] non ci sono più porte locali libere.
\item[\errcode{EAFNOSUPPORT}] l'indirizzo non ha una famiglia di indirizzi
corretta nel relativo campo.
Il primo argomento è un file descriptor ottenuto da una precedente chiamata a
\func{socket}, mentre il secondo e terzo argomento sono rispettivamente
l'indirizzo e la dimensione della struttura che contiene l'indirizzo del
-socket, già descritta in \secref{sec:sock_sockaddr}.
+socket, già descritta in sez.~\ref{sec:sock_sockaddr}.
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_daytime_client}, usando le funzioni illustrate in
-\secref{sec:sock_addr_func}.
+nell'esempio sez.~\ref{sec:TCP_daytime_client}, usando le funzioni illustrate
+in sez.~\ref{sec:sock_addr_func}.
Nel caso di socket TCP la funzione \func{connect} avvia il \textit{three way
handshake}, e ritorna solo quando la connessione è stabilita o si è
\end{enumerate}
Se si fa riferimento al diagramma degli stati del TCP riportato in
-\figref{fig:TCP_state_diag} la funzione \func{connect} porta un socket
+fig.~\ref{fig:TCP_state_diag} la funzione \func{connect} porta un socket
dallo stato \texttt{CLOSED} (lo stato iniziale in cui si trova un socket
appena creato) prima allo stato \texttt{SYN\_SENT} e poi, al ricevimento del
ACK, nello stato \texttt{ESTABLISHED}. Se invece la connessione fallisce il
Questi socket sono tutti nello stato \texttt{ESTABLISHED}.
\end{enumerate}
-Lo schema di funzionamento è descritto in \figref{fig:TCP_listen_backlog}:
+Lo schema di funzionamento è descritto in fig.~\ref{fig:TCP_listen_backlog}:
quando arriva un SYN da un client il server crea una nuova voce nella coda
delle connessioni incomplete, e poi risponde con il SYN$+$ACK. La voce resterà
nella coda delle connessioni incomplete fino al ricevimento dell'ACK dal
client o fino ad un timeout. Nel caso di completamento del three way handshake
la voce viene spostata nella coda delle connessioni complete. Quando il
-processo chiama la funzione \func{accept} (vedi \secref{sec:TCP_func_accept})
+processo chiama la funzione \func{accept} (vedi sez.~\ref{sec:TCP_func_accept})
la prima voce nella coda delle connessioni complete è passata al programma, o,
se la coda è vuota, il processo viene posto in attesa e risvegliato all'arrivo
della prima connessione completa.
comunque una risposta univoca per la scelta del valore, per questo non
conviene specificarlo con una costante (il cui cambiamento richiederebbe la
ricompilazione del server) ma usare piuttosto una variabile di ambiente (vedi
-\secref{sec:proc_environ}).
+sez.~\ref{sec:proc_environ}).
Stevens tratta accuratamente questo argomento in \cite{UNP1}, con esempi presi
da casi reali su web server, ed in particolare evidenzia come non sia più vero
\item[\errcode{EOPNOTSUPP}] il socket è di un tipo che non supporta questa
operazione.
\item[\errcode{EAGAIN} o \errcode{EWOULDBLOCK}] il socket è stato impostato
- come non bloccante (vedi \secref{sec:file_noblocking}), e non ci sono
+ come non bloccante (vedi sez.~\ref{sec:file_noblocking}), e non ci sono
connessioni in attesa di essere accettate.
\item[\errcode{EPERM}] Le regole del firewall non consentono la connessione.
\item[\errcode{ENOBUFS}, \errcode{ENOMEM}] questo spesso significa che
Se la funzione ha successo restituisce il descrittore di un nuovo socket
creato dal kernel (detto \textit{connected socket}) a cui viene associata la
prima connessione completa (estratta dalla relativa coda, vedi
-\secref{sec:TCP_func_listen}) che il client ha effettuato verso il socket
+sez.~\ref{sec:TCP_func_listen}) che il client ha effettuato verso il socket
\param{sockfd}. Quest'ultimo (detto \textit{listening socket}) è quello creato
all'inizio e messo in ascolto con \func{listen}, e non viene toccato dalla
funzione. Se non ci sono connessioni pendenti da accettare la funzione mette
in attesa il processo\footnote{a meno che non si sia impostato il socket per
- essere non bloccante (vedi \secref{sec:file_noblocking}), nel qual caso
+ essere non bloccante (vedi sez.~\ref{sec:file_noblocking}), nel qual caso
ritorna con l'errore \errcode{EAGAIN}. Torneremo su questa modalità di
- operazione in \secref{sec:TCP_sock_multiplexing}.} fintanto che non ne
+ operazione in sez.~\ref{sec:TCP_sock_multiplexing}.} fintanto che non ne
arriva una.
La funzione può essere usata solo con socket che supportino la connessione
\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} (torneremo su questo in \secref{sec:TCP_echo_critical}).
+\errcode{EAGAIN} (torneremo su questo in sez.~\ref{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
+ sez.~\ref{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
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_daytime_iter_server_code}, dove per ogni
+elementare di fig.~\ref{fig:TCP_daytime_iter_server_code}, dove per ogni
connessione il socket creato da \func{accept} viene chiuso dopo l'invio dei
dati.
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_daytime_cunc_server_code}, i valori di ritorno di
+fig.~\ref{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 \secref{sec:TCP_daytime_cunc_server}, lancia per ciascuna
+concorrente di sez.~\ref{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
\subsection{La funzione \func{close}}
\label{sec:TCP_func_close}
-La funzione standard Unix \func{close} (vedi \secref{sec:file_close}) che si
+La funzione standard Unix \func{close} (vedi sez.~\ref{sec:file_close}) che si
usa sui file può essere usata con lo stesso effetto anche sui file descriptor
associati ad un socket.
connessione non avesse chiuso la sua parte). Il kernel invierà comunque tutti
i dati che ha in coda prima di iniziare la sequenza di chiusura.
-Vedremo più avanti in \secref{sec:TCP_so_linger} come è possibile cambiare
+Vedremo più avanti in sez.~\ref{sec:TCP_so_linger} come è possibile cambiare
questo comportamento, e cosa deve essere fatto perché il processo possa
assicurarsi che l'altro capo abbia ricevuto tutti i dati.
di riferimenti, per cui se più di un processo ha lo stesso socket aperto
l'emissione del FIN e la sequenza di chiusura di TCP non viene innescata
fintanto che il numero di riferimenti non si annulla, questo si applica, come
-visto in \secref{sec:file_sharing}, sia ai file descriptor duplicati che a
+visto in sez.~\ref{sec:file_sharing}, sia ai file descriptor duplicati che a
quelli ereditati dagli eventuali processi figli, ed è il comportamento che ci
si aspetta in una qualunque applicazione client/server.
Per attivare immediatamente l'emissione del FIN e la sequenza di chiusura
-descritta in \secref{sec:TCP_conn_term}, si può invece usare la funzione
+descritta in sez.~\ref{sec:TCP_conn_term}, si può invece usare la funzione
\func{shutdown} su cui torneremo in seguito (vedi
-\secref{sec:TCP_shutdown}).
+sez.~\ref{sec:TCP_shutdown}).
dall'\href{http://www.ietf.org/rfc/rfc867.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 è
+sez.~\ref{sec:file_read} e sez.~\ref{sec:file_write}, che nel caso dei socket è
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.
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
+quello richiesto. Come già accennato in sez.~\ref{sec:file_read} questo è un
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.
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}).
+sez.~\ref{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
ritornare solo dopo avere letto o scritto esattamente il numero di byte
specificato; il sorgente è riportato rispettivamente in
-\figref{fig:sock_FullRead_code} e \figref{fig:sock_FullWrite_code} ed è
+fig.~\ref{fig:sock_FullRead_code} e fig.~\ref{fig:sock_FullWrite_code} ed è
disponibile fra i sorgenti allegati alla guida nei file \file{FullRead.c} e
\file{FullWrite.c}.
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. Entrambe le funzioni restituiscono 0 in caso di successo, ed un
-valore negativo in caso di errore, \texttt{FullRead} restituisce il numero di
+valore negativo in caso di errore, \func{FullRead} restituisce il numero di
byte non letti in caso di end-of-file prematuro.
\label{sec:TCP_daytime_client}
Il primo esempio di applicazione delle funzioni di base illustrate in
-\secref{sec:TCP_functions} è relativo alla creazione di un client elementare
+sez.~\ref{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/rfc867.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_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
+In fig.~\ref{fig:TCP_daytime_client_code} è riportata la sezione principale
+del codice del nostro client. Il sorgente completo del programma
+(\texttt{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.
dopo la dichiarazione delle variabili (\texttt{\small 9--12}) si è omessa
tutta la parte relativa al trattamento degli argomenti passati dalla linea di
comando (effettuata con le apposite funzioni illustrate in
-\secref{sec:proc_opt_handling}).
+sez.~\ref{sec:proc_opt_handling}).
Il primo passo (\texttt{\small 14--18}) è creare un socket TCP (quindi di tipo
\const{SOCK\_STREAM} e di famiglia \const{AF\_INET}). La funzione
35}) con il solito carattere nullo per poter essere stampata (\texttt{\small
36}) sullo standard output con l'uso di \func{fputs}.
-Come si è già spiegato in \secref{sec:sock_io_behav} la risposta dal socket
+Come si è già spiegato in sez.~\ref{sec:sock_io_behav} la risposta dal socket
potrà arrivare in un unico pacchetto di 26 byte (come avverrà senz'altro nel
caso in questione) ma potrebbe anche arrivare in 26 pacchetti di un byte. Per
questo nel caso generale non si può mai assumere che tutti i dati arrivino con
elementare, che sia anche in grado di rispondere al precedente client. Come
primo esempio realizzeremo un server iterativo, in grado di fornire una sola
risposta alla volta. Il codice del programma è nuovamente mostrato in
-\figref{fig:TCP_daytime_iter_server_code}, il sorgente completo
-(\file{TCP\_iter\_daytimed.c}) è allegato insieme agli altri file degli esempi.
+fig.~\ref{fig:TCP_daytime_iter_server_code}, il sorgente completo
+(\texttt{TCP\_iter\_daytimed.c}) è allegato insieme agli altri file degli
+esempi.
\begin{figure}[!htbp]
\footnotesize \centering
comando, se lo si volesse utilizzare come demone occorrerebbero le opportune
modifiche\footnote{come una chiamata a \func{daemon} prima dell'inizio del
ciclo principale.} per tener conto di quanto illustrato in
-\secref{sec:sess_daemon}. Si noti anche che non si è inserita nessuna forma di
-gestione della terminazione del processo, dato che tutti i file descriptor
+sez.~\ref{sec:sess_daemon}. Si noti anche che non si è inserita nessuna forma
+di gestione della terminazione del processo, dato che tutti i file descriptor
vengono chiusi automaticamente alla sua uscita, e che, non generando figli,
non è necessario preoccuparsi di gestire la loro terminazione.
\label{sec:TCP_daytime_cunc_server}
Il server \texttt{daytime} dell'esempio in
-\secref{sec:TCP_daytime_iter_server} è un tipico esempio di server iterativo,
+sez.~\ref{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}
+Come accennato anche in sez.~\ref{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
\textit{daytime} dell'esempio precedente in forma concorrente, inserendo anche
una opzione per la stampa degli indirizzi delle connessioni ricevute.
-In \figref{fig:TCP_daytime_cunc_server_code} è mostrato un estratto del
+In fig.~\ref{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.
+server, nel file \texttt{TCP\_cunc\_daytimed.c}, è allegato insieme ai
+sorgenti degli altri esempi.
\begin{figure}[!htb]
\footnotesize \centering
immediatamente (\texttt{\small 33}) il socket \var{list\_fd}; mentre il padre
continua ad operare solo sul socket in ascolto chiudendo (\texttt{\small 48})
\var{conn\_fd} al ritorno dalla \func{fork}. Per quanto abbiamo detto in
-\secref{sec:TCP_func_close} nessuna delle due chiamate a \func{close} causa
+sez.~\ref{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
descriptor non si è annullato.
\label{sec:TCP_echo_client}
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
+disponibile nel file \texttt{TCP\_echo\_first.c}, è riportato in
+fig.~\ref{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.
+sez.~\ref{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
\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}.
+sez.~\ref{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
+fig.~\ref{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
\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
+sez.~\ref{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
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
+quanto spiegato in sez.~\ref{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
+dettaglio più avanti (in sez.~\ref{sec:TCP_echo_startup}) il funzionamento del
programma, usato però con la nostra versione del server \textit{echo}, che
illustriamo immediatamente.
\subsection{Il server \textit{echo}: prima versione}
\label{sec:TCPsimp_server_main}
-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
+La prima versione del server, contenuta nel file \texttt{TCP\_echod\_first.c},
+è riportata in fig.~\ref{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
+sez.~\ref{sec:TCP_daytime_cunc_server}, e da una funzione ausiliaria
\code{ServEcho} che si cura della gestione del servizio.
\begin{figure}[!htbp]
\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
+fig.~\ref{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à
+server di sez.~\ref{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.
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
+ esposto in sez.~\ref{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
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
+alla funzione \code{PrintErr}, riportata in fig.~\ref{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
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}.
+sez.~\ref{sec:sess_daemon}. Come accennato questo è stato fatto utilizzando
+come \textit{wrapper} la funzione \code{PrintErr}, il cui codice è riportato
+in fig.~\ref{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
+ 3}) si usa \func{syslog} (vedi sez.~\ref{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
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
+fig.~\ref{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
+funzione \func{FullWrite} (descritta in fig.~\ref{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}.
\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}).
+tab.~\ref{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
+in sez.~\ref{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
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
- 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
+ (si ricordi quanto detto in sez.~\ref{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}).
+ sez.~\ref{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
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
+esaminato in sez.~\ref{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à
+(si riveda quanto illustrato in sez.~\ref{sec:sig_sigchld}), come risulterà
ripetendo il comando \cmd{ps}:
\begin{verbatim}
2356 pts/0 S 0:00 ./echod
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
+sez.~\ref{sec:proc_wait}), cosa che faremo utilizzando \const{SIGCHLD} secondo
+quanto illustrato in sez.~\ref{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
+\code{Signal} (che abbiamo illustrato in fig.~\ref{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
+visto in fig.~\ref{fig:sig_sigchld_handl}. Basterà allora aggiungere il
seguente codice: \includecodesnip{listati/sigchildhand.c}
\noindent
-all'esempio illustrato in \figref{fig:TCP_echo_server_first_code}.
+all'esempio illustrato in fig.~\ref{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
+come spiegato in sez.~\ref{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
accept error: Interrupted system call
\end{verbatim}%#
-Come accennato in \secref{sec:sig_gen_beha} le conseguenze di questo
+Come accennato in sez.~\ref{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
+rispetto a quanto visto in fig.~\ref{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
+ allegati.} come mostrato in fig.~\ref{fig:sig_SignalRestart_code}, ed
installeremo il gestore usando quest'ultima.
\begin{figure}[!htb]
\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
+illustrata in fig.~\ref{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
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
+mostrata in fig.~\ref{fig:TCP_echo_server_code_second}, dove si sono riportate
la sezioni di codice modificate nella seconda versione del programma, il
-codice completo di quest'ultimo si trova nel file \file{TCP\_echod\_second.c}
-dei sorgenti allegati alla guida.
+codice completo di quest'ultimo si trova nel file
+\texttt{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
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
+fig.~\ref{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.
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
+fig.~\ref{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
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
\index{system call lente} \textit{slow system call}\footnote{si ricordi la
- distinzione fatta in \secref{sec:sig_gen_beha}.} o sono chiamate prima di
+ distinzione fatta in sez.~\ref{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 25--31}) in cui si effettua la chiamata di
+ 23--42}), rispetto precedente versione di fig.~\ref{fig:TCP_ServEcho_first},
+è nella sezione (\texttt{\small 25--31}) 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 è
Infine come ulteriore miglioria si è perfezionata la funzione \code{ServEcho},
sia per tenere conto della nuova funzionalità di debugging, che per effettuare
un controllo in caso di errore; il codice della nuova versione è mostrato in
-\figref{fig:TCP_ServEcho_second}.
+fig.~\ref{fig:TCP_ServEcho_second}.
\begin{figure}[!htb]
\footnotesize \centering
\label{fig:TCP_ServEcho_second}
\end{figure}
-Rispetto alla precedente versione di \figref{fig:TCP_ServEcho_first} in questo
-caso si è provveduto a controllare (\texttt{\small 7--10}) il valore di
+Rispetto alla precedente versione di fig.~\ref{fig:TCP_ServEcho_first} in
+questo caso si è provveduto a controllare (\texttt{\small 7--10}) il valore di
ritorno di \func{read} per rilevare un eventuale errore, in modo da stampare
(\texttt{\small 8}) un messaggio di errore e ritornare (\texttt{\small 9})
concludendo la connessione.
\section{I vari scenari critici}
\label{sec:TCP_echo_critical}
-Con le modifiche viste in \secref{sec:TCP_child_hand} il nostro esempio
+Con le modifiche viste in sez.~\ref{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 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
+accennato in sez.~\ref{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à
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
+del tipo di quello mostrato in fig.~\ref{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}.
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
+a quella illustrata in fig.~\ref{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
+abbiamo trattato in sez.~\ref{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
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
+attraverso la sequenza vista in sez.~\ref{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
seguito dal numero di sequenza per il quale si da il ricevuto; quest'ultimo, a
partire dal terzo pacchetto, viene espresso in forma relativa per maggiore
compattezza. Il campo \texttt{win} in ogni riga indica la \textit{advertising
- window} di cui parlavamo in \secref{sec:TCP_TCP_opt}. Allora si può
+ window} di cui parlavamo in sez.~\ref{sec:TCP_TCP_opt}. Allora si può
verificare dall'output del comando come venga appunto realizzata la sequenza
-di pacchetti descritta in \secref{sec:TCP_conn_cre}: prima viene inviato dal
+di pacchetti descritta in sez.~\ref{sec:TCP_conn_cre}: prima viene inviato dal
client un primo pacchetto con il SYN che inizia la connessione, a cui il
server risponde dando il ricevuto con un secondo pacchetto, che a sua volta
porta un SYN, cui il client risponde con un il terzo pacchetto di ricevuto.
facciamo questo vengono immediatamente generati altri due pacchetti. La
terminazione del processo infatti comporta la chiusura di tutti i suoi file
descriptor, il che comporta, per il socket che avevamo aperto, l'inizio della
-sequenza di chiusura illustrata in \secref{sec:TCP_conn_term}. Questo
+sequenza di chiusura illustrata in sez.~\ref{sec:TCP_conn_term}. Questo
significa che dal server partirà un FIN, che è appunto il primo dei due
pacchetti, contraddistinto dalla lettera \texttt{F}, cui seguirà al solito un
ACK da parte del client.
definitiva della connessione anche nel client, dove non comparirà più
nell'output di \cmd{netstat}.
-Come abbiamo accennato in \secref{sec:TCP_conn_term} e come vedremo più avanti
-in \secref{sec:TCP_shutdown} la chiusura di un solo capo di un socket è
+Come abbiamo accennato in sez.~\ref{sec:TCP_conn_term} e come vedremo più avanti
+in sez.~\ref{sec:TCP_shutdown} la chiusura di un solo capo di un socket è
una operazione lecita, per cui la nostra scrittura avrà comunque successo
(come si può constatare lanciando usando \cmd{strace}\footnote{il comando
\cmd{strace} è un comando di debug molto utile che prende come parametro un
del socket, ma è completamente terminato il programma.
Per questo motivo il nostro client proseguirà leggendo dal socket, e dato che
-questo è stato chiuso avremo che, come spiegato in \secref{sec:TCP_conn_term},
-la funzione \func{read} ritorna normalmente con un valore nullo. Questo
-comporta che la seguente chiamata a \func{fputs} non ha effetto (viene
-stampata una stringa nulla) ed il client si blocca di nuovo nella successiva
-chiamata a \func{fgets}. Per questo diventa possibile inserire una terza riga
-e solo dopo averlo fatto si avrà la terminazione del programma.
+questo è stato chiuso avremo che, come spiegato in
+sez.~\ref{sec:TCP_conn_term}, la funzione \func{read} ritorna normalmente con
+un valore nullo. Questo comporta che la seguente chiamata a \func{fputs} non
+ha effetto (viene stampata una stringa nulla) ed il client si blocca di nuovo
+nella successiva chiamata a \func{fgets}. Per questo diventa possibile
+inserire una terza riga e solo dopo averlo fatto si avrà la terminazione del
+programma.
Per capire come questa avvenga comunque, non avendo inserito nel codice nessun
controllo di errore, occorre ricordare che, a parte la bidirezionalità del
flusso dei dati, dal punto di vista del funzionamento nei confronti delle
funzioni di lettura e scrittura, i socket sono del tutto analoghi a delle
-pipe. Allora, da quanto illustrato in \secref{sec:ipc_pipes}, sappiamo che
+pipe. Allora, da quanto illustrato in sez.~\ref{sec:ipc_pipes}, sappiamo che
tutte le volte che si cerca di scrivere su una pipe il cui altro capo non è
aperto il lettura il processo riceve un segnale di \const{SIGPIPE}, e questo è
esattamente quello che avviene in questo caso, e siccome non abbiamo un
modificare il nostro client perché sia in grado di trattare le varie tipologie
di errore, per questo dovremo riscrivere la funzione \func{ClientEcho}, in
modo da controllare gli stati di uscita delle varie chiamate. Si è riportata
-la nuova versione della funzione in \figref{fig:TCP_ClientEcho_second}.
+la nuova versione della funzione in fig.~\ref{fig:TCP_ClientEcho_second}.
\begin{figure}[!htb]
\footnotesize \centering
fare con la necessità di lavorare con più descrittori, nel qual caso diventa
si pone la questione di come fare a non restare bloccati su un socket quando
altri potrebbero essere liberi. Vedremo come affrontare questa problematica in
-\secref{sec:TCP_sock_multiplexing}.
+sez.~\ref{sec:TCP_sock_multiplexing}.
\subsection{Altri scenari di terminazione della connessione}
pacchetto sono cessati, per essere sostituiti da una serie di richieste di
protocollo ARP in cui il client richiede l'indirizzo del server.
-Come abbiamo accennato in \secref{sec:net_tcpip_general} ARP è il protocollo
-che si incarica di trovare le corrispondenze corrispondenze fra indirizzo IP e
-indirizzo hardware sulla scheda di rete. È evidente allora che nel nostro
-caso, essendo client e server sulla stessa rete, è scaduta la voce nella
-\textit{ARP cache}\footnote{la \textit{ARP chache} è una tabella mantenuta
- internamente dal kernel che contiene tutte le corrispondenze fra indirizzi
- IP e indirizzi fisici, ottenute appunto attraverso il protocollo ARP; le
- voci della tabella hanno un tempo di vita limitato, passato il quale scadono
- e devono essere nuovamente richieste.} relativa ad \texttt{anarres}, ed il
-nostro client ha iniziato ad effettuare richieste ARP sulla rete per sapere
-l'IP di quest'ultimo, che essendo scollegato non poteva rispondere. Anche per
-questo tipo di richieste esiste un timeout, per cui dopo un certo numero di
-tentativi il meccanismo si è interrotto, e l'errore riportato al programma a
-questo punto è stato \errcode{EHOSTUNREACH}, in quanto non si era più in grado
-di contattare il server.
+Come abbiamo accennato in sez.~\ref{sec:net_tcpip_general} ARP è il protocollo
+che si incarica di trovare le corrispondenze fra indirizzo IP e indirizzo
+hardware sulla scheda di rete. È evidente allora che nel nostro caso, essendo
+client e server sulla stessa rete, è scaduta la voce nella \textit{ARP
+ cache}\footnote{la \textit{ARP chache} è una tabella mantenuta internamente
+ dal kernel che contiene tutte le corrispondenze fra indirizzi IP e indirizzi
+ fisici, ottenute appunto attraverso il protocollo ARP; le voci della tabella
+ hanno un tempo di vita limitato, passato il quale scadono e devono essere
+ nuovamente richieste.} relativa ad \texttt{anarres}, ed il nostro client ha
+iniziato ad effettuare richieste ARP sulla rete per sapere l'IP di
+quest'ultimo, che essendo scollegato non poteva rispondere. Anche per questo
+tipo di richieste esiste un timeout, per cui dopo un certo numero di tentativi
+il meccanismo si è interrotto, e l'errore riportato al programma a questo
+punto è stato \errcode{EHOSTUNREACH}, in quanto non si era più in grado di
+contattare il server.
Un altro errore possibile in questo tipo di situazione, che si può avere
quando la macchina è su una rete remota, è \errcode{ENETUNREACH}; esso viene
si vuole che il client sia in grado di accorgersi del crollo del server anche
quando non sta effettuando uno scambio di dati, è possibile usare una
impostazione speciale del socket (ci torneremo in
-\secref{sec:TCP_sock_options}) che provvede all'esecuzione di questo
+sez.~\ref{sec:TCP_sock_options}) che provvede all'esecuzione di questo
controllo.
\section{L'uso dell'I/O multiplexing}
\label{sec:TCP_sock_multiplexing}
Affronteremo in questa sezione l'utilizzo dell'I/O multiplexing, affrontato in
-\secref{sec:file_multiplexing}, nell'ambito delle applicazioni di rete. Già in
-\secref{sec:TCP_server_crash} era emerso il problema relativo al client del
-servizio echo che non era in grado di accorgersi della terminazione precoce
-del server, essendo bloccato nella lettura dei dati immessi da tastiera.
-
-Abbiamo visto in \secref{sec:file_multiplexing} quali sono le funzionalità del
-sistema che ci permettono di tenere sotto controllo più file descriptor in
+sez.~\ref{sec:file_multiplexing}, nell'ambito delle applicazioni di rete. Già
+in sez.~\ref{sec:TCP_server_crash} era emerso il problema relativo al client
+del servizio echo che non era in grado di accorgersi della terminazione
+precoce del server, essendo bloccato nella lettura dei dati immessi da
+tastiera.
+
+Abbiamo visto in sez.~\ref{sec:file_multiplexing} quali sono le funzionalità
+del sistema che ci permettono di tenere sotto controllo più file descriptor in
contemporanea; in quella occasione non abbiamo fatto esempi, in quanto quando
si tratta con file normali questa tipologia di I/O normalmente non viene
usata, è invece un caso tipico delle applicazioni di rete quello di dover
Iniziamo con la prima delle funzioni usate per l'I/O multiplexing,
\func{select}; il suo funzionamento è già stato descritto in dettaglio in
-\secref{sec:file_multiplexing} e non staremo a ripetere quanto detto lì;
+sez.~\ref{sec:file_multiplexing} e non staremo a ripetere quanto detto lì;
sappiamo che la funzione ritorna quando uno o più dei file descriptor messi
sotto controllo è pronto per la relativa operazione.
sufficiente a superare il valore di una \textsl{soglia di basso livello} (il
cosiddetto \textit{low watermark}). Questo valore è espresso in numero di
byte e può essere impostato con l'opzione del socket \const{SO\_RCVLOWAT}
- (tratteremo le opzioni dei socket in \secref{sec:TCP_sock_options}); il suo
- valore di default è 1 per i socket TCP e UDP. In questo caso una operazione
- di lettura avrà successo e leggerà un numero di byte maggiore di zero.
+ (tratteremo le opzioni dei socket in sez.~\ref{sec:TCP_sock_options}); il
+ suo valore di default è 1 per i socket TCP e UDP. In questo caso una
+ operazione di lettura avrà successo e leggerà un numero di byte maggiore di
+ zero.
\item il lato in lettura della connessione è stato chiuso; si è cioè ricevuto
- un segmento FIN (si ricordi quanto illustrato in \secref{sec:TCP_conn_term})
- sulla connessione. In questo caso una operazione di lettura avrà successo,
- ma non risulteranno presenti dati (in sostanza \func{read} ritornerà con un
- valore nullo) per indicare la condizione di end-of-file.
+ un segmento FIN (si ricordi quanto illustrato in
+ sez.~\ref{sec:TCP_conn_term}) sulla connessione. In questo caso una
+ operazione di lettura avrà successo, ma non risulteranno presenti dati (in
+ sostanza \func{read} ritornerà con un valore nullo) per indicare la
+ condizione di end-of-file.
\item c'è stato un errore sul socket. In questo caso una operazione di lettura
non si bloccherà ma restituirà una condizione di errore (ad esempio
\func{read} restituirà -1) e imposterà la variabile \var{errno} al relativo
- valore. Vedremo in \secref{sec:TCP_sock_options} come sia possibile estrarre
- e cancellare errori pendenti su un socket usando l'opzione
+ valore. Vedremo in sez.~\ref{sec:TCP_sock_options} come sia possibile
+ estrarre e cancellare errori pendenti su un socket usando l'opzione
\const{SO\_ERROR}.
\item quando si sta utilizzando un \textit{listening socket} ed ci sono delle
connessioni completate. In questo caso la funzione \func{accept} non si
bloccherà.\footnote{in realtà questo non è sempre vero, come accennato in
- \secref{sec:TCP_conn_early_abort} una connessione può essere abortita
+ sez.~\ref{sec:TCP_conn_early_abort} una connessione può essere abortita
dalla ricezione di un segmento RST una volta che è stata completata,
allora se questo avviene dopo che \func{select} è ritornata, ma prima
della chiamata ad \func{accept}, quest'ultima, in assenza di altre
\item c'è stato un errore sul socket. In questo caso una operazione di
scrittura non si bloccherà ma restituirà una condizione di errore ed
imposterà opportunamente la variabile \var{errno}. Vedremo in
- \secref{sec:TCP_sock_options} come sia possibile estrarre e cancellare
+ sez.~\ref{sec:TCP_sock_options} come sia possibile estrarre e cancellare
errori pendenti su un socket usando l'opzione \const{SO\_ERROR}.
\end{itemize*}
che un socket (che sarà riportato nel terzo insieme di file descriptor) ha una
condizione di eccezione pendente, e cioè la ricezione sul socket di dati
\textsl{fuori banda} (o \textit{out-of-band}), una caratteristica specifica
-dei socket TCP su cui torneremo in \secref{sec:TCP_urgent_data}.
+dei socket TCP su cui torneremo in sez.~\ref{sec:TCP_urgent_data}.
Si noti come nel caso della lettura \func{select} si applichi anche ad
operazioni che non hanno nulla a che fare con l'I/O di dati come il
Abbiamo incontrato la problematica tipica che conduce all'uso dell'I/O
multiplexing nella nostra analisi degli errori in
-\secref{sec:TCP_conn_early_abort}, quando il nostro client non era in grado di
-rendersi conto di errori sulla connessione essendo impegnato nella attesa di
-dati in ingresso dallo standard input.
+sez.~\ref{sec:TCP_conn_early_abort}, quando il nostro client non era in grado
+di rendersi conto di errori sulla connessione essendo impegnato nella attesa
+di dati in ingresso dallo standard input.
In questo caso il problema è quello di dover tenere sotto controllo due
diversi file descriptor, lo standard input, da cui viene letto il testo che
Nel nostro caso quello che ci interessa è non essere bloccati in lettura sullo
standard input in caso di errori sulla connessione o chiusura della stessa da
parte del server. Entrambi questi casi possono essere rilevati usando
-\func{select}, per quanto detto in \secref{sec:TCP_sock_select}, mettendo
+\func{select}, per quanto detto in sez.~\ref{sec:TCP_sock_select}, mettendo
sotto osservazione i file descriptor per la condizione di essere pronti in
lettura: sia infatti che si ricevano dati, che la connessione sia chiusa
regolarmente (con la ricezione di un segmento FIN) che si riceva una
Riprendiamo allora il codice del client, modificandolo per l'uso di
\func{select}. Quello che dobbiamo modificare è la funzione \func{ClientEcho}
-di \figref{fig:TCP_ClientEcho_second}, dato che tutto il resto, che riguarda
+di fig.~\ref{fig:TCP_ClientEcho_second}, dato che tutto il resto, che riguarda
le modalità in cui viene stabilita la connessione con il server, resta
assolutamente identico. La nostra nuova versione di \func{ClientEcho}, la
-terza della serie, è riportata in \figref{fig:TCP_ClientEcho_third}, il codice
-completo si trova nel file \file{TCP\_echo\_third.c} dei sorgenti allegati alla
-guida.
+terza della serie, è riportata in fig.~\ref{fig:TCP_ClientEcho_third}, il
+codice completo si trova nel file \file{TCP\_echo\_third.c} dei sorgenti
+allegati alla guida.
In questo caso la funzione comincia (\texttt{\small 8--9}) con l'azzeramento
del file descriptor set \var{fset} e l'impostazione del valore \var{maxfd}, da
scritto. Ma adesso il client diventa capace di accorgersi immediatamente della
terminazione del server; in tal caso infatti il server chiuderà il socket
connesso, ed alla ricezione del FIN la funzione \func{select} ritornerà (come
-illustrato in \secref{sec:TCP_sock_select}) segnalando una condizione di end
+illustrato in sez.~\ref{sec:TCP_sock_select}) segnalando una condizione di end
of file, per cui il nostro client potrà uscire immediatamente.
-Riprendiamo la situazione affrontata in \secref{sec:TCP_server_crash},
+Riprendiamo la situazione affrontata in sez.~\ref{sec:TCP_server_crash},
terminando il server durante una connessione, in questo caso quello che
otterremo, una volta scritta una prima riga ed interrotto il server con un
\texttt{C-c}, sarà:
connesso è stato chiuso ed uscire immediatamente.
Veniamo allora agli altri scenari di terminazione anomala visti in
-\secref{sec:TCP_conn_crash}. Il primo di questi è l'interruzione fisica della
+sez.~\ref{sec:TCP_conn_crash}. Il primo di questi è l'interruzione fisica della
connessione; in questo caso avremo un comportamento analogo al precedente, in
cui si scrive una riga e non si riceve risposta dal server e non succede
niente fino a quando non si riceve un errore di \errcode{EHOSTUNREACH} o
in cui, una volta riconnessa la rete, tutto quello che abbiamo scritto durante
il periodo di disconnessione restituito indietro e stampato immediatamente.
-Lo stesso comportamento visto in \secref{sec:TCP_server_crash} si riottiene
+Lo stesso comportamento visto in sez.~\ref{sec:TCP_server_crash} si riottiene
nel caso di un crollo completo della macchina su cui sta il server. In questo
caso di nuovo il client non è in grado di accorgersi di niente dato che si
suppone che il programma server non venga terminato correttamente, ma si
blocchi tutto senza la possibilità di avere l'emissione di un segmento FIN che
segnala la terminazione della connessione. Di nuovo fintanto che la
-connessione non si riattiva )con il riavvio della macchina del server) il
+connessione non si riattiva (con il riavvio della macchina del server) il
client non è in grado di fare altro che accettare dell'input e tentare di
inviarlo. La differenza in questo caso è che non appena la connessione
ridiventa attiva i dati verranno sì trasmessi, ma essendo state perse tutte le
\subsection{La funzione \func{shutdown}}
\label{sec:TCP_shutdown}
-Come spiegato in \secref{sec:TCP_conn_term} il procedimento di chiusura di un
+Come spiegato in sez.~\ref{sec:TCP_conn_term} il procedimento di chiusura di un
socket TCP prevede che da entrambe le parti venga emesso un segmento FIN. È
pertanto del tutto normale dal punto di vista del protocollo che uno dei due
capi chiuda la connessione, quando l'altro capo la lascia
aperta.\footnote{abbiamo incontrato questa situazione nei vari scenari critici
- di \secref{sec:TCP_echo_critical}.}
+ di sez.~\ref{sec:TCP_echo_critical}.}
È pertanto possibile avere una situazione in cui un capo della connessione non
avendo più nulla da scrivere, possa chiudere il socket, segnalando così
closed}.
Il problema che si pone è che se la chiusura del socket è effettuata con la
-funzione \func{close}, come spiegato in \secref{sec:TCP_func_close}, si perde
+funzione \func{close}, come spiegato in sez.~\ref{sec:TCP_func_close}, si perde
ogni possibilità di poter rileggere quanto l'altro capo può continuare a
scrivere. Per poter permettere allora di segnalare che si è concluso con la
scrittura, continuando al contempo a leggere quanto può provenire dall'altro
l'emissione di un segmento FIN, secondo la procedura chiamata
\textit{half-close}. Tutti i dati presenti nel buffer di scrittura prima
della chiamata saranno inviati, seguiti dalla sequenza di chiusura
- illustrata in \secref{sec:TCP_conn_term}.
+ illustrata in sez.~\ref{sec:TCP_conn_term}.
\item[\macro{SHUT\_RDWR}] chiude sia il lato in lettura che quello in
scrittura del socket. È equivalente alla chiamata in sequenza con
\macro{SHUT\_RD} e \macro{SHUT\_WR}.
cui si avrebbe potuto avere l'impressione che sia una corrispondenza univoca
fra un socket ed il file descriptor con cui vi si accede. Questo non è
assolutamente vero, (e lo abbiamo già visto nel codice del server di
-\figref{fig:TCP_echo_server_first_code}), ed è invece assolutamente normale
+fig.~\ref{fig:TCP_echo_server_first_code}), ed è invece assolutamente normale
che, come per gli altri oggetti, ci possano essere più file descriptor che
fanno riferimento allo stesso socket.
di \func{close} si limiterà a deallocare nel processo corrente il file
descriptor utilizzato, ma il socket resterà pienamente accessibile attraverso
tutti gli altri riferimenti. Se torniamo all'esempio originale del server di
-\figref{fig:TCP_echo_server_first_code} abbiamo infatti che ci sono due
+fig.~\ref{fig:TCP_echo_server_first_code} abbiamo infatti che ci sono due
\func{close}, una sul socket connesso nel padre, ed una sul socket in ascolto
nel figlio, ma queste non effettuano nessuna chiusura reale di detti socket,
dato che restano altri riferimenti attivi, uno al socket connesso nel figlio
quello che viene stimato con l'uso del comando \cmd{ping}.
A questo punto, se torniamo al codice mostrato in
-\figref{fig:TCP_ClientEcho_third}, possiamo vedere che mentre i pacchetti sono
-in transito sulla rete il client continua a leggere e a scrivere fintanto che
-il file in ingresso finisce. Però non appena viene ricevuto un end-of-file in
-ingresso il nostro client termina. Nel caso interattivo, in cui si inviavano
-brevi stringhe una alla volta, c'era sempre il tempo di eseguire la lettura
-completa di quanto il server rimandava indietro. In questo caso invece, quando
-il client termina, essendo la comunicazione saturata e a piena velocità, ci
-saranno ancora pacchetti in transito sulla rete che devono arrivare al server
-e poi tornare indietro, ma siccome il client esce immediatamente dopo la fine
-del file in ingresso, questi non faranno a tempo a completare il percorso e
-verranno persi.
+fig.~\ref{fig:TCP_ClientEcho_third}, possiamo vedere che mentre i pacchetti
+sono in transito sulla rete il client continua a leggere e a scrivere fintanto
+che il file in ingresso finisce. Però non appena viene ricevuto un end-of-file
+in ingresso il nostro client termina. Nel caso interattivo, in cui si
+inviavano brevi stringhe una alla volta, c'era sempre il tempo di eseguire la
+lettura completa di quanto il server rimandava indietro. In questo caso
+invece, quando il client termina, essendo la comunicazione saturata e a piena
+velocità, ci saranno ancora pacchetti in transito sulla rete che devono
+arrivare al server e poi tornare indietro, ma siccome il client esce
+immediatamente dopo la fine del file in ingresso, questi non faranno a tempo a
+completare il percorso e verranno persi.
Per evitare questo tipo di problema, invece di uscire una volta completata la
lettura del file in ingresso, occorre usare \func{shutdown} per effettuare la
\label{fig:TCP_ClientEcho}
\end{figure}
-Si è allora riportato in \figref{fig:TCP_ClientEcho} la versione finale della
-nostra funzione \func{ClientEcho}, in grado di gestire correttamente l'intero
-flusso di dati fra client e server. Il codice completo del client,
+Si è allora riportato in fig.~\ref{fig:TCP_ClientEcho} la versione finale
+della nostra funzione \func{ClientEcho}, in grado di gestire correttamente
+l'intero flusso di dati fra client e server. Il codice completo del client,
comprendente la gestione delle opzioni a riga di comando e le istruzioni per
-la creazione della connessione, si trova nel file \file{TCP\_echo.c},
-distribuito coi sorgenti allegati alla guida.
+la creazione della connessione, si trova nel file
+\texttt{TCP\_echo\_fourth.c}, distribuito coi sorgenti allegati alla guida.
La nuova versione è molto simile alla precedente di
-\figref{fig:TCP_ClientEcho_third}; la prima differenza è l'introduzione
+fig.~\ref{fig:TCP_ClientEcho_third}; la prima differenza è l'introduzione
(\texttt{\small 7}) della variabile \var{eof}, inizializzata ad un valore
nullo, che serve a mantenere traccia dell'avvenuta conclusione della lettura
del file in ingresso.
connessione.\footnote{ne faremo comunque una implementazione diversa rispetto
a quella presentata da Stevens in \cite{UNP1}.}
-La struttura del nuovo server è illustrata in \figref{fig:TCP_echo_multiplex},
-in questo caso avremo un solo processo che ad ogni nuova connessione da parte
-di un client sul socket in ascolto si limiterà a registrare l'entrata in uso
-di un nuovo file descriptor ed utilizzerà \func{select} per rilevare la
-presenza di dati in arrivo su tutti i file descriptor attivi, operando
-direttamente su ciascuno di essi.
+La struttura del nuovo server è illustrata in
+fig.~\ref{fig:TCP_echo_multiplex}, in questo caso avremo un solo processo che
+ad ogni nuova connessione da parte di un client sul socket in ascolto si
+limiterà a registrare l'entrata in uso di un nuovo file descriptor ed
+utilizzerà \func{select} per rilevare la presenza di dati in arrivo su tutti i
+file descriptor attivi, operando direttamente su ciascuno di essi.
\begin{figure}[htb]
\centering
\end{figure}
La sezione principale del codice del nuovo server è illustrata in
-\figref{fig:TCP_SelectEchod}. Si è tralasciata al solito la gestione delle
+fig.~\ref{fig:TCP_SelectEchod}. Si è tralasciata al solito la gestione delle
opzioni, che è identica alla versione precedente. Resta invariata anche tutta
la parte relativa alla gestione dei segnali, degli errori, e della cessione
dei privilegi, così come è identica la gestione della creazione del socket (si
può fare riferimento al codice già illustrato in
-\secref{sec:TCPsimp_server_main}); al solito il codice completo del server è
+sez.~\ref{sec:TCPsimp_server_main}); al solito il codice completo del server è
disponibile coi sorgenti allegati nel file \texttt{select\_echod.c}.
\begin{figure}[!htbp]
In questo caso, una volta aperto e messo in ascolto il socket, tutto quello
che ci servirà sarà chiamare \func{select} per rilevare la presenza di nuove
connessioni o di dati in arrivo, e processarli immediatamente. Per
-implementare lo schema mostrato in \figref{fig:TCP_echo_multiplex}, il
+implementare lo schema mostrato in fig.~\ref{fig:TCP_echo_multiplex}, il
programma usa una tabella dei socket connessi mantenuta nel vettore
\var{fd\_open} dimensionato al valore di \macro{FD\_SETSIZE}, ed una variabile
\var{max\_fd} per registrare il valore più alto dei file descriptor aperti.
trovati attivi.
Per far questo si usa la caratteristica dei file descriptor, descritta in
-\secref{sec:file_open}, per cui il kernel associa sempre ad ogni nuovo file il
-file descriptor con il valore più basso disponibile. Questo fa sì che si possa
-eseguire il ciclo (\texttt{\small 8}) a partire da un valore minimo, che sarà
-sempre quello del socket in ascolto, mantenuto in \var{list\_fd}, fino al
+sez.~\ref{sec:file_open}, per cui il kernel associa sempre ad ogni nuovo file
+il file descriptor con il valore più basso disponibile. Questo fa sì che si
+possa eseguire il ciclo (\texttt{\small 8}) a partire da un valore minimo, che
+sarà sempre quello del socket in ascolto, mantenuto in \var{list\_fd}, fino al
valore massimo di \var{max\_fd} che dovremo aver cura di tenere aggiornato.
Dopo di che basterà controllare (\texttt{\small 9}) nella nostra tabella se il
file descriptor è in uso o meno,\footnote{si tenga presente che benché il
Una volta inizializzato con i socket aperti il nostro \textit{file descriptor
set} potremo chiamare \func{select} per fargli osservare lo stato degli
stessi (in lettura, presumendo che la scrittura sia sempre consentita). Come
-per il precedente esempio di \secref{sec:TCP_child_hand}, essendo questa
+per il precedente esempio di sez.~\ref{sec:TCP_child_hand}, essendo questa
l'unica funzione che può bloccarsi, ed essere interrotta da un segnale, la
eseguiremo (\texttt{\small 11--12}) all'interno di un ciclo di \code{while}
che la ripete indefinitamente qualora esca con un errore di \errcode{EINTR}.
\func{FullWrite} per riscriverli indietro sul socket stesso, avendo cura di
uscire con un messaggio in caso di errore (\texttt{\small 50--53}). Si noti
che nel ciclo si esegue una sola lettura, contrariamente a quanto fatto con la
-precedente versione (si riveda il codice di \secref{fig:TCP_ServEcho_second})
+precedente versione (si riveda il codice di fig.~\ref{fig:TCP_ServEcho_second})
in cui si continuava a leggere fintanto che non si riceveva un
\textit{end-of-file}, questo perché usando l'\textit{I/O multiplexing} non si
vuole essere bloccati in lettura. L'uso di \func{select} ci permette di
impiegando la funzione \func{select}; questo è quello che avviene nella
maggior parte dei casi, in quanto essa è nata sotto BSD proprio per affrontare
queste problematiche con i socket. Abbiamo però visto in
-\secref{sec:file_multiplexing} come la funzione \func{poll} possa costituire
+sez.~\ref{sec:file_multiplexing} come la funzione \func{poll} possa costituire
una alternativa a \func{select}, con alcuni vantaggi.\footnote{non soffrendo
delle limitazioni dovute all'uso dei \textit{file descriptor set}.}
-Ancora una volta in \secref{sec:file_poll} abbiamo trattato la funzione in
+Ancora una volta in sez.~\ref{sec:file_poll} abbiamo trattato la funzione in
maniera generica, parlando di file descriptor, ma come per \func{select}
quando si ha a che fare con dei socket il concetto di essere \textsl{pronti}
per l'I/O deve essere specificato nei dettagli, per tener conto delle
\end{itemize}
Come esempio dell'uso di \func{poll} proviamo allora a reimplementare il
-server \textit{echo} secondo lo schema di \figref{fig:TCP_echo_multiplex}
+server \textit{echo} secondo lo schema di fig.~\ref{fig:TCP_echo_multiplex}
usando \func{poll} al posto di \func{select}. In questo caso dovremo fare
qualche modifica, per tenere conto della diversa sintassi delle due funzioni,
ma la struttura del programma resta sostanzialmente la stessa.
\label{fig:TCP_PollEchod}
\end{figure}
-In \figref{fig:TCP_PollEchod} è riportata la sezione principale della nuova
+In fig.~\ref{fig:TCP_PollEchod} è riportata la sezione principale della nuova
versione del server, la versione completa del codice è riportata nel file
-\file{poll\_echod.c} dei sorgenti allegati alla guida. Al solito nella figura
-si sono tralasciate la gestione delle opzioni, la creazione del socket in
-ascolto, la cessione dei privilegi e le operazioni necessarie a far funzionare
-il programma come demone, privilegiando la sezione principale del programma.
+\texttt{poll\_echod.c} dei sorgenti allegati alla guida. Al solito nella
+figura si sono tralasciate la gestione delle opzioni, la creazione del socket
+in ascolto, la cessione dei privilegi e le operazioni necessarie a far
+funzionare il programma come demone, privilegiando la sezione principale del
+programma.
Come per il precedente server basato su \func{select} il primo passo
(\texttt{\small 2--8}) è quello di inizializzare le variabili necessarie. Dato
uscita e notifica in caso si errore (\texttt{\small 49--52}).
Come si può notare la logica del programma è identica a quella vista in
-\figref{fig:TCP_SelectEchod} per l'analogo server basato su \func{select}; la
+fig.~\ref{fig:TCP_SelectEchod} per l'analogo server basato su \func{select}; la
sola differenza significativa è che in questo caso non c'è bisogno di
rigenerare i file descriptor set in quanto l'uscita è indipendente dai dati in
ingresso. Si applicano comunque anche a questo server le considerazioni finali
-di \secref{sec:TCP_serv_select}.
+di sez.~\ref{sec:TCP_serv_select}.
projects / gapil.git / blobdiff