Negli esempi dei capitoli precedenti abbiamo sempre identificato le singole
macchine attraverso indirizzi numerici, sfruttando al più le funzioni di
conversione elementare illustrate in sez.~\ref{sec:sock_addr_func} che
-permettono di passare da un indirizzo espresso in forma dotted decimal ad un
-numero. Vedremo in questa sezione le funzioni utilizzate per poter utilizzare
-dei nomi simbolici al posto dei valori numerici, e viceversa quelle che
-permettono di ottenere i nomi simbolici associati ad indirizzi, porte o altre
-proprietà del sistema.
+permettono di passare da un indirizzo espresso in forma \textit{dotted
+ decimal} ad un numero. Vedremo in questa sezione le funzioni utilizzate per
+poter utilizzare dei nomi simbolici al posto dei valori numerici, e viceversa
+quelle che permettono di ottenere i nomi simbolici associati ad indirizzi,
+porte o altre proprietà del sistema.
\subsection{La struttura del \textit{resolver}}
Lo schema di funzionamento del \textit{resolver} è illustrato in
fig.~\ref{fig:sock_resolver_schema}; in sostanza i programmi hanno a
disposizione un insieme di funzioni di libreria con cui chiamano il
-\textit{resolver}, indicate con le freccie nere. Ricevuta la richiesta è
+\textit{resolver}, indicate con le frecce nere. Ricevuta la richiesta è
quest'ultimo che, sulla base della sua configurazione, esegue le operazioni
necessarie a fornire la risposta, che possono essere la lettura delle
informazioni mantenute nei relativi dei file statici presenti sulla macchina,
una interrogazione ad un DNS (che a sua volta, per il funzionamento del
-protocollo può interrogarene altri) o la richiesta ad altri server per i quali
+protocollo, può interrogarne altri) o la richiesta ad altri server per i quali
sia fornito il supporto, come LDAP.\footnote{la sigla LDAP fa riferimento ad
un protocollo, il \textit{Lightweight Directory Access Protocol}, che
prevede un meccanismo per la gestione di \textsl{elenchi} di informazioni
via rete; il contenuto di un elenco può essere assolutamente generico, e
- questo permette il manenimento dei più vari tipi di informazioni su una
+ questo permette il mantenimento dei più vari tipi di informazioni su una
infrastruttura di questo tipo.}
La configurazione del \textit{resolver} attiene più alla amministrazione di
da LDAP.} o come quelli dei protocolli e dei servizi che sono mantenuti nei
file statici \file{/etc/protocols} e \file{/etc/services}. Molte di queste
informazioni non si trovano su un DNS, ma in una rete locale può essere molto
-utile centralizzare il mentenimento di alcune di esse su opportuni server.
+utile centralizzare il mantenimento di alcune di esse su opportuni server.
Inoltre l'uso di diversi supporti possibili per le stesse informazioni (ad
esempio il nome delle macchine può essere mantenuto sia tramite
\file{/etc/hosts}, che con il DNS, che con NIS) comporta il problema
dell'ordine in cui questi vengono interrogati.\footnote{con le implementazioni
classiche i vari supporti erano introdotti modificando direttamente le
- funzioni di liberia, prevedendo un ordine di interrogazione predefinito e
+ funzioni di libreria, prevedendo un ordine di interrogazione predefinito e
non modificabile (a meno di una ricompilazione delle librerie stesse).}
Per risolvere questa serie di problemi la risoluzione dei nomi a dominio
-eseguira dal \textit{resolver} è stata inclusa all'interno di un meccanismo
-generico per la risoluzione di corripondenze fra nomi ed informazioni ad essi
+eseguirà dal \textit{resolver} è stata inclusa all'interno di un meccanismo
+generico per la risoluzione di corrispondenze fra nomi ed informazioni ad essi
associate chiamato \textit{Name Service Switch}\footnote{il sistema è stato
introdotto la prima volta nelle librerie standard di Solaris, le \acr{glibc}
hanno ripreso lo stesso schema, si tenga presente che questo sistema non
benché in teoria sia solo uno dei possibili supporti su cui mantenere le
informazioni, in pratica costituisce il meccanismo principale con cui vengono
risolti i nomi a dominio. Per questo motivo esistono una serie di funzioni di
-libreria che servono specificamente ad esseguire delle interrogazioni verso un
+libreria che servono specificamente ad eseguire delle interrogazioni verso un
server DNS, funzioni che poi vengono utilizzate per realizzare le funzioni
generiche di libreria usate anche dal sistema del \textit{resolver}.
fra un nome a dominio ed un indirizzo IP sono solo uno fra i vari tipi di
informazione che un server DNS fornisce normalmente.
-L'esistenza di vari tipi di informazioni è un'altro dei motivi per cui il
+L'esistenza di vari tipi di informazioni è un altro dei motivi per cui il
\textit{resolver} prevede, rispetto a quelle relative alla semplice
risoluzione dei nomi, un insieme di funzioni specifiche dedicate
all'interrogazione di un server DNS; la prima di queste funzioni è
del dominio di default ai nomi singoli (che non
contengono cioè un ``\texttt{.}'').\\
\const{RES\_STAYOPEN} & usato con \const{RES\_USEVC} per mantenere
- aperte le connesioni TCP fra interrogazioni
+ aperte le connessioni TCP fra interrogazioni
diverse. \\
\const{RES\_DNSRCH} & se attivo \func{res\_search} esegue le ricerche
di nomi di macchine nel dominio corrente o nei
questo campo, ed il relativo significato sono illustrate in
tab.~\ref{tab:resolver_option}; trattandosi di una maschera binaria un valore
deve essere espresso con un opportuno OR aritmetico di dette costanti; ad
-esempio il valore di default delle opzioni, epsresso dalla costante
+esempio il valore di default delle opzioni, espresso dalla costante
\const{RES\_DEFAULT}, è definito come:
\includecodesnip{listati/resolv_option_def.c}
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 raddoppianto
+richiesta, ciascun tentativo di richiesta fallito viene ripetuto raddoppiando
il tempo di scadenza per il numero massimo di volte stabilito da
\texttt{RES\_RETRY}.
\end{table}
Come accennato le tipologie di dati che sono mantenibili su un server DNS sono
-diverse, ed a ciascuna di essa corriponde un diverso tipo di \textit{resource
+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
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 rifererimento; i dati relativi ad un certo
+ 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
\const{T\_MD} & destinazione per la posta elettronica.\\
\const{T\_MF} & redistributore per la posta elettronica.\\
\const{T\_CNAME} & nome canonico.\\
- \const{T\_SOA} & inzio di una zona di autorità.\\
+ \const{T\_SOA} & inizio di una zona di autorità.\\
\const{T\_MB} & nome a dominio di una casella di posta.\\
\const{T\_MG} & nome di un membro di un gruppo di posta.\\
\const{T\_MR} & nome di un cambiamento di nome per la posta.\\
\const{T\_SIG} & firma digitale di sicurezza.\\
\const{T\_KEY} & chiave per firma.\\
\const{T\_PX} & corrispondenza per la posta X.400.\\
- \const{T\_GPOS} & posizione grografica.\\
+ \const{T\_GPOS} & posizione geografica.\\
\const{T\_AAAA} & indirizzo IPv6.\\
\const{T\_LOC} & informazione di collocazione.\\
\const{T\_NXT} & dominio successivo.\\
funzioni del \textit{resolver}. Questi sono sostanzialmente i seguenti (per
indicarli si è usata la notazione dei file di zona di BIND):
\begin{basedescript}{\desclabelwidth{1.2cm}\desclabelstyle{\nextlinelabel}}
-\item[\texttt{A}] viene usato per indicare la corripondenza fra un nome a
+\item[\texttt{A}] viene usato per indicare la corrispondenza fra un nome a
dominio ed un indirizzo IPv4; ad esempio la corrispondenza fra
\texttt{dodds.truelite.it} e l'indirizzo IP \texttt{62.48.34.25}.
\item[\texttt{AAAA}] viene usato per indicare la corrispondenza fra un nome a
dominio ed un indirizzo IPv6; è chiamato in questo modo dato che la
dimensione di un indirizzo IPv6 è quattro volte quella di un indirizzo IPv4.
-\item[\texttt{PTR}] per fornire la corripondenza inversa fra un indirizzo IP
+\item[\texttt{PTR}] per fornire la corrispondenza inversa fra un indirizzo IP
ed un nome a dominio ad esso associato si utilizza questo tipo di record (il
cui nome sta per \textit{pointer}).
\item[\texttt{CNAME}] qualora si abbiamo più nomi che corrispondono allo
\headdecl{netdb.h}
\funcdecl{const char *hstrerror(int err)}
-Restituisce una stringa corripondente ad un errore di risoluzione.
+Restituisce una stringa corrispondente ad un errore di risoluzione.
\end{functions}
-\noindent che, come l'analoga \func{strerror}, restituise una stringa con un
+\noindent che, come l'analoga \func{strerror}, restituisce una stringa con un
messaggio di errore già formattato, corrispondente al codice passato come
argomento (che si presume sia dato da \var{h\_errno}).
\begin{minipage}[c]{15cm}
\includestruct{listati/hostent.h}
\end{minipage}
- \caption{La struttura \structd{hostent}.}
+ \caption{La struttura \structd{hostent} per la risoluzione dei nomi a
+ dominio e degli indirizzi IP.}
\label{fig:sock_hostent_struct}
\end{figure}
fig.~\ref{fig:myhost_example} è riportato un estratto del codice di un
programma che esegue una semplice interrogazione al \textit{resolver} usando
\func{gethostbyname} e poi ne stampa a video i risultati. Al solito il
-sorgente completo, he comprende il trattamento delle opzioni ed una funzione
+sorgente completo, che comprende il trattamento delle opzioni ed una funzione
per stampare un messaggio di aiuto, è nel file \texttt{myhost.c} dei sorgenti
allegati alla guida.
Il programma richiede un solo argomento che specifichi il nome da cercare,
senza il quale (\texttt{\small 12--15}) esce con un errore. Dopo di che
-(\texttt{\small 16}) si limita a chiamare \func{gethostbyname}, ricendo il
+(\texttt{\small 16}) si limita a chiamare \func{gethostbyname}, ricevendo il
risultato nel puntatore \var{data}. Questo (\texttt{\small 17--20}) viene
controllato per rilevare eventuali errori, nel qual caso il programma esce
dopo aver stampato un messaggio con \func{herror}.
come \index{\textit{value~result~argument}}\textit{value result argument}, si
deve specificare l'indirizzo della variabile su cui la funzione dovrà salvare
il codice di errore con \param{h\_errnop} e quello su cui dovrà salvare il
-puntatatore che si userà per accedere i dati con \param{result}.
+puntatore che si userà per accedere i dati con \param{result}.
In caso di successo entrambe le funzioni restituiscono un valore nullo,
altrimenti restituiscono un codice di errore negativo e all'indirizzo puntato
\end{functions}
In questo caso l'argomento \param{addr} dovrà essere il puntatore ad una
-appropriata struttura contentente il valore dell'indirizzo IP (o IPv6) che si
+appropriata struttura contenente il valore dell'indirizzo IP (o IPv6) che si
vuole risolvere. L'uso del tipo \type{char *} per questo argomento è storico,
il dato dovrà essere fornito in una struttura \struct{in\_addr}\footnote{si
ricordi che, come illustrato in fig.~\ref{fig:sock_sa_ipv4_struct}, questo
Per risolvere il problema dell'uso da parte delle due funzioni
\func{gethostbyname} e \func{gethostbyaddr} di memoria statica che può essere
-socrascritta fra due chiamate successive, e per avere sempre la possibilità di
+sovrascritta fra due chiamate successive, e per avere sempre la possibilità di
indicare esplicitamente il tipo di indirizzi voluto (cosa che non è possibile
con \func{gethostbyname}), vennero introdotte due nuove funzioni di
risoluzione,\footnote{le funzioni sono presenti nelle \acr{glibc} versione
Entrambe le funzioni supportano esplicitamente la scelta di una famiglia di
indirizzi con l'argomento \param{af} (che può assumere i valori
\const{AF\_INET} o \const{AF\_INET6}), e restituiscono un codice di errore
-(identico a quelli precedentemente illustrati in
-tab.~\ref{tab:h_errno_values}) nella variabile puntata da
-\param{error\_num}. La funzione \func{getipnodebyaddr} richiede poi che si
-specifichi l'indirizzo come per \func{gethostbyaddr} passando anche la
-lunghezza dello stesso nell'argomento \param{len}.
+(con valori identici a quelli precedentemente illustrati in
+tab.~\ref{tab:h_errno_values}) nella variabile puntata da \param{error\_num}.
+La funzione \func{getipnodebyaddr} richiede poi che si specifichi l'indirizzo
+come per \func{gethostbyaddr} passando anche la lunghezza dello stesso
+nell'argomento \param{len}.
La funzione \func{getipnodebyname} prende come primo argomento il nome da
risolvere, inoltre prevede un apposito argomento \param{flags}, da usare come
\end{table}
Entrambe le funzioni restituiscono un puntatore ad una struttura \var{hostent}
-allocata dinamicamente che contiene i risultati della ricerca, e per questo
-non soffrono dei problemi dovuti all'uso di una sezione statica di memoria
-presenti con le precedenti \func{gethostbyname} e \func{gethostbyaddr}.
-Questo però comporta la necessità di deallocare esplicitamente la memoria
-occupata dai risultati una volta che questi non siano più necessari, onde
-evitare perdite di memoria; a tale scopo viene fornita la funzione
-\funcd{freehostent}, il cui prototipo è:
+che contiene i risultati della ricerca, che viene allocata dinamicamente
+insieme a tutto lo spazio necessario a contenere i dati in essa referenziati;
+per questo motivo queste funzioni non soffrono dei problemi dovuti all'uso di
+una sezione statica di memoria presenti con le precedenti \func{gethostbyname}
+e \func{gethostbyaddr}. L'uso di una allocazione dinamica però comporta anche
+la necessità di deallocare esplicitamente la memoria occupata dai risultati
+una volta che questi non siano più necessari; a tale scopo viene fornita la
+funzione \funcd{freehostent}, il cui prototipo è:
\begin{functions}
\headdecl{netdb.h}
\headdecl{sys/types.h}
tab.~\ref{tab:name_resolution_functions}, dove le si sono suddivise rispetto
al tipo di informazione che forniscono (riportato in prima colonna). Nella
tabella si è anche riportato il file su cui vengono ordinariamente mantenute
-queste informazioni, che può essere sostituito da un qualunque supporto
-interno al \textit{Name Service Switch}, anche se usualmente questo avviene
-solo per la risoluzione degli indirizzi. Ciascuna funzione fa riferimento ad
+queste informazioni, che però può essere sostituito da un qualunque supporto
+interno al \textit{Name Service Switch} (anche se usualmente questo avviene
+solo per la risoluzione degli indirizzi). Ciascuna funzione fa riferimento ad
una sua apposita struttura che contiene i relativi dati, riportata in terza
colonna.
una entità esterna; per le altre invece, estensioni fornite dal NSS a parte,
si fa sempre riferimento ai dati mantenuti nei rispettivi file.
-Consideriamo allora una ricerca sui nomi dei servizi, le due funzioni in
-questione sono \funcd{getservbyname} e \funcd{getservbyaddr} i cui prototopi
-sono:
+Dopo la risoluzione dei nomi a dominio una delle ricerche più comuni è quella
+sui nomi dei servizi noti (cioè \texttt{http}, \texttt{smtp}, ecc.) da
+associare alle rispettive porte, le due funzioni da utilizzare per questo sono
+\funcd{getservbyname} e \funcd{getservbyaddr}, che permettono rispettivamente
+di ottenere il numero di porta associato ad un servizio dato il nome e
+viceversa; i loro prototipi sono:
\begin{functions}
\headdecl{netdb.h}
\funcdecl{struct servent *getservbyname(const char *name, const char *proto)}
\funcdecl{struct servent *getservbyport(int port, const char *proto)}
- Disalloca una struttura \var{hostent}.
+ Risolvono il nome di un servizio nel rispettivo numero di porta e viceversa.
- \bodydesc{La funzione non ritorna nulla.}
+ \bodydesc{Ritornano il puntatore ad una struttura \struct{servent} con i
+ risultati in caso di successo, o \const{NULL} in caso di errore.}
\end{functions}
+Entrambe le funzioni prendono come ultimo argomento una stringa \param{proto}
+che indica il protocollo per il quale si intende effettuare la
+ricerca,\footnote{le informazioni mantenute in \file{/etc/services} infatti
+ sono relative sia alle porte usate su UDP che su TCP, occorre quindi
+ specificare a quale dei due protocolli si fa riferimento.} che nel caso si
+IP può avere come valori possibili solo \texttt{udp} o
+\texttt{tcp};\footnote{in teoria si potrebbe avere un qualunque protocollo fra
+ quelli citati in \file{/etc/protocols}, posto che lo stesso supporti il
+ concetto di \textsl{porta}, in pratica questi due sono gli unici presenti.}
+se si specifica un puntatore nullo la ricerca sarà eseguita su un protocollo
+qualsiasi.
+
+Il primo argomento è il nome del servizio per \func{getservbyname},
+specificato tramite la stringa \param{name}, mentre \func{getservbyport}
+richiede il numero di porta in \param{port}. Entrambe le funzioni eseguono una
+ricerca sul file \file{/etc/services}\footnote{il \textit{Name Service Switch}
+ astrae il concetto a qualunque supporto su cui si possano mantenere i
+ suddetti dati. } ed estraggono i dati dalla prima riga che corrisponde agli
+argomenti specificati; se la risoluzione ha successo viene restituito un
+puntatore ad una apposita struttura \struct{servent} contenente tutti i
+risultati), altrimenti viene restituito un puntatore nullo. Si tenga presente
+che anche in questo caso i dati vengono mantenuti in una area di memoria
+statica e che quindi la funzione non è rientrante.
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \includestruct{listati/servent.h}
+ \end{minipage}
+ \caption{La struttura \structd{servent} per la risoluzione dei nomi dei
+ servizi e dei numeri di porta.}
+ \label{fig:sock_servent_struct}
+\end{figure}
+
+La definizione della struttura \struct{servent} è riportata in
+fig.~\ref{fig:sock_servent_struct}, il primo campo, \var{s\_name} contiene
+sempre il nome canonico del servizio, mentre \var{s\_aliases} è un puntatore
+ad un vettore di stringhe contenenti gli eventuali nomi alternativi
+utilizzabili per identificare lo stesso servizio. Infine \var{s\_port}
+contiene il numero di porta e \var{s\_proto} il nome del protocollo.
+
+Come riportato in tab.~\ref{tab:name_resolution_functions} ci sono analoghe
+funzioni per la risoluzione del nome dei protocolli e delle reti; non staremo
+a descriverle nei dettagli, in quanto il loro uso è molto limitato, esse
+comunque hanno una struttura del tutto analoga alle precedenti, e tutti i
+dettagli relativi al loro funzionamento possono essere trovati nelle
+rispettive pagine di manuale.
+
+Oltre alle funzioni di ricerca esistono delle ulteriori funzioni che prevedono
+una lettura sequenziale delle informazioni mantenute nel \textit{Name Service
+ Switch} (in sostanza permettono di leggere i file contenenti le informazioni
+riga per riga), che sono analoghe a quelle elencate in
+tab.~\ref{tab:sys_passwd_func} per le informazioni relative ai dati degli
+utenti e dei gruppi. Nel caso specifico dei servizi avremo allora le tre
+funzioni \funcd{setservent}, \funcd{getservent} e \funcd{endservent} i cui
+prototipi sono:
+\begin{functions}
+ \headdecl{netdb.h}
+ \funcdecl{void setservent(int stayopen)}
+ Apre il file \file{/etc/services} e si posiziona al suo inizio.
+
+ \funcdecl{struct servent *getservent(void)}
+ Legge la voce successiva nel file \file{/etc/services}.
+
+ \funcdecl{void endservent(void)}
+ Chiude il file \file{/etc/services}.
+
+ \bodydesc{Le due funzioni \func{setservent} e \func{endservent} non
+ restituiscono nulla, \func{getservent} restituisce il puntatore ad una
+ struttura \struct{servent} in caso di successo e \const{NULL} in caso di
+ errore o fine del file.}
+\end{functions}
-Oltre alle precedenti funzioni di ricerca sono definite anche delle ulteriori
-funzioni generiche che permettono di accedere direttamente al contenuto dei
-file contenenti le informazioni; come le precedenti esse sono tutte nella
-forma \texttt{setXXXent}, \texttt{getXXXent} ed \texttt{endXXXent}, e sono
-analoghe a quelle viste in sez.~\ref{sec:sys_user_group} per la lettura delle
-informazioni relative ai dati degli utenti e dei gruppi (vedi
-tab.~\ref{tab:sys_passwd_func}) che pure sono mantenute tremite il
-\textit{Name Service Switch}.
+La prima funzione, \func{getservent}, legge una singola voce a partire dalla
+posizione corrente in \file{/etc/services}, pertanto si può eseguire una
+lettura sequenziale dello stesso invocandola più volte. Se il file non è
+aperto provvede automaticamente ad aprirlo, nel qual caso leggerà la prima
+voce. La seconda funzione, \func{setservent}, permette di aprire il file
+\file{/etc/services} per una successiva lettura, ma se il file è già stato
+aperto riporta la posizione di lettura alla prima voce del file, in questo
+modo si può far ricominciare da capo una lettura sequenziale. L'argomento
+\param{stayopen}, se diverso da zero, fa sì che il file resti aperto anche fra
+diverse chiamate a \func{getservbyname} e \func{getservbyaddr}.\footnote{di
+ default dopo una chiamata a queste funzioni il file viene chiuso, cosicchè
+ una successiva chiamata a \func{getservent} riparte dall'inizio.} La terza
+funzione, \funcd{endservent}, provvede semplicemente a chiudere il file.
+
+Queste tre funzioni per la lettura sequenziale di nuovo sono presenti per
+ciascuno dei vari tipi di informazione relative alle reti di
+tab.~\ref{tab:name_resolution_functions}; questo significa che esistono
+altrettante funzioni nella forma \texttt{setXXXent}, \texttt{getXXXent} e
+\texttt{endXXXent}, analoghe alle precedenti per la risoluzione dei servizi,
+che abbiamo riportato in tab.~\ref{tab:name_sequential_read}. Essendo, a
+parte il tipo di informazione che viene trattato, sostanzialmente identiche
+nel funzionamento e di scarso utilizzo, non staremo a trattarle una per una,
+rimandando alle rispettive pagine di manuale.
+\begin{table}[!htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|l|l|l|}
+ \hline
+ \textbf{Informazione}&\multicolumn{3}{|c|}{\textbf{Funzioni}}\\
+ \hline
+ \hline
+ indirizzo&\func{sethostent}&\func{gethostent}&\func{endhostent} \\
+ servizio &cd te\func{setservent}&\func{getservent}&\func{endservent}\\
+ rete &\func{setnetent}&\func{getnetent}&\func{endnetent}\\
+ protocollo&\func{setprotoent}&\func{getprotoent}&\func{endprotoent}\\
+ \hline
+ \end{tabular}
+ \caption{Funzioni lettura sequenziale dei dati del \textit{Name Service
+ Switch}.}
+ \label{tab:name_sequential_read}
+\end{table}
di vari inconvenienti come il fatto che usano informazioni statiche, e non
prevedono la possibilità di avere diverse classi di indirizzi. Anche se sono
state create delle estensioni o metodi diversi che permettono di risolvere
-questi inconvenienti, non c'è comunque una interfaccia sufficientemente
-generica
-
+alcuni di questi inconvenienti,\footnote{rimane ad esempio il problema
+ generico che si deve sapere in anticipo quale tipo di indirizzi IP (IPv4 o
+ IPv6) corrispondono ad un certo nome a dominio.} comunque esse non
+forniscono una interfaccia sufficientemente generica.
+
+Inoltre in genere quando si ha a che fare con i socket non esiste soltanto il
+problema della risoluzione del nome che identifica la macchina, ma anche
+quello del servizio a cui ci si vuole rivolgere. Per questo motivo con lo
+standard Posix 1003.1-2001 sono state indicate come deprecate le varie
+funzioni \func{gethostbyaddr}, \func{gethostbyname}, \var{getipnodebyname} e
+\var{getipnodebyaddr} ed è stata introdotta una interfaccia completamente
+nuova.
+
+La prima funzione di questa interfaccia, che combina le funzionalità di
+\func{getipnodebyname}, \func{getipnodebyaddr}, \func{getservbyname} e
+\func{getservbyport}, consentendo di ottenere contemporaneamente la
+risoluzione di un indirizzo e di un servizio, è \funcd{getaddrinfo}, il cui
+prototipo è:
+\begin{functions}
+ \headdecl{netdb.h}
+ \headdecl{sys/socket.h}
+ \headdecl{netdb.h}
-Per questo motivo lo standard Posix 1003.1-2001 indicava come deprecate le
-varie \func{gethostbyaddr}, \func{gethostbyname}, \var{getipnodebyname} e
-\var{getipnodebyaddr} per introdurre una interfaccia
+ \funcdecl{int getaddrinfo(const char *node, const char *service, const
+ struct addrinfo *hints, struct addrinfo **res)}
+ Esegue una risoluzione di un nome a dominio e di un nome di servizio.
+ \bodydesc{La funzione restituisce 0 in caso di successo o un codice di
+ errore diverso da zero in caso di fallimento.}
+\end{functions}
-rimane comunque il problema generico che si deve sapere
-in anticipo quale tipo di indirizzi devo
+La funzione prende come primo argomento il nome della macchina che si vuole
+risolvere. Questo, oltre ad un comune nome a dominio, può essere anche un
+indirizzo numerico in forma \textit{dotted-decimal} per IPv4 o in formato
+esadecimale per IPv6. Si può anche specificare il nome di una rete invece che
+di una singola macchina. Il secondo argomento specifica invece il nome del
+servizio che si intende risolvere. Uno di questi due argomenti può essere
+anche inizializzato a \const{NULL}
projects / gapil.git / commitdiff