+Lo schema di funzionamento è descritto in \figref{fig:TCP_listen_backlog}:
+quando arriva un SYN da un client il server crea una nuova voce nella coda
+delle connessioni incomplete, e poi risponde con il SYN$+$ACK. La voce resterà
+nella coda delle connessioni incomplete fino al ricevimento dell'ACK dal
+client o fino ad un timeout. Nel caso di completamento del three way handshake
+la voce viene spostata nella coda delle connessioni complete. Quando il
+processo chiama la funzione \func{accept} (vedi \secref{sec:TCP_func_accept})
+la prima voce nella coda delle connessioni complete è passata al programma, o,
+se la coda è vuota, il processo viene posto in attesa e risvegliato all'arrivo
+della prima connessione completa.
+
+\begin{figure}[htb]
+ \centering
+ \includegraphics[width=11cm]{img/tcp_listen_backlog}
+ \caption{Schema di funzionamento delle code delle connessioni complete ed
+ incomplete.}
+ \label{fig:TCP_listen_backlog}
+\end{figure}
+
+Storicamente il valore del parametro \param{backlog} era corrispondente al
+massimo valore della somma del numero di voci possibili per ciascuna delle due
+code. Stevens in \cite{UNP1} riporta che BSD ha sempre applicato un fattore di
+1.5 a detto valore, e fornisce una tabella con i risultati ottenuti con vari
+kernel, compreso Linux 2.0, che mostrano le differenze fra diverse
+implementazioni.
+
+In Linux il significato di questo valore è cambiato a partire dal kernel 2.2
+per prevenire l'attacco chiamato \textit{syn flood}. Questo si basa
+sull'emissione da parte dell'attaccante di un grande numero di pacchetti SYN
+indirizzati verso una porta, forgiati con indirizzo IP fasullo\footnote{con la
+ tecnica che viene detta \textit{ip spoofing}.} così che i SYN$+$ACK vanno
+perduti e la coda delle connessioni incomplete viene saturata, impedendo di
+fatto ulteriori connessioni.
+
+Per ovviare a questo il significato del \param{backlog} è stato cambiato a
+indicare la lunghezza della coda delle connessioni complete. La lunghezza
+della coda delle connessioni incomplete può essere ancora controllata usando
+la funzione \func{sysctl} con il parametro \const{NET\_TCP\_MAX\_SYN\_BACKLOG}
+o scrivendola direttamente in
+\file{/proc/sys/net/ipv4/tcp\_max\_syn\_backlog}. Quando si attiva la
+protezione dei syncookies però (con l'opzione da compilare nel kernel e da
+attivare usando \file{/proc/sys/net/ipv4/tcp\_syncookies}) questo valore viene
+ignorato e non esiste più un valore massimo. In ogni caso in Linux il valore
+di \param{backlog} viene troncato ad un massimo di \const{SOMAXCONN} se è
+superiore a detta costante (che di default vale 128).
+
+La scelta storica per il valore di questo parametro era di 5, e alcuni vecchi
+kernel non supportavano neanche valori superiori, ma la situazione corrente è
+molto cambiata per via della presenza di server web che devono gestire un gran
+numero di connessioni per cui un tale valore non è più adeguato. Non esiste
+comunque una risposta univoca per la scelta del valore, per questo non
+conviene specificarlo con una costante (il cui cambiamento richiederebbe la
+ricompilazione del server) ma usare piuttosto una variabile di ambiente (vedi
+\secref{sec:proc_environ}).
+
+Stevens tratta accuratamente questo argomento in \cite{UNP1}, con esempi presi
+da casi reali su web server, ed in particolare evidenzia come non sia più vero
+che il compito principale della coda sia quello di gestire il caso in cui il
+server è occupato fra chiamate successive alla \func{accept} (per cui la coda
+più occupata sarebbe quella delle connessioni completate), ma piuttosto quello
+di gestire la presenza di un gran numero di SYN in attesa di concludere il
+three way handshake.
+
+Infine va messo in evidenza che, nel caso di socket TCP, quando un SYN arriva
+con tutte le code piene, il pacchetto deve essere ignorato. Questo perché la
+condizione in cui le code sono piene è ovviamente transitoria, per cui se il
+client ritrasmette il SYN è probabile che passato un po' di tempo possa
+trovare nella coda lo spazio per una nuova connessione. Se invece si
+rispondesse con un RST, per indicare l'impossibilità di effettuare la
+connessione, la chiamata a \func{connect} nel client ritornerebbe con una
+condizione di errore, costringendo a inserire nell'applicazione la gestione
+dei tentativi di riconnessione, che invece può essere effettuata in maniera
+trasparente dal protocollo TCP.
+
+
+\subsection{La funzione \func{accept}}
+\label{sec:TCP_func_accept}
+
+La funzione \funcd{accept} è chiamata da un server per gestire la connessione
+una volta che sia stato completato il \textit{three way handshake}, la
+funzione restituisce un nuovo socket descriptor su cui si potrà operare per
+effettuare la comunicazione. Se non ci sono connessioni completate il processo
+viene messo in attesa. Il prototipo della funzione è il seguente:
+\begin{prototype}{sys/socket.h}
+{int accept(int sockfd, struct sockaddr *addr, socklen\_t *addrlen)}
+
+ Accetta una connessione sul socket specificato.
+
+ \bodydesc{La funzione restituisce un numero di socket descriptor positivo in
+ caso di successo e -1 in caso di errore, nel qual caso \var{errno} viene
+ impostata ai seguenti valori:
+
+ \begin{errlist}
+ \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor
+ valido.
+ \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket.
+ \item[\errcode{EOPNOTSUPP}] il socket è di un tipo che non supporta questa
+ operazione.
+ \item[\errcode{EAGAIN} o \errcode{EWOULDBLOCK}] il socket è stato impostato
+ come non bloccante (vedi \secref{sec:file_noblocking}), e non ci sono
+ connessioni in attesa di essere accettate.
+ \item[\errcode{EPERM}] Le regole del firewall non consentono la connessione.
+ \item[\errcode{ENOBUFS}, \errcode{ENOMEM}] questo spesso significa che
+ l'allocazione della memoria è limitata dai limiti sui buffer dei socket,
+ non dalla memoria di sistema.
+ \item[\errcode{EINTR}] La funzione è stata interrotta da un segnale.
+ \end{errlist}
+ Inoltre possono essere restituiti gli errori di rete relativi al nuovo
+ socket, diversi a secondo del protocollo, come: \errval{EMFILE},
+ \errval{EINVAL}, \errval{ENOSR}, \errval{ENOBUFS}, \errval{EFAULT},
+ \errval{EPERM}, \errval{ECONNABORTED}, \errval{ESOCKTNOSUPPORT},
+ \errval{EPROTONOSUPPORT}, \errval{ETIMEDOUT}, \errval{ERESTARTSYS}.}
+\end{prototype}
+
+La funzione estrae la prima connessione relativa al socket \param{sockfd} in
+attesa sulla coda delle connessioni complete, che associa ad nuovo socket con
+le stesse caratteristiche di \param{sockfd}. Il socket originale non viene
+toccato e resta nello stato di \texttt{LISTEN}, mentre il nuovo socket viene
+posto nello stato \texttt{ESTABLISHED}. Nella struttura \param{addr} e nella
+variabile \param{addrlen} vengono restituiti indirizzo e relativa lunghezza
+del client che si è connesso.
+
+I due argomenti \param{addr} e \param{addrlen} (si noti che quest'ultimo è
+passato per indirizzo per avere indietro il valore) sono usati per ottenere
+l'indirizzo del client da cui proviene la connessione. Prima della chiamata
+\param{addrlen} deve essere inizializzato alle dimensioni della struttura il
+cui indirizzo è passato come argomento in \param{addr}; al ritorno della
+funzione \param{addrlen} conterrà il numero di byte scritti dentro
+\param{addr}. Se questa informazione non interessa basterà inizializzare a
+\val{NULL} detti puntatori.
+
+Se la funzione ha successo restituisce il descrittore di un nuovo socket
+creato dal kernel (detto \textit{connected socket}) a cui viene associata la
+prima connessione completa (estratta dalla relativa coda, vedi
+\secref{sec:TCP_func_listen}) che il client ha effettuato verso il socket
+\param{sockfd}. Quest'ultimo (detto \textit{listening socket}) è quello creato
+all'inizio e messo in ascolto con \func{listen}, e non viene toccato dalla
+funzione. Se non ci sono connessioni pendenti da accettare la funzione mette
+in attesa il processo\footnote{a meno che non si sia impostato il socket per
+ essere non bloccante (vedi \secref{sec:file_noblocking}), nel qual caso
+ ritorna con l'errore \errcode{EAGAIN}. Torneremo su questa modalità di
+ operazione in \secref{sec:xxx_sock_noblock}.} fintanto che non ne arriva
+una.
+
+La funzione può essere usata solo con socket che supportino la connessione
+(cioè di tipo \const{SOCK\_STREAM}, \const{SOCK\_SEQPACKET} o
+\const{SOCK\_RDM}). Per alcuni protocolli che richiedono una conferma
+esplicita della connessione,\footnote{attualmente in Linux solo DECnet ha
+ questo comportamento.} la funzione opera solo l'estrazione dalla coda delle
+connessioni, la conferma della connessione viene eseguita implicitamente dalla
+prima chiamata ad una \func{read} o una \func{write}, mentre il rifiuto della
+connessione viene eseguito con la funzione \func{close}.
+
+È da chiarire che Linux presenta un comportamento diverso nella gestione degli
+errori rispetto ad altre implementazioni dei socket BSD, infatti la funzione
+\func{accept} passa gli errori di rete pendenti sul nuovo socket come codici
+di errore per \func{accept}, per cui l'applicazione deve tenerne conto ed
+eventualmente ripetere la chiamata alla funzione come per l'errore di
+\errcode{EAGAIN}. Un'altra differenza con BSD è che la funzione non fa
+ereditare al nuovo socket i flag del socket originale, come
+\const{O\_NONBLOCK},\footnote{ed in generale tutti quelli che si possono
+ impostare con \func{fcntl}, vedi \secref{sec:file_fcntl}.} che devono essere
+rispecificati ogni volta. Tutto questo deve essere tenuto in conto se si
+devono scrivere programmi portabili.
+
+Il meccanismo di funzionamento di \func{accept} è essenziale per capire il
+funzionamento di un server: in generale infatti c'è sempre un solo socket in
+ascolto, detto per questo \textit{listening socket}, che resta per tutto il
+tempo nello stato \texttt{LISTEN}, mentre le connessioni vengono gestite dai
+nuovi socket, detti \textit{connected socket}, ritornati da \func{accept}, che
+si trovano automaticamente nello stato \texttt{ESTABLISHED}, e vengono
+utilizzati per lo scambio dei dati, che avviene su di essi, fino alla chiusura
+della connessione. Si può riconoscere questo schema anche nell'esempio
+elementare di \figref{fig:TCP_serv_code}, dove per ogni connessione il socket
+creato da \func{accept} viene chiuso dopo l'invio dei dati.
+
+
+\subsection{Le funzioni \func{getsockname} e \func{getpeername}}
+\label{sec:TCP_get_names}
+
+Oltre a tutte quelle viste finora, dedicate all'utilizzo dei socket, esistono
+alcune funzioni ausiliarie che possono essere usate per recuperare alcune
+informazioni relative ai socket ed alle connessioni ad essi associate. Le due
+funzioni più elementari sono queste, che vengono usate per ottenere i dati
+relativi alla socket pair associata ad un certo socket.
+
+La prima funzione è \funcd{getsockname} e serve ad ottenere l'indirizzo locale
+associato ad un socket; il suo prototipo è:
+\begin{prototype}{sys/socket.h}
+ {int getsockname(int sockfd, struct sockaddr * name, socklen\_t * namelen)}
+ Legge l'indirizzo locale di un socket.
+
+\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
+ errore. I codici di errore restituiti in \var{errno} sono i seguenti:
+ \begin{errlist}
+ \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor
+ valido.
+ \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket.
+ \item[\errcode{ENOBUFS}] non ci sono risorse sufficienti nel sistema per
+ eseguire l'operazione.
+ \item[\errcode{EFAULT}] l'indirizzo \param{name} non è valido.
+ \end{errlist}}
+\end{prototype}
+
+La funzione restituisce la struttura degli indirizzi del socket \param{sockfd}
+nella struttura indicata dal puntatore \param{name} la cui lunghezza è
+specificata tramite l'argomento \param{namlen}. Quest'ultimo viene passato
+come indirizzo per avere indietro anche il numero di byte effettivamente
+scritti nella struttura puntata da \param{name}. Si tenga presente che se si è
+utilizzato un buffer troppo piccolo per \param{name} l'indirizzo risulterà
+troncato.
+
+
+La funzione si usa tutte le volte che si vuole avere l'indirizzo locale di un
+socket; ad esempio può essere usata da un client (che usualmente non chiama
+\func{bind}) per ottenere numero IP e porta locale associati al socket
+restituito da una \func{connect}, o da un server che ha chiamato \func{bind}
+su un socket usando 0 come porta locale per ottenere il numero di porta
+effimera assegnato dal kernel.
+
+Inoltre quando un server esegue una \func{bind} su un indirizzo generico, se
+chiamata dopo il completamento di una connessione sul socket restituito da
+\func{accept}, restituisce l'indirizzo locale che il kernel ha assegnato a
+quella connessione.
+
+Tutte le volte che si vuole avere l'indirizzo remoto di un socket si usa la
+funzione \funcd{getpeername}, il cui prototipo è:
+\begin{prototype}{sys/socket.h}
+ {int getpeername(int sockfd, struct sockaddr * name, socklen\_t * namelen)}
+ Legge l'indirizzo remoto di un socket.
+
+ \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
+ errore. I codici di errore restituiti in \var{errno} sono i seguenti:
+ \begin{errlist}
+ \item[\errcode{EBADF}] l'argomento \param{sockfd} non è un file descriptor
+ valido.
+ \item[\errcode{ENOTSOCK}] l'argomento \param{sockfd} non è un socket.
+ \item[\errcode{ENOTCONN}] il socket non è connesso.
+ \item[\errcode{ENOBUFS}] non ci sono risorse sufficienti nel sistema per
+ eseguire l'operazione.
+ \item[\errcode{EFAULT}] l'argomento \param{name} punta al di fuori dello
+ spazio di indirizzi del processo.
+ \end{errlist}}
+\end{prototype}
+
+La funzione è identica a \func{getsockname}, ed usa la stessa sintassi, ma
+restituisce l'indirizzo remoto del socket, cioè quello associato all'altro
+capo della connessione. Ci si può chiedere a cosa serva questa funzione dato
+che dal lato client l'indirizzo remoto è sempre noto quando si esegue la
+\func{connect} mentre dal lato server si possono usare, come vedremo in
+\figref{fig:TCP_cunc_serv_code}, i valori di ritorno di \func{accept}.
+
+Il fatto è che in generale quest'ultimo caso non è sempre possibile. In
+particolare questo avviene quando il server, invece di gestire la connessione
+direttamente in un processo figlio, come vedremo nell'esempio di server
+concorrente di \ref{sec:TCP_cunc_daytime}, lancia per ciascuna connessione un
+altro programma, usando \func{exec}.\footnote{questa ad esempio è la modalità
+ con cui opera il \textsl{super-server} \cmd{inetd}, che può gestire tutta
+ una serie di servizi diversi, eseguendo su ogni connessione ricevuta sulle
+ porte tenute sotto controllo, il relativo server.}
+
+In questo caso benché il processo figlio abbia una immagine della memoria che
+è copia di quella del processo padre (e contiene quindi anche la struttura
+ritornata da \func{accept}), all'esecuzione di \func{exec} verrà caricata in
+memoria l'immagine del programma eseguito, che a questo punto perde ogni
+riferimento ai valori tornati da \func{accept}. Il socket descriptor però
+resta aperto, e se si è seguita una opportuna convenzione per rendere noto al
+programma eseguito qual'è il socket connesso, \footnote{ad esempio il solito
+ \cmd{inetd} fa sempre in modo che i file descriptor 0, 1 e 2 corrispondano
+ al socket connesso.} quest'ultimo potrà usare la funzione \func{getpeername}
+per determinare l'indirizzo remoto del client.
+
+Infine è da chiarire (si legga la pagina di manuale) che, come per
+\func{accept}, il terzo parametro, che è specificato dallo standard POSIX.1g
+come di tipo \code{socklen\_t *} in realtà deve sempre corrispondere ad un
+\ctyp{int *} come prima dello standard perché tutte le implementazioni dei
+socket BSD fanno questa assunzione.
+
+
+\subsection{La funzione \func{close}}
+\label{sec:TCP_func_close}
+
+La funzione standard Unix \func{close} (vedi \secref{sec:file_close}) che si
+usa sui file può essere usata con lo stesso effetto anche sui file descriptor
+associati ad un socket.
+
+L'azione di questa funzione quando applicata a socket è di marcarlo come
+chiuso e ritornare immediatamente al processo. Una volta chiamata il socket
+descriptor non è più utilizzabile dal processo e non può essere usato come
+argomento per una \func{write} o una \func{read} (anche se l'altro capo della
+connessione non avesse chiuso la sua parte). Il kernel invierà comunque tutti
+i dati che ha in coda prima di iniziare la sequenza di chiusura.
+
+Vedremo più avanti in \secref{sec:TCP_so_linger} come è possibile cambiare
+questo comportamento, e cosa deve essere fatto perché il processo possa
+assicurarsi che l'altro capo abbia ricevuto tutti i dati.
+
+Come per tutti i file descriptor anche per i socket viene mantenuto un numero
+di riferimenti, per cui se più di un processo ha lo stesso socket aperto
+l'emissione del FIN e la sequenza di chiusura di TCP non viene innescata
+fintanto che il numero di riferimenti non si annulla, questo si applica, come
+visto in \secref{sec:file_sharing}, sia ai file descriptor duplicati che a
+quelli ereditati dagli eventuali processi figli, ed è il comportamento che ci
+si aspetta in una qualunque applicazione client/server.
+
+Per attivare immediatamente l'emissione del FIN e la sequenza di chiusura
+descritta in \secref{sec:TCP_conn_term}, si può invece usare la funzione
+\func{shutdown} su cui torneremo in seguito (vedi \secref{sec:xxx_shutdown}).
+
+
+
+\section{Un esempio di applicazione}
+\label{sec:TCP_application}
+
+Avendo introdotto le funzioni di base per la gestione dei socket, potremo
+vedere in questa sezione un esempio di applicazione elementare. Prima di
+passare agli esempi del client e del server, inizieremo riprendendo con
+maggiori dettagli una caratteristica delle funzioni di I/O, già accennata in
+\secref{sec:file_read} e \secref{sec:file_write}, che nel caso dei socket è
+particolarmente rilevante, per poi passare agli esempi, sia di server
+iterativo, che di server concorrente.
+
+
+\subsection{Il comportamento delle funzioni di I/O}
+\label{sec:sock_io_behav}
+
+Una cosa che si tende a dimenticare quando si ha a che fare con i socket è che
+le funzioni di input/output non sempre hanno lo stesso comportamento che
+avrebbero con i normali file di dati (in particolare questo accade per i
+socket di tipo stream).
+
+Infatti con i socket è comune che funzioni come \func{read} o \func{write}
+possano restituire in input o scrivere in output un numero di byte minore di
+quello richiesto. Come già accennato in \secref{sec:file_read} questo è un
+comportamento normale per l'I/O su file, ma con i normali file di dati il
+problema si avverte solo quando si incontra la fine del file. In generale non
+è così, e con i socket questo è particolarmente evidente.
+
+Quando ci si trova ad affrontare questo comportamento tutto quello che si deve
+fare è semplicemente ripetere la lettura (o la scrittura) per la quantità di
+byte restanti, tenendo conto che le funzioni si possono bloccare se i dati non
+sono disponibili: è lo stesso comportamento che si può avere scrivendo più di
+\const{PIPE\_BUF} byte in una pipe (si riveda quanto detto in
+\secref{sec:ipc_pipes}).
+
+\begin{figure}[htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \includecodesample{listati/FullRead.c}
+ \end{minipage}
+ \normalsize
+ \caption{La funzione \func{FullRead}, che legge esattamente \var{count} byte
+ da un file descriptor, iterando opportunamente le letture.}
+ \label{fig:sock_FullRead_code}
+\end{figure}
+
+Per questo motivo, seguendo l'esempio di R. W. Stevens in \cite{UNP1}, si sono
+definite due funzioni, \func{FullRead} e \func{FullWrite}, che eseguono
+lettura e scrittura tenendo conto di questa caratteristica, ed in grado di
+ritornare solo dopo avere letto o scritto esattamente il numero di byte
+specificato; il sorgente è riportato rispettivamente in
+\figref{fig:sock_FullRead_code} e \figref{fig:sock_FullWrite_code} ed è
+disponibile fra i sorgenti allegati alla guida nei file \file{FullRead.c} e
+\file{FullWrite.c}.
+
+\begin{figure}[htb]
+ \centering
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \includecodesample{listati/FullWrite.c}
+ \end{minipage}
+ \normalsize
+ \caption{La funzione \func{FullWrite}, che scrive esattamente \var{count}
+ byte su un file descriptor, iterando opportunamente le scritture.}
+ \label{fig:sock_FullWrite_code}
+\end{figure}
+
+Come si può notare le due funzioni ripetono la lettura/scrittura in un ciclo
+fino all'esaurimento del numero di byte richiesti, in caso di errore viene
+controllato se questo è \errcode{EINTR} (cioè un'interruzione della system
+call dovuta ad un segnale), nel qual caso l'accesso viene ripetuto, altrimenti
+l'errore viene ritornato al programma chiamante, interrompendo il ciclo.