Revisioni varie, e fatta la figura degli stati del TCP
[gapil.git] / elemtcp.tex
1 %% elemtcp.tex
2 %%
3 %% Copyright (C) 2000-2002 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 elementari}
12 \label{cha:elem_TCP_sock}
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   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 nell'RFC~1323) sono meno comuni;
165 vengono anche dette \textit{long fat pipe options} dato che questo è il nome
166 che viene dato alle connessioni caratterizzate da alta velocità o da ritardi
167 elevati. In ogni caso Linux supporta pienamente entrambe le opzioni.
168
169 \subsection{La terminazione della connessione}
170 \label{sec:TCP_conn_term}
171
172 Mentre per creare una connessione occorre un interscambio di tre segmenti, la
173 procedura di chiusura ne richiede quattro; ancora una volta si può fare
174 riferimento al codice degli esempi \figref{fig:TCP_cli_code} e
175 \figref{fig:TCP_serv_code}, in questo caso la successione degli eventi è la
176 seguente:
177
178 \begin{enumerate}
179 \item Un processo ad uno dei due capi chiama la funzione \func{close}, dando
180   l'avvio a quella che viene chiamata \textsl{chiusura attiva} (o
181   \textit{active close}). Questo comporta l'emissione di un segmento FIN, che
182   significa che si è finito con l'invio dei dati sulla connessione.
183   
184 \item L'altro capo della connessione riceve il FIN ed esegue la
185   \textsl{chiusura passiva} (o \textit{passive close}); al FIN, come ad ogni
186   altro pacchetto, viene risposto con un ACK. Inoltre il ricevimento del FIN
187   viene segnalato al processo che ha aperto il socket (dopo che ogni altro
188   eventuale dato rimasto in coda è stato ricevuto) come un end-of-file sulla
189   lettura, questo perché il ricevimento di un FIN significa che non si
190   riceveranno altri dati sulla connessione.
191
192 \item Dopo un certo tempo anche il secondo processo chiamerà la funzione
193   \func{close} sul proprio socket, causando l'emissione di un altro segmento
194   FIN. 
195
196 \item L'altro capo della connessione riceverà il FIN conclusivo e risponderà
197   con un ACK.
198 \end{enumerate}
199
200 Dato che in questo caso sono richiesti un FIN ed un ACK per ciascuna direzione
201 normalmente i segmenti scambiati sono quattro.  Questo non è vero sempre
202 giacché in alcune situazioni il FIN del passo 1) è inviato insieme a dei dati.
203 Inoltre è possibile che i segmenti inviati nei passi 2 e 3 dal capo che
204 effettua la chiusura passiva, siano accorpati in un singolo segmento. In
205 \figref{fig:TCP_close} si è rappresentato graficamente lo sequenza di
206 scambio dei segmenti che conclude la connessione.
207
208 \begin{figure}[htb]
209   \centering  
210   \includegraphics[width=10cm]{img/tcp_close}  
211   \caption{La chiusura di una connessione TCP.}
212   \label{fig:TCP_close}
213 \end{figure}
214
215 Come per il SYN anche il FIN occupa un byte nel numero di sequenza, per cui
216 l'ACK riporterà un \textit{acknowledge number} incrementato di uno. 
217
218 Si noti che, nella sequenza di chiusura, fra i passi 2 e 3, è in teoria
219 possibile che si mantenga un flusso di dati dal capo della connessione che
220 deve ancora eseguire la chiusura passiva a quello che sta eseguendo la
221 chiusura attiva.  Nella sequenza indicata i dati verrebbero persi, dato che si
222 è chiuso il socket dal lato che esegue la chiusura attiva; esistono tuttavia
223 situazioni in cui si vuole poter sfruttare questa possibilità, usando una
224 procedura che è chiamata \textit{half-close}; torneremo su questo aspetto e su
225 come utilizzarlo in \secref{xxx_shutdown}, quando parleremo della funzione
226 \func{shutdown}.
227
228 La emissione del FIN avviene quando il socket viene chiuso, questo però non
229 avviene solo per la chiamata della funzione \func{close} (come faremo in
230 \figref{fig:TCP_serv_code}), ma anche alla terminazione di un processo (come
231 vedremo in \figref{fig:TCP_cli_code}). Questo vuol dire ad esempio che se un
232 processo viene terminato da un segnale tutte le connessioni aperte verranno
233 chiuse.
234
235 Infine occorre sottolineare che, benché nella figura (e nell'esempio che
236 vedremo più avanti in \secref{sec:TCPsimp_echo}) sia stato il client ad
237 eseguire la chiusura attiva, nella realtà questa può essere eseguita da uno
238 qualunque dei due capi della comunicazione (come nell'esempio di
239 \figref{fig:TCP_serv_code}), e anche se il caso più comune resta quello del
240 client, ci sono alcuni servizi, il principale dei quali è l'HTTP, per i quali
241 è il server ad effettuare la chiusura attiva.
242
243
244 \subsection{Un esempio di connessione}
245 \label{sec:TCP_conn_dia}
246
247 Come abbiamo visto le operazioni del TCP nella creazione e conclusione di una
248 connessione sono piuttosto complesse, ed abbiamo esaminato soltanto quelle
249 relative ad un andamento normale.  In \secref{sec:TCP_states} vedremo con
250 maggiori dettagli che una connessione può assumere vari stati, che ne
251 caratterizzano il funzionamento, e che sono quelli che vengono riportati dal
252 comando \cmd{netstat}, per ciascun socket TCP aperto, nel campo
253 \textit{State}.
254
255 Non possiamo affrontare qui una descrizione completa del funzionamento del
256 protocollo; un approfondimento sugli aspetti principali si trova in
257 \secref{sec:tcp_protocol}, ma per una trattazione completa il miglior
258 riferimento resta \cite{TCPIll1}. Qui ci limiteremo a descrivere brevemente un
259 semplice esempio di connessione e le transizioni che avvengono nei due casi
260 appena citati (creazione e terminazione della connessione).
261
262 In assenza di connessione lo stato del TCP è \texttt{CLOSED}; quando una
263 applicazione esegue una apertura attiva il TCP emette un SYN e lo stato
264 diventa \texttt{SYN\_SENT}; quando il TCP riceve la risposta del SYN$+$ACK
265 emette un ACK e passa allo stato \texttt{ESTABLISHED}; questo è lo stato
266 finale in cui avviene la gran parte del trasferimento dei dati.
267
268 Dal lato server in genere invece il passaggio che si opera con l'apertura
269 passiva è quello di portare il socket dallo stato \texttt{CLOSED} allo
270 stato \texttt{LISTEN} in cui vengono accettate le connessioni.
271
272 Dallo stato \texttt{ESTABLISHED} si può uscire in due modi; se un'applicazione
273 chiama la funzione \texttt{close} prima di aver ricevuto un
274 \textit{end-of-file} (chiusura attiva) la transizione è verso lo stato
275 \texttt{FIN\_WAIT\_1}; se invece l'applicazione riceve un FIN nello stato
276 \texttt{ESTABLISHED} (chiusura passiva) la transizione è verso lo stato
277 \texttt{CLOSE\_WAIT}.
278
279 In \figref{fig:TCP_conn_example} è riportato lo schema dello scambio dei
280 pacchetti che avviene per una un esempio di connessione, insieme ai vari stati
281 che il protocollo viene ad assumere per i due lati, server e client.
282
283 \begin{figure}[htb]
284   \centering
285   \includegraphics[width=9cm]{img/tcp_connection}  
286   \caption{Schema dello scambio di pacchetti per un esempio di connessione.}
287   \label{fig:TCP_conn_example}
288 \end{figure}
289
290 La connessione viene iniziata dal client che annuncia un MSS di 1460, un
291 valore tipico con Linux per IPv4 su Ethernet, il server risponde con lo stesso
292 valore (ma potrebbe essere anche un valore diverso).
293
294 Una volta che la connessione è stabilita il client scrive al server una
295 richiesta (che assumiamo stare in un singolo segmento, cioè essere minore dei
296 1460 byte annunciati dal server), quest'ultimo riceve la richiesta e
297 restituisce una risposta (che di nuovo supponiamo stare in un singolo
298 segmento). Si noti che l'acknowledge della richiesta è mandato insieme alla
299 risposta: questo viene chiamato \textit{piggybacking} ed avviene tutte le
300 volte che che il server è sufficientemente veloce a costruire la risposta; in
301 caso contrario si avrebbe prima l'emissione di un ACK e poi l'invio della
302 risposta.
303
304 Infine si ha lo scambio dei quattro segmenti che terminano la connessione
305 secondo quanto visto in \secref{sec:TCP_conn_term}; si noti che il capo della
306 connessione che esegue la chiusura attiva entra nello stato
307 \texttt{TIME\_WAIT}, sul cui significato torneremo fra poco.
308
309 È da notare come per effettuare uno scambio di due pacchetti (uno di richiesta
310 e uno di risposta) il TCP necessiti di ulteriori otto segmenti, se invece si
311 fosse usato UDP sarebbero stati sufficienti due soli pacchetti. Questo è il
312 costo che occorre pagare per avere l'affidabilità garantita dal TCP, se si
313 fosse usato UDP si sarebbe dovuto trasferire la gestione di tutta una serie di
314 dettagli (come la verifica della ricezione dei pacchetti) dal livello del
315 trasporto all'interno dell'applicazione.
316
317 Quello che è bene sempre tenere presente è allora quali sono le esigenze che
318 si hanno in una applicazione di rete, perché non è detto che TCP sia la
319 miglior scelta in tutti i casi (ad esempio se si devono solo scambiare dati
320 già organizzati in piccoli pacchetti l'overhead aggiunto può essere eccessivo)
321 per questo esistono applicazioni che usano UDP e lo fanno perché nel caso
322 specifico le sue caratteristiche di velocità e compattezza nello scambio dei
323 dati rispondono meglio alle esigenze che devono essere affrontate.
324
325 \subsection{Lo stato \texttt{TIME\_WAIT}}
326 \label{sec:TCP_time_wait}
327
328 Come riportato da Stevens in \cite{UNP1} lo stato \texttt{TIME\_WAIT} è
329 probabilmente uno degli aspetti meno compresi del protocollo TCP, è infatti
330 comune trovare domande su come sia possibile evitare che un'applicazione resti
331 in questo stato lasciando attiva una connessione ormai conclusa; la risposta è
332 che non deve essere fatto, ed il motivo cercheremo di spiegarlo adesso.
333
334 Come si è visto nell'esempio precedente (vedi \figref{fig:TCP_conn_example})
335 \texttt{TIME\_WAIT} è lo stato finale in cui il capo di una connessione che
336 esegue la chiusura attiva resta prima di passare alla chiusura definitiva
337 della connessione. Il tempo in cui l'applicazione resta in questo stato deve
338 essere due volte la MSL (\textit{Maximum Segment Lifetime}).
339
340 La MSL è la stima del massimo periodo di tempo che un pacchetto IP può vivere
341 sulla rete; questo tempo è limitato perché ogni pacchetto IP può essere
342 ritrasmesso dai router un numero massimo di volte (detto \textit{hop limit}).
343 Il numero di ritrasmissioni consentito è indicato dal campo TTL dell'header di
344 IP (per maggiori dettagli vedi \secref{sec:IP_xxx}), e viene decrementato ad
345 ogni passaggio da un router; quando si annulla il pacchetto viene scartato.
346 Siccome il numero è ad 8 bit il numero massimo di ``\textsl{salti}'' è di 255,
347 pertanto anche se il TTL (da \textit{time to live}) non è propriamente un
348 limite sul tempo di vita, si stima che un pacchetto IP non possa restare nella
349 rete per più di MSL secondi.
350
351 Ogni implementazione del TCP deve scegliere un valore per la MSL (l'RFC~1122
352 raccomanda 2 minuti, Linux usa 30 secondi), questo comporta una durata dello
353 stato \texttt{TIME\_WAIT} che a seconda delle implementazioni può variare fra
354 1 a 4 minuti.
355
356 Lo stato \texttt{TIME\_WAIT} viene utilizzato dal protocollo per due motivi
357 principali:
358 \begin{enumerate}
359 \item implementare in maniera affidabile la terminazione della connessione
360   in entrambe le direzioni.
361 \item consentire l'eliminazione dei segmenti duplicati dalla rete. 
362 \end{enumerate}
363
364 Il punto è che entrambe le ragioni sono importanti, anche se spesso si fa
365 riferimento solo alla prima; ma è solo se si tiene conto della seconda che si
366 capisce il perché della scelta di un tempo pari al doppio della MSL come
367 durata di questo stato.
368
369 Il primo dei due motivi precedenti si può capire tornando a
370 \figref{fig:TCP_conn_example}: assumendo che l'ultimo ACK della sequenza
371 (quello del capo che ha eseguito la chiusura attiva) vanga perso, chi esegue
372 la chiusura passiva non ricevendo risposta rimanderà un ulteriore FIN, per
373 questo motivo chi esegue la chiusura attiva deve mantenere lo stato della
374 connessione per essere in grado di reinviare l'ACK e chiuderla correttamente.
375 Se non fosse così la risposta sarebbe un RST (un altro tipo si segmento) che
376 verrebbe interpretato come un errore.
377
378 Se il TCP deve poter chiudere in maniera pulita entrambe le direzioni della
379 connessione allora deve essere in grado di affrontare la perdita di uno
380 qualunque dei quattro segmenti che costituiscono la chiusura. Per questo
381 motivo lo stato \texttt{TIME\_WAIT} deve essere mantenuto anche dopo l'invio
382 dell'ultimo ACK per poter essere in grado di poterne gestire l'eventuale
383 ritrasmissione in caso di perdita.
384
385 Il secondo motivo è più complesso da capire, e necessita di una spiegazione
386 degli scenari in cui accade che i pacchetti si possano perdere nella rete o
387 restare intrappolati, per poi riemergere in un secondo tempo.
388
389 Il caso più comune in cui questo avviene è quello di anomalie
390 nell'instradamento; può accadere cioè che un router smetta di funzionare o che
391 una connessione fra due router si interrompa. In questo caso i protocolli di
392 instradamento dei pacchetti possono impiegare diverso tempo (anche dell'ordine
393 dei minuti) prima di trovare e stabilire un percorso alternativo per i
394 pacchetti. Nel frattempo possono accadere casi in cui un router manda i
395 pacchetti verso un'altro e quest'ultimo li rispedisce indietro, o li manda ad
396 un terzo router che li rispedisce al primo, si creano cioè dei circoli (i
397 cosiddetti \textit{routing loop}) in cui restano intrappolati i pacchetti.
398
399 Se uno di questi pacchetti intrappolati è un segmento TCP chi l'ha inviato,
400 non ricevendo un ACK in risposta, provvederà alla ritrasmissione e se nel
401 frattempo sarà stata stabilita una strada alternativa il pacchetto ritrasmesso
402 giungerà a destinazione.
403
404 Ma se dopo un po' di tempo (che non supera il limite dell'MSL, dato che
405 altrimenti verrebbe ecceduto il TTL) l'anomalia viene a cessare il circolo di
406 instradamento viene spezzato i pacchetti intrappolati potranno essere inviati
407 alla destinazione finale, con la conseguenza di avere dei pacchetti duplicati;
408 questo è un caso che il TCP deve essere in grado di gestire.
409
410 Allora per capire la seconda ragione per l'esistenza dello stato
411 \texttt{TIME\_WAIT} si consideri il caso seguente: si supponga di avere una
412 connessione fra l'IP \texttt{195.110.112.236} porta 1550 e l'IP
413 \texttt{192.84.145.100} porta 22, che questa venga chiusa e che poco dopo si
414 ristabilisca la stessa connessione fra gli stessi IP sulle stesse porte
415 (quella che viene detta, essendo gli stessi porte e numeri IP, una nuova
416 \textsl{incarnazione} della connessione precedente); in questo caso ci si
417 potrebbe trovare con dei pacchetti duplicati relativi alla precedente
418 connessione che riappaiono nella nuova.
419
420 Ma fintanto che il socket non è chiuso una nuova incarnazione non può essere
421 creata: per questo un socket TCP resta sempre nello stato \texttt{TIME\_WAIT}
422 per un periodo di 2MSL, in modo da attendere MSL secondi per essere sicuri che
423 tutti i pacchetti duplicati in arrivo siano stati ricevuti (e scartati) o che
424 nel frattempo siano stati eliminati dalla rete, e altri MSL secondi per essere
425 sicuri che lo stesso avvenga per le risposte nella direzione opposta.
426
427 In questo modo, prima che venga creata una nuova connessione, il protocollo
428 TCP si assicura che tutti gli eventuali segmenti residui di una precedente
429 connessione, che potrebbero causare disturbi, siano stati eliminati dalla
430 rete.
431
432
433 \subsection{I numeri di porta}
434 \label{sec:TCP_port_num}
435
436 In un ambiente multitasking in un dato momento più processi devono poter usare
437 sia UDP che TCP, e ci devono poter essere più connessioni in contemporanea.
438 Per poter tenere distinte le diverse connessioni entrambi i protocolli usano i
439 \textsl{numeri di porta}, che fanno parte, come si può vedere in
440 \secref{sec:sock_sa_ipv4} e \secref{sec:sock_sa_ipv6} pure delle strutture
441 degli indirizzi del socket.
442
443 Quando un client contatta un server deve poter identificare con quale dei vari
444 possibili server attivi intende parlare. Sia TCP che UDP definiscono un gruppo
445 di \textsl{porte conosciute} (le cosiddette \textit{well-known port}) che
446 identificano una serie di servizi noti (ad esempio la porta 22 identifica il
447 servizio \texttt{ssh}) effettuati da appositi server che rispondono alle
448 connessioni verso tali porte.
449
450 D'altra parte un client non ha necessità di usare un numero di porta
451 specifico, per cui in genere vengono usate le cosiddette \textsl{porte
452   effimere} (o \textit{ephemeral ports}) cioè porte a cui non è assegnato
453 nessun servizio noto e che vengono assegnate automaticamente dal kernel alla
454 creazione della connessione. Queste sono dette effimere in quanto vengono
455 usate solo per la durata della connessione, e l'unico requisito che deve
456 essere soddisfatto è che ognuna di esse sia assegnata in maniera univoca.
457
458 La lista delle porte conosciute è definita dall'RFC~1700 che contiene l'elenco
459 delle porte assegnate dalla IANA (la \textit{Internet Assigned Number
460   Authority}) ma l'elenco viene costantemente aggiornato e pubblicato su
461 internet (una versione corrente si può trovare all'indirizzo
462 \texttt{ftp://ftp.isi.edu/in-notes/iana/assignements/port-numbers}); inoltre
463 in un sistema unix-like un analogo elenco viene mantenuto nel file
464 \file{/etc/services}, con la corrispondenza fra i vari numeri di porta ed il
465 nome simbolico del servizio.  I numeri sono divisi in tre intervalli:
466
467 \begin{enumerate}
468 \item \textsl{le porte conosciute}. I numeri da 0 a 1023. Queste sono
469   controllate e assegnate dalla IANA. Se è possibile la stessa porta è
470   assegnata allo stesso servizio sia su UDP che su TCP (ad esempio la porta 22
471   è assegnata a ssh su entrambi i protocolli, anche se viene usata solo dal
472   TCP).
473   
474 \item \textsl{le porte registrate}. I numeri da 1024 a 49151. Queste porte non
475   sono controllate dalla IANA, che però registra ed elenca chi usa queste
476   porte come servizio agli utenti. Come per le precedenti si assegna una porta
477   ad un servizio sia per TCP che UDP anche se poi il servizio è implementato
478   solo su TCP. Ad esempio X Window usa le porte TCP e UDP dal 6000 al 6063
479   anche se il protocollo è implementato solo tramite TCP.
480   
481 \item \textsl{le porte private} o \textsl{dinamiche}. I numeri da 49152 a
482   65535. La IANA non dice nulla riguardo a queste porte che pertanto
483   sono i candidati naturali ad essere usate come porte effimere.
484 \end{enumerate}
485
486 In realtà rispetto a quanto indicato nell'RFC~1700 i vari sistemi hanno fatto
487 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 root, per far si che solo
504 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
509 dal lato client come parte dell'autenticazione. Questo viene fatto tramite la
510 funzione \func{rresvport} assegnando al socket una porta libera
511 nell'intervallo fra 512 e 1023.
512
513 Data una connessione TCP si suole chiamare \textit{socket pair}\footnote{da
514   non confondere con la coppia di socket della omonima funzione
515   \func{socketpair} che fanno riferimento ad una coppia di socket sulla stessa
516   macchina, non ai capi di una connessione TCP.} la combinazione dei quattro
517 numeri che definiscono i due capi della connessione e cioè l'indirizzo IP
518 locale e la porta TCP locale, e l'indirizzo IP remoto e la porta TCP remota.
519 Questa combinazione, che scriveremo usando una notazione del tipo
520 (\texttt{195.110.112.152:22}, \texttt{192.84.146.100:20100}), identifica
521 univocamente una connessione su internet.  Questo concetto viene di solito
522 esteso anche a UDP, benché in questo caso non abbia senso parlare di
523 connessione. L'utilizzo del programma \cmd{netstat} permette di visualizzare
524 queste informazioni nei campi \textit{Local Address} e \textit{Foreing
525   Address}.
526
527
528 \subsection{Le porte ed il modello client/server}
529 \label{sec:TCP_port_cliserv}
530
531 Per capire meglio l'uso delle porte e come vengono utilizzate quando si ha a
532 che fare con un'applicazione client/server (come quella che scriveremo in
533 \secref{sec:TCP_cunc_daytime}) esamineremo cosa accade con le connessioni nel
534 caso di un server TCP che deve gestire connessioni multiple.
535
536 Se eseguiamo un \cmd{netstat} su una macchina di prova (il cui indirizzo sia
537 \texttt{195.110.112.152}) potremo avere un risultato del tipo:
538 \begin{verbatim}
539 Active Internet connections (servers and established)
540 Proto Recv-Q Send-Q Local Address           Foreign Address         State      
541 tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
542 tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN
543 tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN
544 \end{verbatim}
545 essendo presenti e attivi un server ssh, un server di posta e un DNS per il
546 caching locale.
547
548 Questo ci mostra ad esempio che il server ssh ha compiuto un'apertura passiva,
549 mettendosi in ascolto sulla porta 22 riservata a questo servizio, e che si è
550 posto in ascolto per connessioni provenienti da uno qualunque degli indirizzi
551 associati alle interfacce locali. La notazione \texttt{0.0.0.0} usata da
552 \cmd{netstat} è equivalente all'asterisco utilizzato per il numero di porta,
553 indica il valore generico, e corrisponde al valore \const{INADDR\_ANY}
554 definito in \file{arpa/inet.h} (vedi \ref{tab:TCP_ipv4_addr}).
555
556 Inoltre si noti come la porta e l'indirizzo di ogni eventuale connessione
557 esterna non sono specificati; in questo caso la \textit{socket pair} associata
558 al socket potrebbe essere indicata come (\texttt{*:22}, \texttt{*:*}), usando
559 anche per gli indirizzi l'asterisco come carattere che indica il valore
560 generico.
561
562 Dato che in genere una macchina è associata ad un solo indirizzo IP, ci si può
563 chiedere che senso abbia l'utilizzo dell'indirizzo generico per specificare
564 l'indirizzo locale; ma a parte il caso di macchine che hanno più di un
565 indirizzo IP (il cosiddetto \textit{multihoming}) esiste sempre anche
566 l'indirizzo di loopback, per cui con l'uso dell'indirizzo generico si possono
567 accettare connessioni indirizzate verso uno qualunque degli indirizzi IP
568 presenti. Ma, come si può vedere nell'esempio con il DNS che è in ascolto
569 sulla porta 53, è possibile anche restringere l'accesso ad uno specifico
570 indirizzo, cosa che nel caso è fatta accettando solo connessioni che arrivino
571 sull'interfaccia di loopback.
572
573 Una volta che ci si vorrà collegare a questa macchina da un'altra, per esempio
574 quella con l'indirizzo \texttt{192.84.146.100}, si dovrà lanciare su
575 quest'ultima un client \cmd{ssh} per creare una connessione, e il kernel gli
576 assocerà una porta effimera (ad esempio la 21100), per cui la connessione sarà
577 espressa dalla socket pair (\texttt{192.84.146.100:21100},
578 \texttt{195.110.112.152:22}).
579
580 Alla ricezione della richiesta dal client il server creerà un processo figlio
581 per gestire la connessione, se a questo punto eseguiamo nuovamente il
582 programma \cmd{netstat} otteniamo come risultato:
583 \begin{verbatim}
584 Active Internet connections (servers and established)
585 Proto Recv-Q Send-Q Local Address           Foreign Address         State      
586 tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
587 tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN
588 tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN
589 tcp        0      0 195.110.112.152:22      192.84.146.100:21100    ESTABLISHED
590 \end{verbatim}
591
592 Come si può notare il server è ancora in ascolto sulla porta 22, però adesso
593 c'è un nuovo socket (con lo stato \texttt{ESTABLISHED}) che utilizza anch'esso
594 la porta 22, ed ha specificato l'indirizzo locale, questo è il socket con cui
595 il processo figlio gestisce la connessione mentre il padre resta in ascolto
596 sul socket originale.
597
598 Se a questo punto lanciamo un'altra volta il client \cmd{ssh} per una seconda
599 connessione quello che otterremo usando \cmd{netstat} sarà qualcosa del
600 genere:
601 \begin{verbatim}
602 Active Internet connections (servers and established)
603 Proto Recv-Q Send-Q Local Address           Foreign Address         State      
604 tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
605 tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN
606 tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN
607 tcp        0      0 195.110.112.152:22      192.84.146.100:21100    ESTABLISHED
608 tcp        0      0 195.110.112.152:22      192.84.146.100:21101    ESTABLISHED
609 \end{verbatim}
610 cioè il client effettuerà la connessione usando un'altra porta effimera: con
611 questa sarà aperta la connessione, ed il server creerà un'altro processo
612 figlio per gestirla.
613
614 Tutto ciò mostra come il TCP, per poter gestire le connessioni con un server
615 concorrente, non può suddividere i pacchetti solo sulla base della porta di
616 destinazione, ma deve usare tutta l'informazione contenuta nella socket pair,
617 compresa la porta dell'indirizzo remoto.  E se andassimo a vedere quali sono i
618 processi\footnote{ad esempio con il comando \cmd{fuser}, o con \cmd{lsof}.} a
619 cui fanno riferimento i vari socket vedremmo che i pacchetti che arrivano
620 dalla porta remota 21100 vanno al primo figlio e quelli che arrivano alla
621 porta 21101 al secondo.
622
623
624 \section{Le funzioni dei socket TCP}
625 \label{sec:TCP_functions}
626
627 In questa sezione descriveremo in dettaglio le varie funzioni necessarie per
628 l'uso dei socket TCP, con l'eccezione della funzione \func{socket} che è già
629 stata esaminata in dettaglio nel capitolo precedente in
630 \secref{sec:sock_socket}. 
631
632
633 \subsection{La funzione \func{bind}}
634 \label{sec:TCP_func_bind}
635
636 La funzione \funcd{bind} assegna un indirizzo locale ad un socket. È usata
637 cioè per specificare la prima parte dalla socket pair. Viene usata sul lato
638 server per specificare la porta (e gli eventuali indirizzi locali) su cui poi
639 ci si porrà in ascolto. Il prototipo della funzione è il seguente:
640 \begin{prototype}{sys/socket.h}
641 {int bind(int sockfd, const struct sockaddr *serv\_addr, socklen\_t addrlen)}
642   
643   Assegna un indirizzo ad un socket.
644   
645   \bodydesc{La funzione restituisce 0 in caso di successo e -1 per un errore;
646     in caso di errore la variabile \var{errno} viene impostata secondo i
647     seguenti codici di errore:
648   \begin{errlist}
649   \item[\errcode{EBADF}] il file descriptor non è valido.
650   \item[\errcode{EINVAL}] il socket ha già un indirizzo assegnato.
651   \item[\errcode{ENOTSOCK}] il file descriptor non è associato ad un socket.
652   \item[\errcode{EACCES}] si è cercato di usare una porta riservata senza
653     sufficienti privilegi.
654   \item[\errcode{EADDRNOTAVAIL}] Il tipo di indirizzo specificato non è
655     disponibile.
656   \item[\errcode{EADDRINUSE}] qualche altro socket sta già usando l'indirizzo.
657   \end{errlist}
658   ed anche \errval{EFAULT} e per i socket di tipo \const{AF\_UNIX},
659   \errval{ENOTDIR}, \errval{ENOENT}, \errval{ENOMEM}, \errval{ELOOP},
660   \errval{ENOSR} e \errval{EROFS}.}
661 \end{prototype}
662
663 Il primo argomento è un file descriptor ottenuto da una precedente chiamata a
664 \func{socket}, mentre il secondo e terzo argomento sono rispettivamente
665 l'indirizzo (locale) del socket e la dimensione della struttura che lo
666 contiene, secondo quanto già trattato in \secref{sec:sock_sockaddr}. 
667
668 Con il TCP la chiamata \func{bind} permette di specificare l'indirizzo, la
669 porta, entrambi o nessuno dei due. In genere i server utilizzano una porta
670 nota che assegnano all'avvio, se questo non viene fatto è il kernel a
671 scegliere una porta effimera quando vengono eseguite la funzioni
672 \func{connect} o \func{listen}, ma se questo è normale per il client non lo è
673 per il server\footnote{un'eccezione a tutto ciò sono i server che usano RPC.
674   In questo caso viene fatta assegnare dal kernel una porta effimera che poi
675   viene registrata presso il \textit{portmapper}; quest'ultimo è un altro
676   demone che deve essere contattato dai client per ottenere la porta effimera
677   su cui si trova il server.} che in genere viene identificato dalla porta su
678 cui risponde (l'elenco di queste porte, e dei relativi servizi, è in
679 \file{/etc/services}).
680
681 Con \func{bind} si può assegnare un IP specifico ad un socket, purché questo
682 appartenga ad una interfaccia della macchina.  Per un client TCP questo
683 diventerà l'indirizzo sorgente usato per i tutti i pacchetti inviati sul
684 socket, mentre per un server TCP questo restringerà l'accesso al socket solo
685 alle connessioni che arrivano verso tale indirizzo.
686
687 Normalmente un client non specifica mai l'indirizzo di un socket, ed il kernel
688 sceglie l'indirizzo di origine quando viene effettuata la connessione, sulla
689 base dell'interfaccia usata per trasmettere i pacchetti, (che dipende dalle
690 regole di instradamento usate per raggiungere il server).  Se un server non
691 specifica il suo indirizzo locale il kernel userà come indirizzo di origine
692 l'indirizzo di destinazione specificato dal SYN del client.
693
694 Per specificare un indirizzo generico, con IPv4 si usa il valore
695 \const{INADDR\_ANY}, il cui valore, come accennato in
696 \secref{sec:sock_sa_ipv4}, è pari a zero; nell'esempio
697 \figref{fig:TCP_serv_code} si è usata un'assegnazione immediata del tipo:
698 \includecodesnip{listati/serv_addr_sin_addr.c}
699
700 Si noti che si è usato \func{htonl} per assegnare il valore
701 \const{INADDR\_ANY}, anche se, essendo questo nullo, il riordinamento è
702 inutile.  Si tenga presente comunque che tutte le costanti \val{INADDR\_}
703 (riportate in \tabref{tab:TCP_ipv4_addr}) sono definite secondo
704 l'\textit{endianess} della macchina, ed anche se esse possono essere
705 invarianti rispetto all'ordinamento dei bit, è comunque buona norma usare
706 sempre la funzione \func{htonl}.
707
708 \begin{table}[htb]
709   \centering
710   \footnotesize
711   \begin{tabular}[c]{|l|l|}
712     \hline
713     \textbf{Costante} & \textbf{Significato} \\
714     \hline
715     \hline
716     \const{INADDR\_ANY}      & Indirizzo generico (\texttt{0.0.0.0})\\
717     \const{INADDR\_BROADCAST}& Indirizzo di \textit{broadcast}.\\
718     \const{INADDR\_LOOPBACK} & Indirizzo di \textit{loopback}
719                                (\texttt{127.0.0.1}).\\ 
720     \const{INADDR\_NONE}     & Indirizzo errato.\\
721     \hline    
722   \end{tabular}
723   \caption{Costanti di definizione di alcuni indirizzi generici per IPv4.}
724   \label{tab:TCP_ipv4_addr}
725 \end{table}
726
727 L'esempio precedente funziona correttamente con IPv4 poiché che l'indirizzo è
728 rappresentabile anche con un intero a 32 bit; non si può usare lo stesso
729 metodo con IPv6, in cui l'indirizzo deve necessariamente essere specificato
730 con una struttura, perché il linguaggio C non consente l'uso di una struttura
731 costante come operando a destra in una assegnazione.
732
733 Per questo motivo nell'header \file{netinet/in.h} è definita una variabile
734 \const{in6addr\_any} (dichiarata come \direct{extern}, ed inizializzata dal
735 sistema al valore \const{IN6ADRR\_ANY\_INIT}) che permette di effettuare una
736 assegnazione del tipo: \includecodesnip{listati/serv_addr_sin6_addr.c} in
737 maniera analoga si può utilizzare la variabile \const{in6addr\_loopback} per
738 indicare l'indirizzo di \textit{loopback}, che a sua volta viene inizializzata
739 staticamente a \const{IN6ADRR\_LOOPBACK\_INIT}.
740
741
742
743 \subsection{La funzione \func{connect}}
744 \label{sec:TCP_func_connect}
745
746 La funzione \funcd{connect} è usata da un client TCP per stabilire la
747 connessione con un server TCP, il prototipo della funzione è il seguente:
748 \begin{prototype}{sys/socket.h}
749 {int connect(int sockfd, const struct sockaddr *servaddr, socklen\_t addrlen)}
750   
751   Stabilisce una connessione fra due socket.
752   
753   \bodydesc{La funzione restituisce zero in caso di successo e -1 per un
754     errore, in caso di errore \var{errno} assumerà i valori:
755   \begin{errlist}
756   \item[\errcode{ECONNREFUSED}] non c'è nessuno in ascolto sull'indirizzo
757     remoto.
758   \item[\errcode{ETIMEDOUT}] si è avuto timeout durante il tentativo di
759     connessione.
760   \item[\errcode{ENETUNREACH}] la rete non è raggiungibile.
761   \item[\errcode{EINPROGRESS}] il socket è non bloccante (vedi
762     \secref{sec:file_noblocking}) e la connessione non può essere conclusa
763     immediatamente.
764   \item[\errcode{EALREADY}] il socket è non bloccante (vedi
765     \secref{sec:file_noblocking}) e un tentativo precedente di connessione non
766     si è ancora concluso.
767   \item[\errcode{EAGAIN}] non ci sono più porte locali libere. 
768   \item[\errcode{EAFNOSUPPORT}] l'indirizzo non ha una famiglia di indirizzi
769     corretta nel relativo campo.
770   \item[\errcode{EACCES}, \errcode{EPERM}] si è tentato di eseguire una
771     connessione ad un indirizzo broadcast senza che il socket fosse stato
772     abilitato per il broadcast.
773   \end{errlist}
774   altri errori possibili sono: \errval{EFAULT}, \errval{EBADF},
775   \errval{ENOTSOCK}, \errval{EISCONN} e \errval{EADDRINUSE}.}
776 \end{prototype}
777
778 Il primo argomento è un file descriptor ottenuto da una precedente chiamata a
779 \func{socket}, mentre il secondo e terzo argomento sono rispettivamente
780 l'indirizzo e la dimensione della struttura che contiene l'indirizzo del
781 socket, già descritta in \secref{sec:sock_sockaddr}.
782
783 La struttura dell'indirizzo deve essere inizializzata con l'indirizzo IP e il
784 numero di porta del server a cui ci si vuole connettere, come mostrato
785 nell'esempio \secref{sec:TCP_cli_sample} usando le funzioni illustrate in
786 \secref{sec:sock_addr_func}.
787
788 Nel caso di socket TCP la funzione \func{connect} avvia il \textit{three way
789   handshake}, e ritorna solo quando la connessione è stabilita o si è
790 verificato un errore. Le possibili cause di errore sono molteplici (ed i
791 relativi codici riportati sopra), quelle che però dipendono dalla situazione
792 della rete e non da errori o problemi nella chiamata della funzione sono le
793 seguenti:
794 \begin{enumerate}
795 \item Il client non riceve risposta al SYN: l'errore restituito è
796   \errcode{ETIMEDOUT}. Stevens riporta che BSD invia un primo SYN alla chiamata
797   di \func{connect}, un'altro dopo 6 secondi, un terzo dopo 24 secondi, se
798   dopo 75 secondi non ha ricevuto risposta viene ritornato l'errore. Linux
799   invece ripete l'emissione del SYN ad intervalli di 30 secondi per un numero
800   di volte che può essere stabilito dall'utente sia con una opportuna
801   \func{sysctl} che attraverso il filesystem \file{/proc} scrivendo il valore
802   voluto in \file{/proc/sys/net/ipv4/tcp\_syn\_retries}. Il valore predefinito
803   per la ripetizione dell'invio è di 5 volte, che comporta un timeout dopo
804   circa 180 secondi.
805 %
806 % Le informazioni su tutte le opzioni impostabili via /proc stanno in
807 % Linux/Documentation/networking/ip-sysctl.txt
808 %
809 \item Il client riceve come risposta al SYN un RST significa che non c'è
810   nessun programma in ascolto per la connessione sulla porta specificata (il
811   che vuol dire probabilmente che o si è sbagliato il numero della porta o che
812   non è stato avviato il server), questo è un errore fatale e la funzione
813   ritorna non appena il RST viene ricevuto riportando un errore
814   \errcode{ECONNREFUSED}.
815   
816   Il flag RST sta per \textit{reset} ed è un segmento inviato direttamente
817   dal TCP quando qualcosa non va. Tre condizioni che generano un RST sono:
818   quando arriva un SYN per una porta che non ha nessun server in ascolto,
819   quando il TCP abortisce una connessione in corso, quando TCP riceve un
820   segmento per una connessione che non esiste.
821   
822 \item Il SYN del client provoca l'emissione di un messaggio ICMP di
823   destinazione non raggiungibile. In questo caso dato che il messaggio può
824   essere dovuto ad una condizione transitoria si ripete l'emissione dei SYN
825   come nel caso precedente, fino al timeout, e solo allora si restituisce il
826   codice di errore dovuto al messaggio ICMP, che da luogo ad un
827   \errcode{ENETUNREACH}.
828    
829 \end{enumerate}
830
831 Se si fa riferimento al diagramma degli stati del TCP riportato in
832 \figref{fig:TCP_state_diag} la funzione \func{connect} porta un socket
833 dallo stato \texttt{CLOSED} (lo stato iniziale in cui si trova un socket
834 appena creato) prima allo stato \texttt{SYN\_SENT} e poi, al ricevimento del
835 ACK, nello stato \texttt{ESTABLISHED}. Se invece la connessione fallisce il
836 socket non è più utilizzabile e deve essere chiuso.
837
838 Si noti infine che con la funzione \func{connect} si è specificato solo
839 indirizzo e porta del server, quindi solo una metà della socket pair; essendo
840 questa funzione usata nei client l'altra metà contenente indirizzo e porta
841 locale viene lasciata all'assegnazione automatica del kernel, e non è
842 necessario effettuare una \func{bind}.
843
844
845 \subsection{La funzione \func{listen}}
846 \label{sec:TCP_func_listen}
847
848 La funzione \funcd{listen} serve ad usare un socket in modalità passiva, cioè,
849 come dice il nome, per metterlo in ascolto di eventuali connessioni; in
850 sostanza l'effetto della funzione è di portare il socket dallo stato
851 \texttt{CLOSED} a quello \texttt{LISTEN}. In genere si chiama la funzione in
852 un server dopo le chiamate a \func{socket} e \func{bind} e prima della
853 chiamata ad \func{accept}. Il prototipo della funzione, come definito dalla
854 pagina di manuale, è:
855 \begin{prototype}{sys/socket.h}{int listen(int sockfd, int backlog)}
856   Pone un socket in attesa di una connessione.
857   
858   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
859     errore. I codici di errore restituiti in \var{errno} sono i seguenti:
860   \begin{errlist}
861   \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor
862     valido.
863   \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket.
864   \item[\errcode{EOPNOTSUPP}] il socket è di un tipo che non supporta questa
865     operazione.
866   \end{errlist}}
867 \end{prototype}
868
869 La funzione pone il socket specificato da \param{sockfd} in modalità passiva e
870 predispone una coda per le connessioni in arrivo di lunghezza pari a
871 \param{backlog}. La funzione si può applicare solo a socket di tipo
872 \const{SOCK\_STREAM} o \const{SOCK\_SEQPACKET}.
873
874 L'argomento \param{backlog} indica il numero massimo di connessioni pendenti
875 accettate; se esso viene ecceduto il client al momento della richiesta della
876 connessione riceverà un errore di tipo \errcode{ECONNREFUSED}, o se il
877 protocollo, come accade nel caso del TCP, supporta la ritrasmissione, la
878 richiesta sarà ignorata in modo che la connessione possa venire ritentata.
879
880 Per capire meglio il significato di tutto ciò occorre approfondire la modalità
881 con cui il kernel tratta le connessioni in arrivo. Per ogni socket in ascolto
882 infatti vengono mantenute due code:
883 \begin{enumerate}
884 \item La coda delle connessioni incomplete (\textit{incomplete connection
885     queue} che contiene un riferimento per ciascun socket per il quale è
886   arrivato un SYN ma il \textit{three way handshake} non si è ancora concluso.
887   Questi socket sono tutti nello stato \texttt{SYN\_RECV}.
888 \item La coda delle connessioni complete (\textit{complete connection queue}
889   che contiene un ingresso per ciascun socket per il quale il three way
890   handshake è stato completato ma ancora \func{accept} non è ritornata.
891   Questi socket sono tutti nello stato \texttt{ESTABLISHED}.
892 \end{enumerate}
893
894 Lo schema di funzionamento è descritto in \figref{fig:TCP_listen_backlog}:
895 quando arriva un SYN da un client il server crea una nuova voce nella coda
896 delle connessioni incomplete, e poi risponde con il SYN$+$ACK. La voce resterà
897 nella coda delle connessioni incomplete fino al ricevimento dell'ACK dal
898 client o fino ad un timeout. Nel caso di completamento del three way handshake
899 la voce viene spostata nella coda delle connessioni complete.  Quando il
900 processo chiama la funzione \func{accept} (vedi \secref{sec:TCP_func_accept})
901 la prima voce nella coda delle connessioni complete è passata al programma, o,
902 se la coda è vuota, il processo viene posto in attesa e risvegliato all'arrivo
903 della prima connessione completa.
904
905 \begin{figure}[htb]
906   \centering
907   \includegraphics[width=11cm]{img/tcp_listen_backlog}  
908   \caption{Schema di funzionamento delle code delle connessioni complete ed
909     incomplete.}
910   \label{fig:TCP_listen_backlog}
911 \end{figure}
912
913 Storicamente il valore del parametro \param{backlog} era corrispondente al
914 massimo valore della somma del numero di voci possibili per ciascuna delle due
915 code. Stevens in \cite{UNP1} riporta che BSD ha sempre applicato un fattore di
916 1.5 a detto valore, e fornisce una tabella con i risultati ottenuti con vari
917 kernel, compreso Linux 2.0, che mostrano le differenze fra diverse
918 implementazioni.
919
920 In Linux il significato di questo valore è cambiato a partire dal kernel 2.2
921 per prevenire l'attacco chiamato \textit{syn flood}. Questo si basa
922 sull'emissione da parte dell'attaccante di un grande numero di pacchetti SYN
923 indirizzati verso una porta, forgiati con indirizzo IP fasullo\footnote{con la
924   tecnica che viene detta \textit{ip spoofing}.} così che i SYN$+$ACK vanno
925 perduti e la coda delle connessioni incomplete viene saturata, impedendo di
926 fatto ulteriori connessioni.
927
928 Per ovviare a questo il significato del \param{backlog} è stato cambiato a
929 indicare la lunghezza della coda delle connessioni complete. La lunghezza
930 della coda delle connessioni incomplete può essere ancora controllata usando
931 la funzione \func{sysctl} con il parametro \const{NET\_TCP\_MAX\_SYN\_BACKLOG}
932 o scrivendola direttamente in
933 \file{/proc/sys/net/ipv4/tcp\_max\_syn\_backlog}.  Quando si attiva la
934 protezione dei syncookies però (con l'opzione da compilare nel kernel e da
935 attivare usando \file{/proc/sys/net/ipv4/tcp\_syncookies}) questo valore viene
936 ignorato e non esiste più un valore massimo.  In ogni caso in Linux il valore
937 di \param{backlog} viene troncato ad un massimo di \const{SOMAXCONN} se è
938 superiore a detta costante (che di default vale 128).
939
940 La scelta storica per il valore di questo parametro era di 5, e alcuni vecchi
941 kernel non supportavano neanche valori superiori, ma la situazione corrente è
942 molto cambiata per via della presenza di server web che devono gestire un gran
943 numero di connessioni per cui un tale valore non è più adeguato. Non esiste
944 comunque una risposta univoca per la scelta del valore, per questo non
945 conviene specificarlo con una costante (il cui cambiamento richiederebbe la
946 ricompilazione del server) ma usare piuttosto una variabile di ambiente (vedi
947 \secref{sec:proc_environ}).
948
949 Stevens tratta accuratamente questo argomento in \cite{UNP1}, con esempi presi
950 da casi reali su web server, ed in particolare evidenzia come non sia più vero
951 che il compito principale della coda sia quello di gestire il caso in cui il
952 server è occupato fra chiamate successive alla \func{accept} (per cui la coda
953 più occupata sarebbe quella delle connessioni completate), ma piuttosto quello
954 di gestire la presenza di un gran numero di SYN in attesa di concludere il
955 three way handshake.
956
957 Infine va messo in evidenza che, nel caso di socket TCP, quando un SYN arriva
958 con tutte le code piene, il pacchetto deve essere ignorato. Questo perché la
959 condizione in cui le code sono piene è ovviamente transitoria, per cui se il
960 client ritrasmette il SYN è probabile che passato un po' di tempo possa
961 trovare nella coda lo spazio per una nuova connessione. Se invece si
962 rispondesse con un RST, per indicare l'impossibilità di effettuare la
963 connessione, la chiamata a \func{connect} nel client ritornerebbe con una
964 condizione di errore, costringendo a inserire nell'applicazione la gestione
965 dei tentativi di riconnessione, che invece può essere effettuata in maniera
966 trasparente dal protocollo TCP.
967
968
969 \subsection{La funzione \func{accept}}
970 \label{sec:TCP_func_accept}
971
972 La funzione \funcd{accept} è chiamata da un server per gestire la connessione
973 una volta che sia stato completato il \textit{three way handshake}, la
974 funzione restituisce un nuovo socket descriptor su cui si potrà operare per
975 effettuare la comunicazione. Se non ci sono connessioni completate il processo
976 viene messo in attesa. Il prototipo della funzione è il seguente:
977 \begin{prototype}{sys/socket.h}
978 {int accept(int sockfd, struct sockaddr *addr, socklen\_t *addrlen)} 
979  
980   Accetta una connessione sul socket specificato.
981   
982   \bodydesc{La funzione restituisce un numero di socket descriptor positivo in
983     caso di successo e -1 in caso di errore, nel qual caso \var{errno} viene
984     impostata ai seguenti valori:
985
986   \begin{errlist}
987   \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor
988     valido.
989   \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket.
990   \item[\errcode{EOPNOTSUPP}] il socket è di un tipo che non supporta questa
991     operazione.
992   \item[\errcode{EAGAIN} o \errcode{EWOULDBLOCK}] il socket è stato impostato
993     come non bloccante (vedi \secref{sec:file_noblocking}), e non ci sono
994     connessioni in attesa di essere accettate.
995   \item[\errcode{EPERM}] Le regole del firewall non consentono la connessione.
996   \item[\errcode{ENOBUFS}, \errcode{ENOMEM}] questo spesso significa che
997     l'allocazione della memoria è limitata dai limiti sui buffer dei socket,
998     non dalla memoria di sistema.
999   \item[\errcode{EINTR}] La funzione è stata interrotta da un segnale.
1000   \end{errlist}
1001   Inoltre possono essere restituiti gli errori di rete relativi al nuovo
1002   socket, diversi a secondo del protocollo, come: \errval{EMFILE},
1003   \errval{EINVAL}, \errval{ENOSR}, \errval{ENOBUFS}, \errval{EFAULT},
1004   \errval{EPERM}, \errval{ECONNABORTED}, \errval{ESOCKTNOSUPPORT},
1005   \errval{EPROTONOSUPPORT}, \errval{ETIMEDOUT}, \errval{ERESTARTSYS}.}
1006 \end{prototype}
1007
1008 La funzione estrae la prima connessione relativa al socket \param{sockfd} in
1009 attesa sulla coda delle connessioni complete, che associa ad nuovo socket con
1010 le stesse caratteristiche di \param{sockfd}.  Il socket originale non viene
1011 toccato e resta nello stato di \texttt{LISTEN}, mentre il nuovo socket viene
1012 posto nello stato \texttt{ESTABLISHED}. Nella struttura \param{addr} e nella
1013 variabile \param{addrlen} vengono restituiti indirizzo e relativa lunghezza
1014 del client che si è connesso.
1015
1016 I due argomenti \param{addr} e \param{addrlen} (si noti che quest'ultimo è
1017 passato per indirizzo per avere indietro il valore) sono usati per ottenere
1018 l'indirizzo del client da cui proviene la connessione. Prima della chiamata
1019 \param{addrlen} deve essere inizializzato alle dimensioni della struttura il
1020 cui indirizzo è passato come argomento in \param{addr}; al ritorno della
1021 funzione \param{addrlen} conterrà il numero di byte scritti dentro
1022 \param{addr}. Se questa informazione non interessa basterà inizializzare a
1023 \val{NULL} detti puntatori.
1024
1025 Se la funzione ha successo restituisce il descrittore di un nuovo socket
1026 creato dal kernel (detto \textit{connected socket}) a cui viene associata la
1027 prima connessione completa (estratta dalla relativa coda, vedi
1028 \secref{sec:TCP_func_listen}) che il client ha effettuato verso il socket
1029 \param{sockfd}. Quest'ultimo (detto \textit{listening socket}) è quello creato
1030 all'inizio e messo in ascolto con \func{listen}, e non viene toccato dalla
1031 funzione.  Se non ci sono connessioni pendenti da accettare la funzione mette
1032 in attesa il processo\footnote{a meno che non si sia impostato il socket per
1033   essere non bloccante (vedi \secref{sec:file_noblocking}), nel qual caso
1034   ritorna con l'errore \errcode{EAGAIN}.  Torneremo su questa modalità di
1035   operazione in \secref{sec:xxx_sock_noblock}.}  fintanto che non ne arriva
1036 una.
1037
1038 La funzione può essere usata solo con socket che supportino la connessione
1039 (cioè di tipo \const{SOCK\_STREAM}, \const{SOCK\_SEQPACKET} o
1040 \const{SOCK\_RDM}). Per alcuni protocolli che richiedono una conferma
1041 esplicita della connessione,\footnote{attualmente in Linux solo DECnet ha
1042   questo comportamento.} la funzione opera solo l'estrazione dalla coda delle
1043 connessioni, la conferma della connessione viene eseguita implicitamente dalla
1044 prima chiamata ad una \func{read} o una \func{write}, mentre il rifiuto della
1045 connessione viene eseguito con la funzione \func{close}.
1046
1047 È da chiarire che Linux presenta un comportamento diverso nella gestione degli
1048 errori rispetto ad altre implementazioni dei socket BSD, infatti la funzione
1049 \func{accept} passa gli errori di rete pendenti sul nuovo socket come codici
1050 di errore per \func{accept}, per cui l'applicazione deve tenerne conto ed
1051 eventualmente ripetere la chiamata alla funzione come per l'errore di
1052 \errcode{EAGAIN}. Un'altra differenza con BSD è che la funzione non fa
1053 ereditare al nuovo socket i flag del socket originale, come
1054 \const{O\_NONBLOCK},\footnote{ed in generale tutti quelli che si possono
1055   impostare con \func{fcntl}, vedi \secref{sec:file_fcntl}.} che devono essere
1056 rispecificati ogni volta. Tutto questo deve essere tenuto in conto se si
1057 devono scrivere programmi portabili.
1058
1059 Il meccanismo di funzionamento di \func{accept} è essenziale per capire il
1060 funzionamento di un server: in generale infatti c'è sempre un solo socket in
1061 ascolto, detto per questo \textit{listening socket}, che resta per tutto il
1062 tempo nello stato \texttt{LISTEN}, mentre le connessioni vengono gestite dai
1063 nuovi socket, detti \textit{connected socket}, ritornati da \func{accept}, che
1064 si trovano automaticamente nello stato \texttt{ESTABLISHED}, e vengono
1065 utilizzati per lo scambio dei dati, che avviene su di essi, fino alla chiusura
1066 della connessione.  Si può riconoscere questo schema anche nell'esempio
1067 elementare di \figref{fig:TCP_serv_code}, dove per ogni connessione il socket
1068 creato da \func{accept} viene chiuso dopo l'invio dei dati.
1069
1070
1071 \subsection{Le funzioni \func{getsockname} e \func{getpeername}}
1072 \label{sec:TCP_get_names}
1073
1074 Oltre a tutte quelle viste finora, dedicate all'utilizzo dei socket, esistono
1075 alcune funzioni ausiliarie che possono essere usate per recuperare alcune
1076 informazioni relative ai socket ed alle connessioni ad essi associate. Le due
1077 funzioni più elementari sono queste, che vengono usate per ottenere i dati
1078 relativi alla socket pair associata ad un certo socket.
1079
1080 La prima funzione è \funcd{getsockname} e serve ad ottenere l'indirizzo locale
1081 associato ad un socket; il suo prototipo è:
1082 \begin{prototype}{sys/socket.h}
1083   {int getsockname(int sockfd, struct sockaddr * name, socklen\_t * namelen)}
1084   Legge l'indirizzo locale di un socket.
1085
1086 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
1087   errore. I codici di errore restituiti in \var{errno} sono i seguenti:
1088   \begin{errlist}
1089   \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor
1090     valido.
1091   \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket.
1092   \item[\errcode{ENOBUFS}] non ci sono risorse sufficienti nel sistema per
1093     eseguire l'operazione.
1094   \item[\errcode{EFAULT}] l'indirizzo \param{name} non è valido.
1095   \end{errlist}}
1096 \end{prototype}
1097
1098 La funzione restituisce la struttura degli indirizzi del socket \param{sockfd}
1099 nella struttura indicata dal puntatore \param{name} la cui lunghezza è
1100 specificata tramite l'argomento \param{namlen}. Quest'ultimo viene passato
1101 come indirizzo per avere indietro anche il numero di byte effettivamente
1102 scritti nella struttura puntata da \param{name}. Si tenga presente che se si è
1103 utilizzato un buffer troppo piccolo per \param{name} l'indirizzo risulterà
1104 troncato.
1105
1106
1107 La funzione si usa tutte le volte che si vuole avere l'indirizzo locale di un
1108 socket; ad esempio può essere usata da un client (che usualmente non chiama
1109 \func{bind}) per ottenere numero IP e porta locale associati al socket
1110 restituito da una \func{connect}, o da un server che ha chiamato \func{bind}
1111 su un socket usando 0 come porta locale per ottenere il numero di porta
1112 effimera assegnato dal kernel.
1113
1114 Inoltre quando un server esegue una \func{bind} su un indirizzo generico, se
1115 chiamata dopo il completamento di una connessione sul socket restituito da
1116 \func{accept}, restituisce l'indirizzo locale che il kernel ha assegnato a
1117 quella connessione.
1118
1119 Tutte le volte che si vuole avere l'indirizzo remoto di un socket si usa la
1120 funzione \funcd{getpeername}, il cui prototipo è:
1121 \begin{prototype}{sys/socket.h}
1122   {int getpeername(int sockfd, struct sockaddr * name, socklen\_t * namelen)}
1123   Legge l'indirizzo remoto di un socket.
1124   
1125   \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
1126     errore. I codici di errore restituiti in \var{errno} sono i seguenti:
1127   \begin{errlist}
1128   \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor
1129     valido.
1130   \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket.
1131   \item[\errcode{ENOTCONN}] il socket non è connesso.
1132   \item[\errcode{ENOBUFS}] non ci sono risorse sufficienti nel sistema per
1133     eseguire l'operazione.
1134   \item[\errcode{EFAULT}] l'argomento \param{name} punta al di fuori dello
1135     spazio di indirizzi del processo.
1136   \end{errlist}}
1137 \end{prototype}
1138
1139 La funzione è identica a \func{getsockname}, ed usa la stessa sintassi, ma
1140 restituisce l'indirizzo remoto del socket, cioè quello associato all'altro
1141 capo della connessione.  Ci si può chiedere a cosa serva questa funzione dato
1142 che dal lato client l'indirizzo remoto è sempre noto quando si esegue la
1143 \func{connect} mentre dal lato server si possono usare, come vedremo in
1144 \figref{fig:TCP_cunc_serv_code}, i valori di ritorno di \func{accept}.
1145
1146 Il fatto è che in generale quest'ultimo caso non è sempre possibile.  In
1147 particolare questo avviene quando il server, invece di gestire la connessione
1148 direttamente in un processo figlio, come vedremo nell'esempio di server
1149 concorrente di \ref{sec:TCP_cunc_daytime}, lancia per ciascuna connessione un
1150 altro programma, usando \func{exec}.\footnote{questa ad esempio è la modalità
1151   con cui opera il \textsl{super-server} \cmd{inetd}, che può gestire tutta
1152   una serie di servizi diversi, eseguendo su ogni connessione ricevuta sulle
1153   porte tenute sotto controllo, il relativo server.}
1154
1155 In questo caso benché il processo figlio abbia una immagine della memoria che
1156 è copia di quella del processo padre (e contiene quindi anche la struttura
1157 ritornata da \func{accept}), all'esecuzione di \func{exec} verrà caricata in
1158 memoria l'immagine del programma eseguito, che a questo punto perde ogni
1159 riferimento ai valori tornati da \func{accept}.  Il socket descriptor però
1160 resta aperto, e se si è seguita una opportuna convenzione per rendere noto al
1161 programma eseguito qual'è il socket connesso, \footnote{ad esempio il solito
1162   \cmd{inetd} fa sempre in modo che i file descriptor 0, 1 e 2 corrispondano
1163   al socket connesso.} quest'ultimo potrà usare la funzione \func{getpeername}
1164 per determinare l'indirizzo remoto del client.
1165
1166 Infine è da chiarire (si legga la pagina di manuale) che, come per
1167 \func{accept}, il terzo parametro, che è specificato dallo standard POSIX.1g
1168 come di tipo \code{socklen\_t *} in realtà deve sempre corrispondere ad un
1169 \ctyp{int *} come prima dello standard perché tutte le implementazioni dei
1170 socket BSD fanno questa assunzione.
1171
1172
1173 \subsection{La funzione \func{close}}
1174 \label{sec:TCP_func_close}
1175
1176 La funzione standard Unix \func{close} (vedi \secref{sec:file_close}) che si
1177 usa sui file può essere usata con lo stesso effetto anche sui file descriptor
1178 associati ad un socket.
1179
1180 L'azione di questa funzione quando applicata a socket è di marcarlo come
1181 chiuso e ritornare immediatamente al processo. Una volta chiamata il socket
1182 descriptor non è più utilizzabile dal processo e non può essere usato come
1183 argomento per una \func{write} o una \func{read} (anche se l'altro capo della
1184 connessione non avesse chiuso la sua parte).  Il kernel invierà comunque tutti
1185 i dati che ha in coda prima di iniziare la sequenza di chiusura.
1186
1187 Vedremo più avanti in \secref{sec:TCP_so_linger} come è possibile cambiare
1188 questo comportamento, e cosa deve essere fatto perché il processo possa
1189 assicurarsi che l'altro capo abbia ricevuto tutti i dati.
1190
1191 Come per tutti i file descriptor anche per i socket viene mantenuto un numero
1192 di riferimenti, per cui se più di un processo ha lo stesso socket aperto
1193 l'emissione del FIN e la sequenza di chiusura di TCP non viene innescata
1194 fintanto che il numero di riferimenti non si annulla, questo si applica, come
1195 visto in \secref{sec:file_sharing}, sia ai file descriptor duplicati che a
1196 quelli ereditati dagli eventuali processi figli, ed è il comportamento che ci
1197 si aspetta in una qualunque applicazione client/server.
1198
1199 Per attivare immediatamente l'emissione del FIN e la sequenza di chiusura
1200 descritta in \secref{sec:TCP_conn_term}, si può invece usare la funzione
1201 \func{shutdown} su cui torneremo in seguito (vedi \secref{sec:xxx_shutdown}).
1202
1203
1204
1205 \section{Un esempio di applicazione}
1206 \label{sec:TCP_application}
1207
1208 Avendo introdotto le funzioni di base per la gestione dei socket, potremo
1209 vedere in questa sezione un esempio di applicazione elementare.  Prima di
1210 passare agli esempi del client e del server, inizieremo riprendendo con
1211 maggiori dettagli una caratteristica delle funzioni di I/O, già accennata in
1212 \secref{sec:file_read} e \secref{sec:file_write}, che nel caso dei socket è
1213 particolarmente rilevante, per poi passare agli esempi, sia di server
1214 iterativo, che di server concorrente.
1215
1216
1217 \subsection{Il comportamento delle funzioni di I/O}
1218 \label{sec:sock_io_behav}
1219
1220 Una cosa che si tende a dimenticare quando si ha a che fare con i socket è che
1221 le funzioni di input/output non sempre hanno lo stesso comportamento che
1222 avrebbero con i normali file di dati (in particolare questo accade per i
1223 socket di tipo stream).
1224
1225 Infatti con i socket è comune che funzioni come \func{read} o \func{write}
1226 possano restituire in input o scrivere in output un numero di byte minore di
1227 quello richiesto. Come già accennato in \secref{sec:file_read} questo è un
1228 comportamento normale per l'I/O su file, ma con i normali file di dati il
1229 problema si avverte solo quando si incontra la fine del file. In generale non
1230 è così, e con i socket questo è particolarmente evidente.
1231
1232 Quando ci si trova ad affrontare questo comportamento tutto quello che si deve
1233 fare è semplicemente ripetere la lettura (o la scrittura) per la quantità di
1234 byte restanti, tenendo conto che le funzioni si possono bloccare se i dati non
1235 sono disponibili: è lo stesso comportamento che si può avere scrivendo più di
1236 \const{PIPE\_BUF} byte in una pipe (si riveda quanto detto in
1237 \secref{sec:ipc_pipes}).
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 Per questo motivo, seguendo l'esempio di R. W. Stevens in \cite{UNP1}, si sono
1251 definite due funzioni, \func{FullRead} e \func{FullWrite}, che eseguono
1252 lettura e scrittura tenendo conto di questa caratteristica, ed in grado di
1253 ritornare solo dopo avere letto o scritto esattamente il numero di byte
1254 specificato; il sorgente è riportato rispettivamente in
1255 \figref{fig:sock_FullRead_code} e \figref{fig:sock_FullWrite_code} ed è
1256 disponibile fra i sorgenti allegati alla guida nei file \file{FullRead.c} e
1257 \file{FullWrite.c}.
1258
1259 \begin{figure}[htb]
1260   \centering
1261   \footnotesize \centering
1262   \begin{minipage}[c]{15cm}
1263     \includecodesample{listati/FullWrite.c}
1264   \end{minipage} 
1265   \normalsize
1266   \caption{La funzione \func{FullWrite}, che scrive esattamente \var{count}
1267     byte su un file descriptor, iterando opportunamente le scritture.}
1268   \label{fig:sock_FullWrite_code}
1269 \end{figure}
1270
1271 Come si può notare le due funzioni ripetono la lettura/scrittura in un ciclo
1272 fino all'esaurimento del numero di byte richiesti, in caso di errore viene
1273 controllato se questo è \errcode{EINTR} (cioè un'interruzione della system
1274 call dovuta ad un segnale), nel qual caso l'accesso viene ripetuto, altrimenti
1275 l'errore viene ritornato al programma chiamante, interrompendo il ciclo.
1276
1277 Nel caso della lettura, se il numero di byte letti è zero, significa che si è
1278 arrivati alla fine del file (per i socket questo significa in genere che
1279 l'altro capo è stato chiuso, e quindi non sarà più possibile leggere niente) e
1280 pertanto si ritorna senza aver concluso la lettura di tutti i byte richiesti.
1281
1282
1283 \subsection{Un primo esempio di client}
1284 \label{sec:TCP_cli_sample}
1285
1286 Il primo esempio di applicazione delle funzioni viste finora è relativo alla
1287 creazione di un client elementare per il servizio \textit{daytime}, un
1288 servizio standard che restituisce l'ora locale della macchina a cui si
1289 effettua la richiesta, e che è assegnato alla porta 13.
1290
1291 In \figref{fig:TCP_cli_code} è riportata la sezione principale del codice del
1292 nostro client. Il sorgente completo del programma
1293 (\file{ElemDaytimeTCPClient.c}, che comprende il trattamento delle opzioni ed
1294 una funzione per stampare un messaggio di aiuto) è allegato alla guida nella
1295 sezione dei codici sorgente e può essere compilato su una qualunque macchina
1296 GNU/Linux.
1297
1298 \begin{figure}[!htb]
1299   \footnotesize \centering
1300   \begin{minipage}[c]{15cm}
1301     \includecodesample{listati/ElemDaytimeTCPClient.c}
1302   \end{minipage} 
1303   \normalsize
1304   \caption{Esempio di codice di un client elementare per il servizio daytime.}
1305   \label{fig:TCP_cli_code}
1306 \end{figure}
1307
1308 Il programma anzitutto (\texttt{\small 1--5}) include gli header necessari;
1309 dopo la dichiarazione delle variabili (\texttt{\small 9--12}) si è omessa
1310 tutta la parte relativa al trattamento degli argomenti passati dalla linea di
1311 comando (effettuata con le apposite funzioni illustrate in
1312 \secref{sec:proc_opt_handling}).
1313
1314 Il primo passo (\texttt{\small 14--18}) è creare un socket TCP (quindi di tipo
1315 \const{SOCK\_STREAM} e di famiglia \const{AF\_INET}). La funzione
1316 \func{socket} ritorna il descrittore che viene usato per identificare il
1317 socket in tutte le chiamate successive. Nel caso la chiamata fallisca si
1318 stampa un errore (\texttt{\small 16}) con la funzione \func{perror} e si esce
1319 (\texttt{\small 16}) con un codice di errore.
1320
1321 Il passo seguente (\texttt{\small 19--27}) è quello di costruire un'apposita
1322 struttura \struct{sockaddr\_in} in cui sarà inserito l'indirizzo del server ed
1323 il numero della porta del servizio. Il primo passo (\texttt{\small 20}) è
1324 inizializzare tutto a zero, per poi inserire il tipo di indirizzo
1325 (\texttt{\small 21}) e la porta (\texttt{\small 22}), usando per quest'ultima
1326 la funzione \func{htons} per convertire il formato dell'intero usato dal
1327 computer a quello usato nella rete, infine \texttt{\small 23--27} si può
1328 utilizzare la funzione \func{inet\_pton} per convertire l'indirizzo numerico
1329 passato dalla linea di comando.
1330
1331 A questo punto (\texttt{\small 28--32}) usando la funzione \func{connect} sul
1332 socket creato in precedenza (\texttt{\small 29}) si può stabilire la
1333 connessione con il server. Per questo si deve utilizzare come secondo
1334 argomento la struttura preparata in precedenza con il relativo indirizzo; si
1335 noti come, esistendo diversi tipi di socket, si sia dovuto effettuare un cast.
1336 Un valore di ritorno della funzione negativo implica il fallimento della
1337 connessione, nel qual caso si stampa un errore (\texttt{\small 30}) e si
1338 ritorna (\texttt{\small 31}).
1339
1340 Completata con successo la connessione il passo successivo (\texttt{\small
1341   34--40}) è leggere la data dal socket; il protocollo prevede che il server
1342 invii sempre una stringa alfanumerica di 26 caratteri, nella forma giorno
1343 della settimana, mese, ora minuto e secondo, anno, seguita dai caratteri di
1344 terminazione \verb|\r\n|, cioè qualcosa del tipo:
1345 \begin{verbatim}
1346 Wed Apr 4 00:53:00 2001\r\n
1347 \end{verbatim}
1348 questa viene letta dal socket (\texttt{\small 34}) con la funzione \func{read}
1349 in un buffer temporaneo; la stringa poi deve essere terminata (\texttt{\small
1350   35}) con il solito carattere nullo per poter essere stampata (\texttt{\small
1351   36}) sullo standard output con l'uso di \func{fputs}.
1352
1353 Come si è già spiegato in \secref{sec:sock_io_behav} la risposta dal socket
1354 potrà arrivare in un unico pacchetto di 26 byte (come avverrà senz'altro nel
1355 caso in questione) ma potrebbe anche arrivare in 26 pacchetti di un byte.  Per
1356 questo nel caso generale non si può mai assumere che tutti i dati arrivino con
1357 una singola lettura, pertanto quest'ultima deve essere effettuata in un ciclo
1358 in cui si continui a leggere fintanto che la funzione \func{read} non ritorni
1359 uno zero (che significa che l'altro capo ha chiuso la connessione) o un numero
1360 minore di zero (che significa un errore nella connessione).
1361
1362 Si noti come in questo caso la fine dei dati sia specificata dal server che
1363 chiude la connessione (anche questo è quanto richiesto dal protocollo); questa
1364 è una delle tecniche possibili (è quella usata pure dal protocollo HTTP), ma
1365 ce ne possono essere altre, ad esempio FTP marca la conclusione di un blocco
1366 di dati con la sequenza ASCII \verb|\r\n| (carriage return e line feed),
1367 mentre il DNS mette la lunghezza in testa ad ogni blocco che trasmette. Il
1368 punto essenziale è che TCP non provvede nessuna indicazione che permetta di
1369 marcare dei blocchi di dati, per cui se questo è necessario deve provvedere il
1370 programma stesso.
1371
1372 Se abilitiamo il servizio \textit{daytime}\footnote{in genere questo viene
1373   fornito direttamente dal \textsl{superdemone} \texttt{inetd}, pertanto basta
1374   assicurarsi che esso sia abilitato nel relativo file di configurazione.}
1375 possiamo verificare il funzionamento del nostro client, avremo allora:
1376 \begin{verbatim}
1377 [piccardi@gont sources]$ ./daytime 127.0.0.1
1378 Mon Apr 21 20:46:11 2003
1379 \end{verbatim}%$
1380 e come si vede tutto funziona regolarmente.
1381
1382
1383 \subsection{Un primo esempio di server}
1384 \label{sec:TCP_serv_sample}
1385
1386 Dopo aver illustrato il client daremo anche un esempio di un server
1387 elementare, che sia anche in grado di rispondere al precedente client. Come
1388 primo esempio realizzeremo un server iterativo, in grado di fornire una sola
1389 risposta alla volta. Il codice del programma è nuovamente mostrato in
1390 \figref{fig:TCP_serv_code}, il sorgente completo
1391 (\file{ElemDaytimeTCPServer.c}) è allegato insieme agli altri file degli
1392 esempi.
1393
1394 \begin{figure}[!htbp]
1395   \footnotesize \centering
1396   \begin{minipage}[c]{15cm}
1397     \includecodesample{listati/ElemDaytimeTCPServer.c}
1398   \end{minipage} 
1399   \normalsize
1400   \caption{Esempio di codice di un semplice server per il servizio daytime.}
1401   \label{fig:TCP_serv_code}
1402 \end{figure}
1403
1404 Come per il client si includono (\texttt{\small 1--9}) gli header necessari a
1405 cui è aggiunto quello per trattare i tempi, e si definiscono (\texttt{\small
1406   14--18}) alcune costanti e le variabili necessarie in seguito. Come nel caso
1407 precedente si sono omesse le parti relative al trattamento delle opzioni da
1408 riga di comando.
1409
1410 La creazione del socket (\texttt{\small 20--24}) è analoga al caso precedente,
1411 come pure l'inizializzazione (\texttt{\small 25--29}) della struttura
1412 \struct{sockaddr\_in}.  Anche in questo caso (\texttt{\small 28}) si usa la
1413 porta standard del servizio daytime, ma come indirizzo IP si usa
1414 (\texttt{\small 27}) il valore predefinito \const{INET\_ANY}, che corrisponde
1415 all'indirizzo generico.
1416
1417 Si effettua poi (\texttt{\small 30--34}) la chiamata alla funzione \func{bind}
1418 che permette di associare la precedente struttura al socket, in modo che
1419 quest'ultimo possa essere usato per accettare connessioni su una qualunque
1420 delle interfacce di rete locali. In caso di errore si stampa (\texttt{\small
1421   31}) un messaggio, e si termina (\texttt{\small 32}) immediatamente il
1422 programma.
1423
1424 Il passo successivo (\texttt{\small 35--39}) è quello di mettere ``in
1425 ascolto'' il socket; questo viene fatto (\texttt{\small 36}) con la funzione
1426 \func{listen} che dice al kernel di accettare connessioni per il socket che
1427 abbiamo creato; la funzione indica inoltre, con il secondo parametro, il
1428 numero massimo di connessioni che il kernel accetterà di mettere in coda per
1429 il suddetto socket. Di nuovo in caso di errore si stampa (\texttt{\small 37})
1430 un messaggio, e si esce (\texttt{\small 38}) immediatamente.
1431
1432 La chiamata a \func{listen} completa la preparazione del socket per l'ascolto
1433 (che viene chiamato anche \textit{listening descriptor}) a questo punto si può
1434 procedere con il ciclo principale (\texttt{\small 40--53}) che viene eseguito
1435 indefinitamente. Il primo passo (\texttt{\small 42}) è porsi in attesa di
1436 connessioni con la chiamata alla funzione \func{accept}, come in precedenza in
1437 caso di errore si stampa (\texttt{\small 43}) un messaggio, e si esce
1438 (\texttt{\small 44}).
1439
1440 Il processo resterà in stato di \textit{sleep} fin quando non arriva e viene
1441 accettata una connessione da un client; quando questo avviene \func{accept}
1442 ritorna, restituendo un secondo descrittore, che viene chiamato
1443 \textit{connected descriptor}, e che è quello che verrà usato dalla successiva
1444 chiamata alla \func{write} per scrivere la risposta al client.
1445
1446 Il ciclo quindi proseguirà determinando (\texttt{\small 46}) il tempo corrente
1447 con una chiamata a \texttt{time}, con il quale si potrà opportunamente
1448 costruire (\texttt{\small 47}) la stringa con la data da trasmettere
1449 (\texttt{\small 48}) con la chiamata a \func{write}. Completata la
1450 trasmissione il nuovo socket viene chiuso (\texttt{\small 52}).  A questo
1451 punto il ciclo si chiude ricominciando da capo in modo da poter ripetere
1452 l'invio della data in risposta ad una successiva connessione.
1453
1454 È importante notare che questo server è estremamente elementare, infatti, a
1455 parte il fatto di poter essere usato solo con indirizzi IPv4, esso è in grado
1456 di rispondere ad un solo un client alla volta: è cioè, come dicevamo, un
1457 \textsl{server iterativo}. Inoltre è scritto per essere lanciato da linea di
1458 comando, se lo si volesse utilizzare come demone occorrerebbero le opportune
1459 modifiche\footnote{come una chiamata a \func{daemon} prima dell'inizio del
1460   ciclo principale.} per tener conto di quanto illustrato in
1461 \secref{sec:sess_daemon}. Si noti anche che non si è inserita nessuna forma di
1462 gestione della terminazione del processo, dato che tutti i file descriptor
1463 vengono chiusi automaticamente alla sua uscita, e che, non generando figli,
1464 non è necessario preoccuparsi di gestire la loro terminazione.
1465
1466
1467 \subsection{Un esempio di server \textit{daytime} concorrente}
1468 \label{sec:TCP_cunc_daytime}
1469
1470 Il server \texttt{daytime} dell'esempio in \secref{sec:TCP_cli_sample} è un
1471 tipico esempio di server iterativo, in cui viene servita una richiesta alla
1472 volta; in generale però, specie se il servizio è più complesso e comporta uno
1473 scambio di dati più sostanzioso di quello in questione, non è opportuno
1474 bloccare un server nel servizio di un client per volta; per questo si ricorre
1475 alle capacità di multitasking del sistema.
1476
1477 Come accennato anche in \secref{sec:proc_gen} una delle modalità più comuni di
1478 funzionamento da parte dei server è quella di usare la funzione \func{fork}
1479 per creare, ad ogni richiesta da parte di un client, un processo figlio che si
1480 incarichi della gestione della comunicazione.  Si è allora riscritto il server
1481 \texttt{daytime} dell'esempio precedente in forma concorrente, inserendo anche
1482 una opzione per la stampa degli indirizzi delle connessioni ricevute.
1483
1484 In \figref{fig:TCP_cunc_serv_code} è mostrato un estratto del codice, in cui
1485 si sono tralasciati il trattamento delle opzioni e le parti rimaste invariate
1486 rispetto al precedente esempio (cioè tutta la parte riguardante l'apertura
1487 passiva del socket). Al solito il sorgente completo del server, nel file
1488 \file{ElemDaytimeTCPCuncServ.c}, è allegato insieme ai sorgenti degli altri
1489 esempi.
1490
1491 \begin{figure}[!htb]
1492   \footnotesize \centering
1493   \begin{minipage}[c]{15cm}
1494     \includecodesample{listati/ElemDaytimeTCPCuncServ.c}
1495   \end{minipage} 
1496   \normalsize
1497   \caption{Esempio di codice di un server concorrente elementare per il 
1498     servizio daytime.}
1499   \label{fig:TCP_cunc_serv_code}
1500 \end{figure}
1501
1502 Stavolta (\texttt{\small 21--25}) la funzione \func{accept} è chiamata
1503 fornendo una struttura di indirizzi in cui saranno ritornati l'indirizzo IP e
1504 la porta da cui il client effettua la connessione, che in un secondo tempo,
1505 (\texttt{\small 39--43}), se il logging è abilitato, stamperemo sullo standard
1506 output.
1507
1508 Quando \func{accept} ritorna il server chiama la funzione \func{fork}
1509 (\texttt{\small 26--30}) per creare il processo figlio che effettuerà
1510 (\texttt{\small 31--45}) tutte le operazioni relative a quella connessione,
1511 mentre il padre proseguirà l'esecuzione del ciclo principale in attesa di
1512 ulteriori connessioni.
1513
1514 Si noti come il figlio operi solo sul socket connesso, chiudendo
1515 immediatamente (\texttt{\small 32}) il socket \var{list\_fd}; mentre il padre
1516 continua ad operare solo sul socket in ascolto chiudendo (\texttt{\small 47})
1517 \var{sock\_fd} al ritorno dalla \func{fork}. Per quanto abbiamo detto in
1518 \secref{sec:TCP_func_close} nessuna delle due chiamate a \func{close} causa
1519 l'innesco della sequenza di chiusura perché il numero di riferimenti al file
1520 descriptor non si è annullato.
1521
1522 Infatti subito dopo la creazione del socket \var{list\_fd} ha una referenza, e
1523 lo stesso vale per \var{sock\_fd} dopo il ritorno di \func{accept}, ma dopo la
1524 \func{fork} i descrittori vengono duplicati nel padre e nel figlio per cui
1525 entrambi i socket si trovano con due referenze. Questo fa si che quando il
1526 padre chiude \var{sock\_fd} esso resta con una referenza da parte del figlio,
1527 e sarà definitivamente chiuso solo quando quest'ultimo, dopo aver completato
1528 le sue operazioni, chiamerà (\texttt{\small 44}) la funzione \func{close}.
1529
1530 In realtà per il figlio non sarebbe necessaria nessuna chiamata a
1531 \func{close}, in quanto con la \func{exit} finale (\texttt{\small 45}) tutti i
1532 file descriptor, quindi anche quelli associati ai socket, vengono
1533 automaticamente chiusi.  Tuttavia si è preferito effettuare esplicitamente le
1534 chiusure per avere una maggiore chiarezza del codice, e per evitare eventuali
1535 errori, prevenendo ad esempio un uso involontario del \textit{listening
1536   descriptor}.
1537
1538 Si noti invece come sia essenziale che il padre chiuda ogni volta il socket
1539 connesso dopo la \func{fork}; se così non fosse nessuno di questi socket
1540 sarebbe effettivamente chiuso dato che alla chiusura da parte del figlio
1541 resterebbe ancora un riferimento nel padre. Si avrebbero così due effetti: il
1542 padre potrebbe esaurire i descrittori disponibili (che sono un numero limitato
1543 per ogni processo) e soprattutto nessuna delle connessioni con i client
1544 verrebbe chiusa.
1545
1546 Come per ogni server iterativo il lavoro di risposta viene eseguito
1547 interamente dal processo figlio. Questo si incarica (\texttt{\small 33}) di
1548 chiamare \func{time} per leggere il tempo corrente, e di stamparlo
1549 (\texttt{\small 34}) sulla stringa contenuta in \var{buffer} con l'uso di
1550 \func{snprintf} e \func{ctime}. Poi la stringa viene scritta (\texttt{\small
1551   35--38}) sul socket, controllando che non ci siano errori. Anche in questo
1552 caso si è evitato il ricorso a \func{FullWrite} in quanto la stringa è
1553 estremamente breve e verrà senz'altro scritta in un singolo segmento.
1554
1555 Inoltre nel caso sia stato abilitato il \textit{logging} delle connessioni, si
1556 provvede anche (\texttt{\small 39--42}) a stampare sullo standard output
1557 l'indirizzo e la porta da cui il client ha effettuato la connessione, usando
1558 i valori contenuti nelle strutture restituite da \func{accept}, eseguendo le
1559 opportune conversioni con \func{inet\_ntop} e \func{atohs}.
1560
1561 Ancora una volta l'esempio è estremamente semplificato, si noti come di nuovo
1562 non si sia gestita né la terminazione del processo né il suo uso come demone,
1563 che tra l'altro sarebbe stato incompatibile con l'uso della opzione di logging
1564 che stampa gli indirizzi delle connessioni sullo standard output. Un altro
1565 aspetto tralasciato è la gestione della terminazione dei processi figli,
1566 torneremo su questo più avanti quando tratteremo alcuni esempi di server più
1567 complessi.
1568
1569
1570 %%% Local Variables: 
1571 %%% mode: latex
1572 %%% TeX-master: "gapil"
1573 %%% End: