Aggiornamento copyright e inizio aggiornameto parte sui socket.
[gapil.git] / tcpsock.tex
1 %% tcpsock.tex
2 %%
3 %% Copyright (C) 2000-2016 Simone Piccardi.  Permission is granted to
4 %% copy, distribute and/or modify this document under the terms of the GNU Free
5 %% Documentation License, Version 1.1 or any later version published by the
6 %% Free Software Foundation; with the Invariant Sections being "Un preambolo",
7 %% with no Front-Cover Texts, and with no Back-Cover Texts.  A copy of the
8 %% license is included in the section entitled "GNU Free Documentation
9 %% License".
10 %%
11
12 \chapter{I socket TCP}
13 \label{cha:TCP_socket}
14
15 In questo capitolo tratteremo le basi dei socket TCP, iniziando con una
16 descrizione delle principali caratteristiche del funzionamento di una
17 connessione TCP; vedremo poi le varie funzioni che servono alla creazione di
18 una connessione fra client e server, fornendo alcuni esempi elementari, e
19 finiremo prendendo in esame l'uso dell'I/O multiplexing.
20
21
22 \section{Il funzionamento di una connessione TCP}
23 \label{sec:TCP_connession}
24
25 Prima di entrare nei dettagli delle singole funzioni usate nelle applicazioni
26 che utilizzano i socket TCP, è fondamentale spiegare alcune delle basi del
27 funzionamento del protocollo, poiché questa conoscenza è essenziale per
28 comprendere il comportamento di dette funzioni per questo tipo di socket, ed
29 il relativo modello di programmazione.
30
31 Si ricordi che il protocollo TCP serve a creare degli \textit{stream socket},
32 cioè una forma di canale di comunicazione che stabilisce una connessione
33 stabile fra due stazioni, in modo che queste possano scambiarsi dei dati. In
34 questa sezione ci concentreremo sulle modalità con le quali il protocollo dà
35 inizio e conclude una connessione e faremo inoltre un breve accenno al
36 significato di alcuni dei vari \textsl{stati} ad essa associati.
37
38
39 \subsection{La creazione della connessione: il \textit{three way handshake}}
40 \label{sec:TCP_conn_cre}
41
42 \itindbeg{three~way~handshake} 
43
44 Il processo che porta a creare una connessione TCP viene chiamato
45 \textit{three way handshake}; la successione tipica degli eventi (e dei
46 \textsl{segmenti}\footnote{si ricordi che il segmento è l'unità elementare di
47   dati trasmessa dal protocollo TCP al livello successivo; tutti i segmenti
48   hanno un header che contiene le informazioni che servono allo \textit{stack
49     TCP} (così viene di solito chiamata la parte del kernel che implementa il
50   protocollo) per realizzare la comunicazione, fra questi dati ci sono una
51   serie di flag usati per gestire la connessione, come SYN, ACK, URG, FIN,
52   alcuni di essi, come SYN (che sta per \textit{syncronize}) corrispondono a
53   funzioni particolari del protocollo e danno il nome al segmento, (per
54   maggiori dettagli vedere sez.~\ref{sec:tcp_protocol}).}  di dati che vengono
55 scambiati) che porta alla creazione di una connessione è la seguente:
56  
57 \begin{enumerate}
58 \item Il server deve essere preparato per accettare le connessioni in arrivo;
59   il procedimento si chiama \textsl{apertura passiva} del socket (in inglese
60   \textit{passive open}). Questo viene fatto chiamando la sequenza di funzioni
61   \func{socket}, \func{bind} e \func{listen}. Completata l'apertura passiva il
62   server chiama la funzione \func{accept} e il processo si blocca in attesa di
63   connessioni.
64   
65 \item Il client richiede l'inizio della connessione usando la funzione
66   \func{connect}, attraverso un procedimento che viene chiamato
67   \textsl{apertura attiva}, dall'inglese \textit{active open}. La chiamata di
68   \func{connect} blocca il processo e causa l'invio da parte del client di un
69   segmento SYN, in sostanza viene inviato al server un pacchetto IP che
70   contiene solo gli header IP e TCP (con il numero di sequenza iniziale e il
71   flag SYN) e le opzioni di TCP.
72   
73 \item il server deve dare ricevuto (l'\textit{acknowledge}) del SYN del
74   client, inoltre anche il server deve inviare il suo SYN al client (e
75   trasmettere il suo numero di sequenza iniziale) questo viene fatto
76   ritrasmettendo un singolo segmento in cui sono impostati entrambi i flag SYN
77   e ACK.
78   
79 \item una volta che il client ha ricevuto l'acknowledge dal server la funzione
80   \func{connect} ritorna, l'ultimo passo è dare il ricevuto del SYN del
81   server inviando un ACK. Alla ricezione di quest'ultimo la funzione
82   \func{accept} del server ritorna e la connessione è stabilita.
83 \end{enumerate} 
84
85 Il procedimento viene chiamato \textit{three way handshake} dato che per
86 realizzarlo devono essere scambiati tre segmenti.  In fig.~\ref{fig:TCP_TWH}
87 si è rappresentata graficamente la sequenza di scambio dei segmenti che
88 stabilisce la connessione.
89
90 % Una analogia citata da R. Stevens per la connessione TCP è quella con il
91 % sistema del telefono. La funzione \func{socket} può essere considerata
92 % l'equivalente di avere un telefono. La funzione \func{bind} è analoga al
93 % dire alle altre persone qual è il proprio numero di telefono perché possano
94 % chiamare. La funzione \func{listen} è accendere il campanello del telefono
95 % per sentire le chiamate in arrivo.  La funzione \func{connect} richiede di
96 % conoscere il numero di chi si vuole chiamare. La funzione \func{accept} è
97 % quando si risponde al telefono.
98
99 \begin{figure}[!htb]
100   \centering \includegraphics[width=10cm]{img/three_way_handshake}  
101   \caption{Il \textit{three way handshake} del TCP.}
102   \label{fig:TCP_TWH}
103 \end{figure}
104
105 Si è accennato in precedenza ai \textsl{numeri di sequenza} (che sono anche
106 riportati in fig.~\ref{fig:TCP_TWH}): per gestire una connessione affidabile
107 infatti il protocollo TCP prevede nell'header la presenza di un numero a 32
108 bit (chiamato appunto \textit{sequence number}) che identifica a quale byte
109 nella sequenza del flusso corrisponde il primo byte della sezione dati
110 contenuta nel segmento.
111
112 Il numero di sequenza di ciascun segmento viene calcolato a partire da un
113 \textsl{numero di sequenza iniziale} generato in maniera casuale del kernel
114 all'inizio della connessione e trasmesso con il SYN; l'acknowledgement di
115 ciascun segmento viene effettuato dall'altro capo della connessione impostando
116 il flag ACK e restituendo nell'apposito campo dell'header un
117 \textit{acknowledge number}) pari al numero di sequenza che il ricevente si
118 aspetta di ricevere con il pacchetto successivo; dato che il primo pacchetto
119 SYN consuma un byte, nel \textit{three way handshake} il numero di acknowledge
120 è sempre pari al numero di sequenza iniziale incrementato di uno; lo stesso
121 varrà anche (vedi fig.~\ref{fig:TCP_close}) per l'acknowledgement di un FIN.
122
123 \itindend{three~way~handshake}
124
125
126 \subsection{Le opzioni TCP.}
127 \label{sec:TCP_TCP_opt}
128
129 Ciascun segmento SYN contiene in genere delle opzioni per il protocollo TCP,
130 le cosiddette \textit{TCP options},\footnote{da non confondere con le opzioni
131   dei socket TCP che tratteremo in sez.~\ref{sec:sock_tcp_udp_options}, in
132   questo caso si tratta delle opzioni che vengono trasmesse come parte di un
133   pacchetto TCP, non delle funzioni che consentono di impostare i relativi
134   valori.} che vengono inserite fra l'header e i dati, e che servono a
135 comunicare all'altro capo una serie di parametri utili a regolare la
136 connessione.  Normalmente vengono usate le seguenti opzioni:
137
138 \begin{itemize}
139 \item \textit{MSS option}, con questa opzione ciascun capo della connessione
140   annuncia all'altro il massimo ammontare di dati (MMS sta appunto per
141   \textit{Maximum Segment Size}) che vorrebbe accettare per ciascun segmento
142   nella connessione corrente. È possibile leggere e scrivere questo valore
143   attraverso l'opzione del socket \const{TCP\_MAXSEG} (vedi
144   sez.~\ref{sec:sock_tcp_udp_options}).
145   
146 \item \textit{window scale option}, il protocollo TCP implementa il controllo
147   di flusso attraverso una \textit{advertised window} (la ``\textsl{finestra
148     annunciata}'', vedi sez.~\ref{sec:tcp_protocol_xxx}) con la quale ciascun
149   capo della comunicazione dichiara quanto spazio disponibile ha in memoria
150   per i dati.  Questo è un numero a 16 bit dell'header, che così può indicare
151   un massimo di 65535 byte;\footnote{in Linux il massimo è 32767 per evitare
152     problemi con alcune implementazioni che usano l'aritmetica con segno per
153     implementare lo stack TCP.} ma alcuni tipi di connessione come quelle ad
154   alta velocità (sopra i 45Mbit/sec) e quelle che hanno grandi ritardi nel
155   cammino dei pacchetti (come i satelliti) richiedono una finestra più grande
156   per poter ottenere il massimo dalla trasmissione. Per questo esiste questa
157   opzione che indica un fattore di scala da applicare al valore della finestra
158   annunciata\footnote{essendo una nuova opzione per garantire la compatibilità
159     con delle vecchie implementazioni del protocollo la procedura che la
160     attiva prevede come negoziazione che l'altro capo della connessione
161     riconosca esplicitamente l'opzione inserendola anche lui nel suo SYN di
162     risposta dell'apertura della connessione.} per la connessione corrente
163   (espresso come numero di bit cui spostare a sinistra il valore della
164   finestra annunciata inserito nel pacchetto). Con Linux è possibile indicare
165   al kernel di far negoziare il fattore di scala in fase di creazione di una
166   connessione tramite la \textit{sysctl} \texttt{tcp\_window\_scaling} (vedi
167   sez.~\ref{sec:sock_ipv4_sysctl}).\footnote{per poter usare questa
168     funzionalità è comunque necessario ampliare le dimensioni dei buffer di
169     ricezione e spedizione, cosa che può essere fatta sia a livello di sistema
170     con le opportune \textit{sysctl} (vedi sez.~\ref{sec:sock_ipv4_sysctl})
171     che a livello di singoli socket con le relative opzioni (vedi
172     sez.~\ref{sec:sock_tcp_udp_options}).}
173
174 \item \textit{timestamp option}, è anche questa una nuova opzione necessaria
175   per le connessioni ad alta velocità per evitare possibili corruzioni di dati
176   dovute a pacchetti perduti che riappaiono; anche questa viene negoziata come
177   la precedente.
178
179 \end{itemize}
180
181 La MSS è generalmente supportata da quasi tutte le implementazioni del
182 protocollo, le ultime due opzioni (trattate
183 nell'\href{http://www.ietf.org/rfc/rfc1323.txt}{RFC~1323}) sono meno comuni;
184 vengono anche dette \textit{long fat pipe options} dato che questo è il nome
185 che viene dato alle connessioni caratterizzate da alta velocità o da ritardi
186 elevati. In ogni caso Linux supporta pienamente entrambe le opzioni.
187
188
189 \subsection{La terminazione della connessione}
190 \label{sec:TCP_conn_term}
191
192 Mentre per la creazione di una connessione occorre un interscambio di tre
193 segmenti, la procedura di chiusura ne richiede normalmente quattro. In questo
194 caso la successione degli eventi è la seguente:
195
196 \begin{enumerate}
197 \item Un processo ad uno dei due capi chiama la funzione \func{close}, dando
198   l'avvio a quella che viene chiamata \textsl{chiusura attiva} (o
199   \textit{active close}). Questo comporta l'emissione di un segmento FIN, che
200   serve ad indicare che si è finito con l'invio dei dati sulla connessione.
201   
202 \item L'altro capo della connessione riceve il FIN e dovrà eseguire la
203   \textsl{chiusura passiva} (o \textit{passive close}). Al FIN, come ad ogni
204   altro pacchetto, viene risposto con un ACK, inoltre il ricevimento del FIN
205   viene segnalato al processo che ha aperto il socket (dopo che ogni altro
206   eventuale dato rimasto in coda è stato ricevuto) come un end-of-file sulla
207   lettura: questo perché il ricevimento di un FIN significa che non si
208   riceveranno altri dati sulla connessione.
209   
210 \item Una volta rilevata l'end-of-file anche il secondo processo chiamerà la
211   funzione \func{close} sul proprio socket, causando l'emissione di un altro
212   segmento FIN.
213
214 \item L'altro capo della connessione riceverà il FIN conclusivo e risponderà
215   con un ACK.
216 \end{enumerate}
217
218 Dato che in questo caso sono richiesti un FIN ed un ACK per ciascuna direzione
219 normalmente i segmenti scambiati sono quattro.  Questo non è vero sempre
220 giacché in alcune situazioni il FIN del passo 1) è inviato insieme a dei dati.
221 Inoltre è possibile che i segmenti inviati nei passi 2 e 3 dal capo che
222 effettua la chiusura passiva, siano accorpati in un singolo segmento. In
223 fig.~\ref{fig:TCP_close} si è rappresentato graficamente lo sequenza di
224 scambio dei segmenti che conclude la connessione.
225
226 \begin{figure}[!htb]
227   \centering \includegraphics[width=10cm]{img/tcp_close}  
228   \caption{La chiusura di una connessione TCP.}
229   \label{fig:TCP_close}
230 \end{figure}
231
232 Come per il SYN anche il FIN occupa un byte nel numero di sequenza, per cui
233 l'ACK riporterà un \textit{acknowledge number} incrementato di uno. 
234
235 Si noti che, nella sequenza di chiusura, fra i passi 2 e 3, è in teoria
236 possibile che si mantenga un flusso di dati dal capo della connessione che
237 deve ancora eseguire la chiusura passiva a quello che sta eseguendo la
238 chiusura attiva.  Nella sequenza indicata i dati verrebbero persi, dato che si
239 è chiuso il socket dal lato che esegue la chiusura attiva; esistono tuttavia
240 situazioni in cui si vuole poter sfruttare questa possibilità, usando una
241 procedura che è chiamata \textit{half-close}; torneremo su questo aspetto e su
242 come utilizzarlo in sez.~\ref{sec:TCP_shutdown}, quando parleremo della
243 funzione \func{shutdown}.
244
245 La emissione del FIN avviene quando il socket viene chiuso, questo però non
246 avviene solo per la chiamata esplicita della funzione \func{close}, ma anche
247 alla terminazione di un processo, quando tutti i file vengono chiusi.  Questo
248 comporta ad esempio che se un processo viene terminato da un segnale tutte le
249 connessioni aperte verranno chiuse.
250
251 Infine occorre sottolineare che, benché nella figura (e nell'esempio che
252 vedremo più avanti in sez.~\ref{sec:TCP_echo}) sia stato il client ad eseguire
253 la chiusura attiva, nella realtà questa può essere eseguita da uno qualunque
254 dei due capi della comunicazione (come nell'esempio di
255 fig.~\ref{fig:TCP_daytime_iter_server_code}), e anche se il caso più comune
256 resta quello del client, ci sono alcuni servizi, il principale dei quali è
257 l'HTTP, per i quali è il server ad effettuare la chiusura attiva.
258
259
260 \subsection{Un esempio di connessione}
261 \label{sec:TCP_conn_dia}
262
263 Come abbiamo visto le operazioni del TCP nella creazione e conclusione di una
264 connessione sono piuttosto complesse, ed abbiamo esaminato soltanto quelle
265 relative ad un andamento normale.  In sez.~\ref{sec:TCP_states} vedremo con
266 maggiori dettagli che una connessione può assumere vari stati, che ne
267 caratterizzano il funzionamento, e che sono quelli che vengono riportati dal
268 comando \cmd{netstat}, per ciascun socket TCP aperto, nel campo
269 \textit{State}.
270
271 Non possiamo affrontare qui una descrizione completa del funzionamento del
272 protocollo; un approfondimento sugli aspetti principali si trova in
273 sez.~\ref{sec:tcp_protocol}, ma per una trattazione completa il miglior
274 riferimento resta \cite{TCPIll1}. Qui ci limiteremo a descrivere brevemente un
275 semplice esempio di connessione e le transizioni che avvengono nei due casi
276 appena citati (creazione e terminazione della connessione).
277
278 In assenza di connessione lo stato del TCP è \texttt{CLOSED}; quando una
279 applicazione esegue una apertura attiva il TCP emette un SYN e lo stato
280 diventa \texttt{SYN\_SENT}; quando il TCP riceve la risposta del SYN$+$ACK
281 emette un ACK e passa allo stato \texttt{ESTABLISHED}; questo è lo stato
282 finale in cui avviene la gran parte del trasferimento dei dati.
283
284 Dal lato server in genere invece il passaggio che si opera con l'apertura
285 passiva è quello di portare il socket dallo stato \texttt{CLOSED} allo
286 stato \texttt{LISTEN} in cui vengono accettate le connessioni.
287
288 Dallo stato \texttt{ESTABLISHED} si può uscire in due modi; se un'applicazione
289 chiama la funzione \func{close} prima di aver ricevuto un
290 \textit{end-of-file} (chiusura attiva) la transizione è verso lo stato
291 \texttt{FIN\_WAIT\_1}; se invece l'applicazione riceve un FIN nello stato
292 \texttt{ESTABLISHED} (chiusura passiva) la transizione è verso lo stato
293 \texttt{CLOSE\_WAIT}.
294
295 In fig.~\ref{fig:TCP_conn_example} è riportato lo schema dello scambio dei
296 pacchetti che avviene per una un esempio di connessione, insieme ai vari stati
297 che il protocollo viene ad assumere per i due lati, server e client.
298
299 \begin{figure}[!htb]
300   \centering \includegraphics[width=9cm]{img/tcp_connection}  
301   \caption{Schema dello scambio di pacchetti per un esempio di connessione.}
302   \label{fig:TCP_conn_example}
303 \end{figure}
304
305 La connessione viene iniziata dal client che annuncia una MSS di 1460, un
306 valore tipico con Linux per IPv4 su Ethernet, il server risponde con lo stesso
307 valore (ma potrebbe essere anche un valore diverso).
308
309 Una volta che la connessione è stabilita il client scrive al server una
310 richiesta (che assumiamo stare in un singolo segmento, cioè essere minore dei
311 1460 byte annunciati dal server), quest'ultimo riceve la richiesta e
312 restituisce una risposta (che di nuovo supponiamo stare in un singolo
313 segmento). Si noti che l'acknowledge della richiesta è mandato insieme alla
314 risposta: questo viene chiamato \textit{piggybacking} ed avviene tutte le
315 volte che il server è sufficientemente veloce a costruire la risposta; in
316 caso contrario si avrebbe prima l'emissione di un ACK e poi l'invio della
317 risposta.
318
319 Infine si ha lo scambio dei quattro segmenti che terminano la connessione
320 secondo quanto visto in sez.~\ref{sec:TCP_conn_term}; si noti che il capo della
321 connessione che esegue la chiusura attiva entra nello stato
322 \texttt{TIME\_WAIT}, sul cui significato torneremo fra poco.
323
324 È da notare come per effettuare uno scambio di due pacchetti (uno di richiesta
325 e uno di risposta) il TCP necessiti di ulteriori otto segmenti, se invece si
326 fosse usato UDP sarebbero stati sufficienti due soli pacchetti. Questo è il
327 costo che occorre pagare per avere l'affidabilità garantita dal TCP, se si
328 fosse usato UDP si sarebbe dovuto trasferire la gestione di tutta una serie di
329 dettagli (come la verifica della ricezione dei pacchetti) dal livello del
330 trasporto all'interno dell'applicazione.
331
332 Quello che è bene sempre tenere presente è allora quali sono le esigenze che
333 si hanno in una applicazione di rete, perché non è detto che TCP sia la
334 miglior scelta in tutti i casi (ad esempio se si devono solo scambiare dati
335 già organizzati in piccoli pacchetti l'overhead aggiunto può essere eccessivo)
336 per questo esistono applicazioni che usano UDP e lo fanno perché nel caso
337 specifico le sue caratteristiche di velocità e compattezza nello scambio dei
338 dati rispondono meglio alle esigenze che devono essere affrontate.
339
340 \subsection{Lo stato \texttt{TIME\_WAIT}}
341 \label{sec:TCP_time_wait}
342
343 Come riportato da Stevens in \cite{UNP1} lo stato \texttt{TIME\_WAIT} è
344 probabilmente uno degli aspetti meno compresi del protocollo TCP, è infatti
345 comune trovare domande su come sia possibile evitare che un'applicazione resti
346 in questo stato lasciando attiva una connessione ormai conclusa; la risposta è
347 che non deve essere fatto, ed il motivo cercheremo di spiegarlo adesso.
348
349 Come si è visto nell'esempio precedente (vedi fig.~\ref{fig:TCP_conn_example})
350 \texttt{TIME\_WAIT} è lo stato finale in cui il capo di una connessione che
351 esegue la chiusura attiva resta prima di passare alla chiusura definitiva
352 della connessione. Il tempo in cui l'applicazione resta in questo stato deve
353 essere due volte la MSL (\textit{Maximum Segment Lifetime}).
354
355 La MSL è la stima del massimo periodo di tempo che un pacchetto IP può vivere
356 sulla rete; questo tempo è limitato perché ogni pacchetto IP può essere
357 ritrasmesso dai router un numero massimo di volte (detto \textit{hop limit}).
358 Il numero di ritrasmissioni consentito è indicato dal campo TTL dell'header di
359 IP (per maggiori dettagli vedi sez.~\ref{sec:ip_protocol}), e viene
360 decrementato ad ogni passaggio da un router; quando si annulla il pacchetto
361 viene scartato.  Siccome il numero è ad 8 bit il numero massimo di
362 ``\textsl{salti}'' è di 255, pertanto anche se il TTL (da \textit{time to
363   live}) non è propriamente un limite sul tempo di vita, si stima che un
364 pacchetto IP non possa restare nella rete per più di MSL secondi.
365
366 Ogni implementazione del TCP deve scegliere un valore per la MSL
367 (l'\href{http://www.ietf.org/rfc/rfc1122.txt}{RFC~1122} raccomanda 2 minuti,
368 Linux usa 30 secondi), questo comporta una durata dello stato
369 \texttt{TIME\_WAIT} che a seconda delle implementazioni può variare fra 1 a 4
370 minuti.  Lo stato \texttt{TIME\_WAIT} viene utilizzato dal protocollo per due
371 motivi principali:
372 \begin{enumerate}
373 \item implementare in maniera affidabile la terminazione della connessione
374   in entrambe le direzioni.
375 \item consentire l'eliminazione dei segmenti duplicati dalla rete. 
376 \end{enumerate}
377
378 Il punto è che entrambe le ragioni sono importanti, anche se spesso si fa
379 riferimento solo alla prima; ma è solo se si tiene conto della seconda che si
380 capisce il perché della scelta di un tempo pari al doppio della MSL come
381 durata di questo stato.
382
383 Il primo dei due motivi precedenti si può capire tornando a
384 fig.~\ref{fig:TCP_conn_example}: assumendo che l'ultimo ACK della sequenza
385 (quello del capo che ha eseguito la chiusura attiva) venga perso, chi esegue
386 la chiusura passiva non ricevendo risposta rimanderà un ulteriore FIN, per
387 questo motivo chi esegue la chiusura attiva deve mantenere lo stato della
388 connessione per essere in grado di reinviare l'ACK e chiuderla correttamente.
389 Se non fosse così la risposta sarebbe un RST (un altro tipo si segmento) che
390 verrebbe interpretato come un errore.
391
392 Se il TCP deve poter chiudere in maniera pulita entrambe le direzioni della
393 connessione allora deve essere in grado di affrontare la perdita di uno
394 qualunque dei quattro segmenti che costituiscono la chiusura. Per questo
395 motivo un socket deve rimanere attivo nello stato \texttt{TIME\_WAIT} anche
396 dopo l'invio dell'ultimo ACK, per potere essere in grado di gestirne
397 l'eventuale ritrasmissione, in caso esso venga perduto.
398
399 Il secondo motivo è più complesso da capire, e necessita di una spiegazione
400 degli scenari in cui può accadere che i pacchetti TCP si possano perdere nella
401 rete o restare intrappolati, per poi riemergere in un secondo tempo.
402
403 Il caso più comune in cui questo avviene è quello di anomalie
404 nell'instradamento; può accadere cioè che un router smetta di funzionare o che
405 una connessione fra due router si interrompa. In questo caso i protocolli di
406 instradamento dei pacchetti possono impiegare diverso tempo (anche dell'ordine
407 dei minuti) prima di trovare e stabilire un percorso alternativo per i
408 pacchetti. Nel frattempo possono accadere casi in cui un router manda i
409 pacchetti verso un altro e quest'ultimo li rispedisce indietro, o li manda ad
410 un terzo router che li rispedisce al primo, si creano cioè dei circoli (i
411 cosiddetti \textit{routing loop}) in cui restano intrappolati i pacchetti.
412
413 Se uno di questi pacchetti intrappolati è un segmento TCP, chi l'ha inviato,
414 non ricevendo un ACK in risposta, provvederà alla ritrasmissione e se nel
415 frattempo sarà stata stabilita una strada alternativa il pacchetto ritrasmesso
416 giungerà a destinazione.
417
418 Ma se dopo un po' di tempo (che non supera il limite dell'MSL, dato che
419 altrimenti verrebbe ecceduto il TTL) l'anomalia viene a cessare, il circolo di
420 instradamento viene spezzato i pacchetti intrappolati potranno essere inviati
421 alla destinazione finale, con la conseguenza di avere dei pacchetti duplicati;
422 questo è un caso che il TCP deve essere in grado di gestire.
423
424 Allora per capire la seconda ragione per l'esistenza dello stato
425 \texttt{TIME\_WAIT} si consideri il caso seguente: si supponga di avere una
426 connessione fra l'IP \texttt{195.110.112.236} porta 1550 e l'IP
427 \texttt{192.84.145.100} porta 22 (affronteremo il significato delle porte
428 nella prossima sezione), che questa venga chiusa e che poco dopo si
429 ristabilisca la stessa connessione fra gli stessi IP sulle stesse porte
430 (quella che viene detta, essendo gli stessi porte e numeri IP, una nuova
431 \textsl{incarnazione} della connessione precedente); in questo caso ci si
432 potrebbe trovare con dei pacchetti duplicati relativi alla precedente
433 connessione che riappaiono nella nuova.
434
435 Ma fintanto che il socket non è chiuso una nuova incarnazione non può essere
436 creata: per questo un socket TCP resta sempre nello stato \texttt{TIME\_WAIT}
437 per un periodo di 2MSL, in modo da attendere MSL secondi per essere sicuri che
438 tutti i pacchetti duplicati in arrivo siano stati ricevuti (e scartati) o che
439 nel frattempo siano stati eliminati dalla rete, e altri MSL secondi per essere
440 sicuri che lo stesso avvenga per le risposte nella direzione opposta.
441
442 In questo modo, prima che venga creata una nuova connessione, il protocollo
443 TCP si assicura che tutti gli eventuali segmenti residui di una precedente
444 connessione, che potrebbero causare disturbi, siano stati eliminati dalla
445 rete.
446
447
448 \subsection{I numeri di porta}
449 \label{sec:TCP_port_num}
450
451 In un ambiente multitasking in un dato momento più processi devono poter usare
452 sia UDP che TCP, e ci devono poter essere più connessioni in contemporanea.
453 Per poter tenere distinte le diverse connessioni entrambi i protocolli usano i
454 \textsl{numeri di porta}, che fanno parte, come si può vedere in
455 sez.~\ref{sec:sock_sa_ipv4} e sez.~\ref{sec:sock_sa_ipv6} pure delle strutture
456 degli indirizzi del socket.
457
458 Quando un client contatta un server deve poter identificare con quale dei vari
459 possibili server attivi intende parlare. Sia TCP che UDP definiscono un gruppo
460 di \textsl{porte conosciute} (le cosiddette \textit{well-known port}) che
461 identificano una serie di servizi noti (ad esempio la porta 22 identifica il
462 servizio SSH) effettuati da appositi server che rispondono alle connessioni
463 verso tali porte.
464
465 D'altra parte un client non ha necessità di usare un numero di porta
466 specifico, per cui in genere vengono usate le cosiddette \textsl{porte
467   effimere} (o \textit{ephemeral ports}) cioè porte a cui non è assegnato
468 nessun servizio noto e che vengono assegnate automaticamente dal kernel alla
469 creazione della connessione. Queste sono dette effimere in quanto vengono
470 usate solo per la durata della connessione, e l'unico requisito che deve
471 essere soddisfatto è che ognuna di esse sia assegnata in maniera univoca.
472
473 La lista delle porte conosciute è definita
474 dall'\href{http://www.ietf.org/rfc/rfc1700.txt}{RFC~1700} che contiene
475 l'elenco delle porte assegnate dalla IANA (la \textit{Internet Assigned Number
476   Authority}) ma l'elenco viene costantemente aggiornato e pubblicato su
477 internet (una versione aggiornata si può trovare all'indirizzo
478 \url{http://www.iana.org/assignments/port-numbers}); inoltre in un sistema
479 unix-like un analogo elenco viene mantenuto nel file \conffile{/etc/services},
480 con la corrispondenza fra i vari numeri di porta ed il nome simbolico del
481 servizio.  I numeri sono divisi in tre intervalli:
482
483 \begin{enumerate*}
484 \item \textsl{le porte note}. I numeri da 0 a 1023. Queste sono controllate e
485   assegnate dalla IANA. Se è possibile la stessa porta è assegnata allo stesso
486   servizio sia su UDP che su TCP (ad esempio la porta 22 è assegnata a SSH su
487   entrambi i protocolli, anche se viene usata solo dal TCP).
488   
489 \item \textsl{le porte registrate}. I numeri da 1024 a 49151. Queste porte non
490   sono controllate dalla IANA, che però registra ed elenca chi usa queste
491   porte come servizio agli utenti. Come per le precedenti si assegna una porta
492   ad un servizio sia per TCP che UDP anche se poi il servizio è implementato
493   solo su TCP. Ad esempio X Window usa le porte TCP e UDP dal 6000 al 6063
494   anche se il protocollo è implementato solo tramite TCP.
495   
496 \item \textsl{le porte private} o \textsl{dinamiche}. I numeri da 49152 a
497   65535. La IANA non dice nulla riguardo a queste porte che pertanto
498   sono i candidati naturali ad essere usate come porte effimere.
499 \end{enumerate*}
500
501 In realtà rispetto a quanto indicato
502 nell'\href{http://www.ietf.org/rfc/rfc1700.txt}{RFC~1700} i vari sistemi hanno
503 fatto scelte diverse per le porte effimere, in particolare in
504 fig.~\ref{fig:TCP_port_alloc} sono riportate quelle di BSD e Linux.
505
506 \begin{figure}[!htb]
507   \centering \includegraphics[width=13cm]{img/port_alloc}  
508   \caption{Allocazione dei numeri di porta.}
509   \label{fig:TCP_port_alloc}
510 \end{figure}
511
512 I sistemi Unix hanno inoltre il concetto di \textsl{porte riservate} (che
513 corrispondono alle porte con numero minore di 1024 e coincidono quindi con le
514 \textsl{porte note}). La loro caratteristica è che possono essere assegnate a
515 un socket solo da un processo con i privilegi di amministratore, per far sì
516 che solo l'amministratore possa allocare queste porte per far partire i
517 relativi servizi.
518
519 Le \textsl{glibc} definiscono in \headfile{netinet/in.h}
520 \constd{IPPORT\_RESERVED} e \constd{IPPORT\_USERRESERVED}, in cui la prima
521 (che vale 1024) indica il limite superiore delle porte riservate, e la seconda
522 (che vale 5000) il limite inferiore delle porte a disposizione degli utenti.
523 La convenzione vorrebbe che le porte \textsl{effimere} siano allocate fra
524 questi due valori. Nel caso di Linux questo è vero solo in uno dei due casi di
525 fig.~\ref{fig:TCP_port_alloc}, e la scelta fra i due possibili intervalli
526 viene fatta dinamicamente dal kernel a seconda della memoria disponibile per
527 la gestione delle relative tabelle.
528
529 Si tenga conto poi che ci sono alcuni client, in particolare \cmd{rsh} e
530 \cmd{rlogin}, che richiedono una connessione su una porta riservata anche dal
531 lato client come parte dell'autenticazione, contando appunto sul fatto che
532 solo l'amministratore può usare queste porte. Data l'assoluta inconsistenza in
533 termini di sicurezza di un tale metodo, al giorno d'oggi esso è in completo
534 disuso.
535
536 Data una connessione TCP si suole chiamare \textit{socket pair}\footnote{da
537   non confondere con la coppia di socket della omonima funzione
538   \func{socketpair} che fanno riferimento ad una coppia di socket sulla stessa
539   macchina, non ai capi di una connessione TCP.} la combinazione dei quattro
540 numeri che definiscono i due capi della connessione e cioè l'indirizzo IP
541 locale e la porta TCP locale, e l'indirizzo IP remoto e la porta TCP remota.
542 Questa combinazione, che scriveremo usando una notazione del tipo
543 (\texttt{195.110.112.152:22}, \texttt{192.84.146.100:20100}), identifica
544 univocamente una connessione su internet.  Questo concetto viene di solito
545 esteso anche a UDP, benché in questo caso non abbia senso parlare di
546 connessione. L'utilizzo del programma \cmd{netstat} permette di visualizzare
547 queste informazioni nei campi \textit{Local Address} e \textit{Foreing
548   Address}.
549
550
551 \subsection{Le porte ed il modello client/server}
552 \label{sec:TCP_port_cliserv}
553
554 Per capire meglio l'uso delle porte e come vengono utilizzate quando si ha a
555 che fare con un'applicazione client/server (come quelle che descriveremo in
556 sez.~\ref{sec:TCP_daytime_application} e sez.~\ref{sec:TCP_echo_application})
557 esamineremo cosa accade con le connessioni nel caso di un server TCP che deve
558 gestire connessioni multiple.
559
560 Se eseguiamo un \cmd{netstat} su una macchina di prova (il cui indirizzo sia
561 \texttt{195.110.112.152}) potremo avere un risultato del tipo:
562 \begin{verbatim}
563 Active Internet connections (servers and established)
564 Proto Recv-Q Send-Q Local Address           Foreign Address         State      
565 tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
566 tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN
567 tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN
568 \end{verbatim}
569 essendo presenti e attivi un server SSH, un server di posta e un DNS per il
570 caching locale.
571
572 Questo ci mostra ad esempio che il server SSH ha compiuto un'apertura passiva,
573 mettendosi in ascolto sulla porta 22 riservata a questo servizio, e che si è
574 posto in ascolto per connessioni provenienti da uno qualunque degli indirizzi
575 associati alle interfacce locali. La notazione \texttt{0.0.0.0} usata da
576 \cmd{netstat} è equivalente all'asterisco utilizzato per il numero di porta,
577 indica il valore generico, e corrisponde al valore \const{INADDR\_ANY}
578 definito in \headfiled{arpa/inet.h} (vedi \ref{tab:TCP_ipv4_addr}).
579
580 Inoltre si noti come la porta e l'indirizzo di ogni eventuale connessione
581 esterna non sono specificati; in questo caso la \textit{socket pair} associata
582 al socket potrebbe essere indicata come (\texttt{*:22}, \texttt{*:*}), usando
583 anche per gli indirizzi l'asterisco come carattere che indica il valore
584 generico.
585
586 Dato che in genere una macchina è associata ad un solo indirizzo IP, ci si può
587 chiedere che senso abbia l'utilizzo dell'indirizzo generico per specificare
588 l'indirizzo locale; ma a parte il caso di macchine che hanno più di un
589 indirizzo IP (il cosiddetto \textit{multihoming}) esiste sempre anche
590 l'indirizzo di loopback, per cui con l'uso dell'indirizzo generico si possono
591 accettare connessioni indirizzate verso uno qualunque degli indirizzi IP
592 presenti. Ma, come si può vedere nell'esempio con il DNS che è in ascolto
593 sulla porta 53, è possibile anche restringere l'accesso ad uno specifico
594 indirizzo, cosa che nel caso è fatta accettando solo connessioni che arrivino
595 sull'interfaccia di loopback.
596
597 Una volta che ci si vorrà collegare a questa macchina da un'altra, per esempio
598 quella con l'indirizzo \texttt{192.84.146.100}, si dovrà lanciare su
599 quest'ultima un client \cmd{ssh} per creare una connessione, e il kernel gli
600 assocerà una porta effimera (ad esempio la 21100), per cui la connessione sarà
601 espressa dalla socket pair (\texttt{192.84.146.100:21100},
602 \texttt{195.110.112.152:22}).
603
604 Alla ricezione della richiesta dal client il server creerà un processo figlio
605 per gestire la connessione, se a questo punto eseguiamo nuovamente il
606 programma \cmd{netstat} otteniamo come risultato:
607 \begin{verbatim}
608 Active Internet connections (servers and established)
609 Proto Recv-Q Send-Q Local Address           Foreign Address         State      
610 tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
611 tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN
612 tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN
613 tcp        0      0 195.110.112.152:22      192.84.146.100:21100    ESTABLISHED
614 \end{verbatim}
615
616 Come si può notare il server è ancora in ascolto sulla porta 22, però adesso
617 c'è un nuovo socket (con lo stato \texttt{ESTABLISHED}) che utilizza anch'esso
618 la porta 22, ed ha specificato l'indirizzo locale, questo è il socket con cui
619 il processo figlio gestisce la connessione mentre il padre resta in ascolto
620 sul socket originale.
621
622 Se a questo punto lanciamo un'altra volta il client \cmd{ssh} per una seconda
623 connessione quello che otterremo usando \cmd{netstat} sarà qualcosa del
624 genere:
625 \begin{verbatim}
626 Active Internet connections (servers and established)
627 Proto Recv-Q Send-Q Local Address           Foreign Address         State      
628 tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
629 tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN
630 tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN
631 tcp        0      0 195.110.112.152:22      192.84.146.100:21100    ESTABLISHED
632 tcp        0      0 195.110.112.152:22      192.84.146.100:21101    ESTABLISHED
633 \end{verbatim}
634 cioè il client effettuerà la connessione usando un'altra porta effimera: con
635 questa sarà aperta la connessione, ed il server creerà un altro processo
636 figlio per gestirla.
637
638 Tutto ciò mostra come il TCP, per poter gestire le connessioni con un server
639 concorrente, non può suddividere i pacchetti solo sulla base della porta di
640 destinazione, ma deve usare tutta l'informazione contenuta nella socket pair,
641 compresa la porta dell'indirizzo remoto.  E se andassimo a vedere quali sono i
642 processi\footnote{ad esempio con il comando \cmd{fuser}, o con \cmd{lsof}, o
643   usando l'opzione \texttt{-p}.} a cui fanno riferimento i vari socket
644 vedremmo che i pacchetti che arrivano dalla porta remota 21100 vanno al primo
645 figlio e quelli che arrivano alla porta 21101 al secondo.
646
647
648 \section{Le funzioni di base per la gestione dei socket}
649 \label{sec:TCP_functions}
650
651 In questa sezione descriveremo in maggior dettaglio le varie funzioni che
652 vengono usate per la gestione di base dei socket TCP, non torneremo però sulla
653 funzione \func{socket}, che è già stata esaminata accuratamente nel capitolo
654 precedente in sez.~\ref{sec:sock_creation}.
655
656
657 \subsection{La funzione \func{bind}}
658 \label{sec:TCP_func_bind}
659
660 La funzione \funcd{bind} assegna un indirizzo locale ad un
661 socket.\footnote{nel nostro caso la utilizzeremo per socket TCP, ma la
662   funzione è generica e deve essere usata per qualunque tipo di socket
663   \const{SOCK\_STREAM} prima che questo possa accettare connessioni.} È usata
664 cioè per specificare la prima parte dalla socket pair.  Viene usata sul lato
665 server per specificare la porta (e gli eventuali indirizzi locali) su cui poi
666 ci si porrà in ascolto. Il prototipo della funzione è il seguente:
667 \begin{prototype}{sys/socket.h}
668 {int bind(int sockfd, const struct sockaddr *serv\_addr, socklen\_t addrlen)}
669   
670   Assegna un indirizzo ad un socket.
671   
672   \bodydesc{La funzione restituisce 0 in caso di successo e -1 per un errore;
673     in caso di errore la variabile \var{errno} viene impostata secondo i
674     seguenti codici di errore:
675   \begin{errlist}
676   \item[\errcode{EBADF}] il file descriptor non è valido.
677   \item[\errcode{EINVAL}] il socket ha già un indirizzo assegnato.
678   \item[\errcode{ENOTSOCK}] il file descriptor non è associato ad un socket.
679   \item[\errcode{EACCES}] si è cercato di usare una porta riservata senza
680     sufficienti privilegi.
681   \item[\errcode{EADDRNOTAVAIL}] il tipo di indirizzo specificato non è
682     disponibile.
683   \item[\errcode{EADDRINUSE}] qualche altro socket sta già usando l'indirizzo.
684   \end{errlist}
685   ed anche \errval{EFAULT} e per i socket di tipo \const{AF\_UNIX},
686   \errval{ENOTDIR}, \errval{ENOENT}, \errval{ENOMEM}, \errval{ELOOP},
687   \errval{ENOSR} e \errval{EROFS}.}
688 \end{prototype}
689
690 Il primo argomento è un file descriptor ottenuto da una precedente chiamata a
691 \func{socket}, mentre il secondo e terzo argomento sono rispettivamente
692 l'indirizzo (locale) del socket e la dimensione della struttura che lo
693 contiene, secondo quanto già trattato in sez.~\ref{sec:sock_sockaddr}. 
694
695 Con i socket TCP la chiamata \func{bind} permette di specificare l'indirizzo,
696 la porta, entrambi o nessuno dei due. In genere i server utilizzano una porta
697 nota che assegnano all'avvio, se questo non viene fatto è il kernel a
698 scegliere una porta effimera quando vengono eseguite la funzioni
699 \func{connect} o \func{listen}, ma se questo è normale per il client non lo è
700 per il server\footnote{un'eccezione a tutto ciò sono i server che usano RPC.
701   In questo caso viene fatta assegnare dal kernel una porta effimera che poi
702   viene registrata presso il \textit{portmapper}; quest'ultimo è un altro
703   demone che deve essere contattato dai client per ottenere la porta effimera
704   su cui si trova il server.} che in genere viene identificato dalla porta su
705 cui risponde (l'elenco di queste porte, e dei relativi servizi, è in
706 \conffile{/etc/services}).
707
708 Con \func{bind} si può assegnare un indirizzo IP specifico ad un socket,
709 purché questo appartenga ad una interfaccia della macchina.  Per un client TCP
710 questo diventerà l'indirizzo sorgente usato per i tutti i pacchetti inviati
711 sul socket, mentre per un server TCP questo restringerà l'accesso al socket
712 solo alle connessioni che arrivano verso tale indirizzo.
713
714 Normalmente un client non specifica mai l'indirizzo di un socket, ed il kernel
715 sceglie l'indirizzo di origine quando viene effettuata la connessione, sulla
716 base dell'interfaccia usata per trasmettere i pacchetti, (che dipenderà dalle
717 regole di instradamento usate per raggiungere il server).  Se un server non
718 specifica il suo indirizzo locale il kernel userà come indirizzo di origine
719 l'indirizzo di destinazione specificato dal SYN del client.
720
721 Per specificare un indirizzo generico, con IPv4 si usa il valore
722 \const{INADDR\_ANY}, il cui valore, come accennato in
723 sez.~\ref{sec:sock_sa_ipv4}, è pari a zero; nell'esempio
724 fig.~\ref{fig:TCP_daytime_iter_server_code} si è usata un'assegnazione
725 immediata del tipo: \includecodesnip{listati/serv_addr_sin_addr.c}
726
727 Si noti che si è usato \func{htonl} per assegnare il valore
728 \const{INADDR\_ANY}, anche se, essendo questo nullo, il riordinamento è
729 inutile.  Si tenga presente comunque che tutte le costanti \val{INADDR\_}
730 (riportate in tab.~\ref{tab:TCP_ipv4_addr}) sono definite secondo
731 l'\textit{endianness} della macchina, ed anche se esse possono essere
732 invarianti rispetto all'ordinamento dei bit, è comunque buona norma usare
733 sempre la funzione \func{htonl}.
734
735 \begin{table}[htb]
736   \centering
737   \footnotesize
738   \begin{tabular}[c]{|l|l|}
739     \hline
740     \textbf{Costante} & \textbf{Significato} \\
741     \hline
742     \hline
743     \constd{INADDR\_ANY}      & Indirizzo generico (\texttt{0.0.0.0})\\
744     \constd{INADDR\_BROADCAST}& Indirizzo di \textit{broadcast}.\\ 
745     \constd{INADDR\_LOOPBACK} & Indirizzo di \textit{loopback}
746                                 (\texttt{127.0.0.1}).\\ 
747     \constd{INADDR\_NONE}     & Indirizzo errato.\\
748     \hline    
749   \end{tabular}
750   \caption{Costanti di definizione di alcuni indirizzi generici per IPv4.}
751   \label{tab:TCP_ipv4_addr}
752 \end{table}
753
754 L'esempio precedente funziona correttamente con IPv4 poiché che l'indirizzo è
755 rappresentabile anche con un intero a 32 bit; non si può usare lo stesso
756 metodo con IPv6, in cui l'indirizzo deve necessariamente essere specificato
757 con una struttura, perché il linguaggio C non consente l'uso di una struttura
758 costante come operando a destra in una assegnazione.
759
760 Per questo motivo nell'header \headfile{netinet/in.h} è definita una variabile
761 \var{in6addr\_any} (dichiarata come \dirct{extern}, ed inizializzata dal
762 sistema al valore \constd{IN6ADRR\_ANY\_INIT}) che permette di effettuare una
763 assegnazione del tipo: \includecodesnip{listati/serv_addr_sin6_addr.c} in
764 maniera analoga si può utilizzare la variabile \var{in6addr\_loopback} per
765 indicare l'indirizzo di \textit{loopback}, che a sua volta viene inizializzata
766 staticamente a \constd{IN6ADRR\_LOOPBACK\_INIT}.
767
768
769 \subsection{La funzione \func{connect}}
770 \label{sec:TCP_func_connect}
771
772 La funzione \funcd{connect} è usata da un client TCP per stabilire la
773 connessione con un server TCP,\footnote{di nuovo la funzione è generica e
774   supporta vari tipi di socket, la differenza è che per socket senza
775   connessione come quelli di tipo \const{SOCK\_DGRAM} la sua chiamata si
776   limiterà ad impostare l'indirizzo dal quale e verso il quale saranno inviati
777   e ricevuti i pacchetti, mentre per socket di tipo \const{SOCK\_STREAM} o
778   \const{SOCK\_SEQPACKET}, essa attiverà la procedura di avvio (nel caso del
779   TCP il \textit{three way handshake}) della connessione.}  il prototipo della
780 funzione è il seguente:
781 \begin{prototype}{sys/socket.h}
782   {int connect(int sockfd, const struct sockaddr *servaddr, socklen\_t
783     addrlen)}
784   
785   Stabilisce una connessione fra due socket.
786   
787   \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
788     errore, nel qual caso \var{errno} assumerà i valori:
789   \begin{errlist}
790   \item[\errcode{ECONNREFUSED}] non c'è nessuno in ascolto sull'indirizzo
791     remoto.
792   \item[\errcode{ETIMEDOUT}] si è avuto timeout durante il tentativo di
793     connessione.
794   \item[\errcode{ENETUNREACH}] la rete non è raggiungibile.
795   \item[\errcode{EINPROGRESS}] il socket è non bloccante (vedi
796     sez.~\ref{sec:file_noblocking}) e la connessione non può essere conclusa
797     immediatamente.
798   \item[\errcode{EALREADY}] il socket è non bloccante (vedi
799     sez.~\ref{sec:file_noblocking}) e un tentativo precedente di connessione
800     non si è ancora concluso.
801   \item[\errcode{EAGAIN}] non ci sono più porte locali libere. 
802   \item[\errcode{EAFNOSUPPORT}] l'indirizzo non ha una famiglia di indirizzi
803     corretta nel relativo campo.
804   \item[\errcode{EACCES}, \errcode{EPERM}] si è tentato di eseguire una
805     connessione ad un indirizzo \textit{broadcast} senza che il socket fosse
806     stato abilitato per il \textit{broadcast}.
807   \end{errlist}
808   altri errori possibili sono: \errval{EFAULT}, \errval{EBADF},
809   \errval{ENOTSOCK}, \errval{EISCONN} e \errval{EADDRINUSE}.}
810 \end{prototype}
811
812 Il primo argomento è un file descriptor ottenuto da una precedente chiamata a
813 \func{socket}, mentre il secondo e terzo argomento sono rispettivamente
814 l'indirizzo e la dimensione della struttura che contiene l'indirizzo del
815 socket, già descritta in sez.~\ref{sec:sock_sockaddr}.
816
817 La struttura dell'indirizzo deve essere inizializzata con l'indirizzo IP e il
818 numero di porta del server a cui ci si vuole connettere, come mostrato
819 nell'esempio sez.~\ref{sec:TCP_daytime_client}, usando le funzioni illustrate
820 in sez.~\ref{sec:sock_addr_func}.
821
822 Nel caso di socket TCP la funzione \func{connect} avvia il \textit{three way
823   handshake}, e ritorna solo quando la connessione è stabilita o si è
824 verificato un errore. Le possibili cause di errore sono molteplici (ed i
825 relativi codici riportati sopra), quelle che però dipendono dalla situazione
826 della rete e non da errori o problemi nella chiamata della funzione sono le
827 seguenti:
828 \begin{enumerate}
829 \item Il client non riceve risposta al SYN: l'errore restituito è
830   \errcode{ETIMEDOUT}. Stevens riporta che BSD invia un primo SYN alla
831   chiamata di \func{connect}, un altro dopo 6 secondi, un terzo dopo 24
832   secondi, se dopo 75 secondi non ha ricevuto risposta viene ritornato
833   l'errore. Linux invece ripete l'emissione del SYN ad intervalli di 30
834   secondi per un numero di volte che può essere stabilito dall'utente. Questo
835   può essere fatto a livello globale con una opportuna
836   \func{sysctl},\footnote{o più semplicemente scrivendo il valore voluto in
837     \sysctlfile{net/ipv4/tcp\_syn\_retries}, vedi
838     sez.~\ref{sec:sock_ipv4_sysctl}.} e a livello di singolo socket con
839   l'opzione \const{TCP\_SYNCNT} (vedi sez.~\ref{sec:sock_tcp_udp_options}). Il
840   valore predefinito per la ripetizione dell'invio è di 5 volte, che comporta
841   un timeout dopo circa 180 secondi.
842
843 \item Il client riceve come risposta al SYN un RST significa che non c'è
844   nessun programma in ascolto per la connessione sulla porta specificata (il
845   che vuol dire probabilmente che o si è sbagliato il numero della porta o che
846   non è stato avviato il server), questo è un errore fatale e la funzione
847   ritorna non appena il RST viene ricevuto riportando un errore
848   \errcode{ECONNREFUSED}.
849   
850   Il flag RST sta per \textit{reset} ed è un segmento inviato direttamente
851   dal TCP quando qualcosa non va. Tre condizioni che generano un RST sono:
852   quando arriva un SYN per una porta che non ha nessun server in ascolto,
853   quando il TCP abortisce una connessione in corso, quando TCP riceve un
854   segmento per una connessione che non esiste.
855   
856 \item Il SYN del client provoca l'emissione di un messaggio ICMP di
857   destinazione non raggiungibile. In questo caso dato che il messaggio può
858   essere dovuto ad una condizione transitoria si ripete l'emissione dei SYN
859   come nel caso precedente, fino al timeout, e solo allora si restituisce il
860   codice di errore dovuto al messaggio ICMP, che da luogo ad un
861   \errcode{ENETUNREACH}.
862    
863 \end{enumerate}
864
865 Se si fa riferimento al diagramma degli stati del TCP riportato in
866 fig.~\ref{fig:TCP_state_diag} la funzione \func{connect} porta un socket
867 dallo stato \texttt{CLOSED} (lo stato iniziale in cui si trova un socket
868 appena creato) prima allo stato \texttt{SYN\_SENT} e poi, al ricevimento del
869 ACK, nello stato \texttt{ESTABLISHED}. Se invece la connessione fallisce il
870 socket non è più utilizzabile e deve essere chiuso.
871
872 Si noti infine che con la funzione \func{connect} si è specificato solo
873 indirizzo e porta del server, quindi solo una metà della socket pair; essendo
874 questa funzione usata nei client l'altra metà contenente indirizzo e porta
875 locale viene lasciata all'assegnazione automatica del kernel, e non è
876 necessario effettuare una \func{bind}.
877
878
879 \subsection{La funzione \func{listen}}
880 \label{sec:TCP_func_listen}
881
882 La funzione \funcd{listen} serve ad usare un socket in modalità passiva, cioè,
883 come dice il nome, per metterlo in ascolto di eventuali
884 connessioni;\footnote{questa funzione può essere usata con socket che
885   supportino le connessioni, cioè di tipo \const{SOCK\_STREAM} o
886   \const{SOCK\_SEQPACKET}.} in sostanza l'effetto della funzione è di portare
887 il socket dallo stato \texttt{CLOSED} a quello \texttt{LISTEN}. In genere si
888 chiama la funzione in un server dopo le chiamate a \func{socket} e \func{bind}
889 e prima della chiamata ad \func{accept}. Il prototipo della funzione, come
890 definito dalla pagina di manuale, è:
891 \begin{prototype}{sys/socket.h}{int listen(int sockfd, int backlog)}
892   Pone un socket in attesa di una connessione.
893   
894   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
895     errore. I codici di errore restituiti in \var{errno} sono i seguenti:
896   \begin{errlist}
897   \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor
898     valido.
899   \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket.
900   \item[\errcode{EOPNOTSUPP}] il socket è di un tipo che non supporta questa
901     operazione.
902   \end{errlist}}
903 \end{prototype}
904
905 La funzione pone il socket specificato da \param{sockfd} in modalità passiva e
906 predispone una coda per le connessioni in arrivo di lunghezza pari a
907 \param{backlog}. La funzione si può applicare solo a socket di tipo
908 \const{SOCK\_STREAM} o \const{SOCK\_SEQPACKET}.
909
910 L'argomento \param{backlog} indica il numero massimo di connessioni pendenti
911 accettate; se esso viene ecceduto il client al momento della richiesta della
912 connessione riceverà un errore di tipo \errcode{ECONNREFUSED}, o se il
913 protocollo, come accade nel caso del TCP, supporta la ritrasmissione, la
914 richiesta sarà ignorata in modo che la connessione possa venire ritentata.
915
916 Per capire meglio il significato di tutto ciò occorre approfondire la modalità
917 con cui il kernel tratta le connessioni in arrivo. Per ogni socket in ascolto
918 infatti vengono mantenute due code:
919 \begin{enumerate}
920 \item La coda delle connessioni incomplete (\textit{incomplete connection
921     queue}) che contiene un riferimento per ciascun socket per il quale è
922   arrivato un SYN ma il \textit{three way handshake} non si è ancora concluso.
923   Questi socket sono tutti nello stato \texttt{SYN\_RECV}.
924 \item La coda delle connessioni complete (\textit{complete connection queue})
925   che contiene un ingresso per ciascun socket per il quale il \textit{three
926     way handshake} è stato completato ma ancora \func{accept} non è ritornata.
927   Questi socket sono tutti nello stato \texttt{ESTABLISHED}.
928 \end{enumerate}
929
930 Lo schema di funzionamento è descritto in fig.~\ref{fig:TCP_listen_backlog}:
931 quando arriva un SYN da un client il server crea una nuova voce nella coda
932 delle connessioni incomplete, e poi risponde con il SYN$+$ACK. La voce resterà
933 nella coda delle connessioni incomplete fino al ricevimento dell'ACK dal
934 client o fino ad un timeout. Nel caso di completamento del \textit{three way
935   handshake} la voce viene spostata nella coda delle connessioni complete.
936 Quando il processo chiama la funzione \func{accept} (vedi
937 sez.~\ref{sec:TCP_func_accept}) la prima voce nella coda delle connessioni
938 complete è passata al programma, o, se la coda è vuota, il processo viene
939 posto in attesa e risvegliato all'arrivo della prima connessione completa.
940
941 \begin{figure}[!htb]
942   \centering \includegraphics[width=11cm]{img/tcp_listen_backlog}  
943   \caption{Schema di funzionamento delle code delle connessioni complete ed
944     incomplete.}
945   \label{fig:TCP_listen_backlog}
946 \end{figure}
947
948 Storicamente il valore dell'argomento \param{backlog} era corrispondente al
949 massimo valore della somma del numero di voci possibili per ciascuna delle due
950 code. Stevens in \cite{UNP1} riporta che BSD ha sempre applicato un fattore di
951 1.5 a detto valore, e fornisce una tabella con i risultati ottenuti con vari
952 kernel, compreso Linux 2.0, che mostrano le differenze fra diverse
953 implementazioni.
954
955 In Linux il significato di questo valore è cambiato a partire dal kernel 2.2
956 per prevenire l'attacco chiamato \itindex{SYN~flood} \textit{SYN
957   flood}. Questo si basa sull'emissione da parte dell'attaccante di un grande
958 numero di pacchetti SYN indirizzati verso una porta, forgiati con indirizzo IP
959 fasullo\footnote{con la tecnica che viene detta \textit{ip spoofing}.} così
960 che i SYN$+$ACK vanno perduti e la coda delle connessioni incomplete viene
961 saturata, impedendo di fatto ulteriori connessioni.
962
963 Per ovviare a questo il significato del \param{backlog} è stato cambiato a
964 indicare la lunghezza della coda delle connessioni complete. La lunghezza
965 della coda delle connessioni incomplete può essere ancora controllata usando
966 la funzione \func{sysctl} con il parametro
967 \constd{NET\_TCP\_MAX\_SYN\_BACKLOG} o scrivendola direttamente in
968 \sysctlfile{net/ipv4/tcp\_max\_syn\_backlog}.  Quando si attiva la protezione
969 dei syncookies però (con l'opzione da compilare nel kernel e da attivare
970 usando \sysctlfile{net/ipv4/tcp\_syncookies}) questo valore viene ignorato e
971 non esiste più un valore massimo.  In ogni caso in Linux il valore
972 di \param{backlog} viene troncato ad un massimo di \const{SOMAXCONN} se è
973 superiore a detta costante (che di default vale 128).\footnote{il valore di
974   questa costante può essere controllato con un altro parametro di
975   \func{sysctl}, vedi sez.~\ref{sec:sock_ioctl_IP}.}
976
977 La scelta storica per il valore di questo parametro era di 5, e alcuni vecchi
978 kernel non supportavano neanche valori superiori, ma la situazione corrente è
979 molto cambiata per via della presenza di server web che devono gestire un gran
980 numero di connessioni per cui un tale valore non è più adeguato. Non esiste
981 comunque una risposta univoca per la scelta del valore, per questo non
982 conviene specificarlo con una costante (il cui cambiamento richiederebbe la
983 ricompilazione del server) ma usare piuttosto una variabile di ambiente (vedi
984 sez.~\ref{sec:proc_environ}).
985
986 Stevens tratta accuratamente questo argomento in \cite{UNP1}, con esempi presi
987 da casi reali su web server, ed in particolare evidenzia come non sia più vero
988 che il compito principale della coda sia quello di gestire il caso in cui il
989 server è occupato fra chiamate successive alla \func{accept} (per cui la coda
990 più occupata sarebbe quella delle connessioni completate), ma piuttosto quello
991 di gestire la presenza di un gran numero di SYN in attesa di concludere il
992 \textit{three way handshake}.
993
994 Infine va messo in evidenza che, nel caso di socket TCP, quando un SYN arriva
995 con tutte le code piene, il pacchetto deve essere ignorato. Questo perché la
996 condizione in cui le code sono piene è ovviamente transitoria, per cui se il
997 client ritrasmette il SYN è probabile che passato un po' di tempo possa
998 trovare nella coda lo spazio per una nuova connessione. Se invece si
999 rispondesse con un RST, per indicare l'impossibilità di effettuare la
1000 connessione, la chiamata a \func{connect} nel client ritornerebbe con una
1001 condizione di errore, costringendo a inserire nell'applicazione la gestione
1002 dei tentativi di riconnessione, che invece può essere effettuata in maniera
1003 trasparente dal protocollo TCP.
1004
1005
1006 \subsection{La funzione \func{accept}}
1007 \label{sec:TCP_func_accept}
1008
1009 La funzione \funcd{accept} è chiamata da un server per gestire la connessione
1010 una volta che sia stato completato il \textit{three way
1011   handshake},\footnote{la funzione è comunque generica ed è utilizzabile su
1012   socket di tipo \const{SOCK\_STREAM}, \const{SOCK\_SEQPACKET} e
1013   \const{SOCK\_RDM}.} la funzione restituisce un nuovo socket descriptor su
1014 cui si potrà operare per effettuare la comunicazione. Se non ci sono
1015 connessioni completate il processo viene messo in attesa. Il prototipo della
1016 funzione è il seguente:
1017 \begin{prototype}{sys/socket.h}
1018 {int accept(int sockfd, struct sockaddr *addr, socklen\_t *addrlen)} 
1019  
1020   Accetta una connessione sul socket specificato.
1021   
1022   \bodydesc{La funzione restituisce un numero di socket descriptor positivo in
1023     caso di successo e -1 in caso di errore, nel qual caso \var{errno} viene
1024     impostata ai seguenti valori:
1025
1026   \begin{errlist}
1027   \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor
1028     valido.
1029   \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket.
1030   \item[\errcode{EOPNOTSUPP}] il socket è di un tipo che non supporta questa
1031     operazione.
1032   \item[\errcode{EAGAIN} o \errcode{EWOULDBLOCK}] il socket è stato impostato
1033     come non bloccante (vedi sez.~\ref{sec:file_noblocking}), e non ci sono
1034     connessioni in attesa di essere accettate.
1035   \item[\errcode{EPERM}] le regole del firewall non consentono la connessione.
1036   \item[\errcode{ENOBUFS}, \errcode{ENOMEM}] questo spesso significa che
1037     l'allocazione della memoria è limitata dai limiti sui buffer dei socket,
1038     non dalla memoria di sistema.
1039   \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
1040   \end{errlist}
1041   Inoltre possono essere restituiti gli errori di rete relativi al nuovo
1042   socket, diversi a secondo del protocollo, come: \errval{EMFILE},
1043   \errval{EINVAL}, \errval{ENOSR}, \errval{ENOBUFS}, \errval{EFAULT},
1044   \errval{EPERM}, \errval{ECONNABORTED}, \errval{ESOCKTNOSUPPORT},
1045   \errval{EPROTONOSUPPORT}, \errval{ETIMEDOUT}, \errval{ERESTARTSYS}.}
1046 \end{prototype}
1047
1048 La funzione estrae la prima connessione relativa al socket \param{sockfd} in
1049 attesa sulla coda delle connessioni complete, che associa ad nuovo socket con
1050 le stesse caratteristiche di \param{sockfd}.  Il socket originale non viene
1051 toccato e resta nello stato di \texttt{LISTEN}, mentre il nuovo socket viene
1052 posto nello stato \texttt{ESTABLISHED}. Nella struttura \param{addr} e nella
1053 variabile \param{addrlen} vengono restituiti indirizzo e relativa lunghezza
1054 del client che si è connesso.
1055
1056 I due argomenti \param{addr} e \param{addrlen} (si noti che quest'ultimo è
1057 passato per indirizzo per avere indietro il valore) sono usati per ottenere
1058 l'indirizzo del client da cui proviene la connessione. Prima della chiamata
1059 \param{addrlen} deve essere inizializzato alle dimensioni della struttura il
1060 cui indirizzo è passato come argomento in \param{addr}; al ritorno della
1061 funzione \param{addrlen} conterrà il numero di byte scritti dentro
1062 \param{addr}. Se questa informazione non interessa basterà inizializzare a
1063 \val{NULL} detti puntatori.
1064
1065 Se la funzione ha successo restituisce il descrittore di un nuovo socket
1066 creato dal kernel (detto \textit{connected socket}) a cui viene associata la
1067 prima connessione completa (estratta dalla relativa coda, vedi
1068 sez.~\ref{sec:TCP_func_listen}) che il client ha effettuato verso il socket
1069 \param{sockfd}. Quest'ultimo (detto \textit{listening socket}) è quello creato
1070 all'inizio e messo in ascolto con \func{listen}, e non viene toccato dalla
1071 funzione.  Se non ci sono connessioni pendenti da accettare la funzione mette
1072 in attesa il processo\footnote{a meno che non si sia impostato il socket per
1073   essere non bloccante (vedi sez.~\ref{sec:file_noblocking}), nel qual caso
1074   ritorna con l'errore \errcode{EAGAIN}.  Torneremo su questa modalità di
1075   operazione in sez.~\ref{sec:TCP_sock_multiplexing}.}  fintanto che non ne
1076 arriva una.
1077
1078 La funzione può essere usata solo con socket che supportino la connessione
1079 (cioè di tipo \const{SOCK\_STREAM}, \const{SOCK\_SEQPACKET} o
1080 \const{SOCK\_RDM}). Per alcuni protocolli che richiedono una conferma
1081 esplicita della connessione,\footnote{attualmente in Linux solo DECnet ha
1082   questo comportamento.} la funzione opera solo l'estrazione dalla coda delle
1083 connessioni, la conferma della connessione viene eseguita implicitamente dalla
1084 prima chiamata ad una \func{read} o una \func{write}, mentre il rifiuto della
1085 connessione viene eseguito con la funzione \func{close}.
1086
1087 È da chiarire che Linux presenta un comportamento diverso nella gestione degli
1088 errori rispetto ad altre implementazioni dei socket BSD, infatti la funzione
1089 \func{accept} passa gli errori di rete pendenti sul nuovo socket come codici
1090 di errore per \func{accept}, per cui l'applicazione deve tenerne conto ed
1091 eventualmente ripetere la chiamata alla funzione come per l'errore di
1092 \errcode{EAGAIN} (torneremo su questo in sez.~\ref{sec:TCP_echo_critical}).
1093 Un'altra differenza con BSD è che la funzione non fa ereditare al nuovo socket
1094 i flag del socket originale, come \const{O\_NONBLOCK},\footnote{ed in generale
1095   tutti quelli che si possono impostare con \func{fcntl}, vedi
1096   sez.~\ref{sec:file_fcntl_ioctl}.} che devono essere rispecificati ogni
1097 volta. Tutto questo deve essere tenuto in conto se si devono scrivere
1098 programmi portabili.
1099
1100 Il meccanismo di funzionamento di \func{accept} è essenziale per capire il
1101 funzionamento di un server: in generale infatti c'è sempre un solo socket in
1102 ascolto, detto per questo \textit{listening socket}, che resta per tutto il
1103 tempo nello stato \texttt{LISTEN}, mentre le connessioni vengono gestite dai
1104 nuovi socket, detti \textit{connected socket}, ritornati da \func{accept}, che
1105 si trovano automaticamente nello stato \texttt{ESTABLISHED}, e vengono
1106 utilizzati per lo scambio dei dati, che avviene su di essi, fino alla chiusura
1107 della connessione.  Si può riconoscere questo schema anche nell'esempio
1108 elementare di fig.~\ref{fig:TCP_daytime_iter_server_code}, dove per ogni
1109 connessione il socket creato da \func{accept} viene chiuso dopo l'invio dei
1110 dati.
1111
1112
1113 \subsection{Le funzioni \func{getsockname} e \func{getpeername}}
1114 \label{sec:TCP_get_names}
1115
1116 Oltre a tutte quelle viste finora, dedicate all'utilizzo dei socket, esistono
1117 alcune funzioni ausiliarie che possono essere usate per recuperare alcune
1118 informazioni relative ai socket ed alle connessioni ad essi associate. Le due
1119 funzioni più elementari sono queste, che vengono usate per ottenere i dati
1120 relativi alla socket pair associata ad un certo socket.
1121
1122 La prima funzione è \funcd{getsockname} e serve ad ottenere l'indirizzo locale
1123 associato ad un socket; il suo prototipo è:
1124 \begin{prototype}{sys/socket.h}
1125   {int getsockname(int sockfd, struct sockaddr *name, socklen\_t *namelen)}
1126   Legge l'indirizzo locale di un socket.
1127
1128 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
1129   errore. I codici di errore restituiti in \var{errno} sono i seguenti:
1130   \begin{errlist}
1131   \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor
1132     valido.
1133   \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket.
1134   \item[\errcode{ENOBUFS}] non ci sono risorse sufficienti nel sistema per
1135     eseguire l'operazione.
1136   \item[\errcode{EFAULT}] l'indirizzo \param{name} non è valido.
1137   \end{errlist}}
1138 \end{prototype}
1139
1140 La funzione restituisce la struttura degli indirizzi del socket \param{sockfd}
1141 nella struttura indicata dal puntatore \param{name} la cui lunghezza è
1142 specificata tramite l'argomento \param{namlen}. Quest'ultimo viene passato
1143 come indirizzo per avere indietro anche il numero di byte effettivamente
1144 scritti nella struttura puntata da \param{name}. Si tenga presente che se si è
1145 utilizzato un buffer troppo piccolo per \param{name} l'indirizzo risulterà
1146 troncato.
1147
1148 La funzione si usa tutte le volte che si vuole avere l'indirizzo locale di un
1149 socket; ad esempio può essere usata da un client (che usualmente non chiama
1150 \func{bind}) per ottenere numero IP e porta locale associati al socket
1151 restituito da una \func{connect}, o da un server che ha chiamato \func{bind}
1152 su un socket usando 0 come porta locale per ottenere il numero di porta
1153 effimera assegnato dal kernel.
1154
1155 Inoltre quando un server esegue una \func{bind} su un indirizzo generico, se
1156 chiamata dopo il completamento di una connessione sul socket restituito da
1157 \func{accept}, restituisce l'indirizzo locale che il kernel ha assegnato a
1158 quella connessione.
1159
1160 Tutte le volte che si vuole avere l'indirizzo remoto di un socket si usa la
1161 funzione \funcd{getpeername}, il cui prototipo è:
1162 \begin{prototype}{sys/socket.h}
1163   {int getpeername(int sockfd, struct sockaddr * name, socklen\_t * namelen)}
1164   Legge l'indirizzo remoto di un socket.
1165   
1166   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
1167     errore. I codici di errore restituiti in \var{errno} sono i seguenti:
1168   \begin{errlist}
1169   \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor
1170     valido.
1171   \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket.
1172   \item[\errcode{ENOTCONN}] il socket non è connesso.
1173   \item[\errcode{ENOBUFS}] non ci sono risorse sufficienti nel sistema per
1174     eseguire l'operazione.
1175   \item[\errcode{EFAULT}] l'argomento \param{name} punta al di fuori dello
1176     spazio di indirizzi del processo.
1177   \end{errlist}}
1178 \end{prototype}
1179
1180 La funzione è identica a \func{getsockname}, ed usa la stessa sintassi, ma
1181 restituisce l'indirizzo remoto del socket, cioè quello associato all'altro
1182 capo della connessione.  Ci si può chiedere a cosa serva questa funzione dato
1183 che dal lato client l'indirizzo remoto è sempre noto quando si esegue la
1184 \func{connect} mentre dal lato server si possono usare, come vedremo in
1185 fig.~\ref{fig:TCP_daytime_cunc_server_code}, i valori di ritorno di
1186 \func{accept}.
1187
1188 Il fatto è che in generale quest'ultimo caso non è sempre possibile.  In
1189 particolare questo avviene quando il server, invece di gestire la connessione
1190 direttamente in un processo figlio, come vedremo nell'esempio di server
1191 concorrente di sez.~\ref{sec:TCP_daytime_cunc_server}, lancia per ciascuna
1192 connessione un altro programma, usando \func{exec}.\footnote{questa ad esempio
1193   è la modalità con cui opera il \textsl{super-server} \cmd{inetd}, che può
1194   gestire tutta una serie di servizi diversi, eseguendo su ogni connessione
1195   ricevuta sulle porte tenute sotto controllo, il relativo server.}
1196
1197 In questo caso benché il processo figlio abbia una immagine della memoria che
1198 è copia di quella del processo padre (e contiene quindi anche la struttura
1199 ritornata da \func{accept}), all'esecuzione di \func{exec} verrà caricata in
1200 memoria l'immagine del programma eseguito, che a questo punto perde ogni
1201 riferimento ai valori tornati da \func{accept}.  Il socket descriptor però
1202 resta aperto, e se si è seguita una opportuna convenzione per rendere noto al
1203 programma eseguito qual è il socket connesso, \footnote{ad esempio il solito
1204   \cmd{inetd} fa sempre in modo che i file descriptor 0, 1 e 2 corrispondano
1205   al socket connesso.} quest'ultimo potrà usare la funzione \func{getpeername}
1206 per determinare l'indirizzo remoto del client.
1207
1208 Infine è da chiarire (si legga la pagina di manuale) che, come per
1209 \func{accept}, il terzo argomento, che è specificato dallo standard POSIX.1g
1210 come di tipo \code{socklen\_t *} in realtà deve sempre corrispondere ad un
1211 \ctyp{int *} come prima dello standard perché tutte le implementazioni dei
1212 socket BSD fanno questa assunzione.
1213
1214
1215 \subsection{La funzione \func{close}}
1216 \label{sec:TCP_func_close}
1217
1218 La funzione standard Unix \func{close} (vedi sez.~\ref{sec:file_open_close})
1219 che si usa sui file può essere usata con lo stesso effetto anche sui file
1220 descriptor associati ad un socket.
1221
1222 L'azione di questa funzione quando applicata a socket è di marcarlo come
1223 chiuso e ritornare immediatamente al processo. Una volta chiamata il socket
1224 descriptor non è più utilizzabile dal processo e non può essere usato come
1225 argomento per una \func{write} o una \func{read} (anche se l'altro capo della
1226 connessione non avesse chiuso la sua parte).  Il kernel invierà comunque tutti
1227 i dati che ha in coda prima di iniziare la sequenza di chiusura.
1228
1229 Vedremo più avanti in sez.~\ref{sec:sock_generic_options} come sia possibile
1230 cambiare questo comportamento, e cosa può essere fatto perché il processo
1231 possa assicurarsi che l'altro capo abbia ricevuto tutti i dati.
1232
1233 Come per tutti i file descriptor anche per i socket viene mantenuto un numero
1234 di riferimenti, per cui se più di un processo ha lo stesso socket aperto
1235 l'emissione del FIN e la sequenza di chiusura di TCP non viene innescata
1236 fintanto che il numero di riferimenti non si annulla, questo si applica, come
1237 visto in sez.~\ref{sec:file_shared_access}, sia ai file descriptor duplicati
1238 che a quelli ereditati dagli eventuali processi figli, ed è il comportamento
1239 che ci si aspetta in una qualunque applicazione client/server.
1240
1241 Per attivare immediatamente l'emissione del FIN e la sequenza di chiusura
1242 descritta in sez.~\ref{sec:TCP_conn_term}, si può invece usare la funzione
1243 \func{shutdown} su cui torneremo in seguito (vedi
1244 sez.~\ref{sec:TCP_shutdown}).
1245
1246
1247
1248 \section{Un esempio elementare: il servizio \textit{daytime}}
1249 \label{sec:TCP_daytime_application}
1250
1251 Avendo introdotto le funzioni di base per la gestione dei socket, potremo
1252 vedere in questa sezione un primo esempio di applicazione elementare che
1253 implementa il servizio \textit{daytime} su TCP, secondo quanto specificato
1254 dall'\href{http://www.ietf.org/rfc/rfc867.txt}{RFC~867}.  Prima di passare
1255 agli esempi del client e del server, inizieremo riesaminando con maggiori
1256 dettagli una peculiarità delle funzioni di I/O, già accennata in
1257 sez.~\ref{sec:file_read} e sez.~\ref{sec:file_write}, che nel caso dei socket è
1258 particolarmente rilevante.  Passeremo poi ad illustrare gli esempi
1259 dell'implementazione, sia dal lato client, che dal lato server, che si è
1260 realizzato sia in forma iterativa che concorrente.
1261
1262
1263 \subsection{Il comportamento delle funzioni di I/O}
1264 \label{sec:sock_io_behav}
1265
1266 Una cosa che si tende a dimenticare quando si ha a che fare con i socket è che
1267 le funzioni di input/output non sempre hanno lo stesso comportamento che
1268 avrebbero con i normali file di dati (in particolare questo accade per i
1269 socket di tipo stream).
1270
1271 Infatti con i socket è comune che funzioni come \func{read} o \func{write}
1272 possano restituire in input o scrivere in output un numero di byte minore di
1273 quello richiesto. Come già accennato in sez.~\ref{sec:file_read} questo è un
1274 comportamento normale per le funzioni di I/O, ma con i normali file di dati il
1275 problema si avverte solo in lettura, quando si incontra la fine del file. In
1276 generale non è così, e con i socket questo è particolarmente evidente.
1277
1278
1279 \begin{figure}[!htbp]
1280   \footnotesize \centering
1281   \begin{minipage}[c]{\codesamplewidth}
1282     \includecodesample{listati/FullRead.c}
1283   \end{minipage} 
1284   \normalsize
1285   \caption{La funzione \func{FullRead}, che legge esattamente \var{count} byte
1286     da un file descriptor, iterando opportunamente le letture.}
1287   \label{fig:sock_FullRead_code}
1288 \end{figure}
1289
1290 Quando ci si trova ad affrontare questo comportamento tutto quello che si deve
1291 fare è semplicemente ripetere la lettura (o la scrittura) per la quantità di
1292 byte restanti, tenendo conto che le funzioni si possono bloccare se i dati non
1293 sono disponibili: è lo stesso comportamento che si può avere scrivendo più di
1294 \const{PIPE\_BUF} byte in una \textit{pipe} (si riveda quanto detto in
1295 sez.~\ref{sec:ipc_pipes}).
1296
1297 Per questo motivo, seguendo l'esempio di R. W. Stevens in \cite{UNP1}, si sono
1298 definite due funzioni, \func{FullRead} e \func{FullWrite}, che eseguono
1299 lettura e scrittura tenendo conto di questa caratteristica, ed in grado di
1300 ritornare solo dopo avere letto o scritto esattamente il numero di byte
1301 specificato; il sorgente è riportato rispettivamente in
1302 fig.~\ref{fig:sock_FullRead_code} e fig.~\ref{fig:sock_FullWrite_code} ed è
1303 disponibile fra i sorgenti allegati alla guida nei file \file{FullRead.c} e
1304 \file{FullWrite.c}.
1305
1306 \begin{figure}[!htbp]
1307   \centering
1308   \footnotesize \centering
1309   \begin{minipage}[c]{\codesamplewidth}
1310     \includecodesample{listati/FullWrite.c}
1311   \end{minipage} 
1312   \normalsize
1313   \caption{La funzione \func{FullWrite}, che scrive esattamente \var{count}
1314     byte su un file descriptor, iterando opportunamente le scritture.}
1315   \label{fig:sock_FullWrite_code}
1316 \end{figure}
1317
1318 Come si può notare le due funzioni ripetono la lettura/scrittura in un ciclo
1319 fino all'esaurimento del numero di byte richiesti, in caso di errore viene
1320 controllato se questo è \errcode{EINTR} (cioè un'interruzione della
1321 \textit{system call} dovuta ad un segnale), nel qual caso l'accesso viene
1322 ripetuto, altrimenti l'errore viene ritornato al programma chiamante,
1323 interrompendo il ciclo.
1324
1325 Nel caso della lettura, se il numero di byte letti è zero, significa che si è
1326 arrivati alla fine del file (per i socket questo significa in genere che
1327 l'altro capo è stato chiuso, e quindi non sarà più possibile leggere niente) e
1328 pertanto si ritorna senza aver concluso la lettura di tutti i byte
1329 richiesti. Entrambe le funzioni restituiscono 0 in caso di successo, ed un
1330 valore negativo in caso di errore, \func{FullRead} restituisce il numero di
1331 byte non letti in caso di end-of-file prematuro.
1332
1333
1334 \subsection{Il client \textit{daytime}}
1335 \label{sec:TCP_daytime_client}
1336
1337 Il primo esempio di applicazione delle funzioni di base illustrate in
1338 sez.~\ref{sec:TCP_functions} è relativo alla creazione di un client elementare
1339 per il servizio \textit{daytime}, un servizio elementare, definito
1340 nell'\href{http://www.ietf.org/rfc/rfc867.txt}{RFC~867}, che restituisce
1341 l'ora locale della macchina a cui si effettua la richiesta, e che è assegnato
1342 alla porta 13.
1343
1344 In fig.~\ref{fig:TCP_daytime_client_code} è riportata la sezione principale
1345 del codice del nostro client. Il sorgente completo del programma
1346 (\texttt{TCP\_daytime.c}, che comprende il trattamento delle opzioni ed una
1347 funzione per stampare un messaggio di aiuto) è allegato alla guida nella
1348 sezione dei codici sorgente e può essere compilato su una qualunque macchina
1349 GNU/Linux.
1350
1351 \begin{figure}[!htbp]
1352   \footnotesize \centering
1353   \begin{minipage}[c]{\codesamplewidth}
1354     \includecodesample{listati/TCP_daytime.c}
1355   \end{minipage} 
1356   \normalsize
1357   \caption{Esempio di codice di un client elementare per il servizio
1358     \textit{daytime}.} 
1359   \label{fig:TCP_daytime_client_code}
1360 \end{figure}
1361
1362 Il programma anzitutto (\texttt{\small 1--5}) include gli header necessari;
1363 dopo la dichiarazione delle variabili (\texttt{\small 9--12}) si è omessa
1364 tutta la parte relativa al trattamento degli argomenti passati dalla linea di
1365 comando (effettuata con le apposite funzioni illustrate in
1366 sez.~\ref{sec:proc_opt_handling}).
1367
1368 Il primo passo (\texttt{\small 14--18}) è creare un socket TCP (quindi di tipo
1369 \const{SOCK\_STREAM} e di famiglia \const{AF\_INET}). La funzione
1370 \func{socket} ritorna il descrittore che viene usato per identificare il
1371 socket in tutte le chiamate successive. Nel caso la chiamata fallisca si
1372 stampa un errore (\texttt{\small 16}) con la funzione \func{perror} e si esce
1373 (\texttt{\small 17}) con un codice di errore.
1374
1375 Il passo seguente (\texttt{\small 19--27}) è quello di costruire un'apposita
1376 struttura \struct{sockaddr\_in} in cui sarà inserito l'indirizzo del server ed
1377 il numero della porta del servizio. Il primo passo (\texttt{\small 20}) è
1378 inizializzare tutto a zero, per poi inserire il tipo di indirizzo
1379 (\texttt{\small 21}) e la porta (\texttt{\small 22}), usando per quest'ultima
1380 la funzione \func{htons} per convertire il formato dell'intero usato dal
1381 computer a quello usato nella rete, infine (\texttt{\small 23--27}) si può
1382 utilizzare la funzione \func{inet\_pton} per convertire l'indirizzo numerico
1383 passato dalla linea di comando.
1384
1385 A questo punto (\texttt{\small 28--32}) usando la funzione \func{connect} sul
1386 socket creato in precedenza (\texttt{\small 29}) si può stabilire la
1387 connessione con il server. Per questo si deve utilizzare come secondo
1388 argomento la struttura preparata in precedenza con il relativo indirizzo; si
1389 noti come, esistendo diversi tipi di socket, si sia dovuto effettuare un cast.
1390 Un valore di ritorno della funzione negativo implica il fallimento della
1391 connessione, nel qual caso si stampa un errore (\texttt{\small 30}) e si
1392 ritorna (\texttt{\small 31}).
1393
1394 Completata con successo la connessione il passo successivo (\texttt{\small
1395   34--40}) è leggere la data dal socket; il protocollo prevede che il server
1396 invii sempre una stringa alfanumerica, il formato della stringa non è
1397 specificato dallo standard, per cui noi useremo il formato usato dalla
1398 funzione \func{ctime}, seguito dai caratteri di terminazione \verb|\r\n|, cioè
1399 qualcosa del tipo:
1400 \begin{verbatim}
1401 Wed Apr 4 00:53:00 2001\r\n
1402 \end{verbatim}
1403 questa viene letta dal socket (\texttt{\small 34}) con la funzione \func{read}
1404 in un buffer temporaneo; la stringa poi deve essere terminata (\texttt{\small
1405   35}) con il solito carattere nullo per poter essere stampata (\texttt{\small
1406   36}) sullo standard output con l'uso di \func{fputs}.
1407
1408 Come si è già spiegato in sez.~\ref{sec:sock_io_behav} la risposta dal socket
1409 potrà arrivare in un unico pacchetto di 26 byte (come avverrà senz'altro nel
1410 caso in questione) ma potrebbe anche arrivare in 26 pacchetti di un byte.  Per
1411 questo nel caso generale non si può mai assumere che tutti i dati arrivino con
1412 una singola lettura, pertanto quest'ultima deve essere effettuata in un ciclo
1413 in cui si continui a leggere fintanto che la funzione \func{read} non ritorni
1414 uno zero (che significa che l'altro capo ha chiuso la connessione) o un numero
1415 minore di zero (che significa un errore nella connessione).
1416
1417 Si noti come in questo caso la fine dei dati sia specificata dal server che
1418 chiude la connessione (anche questo è quanto richiesto dal protocollo); questa
1419 è una delle tecniche possibili (è quella usata pure dal protocollo HTTP), ma
1420 ce ne possono essere altre, ad esempio FTP marca la conclusione di un blocco
1421 di dati con la sequenza ASCII \verb|\r\n| (carriage return e line feed),
1422 mentre il DNS mette la lunghezza in testa ad ogni blocco che trasmette. Il
1423 punto essenziale è che TCP non provvede nessuna indicazione che permetta di
1424 marcare dei blocchi di dati, per cui se questo è necessario deve provvedere il
1425 programma stesso.
1426
1427 Se abilitiamo il servizio \textit{daytime}\footnote{in genere questo viene
1428   fornito direttamente dal \textsl{superdemone} \cmd{inetd}, pertanto basta
1429   assicurarsi che esso sia abilitato nel relativo file di configurazione.}
1430 possiamo verificare il funzionamento del nostro client, avremo allora:
1431 \begin{verbatim}
1432 [piccardi@gont sources]$ ./daytime 127.0.0.1
1433 Mon Apr 21 20:46:11 2003
1434 \end{verbatim}%$
1435 e come si vede tutto funziona regolarmente.
1436
1437
1438 \subsection{Un server \textit{daytime} iterativo}
1439 \label{sec:TCP_daytime_iter_server}
1440
1441 Dopo aver illustrato il client daremo anche un esempio di un server
1442 elementare, che sia anche in grado di rispondere al precedente client. Come
1443 primo esempio realizzeremo un server iterativo, in grado di fornire una sola
1444 risposta alla volta. Il codice del programma è nuovamente mostrato in
1445 fig.~\ref{fig:TCP_daytime_iter_server_code}, il sorgente completo
1446 (\texttt{TCP\_iter\_daytimed.c}) è allegato insieme agli altri file degli
1447 esempi.
1448
1449 \begin{figure}[!htbp]
1450   \footnotesize \centering
1451   \begin{minipage}[c]{\codesamplewidth}
1452     \includecodesample{listati/TCP_iter_daytimed.c}
1453   \end{minipage} 
1454   \normalsize
1455   \caption{Esempio di codice di un semplice server per il servizio daytime.}
1456   \label{fig:TCP_daytime_iter_server_code}
1457 \end{figure}
1458
1459 Come per il client si includono (\texttt{\small 1--9}) gli header necessari a
1460 cui è aggiunto quello per trattare i tempi, e si definiscono (\texttt{\small
1461   14--18}) alcune costanti e le variabili necessarie in seguito. Come nel caso
1462 precedente si sono omesse le parti relative al trattamento delle opzioni da
1463 riga di comando.
1464
1465 La creazione del socket (\texttt{\small 20--24}) è analoga al caso precedente,
1466 come pure l'inizializzazione (\texttt{\small 25--29}) della struttura
1467 \struct{sockaddr\_in}.  Anche in questo caso (\texttt{\small 28}) si usa la
1468 porta standard del servizio daytime, ma come indirizzo IP si usa
1469 (\texttt{\small 27}) il valore predefinito \const{INET\_ANY}, che corrisponde
1470 all'indirizzo generico.
1471
1472 Si effettua poi (\texttt{\small 30--34}) la chiamata alla funzione \func{bind}
1473 che permette di associare la precedente struttura al socket, in modo che
1474 quest'ultimo possa essere usato per accettare connessioni su una qualunque
1475 delle interfacce di rete locali. In caso di errore si stampa (\texttt{\small
1476   31}) un messaggio, e si termina (\texttt{\small 32}) immediatamente il
1477 programma.
1478
1479 Il passo successivo (\texttt{\small 35--39}) è quello di mettere ``\textsl{in
1480   ascolto}'' il socket; questo viene fatto (\texttt{\small 36}) con la
1481 funzione \func{listen} che dice al kernel di accettare connessioni per il
1482 socket che abbiamo creato; la funzione indica inoltre, con il secondo
1483 argomento, il numero massimo di connessioni che il kernel accetterà di mettere
1484 in coda per il suddetto socket. Di nuovo in caso di errore si stampa
1485 (\texttt{\small 37}) un messaggio, e si esce (\texttt{\small 38})
1486 immediatamente.
1487
1488 La chiamata a \func{listen} completa la preparazione del socket per l'ascolto
1489 (che viene chiamato anche \textit{listening descriptor}) a questo punto si può
1490 procedere con il ciclo principale (\texttt{\small 40--53}) che viene eseguito
1491 indefinitamente. Il primo passo (\texttt{\small 42}) è porsi in attesa di
1492 connessioni con la chiamata alla funzione \func{accept}, come in precedenza in
1493 caso di errore si stampa (\texttt{\small 43}) un messaggio, e si esce
1494 (\texttt{\small 44}).
1495
1496 Il processo resterà in stato di \textit{sleep} fin quando non arriva e viene
1497 accettata una connessione da un client; quando questo avviene \func{accept}
1498 ritorna, restituendo un secondo descrittore, che viene chiamato
1499 \textit{connected descriptor}, e che è quello che verrà usato dalla successiva
1500 chiamata alla \func{write} per scrivere la risposta al client.
1501
1502 Il ciclo quindi proseguirà determinando (\texttt{\small 46}) il tempo corrente
1503 con una chiamata a \texttt{time}, con il quale si potrà opportunamente
1504 costruire (\texttt{\small 47}) la stringa con la data da trasmettere
1505 (\texttt{\small 48}) con la chiamata a \func{write}. Completata la
1506 trasmissione il nuovo socket viene chiuso (\texttt{\small 52}).  A questo
1507 punto il ciclo si chiude ricominciando da capo in modo da poter ripetere
1508 l'invio della data in risposta ad una successiva connessione.
1509
1510 È importante notare che questo server è estremamente elementare, infatti, a
1511 parte il fatto di poter essere usato solo con indirizzi IPv4, esso è in grado
1512 di rispondere ad un solo un client alla volta: è cioè, come dicevamo, un
1513 \textsl{server iterativo}. Inoltre è scritto per essere lanciato da linea di
1514 comando, se lo si volesse utilizzare come demone occorrerebbero le opportune
1515 modifiche\footnote{come una chiamata a \func{daemon} prima dell'inizio del
1516   ciclo principale.} per tener conto di quanto illustrato in
1517 sez.~\ref{sec:sess_daemon}. Si noti anche che non si è inserita nessuna forma
1518 di gestione della terminazione del processo, dato che tutti i file descriptor
1519 vengono chiusi automaticamente alla sua uscita, e che, non generando figli,
1520 non è necessario preoccuparsi di gestire la loro terminazione.
1521
1522
1523 \subsection{Un server \textit{daytime} concorrente}
1524 \label{sec:TCP_daytime_cunc_server}
1525
1526 Il server \texttt{daytime} dell'esempio in
1527 sez.~\ref{sec:TCP_daytime_iter_server} è un tipico esempio di server iterativo,
1528 in cui viene servita una richiesta alla volta; in generale però, specie se il
1529 servizio è più complesso e comporta uno scambio di dati più sostanzioso di
1530 quello in questione, non è opportuno bloccare un server nel servizio di un
1531 client per volta; per questo si ricorre alle capacità di multitasking del
1532 sistema.
1533
1534 Come spiegato in sez.~\ref{sec:proc_fork} una delle modalità più comuni di
1535 funzionamento da parte dei server è quella di usare la funzione \func{fork}
1536 per creare, ad ogni richiesta da parte di un client, un processo figlio che si
1537 incarichi della gestione della comunicazione.  Si è allora riscritto il server
1538 \textit{daytime} dell'esempio precedente in forma concorrente, inserendo anche
1539 una opzione per la stampa degli indirizzi delle connessioni ricevute.
1540
1541 In fig.~\ref{fig:TCP_daytime_cunc_server_code} è mostrato un estratto del
1542 codice, in cui si sono tralasciati il trattamento delle opzioni e le parti
1543 rimaste invariate rispetto al precedente esempio (cioè tutta la parte
1544 riguardante l'apertura passiva del socket). Al solito il sorgente completo del
1545 server, nel file \texttt{TCP\_cunc\_daytimed.c}, è allegato insieme ai
1546 sorgenti degli altri esempi.
1547
1548 \begin{figure}[!htbp]
1549   \footnotesize \centering
1550   \begin{minipage}[c]{\codesamplewidth}
1551     \includecodesample{listati/TCP_cunc_daytimed.c}
1552   \end{minipage} 
1553   \normalsize
1554   \caption{Esempio di codice di un server concorrente elementare per il 
1555     servizio daytime.}
1556   \label{fig:TCP_daytime_cunc_server_code}
1557 \end{figure}
1558
1559 Stavolta (\texttt{\small 21--26}) la funzione \func{accept} è chiamata
1560 fornendo una struttura di indirizzi in cui saranno ritornati l'indirizzo IP e
1561 la porta da cui il client effettua la connessione, che in un secondo tempo,
1562 (\texttt{\small 40--44}), se il logging è abilitato, stamperemo sullo standard
1563 output.
1564
1565 Quando \func{accept} ritorna il server chiama la funzione \func{fork}
1566 (\texttt{\small 27--31}) per creare il processo figlio che effettuerà
1567 (\texttt{\small 32--46}) tutte le operazioni relative a quella connessione,
1568 mentre il padre proseguirà l'esecuzione del ciclo principale in attesa di
1569 ulteriori connessioni.
1570
1571 Si noti come il figlio operi solo sul socket connesso, chiudendo
1572 immediatamente (\texttt{\small 33}) il socket \var{list\_fd}; mentre il padre
1573 continua ad operare solo sul socket in ascolto chiudendo (\texttt{\small 48})
1574 \var{conn\_fd} al ritorno dalla \func{fork}. Per quanto abbiamo detto in
1575 sez.~\ref{sec:TCP_func_close} nessuna delle due chiamate a \func{close} causa
1576 l'innesco della sequenza di chiusura perché il numero di riferimenti al file
1577 descriptor non si è annullato.
1578
1579 Infatti subito dopo la creazione del socket \var{list\_fd} ha una referenza, e
1580 lo stesso vale per \var{conn\_fd} dopo il ritorno di \func{accept}, ma dopo la
1581 \func{fork} i descrittori vengono duplicati nel padre e nel figlio per cui
1582 entrambi i socket si trovano con due referenze. Questo fa si che quando il
1583 padre chiude \var{sock\_fd} esso resta con una referenza da parte del figlio,
1584 e sarà definitivamente chiuso solo quando quest'ultimo, dopo aver completato
1585 le sue operazioni, chiamerà (\texttt{\small 45}) la funzione \func{close}.
1586
1587 In realtà per il figlio non sarebbe necessaria nessuna chiamata a
1588 \func{close}, in quanto con la \func{exit} finale (\texttt{\small 45}) tutti i
1589 file descriptor, quindi anche quelli associati ai socket, vengono
1590 automaticamente chiusi.  Tuttavia si è preferito effettuare esplicitamente le
1591 chiusure per avere una maggiore chiarezza del codice, e per evitare eventuali
1592 errori, prevenendo ad esempio un uso involontario del \textit{listening
1593   descriptor}.
1594
1595 Si noti invece come sia essenziale che il padre chiuda ogni volta il socket
1596 connesso dopo la \func{fork}; se così non fosse nessuno di questi socket
1597 sarebbe effettivamente chiuso dato che alla chiusura da parte del figlio
1598 resterebbe ancora un riferimento nel padre. Si avrebbero così due effetti: il
1599 padre potrebbe esaurire i descrittori disponibili (che sono un numero limitato
1600 per ogni processo) e soprattutto nessuna delle connessioni con i client
1601 verrebbe chiusa.
1602
1603 Come per ogni server iterativo il lavoro di risposta viene eseguito
1604 interamente dal processo figlio. Questo si incarica (\texttt{\small 34}) di
1605 chiamare \func{time} per leggere il tempo corrente, e di stamparlo
1606 (\texttt{\small 35}) sulla stringa contenuta in \var{buffer} con l'uso di
1607 \func{snprintf} e \func{ctime}. Poi la stringa viene scritta (\texttt{\small
1608   36--39}) sul socket, controllando che non ci siano errori. Anche in questo
1609 caso si è evitato il ricorso a \func{FullWrite} in quanto la stringa è
1610 estremamente breve e verrà senz'altro scritta in un singolo segmento.
1611
1612 Inoltre nel caso sia stato abilitato il \textit{logging} delle connessioni, si
1613 provvede anche (\texttt{\small 40--43}) a stampare sullo standard output
1614 l'indirizzo e la porta da cui il client ha effettuato la connessione, usando i
1615 valori contenuti nelle strutture restituite da \func{accept}, eseguendo le
1616 opportune conversioni con \func{inet\_ntop} e \func{ntohs}.
1617
1618 Ancora una volta l'esempio è estremamente semplificato, si noti come di nuovo
1619 non si sia gestita né la terminazione del processo né il suo uso come demone,
1620 che tra l'altro sarebbe stato incompatibile con l'uso della opzione di logging
1621 che stampa gli indirizzi delle connessioni sullo standard output. Un altro
1622 aspetto tralasciato è la gestione della terminazione dei processi figli,
1623 torneremo su questo più avanti quando tratteremo alcuni esempi di server più
1624 complessi.
1625
1626
1627
1628 \section{Un esempio più completo: il servizio \textit{echo}}
1629 \label{sec:TCP_echo_application}
1630
1631 L'esempio precedente, basato sul servizio \textit{daytime}, è un esempio molto
1632 elementare, in cui il flusso dei dati va solo nella direzione dal server al
1633 client. In questa sezione esamineremo un esempio di applicazione client/server
1634 un po' più complessa, che usi i socket TCP per una comunicazione in entrambe
1635 le direzioni.
1636
1637 Ci limiteremo a fornire una implementazione elementare, che usi solo le
1638 funzioni di base viste finora, ma prenderemo in esame, oltre al comportamento
1639 in condizioni normali, anche tutti i possibili scenari particolari (errori,
1640 sconnessione della rete, crash del client o del server durante la connessione)
1641 che possono avere luogo durante l'impiego di un'applicazione di rete, partendo
1642 da una versione primitiva che dovrà essere rimaneggiata di volta in volta per
1643 poter tenere conto di tutte le evenienze che si possono manifestare nella vita
1644 reale di un'applicazione di rete, fino ad arrivare ad un'implementazione
1645 completa.
1646
1647
1648 \subsection{Il servizio \textit{echo}}
1649 \label{sec:TCP_echo}
1650
1651
1652 Nella ricerca di un servizio che potesse fare da esempio per una comunicazione
1653 bidirezionale, si è deciso, seguendo la scelta di Stevens in \cite{UNP1}, di
1654 usare il servizio \textit{echo}, che si limita a restituire in uscita quanto
1655 immesso in ingresso. Infatti, nonostante la sua estrema semplicità, questo
1656 servizio costituisce il prototipo ideale per una generica applicazione di rete
1657 in cui un server risponde alle richieste di un client.  Nel caso di una
1658 applicazione più complessa quello che si potrà avere in più è una elaborazione
1659 dell'input del client, che in molti casi viene interpretato come un comando,
1660 da parte di un server che risponde fornendo altri dati in uscita.
1661
1662 Il servizio \textit{echo} è uno dei servizi standard solitamente provvisti
1663 direttamente dal superserver \cmd{inetd}, ed è definito
1664 dall'\href{http://www.ietf.org/rfc/rfc862.txt}{RFC~862}. Come dice il nome il
1665 servizio deve riscrivere indietro sul socket i dati che gli vengono inviati in
1666 ingresso. L'RFC descrive le specifiche del servizio sia per TCP che UDP, e per
1667 il primo stabilisce che una volta stabilita la connessione ogni dato in
1668 ingresso deve essere rimandato in uscita fintanto che il chiamante non ha
1669 chiude la connessione. Al servizio è assegnata la porta riservata 7.
1670
1671 Nel nostro caso l'esempio sarà costituito da un client che legge una linea di
1672 caratteri dallo standard input e la scrive sul server. A sua volta il server
1673 leggerà la linea dalla connessione e la riscriverà immutata all'indietro. Sarà
1674 compito del client leggere la risposta del server e stamparla sullo standard
1675 output.
1676
1677
1678 \subsection{Il client \textit{echo}: prima versione}
1679 \label{sec:TCP_echo_client}
1680
1681 Il codice della prima versione del client per il servizio \textit{echo},
1682 disponibile nel file \texttt{TCP\_echo\_first.c}, è riportato in
1683 fig.~\ref{fig:TCP_echo_client_1}. Esso ricalca la struttura del precedente
1684 client per il servizio \textit{daytime} (vedi
1685 sez.~\ref{sec:TCP_daytime_client}), e la prima parte (\texttt{\small 10--27})
1686 è sostanzialmente identica, a parte l'uso di una porta diversa.
1687
1688 \begin{figure}[!htbp]
1689   \footnotesize \centering
1690   \begin{minipage}[c]{\codesamplewidth}
1691     \includecodesample{listati/TCP_echo_first.c}
1692   \end{minipage} 
1693   \normalsize
1694   \caption{Codice della prima versione del client \textit{echo}.}
1695   \label{fig:TCP_echo_client_1}
1696 \end{figure}
1697
1698 Al solito si è tralasciata la sezione relativa alla gestione delle opzioni a
1699 riga di comando.  Una volta dichiarate le variabili, si prosegue
1700 (\texttt{\small 10--13}) con della creazione del socket con l'usuale controllo
1701 degli errori, alla preparazione (\texttt{\small 14--17}) della struttura
1702 dell'indirizzo, che stavolta usa la porta 7 riservata al servizio
1703 \textit{echo}, infine si converte (\texttt{\small 18--22}) l'indirizzo
1704 specificato a riga di comando.  A questo punto (\texttt{\small 23--27}) si può
1705 eseguire la connessione al server secondo la stessa modalità usata in
1706 sez.~\ref{sec:TCP_daytime_client}.
1707
1708 Completata la connessione, per gestire il funzionamento del protocollo si usa
1709 la funzione \code{ClientEcho}, il cui codice si è riportato a parte in
1710 fig.~\ref{fig:TCP_client_echo_sub}. Questa si preoccupa di gestire tutta la
1711 comunicazione, leggendo una riga alla volta dallo standard input \file{stdin},
1712 scrivendola sul socket e ristampando su \file{stdout} quanto ricevuto in
1713 risposta dal server. Al ritorno dalla funzione (\texttt{\small 30--31}) anche
1714 il programma termina.
1715
1716 La funzione \code{ClientEcho} utilizza due buffer (\texttt{\small 3}) per
1717 gestire i dati inviati e letti sul socket.  La comunicazione viene gestita
1718 all'interno di un ciclo (\texttt{\small 5--10}), i dati da inviare sulla
1719 connessione vengono presi dallo \file{stdin} usando la funzione \func{fgets},
1720 che legge una linea di testo (terminata da un \texttt{CR} e fino al massimo di
1721 \const{MAXLINE} caratteri) e la salva sul buffer di invio.
1722
1723 Si usa poi (\texttt{\small 6}) la funzione \func{FullWrite}, vista in
1724 sez.~\ref{sec:sock_io_behav}, per scrivere i dati sul socket, gestendo
1725 automaticamente l'invio multiplo qualora una singola \func{write} non sia
1726 sufficiente.  I dati vengono riletti indietro (\texttt{\small 7}) con una
1727 \func{read}\footnote{si è fatta l'assunzione implicita che i dati siano
1728   contenuti tutti in un solo segmento, così che la chiamata a \func{read} li
1729   restituisca sempre tutti; avendo scelto una dimensione ridotta per il buffer
1730   questo sarà sempre vero, vedremo più avanti come superare il problema di
1731   rileggere indietro tutti e soli i dati disponibili, senza bloccarsi.} sul
1732 buffer di ricezione e viene inserita (\texttt{\small 8}) la terminazione della
1733 stringa e per poter usare (\texttt{\small 9}) la funzione \func{fputs} per
1734 scriverli su \file{stdout}.
1735
1736 \begin{figure}[!htbp]
1737   \footnotesize \centering
1738   \begin{minipage}[c]{\codesamplewidth}
1739     \includecodesample{listati/ClientEcho_first.c}
1740   \end{minipage} 
1741   \normalsize
1742   \caption{Codice della prima versione della funzione \texttt{ClientEcho} per 
1743     la gestione del servizio \textit{echo}.}
1744   \label{fig:TCP_client_echo_sub}
1745 \end{figure}
1746
1747 Quando si concluderà l'invio di dati mandando un end-of-file sullo standard
1748 input si avrà il ritorno di \func{fgets} con un puntatore nullo (si riveda
1749 quanto spiegato in sez.~\ref{sec:file_line_io}) e la conseguente uscita dal
1750 ciclo; al che la subroutine ritorna ed il nostro programma client termina.
1751
1752 Si può effettuare una verifica del funzionamento del client abilitando il
1753 servizio \textit{echo} nella configurazione di \cmd{initd} sulla propria
1754 macchina ed usandolo direttamente verso di esso in locale, vedremo in
1755 dettaglio più avanti (in sez.~\ref{sec:TCP_echo_startup}) il funzionamento del
1756 programma, usato però con la nostra versione del server \textit{echo}, che
1757 illustriamo immediatamente.
1758
1759
1760 \subsection{Il server \textit{echo}: prima versione}
1761 \label{sec:TCPsimp_server_main}
1762
1763 La prima versione del server, contenuta nel file \texttt{TCP\_echod\_first.c},
1764 è riportata in fig.~\ref{fig:TCP_echo_server_first_code}. Come abbiamo fatto
1765 per il client anche il server è stato diviso in un corpo principale,
1766 costituito dalla funzione \code{main}, che è molto simile a quello visto nel
1767 precedente esempio per il server del servizio \textit{daytime} di
1768 sez.~\ref{sec:TCP_daytime_cunc_server}, e da una funzione ausiliaria
1769 \code{ServEcho} che si cura della gestione del servizio.
1770
1771 \begin{figure}[!htbp]
1772   \footnotesize \centering
1773   \begin{minipage}[c]{\codesamplewidth}
1774     \includecodesample{listati/TCP_echod_first.c}
1775   \end{minipage} 
1776   \normalsize
1777   \caption{Codice del corpo principale della prima versione del server
1778     per il servizio \textit{echo}.}
1779   \label{fig:TCP_echo_server_first_code}
1780 \end{figure}
1781
1782 In questo caso però, rispetto a quanto visto nell'esempio di
1783 fig.~\ref{fig:TCP_daytime_cunc_server_code} si è preferito scrivere il server
1784 curando maggiormente alcuni dettagli, per tenere conto anche di alcune
1785 esigenze generali (che non riguardano direttamente la rete), come la
1786 possibilità di lanciare il server anche in modalità interattiva e la cessione
1787 dei privilegi di amministratore non appena questi non sono più necessari.
1788
1789 La sezione iniziale del programma (\texttt{\small 8--21}) è la stessa del
1790 server di sez.~\ref{sec:TCP_daytime_cunc_server}, ed ivi descritta in
1791 dettaglio: crea il socket, inizializza l'indirizzo e esegue \func{bind}; dato
1792 che quest'ultima funzione viene usata su una porta riservata, il server dovrà
1793 essere eseguito da un processo con i privilegi di amministratore, pena il
1794 fallimento della chiamata.
1795
1796 Una volta eseguita la funzione \func{bind} però i privilegi di amministratore
1797 non sono più necessari, per questo è sempre opportuno rilasciarli, in modo da
1798 evitare problemi in caso di eventuali vulnerabilità del server.  Per questo
1799 prima (\texttt{\small 22--26}) si esegue \func{setgid} per assegnare il
1800 processo ad un gruppo senza privilegi,\footnote{si è usato il valore 65534,
1801   ovvero -1 per il formato \ctyp{short}, che di norma in tutte le
1802   distribuzioni viene usato per identificare il gruppo \texttt{nogroup} e
1803   l'utente \texttt{nobody}, usati appunto per eseguire programmi che non
1804   richiedono nessun privilegio particolare.} e poi si ripete (\texttt{\small
1805   27--30}) l'operazione usando \func{setuid} per cambiare anche
1806 l'utente.\footnote{si tenga presente che l'ordine in cui si eseguono queste
1807   due operazioni è importante, infatti solo avendo i privilegi di
1808   amministratore si può cambiare il gruppo di un processo ad un altro di cui
1809   non si fa parte, per cui chiamare prima \func{setuid} farebbe fallire una
1810   successiva chiamata a \func{setgid}.  Inoltre si ricordi (si riveda quanto
1811   esposto in sez.~\ref{sec:proc_perms}) che usando queste due funzioni il
1812   rilascio dei privilegi è irreversibile.}  Infine (\texttt{\small 30--36}),
1813 qualora sia impostata la variabile \var{demonize}, prima (\texttt{\small 31})
1814 si apre il sistema di logging per la stampa degli errori, e poi
1815 (\texttt{\small 32--35}) si invoca \func{daemon} per eseguire in background il
1816 processo come demone.
1817
1818 A questo punto il programma riprende di nuovo lo schema già visto usato dal
1819 server per il servizio \textit{daytime}, con l'unica differenza della chiamata
1820 alla funzione \code{PrintErr}, riportata in fig.~\ref{fig:TCP_PrintErr}, al
1821 posto di \func{perror} per la stampa degli errori. 
1822
1823 Si inizia con il porre (\texttt{\small 37--41}) in ascolto il socket, e poi si
1824 esegue indefinitamente il ciclo principale (\texttt{\small 42--59}).
1825 All'interno di questo si ricevono (\texttt{\small 43--47}) le connessioni,
1826 creando (\texttt{\small 48--51}) un processo figlio per ciascuna di esse.
1827 Quest'ultimo (\texttt{\small 52--56}), chiuso (\texttt{\small 53}) il
1828 \textit{listening socket}, esegue (\texttt{\small 54}) la funzione di gestione
1829 del servizio \code{ServEcho}, ed al ritorno di questa esce (\texttt{\small
1830   55}).
1831
1832 Il padre invece si limita (\texttt{\small 57}) a chiudere il \textit{connected
1833   socket} per ricominciare da capo il ciclo in attesa di nuove connessioni. In
1834 questo modo si ha un server concorrente. La terminazione del padre non è
1835 gestita esplicitamente, e deve essere effettuata inviando un segnale al
1836 processo.
1837
1838 Avendo trattato direttamente la gestione del programma come demone, si è
1839 dovuto anche provvedere alla necessità di poter stampare eventuali messaggi di
1840 errore attraverso il sistema del \textit{syslog} trattato in
1841 sez.~\ref{sec:sess_daemon}. Come accennato questo è stato fatto utilizzando
1842 come \textit{wrapper} la funzione \code{PrintErr}, il cui codice è riportato
1843 in fig.~\ref{fig:TCP_PrintErr}.
1844
1845 In essa ci si limita a controllare (\texttt{\small 2}) se è stato impostato
1846 (valore attivo per default) l'uso come demone, nel qual caso (\texttt{\small
1847   3}) si usa \func{syslog} (vedi sez.~\ref{sec:sess_daemon}) per stampare il
1848 messaggio di errore fornito come argomento sui log di sistema. Se invece si è
1849 in modalità interattiva (attivabile con l'opzione \texttt{-i}) si usa
1850 (\texttt{\small 5}) semplicemente la funzione \func{perror} per stampare sullo
1851 standard error.
1852
1853 \begin{figure}[!htbp]
1854   \footnotesize \centering
1855   \begin{minipage}[c]{\codesamplewidth}
1856     \includecodesample{listati/PrintErr.c}
1857   \end{minipage} 
1858   \normalsize
1859   \caption{Codice della funzione \code{PrintErr} per la
1860     generalizzazione della stampa degli errori sullo standard input o
1861     attraverso il \texttt{syslog}.}
1862   \label{fig:TCP_PrintErr}
1863 \end{figure}
1864
1865 La gestione del servizio \textit{echo} viene effettuata interamente nella
1866 funzione \code{ServEcho}, il cui codice è mostrato in
1867 fig.~\ref{fig:TCP_ServEcho_first}, e la comunicazione viene gestita all'interno
1868 di un ciclo (\texttt{\small 6--13}).  I dati inviati dal client vengono letti
1869 (\texttt{\small 6}) dal socket con una semplice \func{read}, di cui non si
1870 controlla lo stato di uscita, assumendo che ritorni solo in presenza di dati
1871 in arrivo. La riscrittura (\texttt{\small 7}) viene invece gestita dalla
1872 funzione \func{FullWrite} (descritta in fig.~\ref{fig:sock_FullWrite_code}) che
1873 si incarica di tenere conto automaticamente della possibilità che non tutti i
1874 dati di cui è richiesta la scrittura vengano trasmessi con una singola
1875 \func{write}.
1876
1877 \begin{figure}[!htbp] 
1878   \footnotesize \centering
1879   \begin{minipage}[c]{\codesamplewidth}
1880     \includecodesample{listati/ServEcho_first.c}
1881   \end{minipage} 
1882   \normalsize
1883   \caption{Codice della prima versione della funzione \code{ServEcho} per la
1884     gestione del servizio \textit{echo}.}
1885   \label{fig:TCP_ServEcho_first}
1886 \end{figure}
1887
1888 In caso di errore di scrittura (si ricordi che \func{FullWrite} restituisce un
1889 valore nullo in caso di successo) si provvede (\texttt{\small 8--10}) a
1890 stampare il relativo messaggio con \func{PrintErr}.  Quando il client chiude
1891 la connessione il ricevimento del FIN fa ritornare la \func{read} con un
1892 numero di byte letti pari a zero, il che causa l'uscita dal ciclo e il ritorno
1893 (\texttt{\small 12}) della funzione, che a sua volta causa la terminazione del
1894 processo figlio.
1895
1896
1897 \subsection{L'avvio e il funzionamento normale}
1898 \label{sec:TCP_echo_startup}
1899
1900 Benché il codice dell'esempio precedente sia molto ridotto, esso ci permetterà
1901 di considerare in dettaglio le varie problematiche che si possono incontrare
1902 nello scrivere un'applicazione di rete. Infatti attraverso l'esame delle sue
1903 modalità di funzionamento normali, all'avvio e alla terminazione, e di quello
1904 che avviene nelle varie situazioni limite, da una parte potremo approfondire
1905 la comprensione del protocollo TCP/IP e dall'altra ricavare le indicazioni
1906 necessarie per essere in grado di scrivere applicazioni robuste, in grado di
1907 gestire anche i casi limite.
1908
1909 Il primo passo è compilare e lanciare il server (da root, per poter usare la
1910 porta 7 che è riservata), alla partenza esso eseguirà l'apertura passiva con
1911 la sequenza delle chiamate a \func{socket}, \func{bind}, \func{listen} e poi
1912 si bloccherà nella \func{accept}. A questo punto si potrà controllarne lo
1913 stato con \cmd{netstat}:
1914 \begin{verbatim}
1915 [piccardi@roke piccardi]$ netstat -at
1916 Active Internet connections (servers and established)
1917 Proto Recv-Q Send-Q Local Address           Foreign Address         State 
1918 ...
1919 tcp        0      0 *:echo                  *:*                     LISTEN
1920 ...
1921 \end{verbatim} %$
1922 che ci mostra come il socket sia in ascolto sulla porta richiesta, accettando
1923 connessioni da qualunque indirizzo e da qualunque porta e su qualunque
1924 interfaccia locale.
1925
1926 A questo punto si può lanciare il client, esso chiamerà \func{socket} e
1927 \func{connect}; una volta completato il \textit{three way handshake} la
1928 connessione è stabilita; la \func{connect} ritornerà nel client\footnote{si
1929   noti che è sempre la \func{connect} del client a ritornare per prima, in
1930   quanto questo avviene alla ricezione del secondo segmento (l'ACK del server)
1931   del \textit{three way handshake}, la \func{accept} del server ritorna solo
1932   dopo un altro mezzo RTT quando il terzo segmento (l'ACK del client) viene
1933   ricevuto.}  e la \func{accept} nel server, ed usando di nuovo \cmd{netstat}
1934 otterremmo che:
1935 \begin{verbatim}
1936 Active Internet connections (servers and established)
1937 Proto Recv-Q Send-Q Local Address           Foreign Address         State
1938 tcp        0      0 *:echo                  *:*                     LISTEN
1939 tcp        0      0 roke:echo               gont:32981              ESTABLISHED
1940 \end{verbatim}
1941 mentre per quanto riguarda l'esecuzione dei programmi avremo che:
1942 \begin{itemize}
1943 \item il client chiama la funzione \code{ClientEcho} che si blocca sulla
1944   \func{fgets} dato che non si è ancora scritto nulla sul terminale.
1945 \item il server eseguirà una \func{fork} facendo chiamare al processo figlio
1946   la funzione \code{ServEcho}, quest'ultima si bloccherà sulla \func{read}
1947   dal socket sul quale ancora non sono presenti dati.
1948 \item il processo padre del server chiamerà di nuovo \func{accept}
1949   bloccandosi fino all'arrivo di un'altra connessione.
1950 \end{itemize}
1951 e se usiamo il comando \cmd{ps} per esaminare lo stato dei processi otterremo
1952 un risultato del tipo:
1953 \begin{verbatim}
1954 [piccardi@roke piccardi]$ ps ax
1955   PID TTY      STAT   TIME COMMAND
1956  ...  ...      ...    ...  ...
1957  2356 pts/0    S      0:00 ./echod
1958  2358 pts/1    S      0:00 ./echo 127.0.0.1
1959  2359 pts/0    S      0:00 ./echod
1960 \end{verbatim} %$
1961 (dove si sono cancellate le righe inutili) da cui si evidenzia la presenza di
1962 tre processi, tutti in stato di \textit{sleep} (vedi
1963 tab.~\ref{tab:proc_proc_states}).
1964
1965 Se a questo punto si inizia a scrivere qualcosa sul client non sarà trasmesso
1966 niente fin tanto che non si prema il tasto di a capo (si ricordi quanto detto
1967 in sez.~\ref{sec:file_line_io} a proposito dell'I/O su terminale), solo allora
1968 \func{fgets} ritornerà ed il client scriverà quanto immesso sul socket, per
1969 poi passare a rileggere quanto gli viene inviato all'indietro dal server, che
1970 a sua volta sarà inviato sullo standard output, che nel caso ne provoca
1971 l'immediata stampa a video.
1972
1973
1974 \subsection{La conclusione normale}
1975 \label{sec:TCP_echo_conclusion}
1976
1977 Tutto quello che scriveremo sul client sarà rimandato indietro dal server e
1978 ristampato a video fintanto che non concluderemo l'immissione dei dati; una
1979 sessione tipica sarà allora del tipo: 
1980 \begin{verbatim}
1981 [piccardi@roke sources]$ ./echo 127.0.0.1
1982 Questa e` una prova
1983 Questa e` una prova
1984 Ho finito
1985 Ho finito
1986 \end{verbatim} %$
1987 che termineremo inviando un EOF dal terminale (usando la combinazione di tasti
1988 ctrl-D, che non compare a schermo); se eseguiamo un \cmd{netstat} a questo
1989 punto avremo:
1990 \begin{verbatim}
1991 [piccardi@roke piccardi]$ netstat -at 
1992 tcp        0      0 *:echo                  *:*                     LISTEN
1993 tcp        0      0 localhost:33032         localhost:echo          TIME_WAIT
1994 \end{verbatim} %$
1995 con il client che entra in \texttt{TIME\_WAIT}.
1996
1997 Esaminiamo allora in dettaglio la sequenza di eventi che porta alla
1998 terminazione normale della connessione, che ci servirà poi da riferimento
1999 quando affronteremo il comportamento in caso di conclusioni anomale:
2000
2001 \begin{enumerate}
2002 \item inviando un carattere di EOF da terminale la \func{fgets} ritorna
2003   restituendo un puntatore nullo che causa l'uscita dal ciclo di \code{while},
2004   così la funzione \code{ClientEcho} ritorna.
2005 \item al ritorno di \code{ClientEcho} ritorna anche la funzione \code{main}, e
2006   come parte del processo di terminazione tutti i file descriptor vengono chiusi
2007   (si ricordi quanto detto in sez.~\ref{sec:proc_term_conclusion}); questo
2008   causa la chiusura del socket di comunicazione; il client allora invierà un
2009   FIN al server a cui questo risponderà con un ACK.  A questo punto il client
2010   verrà a trovarsi nello stato \texttt{FIN\_WAIT\_2} ed il server nello stato
2011   \texttt{CLOSE\_WAIT} (si riveda quanto spiegato in
2012   sez.~\ref{sec:TCP_conn_term}).
2013 \item quando il server riceve il FIN la \func{read} del processo figlio che
2014   gestisce la connessione ritorna restituendo 0 causando così l'uscita dal
2015   ciclo e il ritorno di \code{ServEcho}, a questo punto il processo figlio
2016   termina chiamando \func{exit}.
2017 \item all'uscita del figlio tutti i file descriptor vengono chiusi, la
2018   chiusura del socket connesso fa sì che venga effettuata la sequenza finale
2019   di chiusura della connessione, viene emesso un FIN dal server che riceverà
2020   un ACK dal client, a questo punto la connessione è conclusa e il client
2021   resta nello stato \texttt{TIME\_WAIT}.
2022 \end{enumerate}
2023
2024
2025 \subsection{La gestione dei processi figli}
2026 \label{sec:TCP_child_hand}
2027
2028 Tutto questo riguarda la connessione, c'è però da tenere conto dell'effetto
2029 del procedimento di chiusura del processo figlio nel server (si veda quanto
2030 esaminato in sez.~\ref{sec:proc_termination}). In questo caso avremo l'invio
2031 del segnale \signal{SIGCHLD} al padre, ma dato che non si è installato un
2032 gestore e che l'azione predefinita per questo segnale è quella di essere
2033 ignorato, non avendo predisposto la ricezione dello stato di terminazione,
2034 otterremo che il processo figlio entrerà nello stato di \textit{zombie} (si
2035 riveda quanto illustrato in sez.~\ref{sec:sig_sigchld}), come risulterà
2036 ripetendo il comando \cmd{ps}:
2037 \begin{verbatim}
2038  2356 pts/0    S      0:00 ./echod
2039  2359 pts/0    Z      0:00 [echod <defunct>]
2040 \end{verbatim}
2041
2042 Dato che non è il caso di lasciare processi \textit{zombie}, occorrerà
2043 ricevere opportunamente lo stato di terminazione del processo (si veda
2044 sez.~\ref{sec:proc_wait}), cosa che faremo utilizzando \signal{SIGCHLD}
2045 secondo quanto illustrato in sez.~\ref{sec:sig_sigchld}. Una prima modifica al
2046 nostro server è pertanto quella di inserire la gestione della terminazione dei
2047 processi figli attraverso l'uso di un gestore.  Per questo useremo la funzione
2048 \code{Signal} (che abbiamo illustrato in fig.~\ref{fig:sig_Signal_code}), per
2049 installare il gestore che riceve i segnali dei processi figli terminati già
2050 visto in fig.~\ref{fig:sig_sigchld_handl}.  Basterà allora aggiungere il
2051 seguente codice: \includecodesnip{listati/sigchildhand.c}
2052 \noindent
2053 all'esempio illustrato in fig.~\ref{fig:TCP_echo_server_first_code}.
2054
2055 In questo modo però si introduce un altro problema. Si ricordi infatti che,
2056 come spiegato in sez.~\ref{sec:sig_gen_beha}, quando un programma si trova in
2057 stato di \texttt{sleep} durante l'esecuzione di una \textit{system call},
2058 questa viene interrotta alla ricezione di un segnale. Per questo motivo, alla
2059 fine dell'esecuzione del gestore del segnale, se questo ritorna, il programma
2060 riprenderà l'esecuzione ritornando dalla \textit{system call} interrotta con
2061 un errore di \errcode{EINTR}.
2062
2063 Vediamo allora cosa comporta tutto questo nel nostro caso: quando si chiude il
2064 client, il processo figlio che gestisce la connessione terminerà, ed il padre,
2065 per evitare la creazione di \textit{zombie}, riceverà il segnale
2066 \signal{SIGCHLD} eseguendo il relativo gestore. Al ritorno del gestore però
2067 l'esecuzione nel padre ripartirà subito con il ritorno della funzione
2068 \func{accept} (a meno di un caso fortuito in cui il segnale arriva durante
2069 l'esecuzione del programma in risposta ad una connessione) con un errore di
2070 \errcode{EINTR}. Non avendo previsto questa eventualità il programma considera
2071 questo un errore fatale terminando a sua volta con un messaggio del tipo:
2072 \begin{verbatim}
2073 [root@gont sources]# ./echod -i
2074 accept error: Interrupted system call
2075 \end{verbatim}%#
2076
2077 Come accennato in sez.~\ref{sec:sig_gen_beha} le conseguenze di questo
2078 comportamento delle \textit{system call} possono essere superate in due modi
2079 diversi, il più semplice è quello di modificare il codice di \func{Signal} per
2080 richiedere il riavvio automatico delle \textit{system call} interrotte secondo
2081 la semantica di BSD, usando l'opzione \const{SA\_RESTART} di \func{sigaction};
2082 rispetto a quanto visto in fig.~\ref{fig:sig_Signal_code}. Definiremo allora
2083 la nuova funzione \func{SignalRestart}\footnote{anche questa è definita,
2084   insieme alle altre funzioni riguardanti la gestione dei segnali, nel file
2085   \file{SigHand.c}, il cui contento completo può essere trovato negli esempi
2086   allegati.} come mostrato in fig.~\ref{fig:sig_SignalRestart_code}, ed
2087 installeremo il gestore usando quest'ultima.
2088
2089 \begin{figure}[!htbp]
2090   \footnotesize \centering
2091   \begin{minipage}[c]{\codesamplewidth}
2092     \includecodesample{listati/SignalRestart.c}
2093   \end{minipage}  
2094   \normalsize 
2095   \caption{La funzione \func{SignalRestart}, che installa un gestore di
2096     segnali in semantica BSD per il riavvio automatico delle \textit{system
2097       call} interrotte.}
2098   \label{fig:sig_SignalRestart_code}
2099 \end{figure}
2100
2101 Come si può notare questa funzione è identica alla precedente \func{Signal},
2102 illustrata in fig.~\ref{fig:sig_Signal_code}, solo che in questo caso invece
2103 di inizializzare a zero il campo \var{sa\_flags} di \struct{sigaction}, lo si
2104 inizializza (\texttt{\small 5}) al valore \const{SA\_RESTART}. Usando questa
2105 funzione al posto di \func{Signal} nel server non è necessaria nessuna altra
2106 modifica: le \textit{system call} interrotte saranno automaticamente
2107 riavviate, e l'errore \errcode{EINTR} non si manifesterà più.
2108
2109 La seconda soluzione è più invasiva e richiede di controllare tutte le volte
2110 l'errore restituito dalle varie \textit{system call}, ripetendo la chiamata
2111 qualora questo corrisponda ad \errcode{EINTR}. Questa soluzione ha però il
2112 pregio della portabilità, infatti lo standard POSIX dice che la funzionalità
2113 di riavvio automatico delle \textit{system call}, fornita da
2114 \const{SA\_RESTART}, è opzionale, per cui non è detto che essa sia disponibile
2115 su qualunque sistema.  Inoltre in certi casi,\footnote{Stevens in \cite{UNP1}
2116   accenna che la maggior parte degli Unix derivati da BSD non fanno ripartire
2117   \func{select}; altri non riavviano neanche \func{accept} e \func{recvfrom},
2118   cosa che invece nel caso di Linux viene sempre fatta.} anche quando questa è
2119 presente, non è detto possa essere usata con \func{accept}.
2120
2121
2122 La portabilità nella gestione dei segnali però viene al costo di una
2123 riscrittura parziale del server, la nuova versione di questo, in cui si sono
2124 introdotte una serie di nuove opzioni che ci saranno utili per il debug, è
2125 mostrata in fig.~\ref{fig:TCP_echo_server_code_second}, dove si sono riportate
2126 la sezioni di codice modificate nella seconda versione del programma, il
2127 codice completo di quest'ultimo si trova nel file
2128 \texttt{TCP\_echod\_second.c} dei sorgenti allegati alla guida.
2129
2130 La prima modifica effettuata è stata quella di introdurre una nuova opzione a
2131 riga di comando, \texttt{-c}, che permette di richiedere il comportamento
2132 compatibile nella gestione di \signal{SIGCHLD} al posto della semantica BSD
2133 impostando la variabile \var{compat} ad un valore non nullo. Questa è
2134 preimpostata al valore nullo, cosicché se non si usa questa opzione il
2135 comportamento di default del server è di usare la semantica BSD. 
2136
2137 Una seconda opzione aggiunta è quella di inserire un tempo di attesa fisso
2138 specificato in secondi fra il ritorno della funzione \func{listen} e la
2139 chiamata di \func{accept}, specificabile con l'opzione \texttt{-w}, che
2140 permette di impostare la variabile \var{waiting}.  Infine si è introdotta una
2141 opzione \texttt{-d} per abilitare il debugging che imposta ad un valore non
2142 nullo la variabile \var{debugging}. Al solito si è omessa da
2143 fig.~\ref{fig:TCP_echo_server_code_second} la sezione di codice relativa alla
2144 gestione di tutte queste opzioni, che può essere trovata nel sorgente del
2145 programma.
2146
2147 \begin{figure}[!htbp]
2148   \footnotesize \centering
2149   \begin{minipage}[c]{\codesamplewidth}
2150     \includecodesample{listati/TCP_echod_second.c}
2151   \end{minipage} 
2152   \normalsize
2153   \caption{La sezione nel codice della seconda versione del server
2154     per il servizio \textit{echo} modificata per tener conto dell'interruzione
2155     delle \textit{system call}.}
2156   \label{fig:TCP_echo_server_code_second}
2157 \end{figure}
2158
2159 Vediamo allora come è cambiato il nostro server; una volta definite le
2160 variabili e trattate le opzioni il primo passo (\texttt{\small 9--13}) è
2161 verificare la semantica scelta per la gestione di \signal{SIGCHLD}, a seconda
2162 del valore di \var{compat} (\texttt{\small 9}) si installa il gestore con la
2163 funzione \func{Signal} (\texttt{\small 10}) o con \texttt{SignalRestart}
2164 (\texttt{\small 12}), essendo quest'ultimo il valore di default.
2165
2166 Tutta la sezione seguente, che crea il socket, cede i privilegi di
2167 amministratore ed eventualmente lancia il programma come demone, è rimasta
2168 invariata e pertanto è stata omessa in
2169 fig.~\ref{fig:TCP_echo_server_code_second}; l'unica modifica effettuata prima
2170 dell'entrata nel ciclo principale è stata quella di aver introdotto, subito
2171 dopo la chiamata (\texttt{\small 17--20}) alla funzione \func{listen}, una
2172 eventuale pausa con una condizione (\texttt{\small 21}) sulla variabile
2173 \var{waiting}, che viene inizializzata, con l'opzione \texttt{-w Nsec}, al
2174 numero di secondi da aspettare (il valore preimpostato è nullo).
2175
2176 Si è potuto lasciare inalterata tutta la sezione di creazione del socket
2177 perché nel server l'unica chiamata ad una \textit{system call} lenta, che può
2178 essere interrotta dall'arrivo di \signal{SIGCHLD}, è quella ad \func{accept},
2179 che è l'unica funzione che può mettere il processo padre in stato di sleep nel
2180 periodo in cui un figlio può terminare; si noti infatti come le altre
2181 \textit{system call} lente (si ricordi la distinzione fatta in
2182 sez.~\ref{sec:sig_gen_beha}) o sono chiamate prima di entrare nel ciclo
2183 principale, quando ancora non esistono processi figli, o sono chiamate dai
2184 figli stessi e non risentono di \signal{SIGCHLD}.
2185
2186 Per questo l'unica modifica sostanziale nel ciclo principale (\texttt{\small
2187   23--42}), rispetto precedente versione di fig.~\ref{fig:TCP_ServEcho_first},
2188 è nella sezione (\texttt{\small 25--31}) in cui si effettua la chiamata di
2189 \func{accept}.  Quest'ultima viene effettuata (\texttt{\small 26--27})
2190 all'interno di un ciclo di \code{while}\footnote{la sintassi del C relativa a
2191   questo ciclo può non essere del tutto chiara. In questo caso infatti si è
2192   usato un ciclo vuoto che non esegue nessuna istruzione, in questo modo
2193   quello che viene ripetuto con il ciclo è soltanto il codice che esprime la
2194   condizione all'interno del \code{while}.}  che la ripete indefinitamente
2195 qualora in caso di errore il valore di \var{errno} sia \errcode{EINTR}. Negli
2196 altri casi si esce in caso di errore effettivo (\texttt{\small 27--29}),
2197 altrimenti il programma prosegue.
2198
2199 Si noti che in questa nuova versione si è aggiunta una ulteriore sezione
2200 (\texttt{\small 32--40}) di aiuto per il debug del programma, che eseguita con
2201 un controllo (\texttt{\small 33}) sul valore della variabile \var{debugging}
2202 impostato dall'opzione \texttt{-d}. Qualora questo sia nullo, come
2203 preimpostato, non accade nulla. altrimenti (\texttt{\small 33}) l'indirizzo
2204 ricevuto da \var{accept} viene convertito in una stringa che poi
2205 (\texttt{\small 34--39}) viene opportunamente stampata o sullo schermo o nei
2206 log.
2207
2208 Infine come ulteriore miglioria si è perfezionata la funzione \code{ServEcho},
2209 sia per tenere conto della nuova funzionalità di debugging, che per effettuare
2210 un controllo in caso di errore; il codice della nuova versione è mostrato in
2211 fig.~\ref{fig:TCP_ServEcho_second}.
2212
2213 \begin{figure}[!htbp] 
2214   \footnotesize \centering
2215   \begin{minipage}[c]{\codesamplewidth}
2216     \includecodesample{listati/ServEcho_second.c}
2217   \end{minipage} 
2218   \normalsize
2219   \caption{Codice della seconda versione della funzione \code{ServEcho} per la
2220     gestione del servizio \textit{echo}.}
2221   \label{fig:TCP_ServEcho_second}
2222 \end{figure}
2223
2224 Rispetto alla precedente versione di fig.~\ref{fig:TCP_ServEcho_first} in
2225 questo caso si è provveduto a controllare (\texttt{\small 7--10}) il valore di
2226 ritorno di \func{read} per rilevare un eventuale errore, in modo da stampare
2227 (\texttt{\small 8}) un messaggio di errore e ritornare (\texttt{\small 9})
2228 concludendo la connessione.
2229
2230 Inoltre qualora sia stata attivata la funzionalità di debug (avvalorando
2231 \var{debugging} tramite l'apposita opzione \texttt{-d}) si provvederà a
2232 stampare (tenendo conto della modalità di invocazione del server, se
2233 interattiva o in forma di demone) il numero di byte e la stringa letta dal
2234 client (\texttt{\small 16--24}).
2235
2236
2237 \section{I vari scenari critici}
2238 \label{sec:TCP_echo_critical}
2239
2240 Con le modifiche viste in sez.~\ref{sec:TCP_child_hand} il nostro esempio
2241 diventa in grado di affrontare la gestione ordinaria delle connessioni, ma un
2242 server di rete deve tenere conto che, al contrario di quanto avviene per i
2243 server che operano nei confronti di processi presenti sulla stessa macchina,
2244 la rete è di sua natura inaffidabile, per cui è necessario essere in grado di
2245 gestire tutta una serie di situazioni critiche che non esistono per i processi
2246 locali.
2247
2248
2249 \subsection{La terminazione precoce della connessione}
2250 \label{sec:TCP_conn_early_abort}
2251
2252 La prima situazione critica è quella della terminazione precoce, causata da un
2253 qualche errore sulla rete, della connessione effettuata da un client. Come
2254 accennato in sez.~\ref{sec:TCP_func_accept} la funzione \func{accept} riporta
2255 tutti gli eventuali errori di rete pendenti su una connessione sul
2256 \textit{connected socket}. Di norma questo non è un problema, in quanto non
2257 appena completata la connessione, \func{accept} ritorna e l'errore sarà
2258 rilevato in seguito, dal processo che gestisce la connessione, alla prima
2259 chiamata di una funzione che opera sul socket.
2260
2261 È però possibile, dal punto di vista teorico, incorrere anche in uno scenario
2262 del tipo di quello mostrato in fig.~\ref{fig:TCP_early_abort}, in cui la
2263 connessione viene abortita sul lato client per un qualche errore di rete con
2264 l'invio di un segmento RST, prima che nel server sia stata chiamata la
2265 funzione \func{accept}.
2266
2267 \begin{figure}[!htb]
2268   \centering \includegraphics[width=10cm]{img/tcp_client_early_abort}  
2269   \caption{Un possibile caso di terminazione precoce della connessione.}
2270   \label{fig:TCP_early_abort}
2271 \end{figure}
2272
2273 Benché questo non sia un fatto comune, un evento simile può essere osservato
2274 con dei server molto occupati. In tal caso, con una struttura del server
2275 simile a quella del nostro esempio, in cui la gestione delle singole
2276 connessioni è demandata a processi figli, può accadere che il \textit{three
2277   way handshake} venga completato e la relativa connessione abortita subito
2278 dopo, prima che il padre, per via del carico della macchina, abbia fatto in
2279 tempo ad eseguire la chiamata ad \func{accept}. Di nuovo si ha una situazione
2280 analoga a quella illustrata in fig.~\ref{fig:TCP_early_abort}, in cui la
2281 connessione viene stabilita, ma subito dopo si ha una condizione di errore che
2282 la chiude prima che essa sia stata accettata dal programma.
2283
2284 Questo significa che, oltre alla interruzione da parte di un segnale, che
2285 abbiamo trattato in sez.~\ref{sec:TCP_child_hand} nel caso particolare di
2286 \signal{SIGCHLD}, si possono ricevere altri errori non fatali all'uscita di
2287 \func{accept}, che come nel caso precedente, necessitano semplicemente la
2288 ripetizione della chiamata senza che si debba uscire dal programma. In questo
2289 caso anche la versione modificata del nostro server non sarebbe adatta, in
2290 quanto uno di questi errori causerebbe la terminazione dello stesso. In Linux
2291 i possibili errori di rete non fatali, riportati sul socket connesso al
2292 ritorno di \func{accept}, sono \errcode{ENETDOWN}, \errcode{EPROTO},
2293 \errcode{ENOPROTOOPT}, \errcode{EHOSTDOWN}, \errcode{ENONET},
2294 \errcode{EHOSTUNREACH}, \errcode{EOPNOTSUPP} e \errcode{ENETUNREACH}.
2295
2296 Si tenga presente che questo tipo di terminazione non è riproducibile
2297 terminando il client prima della chiamata ad \func{accept}, come si potrebbe
2298 fare usando l'opzione \texttt{-w} per introdurre una pausa dopo il lancio del
2299 demone, in modo da poter avere il tempo per lanciare e terminare una
2300 connessione usando il programma client. In tal caso infatti, alla terminazione
2301 del client, il socket associato alla connessione viene semplicemente chiuso,
2302 attraverso la sequenza vista in sez.~\ref{sec:TCP_conn_term}, per cui la
2303 \func{accept} ritornerà senza errori, e si avrà semplicemente un end-of-file
2304 al primo accesso al socket. Nel caso di Linux inoltre, anche qualora si
2305 modifichi il client per fargli gestire l'invio di un segmento di RST alla
2306 chiusura dal socket (usando l'opzione \const{SO\_LINGER}, vedi
2307 sez.~\ref{sec:sock_options_main}), non si ha nessun errore al ritorno di
2308 \func{accept}, quanto un errore di \errcode{ECONNRESET} al primo tentativo di
2309 accesso al socket.
2310
2311
2312
2313 \subsection{La terminazione precoce del server}
2314 \label{sec:TCP_server_crash}
2315
2316 Un secondo caso critico è quello in cui si ha una terminazione precoce del
2317 server, ad esempio perché il programma ha un crash. In tal caso si suppone che
2318 il processo termini per un errore fatale, cosa che potremo simulare
2319 inviandogli un segnale di terminazione. La conclusione del processo comporta
2320 la chiusura di tutti i file descriptor aperti, compresi tutti i socket
2321 relativi a connessioni stabilite; questo significa che al momento del crollo
2322 del servizio il client riceverà un FIN dal server in corrispondenza della
2323 chiusura del socket.
2324
2325 Vediamo allora cosa succede nel nostro caso, facciamo partire una connessione
2326 con il server e scriviamo una prima riga, poi terminiamo il server con un
2327 \texttt{C-c}. A questo punto scriviamo una seconda riga e poi un'altra riga
2328 ancora. Il risultato finale della sessione è il seguente:
2329 \begin{verbatim}
2330 [piccardi@gont sources]$ ./echo 192.168.1.141
2331 Prima riga
2332 Prima riga
2333 Seconda riga dopo il C-c
2334 Altra riga
2335 [piccardi@gont sources]$
2336 \end{verbatim}
2337
2338 Come si vede il nostro client, nonostante la connessione sia stata interrotta
2339 prima dell'invio della seconda riga, non solo accetta di inviarla, ma prende
2340 anche un'altra riga prima di terminare senza riportare nessun
2341 errore. 
2342
2343 Per capire meglio cosa è successo conviene analizzare il flusso dei pacchetti
2344 utilizzando un analizzatore di traffico come \cmd{tcpdump}. Il comando
2345 permette di selezionare, nel traffico di rete generato su una macchina, i
2346 pacchetti che interessano, stampando a video (o salvando su disco) il loro
2347 contenuto. Non staremo qui ad entrare nei dettagli dell'uso del programma, che
2348 sono spiegati dalla pagina di manuale; per l'uso che vogliamo farne quello che
2349 ci interessa è, posizionandosi sulla macchina che fa da client, selezionare
2350 tutti i pacchetti che sono diretti o provengono dalla macchina che fa da
2351 server. In questo modo (posto che non ci siano altre connessioni col server,
2352 cosa che avremo cura di evitare) tutti i pacchetti rilevati apparterranno alla
2353 nostra sessione di interrogazione del servizio. 
2354
2355 Il comando \cmd{tcpdump} permette selezioni molto complesse, basate sulle
2356 interfacce su cui passano i pacchetti, sugli indirizzi IP, sulle porte, sulle
2357 caratteristiche ed il contenuto dei pacchetti stessi, inoltre permette di
2358 combinare fra loro diversi criteri di selezione con degli operatori logici;
2359 quando un pacchetto che corrisponde ai criteri di selezione scelti viene
2360 rilevato i suoi dati vengono stampati sullo schermo (anche questi secondo un
2361 formato configurabile in maniera molto precisa).  
2362
2363 Lanciando il comando prima di ripetere la sessione di lavoro mostrata
2364 nell'esempio precedente potremo allora catturare tutti pacchetti scambiati fra
2365 il client ed il server; i risultati\footnote{in realtà si è ridotta la
2366   lunghezza dell'output rispetto al reale tagliando alcuni dati non necessari
2367   alla comprensione del flusso.} prodotti in questa occasione da \cmd{tcpdump}
2368 sono allora i seguenti:
2369 \begin{verbatim}
2370 [root@gont gapil]# tcpdump src 192.168.1.141 or dst 192.168.1.141 -N -t
2371 tcpdump: listening on eth0
2372 gont.34559 > anarres.echo: S 800922320:800922320(0) win 5840 
2373 anarres.echo > gont.34559: S 511689719:511689719(0) ack 800922321 win 5792 
2374 gont.34559 > anarres.echo: . ack 1 win 5840 
2375 gont.34559 > anarres.echo: P 1:12(11) ack 1 win 5840 
2376 anarres.echo > gont.34559: . ack 12 win 5792 
2377 anarres.echo > gont.34559: P 1:12(11) ack 12 win 5792 
2378 gont.34559 > anarres.echo: . ack 12 win 5840 
2379 anarres.echo > gont.34559: F 12:12(0) ack 12 win 5792 
2380 gont.34559 > anarres.echo: . ack 13 win 5840 
2381 gont.34559 > anarres.echo: P 12:37(25) ack 13 win 5840 
2382 anarres.echo > gont.34559: R 511689732:511689732(0) win 0 
2383 \end{verbatim}
2384
2385 Le prime tre righe vengono prodotte al momento in cui lanciamo il nostro
2386 client, e corrispondono ai tre pacchetti del \textit{three way handshake}.
2387 L'output del comando riporta anche i numeri di sequenza iniziali, mentre la
2388 lettera \texttt{S} indica che per quel pacchetto si aveva il SYN flag attivo.
2389 Si noti come a partire dal secondo pacchetto sia sempre attivo il campo
2390 \texttt{ack}, seguito dal numero di sequenza per il quale si da il ricevuto;
2391 quest'ultimo, a partire dal terzo pacchetto, viene espresso in forma relativa
2392 per maggiore compattezza.  Il campo \texttt{win} in ogni riga indica la
2393 \textit{advertised window} di cui parlavamo in sez.~\ref{sec:TCP_TCP_opt}.
2394 Allora si può verificare dall'output del comando come venga appunto realizzata
2395 la sequenza di pacchetti descritta in sez.~\ref{sec:TCP_conn_cre}: prima viene
2396 inviato dal client un primo pacchetto con il SYN che inizia la connessione, a
2397 cui il server risponde dando il ricevuto con un secondo pacchetto, che a sua
2398 volta porta un SYN, cui il client risponde con un il terzo pacchetto di
2399 ricevuto.
2400
2401 Ritorniamo allora alla nostra sessione con il servizio echo: dopo le tre righe
2402 del \textit{three way handshake} non avremo nulla fin tanto che non scriveremo
2403 una prima riga sul client; al momento in cui facciamo questo si genera una
2404 sequenza di altri quattro pacchetti. Il primo, dal client al server,
2405 contraddistinto da una lettera \texttt{P} che significa che il flag PSH è
2406 impostato, contiene la nostra riga (che è appunto di 11 caratteri), e ad esso
2407 il server risponde immediatamente con un pacchetto vuoto di ricevuto. Poi
2408 tocca al server riscrivere indietro quanto gli è stato inviato, per cui sarà
2409 lui a mandare indietro un terzo pacchetto con lo stesso contenuto appena
2410 ricevuto, e a sua volta riceverà dal client un ACK nel quarto pacchetto.
2411 Questo causerà la ricezione dell'eco nel client che lo stamperà a video.
2412
2413 A questo punto noi procediamo ad interrompere l'esecuzione del server con un
2414 \texttt{C-c} (cioè con l'invio di \signal{SIGTERM}): nel momento in cui
2415 facciamo questo vengono immediatamente generati altri due pacchetti. La
2416 terminazione del processo infatti comporta la chiusura di tutti i suoi file
2417 descriptor, il che comporta, per il socket che avevamo aperto, l'inizio della
2418 sequenza di chiusura illustrata in sez.~\ref{sec:TCP_conn_term}.  Questo
2419 significa che dal server partirà un FIN, che è appunto il primo dei due
2420 pacchetti, contraddistinto dalla lettera \texttt{F}, cui seguirà al solito un
2421 ACK da parte del client.  
2422
2423 A questo punto la connessione dalla parte del server è chiusa, ed infatti se
2424 usiamo \cmd{netstat} per controllarne lo stato otterremo che sul server si ha:
2425 \begin{verbatim}
2426 anarres:/home/piccardi# netstat -ant
2427 Active Internet connections (servers and established)
2428 Proto Recv-Q Send-Q Local Address           Foreign Address         State
2429 ...      ...    ... ...                     ...                     ...
2430 tcp        0      0 192.168.1.141:7         192.168.1.2:34626       FIN_WAIT2
2431 \end{verbatim}
2432 cioè essa è andata nello stato \texttt{FIN\_WAIT2}, che indica l'avvenuta
2433 emissione del segmento FIN, mentre sul client otterremo che essa è andata
2434 nello stato \texttt{CLOSE\_WAIT}:
2435 \begin{verbatim}
2436 [root@gont gapil]# netstat -ant
2437 Active Internet connections (servers and established)
2438 Proto Recv-Q Send-Q Local Address           Foreign Address         State
2439 ...      ...    ... ...                     ...                     ...
2440 tcp        1      0 192.168.1.2:34582       192.168.1.141:7         CLOSE_WAIT 
2441 \end{verbatim}
2442
2443 Il problema è che in questo momento il client è bloccato dentro la funzione
2444 \texttt{ClientEcho} nella chiamata a \func{fgets}, e sta attendendo dell'input
2445 dal terminale, per cui non è in grado di accorgersi di nulla. Solo quando
2446 inseriremo la seconda riga il comando uscirà da \func{fgets} e proverà a
2447 scriverla sul socket. Questo comporta la generazione degli ultimi due
2448 pacchetti riportati da \cmd{tcpdump}: il primo, inviato dal client contenente
2449 i 25 caratteri della riga appena letta, e ad esso la macchina server
2450 risponderà, non essendoci più niente in ascolto sulla porta 7, con un segmento
2451 di RST, contraddistinto dalla lettera \texttt{R}, che causa la conclusione
2452 definitiva della connessione anche nel client, dove non comparirà più
2453 nell'output di \cmd{netstat}.
2454
2455 Come abbiamo accennato in sez.~\ref{sec:TCP_conn_term} e come vedremo più
2456 avanti in sez.~\ref{sec:TCP_shutdown} la chiusura di un solo capo di un socket
2457 è una operazione lecita, per cui la nostra scrittura avrà comunque successo
2458 (come si può constatare lanciando usando \cmd{strace}\footnote{il comando
2459   \cmd{strace} è un comando di debug molto utile che prende come argomento un
2460   altro comando e ne stampa a video tutte le invocazioni di una \textit{system
2461     call}, coi relativi argomenti e valori di ritorno, per cui usandolo in
2462   questo contesto potremo verificare che effettivamente la \func{write} ha
2463   scritto la riga, che in effetti è stata pure trasmessa via rete.}), in
2464 quanto il nostro programma non ha a questo punto alcun modo di sapere che
2465 dall'altra parte non c'è più nessuno processo in grado di leggere quanto
2466 scriverà. Questo sarà chiaro solo dopo il tentativo di scrittura, e la
2467 ricezione del segmento RST di risposta che indica che dall'altra parte non si
2468 è semplicemente chiuso un capo del socket, ma è completamente terminato il
2469 programma.
2470
2471 Per questo motivo il nostro client proseguirà leggendo dal socket, e dato che
2472 questo è stato chiuso avremo che, come spiegato in
2473 sez.~\ref{sec:TCP_conn_term}, la funzione \func{read} ritorna normalmente con
2474 un valore nullo. Questo comporta che la seguente chiamata a \func{fputs} non
2475 ha effetto (viene stampata una stringa nulla) ed il client si blocca di nuovo
2476 nella successiva chiamata a \func{fgets}. Per questo diventa possibile
2477 inserire una terza riga e solo dopo averlo fatto si avrà la terminazione del
2478 programma.
2479
2480 Per capire come questa avvenga comunque, non avendo inserito nel codice nessun
2481 controllo di errore, occorre ricordare che, a parte la bidirezionalità del
2482 flusso dei dati, dal punto di vista del funzionamento nei confronti delle
2483 funzioni di lettura e scrittura, i socket sono del tutto analoghi a delle
2484 \textit{pipe}. Allora, da quanto illustrato in sez.~\ref{sec:ipc_pipes},
2485 sappiamo che tutte le volte che si cerca di scrivere su una \textit{pipe} il
2486 cui altro capo non è aperto il lettura il processo riceve un segnale di
2487 \signal{SIGPIPE}, e questo è esattamente quello che avviene in questo caso, e
2488 siccome non abbiamo un gestore per questo segnale, viene eseguita l'azione
2489 preimpostata, che è quella di terminare il processo.
2490
2491 Per gestire in maniera più corretta questo tipo di evento dovremo allora
2492 modificare il nostro client perché sia in grado di trattare le varie tipologie
2493 di errore, per questo dovremo riscrivere la funzione \func{ClientEcho}, in
2494 modo da controllare gli stati di uscita delle varie chiamate. Si è riportata
2495 la nuova versione della funzione in fig.~\ref{fig:TCP_ClientEcho_second}.
2496
2497 \begin{figure}[!htbp]
2498   \footnotesize \centering
2499   \begin{minipage}[c]{\codesamplewidth}
2500     \includecodesample{listati/ClientEcho_second.c}
2501   \end{minipage} 
2502   \normalsize
2503   \caption{La sezione nel codice della seconda versione della funzione
2504     \func{ClientEcho} usata dal client per il servizio \textit{echo}
2505     modificata per tener conto degli eventuali errori.}
2506   \label{fig:TCP_ClientEcho_second}
2507 \end{figure}
2508
2509 Come si può vedere in questo caso si controlla il valore di ritorno di tutte
2510 le funzioni, ed inoltre si verifica la presenza di un eventuale end of file in
2511 caso di lettura. Con questa modifica il nostro client echo diventa in grado di
2512 accorgersi della chiusura del socket da parte del server, per cui ripetendo la
2513 sequenza di operazioni precedenti stavolta otterremo che:
2514 \begin{verbatim}
2515 [piccardi@gont sources]$ ./echo 192.168.1.141
2516 Prima riga
2517 Prima riga
2518 Seconda riga dopo il C-c
2519 EOF sul socket
2520 \end{verbatim}%$
2521 ma di nuovo si tenga presente che non c'è modo di accorgersi della chiusura
2522 del socket fin quando non si esegue la scrittura della seconda riga; il
2523 protocollo infatti prevede che ci debba essere una scrittura prima di ricevere
2524 un RST che confermi la chiusura del file, e solo alle successive scritture si
2525 potrà ottenere un errore.
2526
2527 Questa caratteristica dei socket ci mette di fronte ad un altro problema
2528 relativo al nostro client, e che cioè esso non è in grado di accorgersi di
2529 nulla fintanto che è bloccato nella lettura del terminale fatta con
2530 \func{gets}. In questo caso il problema è minimo, ma esso riemergerà più
2531 avanti, ed è quello che si deve affrontare tutte le volte quando si ha a che
2532 fare con la necessità di lavorare con più descrittori, nel qual caso diventa
2533 si pone la questione di come fare a non restare bloccati su un socket quando
2534 altri potrebbero essere liberi. Vedremo come affrontare questa problematica in
2535 sez.~\ref{sec:TCP_sock_multiplexing}.
2536  
2537
2538 \subsection{Altri scenari di terminazione della connessione}
2539 \label{sec:TCP_conn_crash}
2540
2541 La terminazione del server è solo uno dei possibili scenari di terminazione
2542 della connessione, un altro caso è ad esempio quello in cui si ha un crollo
2543 della rete, cosa che potremo simulare facilmente staccando il cavo di rete.
2544 Un'altra condizione è quella di un blocco della macchina completo della su cui
2545 gira il server che deve essere riavviata, cosa che potremo simulare sia
2546 premendo il bottone di reset,\footnote{un normale shutdown non va bene; in tal
2547   caso infatti il sistema provvede a terminare tutti i processi, per cui la
2548   situazione sarebbe sostanzialmente identica alla precedente.} che, in
2549 maniera più gentile, riavviando la macchina dopo aver interrotto la
2550 connessione di rete.
2551
2552 Cominciamo ad analizzare il primo caso, il crollo della rete. Ripetiamo la
2553 nostra sessione di lavoro precedente, lanciamo il client, scriviamo una prima
2554 riga, poi stacchiamo il cavo e scriviamo una seconda riga. Il risultato che
2555 otterremo è:
2556 \begin{verbatim}
2557 [piccardi@gont sources]$ ./echo 192.168.1.141
2558 Prima riga
2559 Prima riga
2560 Seconda riga dopo l'interruzione
2561 Errore in lettura: No route to host
2562 \end{verbatim}%$
2563
2564 Quello che succede in questo è che il programma, dopo aver scritto la seconda
2565 riga, resta bloccato per un tempo molto lungo, prima di dare l'errore
2566 \errcode{EHOSTUNREACH}.  Se andiamo ad osservare con \cmd{strace} cosa accade
2567 nel periodo in cui il programma è bloccato vedremo che stavolta, a differenza
2568 del caso precedente, il programma è bloccato nella lettura dal socket.
2569
2570 Se poi, come nel caso precedente, usiamo l'accortezza di analizzare il
2571 traffico di rete fra client e server con \cmd{tcpdump}, otterremo il seguente
2572 risultato:
2573 \begin{verbatim}
2574 [root@gont sources]# tcpdump src 192.168.1.141 or dst 192.168.1.141 -N -t
2575 tcpdump: listening on eth0
2576 gont.34685 > anarres.echo: S 1943495663:1943495663(0) win 5840
2577 anarres.echo > gont.34685: S 1215783131:1215783131(0) ack 1943495664 win 5792 
2578 gont.34685 > anarres.echo: . ack 1 win 5840
2579 gont.34685 > anarres.echo: P 1:12(11) ack 1 win 5840 
2580 anarres.echo > gont.34685: . ack 12 win 5792 
2581 anarres.echo > gont.34685: P 1:12(11) ack 12 win 5792 
2582 gont.34685 > anarres.echo: . ack 12 win 5840 
2583 gont.34685 > anarres.echo: P 12:45(33) ack 12 win 5840 
2584 gont.34685 > anarres.echo: P 12:45(33) ack 12 win 5840 
2585 gont.34685 > anarres.echo: P 12:45(33) ack 12 win 5840 
2586 gont.34685 > anarres.echo: P 12:45(33) ack 12 win 5840 
2587 gont.34685 > anarres.echo: P 12:45(33) ack 12 win 5840 
2588 gont.34685 > anarres.echo: P 12:45(33) ack 12 win 5840 
2589 gont.34685 > anarres.echo: P 12:45(33) ack 12 win 5840 
2590 gont.34685 > anarres.echo: P 12:45(33) ack 12 win 5840 
2591 gont.34685 > anarres.echo: P 12:45(33) ack 12 win 5840 
2592 arp who-has anarres tell gont
2593 arp who-has anarres tell gont
2594 arp who-has anarres tell gont
2595 arp who-has anarres tell gont
2596 arp who-has anarres tell gont
2597 arp who-has anarres tell gont
2598 ...
2599 \end{verbatim}
2600
2601 In questo caso l'andamento dei primi sette pacchetti è esattamente lo stesso
2602 di prima. Solo che stavolta, non appena inviata la seconda riga, il programma
2603 si bloccherà nella successiva chiamata a \func{read}, non ottenendo nessuna
2604 risposta. Quello che succede è che nel frattempo il kernel provvede, come
2605 richiesto dal protocollo TCP, a tentare la ritrasmissione della nostra riga un
2606 certo numero di volte, con tempi di attesa crescente fra un tentativo ed il
2607 successivo, per tentare di ristabilire la connessione.
2608
2609 Il risultato finale qui dipende dall'implementazione dello stack TCP, e nel
2610 caso di Linux anche dall'impostazione di alcuni dei parametri di sistema che
2611 si trovano in \file{/proc/sys/net/ipv4}, che ne controllano il comportamento:
2612 in questo caso in particolare da \sysctlrelfile{net/ipv4}{tcp\_retries2} (vedi
2613 sez.~\ref{sec:sock_ipv4_sysctl}). Questo parametro infatti specifica il numero
2614 di volte che deve essere ritentata la ritrasmissione di un pacchetto nel mezzo
2615 di una connessione prima di riportare un errore di timeout.  Il valore
2616 preimpostato è pari a 15, il che comporterebbe 15 tentativi di ritrasmissione,
2617 ma nel nostro caso le cose sono andate diversamente, dato che le
2618 ritrasmissioni registrate da \cmd{tcpdump} sono solo 8; inoltre l'errore
2619 riportato all'uscita del client non è stato \errcode{ETIMEDOUT}, come dovrebbe
2620 essere in questo caso, ma \errcode{EHOSTUNREACH}.
2621
2622 Per capire l'accaduto continuiamo ad analizzare l'output di \cmd{tcpdump}:
2623 esso ci mostra che a un certo punto i tentativi di ritrasmissione del
2624 pacchetto sono cessati, per essere sostituiti da una serie di richieste di
2625 protocollo ARP in cui il client richiede l'indirizzo del server.
2626
2627 Come abbiamo accennato in sez.~\ref{sec:net_tcpip_general} ARP è il protocollo
2628 che si incarica di trovare le corrispondenze fra indirizzo IP e indirizzo
2629 hardware sulla scheda di rete. È evidente allora che nel nostro caso, essendo
2630 client e server sulla stessa rete, è scaduta la voce nella \textit{ARP
2631   cache}\footnote{la \textit{ARP cache} è una tabella mantenuta internamente
2632   dal kernel che contiene tutte le corrispondenze fra indirizzi IP e indirizzi
2633   fisici, ottenute appunto attraverso il protocollo ARP; le voci della tabella
2634   hanno un tempo di vita limitato, passato il quale scadono e devono essere
2635   nuovamente richieste.} relativa ad \texttt{anarres}, ed il nostro client ha
2636 iniziato ad effettuare richieste ARP sulla rete per sapere l'IP di
2637 quest'ultimo, che essendo scollegato non poteva rispondere. Anche per questo
2638 tipo di richieste esiste un timeout, per cui dopo un certo numero di tentativi
2639 il meccanismo si è interrotto, e l'errore riportato al programma a questo
2640 punto è stato \errcode{EHOSTUNREACH}, in quanto non si era più in grado di
2641 contattare il server.
2642
2643 Un altro errore possibile in questo tipo di situazione, che si può avere
2644 quando la macchina è su una rete remota, è \errcode{ENETUNREACH}; esso viene
2645 riportato alla ricezione di un pacchetto ICMP di \textit{destination
2646   unreachable} da parte del router che individua l'interruzione della
2647 connessione. Di nuovo anche qui il risultato finale dipende da quale è il
2648 meccanismo più veloce ad accorgersi del problema.
2649
2650 Se però agiamo sui parametri del kernel, e scriviamo in \file{tcp\_retries2}
2651 un valore di tentativi più basso, possiamo evitare la scadenza della
2652 \textit{ARP cache} e vedere cosa succede. Così se ad esempio richiediamo 4
2653 tentativi di ritrasmissione, l'analisi di \cmd{tcpdump} ci riporterà il
2654 seguente scambio di pacchetti:
2655 \begin{verbatim}
2656 [root@gont gapil]# tcpdump src 192.168.1.141 or dst 192.168.1.141 -N -t
2657 tcpdump: listening on eth0
2658 gont.34752 > anarres.echo: S 3646972152:3646972152(0) win 5840
2659 anarres.echo > gont.34752: S 2735190336:2735190336(0) ack 3646972153 win 5792 
2660 gont.34752 > anarres.echo: . ack 1 win 5840 
2661 gont.34752 > anarres.echo: P 1:12(11) ack 1 win 5840
2662 anarres.echo > gont.34752: . ack 12 win 5792 
2663 anarres.echo > gont.34752: P 1:12(11) ack 12 win 5792 
2664 gont.34752 > anarres.echo: . ack 12 win 5840 
2665 gont.34752 > anarres.echo: P 12:45(33) ack 12 win 5840 
2666 gont.34752 > anarres.echo: P 12:45(33) ack 12 win 5840 
2667 gont.34752 > anarres.echo: P 12:45(33) ack 12 win 5840 
2668 gont.34752 > anarres.echo: P 12:45(33) ack 12 win 5840 
2669 gont.34752 > anarres.echo: P 12:45(33) ack 12 win 5840 
2670 \end{verbatim}
2671 e come si vede in questo caso i tentativi di ritrasmissione del pacchetto
2672 iniziale sono proprio 4 (per un totale di 5 voci con quello trasmesso la prima
2673 volta), ed in effetti, dopo un tempo molto più breve rispetto a prima ed in
2674 corrispondenza dell'invio dell'ultimo tentativo, quello che otterremo come
2675 errore all'uscita del client sarà diverso, e cioè:
2676 \begin{verbatim}
2677 [piccardi@gont sources]$ ./echo 192.168.1.141
2678 Prima riga
2679 Prima riga
2680 Seconda riga dopo l'interruzione
2681 Errore in lettura: Connection timed out
2682 \end{verbatim}%$
2683 che corrisponde appunto, come ci aspettavamo, alla ricezione di un
2684 \errcode{ETIMEDOUT}.
2685
2686 Analizziamo ora il secondo scenario, in cui si ha un crollo della macchina che
2687 fa da server. Al solito lanciamo il nostro client, scriviamo una prima riga
2688 per verificare che sia tutto a posto, poi stacchiamo il cavo e riavviamo il
2689 server. A questo punto, ritornato attivo il server, scriviamo una seconda
2690 riga. Quello che otterremo in questo caso è:
2691 \begin{verbatim}
2692 [piccardi@gont sources]$ ./echo 192.168.1.141
2693 Prima riga
2694 Prima riga
2695 Seconda riga dopo l'interruzione
2696 Errore in lettura Connection reset by peer
2697 \end{verbatim}%$
2698 e l'errore ricevuti da \func{read} stavolta è \errcode{ECONNRESET}. Se al
2699 solito riportiamo l'analisi dei pacchetti effettuata con \cmd{tcpdump},
2700 avremo:
2701 \begin{verbatim}
2702 [root@gont gapil]# tcpdump src 192.168.1.141 or dst 192.168.1.141 -N -t
2703 tcpdump: listening on eth0
2704 gont.34756 > anarres.echo: S 904864257:904864257(0) win 5840 
2705 anarres.echo > gont.34756: S 4254564871:4254564871(0) ack 904864258 win 5792
2706 gont.34756 > anarres.echo: . ack 1 win 5840 
2707 gont.34756 > anarres.echo: P 1:12(11) ack 1 win 5840
2708 anarres.echo > gont.34756: . ack 12 win 5792 
2709 anarres.echo > gont.34756: P 1:12(11) ack 12 win 5792
2710 gont.34756 > anarres.echo: . ack 12 win 5840 
2711 gont.34756 > anarres.echo: P 12:45(33) ack 12 win 5840
2712 anarres.echo > gont.34756: R 4254564883:4254564883(0) win 0 
2713 \end{verbatim}
2714
2715 Ancora una volta i primi sette pacchetti sono gli stessi; ma in questo caso
2716 quello che succede dopo lo scambio iniziale è che, non avendo inviato nulla
2717 durante il periodo in cui si è riavviato il server, il client è del tutto
2718 ignaro dell'accaduto per cui quando effettuerà una scrittura, dato che la
2719 macchina server è stata riavviata e che tutti gli stati relativi alle
2720 precedenti connessioni sono completamente persi, anche in presenza di una
2721 nuova istanza del server echo non sarà possibile consegnare i dati in arrivo,
2722 per cui alla loro ricezione il kernel risponderà con un segmento di RST.
2723
2724 Il client da parte sua, dato che neanche in questo caso non è stato emesso un
2725 FIN, dopo aver scritto verrà bloccato nella successiva chiamata a \func{read},
2726 che però adesso ritornerà immediatamente alla ricezione del segmento RST,
2727 riportando appunto come errore \errcode{ECONNRESET}. Occorre precisare che se
2728 si vuole che il client sia in grado di accorgersi del crollo del server anche
2729 quando non sta effettuando uno scambio di dati, è possibile usare una
2730 impostazione speciale del socket (ci torneremo in
2731 sez.~\ref{sec:sock_generic_options}) che provvede all'esecuzione di questo
2732 controllo.
2733
2734
2735 \section{L'uso dell'I/O multiplexing}
2736 \label{sec:TCP_sock_multiplexing}
2737
2738 Affronteremo in questa sezione l'utilizzo dell'I/O multiplexing, affrontato in
2739 sez.~\ref{sec:file_multiplexing}, nell'ambito delle applicazioni di rete. Già
2740 in sez.~\ref{sec:TCP_server_crash} era emerso il problema relativo al client
2741 del servizio echo che non era in grado di accorgersi della terminazione
2742 precoce del server, essendo bloccato nella lettura dei dati immessi da
2743 tastiera.
2744
2745 Abbiamo visto in sez.~\ref{sec:file_multiplexing} quali sono le funzionalità
2746 del sistema che ci permettono di tenere sotto controllo più file descriptor in
2747 contemporanea; in quella occasione non abbiamo fatto esempi, in quanto quando
2748 si tratta con file normali questa tipologia di I/O normalmente non viene
2749 usata, è invece un caso tipico delle applicazioni di rete quello di dover
2750 gestire varie connessioni da cui possono arrivare dati comuni in maniera
2751 asincrona, per cui riprenderemo l'argomento in questa sezione.
2752
2753
2754 \subsection{Il comportamento della funzione \func{select} con i socket.}
2755 \label{sec:TCP_sock_select}
2756
2757 Iniziamo con la prima delle funzioni usate per l'I/O multiplexing,
2758 \func{select}; il suo funzionamento è già stato descritto in dettaglio in
2759 sez.~\ref{sec:file_multiplexing} e non staremo a ripetere quanto detto lì; 
2760 sappiamo che la funzione ritorna quando uno o più dei file descriptor messi
2761 sotto controllo è pronto per la relativa operazione.
2762
2763 In quell'occasione non abbiamo però definito cosa si intende per pronto,
2764 infatti per dei normali file, o anche per delle \textit{pipe}, la condizione
2765 di essere pronti per la lettura o la scrittura è ovvia; invece lo è molto meno
2766 nel caso dei socket, visto che possono intervenire tutte una serie di
2767 possibili condizioni di errore dovute alla rete. Occorre allora specificare
2768 chiaramente quali sono le condizioni per cui un socket risulta essere
2769 ``\textsl{pronto}'' quando viene passato come membro di uno dei tre
2770 \textit{file descriptor set} usati da \func{select}.
2771
2772 Le condizioni che fanno si che la funzione \func{select} ritorni segnalando
2773 che un socket (che sarà riportato nel primo insieme di file descriptor) è
2774 pronto per la lettura sono le seguenti:
2775 \begin{itemize*}
2776 \item nel buffer di ricezione del socket sono arrivati dei dati in quantità
2777   sufficiente a superare il valore di una \textsl{soglia di basso livello} (il
2778   cosiddetto \textit{low watermark}). Questo valore è espresso in numero di
2779   byte e può essere impostato con l'opzione del socket \const{SO\_RCVLOWAT}
2780   (tratteremo l'uso di questa opzione in sez.~\ref{sec:sock_generic_options});
2781   il suo valore di default è 1 per i socket TCP e UDP. In questo caso una
2782   operazione di lettura avrà successo e leggerà un numero di byte maggiore di
2783   zero.
2784 \item il lato in lettura della connessione è stato chiuso; si è cioè ricevuto
2785   un segmento FIN (si ricordi quanto illustrato in
2786   sez.~\ref{sec:TCP_conn_term}) sulla connessione. In questo caso una
2787   operazione di lettura avrà successo, ma non risulteranno presenti dati (in
2788   sostanza \func{read} ritornerà con un valore nullo) per indicare la
2789   condizione di end-of-file.
2790 \item c'è stato un errore sul socket. In questo caso una operazione di lettura
2791   non si bloccherà ma restituirà una condizione di errore (ad esempio
2792   \func{read} restituirà -1) e imposterà la variabile \var{errno} al relativo
2793   valore. Vedremo in sez.~\ref{sec:sock_generic_options} come sia possibile
2794   estrarre e cancellare gli errori pendenti su un socket senza usare
2795   \func{read} usando l'opzione \const{SO\_ERROR}.
2796 \item quando si sta utilizzando un \textit{listening socket} ed ci sono delle
2797   connessioni completate. In questo caso la funzione \func{accept} non si
2798   bloccherà.\footnote{in realtà questo non è sempre vero, come accennato in
2799     sez.~\ref{sec:TCP_conn_early_abort} una connessione può essere abortita
2800     dalla ricezione di un segmento RST una volta che è stata completata,
2801     allora se questo avviene dopo che \func{select} è ritornata, ma prima
2802     della chiamata ad \func{accept}, quest'ultima, in assenza di altre
2803     connessioni, potrà bloccarsi.}
2804 \end{itemize*}
2805
2806 Le condizioni che fanno si che la funzione \func{select} ritorni segnalando
2807 che un socket (che sarà riportato nel secondo insieme di file descriptor) è
2808 pronto per la scrittura sono le seguenti:
2809 \begin{itemize*}
2810 \item nel buffer di invio è disponibile una quantità di spazio superiore al
2811   valore della \textsl{soglia di basso livello} in scrittura ed inoltre o il
2812   socket è già connesso o non necessita (ad esempio è UDP) di connessione.  Il
2813   valore della soglia è espresso in numero di byte e può essere impostato con
2814   l'opzione del socket \const{SO\_SNDLOWAT} (trattata in
2815   sez.~\ref{sec:sock_generic_options}); il suo valore di default è 2048 per i
2816   socket TCP e UDP. In questo caso una operazione di scrittura non si
2817   bloccherà e restituirà un valore positivo pari al numero di byte accettati
2818   dal livello di trasporto.
2819 \item il lato in scrittura della connessione è stato chiuso. In questo caso
2820   una operazione di scrittura sul socket genererà il segnale \signal{SIGPIPE}.
2821 \item c'è stato un errore sul socket. In questo caso una operazione di
2822   scrittura non si bloccherà ma restituirà una condizione di errore ed
2823   imposterà opportunamente la variabile \var{errno}. Vedremo in
2824   sez.~\ref{sec:sock_generic_options} come sia possibile estrarre e cancellare
2825   errori pendenti su un socket usando l'opzione \const{SO\_ERROR}.
2826 \end{itemize*}
2827
2828 Infine c'è una sola condizione che fa si che \func{select} ritorni segnalando
2829 che un socket (che sarà riportato nel terzo insieme di file descriptor) ha una
2830 condizione di eccezione pendente, e cioè la ricezione sul socket di
2831 \textsl{dati urgenti} (o \textit{out-of-band}), una caratteristica specifica
2832 dei socket TCP su cui torneremo in sez.~\ref{sec:TCP_urgent_data}.
2833
2834 Si noti come nel caso della lettura \func{select} si applichi anche ad
2835 operazioni che non hanno nulla a che fare con l'I/O di dati come il
2836 riconoscimento della presenza di connessioni pronte, in modo da consentire
2837 anche l'utilizzo di \func{accept} in modalità non bloccante. Si noti infine
2838 come in caso di errore un socket venga sempre riportato come pronto sia per la
2839 lettura che per la scrittura.
2840
2841 Lo scopo dei due valori di soglia per i buffer di ricezione e di invio è
2842 quello di consentire maggiore flessibilità nell'uso di \func{select} da parte
2843 dei programmi, se infatti si sa che una applicazione non è in grado di fare
2844 niente fintanto che non può ricevere o inviare una certa quantità di dati, si
2845 possono utilizzare questi valori per far si che \func{select} ritorni solo
2846 quando c'è la certezza di avere dati a sufficienza.\footnote{questo tipo di
2847   controllo è utile di norma solo per la lettura, in quanto in genere le
2848   operazioni di scrittura sono già controllate dall'applicazione, che sa
2849   sempre quanti dati invia, mentre non è detto possa conoscere la quantità di
2850   dati in ricezione; per cui, nella situazione in cui si conosce almeno un
2851   valore minimo, per evitare la penalizzazione dovuta alla ripetizione delle
2852   operazioni di lettura per accumulare dati sufficienti, si può lasciare al
2853   kernel il compito di impostare un minimo al di sotto del quale il socket,
2854   pur avendo disponibili dei dati, non viene dato per pronto in lettura.}
2855
2856
2857
2858 \subsection{Un esempio di I/O multiplexing}
2859 \label{sec:TCP_multiplex_example}
2860
2861 Abbiamo incontrato la problematica tipica che conduce all'uso dell'I/O
2862 multiplexing nella nostra analisi degli errori in
2863 sez.~\ref{sec:TCP_conn_early_abort}, quando il nostro client non era in grado
2864 di rendersi conto di errori sulla connessione essendo impegnato nella attesa
2865 di dati in ingresso dallo standard input.
2866
2867 In questo caso il problema è quello di dover tenere sotto controllo due
2868 diversi file descriptor, lo standard input, da cui viene letto il testo che
2869 vogliamo inviare al server, e il socket connesso con il server su cui detto
2870 testo sarà scritto e dal quale poi si vorrà ricevere la risposta. L'uso
2871 dell'I/O multiplexing consente di tenere sotto controllo entrambi, senza
2872 restare bloccati.
2873
2874 Nel nostro caso quello che ci interessa è non essere bloccati in lettura sullo
2875 standard input in caso di errori sulla connessione o chiusura della stessa da
2876 parte del server. Entrambi questi casi possono essere rilevati usando
2877 \func{select}, per quanto detto in sez.~\ref{sec:TCP_sock_select}, mettendo
2878 sotto osservazione i file descriptor per la condizione di essere pronti in
2879 lettura: sia infatti che si ricevano dati, che la connessione sia chiusa
2880 regolarmente (con la ricezione di un segmento FIN) che si riceva una
2881 condizione di errore (con un segmento RST) il socket connesso sarà pronto in
2882 lettura (nell'ultimo caso anche in scrittura, ma questo non è necessario ai
2883 nostri scopi).
2884
2885 \begin{figure}[!htbp]
2886   \footnotesize \centering
2887   \begin{minipage}[c]{\codesamplewidth}
2888     \includecodesample{listati/ClientEcho_third.c}
2889   \end{minipage} 
2890   \normalsize
2891   \caption{La sezione nel codice della terza versione della funzione
2892     \func{ClientEcho} usata dal client per il servizio \textit{echo}
2893     modificata per l'uso di \func{select}.}
2894   \label{fig:TCP_ClientEcho_third}
2895 \end{figure}
2896
2897 Riprendiamo allora il codice del client, modificandolo per l'uso di
2898 \func{select}. Quello che dobbiamo modificare è la funzione \func{ClientEcho}
2899 di fig.~\ref{fig:TCP_ClientEcho_second}, dato che tutto il resto, che riguarda
2900 le modalità in cui viene stabilita la connessione con il server, resta
2901 assolutamente identico. La nostra nuova versione di \func{ClientEcho}, la
2902 terza della serie, è riportata in fig.~\ref{fig:TCP_ClientEcho_third}, il
2903 codice completo si trova nel file \file{TCP\_echo\_third.c} dei sorgenti
2904 allegati alla guida.
2905
2906 In questo caso la funzione comincia (\texttt{\small 8--9}) con l'azzeramento
2907 del \textit{file descriptor set} \var{fset} e l'impostazione del valore
2908 \var{maxfd}, da passare a \func{select} come massimo per il numero di file
2909 descriptor. Per determinare quest'ultimo si usa la macro \code{max} definita
2910 nel nostro file \file{macro.h} che raccoglie una collezione di macro di
2911 preprocessore di varia utilità.
2912
2913 La funzione prosegue poi (\texttt{\small 10--41}) con il ciclo principale, che
2914 viene ripetuto indefinitamente. Per ogni ciclo si reinizializza
2915 (\texttt{\small 11--12}) il \textit{file descriptor set}, impostando i valori
2916 per il file descriptor associato al socket \var{socket} e per lo standard
2917 input (il cui valore si recupera con la funzione \func{fileno}). Questo è
2918 necessario in quanto la successiva (\texttt{\small 13}) chiamata a
2919 \func{select} comporta una modifica dei due bit relativi, che quindi devono
2920 essere reimpostati all'inizio di ogni ciclo.
2921
2922 Si noti come la chiamata a \func{select} venga eseguita usando come primo
2923 argomento il valore di \var{maxfd}, precedentemente calcolato, e passando poi
2924 il solo \textit{file descriptor set} per il controllo dell'attività in
2925 lettura, negli altri argomenti sono passati tutti puntatori nulli, non
2926 interessando né il controllo delle altre attività, né l'impostazione di un
2927 valore di timeout.
2928
2929 Al ritorno di \func{select} si provvede a controllare quale dei due file
2930 descriptor presenta attività in lettura, cominciando (\texttt{\small 14--24})
2931 con il file descriptor associato allo standard input. In caso di attività
2932 (quando cioè \macro{FD\_ISSET} ritorna una valore diverso da zero) si esegue
2933 (\texttt{\small 15}) una \func{fgets} per leggere gli eventuali dati presenti;
2934 se non ve ne sono (e la funzione restituisce pertanto un puntatore nullo) si
2935 ritorna immediatamente (\texttt{\small 16}) dato che questo significa che si è
2936 chiuso lo standard input e quindi concluso l'utilizzo del client; altrimenti
2937 (\texttt{\small 18--22}) si scrivono i dati appena letti sul socket,
2938 prevedendo una uscita immediata in caso di errore di scrittura.
2939
2940 Controllato lo standard input si passa a controllare (\texttt{\small 25--40})
2941 il socket connesso, in caso di attività (\texttt{\small 26}) si esegue subito
2942 una \func{read} di cui si controlla il valore di ritorno; se questo è negativo
2943 (\texttt{\small 27--30}) si è avuto un errore e pertanto si esce
2944 immediatamente segnalandolo, se è nullo (\texttt{\small 31--34}) significa che
2945 il server ha chiuso la connessione, e di nuovo si esce con stampando prima un
2946 messaggio di avviso, altrimenti (\texttt{\small 35--39}) si effettua la
2947 terminazione della stringa e la si stampa a sullo standard output (uscendo in
2948 caso di errore), per ripetere il ciclo da capo.
2949
2950 Con questo meccanismo il programma invece di essere bloccato in lettura sullo
2951 standard input resta bloccato sulla \func{select}, che ritorna soltanto quando
2952 viene rilevata attività su uno dei due file descriptor posti sotto controllo.
2953 Questo di norma avviene solo quando si è scritto qualcosa sullo standard
2954 input, o quando si riceve dal socket la risposta a quanto si era appena
2955 scritto. Ma adesso il client diventa capace di accorgersi immediatamente della
2956 terminazione del server; in tal caso infatti il server chiuderà il socket
2957 connesso, ed alla ricezione del FIN la funzione \func{select} ritornerà (come
2958 illustrato in sez.~\ref{sec:TCP_sock_select}) segnalando una condizione di end
2959 of file, per cui il nostro client potrà uscire immediatamente.
2960
2961 Riprendiamo la situazione affrontata in sez.~\ref{sec:TCP_server_crash},
2962 terminando il server durante una connessione, in questo caso quello che
2963 otterremo, una volta scritta una prima riga ed interrotto il server con un
2964 \texttt{C-c}, sarà:
2965 \begin{verbatim}
2966 [piccardi@gont sources]$ ./echo 192.168.1.1
2967 Prima riga
2968 Prima riga
2969 EOF sul socket
2970 \end{verbatim}%$
2971 dove l'ultima riga compare immediatamente dopo aver interrotto il server. Il
2972 nostro client infatti è in grado di accorgersi immediatamente che il socket
2973 connesso è stato chiuso ed uscire immediatamente.
2974
2975 Veniamo allora agli altri scenari di terminazione anomala visti in
2976 sez.~\ref{sec:TCP_conn_crash}. Il primo di questi è l'interruzione fisica della
2977 connessione; in questo caso avremo un comportamento analogo al precedente, in
2978 cui si scrive una riga e non si riceve risposta dal server e non succede
2979 niente fino a quando non si riceve un errore di \errcode{EHOSTUNREACH} o
2980 \errcode{ETIMEDOUT} a seconda dei casi.
2981
2982 La differenza è che stavolta potremo scrivere più righe dopo l'interruzione,
2983 in quanto il nostro client dopo aver inviato i dati non si bloccherà più nella
2984 lettura dal socket, ma nella \func{select}; per questo potrà accettare
2985 ulteriore dati che scriverà di nuovo sul socket, fintanto che c'è spazio sul
2986 buffer di uscita (ecceduto il quale si bloccherà in scrittura). Si ricordi
2987 infatti che il client non ha modo di determinare se la connessione è attiva o
2988 meno (dato che in molte situazioni reali l'inattività può essere temporanea).
2989 Tra l'altro se si ricollega la rete prima della scadenza del timeout, potremo
2990 anche verificare come tutto quello che si era scritto viene poi effettivamente
2991 trasmesso non appena la connessione ridiventa attiva, per cui otterremo
2992 qualcosa del tipo:
2993 \begin{verbatim}
2994 [piccardi@gont sources]$ ./echo 192.168.1.1
2995 Prima riga
2996 Prima riga
2997 Seconda riga dopo l'interruzione
2998 Terza riga
2999 Quarta riga
3000 Seconda riga dopo l'interruzione
3001 Terza riga
3002 Quarta riga
3003 \end{verbatim}
3004 in cui, una volta riconnessa la rete, tutto quello che abbiamo scritto durante
3005 il periodo di disconnessione restituito indietro e stampato immediatamente.
3006
3007 Lo stesso comportamento visto in sez.~\ref{sec:TCP_server_crash} si riottiene
3008 nel caso di un crollo completo della macchina su cui sta il server. In questo
3009 caso di nuovo il client non è in grado di accorgersi di niente dato che si
3010 suppone che il programma server non venga terminato correttamente, ma si
3011 blocchi tutto senza la possibilità di avere l'emissione di un segmento FIN che
3012 segnala la terminazione della connessione. Di nuovo fintanto che la
3013 connessione non si riattiva (con il riavvio della macchina del server) il
3014 client non è in grado di fare altro che accettare dell'input e tentare di
3015 inviarlo. La differenza in questo caso è che non appena la connessione
3016 ridiventa attiva i dati verranno sì trasmessi, ma essendo state perse tutte le
3017 informazioni relative alle precedenti connessioni ai tentativi di scrittura
3018 del client sarà risposto con un segmento RST che provocherà il ritorno di
3019 \func{select} per la ricezione di un errore di \errcode{ECONNRESET}.
3020
3021
3022 \subsection{La funzione \func{shutdown}}
3023 \label{sec:TCP_shutdown}
3024
3025 Come spiegato in sez.~\ref{sec:TCP_conn_term} il procedimento di chiusura di un
3026 socket TCP prevede che da entrambe le parti venga emesso un segmento FIN. È
3027 pertanto del tutto normale dal punto di vista del protocollo che uno dei due
3028 capi chiuda la connessione, quando l'altro capo la lascia
3029 aperta.\footnote{abbiamo incontrato questa situazione nei vari scenari critici
3030   di sez.~\ref{sec:TCP_echo_critical}.}
3031
3032 \itindbeg{half-close}
3033
3034 È pertanto possibile avere una situazione in cui un capo della connessione non
3035 avendo più nulla da scrivere, possa chiudere il socket, segnalando così
3036 l'avvenuta terminazione della trasmissione (l'altro capo riceverà infatti un
3037 \textit{end-of-file} in lettura) mentre dall'altra parte si potrà proseguire
3038 la trasmissione dei dati scrivendo sul socket che da quel lato è ancora
3039 aperto.  Questa è quella situazione in cui si dice che il socket è
3040 ``\textit{half closed}''.
3041
3042 Il problema che si pone è che se la chiusura del socket è effettuata con la
3043 funzione \func{close}, come spiegato in sez.~\ref{sec:TCP_func_close}, si perde
3044 ogni possibilità di poter rileggere quanto l'altro capo può continuare a
3045 scrivere. Per poter permettere allora di segnalare che si è concluso con la
3046 scrittura, continuando al contempo a leggere quanto può provenire dall'altro
3047 capo del socket si può allora usare la funzione \funcd{shutdown}, il cui
3048 prototipo è:
3049 \begin{prototype}{sys/socket.h}
3050 {int shutdown(int sockfd, int how)}
3051
3052 Chiude un lato della connessione fra due socket.
3053   
3054   \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
3055     errore, nel qual caso \var{errno} assumerà i valori:
3056   \begin{errlist}
3057   \item[\errcode{ENOTSOCK}] il file descriptor non corrisponde a un socket.
3058   \item[\errcode{ENOTCONN}] il socket non è connesso.
3059   \end{errlist}
3060   ed inoltre \errval{EBADF}.}
3061 \end{prototype}
3062
3063 La funzione prende come primo argomento il socket \param{sockfd} su cui si
3064 vuole operare e come secondo argomento un valore intero \param{how} che indica
3065 la modalità di chiusura del socket, quest'ultima può prendere soltanto tre
3066 valori: 
3067 \begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
3068 \item[\constd{SHUT\_RD}] chiude il lato in lettura del socket, non sarà più
3069   possibile leggere dati da esso, tutti gli eventuali dati trasmessi
3070   dall'altro capo del socket saranno automaticamente scartati dal kernel, che,
3071   in caso di socket TCP, provvederà comunque ad inviare i relativi segmenti di
3072   ACK.
3073 \item[\constd{SHUT\_WR}] chiude il lato in scrittura del socket, non sarà più
3074   possibile scrivere dati su di esso. Nel caso di socket TCP la chiamata causa
3075   l'emissione di un segmento FIN, secondo la procedura chiamata
3076   \textit{half-close}. Tutti i dati presenti nel buffer di scrittura prima
3077   della chiamata saranno inviati, seguiti dalla sequenza di chiusura
3078   illustrata in sez.~\ref{sec:TCP_conn_term}.
3079 \item[\constd{SHUT\_RDWR}] chiude sia il lato in lettura che quello in
3080   scrittura del socket. È equivalente alla chiamata in sequenza con
3081   \const{SHUT\_RD} e \const{SHUT\_WR}.
3082 \end{basedescript}
3083
3084 \itindend{half-close}
3085
3086 Ci si può chiedere quale sia l'utilità di avere introdotto \const{SHUT\_RDWR}
3087 quando questa sembra rendere \func{shutdown} del tutto equivalente ad una
3088 \func{close}. In realtà non è così, esiste infatti un'altra differenza con
3089 \func{close}, più sottile. Finora infatti non ci siamo presi la briga di
3090 sottolineare in maniera esplicita che, come per i file e le fifo, anche per i
3091 socket possono esserci più riferimenti contemporanei ad uno stesso socket. Per
3092 cui si avrebbe potuto avere l'impressione che sia una corrispondenza univoca
3093 fra un socket ed il file descriptor con cui vi si accede. Questo non è
3094 assolutamente vero, (e lo abbiamo già visto nel codice del server di
3095 fig.~\ref{fig:TCP_echo_server_first_code}), ed è invece assolutamente normale
3096 che, come per gli altri oggetti, ci possano essere più file descriptor che
3097 fanno riferimento allo stesso socket.
3098
3099 Allora se avviene uno di questi casi quello che succederà è che la chiamata a
3100 \func{close} darà effettivamente avvio alla sequenza di chiusura di un socket
3101 soltanto quando il numero di riferimenti a quest'ultimo diventerà nullo.
3102 Fintanto che ci sono file descriptor che fanno riferimento ad un socket l'uso
3103 di \func{close} si limiterà a deallocare nel processo corrente il file
3104 descriptor utilizzato, ma il socket resterà pienamente accessibile attraverso
3105 tutti gli altri riferimenti. Se torniamo all'esempio originale del server di
3106 fig.~\ref{fig:TCP_echo_server_first_code} abbiamo infatti che ci sono due
3107 \func{close}, una sul socket connesso nel padre, ed una sul socket in ascolto
3108 nel figlio, ma queste non effettuano nessuna chiusura reale di detti socket,
3109 dato che restano altri riferimenti attivi, uno al socket connesso nel figlio
3110 ed uno a quello in ascolto nel padre.
3111
3112 Questo non avviene affatto se si usa \func{shutdown} con argomento
3113 \const{SHUT\_RDWR} al posto di \func{close}; in questo caso infatti la
3114 chiusura del socket viene effettuata immediatamente, indipendentemente dalla
3115 presenza di altri riferimenti attivi, e pertanto sarà efficace anche per tutti
3116 gli altri file descriptor con cui, nello stesso o in altri processi, si fa
3117 riferimento allo stesso socket.
3118
3119 Il caso più comune di uso di \func{shutdown} è comunque quello della chiusura
3120 del lato in scrittura, per segnalare all'altro capo della connessione che si è
3121 concluso l'invio dei dati, restando comunque in grado di ricevere quanto
3122 questi potrà ancora inviarci. Questo è ad esempio l'uso che ci serve per
3123 rendere finalmente completo il nostro esempio sul servizio \textit{echo}. Il
3124 nostro client infatti presenta ancora un problema, che nell'uso che finora ne
3125 abbiamo fatto non è emerso, ma che ci aspetta dietro l'angolo non appena
3126 usciamo dall'uso interattivo e proviamo ad eseguirlo redirigendo standard
3127 input e standard output. Così se eseguiamo:
3128 \begin{verbatim}
3129 [piccardi@gont sources]$ ./echo 192.168.1.1 < ../fileadv.tex  > copia
3130 \end{verbatim}%$
3131 vedremo che il file \texttt{copia} risulta mancare della parte finale.
3132
3133 Per capire cosa avviene in questo caso occorre tenere presente come avviene la
3134 comunicazione via rete; quando redirigiamo lo standard input il nostro client
3135 inizierà a leggere il contenuto del file \texttt{../fileadv.tex} a blocchi di
3136 dimensione massima pari a \texttt{MAXLINE} per poi scriverlo, alla massima
3137 velocità consentitagli dalla rete, sul socket. Dato che la connessione è con
3138 una macchina remota occorre un certo tempo perché i pacchetti vi arrivino,
3139 vengano processati, e poi tornino indietro. Considerando trascurabile il tempo
3140 di processo, questo tempo è quello impiegato nella trasmissione via rete, che
3141 viene detto RTT (dalla denominazione inglese \itindex{Round~Trip~Time~(RTT)}
3142 \textit{Round Trip Time}) ed è quello che viene stimato con l'uso del comando
3143 \cmd{ping}.
3144
3145 A questo punto, se torniamo al codice mostrato in
3146 fig.~\ref{fig:TCP_ClientEcho_third}, possiamo vedere che mentre i pacchetti
3147 sono in transito sulla rete il client continua a leggere e a scrivere fintanto
3148 che il file in ingresso finisce. Però non appena viene ricevuto un end-of-file
3149 in ingresso il nostro client termina. Nel caso interattivo, in cui si
3150 inviavano brevi stringhe una alla volta, c'era sempre il tempo di eseguire la
3151 lettura completa di quanto il server rimandava indietro. In questo caso
3152 invece, quando il client termina, essendo la comunicazione saturata e a piena
3153 velocità, ci saranno ancora pacchetti in transito sulla rete che devono
3154 arrivare al server e poi tornare indietro, ma siccome il client esce
3155 immediatamente dopo la fine del file in ingresso, questi non faranno a tempo a
3156 completare il percorso e verranno persi.
3157
3158 Per evitare questo tipo di problema, invece di uscire una volta completata la
3159 lettura del file in ingresso, occorre usare \func{shutdown} per effettuare la
3160 chiusura del lato in scrittura del socket. In questo modo il client segnalerà
3161 al server la chiusura del flusso dei dati, ma potrà continuare a leggere
3162 quanto il server gli sta ancora inviando indietro, fino a quando anch'esso,
3163 riconosciuta la chiusura del socket in scrittura da parte del client,
3164 effettuerà la chiusura dalla sua parte. Solo alla ricezione della chiusura del
3165 socket da parte del server il client potrà essere sicuro della ricezione di
3166 tutti i dati e della terminazione effettiva della connessione.
3167
3168 \begin{figure}[!htbp]
3169   \footnotesize \centering
3170   \begin{minipage}[c]{\codesamplewidth}
3171     \includecodesample{listati/ClientEcho.c}
3172   \end{minipage} 
3173   \normalsize
3174   \caption{La sezione nel codice della versione finale della funzione
3175     \func{ClientEcho}, che usa \func{shutdown} per una conclusione corretta
3176     della connessione.}
3177   \label{fig:TCP_ClientEcho}
3178 \end{figure}
3179
3180 Si è allora riportato in fig.~\ref{fig:TCP_ClientEcho} la versione finale
3181 della nostra funzione \func{ClientEcho}, in grado di gestire correttamente
3182 l'intero flusso di dati fra client e server. Il codice completo del client,
3183 comprendente la gestione delle opzioni a riga di comando e le istruzioni per
3184 la creazione della connessione, si trova nel file
3185 \texttt{TCP\_echo\_fourth.c}, distribuito coi sorgenti allegati alla guida.
3186
3187 La nuova versione è molto simile alla precedente di
3188 fig.~\ref{fig:TCP_ClientEcho_third}; la prima differenza è l'introduzione
3189 (\texttt{\small 7}) della variabile \var{eof}, inizializzata ad un valore
3190 nullo, che serve a mantenere traccia dell'avvenuta conclusione della lettura
3191 del file in ingresso.
3192
3193 La seconda modifica (\texttt{\small 12--15}) è stata quella di rendere
3194 subordinato ad un valore nullo di \var{eof} l'impostazione del file descriptor
3195 set per l'osservazione dello standard input. Se infatti il valore di \var{eof}
3196 è non nullo significa che si è già raggiunta la fine del file in ingresso ed è
3197 pertanto inutile continuare a tenere sotto controllo lo standard input nella
3198 successiva (\texttt{\small 16}) chiamata a \func{select}.
3199
3200 Le maggiori modifiche rispetto alla precedente versione sono invece nella
3201 gestione (\texttt{\small 18--22}) del caso in cui la lettura con \func{fgets}
3202 restituisce un valore nullo, indice della fine del file. Questa nella
3203 precedente versione causava l'immediato ritorno della funzione; in questo caso
3204 prima (\texttt{\small 19}) si imposta opportunamente \var{eof} ad un valore
3205 non nullo, dopo di che (\texttt{\small 20}) si effettua la chiusura del lato
3206 in scrittura del socket con \func{shutdown}. Infine (\texttt{\small 21}) si
3207 usa la macro \macro{FD\_CLR} per togliere lo standard input dal \textit{file
3208   descriptor set}.
3209
3210 In questo modo anche se la lettura del file in ingresso è conclusa, la
3211 funzione non esce dal ciclo principale (\texttt{\small 11--50}), ma continua
3212 ad eseguirlo ripetendo la chiamata a \func{select} per tenere sotto controllo
3213 soltanto il socket connesso, dal quale possono arrivare altri dati, che
3214 saranno letti (\texttt{\small 31}), ed opportunamente trascritti
3215 (\texttt{\small 44--48}) sullo standard output.
3216
3217 Il ritorno della funzione, e la conseguente terminazione normale del client,
3218 viene invece adesso gestito all'interno (\texttt{\small 30--49}) della lettura
3219 dei dati dal socket; se infatti dalla lettura del socket si riceve una
3220 condizione di end-of-file, la si tratterà (\texttt{\small 36--43}) in maniera
3221 diversa a seconda del valore di \var{eof}. Se infatti questa è diversa da zero
3222 (\texttt{\small 37--39}), essendo stata completata la lettura del file in
3223 ingresso, vorrà dire che anche il server ha concluso la trasmissione dei dati
3224 restanti, e si potrà uscire senza errori, altrimenti si stamperà
3225 (\texttt{\small 40--42}) un messaggio di errore per la chiusura precoce della
3226 connessione.
3227
3228
3229 \subsection{Un server basato sull'I/O multiplexing}
3230 \label{sec:TCP_serv_select}
3231
3232 Seguendo di nuovo le orme di Stevens in \cite{UNP1} vediamo ora come con
3233 l'utilizzo dell'I/O multiplexing diventi possibile riscrivere completamente il
3234 nostro server \textit{echo} con una architettura completamente diversa, in
3235 modo da evitare di dover creare un nuovo processo tutte le volte che si ha una
3236 connessione.\footnote{ne faremo comunque una implementazione diversa rispetto
3237   a quella presentata da Stevens in \cite{UNP1}.}
3238
3239 La struttura del nuovo server è illustrata in
3240 fig.~\ref{fig:TCP_echo_multiplex}, in questo caso avremo un solo processo che
3241 ad ogni nuova connessione da parte di un client sul socket in ascolto si
3242 limiterà a registrare l'entrata in uso di un nuovo file descriptor ed
3243 utilizzerà \func{select} per rilevare la presenza di dati in arrivo su tutti i
3244 file descriptor attivi, operando direttamente su ciascuno di essi.
3245
3246 \begin{figure}[!htb]
3247   \centering \includegraphics[width=13cm]{img/TCPechoMult}
3248   \caption{Schema del nuovo server echo basato sull'I/O multiplexing.}
3249   \label{fig:TCP_echo_multiplex}
3250 \end{figure}
3251
3252 La sezione principale del codice del nuovo server è illustrata in
3253 fig.~\ref{fig:TCP_SelectEchod}. Si è tralasciata al solito la gestione delle
3254 opzioni, che è identica alla versione precedente. Resta invariata anche tutta
3255 la parte relativa alla gestione dei segnali, degli errori, e della cessione
3256 dei privilegi, così come è identica la gestione della creazione del socket (si
3257 può fare riferimento al codice già illustrato in
3258 sez.~\ref{sec:TCPsimp_server_main}); al solito il codice completo del server è
3259 disponibile coi sorgenti allegati nel file \texttt{select\_echod.c}.
3260
3261 \begin{figure}[!htbp]
3262   \footnotesize \centering
3263   \begin{minipage}[c]{\codesamplewidth}
3264     \includecodesample{listati/select_echod.c}
3265   \end{minipage} 
3266   \normalsize
3267   \caption{La sezione principale del codice della nuova versione di server
3268     \textit{echo} basati sull'uso della funzione \func{select}.}
3269   \label{fig:TCP_SelectEchod}
3270 \end{figure}
3271
3272 In questo caso, una volta aperto e messo in ascolto il socket, tutto quello
3273 che ci servirà sarà chiamare \func{select} per rilevare la presenza di nuove
3274 connessioni o di dati in arrivo, e processarli immediatamente. Per
3275 implementare lo schema mostrato in fig.~\ref{fig:TCP_echo_multiplex}, il
3276 programma usa una tabella dei socket connessi mantenuta nel vettore
3277 \var{fd\_open} dimensionato al valore di \const{FD\_SETSIZE}, ed una variabile
3278 \var{max\_fd} per registrare il valore più alto dei file descriptor aperti.
3279
3280 Prima di entrare nel ciclo principale (\texttt{\small 6--56}) la nostra
3281 tabella viene inizializzata (\texttt{\small 2}) a zero (valore che
3282 utilizzeremo come indicazione del fatto che il relativo file descriptor non è
3283 aperto), mentre il valore massimo (\texttt{\small 3}) per i file descriptor
3284 aperti viene impostato a quello del socket in ascolto,\footnote{in quanto esso
3285   è l'unico file aperto, oltre i tre standard, e pertanto avrà il valore più
3286   alto.} che verrà anche (\texttt{\small 4}) inserito nella tabella.
3287
3288 La prima sezione (\texttt{\small 7--10}) del ciclo principale esegue la
3289 costruzione del \textit{file descriptor set} \var{fset} in base ai socket
3290 connessi in un certo momento; all'inizio ci sarà soltanto il socket in
3291 ascolto, ma nel prosieguo delle operazioni, verranno utilizzati anche tutti i
3292 socket connessi registrati nella tabella \var{fd\_open}.  Dato che la chiamata
3293 di \func{select} modifica il valore del \textit{file descriptor set}, è
3294 necessario ripetere (\texttt{\small 7}) ogni volta il suo azzeramento, per poi
3295 procedere con il ciclo (\texttt{\small 8--10}) in cui si impostano i socket
3296 trovati attivi.
3297
3298 Per far questo si usa la caratteristica dei file descriptor, descritta in
3299 sez.~\ref{sec:file_open_close}, per cui il kernel associa sempre ad ogni nuovo
3300 file il file descriptor con il valore più basso disponibile. Questo fa sì che
3301 si possa eseguire il ciclo (\texttt{\small 8}) a partire da un valore minimo,
3302 che sarà sempre quello del socket in ascolto, mantenuto in \var{list\_fd},
3303 fino al valore massimo di \var{max\_fd} che dovremo aver cura di tenere
3304 aggiornato.  Dopo di che basterà controllare (\texttt{\small 9}) nella nostra
3305 tabella se il file descriptor è in uso o meno,\footnote{si tenga presente che
3306   benché il kernel assegni sempre il primo valore libero, dato che nelle
3307   operazioni i socket saranno aperti e chiusi in corrispondenza della
3308   creazione e conclusione delle connessioni, si potranno sempre avere dei
3309   \textsl{buchi} nella nostra tabella.} e impostare \var{fset} di conseguenza.
3310
3311 Una volta inizializzato con i socket aperti il nostro \textit{file descriptor
3312   set} potremo chiamare \func{select} per fargli osservare lo stato degli
3313 stessi (in lettura, presumendo che la scrittura sia sempre consentita). Come
3314 per il precedente esempio di sez.~\ref{sec:TCP_child_hand}, essendo questa
3315 l'unica funzione che può bloccarsi, ed essere interrotta da un segnale, la
3316 eseguiremo (\texttt{\small 11--12}) all'interno di un ciclo di \code{while}
3317 che la ripete indefinitamente qualora esca con un errore di \errcode{EINTR}.
3318 Nel caso invece di un errore normale si provvede (\texttt{\small 13--16}) ad
3319 uscire stampando un messaggio di errore.
3320
3321 Se invece la funzione ritorna normalmente avremo in \var{n} il numero di
3322 socket da controllare. Nello specifico si danno due possibili casi diversi per
3323 cui \func{select} può essere ritornata: o si è ricevuta una nuova connessione
3324 ed è pronto il socket in ascolto, sul quale si può eseguire \func{accept} o
3325 c'è attività su uno dei socket connessi, sui quali si può eseguire
3326 \func{read}.
3327
3328 Il primo caso viene trattato immediatamente (\texttt{\small 17--26}): si
3329 controlla (\texttt{\small 17}) che il socket in ascolto sia fra quelli attivi,
3330 nel qual caso anzitutto (\texttt{\small 18}) se ne decrementa il numero in
3331 \var{n}; poi, inizializzata (\texttt{\small 19}) la lunghezza della struttura
3332 degli indirizzi, si esegue \func{accept} per ottenere il nuovo socket connesso
3333 controllando che non ci siano errori (\texttt{\small 20--23}). In questo caso
3334 non c'è più la necessità di controllare per interruzioni dovute a segnali, in
3335 quanto siamo sicuri che \func{accept} non si bloccherà. Per completare la
3336 trattazione occorre a questo punto aggiungere (\texttt{\small 24}) il nuovo
3337 file descriptor alla tabella di quelli connessi, ed inoltre, se è il caso,
3338 aggiornare (\texttt{\small 25}) il valore massimo in \var{max\_fd}.
3339
3340 Una volta controllato l'arrivo di nuove connessioni si passa a verificare se
3341 vi sono dati sui socket connessi, per questo si ripete un ciclo
3342 (\texttt{\small 29--55}) fintanto che il numero di socket attivi \var{n} resta
3343 diverso da zero; in questo modo se l'unico socket con attività era quello
3344 connesso, avendo opportunamente decrementato il contatore, il ciclo verrà
3345 saltato, e si ritornerà immediatamente (ripetuta l'inizializzazione del
3346 \textit{file descriptor set} con i nuovi valori nella tabella) alla chiamata
3347 di \func{accept}. Se il socket attivo non è quello in ascolto, o ce ne sono
3348 comunque anche altri, il valore di \var{n} non sarà nullo ed il controllo sarà
3349 eseguito. Prima di entrare nel ciclo comunque si inizializza (\texttt{\small
3350   28}) il valore della variabile \var{i} che useremo come indice nella tabella
3351 \var{fd\_open} al valore minimo, corrispondente al file descriptor del socket
3352 in ascolto.
3353
3354 Il primo passo (\texttt{\small 30}) nella verifica è incrementare il valore
3355 dell'indice \var{i} per posizionarsi sul primo valore possibile per un file
3356 descriptor associato ad un eventuale socket connesso, dopo di che si controlla
3357 (\texttt{\small 31}) se questo è nella tabella dei socket connessi, chiedendo
3358 la ripetizione del ciclo in caso contrario. Altrimenti si passa a verificare
3359 (\texttt{\small 32}) se il file descriptor corrisponde ad uno di quelli
3360 attivi, e nel caso si esegue (\texttt{\small 33}) una lettura, uscendo con un
3361 messaggio in caso di errore (\texttt{\small 34--38}).
3362
3363 Se (\texttt{\small 39}) il numero di byte letti \var{nread} è nullo si è in
3364 presenza del caso di un \textit{end-of-file}, indice che una connessione che
3365 si è chiusa, che deve essere trattato (\texttt{\small 39--48}) opportunamente.
3366 Il primo passo è chiudere (\texttt{\small 40}) anche il proprio capo del
3367 socket e rimuovere (\texttt{\small 41}) il file descriptor dalla tabella di
3368 quelli aperti, inoltre occorre verificare (\texttt{\small 42}) se il file
3369 descriptor chiuso è quello con il valore più alto, nel qual caso occorre
3370 trovare (\texttt{\small 42--46}) il nuovo massimo, altrimenti (\texttt{\small
3371   47}) si può ripetere il ciclo da capo per esaminare (se ne restano)
3372 ulteriori file descriptor attivi.
3373
3374 Se però è stato chiuso il file descriptor più alto, dato che la scansione dei
3375 file descriptor attivi viene fatta a partire dal valore più basso, questo
3376 significa che siamo anche arrivati alla fine della scansione, per questo
3377 possiamo utilizzare direttamente il valore dell'indice \var{i} con un ciclo
3378 all'indietro (\texttt{\small 43}) che trova il primo valore per cui la tabella
3379 presenta un file descriptor aperto, e lo imposta (\texttt{\small 44}) come
3380 nuovo massimo, per poi tornare (\texttt{\small 44}) al ciclo principale con un
3381 \code{break}, e rieseguire \func{select}.
3382
3383 Se infine si sono effettivamente letti dei dati dal socket (ultimo caso
3384 rimasto) si potrà invocare immediatamente (\texttt{\small 49})
3385 \func{FullWrite} per riscriverli indietro sul socket stesso, avendo cura di
3386 uscire con un messaggio in caso di errore (\texttt{\small 50--53}). Si noti
3387 che nel ciclo si esegue una sola lettura, contrariamente a quanto fatto con la
3388 precedente versione (si riveda il codice di fig.~\ref{fig:TCP_ServEcho_second})
3389 in cui si continuava a leggere fintanto che non si riceveva un
3390 \textit{end-of-file}, questo perché usando l'\textit{I/O multiplexing} non si
3391 vuole essere bloccati in lettura.  L'uso di \func{select} ci permette di
3392 trattare automaticamente anche il caso in cui la \func{read} non è stata in
3393 grado di leggere tutti i dati presenti sul socket, dato che alla iterazione
3394 successiva \func{select} ritornerà immediatamente segnalando l'ulteriore
3395 disponibilità.
3396
3397 Il nostro server comunque soffre di una vulnerabilità per un attacco di tipo
3398 \textit{Denial of Service}. Il problema è che in caso di blocco di una
3399 qualunque delle funzioni di I/O, non avendo usato processi separati, tutto il
3400 server si ferma e non risponde più a nessuna richiesta. Abbiamo scongiurato
3401 questa evenienza per l'I/O in ingresso con l'uso di \func{select}, ma non vale
3402 altrettanto per l'I/O in uscita. Il problema pertanto può sorgere qualora una
3403 delle chiamate a \func{write} effettuate da \func{FullWrite} si blocchi. Con
3404 il funzionamento normale questo non accade in quanto il server si limita a
3405 scrivere quanto riceve in ingresso, ma qualora venga utilizzato un client
3406 malevolo che esegua solo scritture e non legga mai indietro l'\textsl{eco} del
3407 server, si potrebbe giungere alla saturazione del buffer di scrittura, ed al
3408 conseguente blocco del server su di una \func{write}.
3409
3410 Le possibili soluzioni in questo caso sono quelle di ritornare ad eseguire il
3411 ciclo di risposta alle richieste all'interno di processi separati, utilizzare
3412 un timeout per le operazioni di scrittura, o eseguire queste ultime in
3413 modalità non bloccante, concludendo le operazioni qualora non vadano a buon
3414 fine.
3415
3416
3417
3418 \subsection{I/O multiplexing con \func{poll}}
3419 \label{sec:TCP_serv_poll}
3420
3421 Finora abbiamo trattato le problematiche risolubili con l'I/O multiplexing
3422 impiegando la funzione \func{select}; questo è quello che avviene nella
3423 maggior parte dei casi, in quanto essa è nata sotto BSD proprio per affrontare
3424 queste problematiche con i socket.  Abbiamo però visto in
3425 sez.~\ref{sec:file_multiplexing} come la funzione \func{poll} possa costituire
3426 una alternativa a \func{select}, con alcuni vantaggi.\footnote{non soffrendo
3427   delle limitazioni dovute all'uso dei \textit{file descriptor set}.}
3428
3429 Ancora una volta in sez.~\ref{sec:file_poll} abbiamo trattato la funzione in
3430 maniera generica, parlando di file descriptor, ma come per \func{select}
3431 quando si ha a che fare con dei socket il concetto di essere \textsl{pronti}
3432 per l'I/O deve essere specificato nei dettagli, per tener conto delle
3433 condizioni della rete. Inoltre deve essere specificato come viene classificato
3434 il traffico nella suddivisione fra dati normali e prioritari. In generale
3435 pertanto:
3436 \begin{itemize}
3437 \item i dati inviati su un socket vengono considerati traffico normale,
3438   pertanto vengono rilevati alla loro ricezione sull'altro capo da una
3439   selezione effettuata con \const{POLLIN} o \const{POLLRDNORM};
3440 \item i dati urgenti \textit{out-of-band} (vedi
3441   sez.~\ref{sec:TCP_urgent_data}) su un socket TCP vengono considerati
3442   traffico prioritario e vengono rilevati da una condizione \const{POLLIN},
3443   \const{POLLPRI} o \const{POLLRDBAND}.
3444 \item la chiusura di una connessione (cioè la ricezione di un segmento FIN)
3445   viene considerato traffico normale, pertanto viene rilevato da una
3446   condizione \const{POLLIN} o \const{POLLRDNORM}, ma una conseguente chiamata
3447   a \func{read} restituirà 0.
3448 \item la disponibilità di spazio sul socket per la scrittura di dati viene
3449   segnalata con una condizione \const{POLLOUT}.
3450 \item quando uno dei due capi del socket chiude un suo lato della connessione
3451   con \func{shutdown} si riceve una condizione di \const{POLLHUP}.
3452 \item la presenza di un errore sul socket (sia dovuta ad un segmento RST che a
3453   timeout) viene considerata traffico normale, ma viene segnalata anche dalla
3454   condizione \const{POLLERR}.
3455 \item la presenza di una nuova connessione su un socket in ascolto può essere
3456   considerata sia traffico normale che prioritario, nel caso di Linux
3457   l'implementazione la classifica come normale.
3458 \end{itemize}
3459
3460 Come esempio dell'uso di \func{poll} proviamo allora a reimplementare il
3461 server \textit{echo} secondo lo schema di fig.~\ref{fig:TCP_echo_multiplex}
3462 usando \func{poll} al posto di \func{select}. In questo caso dovremo fare
3463 qualche modifica, per tenere conto della diversa sintassi delle due funzioni,
3464 ma la struttura del programma resta sostanzialmente la stessa.
3465
3466
3467 \begin{figure}[!htbp]
3468   \footnotesize \centering
3469   \begin{minipage}[c]{\codesamplewidth}
3470     \includecodesample{listati/poll_echod.c}
3471   \end{minipage} 
3472   \normalsize
3473   \caption{La sezione principale del codice della nuova versione di server
3474     \textit{echo} basati sull'uso della funzione \func{poll}.}
3475   \label{fig:TCP_PollEchod}
3476 \end{figure}
3477
3478 In fig.~\ref{fig:TCP_PollEchod} è riportata la sezione principale della nuova
3479 versione del server, la versione completa del codice è riportata nel file
3480 \texttt{poll\_echod.c} dei sorgenti allegati alla guida. Al solito nella
3481 figura si sono tralasciate la gestione delle opzioni, la creazione del socket
3482 in ascolto, la cessione dei privilegi e le operazioni necessarie a far
3483 funzionare il programma come demone, privilegiando la sezione principale del
3484 programma.
3485
3486 Come per il precedente server basato su \func{select} il primo passo
3487 (\texttt{\small 2--8}) è quello di inizializzare le variabili necessarie. Dato
3488 che in questo caso dovremo usare un vettore di strutture occorre anzitutto
3489 (\texttt{\small 2}) allocare la memoria necessaria utilizzando il numero
3490 massimo \var{n} di socket osservabili, che viene impostato attraverso
3491 l'opzione \texttt{-n} ed ha un valore di default di 256. 
3492
3493 Dopo di che si preimposta (\texttt{\small 3}) il valore \var{max\_fd} del file
3494 descriptor aperto con valore più alto a quello del socket in ascolto (al
3495 momento l'unico), e si provvede (\texttt{\small 4--7}) ad inizializzare le
3496 strutture, disabilitando (\texttt{\small 5}) l'osservazione con un valore
3497 negativo del campo \var{fd} ma predisponendo (\texttt{\small 6}) il campo
3498 \var{events} per l'osservazione dei dati normali con \const{POLLRDNORM}.
3499 Infine (\texttt{\small 8}) si attiva l'osservazione del socket in ascolto
3500 inizializzando la corrispondente struttura. Questo metodo comporta, in
3501 modalità interattiva, lo spreco di tre strutture (quelle relative a standard
3502 input, output ed error) che non vengono mai utilizzate in quanto la prima è
3503 sempre quella relativa al socket in ascolto.
3504
3505 Una volta completata l'inizializzazione tutto il lavoro viene svolto
3506 all'interno del ciclo principale \texttt{\small 10--55}) che ha una struttura
3507 sostanzialmente identica a quello usato per il precedente esempio basato su
3508 \func{select}. La prima istruzione (\texttt{\small 11--12}) è quella di
3509 eseguire \func{poll} all'interno di un ciclo che la ripete qualora venisse
3510 interrotta da un segnale, da cui si esce soltanto quando la funzione ritorna,
3511 restituendo nella variabile \var{n} il numero di file descriptor trovati
3512 attivi.  Qualora invece si sia ottenuto un errore si procede (\texttt{\small
3513   13--16}) alla terminazione immediata del processo provvedendo a stampare una
3514 descrizione dello stesso.
3515
3516 Una volta ottenuta dell'attività su un file descriptor si hanno di nuovo due
3517 possibilità. La prima possibilità è che ci sia attività sul socket in ascolto,
3518 indice di una nuova connessione, nel qual caso si controlla (\texttt{\small
3519   17}) se il campo \var{revents} della relativa struttura è attivo; se è così
3520 si provvede (\texttt{\small 18}) a decrementare la variabile \var{n} (che
3521 assume il significato di numero di file descriptor attivi rimasti da
3522 controllare) per poi (\texttt{\small 19--23}) effettuare la chiamata ad
3523 \func{accept}, terminando il processo in caso di errore. Se la chiamata ad
3524 \func{accept} ha successo si procede attivando (\texttt{\small 24}) la
3525 struttura relativa al nuovo file descriptor da essa ottenuto, modificando
3526 (\texttt{\small 24}) infine quando necessario il valore massimo dei file
3527 descriptor aperti mantenuto in \var{max\_fd}.
3528
3529 La seconda possibilità è che vi sia dell'attività su uno dei socket aperti in
3530 precedenza, nel qual caso si inizializza (\texttt{\small 27}) l'indice \var{i}
3531 del vettore delle strutture \struct{pollfd} al valore del socket in ascolto,
3532 dato che gli ulteriori socket aperti avranno comunque un valore superiore.  Il