%% sockctrl.tex
%%
-%% Copyright (C) 2004 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2004-2005 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",
\begin{figure}[htb]
\centering
- \includegraphics[width=10cm]{img/resolver}
+ \includegraphics[width=9cm]{img/resolver}
\caption{Schema di funzionamento delle routine del \textit{resolver}.}
\label{fig:sock_resolver_schema}
\end{figure}
funzioni di libreria, prevedendo un ordine di interrogazione predefinito e
non modificabile (a meno di una ricompilazione delle librerie stesse).}
+\index{\textit{Name~Service~Switch}|(}
Per risolvere questa serie di problemi la risoluzione dei nomi a dominio
eseguirà dal \textit{resolver} è stata inclusa all'interno di un meccanismo
generico per la risoluzione di corrispondenze fra nomi ed informazioni ad essi
disposizione,\footnote{è cura della implementazione fattane nelle \acr{glibc}
tenere conto della presenza del \textit{Name Service Switch}.} e sono queste
quelle che tratteremo nelle sezioni successive.
+\index{\textit{Name~Service~Switch}|)}
\subsection{Le funzioni di interrogazione del \textit{resolver}}
sez.~\ref{sec:TCP_func_accept}) ed adottato dalle \acr{glibc}.} è la
dimensione in byte dei dati presenti all'indirizzo indicato da \param{optval}.
Dato che il tipo di dati varia a seconda dell'opzione scelta, occorrerà
-individuare qual'è quello che deve essere usato, ed utilizzare le opportune
+individuare qual è quello che deve essere usato, ed utilizzare le opportune
variabili.
La gran parte delle opzioni utilizzano per \param{optval} un valore intero, se
ma esistono ancora dei processi figli che mantengono attiva almeno una
connessione remota che utilizza l'indirizzo locale; quando si riavvia il
server questo viene bloccato sulla chiamata a \func{bind} dato che la porta
- è ancora utilizzata in una connessione esistente.
-
- Il punto più critico è che con il protocollo TCP questo può avvenire anche
- dopo che l'ultimo processo figlio è terminato, in quanto la connessione può
- restare attiva anche dopo la chiusura del socket mantenendosi nello stato
- \texttt{TIME\_WAIT}. Usando \const{SO\_REUSEADDR} fra la chiamata a
- \func{socket} e quella a \func{bind} si consente a quest'ultima di avere
- successo anche in questo caso. È bene però ricordare che (si riveda quanto
- detto in sez.~\ref{sec:TCP_time_wait}) la presenza dello stato
- \texttt{TIME\_WAIT} ha una ragione, e che se si usa questa opzione esiste
- sempre una probabilità, anche se estremamente remota,\footnote{perché ciò
- avvenga infatti non solo devono coincidere gli indirizzi IP e le porte
- degli estremi della nuova connessione, ma anche i numeri di sequenza dei
- pacchetti, e questo è estremamente improbabile.} che eventuali pacchetti
- rimasti intrappolati in una precedente connessione possano finire fra quelli
- di una nuova.
-
-
-
-
+ è ancora utilizzata in una connessione esistente.\footnote{questa è una
+ delle domande più frequenti sui newsgroup dedicati allo sviluppo, in
+ quanto è piuttosto comune in questa situazione quando si sta sviluppando
+ un server che si ferma e si riavvia in continuazione.} Inoltre se si usa
+ il protocollo TCP questo può avvenire anche dopo che l'ultimo processo
+ figlio è terminato, dato che la connessione può restare attiva anche dopo la
+ chiusura del socket mantenendosi nello stato \texttt{TIME\_WAIT}.
+
+ Usando \const{SO\_REUSEADDR} fra la chiamata a \func{socket} e quella a
+ \func{bind} si consente a quest'ultima di avere comunque successo anche se
+ la connessione è attiva (o nello stato texttt{TIME\_WAIT}). È bene però
+ ricordare (si riveda quanto detto in sez.~\ref{sec:TCP_time_wait}) che la
+ presenza dello stato \texttt{TIME\_WAIT} ha una ragione, ed infatti se si
+ usa questa opzione esiste sempre una probabilità, anche se estremamente
+ remota,\footnote{perché ciò avvenga infatti non solo devono coincidere gli
+ indirizzi IP e le porte degli estremi della nuova connessione, ma anche i
+ numeri di sequenza dei pacchetti, e questo è estremamente improbabile.}
+ che eventuali pacchetti rimasti intrappolati in una precedente connessione
+ possano finire fra quelli di una nuova.
+
+ Il secondo caso in cui viene usata questa opzione è quando si ha una
+ macchina cui sono assegnati diversi numeri IP (o come suol dirsi
+ \textit{multi-homed}) e si vuole porre in ascolto sulla stessa porta un
+ programma diverso (o una istanza diversa dello stesso programma) per
+ indirizzi IP diversi. Si ricordi infatti che è sempre possibile indicare a
+ \func{bind} di collegarsi solo su di un indirizzo specifico; in tal caso se
+ un altro programma cerca di riutilizzare la stessa porta (anche specificando
+ un indirizzo diverso) otterrà un errore a meno di non aver preventivamente
+ impostato \const{SO\_REUSEADDR}. Usando questa opzione diventa anche
+ possibile eseguire \func{bind} sull'indirizzo generico, e questo permetterà
+ il collegamento per tutti gli indirizzi (di quelli presenti) per i quali la
+ porta risulti libera. Infine si tenga presente che con il protocollo TCP non
+ è mai possibile far partire server che eseguano \func{bind} sullo stesso
+ indirizzo e la stessa porta, cioè ottenere quello che viene chiamato un
+ \textit{completely duplicate binding}.
+
+ Il terzo impiego è simile al precedente e prevede l'uso di \func{bind}
+ all'interno dello stesso programma per associare indirizzi diversi a socket
+ diversi. Vale in questo caso quanto detto in precedenza, l'unica differenza
+ è che in questo caso le diverse chiamate a \func{bind} sono eseguite
+ all'interno dello stesso programma.
\item[\const{SO\_TYPE}] questa opzione permette di leggere il tipo di socket