regolare la connessione. Normalmente vengono usate le seguenti opzioni:
\begin{itemize}
-\item \textit{MSS option}, dove MMS sta per \textit{maximum segment size}, con
- questa opzione ciascun capo della connessione annuncia all'altro il massimo
- ammontare di dati che vorrebbe accettare per ciascun segmento nella
- connessione corrente. È possibile leggere e scrivere questo valore
- attraverso l'opzione del socket \const{TCP\_MAXSEG}.
+\item \textit{MSS option}, dove MMS sta per \itindex{Maximum~Segment~Size}
+ \textit{Maximum Segment Size}, con questa opzione ciascun capo della
+ connessione annuncia all'altro il massimo ammontare di dati che vorrebbe
+ accettare per ciascun segmento nella connessione corrente. È possibile
+ leggere e scrivere questo valore attraverso l'opzione del socket
+ \const{TCP\_MAXSEG}.
\item \textit{window scale
option}, %come spiegato in sez.~\ref{sec:tcp_protocol}
\end{itemize}
-La MSS è generalmente supportata da quasi tutte le implementazioni del
-protocollo, le ultime due opzioni (trattate
+La MSS \itindex{Maximum~Segment~Size} è generalmente supportata da quasi tutte
+le implementazioni del protocollo, le ultime due opzioni (trattate
nell'\href{http://www.ietf.org/rfc/rfc1323.txt}{RFC~1323}) sono meno comuni;
vengono anche dette \textit{long fat pipe options} dato che questo è il nome
che viene dato alle connessioni caratterizzate da alta velocità o da ritardi
\label{fig:TCP_conn_example}
\end{figure}
-La connessione viene iniziata dal client che annuncia un MSS di 1460, un
-valore tipico con Linux per IPv4 su Ethernet, il server risponde con lo stesso
-valore (ma potrebbe essere anche un valore diverso).
+La connessione viene iniziata dal client che annuncia una MSS
+\itindex{Maximum~Segment~Size} di 1460, un valore tipico con Linux per IPv4 su
+Ethernet, il server risponde con lo stesso valore (ma potrebbe essere anche un
+valore diverso).
Una volta che la connessione è stabilita il client scrive al server una
richiesta (che assumiamo stare in un singolo segmento, cioè essere minore dei
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 per dei normali file, o anche per delle pipe, la condizione di essere
pronti per la lettura o la scrittura è ovvia; invece lo è molto meno nel caso
dei socket, visto che possono intervenire tutte una serie di possibili
condizioni di errore dovute alla rete. Occorre allora specificare chiaramente
quali sono le condizioni per cui un socket risulta essere ``\textsl{pronto}''
-quando viene passato come membro di uno dei tre \textit{file descriptor set}
-usati da \func{select}.
+quando viene passato come membro di uno dei tre \itindex{file~descriptor~set}
+\textit{file descriptor set} usati da \func{select}.
Le condizioni che fanno si che la funzione \func{select} ritorni segnalando
che un socket (che sarà riportato nel primo insieme di file descriptor) è
non si bloccherà ma restituirà una condizione di errore (ad esempio
\func{read} restituirà -1) e imposterà la variabile \var{errno} al relativo
valore. Vedremo in sez.~\ref{sec:sock_generic_options} come sia possibile
- estrarre e cancellare errori pendenti su un socket usando l'opzione
- \const{SO\_ERROR}.
+ estrarre e cancellare gli errori pendenti su un socket senza usare
+ \func{read} usando l'opzione \const{SO\_ERROR}.
\item quando si sta utilizzando un \textit{listening socket} ed ci sono delle
connessioni completate. In questo caso la funzione \func{accept} non si
bloccherà.\footnote{in realtà questo non è sempre vero, come accennato in
Infine c'è una sola condizione che fa si che \func{select} ritorni segnalando
che un socket (che sarà riportato nel terzo insieme di file descriptor) ha una
-condizione di eccezione pendente, e cioè la ricezione sul socket di dati
-\textsl{fuori banda} (o \itindex{out-of-band} \textit{out-of-band}), una
+condizione di eccezione pendente, e cioè la ricezione sul socket di
+\textsl{dati urgenti} (o \itindex{out-of-band} \textit{out-of-band}), una
caratteristica specifica dei socket TCP su cui torneremo in
sez.~\ref{sec:TCP_urgent_data}.
allegati alla guida.
In questo caso la funzione comincia (\texttt{\small 8--9}) con l'azzeramento
-del file descriptor set \var{fset} e l'impostazione del valore \var{maxfd}, da
-passare a \func{select} come massimo per il numero di file descriptor. Per
-determinare quest'ultimo si usa la macro \code{max} definita nel nostro file
-\file{macro.h} che raccoglie una collezione di macro di preprocessore di varia
-utilità.
+del \itindex{file~descriptor~set} \textit{file descriptor set} \var{fset} e
+l'impostazione del valore \var{maxfd}, da passare a \func{select} come massimo
+per il numero di file descriptor. Per determinare quest'ultimo si usa la macro
+\code{max} definita nel nostro file \file{macro.h} che raccoglie una
+collezione di macro di preprocessore di varia utilità.
La funzione prosegue poi (\texttt{\small 10--41}) con il ciclo principale, che
viene ripetuto indefinitamente. Per ogni ciclo si reinizializza
-(\texttt{\small 11--12}) il file descriptor set, impostando i valori per il
-file descriptor associato al socket \var{socket} e per lo standard input (il
-cui valore si recupera con la funzione \func{fileno}). Questo è necessario in
-quanto la successiva (\texttt{\small 13}) chiamata a \func{select} comporta
-una modifica dei due bit relativi, che quindi devono essere reimpostati
-all'inizio di ogni ciclo.
+(\texttt{\small 11--12}) il \itindex{file~descriptor~set} \textit{file
+ descriptor set}, impostando i valori per il file descriptor associato al
+socket \var{socket} e per lo standard input (il cui valore si recupera con la
+funzione \func{fileno}). Questo è necessario in quanto la successiva
+(\texttt{\small 13}) chiamata a \func{select} comporta una modifica dei due
+bit relativi, che quindi devono essere reimpostati all'inizio di ogni ciclo.
Si noti come la chiamata a \func{select} venga eseguita usando come primo
argomento il valore di \var{maxfd}, precedentemente calcolato, e passando poi
-il solo file descriptor set per il controllo dell'attività in lettura, negli
-altri argomenti sono passati tutti puntatori nulli, non interessando né il
-controllo delle altre attività, né l'impostazione di un valore di timeout.
+il solo \itindex{file~descriptor~set} \textit{file descriptor set} per il
+controllo dell'attività in lettura, negli altri argomenti sono passati tutti
+puntatori nulli, non interessando né il controllo delle altre attività, né
+l'impostazione di un valore di timeout.
Al ritorno di \func{select} si provvede a controllare quale dei due file
descriptor presenta attività in lettura, cominciando (\texttt{\small 14--24})
non nullo, dopo di che (\texttt{\small 20}) si effettua la chiusura del lato
in scrittura del socket con \func{shutdown}. Infine (\texttt{\small 21}) si
usa la macro \macro{FD\_CLR} per togliere lo standard input dal file
-descriptor set.
+descriptor set. \itindex{file~descriptor~set}
In questo modo anche se la lettura del file in ingresso è conclusa, la
funzione non esce dal ciclo principale (\texttt{\small 11--50}), ma continua
alto.} che verrà anche (\texttt{\small 4}) inserito nella tabella.
La prima sezione (\texttt{\small 7--10}) del ciclo principale esegue la
-costruzione del \textit{file descriptor set} \var{fset} in base ai socket
-connessi in un certo momento; all'inizio ci sarà soltanto il socket in
-ascolto, ma nel prosieguo delle operazioni, verranno utilizzati anche tutti i
-socket connessi registrati nella tabella \var{fd\_open}. Dato che la chiamata
-di \func{select} modifica il valore del \textit{file descriptor set}, è
-necessario ripetere (\texttt{\small 7}) ogni volta il suo azzeramento, per poi
-procedere con il ciclo (\texttt{\small 8--10}) in cui si impostano i socket
-trovati attivi.
+costruzione del \itindex{file~descriptor~set} \textit{file descriptor set}
+\var{fset} in base ai socket connessi in un certo momento; all'inizio ci sarà
+soltanto il socket in ascolto, ma nel prosieguo delle operazioni, verranno
+utilizzati anche tutti i socket connessi registrati nella tabella
+\var{fd\_open}. Dato che la chiamata di \func{select} modifica il valore del
+\itindex{file~descriptor~set} \textit{file descriptor set}, è necessario
+ripetere (\texttt{\small 7}) ogni volta il suo azzeramento, per poi procedere
+con il ciclo (\texttt{\small 8--10}) in cui si impostano i socket trovati
+attivi.
Per far questo si usa la caratteristica dei file descriptor, descritta in
sez.~\ref{sec:file_open}, per cui il kernel associa sempre ad ogni nuovo file
(\texttt{\small 29--55}) fintanto che il numero di socket attivi \var{n} resta
diverso da zero; in questo modo se l'unico socket con attività era quello
connesso, avendo opportunamente decrementato il contatore, il ciclo verrà
-saltato, e si ritornerà immediatamente (ripetuta l'inizializzazione del file
-descriptor set con i nuovi valori nella tabella) alla chiamata di
-\func{accept}. Se il socket attivo non è quello in ascolto, o ce ne sono
-comunque anche altri, il valore di \var{n} non sarà nullo ed il controllo sarà
-eseguito. Prima di entrare nel ciclo comunque si inizializza (\texttt{\small
- 28}) il valore della variabile \var{i} che useremo come indice nella tabella
-\var{fd\_open} al valore minimo, corrispondente al file descriptor del socket
-in ascolto.
+saltato, e si ritornerà immediatamente (ripetuta l'inizializzazione del
+\itindex{file~descriptor~set} file descriptor set con i nuovi valori nella
+tabella) alla chiamata di \func{accept}. Se il socket attivo non è quello in
+ascolto, o ce ne sono comunque anche altri, il valore di \var{n} non sarà
+nullo ed il controllo sarà eseguito. Prima di entrare nel ciclo comunque si
+inizializza (\texttt{\small 28}) il valore della variabile \var{i} che useremo
+come indice nella tabella \var{fd\_open} al valore minimo, corrispondente al
+file descriptor del socket in ascolto.
Il primo passo (\texttt{\small 30}) nella verifica è incrementare il valore
dell'indice \var{i} per posizionarsi sul primo valore possibile per un file
queste problematiche con i socket. Abbiamo però visto in
sez.~\ref{sec:file_multiplexing} come la funzione \func{poll} possa costituire
una alternativa a \func{select}, con alcuni vantaggi.\footnote{non soffrendo
- delle limitazioni dovute all'uso dei \textit{file descriptor set}.}
+ delle limitazioni dovute all'uso dei \itindex{file~descriptor~set}
+ \textit{file descriptor set}.}
Ancora una volta in sez.~\ref{sec:file_poll} abbiamo trattato la funzione in
maniera generica, parlando di file descriptor, ma come per \func{select}
\item i dati inviati su un socket vengono considerati traffico normale,
pertanto vengono rilevati alla loro ricezione sull'altro capo da una
selezione effettuata con \const{POLLIN} o \const{POLLRDNORM};
-\item i dati \itindex{out-of-band} \textit{out-of-band} (vedi
+\item i dati urgenti \itindex{out-of-band} \textit{out-of-band} (vedi
sez.~\ref{sec:TCP_urgent_data}) su un socket TCP vengono considerati
traffico prioritario e vengono rilevati da una condizione \const{POLLIN},
\const{POLLPRI} o \const{POLLRDBAND}.
uscita e notifica in caso si errore (\texttt{\small 49--52}).
Come si può notare la logica del programma è identica a quella vista in
-fig.~\ref{fig:TCP_SelectEchod} per l'analogo server basato su \func{select}; la
-sola differenza significativa è che in questo caso non c'è bisogno di
-rigenerare i file descriptor set in quanto l'uscita è indipendente dai dati in
-ingresso. Si applicano comunque anche a questo server le considerazioni finali
-di sez.~\ref{sec:TCP_serv_select}.
+fig.~\ref{fig:TCP_SelectEchod} per l'analogo server basato su \func{select};
+la sola differenza significativa è che in questo caso non c'è bisogno di
+rigenerare i \itindex{file~descriptor~set} file descriptor set in quanto
+l'uscita è indipendente dai dati in ingresso. Si applicano comunque anche a
+questo server le considerazioni finali di sez.~\ref{sec:TCP_serv_select}.
% LocalWords: socket TCP client dell'I multiplexing stream three way handshake
projects / gapil.git / blobdiff