Prova di endianess
[gapil.git] / elemtcp.tex
1 %% elemtcp.tex
2 %%
3 %% Copyright (C) 2000-2003 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 "Prefazione",
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 \chapter{Socket TCP}
12 \label{cha:TCP_socket}
13
14 In questo capitolo iniziamo ad approfondire la conoscenza dei socket TCP,
15 iniziando con una descrizione delle principali caratteristiche del
16 funzionamento di una connessione TCP.  Tratteremo poi le varie funzioni che
17 servono alla creazione di una connessione fra un server elementare ed il suo
18 client, fornendo poi alcuni esempi di applicazione elementare.
19
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 \subsection{La creazione della connessione: il \textit{three way handshake}}
39 \label{sec:TCP_conn_cre}
40
41 Il processo che porta a creare una connessione TCP è chiamato \textit{three
42   way handshake}; la successione tipica degli eventi (e dei
43 \textsl{segmenti}\footnote{Si ricordi che il segmento è l'unità elementare di
44   dati trasmessa dal protocollo TCP al livello successivo; tutti i segmenti
45   hanno un header che contiene le informazioni che servono allo \textit{stack
46     TCP} (così viene di solito chiamata la parte del kernel che implementa il
47   protocollo) per realizzare la comunicazione, fra questi dati ci sono una
48   serie di flag usati per gestire la connessione, come SYN, ACK, URG, FIN,
49   alcuni di essi, come SYN (che sta per \textit{syncronize}) corrispondono a
50   funzioni particolari del protocollo e danno il nome al segmento, (per
51   maggiori dettagli vedere \secref{sec:tcp_protocol}).}  di dati che vengono
52 scambiati) che porta alla creazione di una connessione è la seguente:
53  
54 \begin{enumerate}
55 \item Il server deve essere preparato per accettare le connessioni in arrivo;
56   il procedimento si chiama \textsl{apertura passiva} del socket (in inglese
57   \textit{passive open}). Questo viene fatto chiamando la sequenza di funzioni
58   \func{socket}, \func{bind} e \func{listen}. Completata l'apertura passiva il
59   server chiama la funzione \func{accept} e il processo si blocca in attesa di
60   connessioni.
61   
62 \item Il client richiede l'inizio della connessione usando la funzione
63   \func{connect}, attraverso un procedimento che viene chiamato
64   \textsl{apertura attiva}, dall'inglese \textit{active open}. La chiamata di
65   \func{connect} blocca il processo e causa l'invio da parte del client di un
66   segmento SYN, in sostanza viene inviato al server un pacchetto IP che
67   contiene solo gli header IP e TCP (con il numero di sequenza iniziale e il
68   flag SYN) e le opzioni di TCP.
69   
70 \item il server deve dare ricevuto (l'\textit{acknowledge}) del SYN del
71   client, inoltre anche il server deve inviare il suo SYN al client (e
72   trasmettere il suo numero di sequenza iniziale) questo viene fatto
73   ritrasmettendo un singolo segmento in cui sono impostati entrambi i flag SYN
74   e ACK.
75   
76 \item una volta che il client ha ricevuto l'acknowledge dal server la funzione
77   \func{connect} ritorna, l'ultimo passo è dare dare il ricevuto del SYN del
78   server inviando un ACK. Alla ricezione di quest'ultimo la funzione
79   \func{accept} del server ritorna e la connessione è stabilita.
80 \end{enumerate} 
81
82 Il procedimento viene chiamato \textit{three way handshake} dato che per
83 realizzarlo devono essere scambiati tre segmenti.  In \figref{fig:TCP_TWH}
84 si è rappresentata graficamente la sequenza di scambio dei segmenti che
85 stabilisce la connessione.
86
87 % Una analogia citata da R. Stevens per la connessione TCP è quella con il
88 % sistema del telefono. La funzione \texttt{socket} può essere considerata
89 % l'equivalente di avere un telefono. La funzione \texttt{bind} è analoga al
90 % dire alle altre persone qual'è il proprio numero di telefono perché possano
91 % chiamare. La funzione \texttt{listen} è accendere il campanello del telefono
92 % per sentire le chiamate in arrivo.  La funzione \texttt{connect} richiede di
93 % conoscere il numero di chi si vuole chiamare. La funzione \texttt{accept} è
94 % quando si risponde al telefono.
95
96 \begin{figure}[htb]
97   \centering
98   \includegraphics[width=10cm]{img/three_way_handshake}  
99   \caption{Il \textit{three way handshake} del TCP.}
100   \label{fig:TCP_TWH}
101 \end{figure}
102
103 Si è accennato in precedenza ai \textsl{numeri di sequenza} (che sono anche
104 riportati in \figref{fig:TCP_TWH}): per gestire una connessione affidabile
105 infatti il protocollo TCP prevede nell'header la presenza di un numero a 32
106 bit (chiamato appunto \textit{sequence number}) che identifica a quale byte
107 nella sequenza del flusso corrisponde il primo byte della sezione dati
108 contenuta nel segmento.
109
110 Il numero di sequenza di ciascun segmento viene calcolato a partire da un
111 \textsl{numero di sequenza iniziale} generato in maniera casuale del kernel
112 all'inizio della connessione e trasmesso con il SYN; l'acknowledgement di
113 ciascun segmento viene effettuato dall'altro capo della connessione impostando
114 il flag ACK e restituendo nell'apposito campo dell'header un
115 \textit{acknowledge number}) pari al numero di sequenza che il ricevente si
116 aspetta di ricevere con il pacchetto successivo; dato che il primo pacchetto
117 SYN consuma un byte, nel \textit{three way handshake} il numero di acknowledge
118 è sempre pari al numero di sequenza iniziale incrementato di uno; lo stesso
119 varrà anche (vedi \figref{fig:TCP_close}) per l'acknowledgement di un FIN.
120
121 \subsection{Le opzioni TCP.}
122 \label{sec:TCP_TCP_opt}
123
124 Ciascun segmento SYN contiene in genere delle opzioni per il protocollo TCP
125 (le cosiddette \textit{TCP options}, che vengono inserite fra l'header e i
126 dati) che servono a comunicare all'altro capo una serie di parametri utili a
127 regolare la connessione. Normalmente vengono usate le seguenti opzioni:
128
129 \begin{itemize}
130 \item \textit{MSS option}, dove MMS sta per \textit{maximum segment size}, con
131   questa opzione ciascun capo della connessione annuncia all'altro il massimo
132   ammontare di dati che vorrebbe accettare per ciascun segmento nella
133   connessione corrente. È possibile leggere e scrivere questo valore
134   attraverso l'opzione del socket \const{TCP\_MAXSEG}.
135   
136 \item \textit{window scale option}, %come spiegato in \secref{sec:tcp_protocol}
137   il protocollo TCP implementa il controllo di flusso attraverso una
138   \textsl{finestra annunciata} (\textit{advertized window}) con la quale
139   ciascun capo della comunicazione dichiara quanto spazio disponibile ha in
140   memoria per i dati. Questo è un numero a 16 bit dell'header, che così può
141   indicare un massimo di 65535 byte;\footnote{ Linux usa come massimo 32767
142     per evitare problemi con alcune implementazioni che usano l'aritmetica con
143     segno per implementare lo stack TCP.} ma alcuni tipi di connessione come
144   quelle ad alta velocità (sopra i 45Mbit/sec) e quelle che hanno grandi
145   ritardi nel cammino dei pacchetti (come i satelliti) richiedono una finestra
146   più grande per poter ottenere il massimo dalla trasmissione, per questo
147   esiste questa opzione che indica un fattore di scala da applicare al valore
148   della finestra annunciata\footnote{essendo una nuova opzione per garantire
149     la compatibilità con delle vecchie implementazioni del protocollo la
150     procedura che la attiva prevede come negoziazione che l'altro capo della
151     connessione riconosca esplicitamente l'opzione inserendola anche lui nel
152     suo SYN di risposta dell'apertura della connessione.} per la connessione
153   corrente (espresso come numero di bit cui spostare a sinistra il valore
154   della finestra annunciata inserito nel pacchetto).
155
156 \item \textit{timestamp option}, è anche questa una nuova opzione necessaria
157   per le connessioni ad alta velocità per evitare possibili corruzioni di dati
158   dovute a pacchetti perduti che riappaiono; anche questa viene negoziata come
159   la precedente.
160
161 \end{itemize}
162
163 La MSS è generalmente supportata da quasi tutte le implementazioni del
164 protocollo, le ultime due opzioni (trattate
165 nell'\href{http://www.ietf.org/rfc/rfc1323.txt}{RFC~1323}) sono meno comuni;
166 vengono anche dette \textit{long fat pipe options} dato che questo è il nome
167 che viene dato alle connessioni caratterizzate da alta velocità o da ritardi
168 elevati. In ogni caso Linux supporta pienamente entrambe le opzioni.
169
170 \subsection{La terminazione della connessione}
171 \label{sec:TCP_conn_term}
172
173 Mentre per la creazione di una connessione occorre un interscambio di tre
174 segmenti, la procedura di chiusura ne richiede normalmente quattro. In questo
175 caso la successione degli eventi è la seguente:
176
177 \begin{enumerate}
178 \item Un processo ad uno dei due capi chiama la funzione \func{close}, dando
179   l'avvio a quella che viene chiamata \textsl{chiusura attiva} (o
180   \textit{active close}). Questo comporta l'emissione di un segmento FIN, che
181   serve ad indicare che si è finito con l'invio dei dati sulla connessione.
182   
183 \item L'altro capo della connessione riceve il FIN e dovrà eseguire la
184   \textsl{chiusura passiva} (o \textit{passive close}). Al FIN, come ad ogni
185   altro pacchetto, viene risposto con un ACK, inoltre il ricevimento del FIN
186   viene segnalato al processo che ha aperto il socket (dopo che ogni altro
187   eventuale dato rimasto in coda è stato ricevuto) come un end-of-file sulla
188   lettura: questo perché il ricevimento di un FIN significa che non si
189   riceveranno altri dati sulla connessione.
190   
191 \item Una volta rilevata l'end-of-file anche il secondo processo chiamerà la
192   funzione \func{close} sul proprio socket, causando l'emissione di un altro
193   segmento FIN.
194
195 \item L'altro capo della connessione riceverà il FIN conclusivo e risponderà
196   con un ACK.
197 \end{enumerate}
198
199 Dato che in questo caso sono richiesti un FIN ed un ACK per ciascuna direzione
200 normalmente i segmenti scambiati sono quattro.  Questo non è vero sempre
201 giacché in alcune situazioni il FIN del passo 1) è inviato insieme a dei dati.
202 Inoltre è possibile che i segmenti inviati nei passi 2 e 3 dal capo che
203 effettua la chiusura passiva, siano accorpati in un singolo segmento. In
204 \figref{fig:TCP_close} si è rappresentato graficamente lo sequenza di
205 scambio dei segmenti che conclude la connessione.
206
207 \begin{figure}[htb]
208   \centering  
209   \includegraphics[width=10cm]{img/tcp_close}  
210   \caption{La chiusura di una connessione TCP.}
211   \label{fig:TCP_close}
212 \end{figure}
213
214 Come per il SYN anche il FIN occupa un byte nel numero di sequenza, per cui
215 l'ACK riporterà un \textit{acknowledge number} incrementato di uno. 
216
217 Si noti che, nella sequenza di chiusura, fra i passi 2 e 3, è in teoria
218 possibile che si mantenga un flusso di dati dal capo della connessione che
219 deve ancora eseguire la chiusura passiva a quello che sta eseguendo la
220 chiusura attiva.  Nella sequenza indicata i dati verrebbero persi, dato che si
221 è chiuso il socket dal lato che esegue la chiusura attiva; esistono tuttavia
222 situazioni in cui si vuole poter sfruttare questa possibilità, usando una
223 procedura che è chiamata \textit{half-close}; torneremo su questo aspetto e su
224 come utilizzarlo in \secref{xxx_shutdown}, quando parleremo della funzione
225 \func{shutdown}.
226
227 La emissione del FIN avviene quando il socket viene chiuso, questo però non
228 avviene solo per la chiamata esplicita della funzione \func{close}, ma anche
229 alla terminazione di un processo, quando tutti i file vengono chiusi.  Questo
230 comporta ad esempio che se un processo viene terminato da un segnale tutte le
231 connessioni aperte verranno chiuse.
232
233 Infine occorre sottolineare che, benché nella figura (e nell'esempio che
234 vedremo più avanti in \secref{sec:TCP_echo}) sia stato il client ad eseguire
235 la chiusura attiva, nella realtà questa può essere eseguita da uno qualunque
236 dei due capi della comunicazione (come nell'esempio di
237 \figref{fig:TCP_daytime_iter_server_code}), e anche se il caso più comune
238 resta quello del client, ci sono alcuni servizi, il principale dei quali è
239 l'HTTP, per i quali è il server ad effettuare la chiusura attiva.
240
241
242 \subsection{Un esempio di connessione}
243 \label{sec:TCP_conn_dia}
244
245 Come abbiamo visto le operazioni del TCP nella creazione e conclusione di una
246 connessione sono piuttosto complesse, ed abbiamo esaminato soltanto quelle
247 relative ad un andamento normale.  In \secref{sec:TCP_states} vedremo con
248 maggiori dettagli che una connessione può assumere vari stati, che ne
249 caratterizzano il funzionamento, e che sono quelli che vengono riportati dal
250 comando \cmd{netstat}, per ciascun socket TCP aperto, nel campo
251 \textit{State}.
252
253 Non possiamo affrontare qui una descrizione completa del funzionamento del
254 protocollo; un approfondimento sugli aspetti principali si trova in
255 \secref{sec:tcp_protocol}, ma per una trattazione completa il miglior
256 riferimento resta \cite{TCPIll1}. Qui ci limiteremo a descrivere brevemente un
257 semplice esempio di connessione e le transizioni che avvengono nei due casi
258 appena citati (creazione e terminazione della connessione).
259
260 In assenza di connessione lo stato del TCP è \texttt{CLOSED}; quando una
261 applicazione esegue una apertura attiva il TCP emette un SYN e lo stato
262 diventa \texttt{SYN\_SENT}; quando il TCP riceve la risposta del SYN$+$ACK
263 emette un ACK e passa allo stato \texttt{ESTABLISHED}; questo è lo stato
264 finale in cui avviene la gran parte del trasferimento dei dati.
265
266 Dal lato server in genere invece il passaggio che si opera con l'apertura
267 passiva è quello di portare il socket dallo stato \texttt{CLOSED} allo
268 stato \texttt{LISTEN} in cui vengono accettate le connessioni.
269
270 Dallo stato \texttt{ESTABLISHED} si può uscire in due modi; se un'applicazione
271 chiama la funzione \texttt{close} prima di aver ricevuto un
272 \textit{end-of-file} (chiusura attiva) la transizione è verso lo stato
273 \texttt{FIN\_WAIT\_1}; se invece l'applicazione riceve un FIN nello stato
274 \texttt{ESTABLISHED} (chiusura passiva) la transizione è verso lo stato
275 \texttt{CLOSE\_WAIT}.
276
277 In \figref{fig:TCP_conn_example} è riportato lo schema dello scambio dei
278 pacchetti che avviene per una un esempio di connessione, insieme ai vari stati
279 che il protocollo viene ad assumere per i due lati, server e client.
280
281 \begin{figure}[htb]
282   \centering
283   \includegraphics[width=9cm]{img/tcp_connection}  
284   \caption{Schema dello scambio di pacchetti per un esempio di connessione.}
285   \label{fig:TCP_conn_example}
286 \end{figure}
287
288 La connessione viene iniziata dal client che annuncia un MSS di 1460, un
289 valore tipico con Linux per IPv4 su Ethernet, il server risponde con lo stesso
290 valore (ma potrebbe essere anche un valore diverso).
291
292 Una volta che la connessione è stabilita il client scrive al server una
293 richiesta (che assumiamo stare in un singolo segmento, cioè essere minore dei
294 1460 byte annunciati dal server), quest'ultimo riceve la richiesta e
295 restituisce una risposta (che di nuovo supponiamo stare in un singolo
296 segmento). Si noti che l'acknowledge della richiesta è mandato insieme alla
297 risposta: questo viene chiamato \textit{piggybacking} ed avviene tutte le
298 volte che che il server è sufficientemente veloce a costruire la risposta; in
299 caso contrario si avrebbe prima l'emissione di un ACK e poi l'invio della
300 risposta.
301
302 Infine si ha lo scambio dei quattro segmenti che terminano la connessione
303 secondo quanto visto in \secref{sec:TCP_conn_term}; si noti che il capo della
304 connessione che esegue la chiusura attiva entra nello stato
305 \texttt{TIME\_WAIT}, sul cui significato torneremo fra poco.
306
307 È da notare come per effettuare uno scambio di due pacchetti (uno di richiesta
308 e uno di risposta) il TCP necessiti di ulteriori otto segmenti, se invece si
309 fosse usato UDP sarebbero stati sufficienti due soli pacchetti. Questo è il
310 costo che occorre pagare per avere l'affidabilità garantita dal TCP, se si
311 fosse usato UDP si sarebbe dovuto trasferire la gestione di tutta una serie di
312 dettagli (come la verifica della ricezione dei pacchetti) dal livello del
313 trasporto all'interno dell'applicazione.
314
315 Quello che è bene sempre tenere presente è allora quali sono le esigenze che
316 si hanno in una applicazione di rete, perché non è detto che TCP sia la
317 miglior scelta in tutti i casi (ad esempio se si devono solo scambiare dati
318 già organizzati in piccoli pacchetti l'overhead aggiunto può essere eccessivo)
319 per questo esistono applicazioni che usano UDP e lo fanno perché nel caso
320 specifico le sue caratteristiche di velocità e compattezza nello scambio dei
321 dati rispondono meglio alle esigenze che devono essere affrontate.
322
323 \subsection{Lo stato \texttt{TIME\_WAIT}}
324 \label{sec:TCP_time_wait}
325
326 Come riportato da Stevens in \cite{UNP1} lo stato \texttt{TIME\_WAIT} è
327 probabilmente uno degli aspetti meno compresi del protocollo TCP, è infatti
328 comune trovare domande su come sia possibile evitare che un'applicazione resti
329 in questo stato lasciando attiva una connessione ormai conclusa; la risposta è
330 che non deve essere fatto, ed il motivo cercheremo di spiegarlo adesso.
331
332 Come si è visto nell'esempio precedente (vedi \figref{fig:TCP_conn_example})
333 \texttt{TIME\_WAIT} è lo stato finale in cui il capo di una connessione che
334 esegue la chiusura attiva resta prima di passare alla chiusura definitiva
335 della connessione. Il tempo in cui l'applicazione resta in questo stato deve
336 essere due volte la MSL (\textit{Maximum Segment Lifetime}).
337
338 La MSL è la stima del massimo periodo di tempo che un pacchetto IP può vivere
339 sulla rete; questo tempo è limitato perché ogni pacchetto IP può essere
340 ritrasmesso dai router un numero massimo di volte (detto \textit{hop limit}).
341 Il numero di ritrasmissioni consentito è indicato dal campo TTL dell'header di
342 IP (per maggiori dettagli vedi \secref{sec:IP_xxx}), e viene decrementato ad
343 ogni passaggio da un router; quando si annulla il pacchetto viene scartato.
344 Siccome il numero è ad 8 bit il numero massimo di ``\textsl{salti}'' è di 255,
345 pertanto anche se il TTL (da \textit{time to live}) non è propriamente un
346 limite sul tempo di vita, si stima che un pacchetto IP non possa restare nella
347 rete per più di MSL secondi.
348
349 Ogni implementazione del TCP deve scegliere un valore per la MSL
350 (l'\href{http://www.ietf.org/rfc/rfc1122.txt}{RFC~1122} raccomanda 2 minuti,
351 Linux usa 30 secondi), questo comporta una durata dello stato
352 \texttt{TIME\_WAIT} che a seconda delle implementazioni può variare fra 1 a 4
353 minuti.  Lo stato \texttt{TIME\_WAIT} viene utilizzato dal protocollo per due
354 motivi principali:
355 \begin{enumerate}
356 \item implementare in maniera affidabile la terminazione della connessione
357   in entrambe le direzioni.
358 \item consentire l'eliminazione dei segmenti duplicati dalla rete. 
359 \end{enumerate}
360
361 Il punto è che entrambe le ragioni sono importanti, anche se spesso si fa
362 riferimento solo alla prima; ma è solo se si tiene conto della seconda che si
363 capisce il perché della scelta di un tempo pari al doppio della MSL come
364 durata di questo stato.
365
366 Il primo dei due motivi precedenti si può capire tornando a
367 \figref{fig:TCP_conn_example}: assumendo che l'ultimo ACK della sequenza
368 (quello del capo che ha eseguito la chiusura attiva) vanga perso, chi esegue
369 la chiusura passiva non ricevendo risposta rimanderà un ulteriore FIN, per
370 questo motivo chi esegue la chiusura attiva deve mantenere lo stato della
371 connessione per essere in grado di reinviare l'ACK e chiuderla correttamente.
372 Se non fosse così la risposta sarebbe un RST (un altro tipo si segmento) che
373 verrebbe interpretato come un errore.
374
375 Se il TCP deve poter chiudere in maniera pulita entrambe le direzioni della
376 connessione allora deve essere in grado di affrontare la perdita di uno
377 qualunque dei quattro segmenti che costituiscono la chiusura. Per questo
378 motivo un socket deve rimanere attivo nello stato \texttt{TIME\_WAIT} anche
379 dopo l'invio dell'ultimo ACK, per potere essere in grado di gestirne
380 l'eventuale ritrasmissione, in caso esso venga perduto.
381
382 Il secondo motivo è più complesso da capire, e necessita di una spiegazione
383 degli scenari in cui può accadere che i pacchetti TCP si possano perdere nella
384 rete o restare intrappolati, per poi riemergere in un secondo tempo.
385
386 Il caso più comune in cui questo avviene è quello di anomalie
387 nell'instradamento; può accadere cioè che un router smetta di funzionare o che
388 una connessione fra due router si interrompa. In questo caso i protocolli di
389 instradamento dei pacchetti possono impiegare diverso tempo (anche dell'ordine
390 dei minuti) prima di trovare e stabilire un percorso alternativo per i
391 pacchetti. Nel frattempo possono accadere casi in cui un router manda i
392 pacchetti verso un'altro e quest'ultimo li rispedisce indietro, o li manda ad
393 un terzo router che li rispedisce al primo, si creano cioè dei circoli (i
394 cosiddetti \textit{routing loop}) in cui restano intrappolati i pacchetti.
395
396 Se uno di questi pacchetti intrappolati è un segmento TCP, chi l'ha inviato,
397 non ricevendo un ACK in risposta, provvederà alla ritrasmissione e se nel
398 frattempo sarà stata stabilita una strada alternativa il pacchetto ritrasmesso
399 giungerà a destinazione.
400
401 Ma se dopo un po' di tempo (che non supera il limite dell'MSL, dato che
402 altrimenti verrebbe ecceduto il TTL) l'anomalia viene a cessare, il circolo di
403 instradamento viene spezzato i pacchetti intrappolati potranno essere inviati
404 alla destinazione finale, con la conseguenza di avere dei pacchetti duplicati;
405 questo è un caso che il TCP deve essere in grado di gestire.
406
407 Allora per capire la seconda ragione per l'esistenza dello stato
408 \texttt{TIME\_WAIT} si consideri il caso seguente: si supponga di avere una
409 connessione fra l'IP \texttt{195.110.112.236} porta 1550 e l'IP
410 \texttt{192.84.145.100} porta 22 (affronteremo il significato delle porte
411 nella prossima sezione), che questa venga chiusa e che poco dopo si
412 ristabilisca la stessa connessione fra gli stessi IP sulle stesse porte
413 (quella che viene detta, essendo gli stessi porte e numeri IP, una nuova
414 \textsl{incarnazione} della connessione precedente); in questo caso ci si
415 potrebbe trovare con dei pacchetti duplicati relativi alla precedente
416 connessione che riappaiono nella nuova.
417
418 Ma fintanto che il socket non è chiuso una nuova incarnazione non può essere
419 creata: per questo un socket TCP resta sempre nello stato \texttt{TIME\_WAIT}
420 per un periodo di 2MSL, in modo da attendere MSL secondi per essere sicuri che
421 tutti i pacchetti duplicati in arrivo siano stati ricevuti (e scartati) o che
422 nel frattempo siano stati eliminati dalla rete, e altri MSL secondi per essere
423 sicuri che lo stesso avvenga per le risposte nella direzione opposta.
424
425 In questo modo, prima che venga creata una nuova connessione, il protocollo
426 TCP si assicura che tutti gli eventuali segmenti residui di una precedente
427 connessione, che potrebbero causare disturbi, siano stati eliminati dalla
428 rete.
429
430
431 \subsection{I numeri di porta}
432 \label{sec:TCP_port_num}
433
434 In un ambiente multitasking in un dato momento più processi devono poter usare
435 sia UDP che TCP, e ci devono poter essere più connessioni in contemporanea.
436 Per poter tenere distinte le diverse connessioni entrambi i protocolli usano i
437 \textsl{numeri di porta}, che fanno parte, come si può vedere in
438 \secref{sec:sock_sa_ipv4} e \secref{sec:sock_sa_ipv6} pure delle strutture
439 degli indirizzi del socket.
440
441 Quando un client contatta un server deve poter identificare con quale dei vari
442 possibili server attivi intende parlare. Sia TCP che UDP definiscono un gruppo
443 di \textsl{porte conosciute} (le cosiddette \textit{well-known port}) che
444 identificano una serie di servizi noti (ad esempio la porta 22 identifica il
445 servizio SSH) effettuati da appositi server che rispondono alle connessioni
446 verso tali porte.
447
448 D'altra parte un client non ha necessità di usare un numero di porta
449 specifico, per cui in genere vengono usate le cosiddette \textsl{porte
450   effimere} (o \textit{ephemeral ports}) cioè porte a cui non è assegnato
451 nessun servizio noto e che vengono assegnate automaticamente dal kernel alla
452 creazione della connessione. Queste sono dette effimere in quanto vengono
453 usate solo per la durata della connessione, e l'unico requisito che deve
454 essere soddisfatto è che ognuna di esse sia assegnata in maniera univoca.
455
456 La lista delle porte conosciute è definita
457 dall'\href{http://www.ietf.org/rfc/rfc1700.txt}{RFC~1700} che contiene
458 l'elenco delle porte assegnate dalla IANA (la \textit{Internet Assigned Number
459   Authority}) ma l'elenco viene costantemente aggiornato e pubblicato su
460 internet (una versione aggiornata si può trovare all'indirizzo
461 \texttt{ftp://ftp.isi.edu/in-notes/iana/assignements/port-numbers}); inoltre
462 in un sistema unix-like un analogo elenco viene mantenuto nel file
463 \file{/etc/services}, con la corrispondenza fra i vari numeri di porta ed il
464 nome simbolico del servizio.  I numeri sono divisi in tre intervalli:
465
466 \begin{enumerate}
467 \item \textsl{le porte conosciute}. I numeri da 0 a 1023. Queste sono
468   controllate e assegnate dalla IANA. Se è possibile la stessa porta è
469   assegnata allo stesso servizio sia su UDP che su TCP (ad esempio la porta 22
470   è assegnata a SSH su entrambi i protocolli, anche se viene usata solo dal
471   TCP).
472   
473 \item \textsl{le porte registrate}. I numeri da 1024 a 49151. Queste porte non
474   sono controllate dalla IANA, che però registra ed elenca chi usa queste
475   porte come servizio agli utenti. Come per le precedenti si assegna una porta
476   ad un servizio sia per TCP che UDP anche se poi il servizio è implementato
477   solo su TCP. Ad esempio X Window usa le porte TCP e UDP dal 6000 al 6063
478   anche se il protocollo è implementato solo tramite TCP.
479   
480 \item \textsl{le porte private} o \textsl{dinamiche}. I numeri da 49152 a
481   65535. La IANA non dice nulla riguardo a queste porte che pertanto
482   sono i candidati naturali ad essere usate come porte effimere.
483 \end{enumerate}
484
485 In realtà rispetto a quanto indicato
486 nell'\href{http://www.ietf.org/rfc/rfc1700.txt}{RFC~1700} i vari sistemi hanno
487 fatto scelte diverse per le porte effimere, in particolare in
488 \figref{fig:TCP_port_alloc} sono riportate quelle di BSD e Linux.  Nel caso di
489 Linux poi la scelta fra i due intervalli possibili viene fatta dinamicamente a
490 seconda della memoria a disposizione del kernel per gestire le relative
491 tabelle.
492
493 \begin{figure}[!htb]
494   \centering
495   \includegraphics[width=15cm]{img/port_alloc}  
496   \caption{Allocazione dei numeri di porta.}
497   \label{fig:TCP_port_alloc}
498 \end{figure}
499
500 I sistemi Unix hanno inoltre il concetto di \textsl{porte riservate} (che
501 corrispondono alle porte con numero minore di 1024 e coincidono quindi con le
502 porte conosciute). La loro caratteristica è che possono essere assegnate a un
503 socket solo da un processo con i privilegi di amministratore, per far si che
504 solo l'amministratore possa allocare queste porte per far partire i relativi
505 servizi.
506
507 Si tenga conto poi che ci sono alcuni client, in particolare \cmd{rsh} e
508 \cmd{rlogin}, che richiedono una connessione su una porta riservata anche dal
509 lato client come parte dell'autenticazione, contando appunto sul fatto che
510 solo l'amministratore può usare queste porte. Data l'assoluta inconsistenza in
511 termini di sicurezza di un tale metodo, al giorno d'oggi esso è in completo
512 disuso.
513
514 Data una connessione TCP si suole chiamare \textit{socket pair}\footnote{da
515   non confondere con la coppia di socket della omonima funzione
516   \func{socketpair} che fanno riferimento ad una coppia di socket sulla stessa
517   macchina, non ai capi di una connessione TCP.} la combinazione dei quattro
518 numeri che definiscono i due capi della connessione e cioè l'indirizzo IP
519 locale e la porta TCP locale, e l'indirizzo IP remoto e la porta TCP remota.
520 Questa combinazione, che scriveremo usando una notazione del tipo
521 (\texttt{195.110.112.152:22}, \texttt{192.84.146.100:20100}), identifica
522 univocamente una connessione su internet.  Questo concetto viene di solito
523 esteso anche a UDP, benché in questo caso non abbia senso parlare di
524 connessione. L'utilizzo del programma \cmd{netstat} permette di visualizzare
525 queste informazioni nei campi \textit{Local Address} e \textit{Foreing
526   Address}.
527
528
529 \subsection{Le porte ed il modello client/server}
530 \label{sec:TCP_port_cliserv}
531
532 Per capire meglio l'uso delle porte e come vengono utilizzate quando si ha a
533 che fare con un'applicazione client/server (come quelle che descriveremo in
534 \secref{sec:TCP_daytime_application} e \secref{sec:TCP_echo_application})
535 esamineremo cosa accade con le connessioni nel caso di un server TCP che deve
536 gestire connessioni multiple.
537
538 Se eseguiamo un \cmd{netstat} su una macchina di prova (il cui indirizzo sia
539 \texttt{195.110.112.152}) potremo avere un risultato del tipo:
540 \begin{verbatim}
541 Active Internet connections (servers and established)
542 Proto Recv-Q Send-Q Local Address           Foreign Address         State      
543 tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
544 tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN
545 tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN
546 \end{verbatim}
547 essendo presenti e attivi un server SSH, un server di posta e un DNS per il
548 caching locale.
549
550 Questo ci mostra ad esempio che il server SSH ha compiuto un'apertura passiva,
551 mettendosi in ascolto sulla porta 22 riservata a questo servizio, e che si è
552 posto in ascolto per connessioni provenienti da uno qualunque degli indirizzi
553 associati alle interfacce locali. La notazione \texttt{0.0.0.0} usata da
554 \cmd{netstat} è equivalente all'asterisco utilizzato per il numero di porta,
555 indica il valore generico, e corrisponde al valore \const{INADDR\_ANY}
556 definito in \file{arpa/inet.h} (vedi \ref{tab:TCP_ipv4_addr}).
557
558 Inoltre si noti come la porta e l'indirizzo di ogni eventuale connessione
559 esterna non sono specificati; in questo caso la \textit{socket pair} associata
560 al socket potrebbe essere indicata come (\texttt{*:22}, \texttt{*:*}), usando
561 anche per gli indirizzi l'asterisco come carattere che indica il valore
562 generico.
563
564 Dato che in genere una macchina è associata ad un solo indirizzo IP, ci si può
565 chiedere che senso abbia l'utilizzo dell'indirizzo generico per specificare
566 l'indirizzo locale; ma a parte il caso di macchine che hanno più di un
567 indirizzo IP (il cosiddetto \textit{multihoming}) esiste sempre anche
568 l'indirizzo di loopback, per cui con l'uso dell'indirizzo generico si possono
569 accettare connessioni indirizzate verso uno qualunque degli indirizzi IP
570 presenti. Ma, come si può vedere nell'esempio con il DNS che è in ascolto
571 sulla porta 53, è possibile anche restringere l'accesso ad uno specifico
572 indirizzo, cosa che nel caso è fatta accettando solo connessioni che arrivino
573 sull'interfaccia di loopback.
574
575 Una volta che ci si vorrà collegare a questa macchina da un'altra, per esempio
576 quella con l'indirizzo \texttt{192.84.146.100}, si dovrà lanciare su
577 quest'ultima un client \cmd{ssh} per creare una connessione, e il kernel gli
578 assocerà una porta effimera (ad esempio la 21100), per cui la connessione sarà
579 espressa dalla socket pair (\texttt{192.84.146.100:21100},
580 \texttt{195.110.112.152:22}).
581
582 Alla ricezione della richiesta dal client il server creerà un processo figlio
583 per gestire la connessione, se a questo punto eseguiamo nuovamente il
584 programma \cmd{netstat} otteniamo come risultato:
585 \begin{verbatim}
586 Active Internet connections (servers and established)
587 Proto Recv-Q Send-Q Local Address           Foreign Address         State      
588 tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
589 tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN
590 tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN
591 tcp        0      0 195.110.112.152:22      192.84.146.100:21100    ESTABLISHED
592 \end{verbatim}
593
594 Come si può notare il server è ancora in ascolto sulla porta 22, però adesso
595 c'è un nuovo socket (con lo stato \texttt{ESTABLISHED}) che utilizza anch'esso
596 la porta 22, ed ha specificato l'indirizzo locale, questo è il socket con cui
597 il processo figlio gestisce la connessione mentre il padre resta in ascolto
598 sul socket originale.
599
600 Se a questo punto lanciamo un'altra volta il client \cmd{ssh} per una seconda
601 connessione quello che otterremo usando \cmd{netstat} sarà qualcosa del
602 genere:
603 \begin{verbatim}
604 Active Internet connections (servers and established)
605 Proto Recv-Q Send-Q Local Address           Foreign Address         State      
606 tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
607 tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN
608 tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN
609 tcp        0      0 195.110.112.152:22      192.84.146.100:21100    ESTABLISHED
610 tcp        0      0 195.110.112.152:22      192.84.146.100:21101    ESTABLISHED
611 \end{verbatim}
612 cioè il client effettuerà la connessione usando un'altra porta effimera: con
613 questa sarà aperta la connessione, ed il server creerà un'altro processo
614 figlio per gestirla.
615
616 Tutto ciò mostra come il TCP, per poter gestire le connessioni con un server
617 concorrente, non può suddividere i pacchetti solo sulla base della porta di
618 destinazione, ma deve usare tutta l'informazione contenuta nella socket pair,
619 compresa la porta dell'indirizzo remoto.  E se andassimo a vedere quali sono i
620 processi\footnote{ad esempio con il comando \cmd{fuser}, o con \cmd{lsof}.} a
621 cui fanno riferimento i vari socket vedremmo che i pacchetti che arrivano
622 dalla porta remota 21100 vanno al primo figlio e quelli che arrivano alla
623 porta 21101 al secondo.
624
625
626 \section{Le funzioni di base per la gestione dei socket}
627 \label{sec:TCP_functions}
628
629 In questa sezione descriveremo in maggior dettaglio le varie funzioni che
630 vengono usate per la gestione di base dei socket TCP, non torneremo però sulla
631 funzione \func{socket}, che è già stata esaminata accuratamente nel capitolo
632 precedente in \secref{sec:sock_socket}.
633
634
635 \subsection{La funzione \func{bind}}
636 \label{sec:TCP_func_bind}
637
638 La funzione \funcd{bind} assegna un indirizzo locale ad un socket. È usata
639 cioè per specificare la prima parte dalla socket pair. Viene usata sul lato
640 server per specificare la porta (e gli eventuali indirizzi locali) su cui poi
641 ci si porrà in ascolto. Il prototipo della funzione è il seguente:
642 \begin{prototype}{sys/socket.h}
643 {int bind(int sockfd, const struct sockaddr *serv\_addr, socklen\_t addrlen)}
644   
645   Assegna un indirizzo ad un socket.
646   
647   \bodydesc{La funzione restituisce 0 in caso di successo e -1 per un errore;
648     in caso di errore la variabile \var{errno} viene impostata secondo i
649     seguenti codici di errore:
650   \begin{errlist}
651   \item[\errcode{EBADF}] il file descriptor non è valido.
652   \item[\errcode{EINVAL}] il socket ha già un indirizzo assegnato.
653   \item[\errcode{ENOTSOCK}] il file descriptor non è associato ad un socket.
654   \item[\errcode{EACCES}] si è cercato di usare una porta riservata senza
655     sufficienti privilegi.
656   \item[\errcode{EADDRNOTAVAIL}] Il tipo di indirizzo specificato non è
657     disponibile.
658   \item[\errcode{EADDRINUSE}] qualche altro socket sta già usando l'indirizzo.
659   \end{errlist}
660   ed anche \errval{EFAULT} e per i socket di tipo \const{AF\_UNIX},
661   \errval{ENOTDIR}, \errval{ENOENT}, \errval{ENOMEM}, \errval{ELOOP},
662   \errval{ENOSR} e \errval{EROFS}.}
663 \end{prototype}
664
665 Il primo argomento è un file descriptor ottenuto da una precedente chiamata a
666 \func{socket}, mentre il secondo e terzo argomento sono rispettivamente
667 l'indirizzo (locale) del socket e la dimensione della struttura che lo
668 contiene, secondo quanto già trattato in \secref{sec:sock_sockaddr}. 
669
670 Con i socket TCP la chiamata \func{bind} permette di specificare l'indirizzo,
671 la porta, entrambi o nessuno dei due. In genere i server utilizzano una porta
672 nota che assegnano all'avvio, se questo non viene fatto è il kernel a
673 scegliere una porta effimera quando vengono eseguite la funzioni
674 \func{connect} o \func{listen}, ma se questo è normale per il client non lo è
675 per il server\footnote{un'eccezione a tutto ciò sono i server che usano RPC.
676   In questo caso viene fatta assegnare dal kernel una porta effimera che poi
677   viene registrata presso il \textit{portmapper}; quest'ultimo è un altro
678   demone che deve essere contattato dai client per ottenere la porta effimera
679   su cui si trova il server.} che in genere viene identificato dalla porta su
680 cui risponde (l'elenco di queste porte, e dei relativi servizi, è in
681 \file{/etc/services}).
682
683 Con \func{bind} si può assegnare un IP specifico ad un socket, purché questo
684 appartenga ad una interfaccia della macchina.  Per un client TCP questo
685 diventerà l'indirizzo sorgente usato per i tutti i pacchetti inviati sul
686 socket, mentre per un server TCP questo restringerà l'accesso al socket solo
687 alle connessioni che arrivano verso tale indirizzo.
688
689 Normalmente un client non specifica mai l'indirizzo di un socket, ed il kernel
690 sceglie l'indirizzo di origine quando viene effettuata la connessione, sulla
691 base dell'interfaccia usata per trasmettere i pacchetti, (che dipenderà dalle
692 regole di instradamento usate per raggiungere il server).  Se un server non
693 specifica il suo indirizzo locale il kernel userà come indirizzo di origine
694 l'indirizzo di destinazione specificato dal SYN del client.
695
696 Per specificare un indirizzo generico, con IPv4 si usa il valore
697 \const{INADDR\_ANY}, il cui valore, come accennato in
698 \secref{sec:sock_sa_ipv4}, è pari a zero; nell'esempio
699 \figref{fig:TCP_daytime_iter_server_code} si è usata un'assegnazione immediata
700 del tipo: \includecodesnip{listati/serv_addr_sin_addr.c}
701
702 Si noti che si è usato \func{htonl} per assegnare il valore
703 \const{INADDR\_ANY}, anche se, essendo questo nullo, il riordinamento è
704 inutile.  Si tenga presente comunque che tutte le costanti \val{INADDR\_}
705 (riportate in \tabref{tab:TCP_ipv4_addr}) sono definite secondo
706 l'\textit{endianess} della macchina, ed anche se esse possono essere
707 invarianti rispetto all'ordinamento dei bit, è comunque buona norma usare
708 sempre la funzione \func{htonl}.
709
710 \begin{table}[htb]
711   \centering
712   \footnotesize
713   \begin{tabular}[c]{|l|l|}
714     \hline
715     \textbf{Costante} & \textbf{Significato} \\
716     \hline
717     \hline
718     \const{INADDR\_ANY}      & Indirizzo generico (\texttt{0.0.0.0})\\
719     \const{INADDR\_BROADCAST}& Indirizzo di \textit{broadcast}.\\
720     \const{INADDR\_LOOPBACK} & Indirizzo di \textit{loopback}
721                                (\texttt{127.0.0.1}).\\ 
722     \const{INADDR\_NONE}     & Indirizzo errato.\\
723     \hline    
724   \end{tabular}
725   \caption{Costanti di definizione di alcuni indirizzi generici per IPv4.}
726   \label{tab:TCP_ipv4_addr}
727 \end{table}
728
729 L'esempio precedente funziona correttamente con IPv4 poiché che l'indirizzo è
730 rappresentabile anche con un intero a 32 bit; non si può usare lo stesso
731 metodo con IPv6, in cui l'indirizzo deve necessariamente essere specificato
732 con una struttura, perché il linguaggio C non consente l'uso di una struttura
733 costante come operando a destra in una assegnazione.
734
735 Per questo motivo nell'header \file{netinet/in.h} è definita una variabile
736 \const{in6addr\_any} (dichiarata come \direct{extern}, ed inizializzata dal
737 sistema al valore \const{IN6ADRR\_ANY\_INIT}) che permette di effettuare una
738 assegnazione del tipo: \includecodesnip{listati/serv_addr_sin6_addr.c} in
739 maniera analoga si può utilizzare la variabile \const{in6addr\_loopback} per
740 indicare l'indirizzo di \textit{loopback}, che a sua volta viene inizializzata
741 staticamente a \const{IN6ADRR\_LOOPBACK\_INIT}.
742
743
744
745 \subsection{La funzione \func{connect}}
746 \label{sec:TCP_func_connect}
747
748 La funzione \funcd{connect} è usata da un client TCP per stabilire la
749 connessione con un server TCP, il prototipo della funzione è il seguente:
750 \begin{prototype}{sys/socket.h}
751 {int connect(int sockfd, const struct sockaddr *servaddr, socklen\_t addrlen)}
752   
753   Stabilisce una connessione fra due socket.
754   
755   \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
756     errore, nel qual caso \var{errno} assumerà i valori:
757   \begin{errlist}
758   \item[\errcode{ECONNREFUSED}] non c'è nessuno in ascolto sull'indirizzo
759     remoto.
760   \item[\errcode{ETIMEDOUT}] si è avuto timeout durante il tentativo di
761     connessione.
762   \item[\errcode{ENETUNREACH}] la rete non è raggiungibile.
763   \item[\errcode{EINPROGRESS}] il socket è non bloccante (vedi
764     \secref{sec:file_noblocking}) e la connessione non può essere conclusa
765     immediatamente.
766   \item[\errcode{EALREADY}] il socket è non bloccante (vedi
767     \secref{sec:file_noblocking}) e un tentativo precedente di connessione non
768     si è ancora concluso.
769   \item[\errcode{EAGAIN}] non ci sono più porte locali libere. 
770   \item[\errcode{EAFNOSUPPORT}] l'indirizzo non ha una famiglia di indirizzi
771     corretta nel relativo campo.
772   \item[\errcode{EACCES}, \errcode{EPERM}] si è tentato di eseguire una
773     connessione ad un indirizzo broadcast senza che il socket fosse stato
774     abilitato per il broadcast.
775   \end{errlist}
776   altri errori possibili sono: \errval{EFAULT}, \errval{EBADF},
777   \errval{ENOTSOCK}, \errval{EISCONN} e \errval{EADDRINUSE}.}
778 \end{prototype}
779
780 Il primo argomento è un file descriptor ottenuto da una precedente chiamata a
781 \func{socket}, mentre il secondo e terzo argomento sono rispettivamente
782 l'indirizzo e la dimensione della struttura che contiene l'indirizzo del
783 socket, già descritta in \secref{sec:sock_sockaddr}.
784
785 La struttura dell'indirizzo deve essere inizializzata con l'indirizzo IP e il
786 numero di porta del server a cui ci si vuole connettere, come mostrato
787 nell'esempio \secref{sec:TCP_daytime_client}, usando le funzioni illustrate in
788 \secref{sec:sock_addr_func}.
789
790 Nel caso di socket TCP la funzione \func{connect} avvia il \textit{three way
791   handshake}, e ritorna solo quando la connessione è stabilita o si è
792 verificato un errore. Le possibili cause di errore sono molteplici (ed i
793 relativi codici riportati sopra), quelle che però dipendono dalla situazione
794 della rete e non da errori o problemi nella chiamata della funzione sono le
795 seguenti:
796 \begin{enumerate}
797 \item Il client non riceve risposta al SYN: l'errore restituito è
798   \errcode{ETIMEDOUT}. Stevens riporta che BSD invia un primo SYN alla chiamata
799   di \func{connect}, un'altro dopo 6 secondi, un terzo dopo 24 secondi, se
800   dopo 75 secondi non ha ricevuto risposta viene ritornato l'errore. Linux
801   invece ripete l'emissione del SYN ad intervalli di 30 secondi per un numero
802   di volte che può essere stabilito dall'utente sia con una opportuna
803   \func{sysctl} che attraverso il filesystem \file{/proc} scrivendo il valore
804   voluto in \file{/proc/sys/net/ipv4/tcp\_syn\_retries}. Il valore predefinito
805   per la ripetizione dell'invio è di 5 volte, che comporta un timeout dopo
806   circa 180 secondi.
807 %
808 % Le informazioni su tutte le opzioni impostabili via /proc stanno in
809 % Linux/Documentation/networking/ip-sysctl.txt
810 %
811 \item Il client riceve come risposta al SYN un RST significa che non c'è
812   nessun programma in ascolto per la connessione sulla porta specificata (il
813   che vuol dire probabilmente che o si è sbagliato il numero della porta o che
814   non è stato avviato il server), questo è un errore fatale e la funzione
815   ritorna non appena il RST viene ricevuto riportando un errore
816   \errcode{ECONNREFUSED}.
817   
818   Il flag RST sta per \textit{reset} ed è un segmento inviato direttamente
819   dal TCP quando qualcosa non va. Tre condizioni che generano un RST sono:
820   quando arriva un SYN per una porta che non ha nessun server in ascolto,
821   quando il TCP abortisce una connessione in corso, quando TCP riceve un
822   segmento per una connessione che non esiste.
823   
824 \item Il SYN del client provoca l'emissione di un messaggio ICMP di
825   destinazione non raggiungibile. In questo caso dato che il messaggio può
826   essere dovuto ad una condizione transitoria si ripete l'emissione dei SYN
827   come nel caso precedente, fino al timeout, e solo allora si restituisce il
828   codice di errore dovuto al messaggio ICMP, che da luogo ad un
829   \errcode{ENETUNREACH}.
830    
831 \end{enumerate}
832
833 Se si fa riferimento al diagramma degli stati del TCP riportato in
834 \figref{fig:TCP_state_diag} la funzione \func{connect} porta un socket
835 dallo stato \texttt{CLOSED} (lo stato iniziale in cui si trova un socket
836 appena creato) prima allo stato \texttt{SYN\_SENT} e poi, al ricevimento del
837 ACK, nello stato \texttt{ESTABLISHED}. Se invece la connessione fallisce il
838 socket non è più utilizzabile e deve essere chiuso.
839
840 Si noti infine che con la funzione \func{connect} si è specificato solo
841 indirizzo e porta del server, quindi solo una metà della socket pair; essendo
842 questa funzione usata nei client l'altra metà contenente indirizzo e porta
843 locale viene lasciata all'assegnazione automatica del kernel, e non è
844 necessario effettuare una \func{bind}.
845
846
847 \subsection{La funzione \func{listen}}
848 \label{sec:TCP_func_listen}
849
850 La funzione \funcd{listen} serve ad usare un socket in modalità passiva, cioè,
851 come dice il nome, per metterlo in ascolto di eventuali connessioni; in
852 sostanza l'effetto della funzione è di portare il socket dallo stato
853 \texttt{CLOSED} a quello \texttt{LISTEN}. In genere si chiama la funzione in
854 un server dopo le chiamate a \func{socket} e \func{bind} e prima della
855 chiamata ad \func{accept}. Il prototipo della funzione, come definito dalla
856 pagina di manuale, è:
857 \begin{prototype}{sys/socket.h}{int listen(int sockfd, int backlog)}
858   Pone un socket in attesa di una connessione.
859   
860   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
861     errore. I codici di errore restituiti in \var{errno} sono i seguenti:
862   \begin{errlist}
863   \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor
864     valido.
865   \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket.
866   \item[\errcode{EOPNOTSUPP}] il socket è di un tipo che non supporta questa
867     operazione.
868   \end{errlist}}
869 \end{prototype}
870
871 La funzione pone il socket specificato da \param{sockfd} in modalità passiva e
872 predispone una coda per le connessioni in arrivo di lunghezza pari a
873 \param{backlog}. La funzione si può applicare solo a socket di tipo
874 \const{SOCK\_STREAM} o \const{SOCK\_SEQPACKET}.
875
876 L'argomento \param{backlog} indica il numero massimo di connessioni pendenti
877 accettate; se esso viene ecceduto il client al momento della richiesta della
878 connessione riceverà un errore di tipo \errcode{ECONNREFUSED}, o se il
879 protocollo, come accade nel caso del TCP, supporta la ritrasmissione, la
880 richiesta sarà ignorata in modo che la connessione possa venire ritentata.
881
882 Per capire meglio il significato di tutto ciò occorre approfondire la modalità
883 con cui il kernel tratta le connessioni in arrivo. Per ogni socket in ascolto
884 infatti vengono mantenute due code:
885 \begin{enumerate}
886 \item La coda delle connessioni incomplete (\textit{incomplete connection
887     queue} che contiene un riferimento per ciascun socket per il quale è
888   arrivato un SYN ma il \textit{three way handshake} non si è ancora concluso.
889   Questi socket sono tutti nello stato \texttt{SYN\_RECV}.
890 \item La coda delle connessioni complete (\textit{complete connection queue}
891   che contiene un ingresso per ciascun socket per il quale il three way
892   handshake è stato completato ma ancora \func{accept} non è ritornata.
893   Questi socket sono tutti nello stato \texttt{ESTABLISHED}.
894 \end{enumerate}
895
896 Lo schema di funzionamento è descritto in \figref{fig:TCP_listen_backlog}:
897 quando arriva un SYN da un client il server crea una nuova voce nella coda
898 delle connessioni incomplete, e poi risponde con il SYN$+$ACK. La voce resterà
899 nella coda delle connessioni incomplete fino al ricevimento dell'ACK dal
900 client o fino ad un timeout. Nel caso di completamento del three way handshake
901 la voce viene spostata nella coda delle connessioni complete.  Quando il
902 processo chiama la funzione \func{accept} (vedi \secref{sec:TCP_func_accept})
903 la prima voce nella coda delle connessioni complete è passata al programma, o,
904 se la coda è vuota, il processo viene posto in attesa e risvegliato all'arrivo
905 della prima connessione completa.
906
907 \begin{figure}[htb]
908   \centering
909   \includegraphics[width=11cm]{img/tcp_listen_backlog}  
910   \caption{Schema di funzionamento delle code delle connessioni complete ed
911     incomplete.}
912   \label{fig:TCP_listen_backlog}
913 \end{figure}
914
915 Storicamente il valore del parametro \param{backlog} era corrispondente al
916 massimo valore della somma del numero di voci possibili per ciascuna delle due
917 code. Stevens in \cite{UNP1} riporta che BSD ha sempre applicato un fattore di
918 1.5 a detto valore, e fornisce una tabella con i risultati ottenuti con vari
919 kernel, compreso Linux 2.0, che mostrano le differenze fra diverse
920 implementazioni.
921
922 In Linux il significato di questo valore è cambiato a partire dal kernel 2.2
923 per prevenire l'attacco chiamato \textit{syn flood}. Questo si basa
924 sull'emissione da parte dell'attaccante di un grande numero di pacchetti SYN
925 indirizzati verso una porta, forgiati con indirizzo IP fasullo\footnote{con la
926   tecnica che viene detta \textit{ip spoofing}.} così che i SYN$+$ACK vanno
927 perduti e la coda delle connessioni incomplete viene saturata, impedendo di
928 fatto ulteriori connessioni.
929
930 Per ovviare a questo il significato del \param{backlog} è stato cambiato a
931 indicare la lunghezza della coda delle connessioni complete. La lunghezza
932 della coda delle connessioni incomplete può essere ancora controllata usando
933 la funzione \func{sysctl} con il parametro \const{NET\_TCP\_MAX\_SYN\_BACKLOG}
934 o scrivendola direttamente in
935 \file{/proc/sys/net/ipv4/tcp\_max\_syn\_backlog}.  Quando si attiva la
936 protezione dei syncookies però (con l'opzione da compilare nel kernel e da
937 attivare usando \file{/proc/sys/net/ipv4/tcp\_syncookies}) questo valore viene
938 ignorato e non esiste più un valore massimo.  In ogni caso in Linux il valore
939 di \param{backlog} viene troncato ad un massimo di \const{SOMAXCONN} se è
940 superiore a detta costante (che di default vale 128).
941
942 La scelta storica per il valore di questo parametro era di 5, e alcuni vecchi
943 kernel non supportavano neanche valori superiori, ma la situazione corrente è
944 molto cambiata per via della presenza di server web che devono gestire un gran
945 numero di connessioni per cui un tale valore non è più adeguato. Non esiste
946 comunque una risposta univoca per la scelta del valore, per questo non
947 conviene specificarlo con una costante (il cui cambiamento richiederebbe la
948 ricompilazione del server) ma usare piuttosto una variabile di ambiente (vedi
949 \secref{sec:proc_environ}).
950
951 Stevens tratta accuratamente questo argomento in \cite{UNP1}, con esempi presi
952 da casi reali su web server, ed in particolare evidenzia come non sia più vero
953 che il compito principale della coda sia quello di gestire il caso in cui il
954 server è occupato fra chiamate successive alla \func{accept} (per cui la coda
955 più occupata sarebbe quella delle connessioni completate), ma piuttosto quello
956 di gestire la presenza di un gran numero di SYN in attesa di concludere il
957 three way handshake.
958
959 Infine va messo in evidenza che, nel caso di socket TCP, quando un SYN arriva
960 con tutte le code piene, il pacchetto deve essere ignorato. Questo perché la
961 condizione in cui le code sono piene è ovviamente transitoria, per cui se il
962 client ritrasmette il SYN è probabile che passato un po' di tempo possa
963 trovare nella coda lo spazio per una nuova connessione. Se invece si
964 rispondesse con un RST, per indicare l'impossibilità di effettuare la
965 connessione, la chiamata a \func{connect} nel client ritornerebbe con una
966 condizione di errore, costringendo a inserire nell'applicazione la gestione
967 dei tentativi di riconnessione, che invece può essere effettuata in maniera
968 trasparente dal protocollo TCP.
969
970
971 \subsection{La funzione \func{accept}}
972 \label{sec:TCP_func_accept}
973
974 La funzione \funcd{accept} è chiamata da un server per gestire la connessione
975 una volta che sia stato completato il \textit{three way handshake}, la
976 funzione restituisce un nuovo socket descriptor su cui si potrà operare per
977 effettuare la comunicazione. Se non ci sono connessioni completate il processo
978 viene messo in attesa. Il prototipo della funzione è il seguente:
979 \begin{prototype}{sys/socket.h}
980 {int accept(int sockfd, struct sockaddr *addr, socklen\_t *addrlen)} 
981  
982   Accetta una connessione sul socket specificato.
983   
984   \bodydesc{La funzione restituisce un numero di socket descriptor positivo in
985     caso di successo e -1 in caso di errore, nel qual caso \var{errno} viene
986     impostata ai seguenti valori:
987
988   \begin{errlist}
989   \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor
990     valido.
991   \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket.
992   \item[\errcode{EOPNOTSUPP}] il socket è di un tipo che non supporta questa
993     operazione.
994   \item[\errcode{EAGAIN} o \errcode{EWOULDBLOCK}] il socket è stato impostato
995     come non bloccante (vedi \secref{sec:file_noblocking}), e non ci sono
996     connessioni in attesa di essere accettate.
997   \item[\errcode{EPERM}] Le regole del firewall non consentono la connessione.
998   \item[\errcode{ENOBUFS}, \errcode{ENOMEM}] questo spesso significa che
999     l'allocazione della memoria è limitata dai limiti sui buffer dei socket,
1000     non dalla memoria di sistema.
1001   \item[\errcode{EINTR}] La funzione è stata interrotta da un segnale.
1002   \end{errlist}
1003   Inoltre possono essere restituiti gli errori di rete relativi al nuovo
1004   socket, diversi a secondo del protocollo, come: \errval{EMFILE},
1005   \errval{EINVAL}, \errval{ENOSR}, \errval{ENOBUFS}, \errval{EFAULT},
1006   \errval{EPERM}, \errval{ECONNABORTED}, \errval{ESOCKTNOSUPPORT},
1007   \errval{EPROTONOSUPPORT}, \errval{ETIMEDOUT}, \errval{ERESTARTSYS}.}
1008 \end{prototype}
1009
1010 La funzione estrae la prima connessione relativa al socket \param{sockfd} in
1011 attesa sulla coda delle connessioni complete, che associa ad nuovo socket con
1012 le stesse caratteristiche di \param{sockfd}.  Il socket originale non viene
1013 toccato e resta nello stato di \texttt{LISTEN}, mentre il nuovo socket viene
1014 posto nello stato \texttt{ESTABLISHED}. Nella struttura \param{addr} e nella
1015 variabile \param{addrlen} vengono restituiti indirizzo e relativa lunghezza
1016 del client che si è connesso.
1017
1018 I due argomenti \param{addr} e \param{addrlen} (si noti che quest'ultimo è
1019 passato per indirizzo per avere indietro il valore) sono usati per ottenere
1020 l'indirizzo del client da cui proviene la connessione. Prima della chiamata
1021 \param{addrlen} deve essere inizializzato alle dimensioni della struttura il
1022 cui indirizzo è passato come argomento in \param{addr}; al ritorno della
1023 funzione \param{addrlen} conterrà il numero di byte scritti dentro
1024 \param{addr}. Se questa informazione non interessa basterà inizializzare a
1025 \val{NULL} detti puntatori.
1026
1027 Se la funzione ha successo restituisce il descrittore di un nuovo socket
1028 creato dal kernel (detto \textit{connected socket}) a cui viene associata la
1029 prima connessione completa (estratta dalla relativa coda, vedi
1030 \secref{sec:TCP_func_listen}) che il client ha effettuato verso il socket
1031 \param{sockfd}. Quest'ultimo (detto \textit{listening socket}) è quello creato
1032 all'inizio e messo in ascolto con \func{listen}, e non viene toccato dalla
1033 funzione.  Se non ci sono connessioni pendenti da accettare la funzione mette
1034 in attesa il processo\footnote{a meno che non si sia impostato il socket per
1035   essere non bloccante (vedi \secref{sec:file_noblocking}), nel qual caso
1036   ritorna con l'errore \errcode{EAGAIN}.  Torneremo su questa modalità di
1037   operazione in \secref{sec:xxx_sock_noblock}.}  fintanto che non ne arriva
1038 una.
1039
1040 La funzione può essere usata solo con socket che supportino la connessione
1041 (cioè di tipo \const{SOCK\_STREAM}, \const{SOCK\_SEQPACKET} o
1042 \const{SOCK\_RDM}). Per alcuni protocolli che richiedono una conferma
1043 esplicita della connessione,\footnote{attualmente in Linux solo DECnet ha
1044   questo comportamento.} la funzione opera solo l'estrazione dalla coda delle
1045 connessioni, la conferma della connessione viene eseguita implicitamente dalla
1046 prima chiamata ad una \func{read} o una \func{write}, mentre il rifiuto della
1047 connessione viene eseguito con la funzione \func{close}.
1048
1049 È da chiarire che Linux presenta un comportamento diverso nella gestione degli
1050 errori rispetto ad altre implementazioni dei socket BSD, infatti la funzione
1051 \func{accept} passa gli errori di rete pendenti sul nuovo socket come codici
1052 di errore per \func{accept}, per cui l'applicazione deve tenerne conto ed
1053 eventualmente ripetere la chiamata alla funzione come per l'errore di
1054 \errcode{EAGAIN} (torneremo su questo in \secref{sec:TCP_echo_critical}).
1055 Un'altra differenza con BSD è che la funzione non fa ereditare al nuovo socket
1056 i flag del socket originale, come \const{O\_NONBLOCK},\footnote{ed in generale
1057   tutti quelli che si possono impostare con \func{fcntl}, vedi
1058   \secref{sec:file_fcntl}.} che devono essere rispecificati ogni volta. Tutto
1059 questo deve essere tenuto in conto se si devono scrivere programmi portabili.
1060
1061 Il meccanismo di funzionamento di \func{accept} è essenziale per capire il
1062 funzionamento di un server: in generale infatti c'è sempre un solo socket in
1063 ascolto, detto per questo \textit{listening socket}, che resta per tutto il
1064 tempo nello stato \texttt{LISTEN}, mentre le connessioni vengono gestite dai
1065 nuovi socket, detti \textit{connected socket}, ritornati da \func{accept}, che
1066 si trovano automaticamente nello stato \texttt{ESTABLISHED}, e vengono
1067 utilizzati per lo scambio dei dati, che avviene su di essi, fino alla chiusura
1068 della connessione.  Si può riconoscere questo schema anche nell'esempio
1069 elementare di \figref{fig:TCP_daytime_iter_server_code}, dove per ogni
1070 connessione il socket creato da \func{accept} viene chiuso dopo l'invio dei
1071 dati.
1072
1073
1074 \subsection{Le funzioni \func{getsockname} e \func{getpeername}}
1075 \label{sec:TCP_get_names}
1076
1077 Oltre a tutte quelle viste finora, dedicate all'utilizzo dei socket, esistono
1078 alcune funzioni ausiliarie che possono essere usate per recuperare alcune
1079 informazioni relative ai socket ed alle connessioni ad essi associate. Le due
1080 funzioni più elementari sono queste, che vengono usate per ottenere i dati
1081 relativi alla socket pair associata ad un certo socket.
1082
1083 La prima funzione è \funcd{getsockname} e serve ad ottenere l'indirizzo locale
1084 associato ad un socket; il suo prototipo è:
1085 \begin{prototype}{sys/socket.h}
1086   {int getsockname(int sockfd, struct sockaddr * name, socklen\_t * namelen)}
1087   Legge l'indirizzo locale di un socket.
1088
1089 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
1090   errore. I codici di errore restituiti in \var{errno} sono i seguenti:
1091   \begin{errlist}
1092   \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor
1093     valido.
1094   \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket.
1095   \item[\errcode{ENOBUFS}] non ci sono risorse sufficienti nel sistema per
1096     eseguire l'operazione.
1097   \item[\errcode{EFAULT}] l'indirizzo \param{name} non è valido.
1098   \end{errlist}}
1099 \end{prototype}
1100
1101 La funzione restituisce la struttura degli indirizzi del socket \param{sockfd}
1102 nella struttura indicata dal puntatore \param{name} la cui lunghezza è
1103 specificata tramite l'argomento \param{namlen}. Quest'ultimo viene passato
1104 come indirizzo per avere indietro anche il numero di byte effettivamente
1105 scritti nella struttura puntata da \param{name}. Si tenga presente che se si è
1106 utilizzato un buffer troppo piccolo per \param{name} l'indirizzo risulterà
1107 troncato.
1108
1109 La funzione si usa tutte le volte che si vuole avere l'indirizzo locale di un
1110 socket; ad esempio può essere usata da un client (che usualmente non chiama
1111 \func{bind}) per ottenere numero IP e porta locale associati al socket
1112 restituito da una \func{connect}, o da un server che ha chiamato \func{bind}
1113 su un socket usando 0 come porta locale per ottenere il numero di porta
1114 effimera assegnato dal kernel.
1115
1116 Inoltre quando un server esegue una \func{bind} su un indirizzo generico, se
1117 chiamata dopo il completamento di una connessione sul socket restituito da
1118 \func{accept}, restituisce l'indirizzo locale che il kernel ha assegnato a
1119 quella connessione.
1120
1121 Tutte le volte che si vuole avere l'indirizzo remoto di un socket si usa la
1122 funzione \funcd{getpeername}, il cui prototipo è:
1123 \begin{prototype}{sys/socket.h}
1124   {int getpeername(int sockfd, struct sockaddr * name, socklen\_t * namelen)}
1125   Legge l'indirizzo remoto di un socket.
1126   
1127   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
1128     errore. I codici di errore restituiti in \var{errno} sono i seguenti:
1129   \begin{errlist}
1130   \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor
1131     valido.
1132   \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket.
1133   \item[\errcode{ENOTCONN}] il socket non è connesso.
1134   \item[\errcode{ENOBUFS}] non ci sono risorse sufficienti nel sistema per
1135     eseguire l'operazione.
1136   \item[\errcode{EFAULT}] l'argomento \param{name} punta al di fuori dello
1137     spazio di indirizzi del processo.
1138   \end{errlist}}
1139 \end{prototype}
1140
1141 La funzione è identica a \func{getsockname}, ed usa la stessa sintassi, ma
1142 restituisce l'indirizzo remoto del socket, cioè quello associato all'altro
1143 capo della connessione.  Ci si può chiedere a cosa serva questa funzione dato
1144 che dal lato client l'indirizzo remoto è sempre noto quando si esegue la
1145 \func{connect} mentre dal lato server si possono usare, come vedremo in
1146 \figref{fig:TCP_daytime_cunc_server_code}, i valori di ritorno di
1147 \func{accept}.
1148
1149 Il fatto è che in generale quest'ultimo caso non è sempre possibile.  In
1150 particolare questo avviene quando il server, invece di gestire la connessione
1151 direttamente in un processo figlio, come vedremo nell'esempio di server
1152 concorrente di \secref{sec:TCP_daytime_cunc_server}, lancia per ciascuna
1153 connessione un altro programma, usando \func{exec}.\footnote{questa ad esempio
1154   è la modalità con cui opera il \textsl{super-server} \cmd{inetd}, che può
1155   gestire tutta una serie di servizi diversi, eseguendo su ogni connessione
1156   ricevuta sulle porte tenute sotto controllo, il relativo server.}
1157
1158 In questo caso benché il processo figlio abbia una immagine della memoria che
1159 è copia di quella del processo padre (e contiene quindi anche la struttura
1160 ritornata da \func{accept}), all'esecuzione di \func{exec} verrà caricata in
1161 memoria l'immagine del programma eseguito, che a questo punto perde ogni
1162 riferimento ai valori tornati da \func{accept}.  Il socket descriptor però
1163 resta aperto, e se si è seguita una opportuna convenzione per rendere noto al
1164 programma eseguito qual'è il socket connesso, \footnote{ad esempio il solito
1165   \cmd{inetd} fa sempre in modo che i file descriptor 0, 1 e 2 corrispondano
1166   al socket connesso.} quest'ultimo potrà usare la funzione \func{getpeername}
1167 per determinare l'indirizzo remoto del client.
1168
1169 Infine è da chiarire (si legga la pagina di manuale) che, come per
1170 \func{accept}, il terzo parametro, che è specificato dallo standard POSIX.1g
1171 come di tipo \code{socklen\_t *} in realtà deve sempre corrispondere ad un
1172 \ctyp{int *} come prima dello standard perché tutte le implementazioni dei
1173 socket BSD fanno questa assunzione.
1174
1175
1176 \subsection{La funzione \func{close}}
1177 \label{sec:TCP_func_close}
1178
1179 La funzione standard Unix \func{close} (vedi \secref{sec:file_close}) che si
1180 usa sui file può essere usata con lo stesso effetto anche sui file descriptor
1181 associati ad un socket.
1182
1183 L'azione di questa funzione quando applicata a socket è di marcarlo come
1184 chiuso e ritornare immediatamente al processo. Una volta chiamata il socket
1185 descriptor non è più utilizzabile dal processo e non può essere usato come
1186 argomento per una \func{write} o una \func{read} (anche se l'altro capo della
1187 connessione non avesse chiuso la sua parte).  Il kernel invierà comunque tutti
1188 i dati che ha in coda prima di iniziare la sequenza di chiusura.
1189
1190 Vedremo più avanti in \secref{sec:TCP_so_linger} come è possibile cambiare
1191 questo comportamento, e cosa deve essere fatto perché il processo possa
1192 assicurarsi che l'altro capo abbia ricevuto tutti i dati.
1193
1194 Come per tutti i file descriptor anche per i socket viene mantenuto un numero
1195 di riferimenti, per cui se più di un processo ha lo stesso socket aperto
1196 l'emissione del FIN e la sequenza di chiusura di TCP non viene innescata
1197 fintanto che il numero di riferimenti non si annulla, questo si applica, come
1198 visto in \secref{sec:file_sharing}, sia ai file descriptor duplicati che a
1199 quelli ereditati dagli eventuali processi figli, ed è il comportamento che ci
1200 si aspetta in una qualunque applicazione client/server.
1201
1202 Per attivare immediatamente l'emissione del FIN e la sequenza di chiusura
1203 descritta in \secref{sec:TCP_conn_term}, si può invece usare la funzione
1204 \func{shutdown} su cui torneremo in seguito (vedi \secref{sec:xxx_shutdown}).
1205
1206
1207
1208 \section{Un esempio elementare: il servizio \textit{daytime}}
1209 \label{sec:TCP_daytime_application}
1210
1211 Avendo introdotto le funzioni di base per la gestione dei socket, potremo
1212 vedere in questa sezione un primo esempio di applicazione elementare che
1213 implementa il servizio \textit{daytime} su TCP, secondo quanto specificato
1214 dall'\href{http://www.ietf.org/rfc/rfc0867.txt}{RFC~867}.  Prima di passare
1215 agli esempi del client e del server, inizieremo riesaminando con maggiori
1216 dettagli una peculiarità delle funzioni di I/O, già accennata in
1217 \secref{sec:file_read} e \secref{sec:file_write}, che nel caso dei socket è
1218 particolarmente rilevante.  Passeremo poi ad illustrare gli esempi
1219 dell'implementazione, sia dal lato client, che dal lato server, che si è
1220 realizzato sia in forma iterativa che concorrente.
1221
1222
1223 \subsection{Il comportamento delle funzioni di I/O}
1224 \label{sec:sock_io_behav}
1225
1226 Una cosa che si tende a dimenticare quando si ha a che fare con i socket è che
1227 le funzioni di input/output non sempre hanno lo stesso comportamento che
1228 avrebbero con i normali file di dati (in particolare questo accade per i
1229 socket di tipo stream).
1230
1231 Infatti con i socket è comune che funzioni come \func{read} o \func{write}
1232 possano restituire in input o scrivere in output un numero di byte minore di
1233 quello richiesto. Come già accennato in \secref{sec:file_read} questo è un
1234 comportamento normale per le funzioni di I/O, ma con i normali file di dati il
1235 problema si avverte solo in lettura, quando si incontra la fine del file. In
1236 generale non è così, e con i socket questo è particolarmente evidente.
1237
1238
1239 \begin{figure}[htb]
1240   \footnotesize \centering
1241   \begin{minipage}[c]{15cm}
1242     \includecodesample{listati/FullRead.c}
1243   \end{minipage} 
1244   \normalsize
1245   \caption{La funzione \func{FullRead}, che legge esattamente \var{count} byte
1246     da un file descriptor, iterando opportunamente le letture.}
1247   \label{fig:sock_FullRead_code}
1248 \end{figure}
1249
1250 Quando ci si trova ad affrontare questo comportamento tutto quello che si deve
1251 fare è semplicemente ripetere la lettura (o la scrittura) per la quantità di
1252 byte restanti, tenendo conto che le funzioni si possono bloccare se i dati non
1253 sono disponibili: è lo stesso comportamento che si può avere scrivendo più di
1254 \const{PIPE\_BUF} byte in una pipe (si riveda quanto detto in
1255 \secref{sec:ipc_pipes}).
1256
1257 Per questo motivo, seguendo l'esempio di R. W. Stevens in \cite{UNP1}, si sono
1258 definite due funzioni, \func{FullRead} e \func{FullWrite}, che eseguono
1259 lettura e scrittura tenendo conto di questa caratteristica, ed in grado di
1260 ritornare solo dopo avere letto o scritto esattamente il numero di byte
1261 specificato; il sorgente è riportato rispettivamente in
1262 \figref{fig:sock_FullRead_code} e \figref{fig:sock_FullWrite_code} ed è
1263 disponibile fra i sorgenti allegati alla guida nei file \file{FullRead.c} e
1264 \file{FullWrite.c}.
1265
1266 \begin{figure}[htb]
1267   \centering
1268   \footnotesize \centering
1269   \begin{minipage}[c]{15cm}
1270     \includecodesample{listati/FullWrite.c}
1271   \end{minipage} 
1272   \normalsize
1273   \caption{La funzione \func{FullWrite}, che scrive esattamente \var{count}
1274     byte su un file descriptor, iterando opportunamente le scritture.}
1275   \label{fig:sock_FullWrite_code}
1276 \end{figure}
1277
1278 Come si può notare le due funzioni ripetono la lettura/scrittura in un ciclo
1279 fino all'esaurimento del numero di byte richiesti, in caso di errore viene
1280 controllato se questo è \errcode{EINTR} (cioè un'interruzione della system
1281 call dovuta ad un segnale), nel qual caso l'accesso viene ripetuto, altrimenti
1282 l'errore viene ritornato al programma chiamante, interrompendo il ciclo.
1283
1284 Nel caso della lettura, se il numero di byte letti è zero, significa che si è
1285 arrivati alla fine del file (per i socket questo significa in genere che
1286 l'altro capo è stato chiuso, e quindi non sarà più possibile leggere niente) e
1287 pertanto si ritorna senza aver concluso la lettura di tutti i byte
1288 richiesti. Entrambe le funzioni restituiscono 0 in caso di successo, ed un
1289 valore negativo in caso di errore, \texttt{FullRead} restituisce il numero di
1290 byte non letti in caso di end-of-file prematuro.
1291
1292
1293 \subsection{Il client \textit{daytime}}
1294 \label{sec:TCP_daytime_client}
1295
1296 Il primo esempio di applicazione delle funzioni di base illustrate in
1297 \secref{sec:TCP_functions} è relativo alla creazione di un client elementare
1298 per il servizio \textit{daytime}, un servizio elementare, definito
1299 nell'\href{http://www.ietf.org/rfc/rfc0867.txt}{RFC~867}, che restituisce
1300 l'ora locale della macchina a cui si effettua la richiesta, e che è assegnato
1301 alla porta 13.
1302
1303 In \figref{fig:TCP_daytime_client_code} è riportata la sezione principale del
1304 codice del nostro client. Il sorgente completo del programma
1305 (\file{TCP\_daytime.c}, che comprende il trattamento delle opzioni ed una
1306 funzione per stampare un messaggio di aiuto) è allegato alla guida nella
1307 sezione dei codici sorgente e può essere compilato su una qualunque macchina
1308 GNU/Linux.
1309
1310 \begin{figure}[!htb]
1311   \footnotesize \centering
1312   \begin{minipage}[c]{15cm}
1313     \includecodesample{listati/TCP_daytime.c}
1314   \end{minipage} 
1315   \normalsize
1316   \caption{Esempio di codice di un client elementare per il servizio
1317     \textit{daytime}.} 
1318   \label{fig:TCP_daytime_client_code}
1319 \end{figure}
1320
1321 Il programma anzitutto (\texttt{\small 1--5}) include gli header necessari;
1322 dopo la dichiarazione delle variabili (\texttt{\small 9--12}) si è omessa
1323 tutta la parte relativa al trattamento degli argomenti passati dalla linea di
1324 comando (effettuata con le apposite funzioni illustrate in
1325 \secref{sec:proc_opt_handling}).
1326
1327 Il primo passo (\texttt{\small 14--18}) è creare un socket TCP (quindi di tipo
1328 \const{SOCK\_STREAM} e di famiglia \const{AF\_INET}). La funzione
1329 \func{socket} ritorna il descrittore che viene usato per identificare il
1330 socket in tutte le chiamate successive. Nel caso la chiamata fallisca si
1331 stampa un errore (\texttt{\small 16}) con la funzione \func{perror} e si esce
1332 (\texttt{\small 17}) con un codice di errore.
1333
1334 Il passo seguente (\texttt{\small 19--27}) è quello di costruire un'apposita
1335 struttura \struct{sockaddr\_in} in cui sarà inserito l'indirizzo del server ed
1336 il numero della porta del servizio. Il primo passo (\texttt{\small 20}) è
1337 inizializzare tutto a zero, per poi inserire il tipo di indirizzo
1338 (\texttt{\small 21}) e la porta (\texttt{\small 22}), usando per quest'ultima
1339 la funzione \func{htons} per convertire il formato dell'intero usato dal
1340 computer a quello usato nella rete, infine \texttt{\small 23--27} si può
1341 utilizzare la funzione \func{inet\_pton} per convertire l'indirizzo numerico
1342 passato dalla linea di comando.
1343
1344 A questo punto (\texttt{\small 28--32}) usando la funzione \func{connect} sul
1345 socket creato in precedenza (\texttt{\small 29}) si può stabilire la
1346 connessione con il server. Per questo si deve utilizzare come secondo
1347 argomento la struttura preparata in precedenza con il relativo indirizzo; si
1348 noti come, esistendo diversi tipi di socket, si sia dovuto effettuare un cast.
1349 Un valore di ritorno della funzione negativo implica il fallimento della
1350 connessione, nel qual caso si stampa un errore (\texttt{\small 30}) e si
1351 ritorna (\texttt{\small 31}).
1352
1353 Completata con successo la connessione il passo successivo (\texttt{\small
1354   34--40}) è leggere la data dal socket; il protocollo prevede che il server
1355 invii sempre una stringa alfanumerica, il formato della stringa non è
1356 specificato dallo standard, per cui noi useremo il formato usato dalla
1357 funzione \func{ctime}, seguito dai caratteri di terminazione \verb|\r\n|, cioè
1358 qualcosa del tipo:
1359 \begin{verbatim}
1360 Wed Apr 4 00:53:00 2001\r\n
1361 \end{verbatim}
1362 questa viene letta dal socket (\texttt{\small 34}) con la funzione \func{read}
1363 in un buffer temporaneo; la stringa poi deve essere terminata (\texttt{\small
1364   35}) con il solito carattere nullo per poter essere stampata (\texttt{\small
1365   36}) sullo standard output con l'uso di \func{fputs}.
1366
1367 Come si è già spiegato in \secref{sec:sock_io_behav} la risposta dal socket
1368 potrà arrivare in un unico pacchetto di 26 byte (come avverrà senz'altro nel
1369 caso in questione) ma potrebbe anche arrivare in 26 pacchetti di un byte.  Per
1370 questo nel caso generale non si può mai assumere che tutti i dati arrivino con
1371 una singola lettura, pertanto quest'ultima deve essere effettuata in un ciclo
1372 in cui si continui a leggere fintanto che la funzione \func{read} non ritorni
1373 uno zero (che significa che l'altro capo ha chiuso la connessione) o un numero
1374 minore di zero (che significa un errore nella connessione).
1375
1376 Si noti come in questo caso la fine dei dati sia specificata dal server che
1377 chiude la connessione (anche questo è quanto richiesto dal protocollo); questa
1378 è una delle tecniche possibili (è quella usata pure dal protocollo HTTP), ma
1379 ce ne possono essere altre, ad esempio FTP marca la conclusione di un blocco
1380 di dati con la sequenza ASCII \verb|\r\n| (carriage return e line feed),
1381 mentre il DNS mette la lunghezza in testa ad ogni blocco che trasmette. Il
1382 punto essenziale è che TCP non provvede nessuna indicazione che permetta di
1383 marcare dei blocchi di dati, per cui se questo è necessario deve provvedere il
1384 programma stesso.
1385
1386 Se abilitiamo il servizio \textit{daytime}\footnote{in genere questo viene
1387   fornito direttamente dal \textsl{superdemone} \texttt{inetd}, pertanto basta
1388   assicurarsi che esso sia abilitato nel relativo file di configurazione.}
1389 possiamo verificare il funzionamento del nostro client, avremo allora:
1390 \begin{verbatim}
1391 [piccardi@gont sources]$ ./daytime 127.0.0.1
1392 Mon Apr 21 20:46:11 2003
1393 \end{verbatim}%$
1394 e come si vede tutto funziona regolarmente.
1395
1396
1397 \subsection{Un server \textit{daytime} iterativo}
1398 \label{sec:TCP_daytime_iter_server}
1399
1400 Dopo aver illustrato il client daremo anche un esempio di un server
1401 elementare, che sia anche in grado di rispondere al precedente client. Come
1402 primo esempio realizzeremo un server iterativo, in grado di fornire una sola
1403 risposta alla volta. Il codice del programma è nuovamente mostrato in
1404 \figref{fig:TCP_daytime_iter_server_code}, il sorgente completo
1405 (\file{TCP\_iter\_daytimed.c}) è allegato insieme agli altri file degli esempi.
1406
1407 \begin{figure}[!htbp]
1408   \footnotesize \centering
1409   \begin{minipage}[c]{15cm}
1410     \includecodesample{listati/TCP_iter_daytimed.c}
1411   \end{minipage} 
1412   \normalsize
1413   \caption{Esempio di codice di un semplice server per il servizio daytime.}
1414   \label{fig:TCP_daytime_iter_server_code}
1415 \end{figure}
1416
1417 Come per il client si includono (\texttt{\small 1--9}) gli header necessari a
1418 cui è aggiunto quello per trattare i tempi, e si definiscono (\texttt{\small
1419   14--18}) alcune costanti e le variabili necessarie in seguito. Come nel caso
1420 precedente si sono omesse le parti relative al trattamento delle opzioni da
1421 riga di comando.
1422
1423 La creazione del socket (\texttt{\small 20--24}) è analoga al caso precedente,
1424 come pure l'inizializzazione (\texttt{\small 25--29}) della struttura
1425 \struct{sockaddr\_in}.  Anche in questo caso (\texttt{\small 28}) si usa la
1426 porta standard del servizio daytime, ma come indirizzo IP si usa
1427 (\texttt{\small 27}) il valore predefinito \const{INET\_ANY}, che corrisponde
1428 all'indirizzo generico.
1429
1430 Si effettua poi (\texttt{\small 30--34}) la chiamata alla funzione \func{bind}
1431 che permette di associare la precedente struttura al socket, in modo che
1432 quest'ultimo possa essere usato per accettare connessioni su una qualunque
1433 delle interfacce di rete locali. In caso di errore si stampa (\texttt{\small
1434   31}) un messaggio, e si termina (\texttt{\small 32}) immediatamente il
1435 programma.
1436
1437 Il passo successivo (\texttt{\small 35--39}) è quello di mettere ``in
1438 ascolto'' il socket; questo viene fatto (\texttt{\small 36}) con la funzione
1439 \func{listen} che dice al kernel di accettare connessioni per il socket che
1440 abbiamo creato; la funzione indica inoltre, con il secondo parametro, il
1441 numero massimo di connessioni che il kernel accetterà di mettere in coda per
1442 il suddetto socket. Di nuovo in caso di errore si stampa (\texttt{\small 37})
1443 un messaggio, e si esce (\texttt{\small 38}) immediatamente.
1444
1445 La chiamata a \func{listen} completa la preparazione del socket per l'ascolto
1446 (che viene chiamato anche \textit{listening descriptor}) a questo punto si può
1447 procedere con il ciclo principale (\texttt{\small 40--53}) che viene eseguito
1448 indefinitamente. Il primo passo (\texttt{\small 42}) è porsi in attesa di
1449 connessioni con la chiamata alla funzione \func{accept}, come in precedenza in
1450 caso di errore si stampa (\texttt{\small 43}) un messaggio, e si esce
1451 (\texttt{\small 44}).
1452
1453 Il processo resterà in stato di \textit{sleep} fin quando non arriva e viene
1454 accettata una connessione da un client; quando questo avviene \func{accept}
1455 ritorna, restituendo un secondo descrittore, che viene chiamato
1456 \textit{connected descriptor}, e che è quello che verrà usato dalla successiva
1457 chiamata alla \func{write} per scrivere la risposta al client.
1458
1459 Il ciclo quindi proseguirà determinando (\texttt{\small 46}) il tempo corrente
1460 con una chiamata a \texttt{time}, con il quale si potrà opportunamente
1461 costruire (\texttt{\small 47}) la stringa con la data da trasmettere
1462 (\texttt{\small 48}) con la chiamata a \func{write}. Completata la
1463 trasmissione il nuovo socket viene chiuso (\texttt{\small 52}).  A questo
1464 punto il ciclo si chiude ricominciando da capo in modo da poter ripetere
1465 l'invio della data in risposta ad una successiva connessione.
1466
1467 È importante notare che questo server è estremamente elementare, infatti, a
1468 parte il fatto di poter essere usato solo con indirizzi IPv4, esso è in grado
1469 di rispondere ad un solo un client alla volta: è cioè, come dicevamo, un
1470 \textsl{server iterativo}. Inoltre è scritto per essere lanciato da linea di
1471 comando, se lo si volesse utilizzare come demone occorrerebbero le opportune
1472 modifiche\footnote{come una chiamata a \func{daemon} prima dell'inizio del
1473   ciclo principale.} per tener conto di quanto illustrato in
1474 \secref{sec:sess_daemon}. Si noti anche che non si è inserita nessuna forma di
1475 gestione della terminazione del processo, dato che tutti i file descriptor
1476 vengono chiusi automaticamente alla sua uscita, e che, non generando figli,
1477 non è necessario preoccuparsi di gestire la loro terminazione.
1478
1479
1480 \subsection{Un server \textit{daytime} concorrente}
1481 \label{sec:TCP_daytime_cunc_server}
1482
1483 Il server \texttt{daytime} dell'esempio in
1484 \secref{sec:TCP_daytime_iter_server} è un tipico esempio di server iterativo,
1485 in cui viene servita una richiesta alla volta; in generale però, specie se il
1486 servizio è più complesso e comporta uno scambio di dati più sostanzioso di
1487 quello in questione, non è opportuno bloccare un server nel servizio di un
1488 client per volta; per questo si ricorre alle capacità di multitasking del
1489 sistema.
1490
1491 Come accennato anche in \secref{sec:proc_gen} una delle modalità più comuni di
1492 funzionamento da parte dei server è quella di usare la funzione \func{fork}
1493 per creare, ad ogni richiesta da parte di un client, un processo figlio che si
1494 incarichi della gestione della comunicazione.  Si è allora riscritto il server
1495 \textit{daytime} dell'esempio precedente in forma concorrente, inserendo anche
1496 una opzione per la stampa degli indirizzi delle connessioni ricevute.
1497
1498 In \figref{fig:TCP_daytime_cunc_server_code} è mostrato un estratto del
1499 codice, in cui si sono tralasciati il trattamento delle opzioni e le parti
1500 rimaste invariate rispetto al precedente esempio (cioè tutta la parte
1501 riguardante l'apertura passiva del socket). Al solito il sorgente completo del
1502 server, nel file \file{TCP\_cunc\_daytimed.c}, è allegato insieme ai sorgenti
1503 degli altri esempi.
1504
1505 \begin{figure}[!htb]
1506   \footnotesize \centering
1507   \begin{minipage}[c]{15cm}
1508     \includecodesample{listati/TCP_cunc_daytimed.c}
1509   \end{minipage} 
1510   \normalsize
1511   \caption{Esempio di codice di un server concorrente elementare per il 
1512     servizio daytime.}
1513   \label{fig:TCP_daytime_cunc_server_code}
1514 \end{figure}
1515
1516 Stavolta (\texttt{\small 21--25}) la funzione \func{accept} è chiamata
1517 fornendo una struttura di indirizzi in cui saranno ritornati l'indirizzo IP e
1518 la porta da cui il client effettua la connessione, che in un secondo tempo,
1519 (\texttt{\small 39--43}), se il logging è abilitato, stamperemo sullo standard
1520 output.
1521
1522 Quando \func{accept} ritorna il server chiama la funzione \func{fork}
1523 (\texttt{\small 26--30}) per creare il processo figlio che effettuerà
1524 (\texttt{\small 31--45}) tutte le operazioni relative a quella connessione,
1525 mentre il padre proseguirà l'esecuzione del ciclo principale in attesa di
1526 ulteriori connessioni.
1527
1528 Si noti come il figlio operi solo sul socket connesso, chiudendo
1529 immediatamente (\texttt{\small 32}) il socket \var{list\_fd}; mentre il padre
1530 continua ad operare (\texttt{\small 47}) solo sul socket in ascolto chiudendo
1531 \var{sock\_fd} al ritorno dalla \func{fork}. Per quanto abbiamo detto in
1532 \secref{sec:TCP_func_close} nessuna delle due chiamate a \func{close} causa
1533 l'innesco della sequenza di chiusura perché il numero di riferimenti al file
1534 descriptor non si è annullato.
1535
1536 Infatti subito dopo la creazione del socket \var{list\_fd} ha una referenza, e
1537 lo stesso vale per \var{sock\_fd} dopo il ritorno di \func{accept}, ma dopo la
1538 \func{fork} i descrittori vengono duplicati nel padre e nel figlio per cui
1539 entrambi i socket si trovano con due referenze. Questo fa si che quando il
1540 padre chiude \var{sock\_fd} esso resta con una referenza da parte del figlio,
1541 e sarà definitivamente chiuso solo quando quest'ultimo, dopo aver completato
1542 le sue operazioni, chiamerà (\texttt{\small 44}) la funzione \func{close}.
1543
1544 In realtà per il figlio non sarebbe necessaria nessuna chiamata a
1545 \func{close}, in quanto con la \func{exit} finale (\texttt{\small 45}) tutti i
1546 file descriptor, quindi anche quelli associati ai socket, vengono
1547 automaticamente chiusi.  Tuttavia si è preferito effettuare esplicitamente le
1548 chiusure per avere una maggiore chiarezza del codice, e per evitare eventuali
1549 errori, prevenendo ad esempio un uso involontario del \textit{listening
1550   descriptor}.
1551
1552 Si noti invece come sia essenziale che il padre chiuda ogni volta il socket
1553 connesso dopo la \func{fork}; se così non fosse nessuno di questi socket
1554 sarebbe effettivamente chiuso dato che alla chiusura da parte del figlio
1555 resterebbe ancora un riferimento nel padre. Si avrebbero così due effetti: il
1556 padre potrebbe esaurire i descrittori disponibili (che sono un numero limitato
1557 per ogni processo) e soprattutto nessuna delle connessioni con i client
1558 verrebbe chiusa.
1559
1560 Come per ogni server iterativo il lavoro di risposta viene eseguito
1561 interamente dal processo figlio. Questo si incarica (\texttt{\small 33}) di
1562 chiamare \func{time} per leggere il tempo corrente, e di stamparlo
1563 (\texttt{\small 34}) sulla stringa contenuta in \var{buffer} con l'uso di
1564 \func{snprintf} e \func{ctime}. Poi la stringa viene scritta (\texttt{\small
1565   35--38}) sul socket, controllando che non ci siano errori. Anche in questo
1566 caso si è evitato il ricorso a \func{FullWrite} in quanto la stringa è
1567 estremamente breve e verrà senz'altro scritta in un singolo segmento.
1568
1569 Inoltre nel caso sia stato abilitato il \textit{logging} delle connessioni, si
1570 provvede anche (\texttt{\small 39--42}) a stampare sullo standard output
1571 l'indirizzo e la porta da cui il client ha effettuato la connessione, usando
1572 i valori contenuti nelle strutture restituite da \func{accept}, eseguendo le
1573 opportune conversioni con \func{inet\_ntop} e \func{atohs}.
1574
1575 Ancora una volta l'esempio è estremamente semplificato, si noti come di nuovo
1576 non si sia gestita né la terminazione del processo né il suo uso come demone,
1577 che tra l'altro sarebbe stato incompatibile con l'uso della opzione di logging
1578 che stampa gli indirizzi delle connessioni sullo standard output. Un altro
1579 aspetto tralasciato è la gestione della terminazione dei processi figli,
1580 torneremo su questo più avanti quando tratteremo alcuni esempi di server più
1581 complessi.
1582
1583
1584
1585 \section{Un esempio più completo: il servizio \textit{echo}}
1586 \label{sec:TCP_echo_application}
1587
1588 L'esempio precedente, basato sul servizio \textit{daytime}, è un esempio molto
1589 elementare, in cui il flusso dei dati va solo nella direzione dal server al
1590 client. In questa sezione esamineremo un esempio di applicazione client/server
1591 un po' più complessa, che usi i socket TCP per una comunicazione in entrambe
1592 le direzioni.
1593
1594 Ci limiteremo a fornire una implementazione elementare, che usi solo le
1595 funzioni di base viste finora, ma prenderemo in esame, oltre al comportamento
1596 in condizioni normali, anche tutti i possibili scenari particolari (errori,
1597 sconnessione della rete, crash del client o del server durante la connessione)
1598 che possono avere luogo durante l'impiego di un'applicazione di rete, partendo
1599 da una versione primitiva che dovrà essere rimaneggiata di volta in volta per
1600 poter tenere conto di tutte le evenienze che si possono manifestare nella vita
1601 reale di un'applicazione di rete, fino ad arrivare ad un'implementazione
1602 completa.
1603
1604
1605 \subsection{Il servizio \textit{echo}}
1606 \label{sec:TCP_echo}
1607
1608
1609 Nella ricerca di un servizio che potesse fare da esempio per una comunicazione
1610 bidirezionale, si è deciso, seguendo la scelta di Stevens in \cite{UNP1}, di
1611 usare il servizio \textit{echo}, che si limita a restituire in uscita quanto
1612 immesso in ingresso. Infatti, nonostante la sua estrema semplicità, questo
1613 servizio costituisce il prototipo ideale per una generica applicazione di rete
1614 in cui un server risponde alle richieste di un client.  Nel caso di una
1615 applicazione più complessa quello che si potrà avere in più è una elaborazione
1616 dell'input del client, che in molti casi viene interpretato come un comando,
1617 da parte di un server che risponde fornendo altri dati in uscita.
1618
1619 Il servizio \textit{echo} è uno dei servizi standard solitamente provvisti
1620 direttamente dal superserver \cmd{inetd}, ed è definito
1621 dall'\href{http://www.ietf.org/rfc/rfc0862.txt}{RFC~862}. Come dice il nome il
1622 servizio deve riscrivere indietro sul socket i dati che gli vengono inviati in
1623 ingresso. L'RFC descrive le specifiche del servizio sia per TCP che UDP, e per
1624 il primo stabilisce che una volta stabilita la connessione ogni dato in
1625 ingresso deve essere rimandato in uscita fintanto che il chiamante non ha
1626 chiude la connessione. Al servizio è assegnata la porta riservata 7.
1627
1628 Nel nostro caso l'esempio sarà costituito da un client che legge una linea di
1629 caratteri dallo standard input e la scrive sul server. A sua volta il server
1630 leggerà la linea dalla connessione e la riscriverà immutata all'indietro. Sarà
1631 compito del client leggere la risposta del server e stamparla sullo standard
1632 output.
1633
1634
1635 \subsection{Il client: prima versione}
1636 \label{sec:TCP_echo_client}
1637
1638 Il codice della prima versione del client per il servizio \textit{echo},
1639 disponibile nel file \file{TCP\_echo\_first.c}, è riportato in
1640 \figref{fig:TCP_echo_client_1}. Esso ricalca la struttura del precedente
1641 client per il servizio \textit{daytime} (vedi
1642 \secref{sec:TCP_daytime_client}), e la prima parte (\texttt{\small 10--27}) è
1643 sostanzialmente identica, a parte l'uso di una porta diversa.
1644
1645 \begin{figure}[!htb]
1646   \footnotesize \centering
1647   \begin{minipage}[c]{15.6 cm}
1648     \includecodesample{listati/TCP_echo_first.c}
1649   \end{minipage} 
1650   \normalsize
1651   \caption{Codice della prima versione del client \textit{echo}.}
1652   \label{fig:TCP_echo_client_1}
1653 \end{figure}
1654
1655 Al solito si è tralasciata la sezione relativa alla gestione delle opzioni a
1656 riga di comando.  Una volta dichiarate le variabili, si prosegue
1657 (\texttt{\small 10--13}) con della creazione del socket con l'usuale controllo
1658 degli errori, alla preparazione (\texttt{\small 14--17}) della struttura
1659 dell'indirizzo, che stavolta usa la porta 7 riservata al servizio
1660 \textit{echo}, infine si converte (\texttt{\small 18--22}) l'indirizzo
1661 specificato a riga di comando.  A questo punto (\texttt{\small 23--27}) si può
1662 eseguire la connessione al server secondo la stessa modalità usata in
1663 \secref{sec:TCP_daytime_client}.
1664
1665 Completata la connessione, per gestire il funzionamento del protocollo si usa
1666 la funzione \code{ClientEcho}, il cui codice si è riportato a parte in
1667 \figref{fig:TCP_client_echo_sub}. Questa si preoccupa di gestire tutta la
1668 comunicazione, leggendo una riga alla volta dallo standard input \file{stdin},
1669 scrivendola sul socket e ristampando su \file{stdout} quanto ricevuto in
1670 risposta dal server. Al ritorno dalla funzione (\texttt{\small 30--31}) anche
1671 il programma termina.
1672
1673 La funzione \code{ClientEcho} utilizza due buffer (\texttt{\small 3}) per
1674 gestire i dati inviati e letti sul socket.  La comunicazione viene gestita
1675 all'interno di un ciclo (\texttt{\small 5--10}), i dati da inviare sulla
1676 connessione vengono presi dallo \file{stdin} usando la funzione \func{fgets},
1677 che legge una linea di testo (terminata da un \texttt{CR} e fino al massimo di
1678 \const{MAXLINE} caratteri) e la salva sul buffer di invio.
1679
1680 Si usa poi (\texttt{\small 6}) la funzione \func{FullWrite}, vista in
1681 \secref{sec:sock_io_behav}, per scrivere i dati sul socket, gestendo
1682 automaticamente l'invio multiplo qualora una singola \func{write} non sia
1683 sufficiente.  I dati vengono riletti indietro (\texttt{\small 7}) con una
1684 \func{read}\footnote{si è fatta l'assunzione implicita che i dati siano
1685   contenuti tutti in un solo segmento, così che la chiamata a \texttt{read} li
1686   restituisca sempre tutti; avendo scelto una dimensione ridotta per il buffer
1687   questo sarà sempre vero, vedremo più avanti come superare il problema di
1688   rileggere indietro tutti e soli i dati disponibili, senza bloccarsi.} sul
1689 buffer di ricezione e viene inserita (\texttt{\small 8}) la terminazione della
1690 stringa e per poter usare (\texttt{\small 9}) la funzione \func{fputs} per
1691 scriverli su \file{stdout}.
1692
1693 \begin{figure}[!htb]
1694   \footnotesize \centering
1695   \begin{minipage}[c]{15.6cm}
1696     \includecodesample{listati/ClientEcho.c}
1697   \end{minipage} 
1698   \normalsize
1699   \caption{Codice della prima versione della funzione \texttt{ClientEcho} per 
1700     la gestione del servizio \textit{echo}.}
1701   \label{fig:TCP_client_echo_sub}
1702 \end{figure}
1703
1704 Quando si concluderà l'invio di dati mandando un end-of-file sullo standard
1705 input si avrà il ritorno di \func{fgets} con un puntatore nullo (si riveda
1706 quanto spiegato in \secref{sec:file_line_io}) e la conseguente uscita dal
1707 ciclo; al che la subroutine ritorna ed il nostro programma client termina.
1708
1709 Si può effettuare una verifica del funzionamento del client abilitando il
1710 servizio \textit{echo} nella configurazione di \cmd{initd} sulla propria
1711 macchina ed usandolo direttamente verso di esso in locale, vedremo in
1712 dettaglio più avanti (in \secref{sec:TCP_echo_startup}) il funzionamento del
1713 programma, usato però con la nostra versione del server \textit{echo}, che
1714 illustriamo immediatamente.
1715
1716
1717 \subsection{Il server: prima versione}
1718 \label{sec:TCPsimp_server_main}
1719
1720 La prima versione del server, contenuta nel file \file{TCP\_echod\_first.c}, è
1721 riportata in \figref{fig:TCP_echo_server_first_code}. Come abbiamo fatto per
1722 il client anche il server è stato diviso in un corpo principale, costituito
1723 dalla funzione \code{main}, che è molto simile a quello visto nel precedente
1724 esempio per il server del servizio \textit{daytime} di
1725 \secref{sec:TCP_daytime_cunc_server}, e da una funzione ausiliaria
1726 \code{ServEcho} che si cura della gestione del servizio.
1727
1728 \begin{figure}[!htbp]
1729   \footnotesize \centering
1730   \begin{minipage}[c]{15.6cm}
1731     \includecodesample{listati/TCP_echod_first.c}
1732   \end{minipage} 
1733   \normalsize
1734   \caption{Codice del corpo principale della prima versione del server
1735     per il servizio \textit{echo}.}
1736   \label{fig:TCP_echo_server_first_code}
1737 \end{figure}
1738
1739 In questo caso però, rispetto a quanto visto nell'esempio di
1740 \figref{fig:TCP_daytime_cunc_server_code} si è preferito scrivere il server
1741 curando maggiormente alcuni dettagli, per tenere conto anche di alcune
1742 esigenze generali (che non riguardano direttamente la rete), come la
1743 possibilità di lanciare il server anche in modalità interattiva e la cessione
1744 dei privilegi di amministratore non appena questi non sono più necessari.
1745
1746 La sezione iniziale del programma (\texttt{\small 8--21}) è la stessa del
1747 server di \secref{sec:TCP_daytime_cunc_server}, ed ivi descritta in dettaglio:
1748 crea il socket, inizializza l'indirizzo e esegue \func{bind}; dato che
1749 quest'ultima funzione viene usata su una porta riservata, il server dovrà
1750 essere eseguito da un processo con i privilegi di amministratore, pena il
1751 fallimento della chiamata.
1752
1753 Una volta eseguita la funzione \func{bind} però i privilegi di amministratore
1754 non sono più necessari, per questo è sempre opportuno rilasciarli, in modo da
1755 evitare problemi in caso di eventuali vulnerabilità del server.  Per questo
1756 prima (\texttt{\small 22--26}) si esegue \func{setgid} per assegnare il
1757 processo ad un gruppo senza privilegi,\footnote{si è usato il valore 65534,
1758   ovvero -1 per il formato \ctyp{short}, che di norma in tutte le
1759   distribuzioni viene usato per identificare il gruppo \texttt{nogroup} e
1760   l'utente \texttt{nobody}, usati appunto per eseguire programmi che non
1761   richiedono nessun privilegio particolare.} e poi si ripete (\texttt{\small
1762   27--30}) l'operazione usando \func{setuid} per cambiare anche
1763 l'utente.\footnote{si tenga presente che l'ordine in cui si eseguono queste
1764   due operazioni è importante, infatti solo avendo i privilegi di
1765   amministratore si può cambiare il gruppo di un processo ad un'altro di cui
1766   non si fa parte, per cui chiamare prima \func{setuid} farebbe fallire una
1767   successiva chiamata a \func{setgid}.  Inoltre si ricordi (si riveda quanto
1768   esposto in \secref{sec:proc_perms}) che usando queste due funzioni il
1769   rilascio dei privilegi è irreversibile.}  Infine (\texttt{\small 30--36}),
1770 qualora sia impostata la variabile \var{demonize}, prima (\texttt{\small 31})
1771 si apre il sistema di logging per la stampa degli errori, e poi
1772 (\texttt{\small 32--35}) si invoca \func{daemon} per eseguire in background il
1773 processo come demone.
1774
1775 A questo punto il programma riprende di nuovo lo schema già visto usato dal
1776 server per il servizio \textit{daytime}, con l'unica differenza della chiamata
1777 alla funzione \code{PrintErr}, riportata in \figref{fig:TCP_PrintErr}, al
1778 posto di \func{perror} per la stampa degli errori. 
1779
1780 Si inizia con il porre (\texttt{\small 37--41}) in ascolto il socket, e poi si
1781 esegue indefinitamente il ciclo principale (\texttt{\small 42--58}).
1782 All'interno di questo si ricevono (\texttt{\small 43--46}) le connessioni,
1783 creando (\texttt{\small 47--50}) un processo figlio per ciascuna di esse.
1784 Quest'ultimo (\texttt{\small 51--55}), chiuso (\texttt{\small 52}) il
1785 \textit{listening socket}, esegue (\texttt{\small 53}) la funzione di gestione
1786 del servizio \code{ServEcho}, ed al ritorno di questa (\texttt{\small 54})
1787 esce.
1788
1789 Il padre invece si limita (\texttt{\small 56}) a chiudere il \textit{connected
1790   socket} per ricominciare da capo il ciclo in attesa di nuove connessioni. In
1791 questo modo si ha un server concorrente. La terminazione del padre non è
1792 gestita esplicitamente, e deve essere effettuata inviando un segnale al
1793 processo.
1794
1795 Avendo trattato direttamente la gestione del programma come demone, si è
1796 dovuto anche provvedere alla necessità di poter stampare eventuali messaggi di
1797 errore attraverso il sistema del \textit{syslog} trattato in
1798 \secref{sec:sess_daemon}. Come accennato questo è stato fatto utilizzando come
1799 \textit{wrapper} la funzione \code{PrintErr}, il cui codice è riportato in
1800 \figref{fig:TCP_PrintErr}. 
1801
1802 In essa ci si limita a controllare (\texttt{\small 2}) se è stato impostato
1803 (valore attivo per default) l'uso come demone, nel qual caso (\texttt{\small
1804   3}) si usa \func{syslog} (vedi \secref{sec:sess_daemon}) per stampare il
1805 messaggio di errore fornito come argomento sui log di sistema. Se invece si è
1806 in modalità interattiva (attivabile con l'opzione \texttt{-i}) si usa
1807 (\texttt{\small 5}) semplicemente la funzione \func{perror} per stampare sullo
1808 standard error.
1809
1810 \begin{figure}[!htb]
1811   \footnotesize \centering
1812   \begin{minipage}[c]{15.6cm}
1813     \includecodesample{listati/PrintErr.c}
1814   \end{minipage} 
1815   \normalsize
1816   \caption{Codice della funzione \code{PrintErr} per la
1817     generalizzazione della stampa degli errori sullo standard input o
1818     attraverso il \texttt{syslog}.}
1819   \label{fig:TCP_PrintErr}
1820 \end{figure}
1821
1822 La gestione del servizio \textit{echo} viene effettuata interamente nella
1823 funzione \code{ServEcho}, il cui codice è mostrato in
1824 \figref{fig:TCP_ServEcho_first}, e la comunicazione viene gestita all'interno
1825 di un ciclo (\texttt{\small 6--13}).  I dati inviati dal client vengono letti
1826 (\texttt{\small 6}) dal socket con una semplice \func{read}, di cui non si
1827 controlla lo stato di uscita, assumendo che ritorni solo in presenza di dati
1828 in arrivo. La riscrittura (\texttt{\small 7}) viene invece gestita dalla
1829 funzione \func{FullWrite} (descritta in \figref{fig:sock_FullWrite_code}) che
1830 si incarica di tenere conto automaticamente della possibilità che non tutti i
1831 dati di cui è richiesta la scrittura vengano trasmessi con una singola
1832 \func{write}.
1833
1834 \begin{figure}[!htb] 
1835   \footnotesize \centering
1836   \begin{minipage}[c]{15.6cm}
1837     \includecodesample{listati/ServEcho_first.c}
1838   \end{minipage} 
1839   \normalsize
1840   \caption{Codice della prima versione della funzione \code{ServEcho} per la
1841     gestione del servizio \textit{echo}.}
1842   \label{fig:TCP_ServEcho_first}
1843 \end{figure}
1844
1845 In caso di errore di scrittura (si ricordi che \func{FullWrite} restituisce un
1846 valore nullo in caso di successo) si provvede (\texttt{\small 8--10}) a
1847 stampare il relativo messaggio con \func{PrintErr}.  Quando il client chiude
1848 la connessione il ricevimento del FIN fa ritornare la \func{read} con un
1849 numero di byte letti pari a zero, il che causa l'uscita dal ciclo e il ritorno
1850 (\texttt{\small 12}) della funzione, che a sua volta causa la terminazione del
1851 processo figlio.
1852
1853
1854 \subsection{L'avvio e il funzionamento normale}
1855 \label{sec:TCP_echo_startup}
1856
1857 Benché il codice dell'esempio precedente sia molto ridotto, esso ci permetterà
1858 di considerare in dettaglio le varie problematiche che si possono incontrare
1859 nello scrivere un'applicazione di rete. Infatti attraverso l'esame delle sue
1860 modalità di funzionamento normali, all'avvio e alla terminazione, e di quello
1861 che avviene nelle varie situazioni limite, da una parte potremo approfondire
1862 la comprensione del protocollo TCP/IP e dall'altra ricavare le indicazioni
1863 necessarie per essere in grado di scrivere applicazioni robuste, in grado di
1864 gestire anche i casi limite.
1865
1866 Il primo passo è compilare e lanciare il server (da root, per poter usare la
1867 porta 7 che è riservata), alla partenza esso eseguirà l'apertura passiva con
1868 la sequenza delle chiamate a \func{socket}, \func{bind}, \func{listen} e poi
1869 si bloccherà nella \func{accept}. A questo punto si potrà controllarne lo
1870 stato con \cmd{netstat}:
1871 \begin{verbatim}
1872 [piccardi@roke piccardi]$ netstat -at
1873 Active Internet connections (servers and established)
1874 Proto Recv-Q Send-Q Local Address           Foreign Address         State 
1875 ...
1876 tcp        0      0 *:echo                  *:*                     LISTEN
1877 ...
1878 \end{verbatim} %$
1879 che ci mostra come il socket sia in ascolto sulla porta richiesta, accettando
1880 connessioni da qualunque indirizzo e da qualunque porta e su qualunque
1881 interfaccia locale.
1882
1883 A questo punto si può lanciare il client, esso chiamerà \func{socket} e
1884 \func{connect}; una volta completato il three way handshake la connessione è
1885 stabilita; la \func{connect} ritornerà nel client\footnote{si noti che è
1886   sempre la \func{connect} del client a ritornare per prima, in quanto
1887   questo avviene alla ricezione del secondo segmento (l'ACK del server) del
1888   three way handshake, la \func{accept} del server ritorna solo dopo
1889   un altro mezzo RTT quando il terzo segmento (l'ACK del client) viene
1890   ricevuto.} e la \func{accept} nel server, ed usando di nuovo
1891 \cmd{netstat} otterremmo che:
1892 \begin{verbatim}
1893 Active Internet connections (servers and established)
1894 Proto Recv-Q Send-Q Local Address           Foreign Address         State
1895 tcp        0      0 *:echo                  *:*                     LISTEN
1896 tcp        0      0 roke:echo               gont:32981              ESTABLISHED
1897 \end{verbatim}
1898 mentre per quanto riguarda l'esecuzione dei programmi avremo che:
1899 \begin{itemize}
1900 \item il client chiama la funzione \code{ClientEcho} che si blocca sulla
1901   \func{fgets} dato che non si è ancora scritto nulla sul terminale.
1902 \item il server eseguirà una \func{fork} facendo chiamare al processo figlio
1903   la funzione \code{ServEcho}, quest'ultima si bloccherà sulla \func{read}
1904   dal socket sul quale ancora non sono presenti dati.
1905 \item il processo padre del server chiamerà di nuovo \func{accept}
1906   bloccandosi fino all'arrivo di un'altra connessione.
1907 \end{itemize}
1908 e se usiamo il comando \cmd{ps} per esaminare lo stato dei processi otterremo
1909 un risultato del tipo:
1910 \begin{verbatim}
1911 [piccardi@roke piccardi]$ ps ax
1912   PID TTY      STAT   TIME COMMAND
1913  ...  ...      ...    ...  ...
1914  2356 pts/0    S      0:00 ./echod
1915  2358 pts/1    S      0:00 ./echo 127.0.0.1
1916  2359 pts/0    S      0:00 ./echod
1917 \end{verbatim} %$
1918 (dove si sono cancellate le righe inutili) da cui si evidenzia la presenza di
1919 tre processi, tutti in stato di \textit{sleep} (vedi
1920 \tabref{tab:proc_proc_states}).
1921
1922 Se a questo punto si inizia a scrivere qualcosa sul client non sarà trasmesso
1923 niente fin tanto che non si prema il tasto di a capo (si ricordi quanto detto
1924 in \secref{sec:file_line_io} a proposito dell'I/O su terminale), solo allora
1925 \func{fgets} ritornerà ed il client scriverà quanto immesso sul socket, per
1926 poi passare a rileggere quanto gli viene inviato all'indietro dal server, che
1927 a sua volta sarà inviato sullo standard output, che nel caso ne provoca
1928 l'immediatamente stampa a video.
1929
1930
1931 \subsection{La conclusione normale}
1932 \label{sec:TCP_echo_conclusion}
1933
1934 Tutto quello che scriveremo sul client sarà rimandato indietro dal server e
1935 ristampato a video fintanto che non concluderemo l'immissione dei dati; una
1936 sessione tipica sarà allora del tipo: 
1937 \begin{verbatim}
1938 [piccardi@roke sources]$ ./echo 127.0.0.1
1939 Questa e` una prova
1940 Questa e` una prova
1941 Ho finito
1942 Ho finito
1943 \end{verbatim} %$
1944 che termineremo inviando un EOF dal terminale (usando la combinazione di tasti
1945 ctrl-D, che non compare a schermo); se eseguiamo un \cmd{netstat} a questo
1946 punto avremo:
1947 \begin{verbatim}
1948 [piccardi@roke piccardi]$ netstat -at 
1949 tcp        0      0 *:echo                  *:*                     LISTEN
1950 tcp        0      0 localhost:33032         localhost:echo          TIME_WAIT
1951 \end{verbatim} %$
1952 con il client che entra in \texttt{TIME\_WAIT}.
1953
1954 Esaminiamo allora in dettaglio la sequenza di eventi che porta alla
1955 terminazione normale della connessione, che ci servirà poi da riferimento
1956 quando affronteremo il comportamento in caso di conclusioni anomale:
1957
1958 \begin{enumerate}
1959 \item inviando un carattere di EOF da terminale la \func{fgets} ritorna
1960   restituendo un puntatore nullo che causa l'uscita dal ciclo di \code{while},
1961   così la funzione \code{ClientEcho} ritorna.
1962 \item al ritorno di \code{ClientEcho} ritorna anche la funzione \code{main}, e
1963   come parte del processo terminazione tutti i file descriptor vengono chiusi
1964   (si ricordi quanto detto in \secref{sec:proc_term_conclusion}); questo causa
1965   la chiusura del socket di comunicazione; il client allora invierà un FIN al
1966   server a cui questo risponderà con un ACK.  A questo punto il client verrà a
1967   trovarsi nello stato \texttt{FIN\_WAIT\_2} ed il server nello stato
1968   \texttt{CLOSE\_WAIT} (si riveda quanto spiegato in
1969   \secref{sec:TCP_conn_term}).
1970 \item quando il server riceve il FIN la \func{read} del processo figlio che
1971   gestisce la connessione ritorna restituendo 0 causando così l'uscita dal
1972   ciclo e il ritorno di \code{ServEcho}, a questo punto il processo figlio
1973   termina chiamando \func{exit}.
1974 \item all'uscita del figlio tutti i file descriptor vengono chiusi, la
1975   chiusura del socket connesso fa sì che venga effettuata la sequenza finale
1976   di chiusura della connessione, viene emesso un FIN dal server che riceverà
1977   un ACK dal client, a questo punto la connessione è conclusa e il client
1978   resta nello stato \texttt{TIME\_WAIT}.
1979 \end{enumerate}
1980
1981
1982 \subsection{La gestione dei processi figli}
1983 \label{sec:TCP_child_hand}
1984
1985 Tutto questo riguarda la connessione, c'è però da tenere conto dell'effetto
1986 del procedimento di chiusura del processo figlio nel server (si veda quanto
1987 esaminato in \secref{sec:proc_termination}). In questo caso avremo l'invio del
1988 segnale \const{SIGCHLD} al padre, ma dato che non si è installato un
1989 gestore e che l'azione predefinita per questo segnale è quella di essere
1990 ignorato, non avendo predisposto la ricezione dello stato di terminazione,
1991 otterremo che il processo figlio entrerà nello stato di zombie\index{zombie}
1992 (si riveda quanto illustrato in \secref{sec:sig_sigchld}), come risulterà
1993 ripetendo il comando \cmd{ps}:
1994 \begin{verbatim}
1995  2356 pts/0    S      0:00 ./echod
1996  2359 pts/0    Z      0:00 [echod <defunct>]
1997 \end{verbatim}
1998
1999 Dato che non è il caso di lasciare processi zombie\index{zombie}, occorrerà
2000 ricevere opportunamente lo stato di terminazione del processo (si veda
2001 \secref{sec:proc_wait}), cosa che faremo utilizzando \const{SIGCHLD} secondo
2002 quanto illustrato in \secref{sec:sig_sigchld}. Una prima modifica al nostro
2003 server è pertanto quella di inserire la gestione della terminazione dei
2004 processi figli attraverso l'uso di un gestore.  Per questo useremo la funzione
2005 \code{Signal} (che abbiamo illustrato in \figref{fig:sig_Signal_code}), per
2006 installare il gestore che riceve i segnali dei processi figli terminati già
2007 visto in \figref{fig:sig_sigchld_handl}.  Basterà allora aggiungere il
2008 seguente codice: \includecodesnip{listati/sigchildhand.c}
2009 \noindent
2010 all'esempio illustrato in \figref{fig:TCP_echo_server_first_code}.
2011
2012 In questo modo però si introduce un altro problema. Si ricordi infatti che,
2013 come spiegato in \secref{sec:sig_gen_beha}, quando un programma si trova in
2014 stato di \texttt{sleep} durante l'esecuzione di una system call, questa viene
2015 interrotta alla ricezione di un segnale. Per questo motivo, alla fine
2016 dell'esecuzione del gestore del segnale, se questo ritorna, il programma
2017 riprenderà l'esecuzione ritornando dalla system call interrotta con un errore
2018 di \errcode{EINTR}.
2019
2020 Vediamo allora cosa comporta tutto questo nel nostro caso: quando si chiude il
2021 client, il processo figlio che gestisce la connessione terminerà, ed il padre,
2022 per evitare la creazione di zombie, riceverà il segnale \const{SIGCHLD}
2023 eseguendo il relativo gestore. Al ritorno del gestore però l'esecuzione nel
2024 padre ripartirà subito con il ritorno della funzione \func{accept} (a meno di
2025 un caso fortuito in cui il segnale arriva durante l'esecuzione del programma
2026 in risposta ad una connessione) con un errore di \errcode{EINTR}. Non avendo
2027 previsto questa eventualità il programma considera questo un errore fatale
2028 terminando a sua volta con un messaggio del tipo:
2029 \begin{verbatim}
2030 [root@gont sources]# ./echod -i
2031 accept error: Interrupted system call
2032 \end{verbatim}%#
2033
2034 Come accennato in \secref{sec:sig_gen_beha} le conseguenze di questo
2035 comportamento delle system call possono essere superate in due modi diversi,
2036 il più semplice è quello di modificare il codice di \func{Signal} per
2037 richiedere il riavvio automatico delle system call interrotte secondo la
2038 semantica di BSD, usando l'opzione \const{SA\_RESTART} di \func{sigaction};
2039 rispetto a quanto visto in \figref{fig:sig_Signal_code}. Definiremo allora la
2040 nuova funzione \func{SignalRestart}\footnote{anche questa è definita, insieme
2041   alle altre funzioni riguardanti la gestione dei segnali, nel file
2042   \file{SigHand.c}, il cui contento completo può essere trovato negli esempi
2043   allegati.} come mostrato in \figref{fig:sig_SignalRestart_code}, ed
2044 installeremo il gestore usando quest'ultima.
2045
2046 \begin{figure}[!htb]
2047   \footnotesize  \centering
2048   \begin{minipage}[c]{15.6cm}
2049     \includecodesample{listati/SignalRestart.c}
2050   \end{minipage}  
2051   \normalsize 
2052   \caption{La funzione \funcd{SignalRestart}, che installa un gestore di
2053     segnali in semantica BSD per il riavvio automatico delle system call
2054     interrotte.}
2055   \label{fig:sig_SignalRestart_code}
2056 \end{figure}
2057
2058 Come si può notare questa funzione è identica alla precedente \func{Signal},
2059 illustrata in \figref{fig:sig_Signal_code}, solo che in questo caso invece di
2060 inizializzare a zero il campo \var{sa\_flags} di \struct{sigaction}, lo si
2061 inizializza (\texttt{\small 5}) al valore \const{SA\_RESTART}. Usando questa
2062 funzione al posto di \func{Signal} nel server non è necessaria nessuna altra
2063 modifica: le system call interrotte saranno automaticamente riavviate, e
2064 l'errore \errcode{EINTR} non si manifesterà più.
2065
2066 La seconda soluzione è più invasiva e richiede di controllare tutte le volte
2067 l'errore restituito dalle varie system call, ripetendo la chiamata qualora
2068 questo corrisponda ad \errcode{EINTR}. Questa soluzione ha però il pregio
2069 della portabilità, infatti lo standard POSIX dice che la funzionalità di
2070 riavvio automatico delle system call, fornita da \const{SA\_RESTART}, è
2071 opzionale, per cui non è detto che essa sia disponibile su qualunque sistema.
2072 Inoltre in certi casi,\footnote{Stevens in \cite{UNP1} accenna che la maggior
2073   parte degli Unix derivati da BSD non fanno ripartire \func{select}; altri
2074   non riavviano neanche \func{accept} e \func{recvfrom}, cosa che invece nel
2075   caso di Linux viene sempre fatta.} anche quando questa è presente, non è
2076 detto possa essere usata con \func{accept}. 
2077
2078
2079 La portabilità nella gestione dei segnali però viene al costo di una
2080 riscrittura parziale del server, la nuova versione di questo, in cui si sono
2081 introdotte una serie di nuove opzioni che ci saranno utili per il debug, è
2082 mostrata in \figref{fig:TCP_echo_server_code_second}, dove si sono riportate
2083 la sezioni di codice modificate nella seconda versione del programma, il
2084 sorgente completo di quest'ultimo si trova nel file
2085 \file{TCP\_echod\_second.c} dei sorgenti allegati alla guida.
2086
2087 La prima modifica effettuata è stata quella di introdurre una nuova opzione a
2088 riga di comando, \texttt{-c}, che permette di richiedere il comportamento
2089 compatibile nella gestione di \const{SIGCHLD} al posto della semantica BSD
2090 impostando la variabile \var{compat} ad un valore non nullo. Questa è
2091 preimpostata al valore nullo, cosicché se non si usa questa opzione il
2092 comportamento di default del server è di usare la semantica BSD. 
2093
2094 Una seconda opzione aggiunta è quella di inserire un tempo di attesa fisso
2095 specificato in secondi fra il ritorno della funzione \func{listen} e la
2096 chiamata di \func{accept}, specificabile con l'opzione \texttt{-w}, che
2097 permette di impostare la variabile \var{waiting}.  Infine si è introdotta una
2098 opzione \texttt{-d} per abilitare il debugging che imposta ad un valore non
2099 nullo la variabile \var{debugging}. Al solito si è omessa da
2100 \figref{fig:TCP_echo_server_code_second} la sezione di codice relativa alla
2101 gestione di tutte queste opzioni, che può essere trovata nel sorgente del
2102 programma.
2103
2104 \begin{figure}[!htb]
2105   \footnotesize \centering
2106   \begin{minipage}[c]{15.6cm}
2107     \includecodesample{listati/TCP_echod_second.c}
2108   \end{minipage} 
2109   \normalsize
2110   \caption{La sezione nel codice della seconda versione del server
2111     per il servizio \textit{echo} modificata per tener conto dell'interruzione
2112     delle system call.}
2113   \label{fig:TCP_echo_server_code_second}
2114 \end{figure}
2115
2116 Vediamo allora come è cambiato il nostro server; una volta definite le
2117 variabili e trattate le opzioni il primo passo (\texttt{\small 9--13}) è
2118 verificare la semantica scelta per la gestione di \const{SIGCHLD}, a seconda
2119 del valore di \var{compat} (\texttt{\small 9}) si installa il gestore con la
2120 funzione \func{Signal} (\texttt{\small 10}) o con \texttt{SignalRestart}
2121 (\texttt{\small 12}), essendo quest'ultimo il valore di default.
2122
2123 Tutta la sezione seguente, che crea il socket, cede i privilegi di
2124 amministratore ed eventualmente lancia il programma come demone, è rimasta
2125 invariata e pertanto è stata omessa in
2126 \figref{fig:TCP_echo_server_code_second}; l'unica modifica effettuata prima
2127 dell'entrata nel ciclo principale è stata quella di aver introdotto, subito
2128 dopo la chiamata (\texttt{\small 17--20}) alla funzione \func{listen}, una
2129 eventuale pausa con una condizione (\texttt{\small 21}) sulla variabile
2130 \var{waiting}, che viene inizializzata, con l'opzione \code{-w Nsec}, al
2131 numero di secondi da aspettare (il valore preimpostato è nullo).
2132
2133 Si è potuto lasciare inalterata tutta la sezione di creazione del socket
2134 perché nel server l'unica chiamata ad una system call critica, che può essere
2135 interrotta dall'arrivo di \const{SIGCHLD}, è quella ad \func{accept}, che è
2136 l'unica funzione che può mettere il processo padre in stato di sleep nel
2137 periodo in cui un figlio può terminare; si noti infatti come le altre
2138 \textit{slow system call}\footnote{si ricordi la distinzione fatta in
2139   \secref{sec:sig_gen_beha}.} o sono chiamate prima di entrare nel ciclo
2140 principale, quando ancora non esistono processi figli, o sono chiamate dai
2141 figli stessi e non risentono di \const{SIGCHLD}.
2142
2143 Per questo l'unica modifica sostanziale nel ciclo principale (\texttt{\small
2144   23--42}), rispetto precedente versione di \figref{fig:TCP_ServEcho_first}, è
2145 nella sezione (\texttt{\small 26--30}) in cui si effettua la chiamata di
2146 \func{accept}.  Quest'ultima viene effettuata (\texttt{\small 26--27})
2147 all'interno di un ciclo di \code{while}\footnote{la sintassi del C relativa a
2148   questo ciclo può non essere del tutto chiara. In questo caso infatti si è
2149   usato un ciclo vuoto che non esegue nessuna istruzione, in questo modo
2150   quello che viene ripetuto con il ciclo è soltanto il codice che esprime la
2151   condizione all'interno del \code{while}.}  che la ripete indefinitamente
2152 qualora in caso di errore il valore di \var{errno} sia \errcode{EINTR}. Negli
2153 altri casi si esce in caso di errore effettivo (\texttt{\small 27--29}),
2154 altrimenti il programma prosegue.
2155
2156 Si noti che in questa nuova versione si è aggiunta una ulteriore sezione
2157 (\texttt{\small 31--39}) di aiuto per il debug del programma, che eseguita con
2158 un controllo (\texttt{\small 31}) sul valore della variabile \var{debugging}
2159 impostato dall'opzione \texttt{-d}. Qualora questo sia nullo, come
2160 preimpostato, non accade nulla. altrimenti (\texttt{\small 32}) l'indirizzo
2161 ricevuto da \var{accept} viene convertito in una stringa che poi
2162 (\texttt{\small 33--38}) viene opportunamente stampata o sullo schermo o nei
2163 log.
2164
2165
2166
2167
2168 \section{I vari scenari critici}
2169 \label{sec:TCP_echo_critical}
2170
2171 Con le modifiche viste in \secref{sec:TCP_child_hand} il nostro esempio
2172 diventa in grado di affrontare la gestione ordinaria delle connessioni, ma un
2173 server di rete deve tenere conto che, al contrario di quanto avviene per i
2174 server che operano nei confronti di processi presenti sulla stessa macchina,
2175 la rete è di sua natura inaffidabile, per cui è necessario essere in grado di
2176 gestire tutta una serie di situazioni critiche che non esistono per i processi
2177 locali.
2178
2179
2180 \subsection{La terminazione precoce della connessione}
2181 \label{sec:TCP_conn_early_abort}
2182
2183 La prima situazione critica è quella della terminazione precoce, causata da un
2184 qualche errore sulla rete, della connessione effettuata da un client. Come
2185 accennato in \secref{sec:TCP_func_accept} la funzione \func{accept} riporta
2186 tutti gli eventuali errori di rete pendenti su una connessione sul
2187 \textit{connected socket}. Di norma questo non è un problema, in quanto non
2188 appena completata la connessione, \func{accept} ritorna e l'errore sarà
2189 rilevato in seguito, dal processo che gestisce la connessione, alla prima
2190 chiamata di una funzione che opera sul socket.
2191
2192 È però possibile, dal punto di vista teorico, incorrere anche in uno scenario
2193 del tipo di quello mostrato in \figref{fig:TCP_early_abort}, in cui la
2194 connessione viene abortita sul lato client per un qualche errore di rete con
2195 l'invio di un segmento RST, prima che nel server sia stata chiamata la
2196 funzione \func{accept}.
2197
2198 \begin{figure}[htb]
2199   \centering
2200   \includegraphics[width=10cm]{img/tcp_client_early_abort}  
2201   \caption{Un possibile caso di terminazione precoce della connessione.}
2202   \label{fig:TCP_early_abort}
2203 \end{figure}
2204
2205 Benché questo non sia un fatto comune, un evento simile può essere osservato
2206 con dei server molto occupati. In tal caso, con una struttura del server
2207 simile a quella del nostro esempio, in cui la gestione delle singole
2208 connessioni è demandata a processi figli, può accadere che il three way
2209 handshake venga completato e la relativa connessione abortita subito dopo,
2210 prima che il padre, per via del carico della macchina, abbia fatto in tempo ad
2211 eseguire la chiamata ad \func{accept}. Di nuovo si ha una situazione analoga
2212 a quella illustrata in \figref{fig:TCP_early_abort}, in cui la connessione
2213 viene stabilita, ma subito dopo si ha una condizione di errore che la chiude
2214 prima che essa sia stata accettata dal programma.
2215
2216 Questo significa che, oltre alla interruzione da parte di un segnale, che
2217 abbiamo trattato in \secref{sec:TCP_child_hand} nel caso particolare di
2218 \const{SIGCHLD}, si possono ricevere altri errori non fatali all'uscita di
2219 \func{accept}, che come nel caso precedente, necessitano semplicemente la
2220 ripetizione della chiamata senza che si debba uscire dal programma. In questo
2221 caso anche la versione modificata del nostro server non sarebbe adatta, in
2222 quanto uno di questi errori causerebbe la terminazione dello stesso. In Linux
2223 i possibili errori di rete non fatali, riportati sul socket connesso al
2224 ritorno di \func{accept}, sono \errcode{ENETDOWN}, \errcode{EPROTO},
2225 \errcode{ENOPROTOOPT}, \errcode{EHOSTDOWN}, \errcode{ENONET},
2226 \errcode{EHOSTUNREACH}, \errcode{EOPNOTSUPP} e \errcode{ENETUNREACH}.
2227
2228 Si tenga presente che questo tipo di terminazione non è riproducibile
2229 terminando il client prima della chiamata ad \func{accept}, come si potrebbe
2230 fare usando l'opzione \texttt{-w} per introdurre una pausa dopo il lancio del
2231 demone, in modo da poter avere il tempo per lanciare e terminare una
2232 connessione usando il programma client. In tal caso infatti, alla terminazione
2233 del client, il socket associato alla connessione viene semplicemente chiuso,
2234 attraverso la sequenza vista in \secref{sec:TCP_conn_term}, per cui la
2235 \func{accept} ritornerà senza errori, e si avrà semplicemente un end-of-file
2236 al primo accesso al socket. Nel caso di Linux inoltre, anche qualora si
2237 modifichi il client per fargli gestire l'invio di un segmento di RST alla
2238 chiusura dal socket (come suggerito da Stevens in \cite{UNP1}), non si ha
2239 nessun errore al ritorno di \funcd{accept} quanto un errore di
2240 \errcode{ECONNRESET} al primo tentativo di accesso al socket.
2241
2242
2243
2244 \subsection{Il crollo del server}
2245 \label{sec:TCP_server_crash}
2246
2247 Un secondo caso critico è quello in cui si ha il crollo del server. In tal
2248 caso si suppone che il processo del server termini per un errore fatale, cosa
2249 che potremo simulare inviandogli un segnale di terminazione. La conclusione
2250 del processo comporta la chiusura di tutti i file aperti, compresi tutti i
2251 socket relativi a connessioni stabilite; questo significa che al momento del
2252 crollo del servizio il client riceverà un FIN dal server in corrispondenza
2253 della chiusura del socket.
2254
2255
2256
2257
2258
2259 %%% Local Variables: 
2260 %%% mode: latex
2261 %%% TeX-master: "gapil"
2262 %%% End: