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
11 \chapter{Socket TCP elementari}
12 \label{cha:elem_TCP_sock}
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.
22 \section{Il funzionamento di una connessione TCP}
23 \label{sec:TCP_connession}
25 Prima di entrare nei dettagli delles 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.
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.
38 \subsection{La creazione della connessione: il \textit{three way handshake}}
39 \label{sec:TCP_conn_cre}
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 \capref{cha:tcp_protocol}).} di dati che vengono
52 scambiati) che porta alla creazione di una connessione è la seguente:
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
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.
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
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.
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.
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.
98 \includegraphics[width=10cm]{img/three_way_handshake}
99 \caption{Il \textit{three way handshake} del TCP.}
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.
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.
121 \subsection{Le opzioni TCP.}
122 \label{sec:TCP_TCP_opt}
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:
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}.
136 \item \textit{window scale option}, %come spiegato in \capref{cha: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).
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
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.
169 \subsection{La terminazione della connessione}
170 \label{sec:TCP_conn_term}
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
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.
184 \item L'altro capo della connessione riceve il FIN ed esegue la
185 \textit{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.
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
196 \item L'altro capo della connessione riceverà il FIN conclusivo e risponderà
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.
210 \includegraphics[width=10cm]{img/tcp_close}
211 \caption{La chiusura di una connessione TCP.}
212 \label{fig:TCP_close}
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.
218 Si noti che nella sequenza di chiusura fra i passi 2 e 3 è in teoria possibile
219 che si mantenga un flusso di dati dal capo della connessione che deve ancora
220 eseguire la chiusura passiva a quello che sta eseguendo la chiusura attiva.
221 Nella sequenza indicata i dati verrebbero persi, dato che si è chiuso il
222 socket dal lato che esegue la chiusura attiva; esistono tuttavia situazioni in
223 cui si vuole poter sfruttare questa possibilità, usando una procedura che è
224 chiamata \textit{half-close}; torneremo su questo aspetto e su come
225 utilizzarlo in \secref{xxx_shutdown}, quando parleremo della funzione
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
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.
244 \subsection{Un esempio di connessione}
245 \label{sec:TCP_conn_dia}
247 Le operazioni del TCP nella creazione e conclusione di una connessione sono
248 specificate attraverso il diagramma di transizione degli stati riportato in
249 \figref{fig:TCP_conn_example}. TCP prevede l'esistenza di 11 diversi stati
250 per un socket ed un insieme di regole per le transizioni da uno stato
251 all'altro basate sullo stato corrente e sul tipo di segmento ricevuto; i nomi
252 degli stati sono gli stessi che vengono riportati del comando \cmd{netstat}
253 nel campo \textit{State}.
255 Non possiamo affrontare una descrizione completa del funzionamento del
256 protocollo; un approfondimento sugli aspetti principali si trova in
257 \capref{cha:tcp_protocol}, ma per una trattazione esauriente 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).
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.
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.
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}.
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.
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}
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).
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
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.
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.
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.
325 \subsection{Lo stato \texttt{TIME\_WAIT}}
326 \label{sec:TCP_time_wait}
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.
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}).
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.
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
356 Lo stato \texttt{TIME\_WAIT} viene utilizzato dal protocollo per due motivi
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
433 \subsection{I numeri di porta}
434 \label{sec:TCP_port_num}
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.
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.
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.
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:
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
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.
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.
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
495 \includegraphics[width=15cm]{img/port_alloc}
496 \caption{Allocazione dei numeri di porta.}
497 \label{fig:TCP_port_alloc}
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
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.
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
528 \subsection{Le porte ed il modello client/server}
529 \label{sec:TCP_port_cliserv}
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.
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:
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
545 essendo presenti e attivi un server ssh, un server di posta e un DNS per il
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}).
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
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.
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}).
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:
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
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.
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
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
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
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.
624 \section{Le funzioni dei socket TCP}
625 \label{sec:TCP_functions}
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}.
633 \subsection{La funzione \func{bind}}
634 \label{sec:TCP_func_bind}
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)}
643 Assegna un indirizzo ad un socket.
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:
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 è
656 \item[\errcode{EADDRINUSE}] qualche altro socket sta già usando l'indirizzo.
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}.}
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}.
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}).
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.
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.
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}
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}.
711 \begin{tabular}[c]{|l|l|}
713 \textbf{Costante} & \textbf{Significato} \\
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.\\
723 \caption{Costanti di definizione di alcuni indirizzi generici per IPv4.}
724 \label{tab:TCP_ipv4_addr}
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.
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}.
743 \subsection{La funzione \func{connect}}
744 \label{sec:TCP_func_connect}
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)}
751 Stabilisce una connessione fra due socket.
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:
756 \item[\errcode{ECONNREFUSED}] non c'è nessuno in ascolto sull'indirizzo
758 \item[\errcode{ETIMEDOUT}] si è avuto timeout durante il tentativo di
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
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.
774 altri errori possibili sono: \errval{EFAULT}, \errval{EBADF},
775 \errval{ENOTSOCK}, \errval{EISCONN} e \errval{EADDRINUSE}.}
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}.
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}.
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
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
806 % Le informazioni su tutte le opzioni impostabili via /proc stanno in
807 % Linux/Documentation/networking/ip-sysctl.txt
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}.
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.
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}.
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.
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}.
845 \subsection{La funzione \func{listen}}
846 \label{sec:TCP_func_listen}
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.
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:
861 \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor
863 \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket.
864 \item[\errcode{EOPNOTSUPP}] il socket è di un tipo che non supporta questa
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}.
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.
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:
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}.
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.
907 \includegraphics[width=10cm]{img/tcp_listen_backlog}
908 \caption{Schema di funzionamento delle code delle connessioni complete ed
910 \label{fig:TCP_listen_backlog}
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
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.
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).
940 La scelta storica per il valore di questo parametro è 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}).
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
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.
969 \subsection{La funzione \func{accept}}
970 \label{sec:TCP_func_accept}
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)}
980 Accetta una connessione sul socket specificato.
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:
987 \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor
989 \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket.
990 \item[\errcode{EOPNOTSUPP}] il socket è di un tipo che non supporta questa
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.
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}.}
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.
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.
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
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}.
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.
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, che resta per tutto il tempo nello stato \texttt{LISTEN}, mentre le
1062 connessioni vengono gestite dai nuovi socket ritornati da \func{accept}, che
1063 si trovano automaticamente nello stato \texttt{ESTABLISHED}, e vengono
1064 utilizzati fino alla chiusura della connessione, che avviene su di essi. Si
1065 può riconoscere questo schema anche nell'esempio elementare in
1066 \figref{fig:TCP_serv_code} dove per ogni connessione il socket creato da
1067 \func{accept} viene chiuso dopo l'invio dei dati.
1070 \subsection{La funzione \func{close}}
1071 \label{sec:TCP_func_close}
1073 La funzione standard Unix \func{close} (vedi \secref{sec:file_close}) che si
1074 usa sui file può essere usata con lo stesso effetto anche sui file descriptor
1075 associati ad un socket.
1077 L'azione di questa funzione quando applicata a socket è di marcarlo come
1078 chiuso e ritornare immediatamente al processo. Una volta chiamata il socket
1079 descriptor non è più utilizzabile dal processo e non può essere usato come
1080 argomento per una \func{write} o una \func{read} (anche se l'altro capo della
1081 connessione non avesse chiuso la sua parte). Il kernel invierà comunque tutti
1082 i dati che ha in coda prima di iniziare la sequenza di chiusura.
1084 Vedremo più avanti in \secref{sec:TCP_so_linger} come è possibile cambiare
1085 questo comportamento, e cosa deve essere fatto perché il processo possa
1086 assicurarsi che l'altro capo abbia ricevuto tutti i dati.
1088 Come per tutti i file descriptor anche per i socket viene mantenuto un numero
1089 di riferimenti, per cui se più di un processo ha lo stesso socket aperto
1090 l'emissione del FIN e la sequenza di chiusura di TCP non viene innescata
1091 fintanto che il numero di riferimenti non si annulla, questo si applica, come
1092 visto in \secref{sec:file_sharing}, sia ai file descriptor duplicati che a
1093 quelli ereditati dagli eventuali processi figli, ed è il comportamento che ci
1094 si aspetta in una qualunque applicazione client/server.
1096 Per attivare immediatamente l'emissione del FIN e la sequenza di chiusura
1097 descritta in \secref{sec:TCP_conn_term}, si può invece usare la funzione
1098 \func{shutdown} su cui torneremo in seguito (vedi \secref{sec:xxx_shutdown}).
1102 \section{Un esempio di applicazione}
1103 \label{sec:TCP_application}
1105 Avendo introdotto le funzioni di base per la gestione dei socket, potremo
1106 vedere in questa sezione un esempio di applicazione elementare. Prima di
1107 passare agli esempi del client e del server, inizieremo riprendendo con
1108 maggiori dettagli una caratteristica delle funzioni di I/O, già accennata in
1109 \secref{sec:file_read} e \secref{sec:file_write}, che nel caso dei socket è
1110 particolarmente rilevante, per poi passare agli esempi, sia di server
1111 iterativo, che di server concorrente.
1114 \subsection{Il comportamento delle funzioni di I/O}
1115 \label{sec:sock_io_behav}
1117 Una cosa che si tende a dimenticare quando si ha a che fare con i socket è che
1118 le funzioni di input/output non sempre hanno lo stesso comportamento che
1119 avrebbero con i normali file di dati (in particolare questo accade per i
1120 socket di tipo stream).
1122 Infatti con i socket è comune che funzioni come \func{read} o \func{write}
1123 possano restituire in input o scrivere in output un numero di byte minore di
1124 quello richiesto. Come già accennato in \secref{sec:file_read} questo è un
1125 comportamento normale per l'I/O su file, ma con i normali file di dati il
1126 problema si avverte solo quando si incontra la fine del file, in generale non
1127 è così, e con i socket questo è particolarmente evidente.
1129 Quando ci si trova ad affrontare questo comportamento tutto quello che si deve
1130 fare è semplicemente ripetere la lettura (o la scrittura) per la quantità di
1131 byte restanti, tenendo conto che le funzioni si possono bloccare se i dati non
1132 sono disponibili: è lo stesso comportamento che si può avere scrivendo più di
1133 \const{PIPE\_BUF} byte in una pipe (si riveda quanto detto in
1134 \secref{sec:ipc_pipes}).
1137 \footnotesize \centering
1138 \begin{minipage}[c]{15cm}
1139 \includecodesample{listati/FullRead.c}
1142 \caption{La funzione \func{FullRead}, che legge esattamente \var{count} byte
1143 da un file descriptor, iterando opportunamente le letture.}
1144 \label{fig:sock_FullRead_code}
1147 Per questo motivo, seguendo l'esempio di R. W. Stevens in \cite{UNP1}, si sono
1148 definite due funzioni, \func{FullRead} e \func{FullWrite}, che eseguono
1149 lettura e scrittura tenendo conto di questa caratteristica, ed in grado di
1150 ritornare dopo avere letto o scritto esattamente il numero di byte
1151 specificato; il sorgente è riportato rispettivamente in
1152 \figref{fig:sock_FullRead_code} e \figref{fig:sock_FullWrite_code} ed è
1153 disponibile fra i sorgenti allegati alla guida nei file \file{FullRead.c} e
1158 \footnotesize \centering
1159 \begin{minipage}[c]{15cm}
1160 \includecodesample{listati/FullWrite.c}
1163 \caption{La funzione \func{FullWrite}, che scrive esattamente \var{count}
1164 byte su un file descriptor, iterando opportunamente le scritture.}
1165 \label{fig:sock_FullWrite_code}
1168 Come si può notare le due funzioni ripetono la lettura/scrittura in un ciclo
1169 fino all'esaurimento del numero di byte richiesti, in caso di errore viene
1170 controllato se questo è \errcode{EINTR} (cioè un'interruzione della system
1171 call dovuta ad un segnale), nel qual caso l'accesso viene ripetuto, altrimenti
1172 l'errore viene ritornato al programma chiamante, interrompendo il ciclo.
1174 Nel caso della lettura, se il numero di byte letti è zero, significa che si è
1175 arrivati alla fine del file (per i socket questo significa in genere che
1176 l'altro capo è stato chiuso, e non è quindi più possibile leggere niente) e
1177 pertanto si ritorna senza aver concluso la lettura di tutti i byte richiesti.
1180 \subsection{Un primo esempio di client}
1181 \label{sec:TCP_cli_sample}
1183 Il primo esempio di applicazione delle funzioni viste finora (sia in
1184 \capref{cha:socket_intro} che in \secref{sec:TCP_functions}) è relativo alla
1185 creazione di un client elementare per il servizio \textit{daytime}, un
1186 servizio standard che restituisce l'ora locale della macchina a cui si
1187 effettua la richiesta, e che è assegnato alla porta 13.
1189 In \figref{fig:TCP_cli_code} è riportata la sezione principale del codice del
1190 nostro client. Il sorgente completo del programma
1191 (\file{ElemDaytimeTCPClient.c}, che comprende il trattamento delle opzioni e
1192 una funzione per stampare un messaggio di aiuto) è allegato alla guida nella
1193 sezione dei codici sorgente e può essere compilato su una qualunque macchina
1196 \begin{figure}[!htb]
1197 \footnotesize \centering
1198 \begin{minipage}[c]{15cm}
1199 \includecodesample{listati/ElemDaytimeTCPClient.c}
1202 \caption{Esempio di codice di un client elementare per il servizio daytime.}
1203 \label{fig:TCP_cli_code}
1206 Il programma anzitutto (\texttt{\small 1--5}) include gli header necessari;
1207 dopo la dichiarazione delle variabili (\texttt{\small 9--12}) si è omessa
1208 tutta la parte relativa al trattamento degli argomenti passati dalla linea di
1209 comando (effettuata con le apposite funzioni illustrate in
1210 \capref{sec:proc_opt_handling}).
1212 Il primo passo (\texttt{\small 14--18}) è creare un \textit{socket} TCP
1213 (quindi di famiglia \const{AF\_INET} e di tipo \const{SOCK\_STREAM}). La
1214 funzione \func{socket} ritorna il descrittore che viene usato per identificare
1215 il socket in tutte le chiamate successive. Nel caso la chiamata fallisca si
1216 stampa un errore (\texttt{\small 16}) con la funzione \func{perror} e si esce
1217 (\texttt{\small 16}) con un codice di errore.
1219 Il passo seguente (\texttt{\small 19--27}) è quello di costruire un'apposita
1220 struttura \struct{sockaddr\_in} in cui sarà inserito l'indirizzo del server ed
1221 il numero della porta del servizio. Il primo passo (\texttt{\small 20}) è
1222 inizializzare tutto a zero, per poi inserire il tipo di protocollo
1223 (\texttt{\small 21}) e la porta (\texttt{\small 22}), usando per quest'ultima
1224 la funzione \func{htons} per convertire il formato dell'intero usato dal
1225 computer a quello usato nella rete, infine \texttt{\small 23--27} si può
1226 utilizzare la funzione \func{inet\_pton} per convertire l'indirizzo numerico
1227 passato dalla linea di comando.
1229 A questo punto (\texttt{\small 28--32}) usando la funzione \func{connect} sul
1230 socket creato in precedenza (\texttt{\small 29}) si può stabilire la
1231 connessione con il server. Per questo si deve utilizzare come secondo
1232 argomento la struttura preparata in precedenza con il relativo indirizzo; si
1233 noti come, esistendo diversi tipi di socket, si sia dovuto effettuare un cast.
1234 Un valore di ritorno della funzione negativo implica il fallimento della
1235 connessione, nel qual caso si stampa un errore (\texttt{\small 30}) e si
1236 ritorna (\texttt{\small 31}).
1238 Completata con successo la connessione il passo successivo (\texttt{\small
1239 34--40}) è leggere la data dal socket; il protocollo prevede che il server
1240 invii sempre una stringa alfanumerica di 26 caratteri, nella forma giorno
1241 della settimana, mese, ora minuto e secondo, anno, seguita dai caratteri di
1242 teminazione \verb|\r\n|, cioè qualcosa del tipo:
1244 Wed Apr 4 00:53:00 2001\r\n
1246 questa viene letta dal socket (\texttt{\small 34}) con la funzione \func{read}
1247 in un buffer temporaneo; la stringa poi deve essere terminata (\texttt{\small
1248 35}) con il solito carattere nullo per poter essere stampata (\texttt{\small
1249 36}) sullo standard output con l'uso di \func{fputs}.
1251 Come si è già spiegato in \secref{sec:sock_io_behav} la risposta dal socket
1252 potrà arrivare in un unico pacchetto di 26 byte (come avverrà senz'altro nel
1253 caso in questione) ma potrebbe anche arrivare in 26 pacchetti di un byte. Per
1254 questo nel caso generale non si può mai assumere che tutti i dati arrivino con
1255 una singola lettura, pertanto quest'ultima deve essere effettuata in un ciclo
1256 in cui si continui a leggere fintanto che la funzione \func{read} non ritorni
1257 uno zero (che significa che l'altro capo ha chiuso la connessione) o un numero
1258 minore di zero (che significa un errore nella connessione).
1260 Si noti come in questo caso la fine dei dati sia specificata dal server che
1261 chiude la connessione (anche questo è quanto richiesto dal protocollo); questa
1262 è una delle tecniche possibili (è quella usata pure dal protocollo HTTP), ma
1263 ce ne possono essere altre, ad esempio FTP marca la conclusione di un blocco
1264 di dati con la sequenza ASCII \verb|\r\n| (carriage return e line feed),
1265 mentre il DNS mette la lunghezza in testa ad ogni blocco che trasmette. Il
1266 punto essenziale è che TCP non provvede nessuna indicazione che permetta di
1267 marcare dei blocchi di dati, per cui se questo è necessario deve provvedere il
1270 Se abilitiamo il servizio \textit{daytime}\footnote{in genere questo viene
1271 fornito direttamente dal \textsl{superdemone} \texttt{inetd}, pertanto basta
1272 assicurarsi che esso sia abilitato nel relativo file di configurazione.}
1273 possiamo verificare il funzionamento del nostro client, avremo allora:
1275 [piccardi@gont sources]$ ./daytime 127.0.0.1
1276 Mon Apr 21 20:46:11 2003
1278 e come si vede tutto funziona regolarmente.
1281 \subsection{Un primo esempio di server}
1282 \label{sec:TCP_serv_sample}
1284 Dopo aver illustrato il client daremo anche un esempio di un server
1285 elementare, che sia anche in grado di rispondere al precedente client. Come
1286 primo esempio realizzeremo un server iterativo, in grado di fornire una sola
1287 risposta alla volta. Il codice del programma è nuovamente mostrato in
1288 \figref{fig:TCP_serv_code}, il sorgente completo
1289 (\file{ElemDaytimeTCPServer.c}) è allegato insieme agli altri file degli
1292 \begin{figure}[!htbp]
1293 \footnotesize \centering
1294 \begin{minipage}[c]{15cm}
1295 \includecodesample{listati/ElemDaytimeTCPServer.c}
1298 \caption{Esempio di codice di un semplice server per il servizio daytime.}
1299 \label{fig:TCP_serv_code}
1302 Come per il client si includono (\texttt{\small 1--9}) gli header necessari a
1303 cui è aggiunto quello per trattare i tempi, e si definiscono (\texttt{\small
1304 14--18}) alcune costanti e le variabili necessarie in seguito, come nel caso
1305 precedente si sono omesse le parti relative al trattamento delle opzioni da
1308 La creazione del socket (\texttt{\small 20--24}) è analoga al caso precedente,
1309 come pure l'inizializzazione (\texttt{\small 25--29}) della struttura
1310 \struct{sockaddr\_in}, anche in questo caso (\texttt{\small 28}) si usa la
1311 porta standard del servizio daytime, ma come indirizzo IP si usa
1312 (\texttt{\small 27}) il valore predefinito \const{INET\_ANY}, che corrisponde
1313 ad un indirizzo generico.
1315 Si effettua poi (\texttt{\small 30--34}) la chiamata alla funzione \func{bind}
1316 che permette di associare la precedente struttura al socket, in modo che
1317 quest'ultimo possa essere usato per accettare connessioni su una qualunque
1318 delle interfacce di rete locali. In caso di errore si stampa (\texttt{\small
1319 31}) un messaggio, e si termina (\texttt{\small 32}) immediatamente il
1322 Il passo successivo (\texttt{\small 35--39}) è quello di mettere ``in
1323 ascolto'' il socket; questo viene fatto (\texttt{\small 36}) con la funzione
1324 \func{listen} che dice al kernel di accettare connessioni per il socket che
1325 abbiamo creatp; la funzione indica inoltre, con il secondo parametro, il
1326 numero massimo di connessioni che il kernel accetterà di mettere in coda per
1327 il suddetto socket. Di nuovo in caso di errore si stampa (\texttt{\small 37})
1328 un messaggio, e si esce (\texttt{\small 38}) immediatamente.
1330 La chiamata a \func{listen} completa la preparazione del socket per l'ascolto
1331 (che viene chiamato anche \textit{listening descriptor}) a questo punto si può
1332 procedere con il ciclo (\texttt{\small 40--53}) principale che viene eseguito
1333 indefinitamente. Il primo passo è porsi (\texttt{\small 42}) in attesa di
1334 connessioni con la chiamata alla funzione \func{accept}, come in precedenza in
1335 caso di errore si stampa (\texttt{\small 43}) un messaggio, e si esce
1336 (\texttt{\small 44}).
1338 Il provesso resterà in stato di \textit{sleep} fin quando non arriva e viene
1339 accettata una connessione da un client; quando questo avviene \func{accept}
1340 ritorna un secondo descrittore di socket, che viene chiamato \textit{connected
1341 descriptor}, e che è quello che verrà usato dalla successiva chiamata alla
1342 \func{write} per scrivere la risposta al client.
1344 Il ciclo quindi proseguirà determinando (\texttt{\small 46}) il tempo corrente
1345 con una chiamata a \texttt{time}, con il quale si potrà opportunamente
1346 costruire (\texttt{\small 47}) la stringa con la data da trasmettere
1347 (\texttt{\small 48}) con la chiamata a \func{write}. Completata la
1348 trasmissione il nuovo socket viene chiuso (\texttt{\small 52}). A questo
1349 punto il ciclo si chiude ricominciando da capo in modo da poter ripetere
1350 l'invio della data in risposta ad una successiva connessione.
1352 È importante notare che questo server è estremamente elementare, infatti a
1353 parte il fatto di poter essere usato solo con indirizzi IPv4, esso è in grado
1354 di rispondere ad un solo un client alla volta: è cioè, come dicevamo, un
1355 \textsl{server iterativo}. Inoltre esso è scritto per essere lanciato da linea
1356 di comando, se lo si volesse utilizzare come demone occorrerebbero le
1357 opportune modifiche\footnote{come una chiamata a \func{daemon} prima
1358 dell'inizio del ciclo principale.} per tener conto di quanto illustrato in
1359 \secref{sec:sess_daemon}. Si noti anche che non si è inserita nessuna forma di
1360 gestione della terminazione del processo, dato che tutti i file descriptor
1361 vengono chiusi automaticamente alla sua uscita, e che, non generando figli,
1362 non è necessario preoccuparsi di gestire la loro terminazione.
1365 \subsection{Un esempio di server \textit{daytime} concorrente}
1366 \label{sec:TCP_cunc_daytime}
1368 Il server \texttt{daytime} dell'esempio in \secref{sec:TCP_cli_sample} è un
1369 tipico esempio di server iterativo, in cui viene servita una richiesta alla
1370 volta; in generale però, specie se il servizio è più complesso e comporta uno
1371 scambio di dati più sostanzioso di quello in questione, non è opportuno
1372 bloccare un server nel servizio di un client per volta; per questo si ricorre
1373 alle capacità di multitasking del sistema.
1375 Come già visto per i server basati sui meccanismi di intercomunicazione locale
1376 visti in \capref{cha:IPC}, il modo più immediato per creare un server
1377 concorrente è quello di usare la funzione \func{fork} per creare ad ogni
1378 richiesta da parte di un client un processo figlio che si incarichi della
1379 gestione della comunicazione. Si è allora riscritto il server \texttt{daytime}
1380 dell'esempio precedente in forma concorrente, inserendo anche una opzione per
1381 la stampa degli indirizzi delle connessioni ricevute.
1383 In \figref{fig:TCP_cunc_serv_code} è mostrato un estratto del codice, in cui si
1384 sono tralasciati il trattamento delle opzioni e le parti rimaste invariate
1385 rispetto al precedente esempio (cioè tutta la parte riguardante l'apertura
1386 passiva del socket). Al solito il sorgente completo del server
1387 \file{ElemDaytimeTCPCuncServ.c} è allegato insieme ai sorgenti degli altri
1390 \begin{figure}[!htb]
1391 \footnotesize \centering
1392 \begin{minipage}[c]{15cm}
1393 \includecodesample{listati/ElemDaytimeTCPCuncServ.c}
1396 \caption{Esempio di codice di un server concorrente elementare per il
1398 \label{fig:TCP_cunc_serv_code}
1401 Stavolta (\texttt{\small 21--25}) la funzione \func{accept} è chiamata
1402 fornendo una struttura di indirizzi in cui saranno ritornati l'indirizzo IP e
1403 la porta da cui il client effettua la connessione, che più avanti
1404 (\texttt{\small 39--43}), se il logging è abilitato, stamperemo sullo standard
1407 Quando \func{accept} ritorna il server chiama la funzione \func{fork}
1408 (\texttt{\small 26--30}) per creare il processo figlio che effettuerà
1409 (\texttt{\small 31--45}) tutte le operazioni relative a quella connessione,
1410 mentre il padre resterà in attesa di ulteriori connessioni.
1412 Si noti come il figlio operi solo sul socket connesso, chiudendo
1413 immediatamente (\texttt{\small 32}) il socket \var{list\_fd}; mentre il padre
1414 continua ad operare solo sul socket in ascolto chiudendo \var{sock\_fd} dopo
1415 (\texttt{\small 47}) ciascuna \func{accept}. Per quanto abbiamo detto in
1416 \secref{sec:TCP_func_close} queste due chiusure non causano l'innesco della
1417 sequenza di chiusura perché il numero di riferimenti al file descriptor non si
1420 Infatti subito dopo la creazione del socket \var{list\_fd} ha una referenza, e
1421 lo stesso vale per \var{sock\_fd} dopo il ritorno di \func{accept}, ma dopo la
1422 fork i descrittori vengono duplicati nel padre e nel figlio per cui entrambi i
1423 socket si trovano con due referenze. Questo fa si che quando il padre chiude
1424 \var{sock\_fd} esso resta con una referenza da parte del figlio, e sarà
1425 definitivamente chiuso solo quando quest'ultimo, dopo aver completato le sue
1426 operazioni, chiamerà la funzione \func{close}.
1428 In realtà per il figlio non sarebbero necessarie nessuna delle due chiamate a
1429 \func{close} in quanto nella \func{exit} tutti i file ed i socket vengono
1430 chiusi. Tuttavia si è preferito effettuare la chiusura esplicitamente per
1431 avere una maggiore chiarezza del codice ed evitare possibili errori.
1433 Si noti come sia essenziale che il padre chiuda ogni volta il socket connesso
1434 dopo la \func{accept}; se così non fosse nessuno di questi socket sarebbe
1435 effettivamente chiuso dato che alla chiusura da parte del figlio resterebbe
1436 ancora un riferimento. Si avrebbero così due effetti, il padre potrebbe
1437 esaurire i descrittori disponibili (che sono un numero limitato per ogni
1438 processo) e soprattutto nessuna delle connessioni con i client verrebbe
1441 Si noti come anche in questo caso non si sia gestita né la terminazione del
1442 processo né il suo uso come demone, che tra l'altro sarenne stato
1443 incompatibile con l'uso della opzione di logging che stampa gli indirizzi
1444 delle connessioni sullo standard output. Un altro aspetto tralasciato è la
1445 gestione della terminazione dei processi figli, torneremo su questo più avanti
1446 quando tratteremo alcuni esempi di server più complessi.
1449 \subsection{Le funzioni \func{getsockname} e \func{getpeername}}
1450 \label{sec:TCP_get_names}
1452 Queste due funzioni vengono usate per ottenere i dati relativi alla socket
1453 pair associata ad un certo socket; la prima è \funcd{getsockname} e
1454 restituisce l'indirizzo locale; il suo prototipo è:
1455 \begin{prototype}{sys/socket.h}
1456 {int getsockname(int sockfd, struct sockaddr * name, socklen\_t * namelen)}
1457 Legge l'indirizzo locale del socket \param{sockfd} nella struttura
1460 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
1461 errore. I codici di errore restituiti in \var{errno} sono i seguenti:
1463 \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor
1465 \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket.
1466 \item[\errcode{ENOBUFS}] non ci sono risorse sufficienti nel sistema per
1467 eseguire l'operazione.
1468 \item[\errcode{EFAULT}] l'argomento \param{name} punta al di fuori dello
1469 spazio di indirizzi del processo.
1473 La funzione si usa tutte le volte che si vuole avere l'indirizzo locale di un
1474 socket; ad esempio può essere usata da un client (che usualmente non chiama
1475 \func{bind}) per ottenere numero IP e porta locale associati al socket
1476 restituito da una \func{connect}, o da un server che ha chiamato \func{bind}
1477 su un socket usando 0 come porta locale per ottenere il numero di porta
1478 effimera assegnato dal kernel.
1480 Inoltre quando un server esegue una \func{bind} su un indirizzo generico, se
1481 chiamata dopo il completamento di una connessione sul socket restituito da
1482 \func{accept}, restituisce l'indirizzo locale che il kernel ha assegnato a
1485 Tutte le volte che si vuole avere l'indirizzo remoto di un socket si usa la
1486 funzione \funcd{getpeername}, il cui prototipo è:
1487 \begin{prototype}{sys/socket.h}
1488 {int getpeername(int sockfd, struct sockaddr * name, socklen\_t * namelen)}
1489 Legge l'indirizzo remoto del socket \param{sockfd} nella struttura
1492 \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
1493 errore. I codici di errore restituiti in \var{errno} sono i seguenti:
1495 \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor
1497 \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket.
1498 \item[\errcode{ENOTCONN}] il socket non è connesso.
1499 \item[\errcode{ENOBUFS}] non ci sono risorse sufficienti nel sistema per
1500 eseguire l'operazione.
1501 \item[\errcode{EFAULT}] l'argomento \param{name} punta al di fuori dello
1502 spazio di indirizzi del processo.
1506 Ci si può chiedere a cosa serva questa funzione dato che dal lato client
1507 l'indirizzo remoto è sempre noto quando si esegue la \func{connect} mentre
1508 dal lato server si possono usare, come si è fatto nell'esempio precedente, i
1509 valori di ritorno di \func{accept}.
1511 In generale però questa ultima possibilità è sempre possibile. In particolare
1512 questo avviene quando il server invece di far gestire la connessione
1513 direttamente a un processo figlio, come nell'esempio precedente, lancia un
1514 opportuno programma per ciascuna connessione usando \func{exec} (questa ad
1515 esempio è la modalità con cui opera il \textsl{super-server} \cmd{inetd}
1516 che gestisce tutta una serie di servizi lanciando per ogni connessione
1517 l'opportuno server).
1519 In questo caso benché il processo figlio abbia una immagine della memoria che
1520 è copia di quella del processo padre (e contiene quindi anche la struttura
1521 ritornata da \func{accept}), all'esecuzione di \func{exec} viene caricata
1522 in memoria l'immagine del programma eseguito che a questo punto perde ogni
1523 riferimento. Il socket descriptor però resta aperto. Allora se una opportuna
1524 convenzione è seguita per rendere noto al programma eseguito qual'è il socket
1525 connesso (\cmd{inetd} ad esempio fa sempre in modo che i file descriptor 0,
1526 1 e 2 corrispondano al socket connesso) quest'ultimo potrà usare la funzione
1527 \func{getpeername} per determinare l'indirizzo remoto del client.
1529 Infine è da chiarire (si legga la pagina di manuale) che, come per
1530 \func{accept}, il terzo parametro, che è specificato dallo standard POSIX.1g
1531 come di tipo \code{socklen\_t *} in realtà deve sempre corrispondere ad un
1532 \ctyp{int *} come prima dello standard perché tutte le implementazioni dei
1533 socket BSD fanno questa assunzione.
1549 %%% Local Variables:
1551 %%% TeX-master: "gapil"