sono specificati server verrà utilizzato l'indirizzo locale, e se non è
definito un dominio di default sarà usato quello associato con l'indirizzo
locale (ma questo può essere sovrascritto con l'uso della variabile di
-ambiente \texttt{LOCALDOMAIN}). In genere non è necessario eseguire questa
+ambiente \envvar{LOCALDOMAIN}). In genere non è necessario eseguire questa
funzione direttamente in quanto viene automaticamente chiamata la prima volta
che si esegue una delle altre.
Le impostazioni e lo stato del \textit{resolver} vengono mantenuti in una
serie di variabili raggruppate nei campi di una apposita struttura \var{\_res}
-usata da tutte queste funzioni. Essa viene definita in \file{resolv.h} ed è
-utilizzata internamente alle funzioni essendo definita come variabile globale;
-questo consente anche di accedervi direttamente all'interno di un qualunque
-programma, una volta che la sia opportunamente dichiarata come:
+usata da tutte queste funzioni. Essa viene definita in \headfile{resolv.h} ed
+è utilizzata internamente alle funzioni essendo definita come variabile
+globale; questo consente anche di accedervi direttamente all'interno di un
+qualunque programma, una volta che la sia opportunamente dichiarata come:
\includecodesnip{listati/resolv_option.c}
Tutti i campi della struttura sono ad uso interno, e vengono usualmente
\const{RES\_INSECURE1} & Blocca i controlli di sicurezza di tipo 1.\\
\const{RES\_INSECURE2} & Blocca i controlli di sicurezza di tipo 2.\\
\const{RES\_NOALIASES} & Blocca l'uso della variabile di ambiente
- \texttt{HOSTALIASES}.\\
+ \envvar{HOSTALIASES}.\\
\const{RES\_USE\_INET6} & Restituisce indirizzi IPv6 con
\func{gethostbyname}. \\
\const{RES\_ROTATE} & Ruota la lista dei server DNS dopo ogni
modificarli direttamente; gran parte di essi sono infatti impostati dal
contenuto dei file di configurazione, mentre le funzionalità controllate da
alcuni di esse possono essere modificate con l'uso delle opportune variabili
-di ambiente come abbiamo visto per \texttt{LOCALDOMAIN}. In particolare con
-\texttt{RES\_RETRY} si soprassiede il valore del campo \var{retry} che
+di ambiente come abbiamo visto per \envvar{LOCALDOMAIN}. In particolare con
+\envvar{RES\_RETRY} si soprassiede il valore del campo \var{retry} che
controlla quante volte viene ripetuto il tentativo di connettersi ad un server
DNS prima di dichiarare fallimento; il valore di default è 4, un valore nullo
-significa bloccare l'uso del DNS. Infine con \texttt{RES\_TIMEOUT} si
+significa bloccare l'uso del DNS. Infine con \envvar{RES\_TIMEOUT} si
soprassiede il valore del campo \var{retrans},\footnote{preimpostato al valore
- della omonima costante \const{RES\_TIMEOUT} di \file{resolv.h}.} che è il
-valore preso come base (in numero di secondi) per definire la scadenza di una
-richiesta, ciascun tentativo di richiesta fallito viene ripetuto raddoppiando
-il tempo di scadenza per il numero massimo di volte stabilito da
+ della omonima costante \const{RES\_TIMEOUT} di \headfile{resolv.h}.} che è
+il valore preso come base (in numero di secondi) per definire la scadenza di
+una richiesta, ciascun tentativo di richiesta fallito viene ripetuto
+raddoppiando il tempo di scadenza per il numero massimo di volte stabilito da
\texttt{RES\_RETRY}.
La funzione di interrogazione principale è \funcd{res\_query}, che serve ad
eseguire una richiesta ad un server DNS per un nome a dominio
-\textsl{completamente specificato} (quello che si chiama FQDN, \textit{Fully
- Qualified Domain Name}); il suo prototipo è:
+\textsl{completamente specificato} (quello che si chiama
+\itindex{Fully~Qualified~Domain~Name~(FQDN)} FQDN, \textit{Fully Qualified
+ Domain Name}); il suo prototipo è:
\begin{functions}
\headdecl{netinet/in.h}
Come accennato le tipologie di dati che sono mantenibili su un server DNS sono
diverse, ed a ciascuna di essa corrisponde un diverso tipo di \textit{resource
record}. L'elenco delle costanti\footnote{ripreso dai file di dichiarazione
- \file{arpa/nameser.h} e \file{arpa/nameser\_compat.h}.} che definiscono i
-valori che si possono usare per l'argomento \param{type} per specificare il
-tipo di \textit{resource record} da richiedere è riportato in
+ \headfile{arpa/nameser.h} e \headfile{arpa/nameser\_compat.h}.} che
+definiscono i valori che si possono usare per l'argomento \param{type} per
+specificare il tipo di \textit{resource record} da richiedere è riportato in
tab.~\ref{tab:DNS_record_type}; le costanti (tolto il \texttt{T\_} iniziale)
hanno gli stessi nomi usati per identificare i record nei file di zona di
BIND,\footnote{BIND, acronimo di \textit{Berkley Internet Name Domain}, è una
implementazione di un server DNS, ed, essendo utilizzata nella stragrande
- maggioranza dei casi, fa da riferimento; i dati relativi ad un certo
- dominio (cioè i suoi \textit{resource record} vengono mantenuti in quelli
- che sono usualmente chiamati \textsl{file di zona}, e in essi ciascun tipo
- di dominio è identificato da un nome che è appunto identico a quello delle
- costanti di tab.~\ref{tab:DNS_record_type} senza il \texttt{T\_} iniziale.}
-e che normalmente sono anche usati come nomi per indicare i record.
+ maggioranza dei casi, fa da riferimento; i dati relativi ad un certo dominio
+ (cioè i suoi \textit{resource record} vengono mantenuti in quelli che sono
+ usualmente chiamati \textsl{file di zona}, e in essi ciascun tipo di dominio
+ è identificato da un nome che è appunto identico a quello delle costanti di
+ tab.~\ref{tab:DNS_record_type} senza il \texttt{T\_} iniziale.} e che
+normalmente sono anche usati come nomi per indicare i record.
\begin{table}[!htb]
\centering
In questo caso la funzione prende un secondo argomento \param{af} che indica
(i soli valori consentiti sono \const{AF\_INET} o \const{AF\_INET6}, per
-questo è necessario l'uso di \texttt{sys/socket.h}) la famiglia di indirizzi
+questo è necessario l'uso di \headfile{sys/socket.h}) la famiglia di indirizzi
che dovrà essere utilizzata nei risultati restituiti dalla funzione. Per tutto
il resto la funzione è identica a \func{gethostbyname}, ed identici sono i
suoi risultati.
\end{figure}
Come illustrato la struttura \struct{addrinfo}, la cui definizione\footnote{la
- definizione è ripresa direttamente dal file \texttt{netdb.h} in questa
+ definizione è ripresa direttamente dal file \headfile{netdb.h} in questa
struttura viene dichiarata, la pagina di manuale riporta \type{size\_t} come
tipo di dato per il campo \var{ai\_addrlen}, qui viene usata quanto previsto
dallo standard POSIX, in cui viene utilizzato \type{socklen\_t}; i due tipi
qualora la loro dimensione ecceda quelle specificate dagli argomenti
\param{hostlen} e \param{servlen}. Sono comunque definite le due costanti
\const{NI\_MAXHOST} e \const{NI\_MAXSERV}\footnote{in Linux le due costanti
- sono definite in \file{netdb.h} ed hanno rispettivamente il valore 1024 e
- 12.} che possono essere utilizzate come limiti massimi. In caso di errore
-viene restituito invece un codice che assume gli stessi valori illustrati in
-tab.~\ref{tab:addrinfo_error_code}.
+ sono definite in \headfile{netdb.h} ed hanno rispettivamente il valore 1024
+ e 12.} che possono essere utilizzate come limiti massimi. In caso di
+errore viene restituito invece un codice che assume gli stessi valori
+illustrati in tab.~\ref{tab:addrinfo_error_code}.
A questo punto possiamo fornire degli esempi di utilizzo della nuova
interfaccia, adottandola per le precedenti implementazioni del client e del
connessioni (è pertanto usata con i socket TCP ed ignorata per UDP) e
modifica il comportamento delle funzioni \func{close} e \func{shutdown}.
L'opzione richiede che l'argomento \param{optval} sia una struttura di tipo
- \struct{linger}, definita in \texttt{sys/socket.h} ed illustrata in
+ \struct{linger}, definita in \headfile{sys/socket.h} ed illustrata in
fig.~\ref{fig:sock_linger_struct}. Maggiori dettagli sul suo funzionamento
sono forniti in sez.~\ref{sec:sock_options_main}.
livello da utilizzare è \const{SOL\_IP} (o l'equivalente \const{IPPROTO\_IP});
si è riportato un elenco di queste opzioni in tab.~\ref{tab:sock_opt_iplevel}.
Le costanti indicanti le opzioni e tutte le altre costanti ad esse collegate
-sono definite in \file{netinet/ip.h}, ed accessibili includendo detto file.
+sono definite in \headfile{netinet/ip.h}, ed accessibili includendo detto
+file.
\begin{table}[!htb]
\centering
dove sono elencate le rispettive costanti da utilizzare come valore per
l'argomento \param{optname}. Dette costanti e tutte le altre costanti e
strutture collegate all'uso delle opzioni TCP sono definite in
-\file{netinet/tcp.h}, ed accessibili includendo detto file.\footnote{in realtà
- questo è il file usato dalle librerie; la definizione delle opzioni
- effettivamente supportate da Linux si trova nel file \texttt{linux/tcp.h},
- dal quale si sono estratte le costanti di tab.~\ref{tab:sock_opt_tcplevel}.}
+\headfile{netinet/tcp.h}, ed accessibili includendo detto file.\footnote{in
+ realtà questo è il file usato dalle librerie; la definizione delle opzioni
+ effettivamente supportate da Linux si trova nel file
+ \texttt{include/linux/tcp.h} dei sorgenti del kernel, dal quale si sono
+ estratte le costanti di tab.~\ref{tab:sock_opt_tcplevel}.}
\begin{table}[!htb]
\centering
questo caso per poterle utilizzare occorrerà impostare l'opportuno valore per
l'argomento \param{level}, che è \const{SOL\_UDP} (o l'equivalente
\const{IPPROTO\_UDP}). Le costanti che identificano dette opzioni sono
-definite in \file{netinet/udp.h}, ed accessibili includendo detto
+definite in \headfile{netinet/udp.h}, ed accessibili includendo detto
file.\footnote{come per TCP, la definizione delle opzioni effettivamente
- supportate dal kernel si trova in realtà nel file \texttt{linux/udp.h}, dal
- quale si sono estratte le costanti di tab.~\ref{tab:sock_opt_udplevel}.}
+ supportate dal kernel si trova in realtà nel file
+ \texttt{include/linux/udp.h}, dal quale si sono estratte le costanti di
+ tab.~\ref{tab:sock_opt_udplevel}.}
\begin{table}[!htb]
\centering
projects / gapil.git / blobdiff