 %% tcpsockadv.tex
%%
%% Copyright (C) 2003 Simone Piccardi.  Permission is granted to
%% copy, distribute and/or modify this document under the terms of the GNU Free
%% Documentation License, Version 1.1 or any later version published by the
%% Free Software Foundation; with the Invariant Sections being "Prefazione",
%% with no Front-Cover Texts, and with no Back-Cover Texts.  A copy of the
%% license is included in the section entitled "GNU Free Documentation
%% License".
%%
\chapter{Socket TCP avanzati}
\label{cha:TCP_advanced}

Esamineremo in questo capitolo le funzionalità più evolute della gestione dei
socket TCP. 



\section{Socket multiplexing}
\label{sec:TCP_sock_multiplexing}

Affronteremo in questa sezione l'utilizzo dell'I/O multiplexing, affrontato in
\secref{sec:file_multiplexing}, nell'ambito delle applicazioni di rete. Già in
\ref{sec:TCP_server_crash} era emerso il problema relativo al client del
servizio echo che non era in grado di accorgersi della terminazione precoce
del server essendo bloccato nella lettura dei dati immessi da tastiera.

Abbiamo visto in \secref{sec:file_multiplexing} quali sono le funzionalità del
sistema che ci permettono di tenere sotto controllo più file descriptor in
contemporanea; in quella occasione non abbiamo fatto esempi, in quanto quando
si tratta con file normali questa tipologia di I/O non viene usata, è invece
un caso tipico delle applicazioni di rete quello di dover gestire varie
connessioni da cui possono arrivare dati comuni in maniera asincrona, per cui
riprenderemo l'argomento in questa sezione.



\subsection{La funzione \func{select} con i socket.}
\label{sec:TCP_sock_select}




Iniziamo con la prima delle funzioni usate per l'I/O multiplexing,
\func{select}, il suo funzionamento è già stato descritto in dettaglio in
\secref{sec:file_multiplexing}; e sappiamo che la funzione ritorna quando uno
o più dei file descriptor messi sotto controllo è pronto per la relativa
operazione. 

In quell'occasione non abbiamo però definito cosa si intende per pronto,
infatti se per dei normali file, o anche per delle pipe, la condizione di
essere pronti per la lettura o la scrittura è ovvia, lo è un po' meno di meno
nel caso dei socket, visto che intervengono tutte le possibili condizioni
dovute alla rete. Occorre allora specificare quali sono le condizioni in cui
un socket risulta \textsl{pronto}.





\section{Le opzioni dei socket}
\label{sec:TCP_sock_options}

Dato che la maggior parte delle opzioni dei socket sono relative ai socket
TCP, ed hanno poi significato analogo quando usate con altri socket,
tratteremo qui l'argomento in generale.



\section{I dati \textit{out-of-band}}
\label{sec:TCP_outofband}

Una caratteristica speciale dei socket TCP è quella della presenza dei
cosiddetti dati \textit{out-of-band}



\subsection{La funzione \func{shutdown}}
\label{sec:TCP_shutdown}

Come spiegato in \secref{sec:TCP_conn_term} il procedimento di chiusura di un
socket TCP prevede che da entrambe le parti venga emesso un segmento FIN. È
pertanto del tutto normale dal punto di vista del protocollo che uno dei due
capi chiuda la connessione, quando l'altro capo la lascia
aperta.\footnote{abbiamo incontrato questa situazione nei vari scenari critici
  di \secref{sec:TCP_echo_critical}.}

È pertanto possibile avere una situazione in cui un capo della connessione non
avendo più nulla da scrivere, possa chiudere il socket, segnalando così
l'avvenuta terminazione della trasmissione (l'altro capo riceverà infatti un
end-of-file in lettura) mentre dall'altra parte si potrà proseguire la
trasmissione dei dati scrivendo sul socket che da quel lato è ancora aperto.
Questa è quella situazione in cui si dice che il socket è \textit{half
  closed}.

Il problema che si pone è che se la chiusura del socket è effettuata con la
funzione \func{close}, come spiegato in \secref{sec:TCP_func_close}, si perde
ogni possibilità di poter rileggere quanto l'altro capo può continuare a
scrivere. Per poter permettere allora 




%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "gapil"
%%% End: 
