X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=sockctrl.tex;h=62989d4a2deaa2922461f33ff4c9e966f0a82500;hp=66015acec48883333b651c75b5ce3103aafd4bb4;hb=9f5fac5abf66c3a2fe782ecc17d63b62af2485ef;hpb=ec40bdfb4408819c4b6845e2c25b897ae505cc59 diff --git a/sockctrl.tex b/sockctrl.tex index 66015ac..62989d4 100644 --- a/sockctrl.tex +++ b/sockctrl.tex @@ -13,29 +13,454 @@ Esamineremo in questo capitolo una serie di funzionalità aggiuntive relative alla gestione dei socket, come la gestione della risoluzione di nomi e -indirizzi, le impostazioni delle varie proprietà degli stessi, e le funzioni -di controllo che vanno ad operare su di essi. +indirizzi, le impostazioni delle varie proprietà ed opzioni relative ai +socket, e le funzioni di controllo che permettono di modificarne il +comportamento. +\section{La risoluzione dei nomi} +\label{sec:sock_name_resolution} -\section{La gestione degli indirizzi} -\label{sec:sock_addresses} +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. -Negli esempi precedenti abbiamo sempre identificato le singole macchine -attraverso indirizzi numerici, sfruttando al più le funzioni di conversione -elementari 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 identificare le varie -proprietà di un indirizzo (numero IP e porta) attraverso dei nomi simbolici -che vengano automaticamente tradotti nei rispettivi valori numerici. - -\subsection{Il sistema del \textit{resolver}} +\subsection{La struttura del \textit{resolver}} \label{sec:sock_resolver} +La risoluzione dei nomi è associata tradizionalmente al servizio del +\textit{Domain Name Service} che permette di identificare le macchine su +internet invece che per numero IP attraverso il relativo \textsl{nome a + dominio}.\footnote{non staremo ad entrare nei dettagli della definizione di + cosa è un nome a dominio, dandolo per noto, una introduzione alla + problematica si trova in \cite{AGL} (cap. 9) mentre per una trattazione + approfondita di tutte le problematiche relative al DNS si può fare + riferimento a \cite{DNSbind}.} In realtà per DNS si intendono spesso i +server che forniscono su internet questo servizio, mentre nel nostro caso +affronteremo la problematica dal lato client, di un qualunque programma che +necessita di compiere questa operazione. + +\begin{figure}[htb] + \centering + \includegraphics[width=10cm]{img/resolver} + \caption{Schema di funzionamento delle routine del \textit{resolver}.} + \label{fig:sock_resolver_schema} +\end{figure} + +Inoltre quella fra nomi a dominio e indirizzi IP non è l'unica corrispondenza +possibile fra nomi simbolici e valori numerici, come abbiamo visto anche in +sez.~\ref{sec:sys_user_group} per le corrispondenze fra nomi di utenti e +gruppi e relativi identificatori numerici; per quanto riguarda però tutti i +nomi associati a identificativi o servizi relativi alla rete il servizio di +risoluzione è gestito in maniera unificata da un insieme di routine fornite +con le librerie del C, detto appunto \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 è +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 +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 + infrastruttura di questo tipo.} + +La configurazione del \textit{resolver} attiene più alla amministrazione di +sistema che alla programmazione, ciò non di meno, prima di trattare le varie +funzioni di librerie utilizzate dai programmi, vale la pena fare una +panoramica generale. Originariamente la configurazione del \textit{resolver} +riguardava esclusivamente le questioni relative alla gestione dei nomi a +dominio, e prevedeva solo l'utilizzo del DNS e del file statico +\file{/etc/hosts}. + +Per questo aspetto il file di configurazione principale del sistema è +\file{/etc/resolv.conf} che contiene in sostanza l'elenco dei server DNS da +contattare; a questo si affianca il file \file{/etc/host.conf} il cui scopo +principale è indicare l'ordine in cui eseguire la risoluzione dei nomi (se +usare prima i valori di \file{/etc/hosts} o quelli del DNS). Tralasciamo i +dettagli relativi alle varie direttive che possono essere usate in questi +file, che si trovano nelle rispettive pagine di manuale. + +Con il tempo però è divenuto possibile fornire diversi sostituti per +l'utilizzo delle associazione statiche in \file{/etc/hosts}, inoltre oltre +alla risoluzione dei nomi a dominio ci sono anche altri nomi da risolvere, +come quelli che possono essere associati ad una rete (invece che ad una +singola macchina) o ai gruppi di macchine definiti dal servizio +NIS,\footnote{il \textit{Network Information Service} è un servizio, creato da + Sun, e poi diffuso su tutte le piattaforme unix-like, che permette di + raggruppare all'interno di una rete (in quelli che appunto vengono chiamati + \textit{netgroup}) varie macchine, centralizzando i servizi di definizione + di utenti e gruppi e di autenticazione, oggi è sempre più spesso sostituito + 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, e poi in un ambiente distribuito può +essere molto utile centralizzare il mentenimento 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 + 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 +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 + esiste per altre librerie standard come le \acr{libc5} o le \acr{uclib}.} +cui abbiamo accennato anche in sez.~\ref{sec:sys_user_group} per quanto +riguarda la gestione dei dati associati a utenti e gruppi. Il \textit{Name + Service Switch} (cui spesso si fa riferimento con l'acronimo NSS) è un +sistema di librerie dinamiche che permette di definire in maniera generica sia +i supporti su cui mantenere i dati di corrispondenza fra nomi e valori +numerici, sia l'ordine in cui effettuare le ricerche sui vari supporti +disponibili. Il sistema prevede una serie di possibili classi di +corrispondenza, quelle attualmente definite sono riportate in +tab.~\ref{tab:sys_NSS_classes}. + +\begin{table}[htb] + \footnotesize + \centering + \begin{tabular}[c]{|l|p{8cm}|} + \hline + \textbf{Classe} & \textbf{Tipo di corrispondenza}\\ + \hline + \hline + \texttt{shadow} & corrispondenze fra username e proprietà dell'utente + (\acr{uid}, ecc.).\\ + \texttt{group} & corrispondenze fra nome del gruppo e proprietà dello + stesso.\\ + \texttt{aliases} & alias per la posta elettronica\\ + \texttt{ethers} & corrispondenze fra numero IP e MAC address della + scheda di rete.\\ + \texttt{hosts} & corrispondenze fra nome a dominio e numero IP.\\ + \texttt{netgroup} & corrispondenze gruppo di rete e macchine che lo + compongono.\\ + \texttt{networks} & corrispondenze fra nome di una rete e suo indirizzo + IP.\\ + \texttt{protocols}& corrispondenze fra nome di un protocollo e relativo + numero identificativo.\\ + \texttt{rpc} & corrispondenze fra nome di un servizio RPC e relativo + numero identificativo.\\ + \texttt{services} & corrispondenze fra nome di un servizio e numero di + porta. \\ + \hline + \end{tabular} + \caption{Le diverse classi di corrispondenze definite + all'interno del \textit{Name Service Switch}.} + \label{tab:sys_NSS_classes} +\end{table} + +Il sistema del \textit{Name Service Switch} è controllato dal contenuto del +file \file{/etc/nsswitch.conf}; questo contiene una riga\footnote{seguendo una + convezione comune per i file di configurazione le righe vuote vengono + ignorate e tutto quello che segue un carattere ``\texttt{\#}'' viene + considerato un commento.} di configurazione per ciascuna di queste classi, +che viene inizia col nome di tab.~\ref{tab:sys_NSS_classes} seguito da un +carattere ``\texttt{:}'' e prosegue con la lista dei \textsl{servizi} su cui +le relative informazioni sono raggiungibili, scritti nell'ordine in cui si +vuole siano interrogati. + +Ogni servizio è specificato a sua volta da un nome, come \texttt{file}, +\texttt{dns}, \texttt{db}, ecc. che identifica la libreria dinamica che +realizza l'interfaccia con esso. Per ciascun servizio se \texttt{NAME} è il +nome utilizzato dentro \file{/etc/nsswitch.conf}, dovrà essere presente +(usualmente in \file{/lib}) una libreria \texttt{libnss\_NAME} che ne +implementa le funzioni. + +In ogni caso, qualunque sia la modalità con cui ricevono i dati o il supporto +su cui vengono mantenuti, e che si usino o meno funzionalità aggiuntive +fornire dal sistema del \textit{Name Service Switch}, dal punto di vista di un +programma che deve effettuare la risoluzione di un nome a dominio, tutto +quello che conta sono le funzioni classiche che il \textit{resolver} mette a +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. + + +\subsection{Le funzioni di interrogazione del \textit{resolver}} +\label{sec:sock_resolver_functions} + +Prima di trattare le funzioni usate normalmente nella risoluzione dei nomi a +dominio conviene trattare in maniera più dettagliata il meccanismo principale +da esse utilizzato e cioè quello del servizio DNS. Come accennato questo, +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 +server DNS, funzioni che poi vengono utilizzate per realizzare le funzioni +generiche di libreria usate anche dal sistema del \textit{resolver}. + +Il sistema del DNS è in sostanza di un database distribuito organizzato in +maniera gerarchica, la manutenzione dei dati è mantenuta in tanti server +distinti ciascuno dei quali si occupa della risoluzione del proprio +\textsl{dominio}; i nomi a dominio sono poi organizzati in una struttura ad +albero analoga a quella dell'albero dei file in un sistema unix-like, con +domini di primo livello (come i \texttt{.org}), secondo livello (come +\texttt{.truelite.it}), ecc. In questo caso le separazioni sono fra i vari +livelli sono definite dal carattere ``\texttt{.}'' ed i nomi devono essere +risolti da destra verso sinistra. Il meccanismo funziona con il criterio della +\textsl{delegazione}, un server responsabile per un dominio di primo livello +può delegare la risoluzione degli indirizzi per un suo dominio di secondo +livello ad un altro server, il quale a sua volta potrà delegare la risoluzione +di un eventuale sottodominio di terzo livello ad un altro server ancora. + +In realtà un server DNS contiene comunque una serie di altre informazioni; +ciascuna voce nel database viene chiamata \textit{resource record}, e può +contenere diverse informazioni; in genere i \textit{resource record} vengono +classificati per la \textsl{classe di indirizzi} cui i dati contenuti fanno +riferimento, e per il \textsl{tipo} di questi ultimi. Oggigiorno i dati +mantenuti nei server DNS sono sostanzialmente relativi soltanto ad indirizzi +internet, per cui in pratica c'è soltanto una classe di indirizzi utilizzata, +i dati invece possono essere di vario tipo, uno dei quali è appunto la +corrispondenza fra nome a dominio e numero IP. + +L'esistenza di vari tipi di informazioni ottenibili da un server DNS è +un'altro dei motivi per cui il \textit{resolver} prevede un insieme di +funzioni dedicato rispetto a quelle della semplice risoluzione dei nomi; la +prima di queste è \funcd{res\_init}, il cui prototipo è: +\begin{functions} +\headdecl{netinet/in.h} +\headdecl{arpa/nameser.h} +\headdecl{resolv.h} +\funcdecl{int res\_init(void)} + +Inizializza il sistema del \textit{resolver}. + +\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di + errore.} +\end{functions} + +La funzione legge il contenuto dei file di configurazione per impostare il +dominio di default, gli indirizzi dei server DNS da contattare e l'ordine +delle ricerche; se non sono specificati server verrà utilizzato l'indirizzo +locale, e se non è definito un dominio di default sarà usato quello associato +con l'indirizzo locale. In genere si deve eseguire questa funzione prima di +chiamare tutte le altre. + +Le impostazioni del resolver e lo stato del sistema vengono mantenute in una +serie di variabili globali contenuti in una apposita struttura interna, +definita in \file{resolv.h}, che può essere acceduta una volta che la si +dichiara con: +\includecodesnip{listati/resolv_option.c} + +Tutti i campi della struttura sono ad uso interno, l'unico che può essere +utile modificare è il campo \var{\_res.options}, che è una maschera binaria +che permette di controllare il comportamento del resolver, modificandone +alcune impostazioni direttamente da programma prima di invocare +\func{res\_init}. Le costanti che definiscono i vari bit di questo campo, con +il relativo significato sono illustrate in tab.~\ref{tab:resolver_option}, un +valore deve essere espresso con un opportuno OR aritmetico di dette costanti; +ad esempio il valore di default dato dalla costante \const{RES\_DEFAULT} è +definito come: +\includecodesnip{listati/resolv_option_def.c} + +\begin{table}[htb] + \centering + \footnotesize + \begin{tabular}[c]{|l|p{8cm}|} + \hline + \textbf{Costante} & \textbf{Significato} \\ + \hline + \hline + \const{RES\_INIT} & viene attivato se è stata chiamata + \func{res\_init}. \\ + \const{RES\_DEBUG} & stampa dei messaggi di debug.\\ + \const{RES\_AAONLY} & accetta solo risposte autoritative.\\ + \const{RES\_USEVC} & usa connessioni TCP per contattare i server + invece che l'usuale UDP.\\ + \const{RES\_PRIMARY} & interroga soltanto server DNS primari. + \\ + \const{RES\_IGNTC} & ignora gli errori di troncamento, non ritenta la + richiesta con una connessione TCP.\\ + \const{RES\_RECURSE} & imposta il bit che indica che si desidera + eseguire una interrogazione ricorsiva.\\ + \const{RES\_DEFNAMES} & se attivo \func{res\_search} aggiunge il nome + 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 + diverse. \\ + \const{RES\_DNSRCH} & se attivo \func{res\_search} esegue le ricerche + di nomi di macchine nel dominio corrente o nei + domini ad esso sovrastanti.\\ + \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}.\\ + \const{RES\_USE\_INET6} & restituisce indirizzi IPv6 con + \func{gethostbyname}. \\ + \const{RES\_ROTATE} & ruota la lista dei server DNS dopo ogni + interrogazione.\\ + \const{RES\_NOCHECKNAME}& non controlla i nomi per verificarne la + correttezza sintattica. \\ + \const{RES\_KEEPTSIG} & non elimina i record di tipo \texttt{TSIG}.\\ + \const{RES\_BLAST} & \\ + \const{RES\_DEFAULT} & è l'insieme di \const{RES\_RECURSE}, + \const{RES\_DEFNAMES} e \const{RES\_DNSRCH}.\\ + \hline + \end{tabular} + \caption{Costanti utilizzabili come valori per \var{\_res.options}.} + \label{tab:resolver_option} +\end{table} + +La funzione di richiesta principale è \funcd{res\_query}, che serve ad +eseguire una richiesta ad un server DNS per un nome a dominio completamente +specificato (quello che si chiama FQDN, \textit{Fully Qualified Domain Name}); +il suo prototipo è: + +\begin{functions} +\headdecl{netinet/in.h} +\headdecl{arpa/nameser.h} +\headdecl{resolv.h} +\funcdecl{int res\_query(const char *dname, int class, int type, + unsigned char *answer, int anslen)} + + Esegue una interrogazione al DNS. + +\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di + errore.} +\end{functions} + + +Per quanto ci interessa i tipi di \textit{resource record} che vengono +utilizzati dal \textit{resolver} sono sostanzialmente i seguenti: +\begin{basedescript}{\desclabelwidth{1.2cm}\desclabelstyle{\nextlinelabel}} +\item[\texttt{A}] indica la corripondenza 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}] chiamato in questo modo dato che la dimensione è quattro + volte quella di un indirizzo IPv4, questo record contiene la corrispondenza + fra un nome a dominio ed un indirizzo IPv6. +\item[\texttt{PTR}] per provvedere la mappatura inversa fra un indirizzo IP ed + un nome a dominio si utilizza invece questo tipo di record (il cui nome sta + per \textit{pointer}). +\item[\texttt{CNAME}] qualora si abbiamo più nomi con i quali si voglia + indicare lo stesso indirizzo (ad esempio \texttt{www.truelite.it}, o + \texttt{sources.truelite.it}, che comunque fanno sempre riferimento alla + macchina \texttt{dodds.truelite.it}) si può usare questo tipo di record per + creare degli \textit{alias} in modo da associare un qualunque altro nome al + \textsl{nome canonico} della macchina (quello associato al record + \texttt{A}). +\end{basedescript} + + + + + + +Per questo motivo il \textit{resolver} prevede delle funzioni che permettono +sia di eseguire direttamente delle interrogazione ad un server DNS, che di +controllare le modalità con cui queste vengono eseguite; diventa così +possibile modificare da programma buona parte dei parametri controllati da +\file{/etc/resolv.conf}. + + + +\subsection{La risoluzione dei nomi a dominio} +\label{sec:sock_gethostbyname} + +Dato che la principale funzionalità del \textit{resolver} resta quella di +risolvere i nomi a dominio in indirizzi IP, vedremo per prime le funzioni a +questo dedicate. La prima funzione è \funcd{gethostbyname} il cui scopo è +ottenere l'indirizzo di una stazione noto il suo nome a dominio, il suo +prototipo è: +\begin{prototype}{netdb.h} +{struct hostent *gethostbyname(const char *name)} + +Determina l'indirizzo associato al nome a dominio \param{name}. + +\bodydesc{La funzione restituisce in caso di successo il puntatore ad una + struttura di tipo \struct{hostent} contente i dati associati al nome a + dominio o un puntatore nullo in caso di errore.} +\end{prototype} + +La funzione prende come argomento una stringa \param{name} contenente il nome +a dominio che si vuole risolvere, in caso di successo i dati ad esso relativi +vengono memorizzati in una opportuna struttura \struct{hostent} la cui +definizione è riportata in fig.~\ref{fig:sock_hostent_struct}. In caso di +insuccesso l'errore viene segnalato da un valore nullo del puntatore, ma in +questo caso, a differenza delle funzioni viste finora, non viene utilizzata la +variabile \var{errno} per riportare un codice di errore, in quanto questo +dipende solo dalle sottostanti chiamate al sistema e può non avere nessun +significato nell'indicare quale parte del procedimento di risoluzione è +fallita. + +\begin{figure}[!htb] + \footnotesize \centering + \begin{minipage}[c]{15cm} + \includestruct{listati/hostent.h} + \end{minipage} + \caption{La struttura \structd{hostent}.} + \label{fig:sock_hostent_struct} +\end{figure} + +Per questo motivo all'interno del resolver è stata definita una apposita +variabile di errore, \var{h\_errno} che viene utilizzata dalle funzioni di +libreria per indicare quale problema ha causato il fallimento della +risoluzione del nome. Ad essa si può accedere una volta che la si dichiara +con: +\includecodesnip{listati/herrno.c} +ed i valori che può assumere sono i seguenti: +\begin{basedescript}{\desclabelwidth{3cm}\desclabelstyle{\nextlinelabel}} +\item[\const{HOST\_NOT\_FOUND}] l'indirizzo richiesto non è valido e la + macchina indicata è sconosciuta. +\item[\const{NO\_ADDRESS}] il nome a dominio richiesto è valido, ma non ha un + indirizzo associato ad esso (alternativamente può essere indicato come + \const{NO\_DATA}). +\item[\const{NO\_RECOVERY}] si è avuto un errore non recuperabile + nell'interrogazione di un server DNS. +\item[\const{TRY\_AGAIN}] si è avuto un errore temporaneo nell'interrogazione + di un server DNS, si può ritentare l'interrogazione in un secondo tempo. +\end{basedescript} + +Quando un programma chiama \func{gethostbyname} e questa usa il DNS per +effettuare la risoluzione del nome, è con i valori di questi record che +vengono riempite le varie parti della struttura \struct{hostent}. Il primo +campo della struttura, \var{h\_name} contiene sempre il \textsl{nome + canonico}, che nel caso del DNS è appunto il nome associato ad un record +\texttt{A}. Il secondo campo della struttura, \var{h\_aliases}, invece è un +puntatore ad vettore di puntatori, terminato da un puntatore nullo. Ciascun +puntatore del vettore punta ad una stringa contenente uno degli altri +possibili nomi associati allo stesso \textsl{nome canonico} (quelli che nel +DNS vengono inseriti come record di tipo \texttt{CNAME}). + +Il terzo campo della struttura, \var{h\_addrtype}, indica il tipo di indirizzo +che è stato restituito, e può assumere soltanto i valori \const{AF\_INET} o +\const{AF\_INET6}, mentre il quarto campo, \var{h\_length}, indica la +lunghezza dell'indirizzo stesso in byte. La funzione ritorna sempre una +struttura + +Infine il campo \var{h\_addr\_list} è il puntatore ad un vettore di puntatori +ai singoli indirizzi; il vettore è terminato da un puntatore nullo. Inoltre, +come illustrato in fig.~\ref{fig:sock_hostent_struct}, viene definito il campo +\var{h\_addr} come sinonimo di \code{h\_addr\_list[0]}, cioè un riferimento +diretto al primo indirizzo della lista. + +Oltre ai normali nomi a dominio la funzione accetta come argomento +\param{name} anche indirizzi numerici, in formato dotted decimal per IPv4 o +con la notazione illustrata in sez.~\ref{sec:IP_ipv6_notation}. In tal caso +\func{gethostbyname} non eseguirà nessuna interrogazione remota, ma si +limiterà a copiare la stringa nel campo \var{h\_name} ed a creare la +corrispondente struttura \var{in\_addr} da indirizzara con +\code{h\_addr\_list[0]}. + + -Effettueremo in questa sezione una trattazione completa delle funzioni -utilizzate per la gestione degli indirizzi dei socket.