Le funzioni illustrate finora hanno un difetto: utilizzando una area di
memoria interna per allocare i contenuti della struttura \struct{hostent} non
-possono essere\index{funzioni!rientranti} rientranti. Questo comporta anche
-che in due successive chiamate i dati potranno essere sovrascritti. Si tenga
-presente poi che copiare il contenuto della sola struttura non è sufficiente
-per salvare tutti i dati, in quanto questa contiene puntatori ad altri dati,
-che pure possono essere sovrascritti; per questo motivo, se si vuole salvare
-il risultato di una chiamata, occorrerà eseguire quella che si chiama una
-\itindex{deep~copy} \textit{deep copy}.\footnote{si chiama così quella tecnica
- per cui, quando si deve copiare il contenuto di una struttura complessa (con
- puntatori che puntano ad altri dati, che a loro volta possono essere
- puntatori ad altri dati) si deve copiare non solo il contenuto della
- struttura, ma eseguire una scansione per risolvere anche tutti i puntatori
- contenuti in essa (e così via se vi sono altre sotto-strutture con altri
- puntatori) e copiare anche i dati da questi referenziati.}
+possono essere rientranti. Questo comporta anche che in due successive
+chiamate i dati potranno essere sovrascritti. Si tenga presente poi che
+copiare il contenuto della sola struttura non è sufficiente per salvare tutti
+i dati, in quanto questa contiene puntatori ad altri dati, che pure possono
+essere sovrascritti; per questo motivo, se si vuole salvare il risultato di
+una chiamata, occorrerà eseguire quella che si chiama una \itindex{deep~copy}
+\textit{deep copy}.\footnote{si chiama così quella tecnica per cui, quando si
+ deve copiare il contenuto di una struttura complessa (con puntatori che
+ puntano ad altri dati, che a loro volta possono essere puntatori ad altri
+ dati) si deve copiare non solo il contenuto della struttura, ma eseguire una
+ scansione per risolvere anche tutti i puntatori contenuti in essa (e così
+ via se vi sono altre sotto-strutture con altri puntatori) e copiare anche i
+ dati da questi referenziati.}
Per ovviare a questi problemi nelle \acr{glibc} sono definite anche delle
-versioni \index{funzioni!rientranti} rientranti delle precedenti funzioni, al
-solito queste sono caratterizzate dall'avere un suffisso \texttt{\_r},
-pertanto avremo le due funzioni \funcd{gethostbyname\_r} e
-\funcd{gethostbyname2\_r} i cui prototipi sono:
+versioni rientranti delle precedenti funzioni, al solito queste sono
+caratterizzate dall'avere un suffisso \texttt{\_r}, pertanto avremo le due
+funzioni \funcd{gethostbyname\_r} e \funcd{gethostbyname2\_r} i cui prototipi
+sono:
\begin{functions}
\headdecl{netdb.h}
\headdecl{sys/socket.h}
\param{buf} e \param{buflen}.
Gli ultimi due argomenti vengono utilizzati per avere indietro i risultati
-come \itindex{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
-puntatore che si userà per accedere i dati con \param{result}.
+come \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 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
da \param{result} sarà salvato un puntatore nullo, mentre a quello puntato da
\param{h\_errnop} sarà salvato il valore del codice di errore, dato che per
-essere \index{funzioni!rientranti} rientrante la funzione non può la variabile
-globale \var{h\_errno}. In questo caso il codice di errore, oltre ai valori di
+essere rientrante la funzione non può la variabile globale \var{h\_errno}. In
+questo caso il codice di errore, oltre ai valori di
tab.~\ref{tab:h_errno_values}, può avere anche quello di \errcode{ERANGE}
qualora il buffer allocato su \param{buf} non sia sufficiente a contenere i
dati, in tal caso si dovrà semplicemente ripetere l'esecuzione della funzione
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 è \index{funzioni!rientranti}
-rientrante.
+memoria statica e che quindi la funzione non è rientrante.
\begin{figure}[!htb]
\footnotesize \centering
Come ultimo argomento in \param{res} deve essere passato un puntatore ad una
variabile (di tipo puntatore ad una struttura \struct{addrinfo}) che verrà
-utilizzata dalla funzione per riportare (come \itindex{value~result~argument}
-\textit{value result argument}) i propri risultati. La funzione infatti è
-\index{funzioni!rientranti} rientrante, ed alloca autonomamente tutta la
-memoria necessaria in cui verranno riportati i risultati della risoluzione.
-La funzione scriverà all'indirizzo puntato da \param{res} il puntatore
-iniziale ad una \itindex{linked~list} \textit{linked list} di strutture di
-tipo \struct{addrinfo} contenenti tutte le informazioni ottenute.
+utilizzata dalla funzione per riportare (come \textit{value result argument})
+i propri risultati. La funzione infatti è rientrante, ed alloca autonomamente
+tutta la memoria necessaria in cui verranno riportati i risultati della
+risoluzione. La funzione scriverà all'indirizzo puntato da \param{res} il
+puntatore iniziale ad una \itindex{linked~list} \textit{linked list} di
+strutture di tipo \struct{addrinfo} contenenti tutte le informazioni ottenute.
\begin{figure}[!htb]
\footnotesize \centering
Si noti come per la funzione sia del tutto irrilevante se la struttura
ritornata contiene indirizzi IPv6 o IPv4, in quanto si fa uso direttamente dei
dati relativi alle strutture degli indirizzi di \struct{addrinfo} che sono
-\index{tipo!opaco} opachi rispetto all'uso della funzione \func{connect}.
+opachi rispetto all'uso della funzione \func{connect}.
\begin{figure}[!htbp]
\footnotesize \centering
per entrambe le funzioni. In questo caso \param{optval} viene usato per
ricevere le informazioni ed indica l'indirizzo a cui andranno scritti i dati
letti dal socket, infine \param{optlen} diventa un puntatore ad una variabile
-che viene usata come \itindex{value~result~argument} \textit{value result
- argument} per indicare, prima della chiamata della funzione, la lunghezza
-del buffer allocato per \param{optval} e per ricevere indietro, dopo la
-chiamata della funzione, la dimensione effettiva dei dati scritti su di esso.
-Se la dimensione del buffer allocato per \param{optval} non è sufficiente si
-avrà un errore.
+che viene usata come \textit{value result argument} per indicare, prima della
+chiamata della funzione, la lunghezza del buffer allocato per \param{optval} e
+per ricevere indietro, dopo la chiamata della funzione, la dimensione
+effettiva dei dati scritti su di esso. Se la dimensione del buffer allocato
+per \param{optval} non è sufficiente si avrà un errore.
\func{bind} su un indirizzo ed una porta che sono già \textsl{legati} ad un
altro socket. Questo ovviamente non ha senso per il normale traffico di rete,
in cui i pacchetti vengono scambiati direttamente fra due applicazioni; ma
-quando un sistema supporta il traffico in \itindex{multicast}
-\textit{multicast}, in cui una applicazione invia i pacchetti a molte altre
-(vedi sez.~\ref{sec:xxx_multicast}), allora ha senso che su una macchina i
-pacchetti provenienti dal traffico in \itindex{multicast} \textit{multicast}
+quando un sistema supporta il traffico in \textit{multicast}, allora ha senso
+che su una macchina i pacchetti provenienti dal traffico in \textit{multicast}
possano essere ricevuti da più applicazioni\footnote{l'esempio classico di
traffico in \textit{multicast} è quello di uno streaming di dati (audio,
video, ecc.), l'uso del \textit{multicast} consente in tal caso di
questo caso è perfettamente logico aspettarsi che sulla stessa macchina più
utenti possano lanciare un programma che permetta loro di ricevere gli
stessi dati.} o da diverse istanze della stessa applicazione.
-\itindex{multicast}
In questo caso utilizzando \const{SO\_REUSEADDR} si consente ad una
applicazione eseguire \func{bind} sulla stessa porta ed indirizzo usata da
la cosa non ha alcun senso per i socket TCP, ed infatti in questo tipo di
applicazione è normale l'uso del protocollo UDP). La regola è che quando si
hanno più applicazioni che hanno eseguito \func{bind} sulla stessa porta, di
-tutti pacchetti destinati ad un indirizzo di \itindex{broadcast}
-\textit{broadcast} o di \itindex{multicast} \textit{multicast} viene inviata
-una copia a ciascuna applicazione. Non è definito invece cosa accade qualora
-il pacchetto sia destinato ad un indirizzo normale (unicast).
+tutti pacchetti destinati ad un indirizzo di \textit{broadcast} o di
+\textit{multicast} viene inviata una copia a ciascuna applicazione. Non è
+definito invece cosa accade qualora il pacchetto sia destinato ad un indirizzo
+normale (unicast).
Essendo questo un caso particolare in alcuni sistemi (come BSD) è stata
introdotta una opzione ulteriore, \const{SO\_REUSEPORT} che richiede che detta
\const{IP\_ROUTER\_ALERT} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
Imposta l'opzione \textit{IP router alert} sui pacchetti.\\
\const{IP\_MULTICAST\_TTL} &$\bullet$&$\bullet$& &\texttt{int}&
- Imposta il TTL per i pacchetti \itindex{multicast} \textit{multicast}.\\
+ Imposta il TTL per i pacchetti \textit{multicast}.\\
\const{IP\_MULTICAST\_LOOP} &$\bullet$&$\bullet$&$\bullet$&\texttt{int}&
- Controlla il reinvio a se stessi dei dati di \itindex{multicast}
- \textit{multicast}.\\
+ Controlla il reinvio a se stessi dei dati di \textit{multicast}.\\
\const{IP\_ADD\_MEMBERSHIP} & &$\bullet$& &\struct{ip\_mreqn}&
- Si unisce a un gruppo di \itindex{multicast} \textit{multicast}.\\
+ Si unisce a un gruppo di \textit{multicast}.\\
\const{IP\_DROP\_MEMBERSHIP}& &$\bullet$& &\struct{ip\_mreqn}&
Si sgancia da un gruppo di \textit{multicast}.\\
\const{IP\_MULTICAST\_IF} & &$\bullet$& &\struct{ip\_mreqn}&
- Imposta l'interfaccia locale di un socket \itindex{multicast}
- \textit{multicast}.\\
+ Imposta l'interfaccia locale di un socket \textit{multicast}.\\
\hline
\end{tabular}
\caption{Le opzioni disponibili al livello \const{SOL\_IP}.}
sez.~\ref{sec:IP_options}) che devono essere inoltrati al socket
corrente. Può essere usata soltanto per socket di tipo raw.
-\itindbeg{multicast}
\item[\const{IP\_MULTICAST\_TTL}] L'opzione permette di impostare o leggere il
valore del campo TTL per i pacchetti \textit{multicast} in uscita associati
al socket. È importante che questo valore sia il più basso possibile, ed il
% TODO chiarire quale è la struttura \struct{ip\_mreq}
-\itindend{multicast}
\end{basedescript}
generico. Nell'elenco si illustrerà anche, per ciascuna operazione, il tipo di
dato usato come terzo argomento della funzione ed il significato che esso
viene ad assumere. Dato che in caso di lettura questi dati vengono restituiti
-come \itindex{value~result~argument} \textit{value result argument}, con
-queste operazioni il terzo argomento deve sempre essere passato come puntatore
-ad una variabile (o struttura) precedentemente allocata. Le costanti che
-identificano le operazioni sono le seguenti:
+come \textit{value result argument}, con queste operazioni il terzo argomento
+deve sempre essere passato come puntatore ad una variabile (o struttura)
+precedentemente allocata. Le costanti che identificano le operazioni sono le
+seguenti:
\begin{basedescript}{\desclabelwidth{2.5cm}\desclabelstyle{\nextlinelabel}}
\item[\const{SIOCGSTAMP}] restituisce il contenuto di una struttura
\struct{timeval} con la marca temporale dell'ultimo pacchetto ricevuto sul
pacchetti che vede passare, compresi quelli non
direttamente indirizzati a lei).\\
\const{IFF\_NOTRAILERS}& Evita l'uso di \textit{trailer} nei pacchetti.\\
- \const{IFF\_ALLMULTI} & Riceve tutti i pacchetti di \itindex{multicast}
- \textit{multicast}.\\
+ \const{IFF\_ALLMULTI} & Riceve tutti i pacchetti di \textit{multicast}.\\
\const{IFF\_MASTER} & L'interfaccia è il master di un bundle per il
bilanciamento di carico.\\
\const{IFF\_SLAVE} & L'interfaccia è uno slave di un bundle per il
bilanciamento di carico.\\
\const{IFF\_MULTICAST} & L'interfaccia ha il supporto per il
- \textit{multicast} \itindex{multicast} attivo.\\
+ \textit{multicast} attivo.\\
\const{IFF\_PORTSEL} & L'interfaccia può impostare i suoi parametri
hardware (con l'uso di \struct{ifmap}).\\
\const{IFF\_AUTOMEDIA} & L'interfaccia è in grado di selezionare
struttura \struct{ifmap}, secondo la definizione di
fig.~\ref{fig:netdevice_ifmap_struct}.
-\item[\const{SIOCADDMULTI}] aggiunge un indirizzo di \itindex{multicast}
- \textit{multicast} ai filtri del livello di collegamento associati
- dell'interfaccia. Si deve usare un indirizzo hardware da specificare
- attraverso il campo \var{ifr\_hwaddr}, che conterrà l'opportuna struttura
- \struct{sockaddr}; l'operazione è privilegiata. Per una modalità alternativa
- per eseguire la stessa operazione si possono usare i \textit{packet socket},
- vedi sez.~\ref{sec:packet_socket}.
+\item[\const{SIOCADDMULTI}] aggiunge un indirizzo di \textit{multicast} ai
+ filtri del livello di collegamento associati dell'interfaccia. Si deve usare
+ un indirizzo hardware da specificare attraverso il campo \var{ifr\_hwaddr},
+ che conterrà l'opportuna struttura \struct{sockaddr}; l'operazione è
+ privilegiata. Per una modalità alternativa per eseguire la stessa operazione
+ si possono usare i \textit{packet socket}, vedi
+ sez.~\ref{sec:packet_socket}.
-\item[\const{SIOCDELMULTI}] rimuove un indirizzo di \itindex{multicast}
- \textit{multicast} ai filtri del livello di collegamento dell'interfaccia,
- vuole un indirizzo hardware specificato come per \const{SIOCADDMULTI}. Anche
- questa operazione è privilegiata e può essere eseguita in forma alternativa
- con i \textit{packet socket}.
+\item[\const{SIOCDELMULTI}] rimuove un indirizzo di \textit{multicast} ai
+ filtri del livello di collegamento dell'interfaccia, vuole un indirizzo
+ hardware specificato come per \const{SIOCADDMULTI}. Anche questa operazione
+ è privilegiata e può essere eseguita in forma alternativa con i
+ \textit{packet socket}.
\item[\const{SIOCGIFTXQLEN}] permette di leggere la lunghezza della coda di
trasmissione del dispositivo associato all'interfaccia specificata nel campo
relativa pagina di manuale, accessibile con \texttt{man 7 tcp}, e prevedono
come possibile valore per il secondo argomento della funzione le costanti
illustrate nell'elenco seguente; il terzo argomento della funzione, gestito
-come \itindex{value~result~argument} \textit{value result argument}, deve
-essere sempre il puntatore ad una variabile di tipo \ctyp{int}:
+come \textit{value result argument}, deve essere sempre il puntatore ad una
+variabile di tipo \ctyp{int}:
\begin{basedescript}{\desclabelwidth{2.5cm}\desclabelstyle{\nextlinelabel}}
\item[\const{SIOCINQ}] restituisce la quantità di dati non ancora letti
presenti nel buffer di ricezione; il socket non deve essere in stato
Le operazioni di controllo disponibili per i socket UDP, anch'esse illustrate
dalla relativa pagina di manuale accessibile con \texttt{man 7 udp}, sono
quelle indicate dalle costanti del seguente elenco; come per i socket TCP il
-terzo argomento viene gestito come \itindex{value~result~argument}
-\textit{value result argument} e deve essere un puntatore ad una variabile di
-tipo \ctyp{int}:
+terzo argomento viene gestito come \textit{value result argument} e deve
+essere un puntatore ad una variabile di tipo \ctyp{int}:
\begin{basedescript}{\desclabelwidth{2.5cm}\desclabelstyle{\nextlinelabel}}
\item[\const{FIONREAD}] restituisce la dimensione in byte del primo pacchetto
in attesa di ricezione, o 0 qualora non ci sia nessun pacchetto.
projects / gapil.git / blobdiff