+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} (restituito dalla funzione stessa). Il
+socket originale non viene toccato. Nella struttura \param{addr} e nella
+variabile \param{addrlen} vengono restituiti indirizzo e relativa lunghezza del
+client che si è connesso.
+
+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, (attualmente in Linux solo DECnet ha questo
+comportamento), la funzione opera solo l'estrazione dalla coda delle
+connessioni, la conferma della connessione viene fatta implicitamente dalla
+prima chiamata ad una \func{read} o una \func{write} mentre il rifiuto della
+connessione viene fatto 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}. Inoltre la funzione non fa ereditare ai nuovi
+socket flag come \const{O\_NONBLOCK}, che devono essere rispecificati volta
+volta, questo è un comportamento diverso rispetto a quanto accade con BSD e
+deve essere tenuto in conto per scrivere programmi portabili.
+
+I due argomenti \param{cliaddr} 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{cliaddr}, al ritorno della
+funzione \param{addrlen} conterrà il numero di byte scritti dentro
+\param{cliaddr}. 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:TCPel_func_listen}) che il client TCP 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.
+
+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, che resta per tutto il tempo nello stato \texttt{LISTEN}, mentre le
+connessioni vengono gestite dai nuovi socket ritornati da \func{accept} che
+si trovano automaticamente nello stato \texttt{ESTABLISHED} e utilizzati fino
+alla chiusura della connessione che avviene su di essi. Si può riconoscere
+questo schema anche nell'esempio elementare in \figref{fig:net_serv_code} dove
+per ogni connessione il socket creato da \func{accept} viene chiuso dopo
+l'invio dei dati.
+
+
+\subsection{La funzione \func{close}}
+\label{sec:TCPel_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 socket
+descriptor.
+
+L'azione standard 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:TCPadv_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 i file anche per i socket descriptor 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 è il
+comportamento normale che ci si aspetta in un'applicazione client/server quale
+quella che illustreremo in \secref{sec:TCPel_cunc_serv}.
+
+Per attivare immediatamente l'emissione del FIN e la sequenza di chiusura si
+può usare la funzione \func{shutdown} su cui torneremo in seguito.
+
+
+
+\section{I server concorrenti su TCP}
+\label{sec:TCPel_cunc_serv}
+
+Il server \texttt{daytime} dell'esempio in \secref{sec:net_cli_sample} è un
+tipico esempio di server iterativo, in cui viene servita una richiesta alla
+volta; in generale però, specie se il servizio è più complesso e comporta uno
+scambio di dati più sostanzioso di quello in questione, non è opportuno
+bloccare un server nel servizio di un client per volta; per questo si ricorre
+alle capacità di multitasking del sistema.
+
+Il modo più immediato per creare un server concorrente è allora quello di
+usare la funzione \func{fork} per far creare al server per ogni richiesta da
+parte di un client un processo figlio che si incarichi della gestione della
+comunicazione.
+