\texttt{CLOSED} a quello \texttt{LISTEN}. In genere si chiama la funzione in
un server dopo le chiamate a \func{socket} e \func{bind} e prima della
chiamata ad \func{accept}. Il prototipo della funzione come definito dalla
-man page è:
+pagina di manuale è:
\begin{prototype}{sys/socket.h}{int listen(int sockfd, int backlog)}
La funzione pone il socket specificato da \var{sockfd} in modalità
passiva e predispone una coda per le connessioni in arrivo di lunghezza pari
1 e 2 corrispondano al socket connesso) quest'ultimo potrà usare la funzione
\func{getpeername} per determinare l'indirizzo remoto del client.
-Infine è da chiarire (si legga la man page) che come per \func{accept} il
-terzo parametro che è specificato dallo standard POSIX 1003.1g come di tipo
-\code{socklen\_t *} in realtà deve sempre corrispondere ad un \ctyp{int *}
-come prima dello standard perché tutte le implementazioni dei socket BSD fanno
-questa assunzione.
+Infine è da chiarire (si legga la pagina di manuale) che, come per
+\func{accept}, il terzo parametro, che è specificato dallo standard POSIX.1g
+come di tipo \code{socklen\_t *} in realtà deve sempre corrispondere ad un
+\ctyp{int *} come prima dello standard perché tutte le implementazioni dei
+socket BSD fanno questa assunzione.
\item \macro{EMFILE} \textit{Too many open files}. Il processo corrente ha
troppi file aperti e non può aprirne altri. Anche i descrittori duplicati
vengono tenuti in conto\footnote{Il numero massimo di file aperti è
- controllabile dal sistema, in Linux si può usare il comando \cmd{ulimit}}.
+ controllabile dal sistema, in Linux si può usare il comando
+ \cmd{ulimit}.}.
\item \macro{ENFILE} \textit{File table overflow}. Ci sono troppi file aperti
nel sistema.
\item \macro{ENOTTY} \textit{Not a terminal}. Si è tentata una operazione di
Per aggiungere un nome ad un inode si utilizza la funzione \func{link}; si
suole chiamare questo tipo di associazione un collegamento diretto (o
\textit{hard link}). Il prototipo della funzione e le sue caratteristiche
-principali, come risultano dalla man page, sono le seguenti:
+principali, come risultano dalla pagina di manuale, sono le seguenti:
\begin{prototype}{unistd.h}
{int link(const char *oldpath, const char *newpath)}
Crea un nuovo collegamento diretto al file indicato da \var{oldpath}
La struttura \var{stat} usata da queste funzioni è definita nell'header
\file{sys/stat.h} e in generale dipende dall'implementazione, la versione
-usata da Linux è mostrata in \nfig, così come riportata dalla man page di
-\func{stat} (in realtà la definizione effettivamente usata nel kernel dipende
-dall'architettura e ha altri campi riservati per estensioni come tempi più
-precisi, o per il padding dei campi).
+usata da Linux è mostrata in \nfig, così come riportata dalla pagina di
+manuale di \func{stat} (in realtà la definizione effettivamente usata nel
+kernel dipende dall'architettura e ha altri campi riservati per estensioni
+come tempi più precisi, o per il padding dei campi).
\begin{figure}[!htb]
\footnotesize
\end{itemize*}
-Dettagli ulteriori sulle varie opzioni possono essere trovati nella man page
-di \func{printf} e nella documentazione delle \acr{glibc}.
+Dettagli ulteriori sulle varie opzioni possono essere trovati nella pagina di
+manuale di \func{printf} e nella documentazione delle \acr{glibc}.
\begin{table}[htb]
\centering
separazione (che possono essere spazi, tabulatori, virgole etc.), mentre
caratteri diversi richiedono una corrispondenza esatta. Le direttive di
conversione sono analoghe a quelle di \func{printf} e si trovano descritte in
-dettaglio nelle man page e nel manuale delle \acr{glibc}.
+dettaglio nelle pagine di manuale e nel manuale delle \acr{glibc}.
Le funzioni eseguono la lettura dall'input, scartano i separatori (e gli
eventuali caratteri diversi indicati dalla stringa di formato) effettuando le
\label{tab:file_open_flags}
\end{table}
-\footnotetext[2]{la man page di \func{open} segnala che questa opzione è
- difettosa su NFS, e che i programmi che la usano per stabilire un file di
- lock possono incorrere in una race condition\index{race condition}. Si
- consiglia come alternativa di usare un file con un nome univoco e la
+\footnotetext[2]{la pagina di manuale di \func{open} segnala che questa
+ opzione è difettosa su NFS, e che i programmi che la usano per stabilire un
+ file di lock possono incorrere in una race condition\index{race condition}.
+ Si consiglia come alternativa di usare un file con un nome univoco e la
funzione \func{link} per verificarne l'esistenza.}
\footnotetext[3]{\textit{Denial of Service}, si chiamano così attacchi miranti
di \tabref{tab:file_open_flags}).
\item[\macro{F\_SETFL}] imposta il \textit{file status flag} al valore
specificato da \param{arg}, possono essere impostati solo i bit riportati
- nella terza sezione di \tabref{tab:file_open_flags}.\footnote{la man page
- riporta come impostabili solo \macro{O\_APPEND}, \macro{O\_NONBLOCK} e
- \macro{O\_ASYNC}.}
+ nella terza sezione di \tabref{tab:file_open_flags}.\footnote{la pagina di
+ manuale riporta come impostabili solo \macro{O\_APPEND},
+ \macro{O\_NONBLOCK} e \macro{O\_ASYNC}.}
\item[\macro{F\_GETLK}] se un file lock è attivo restituisce nella struttura
\param{lock} la struttura \type{flock} che impedisce l'acquisizione del
blocco, altrimenti imposta il campo \var{l\_type} a \macro{F\_UNLCK} (per i
\usepackage{listings}
\lstloadlanguages{C++}
\usepackage{color}
-%\usepackage{mdwlist} % scommentare per la stampa (PS e PDF)
-%\usepackage{boxedminipage} % scommentare per la stampa (PS e PDF)
+\usepackage{mdwlist} % scommentare per la stampa (PS e PDF)
+\usepackage{boxedminipage} % scommentare per la stampa (PS e PDF)
%\usepackage{footnote}
%\usepackage{mdwtab}
%
\tableofcontents
\clearemptydoublepage
-\include{compatib} % commentare per la stampa PS e PDF
+%\include{compatib} % commentare per la stampa PS e PDF
\include{macro}
\setcounter{secnumdepth}{-2}
\include{pref}
Per capire le caratteristiche di IPv6 partiamo dall'intestazione usata dal
protocollo per gestire la trasmissione dei pacchetti; in
-\tabref{tab:IP_ipv6head} è riportato il formato dell'intestazione di IPv6 da
-confrontare con quella di IPv4 in \tabref{tab:IP_ipv4head}. La spiegazione del
+\figref{fig:IP_ipv6head} è riportato il formato dell'intestazione di IPv6 da
+confrontare con quella di IPv4 in \figref{fig:IP_ipv4head}. La spiegazione del
significato dei vari campi delle due intestazioni è riportato rispettivamente
in \tabref{tab:IP_ipv6field} e \tabref{tab:IP_ipv4field})
-\begin{table}[htb]
- \footnotesize
- \begin{center}
- \begin{tabular}{@{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule}p{16mm}
- @{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule}p{16mm}
- @{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule} }
- \multicolumn{8}{@{}c@{}}{0\hfill 15 16\hfill 31}\\
- \hline
- \centering version&\centering priority&
- \multicolumn{6}{@{}p{96mm}@{\vrule}}{\centering flow label} \\
- \hline
- \multicolumn{4}{@{\vrule}p{64mm}@{\vrule}}{\centering payload length} &
- \multicolumn{2}{@{}p{32mm}@{\vrule}}{\centering next header} &
- \multicolumn{2}{@{}p{32mm}@{\vrule}}{\centering hop limit}\\
- \hline
- \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
- \multicolumn{8}{@{\vrule}c@{\vrule}}{
- source} \\
- \multicolumn{8}{@{\vrule}c@{\vrule}}{
- IP address} \\
- \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
- \hline
- \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
- \multicolumn{8}{@{\vrule}c@{\vrule}}{
- destination} \\
- \multicolumn{8}{@{\vrule}c@{\vrule}}{
- IP address} \\
- \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
- \hline
- \end{tabular}
- \caption{L'intestazione o \textit{header} di IPv6}
- \label{tab:IP_ipv6head}
- \end{center}
-\end{table}
+% \begin{table}[htb]
+% \footnotesize
+% \begin{center}
+% \begin{tabular}{@{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule}p{16mm}
+% @{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule}p{16mm}
+% @{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule} }
+% \multicolumn{8}{@{}c@{}}{0\hfill 15 16\hfill 31}\\
+% \hline
+% \centering version&\centering priority&
+% \multicolumn{6}{@{}p{96mm}@{\vrule}}{\centering flow label} \\
+% \hline
+% \multicolumn{4}{@{\vrule}p{64mm}@{\vrule}}{\centering payload length} &
+% \multicolumn{2}{@{}p{32mm}@{\vrule}}{\centering next header} &
+% \multicolumn{2}{@{}p{32mm}@{\vrule}}{\centering hop limit}\\
+% \hline
+% \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
+% \multicolumn{8}{@{\vrule}c@{\vrule}}{
+% source} \\
+% \multicolumn{8}{@{\vrule}c@{\vrule}}{
+% IP address} \\
+% \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
+% \hline
+% \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
+% \multicolumn{8}{@{\vrule}c@{\vrule}}{
+% destination} \\
+% \multicolumn{8}{@{\vrule}c@{\vrule}}{
+% IP address} \\
+% \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
+% \hline
+% \end{tabular}
+% \caption{L'intestazione o \textit{header} di IPv6}
+% \label{tab:IP_ipv6head}
+% \end{center}
+% \end{table}
+
+\begin{figure}[htb]
+ \centering
+ \includegraphics[width=10cm]{img/ipv6_head}
+ \caption{L'intestazione o \textit{header} di IPv6.}
+ \label{fig:IP_ipv6head}
+\end{figure}
+
Come si può notare l'intestazione di IPv6 diventa di dimensione fissa, pari a
40 byte, contro una dimensione (minima, in assenza di opzioni) di 20 byte per
Abbiamo già anticipato in \secref{sec:IP_ipv6over} uno dei criteri principali
nella progettazione di IPv6 è stato quello di ridurre al minimo il tempo di
processamento dei pacchetti da parte dei router, un confronto con
-l'intestazione di IPv4 (vedi \secref{tab:IP_ipv4head}) mostra le seguenti
+l'intestazione di IPv4 (vedi \figref{fig:IP_ipv4head}) mostra le seguenti
differenze:
\begin{itemize}
\item è stato introdotto un nuovo campo \textit{flow label}, che viene usato,
insieme al campo \textit{priority} (che recupera i bit di precedenza del
campo \textit{type of service}) per implementare la gestione di una
- ``qualità di servizio'' (vedi Sez.~\ref{sec:IP_ipv6_qos}) che permette di
+ ``qualità di servizio'' (vedi \secref{sec:IP_ipv6_qos}) che permette di
identificare i pacchetti appartenenti a un ``flusso'' di dati per i quali si
può provvedere un trattamento speciale.
\end{itemize}
-\begin{table}[htb]
- \footnotesize
+
+\begin{figure}[htb]
\centering
- \begin{tabular}{@{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule}p{16mm}
- @{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule}p{16mm}
- @{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule} }
- \multicolumn{8}{@{}c@{}}{0\hfill 15 16\hfill 31}\\
- \hline
- \centering version&
- \centering head length&
- \multicolumn{2}{@{}p{32mm}@{\vrule}}{\centering type of service} &
- \multicolumn{4}{@{}p{64mm}@{\vrule}}{\centering total length} \\
- \hline
- \multicolumn{4}{@{\vrule}p{64mm}@{\vrule}}{\centering identification} &
- \multicolumn{4}{@{}p{64mm}@{\vrule}}{\parbox{11mm}{\centering flag} \vrule
- \parbox{52mm}{\centering fragment offset}}\\
- \hline
- \multicolumn{2}{@{\vrule}p{32mm}@{\vrule}}{\centering TTL}&
- \multicolumn{2}{@{}p{32mm}@{\vrule}}{\centering protocol}&
- \multicolumn{4}{@{}p{64mm}@{\vrule}}{\centering header checksum} \\
- \hline
- \multicolumn{8}{@{\vrule}c@{\vrule}}{
- source IP address} \\
- \hline
- \multicolumn{8}{@{\vrule}c@{\vrule}}{
- destination IP address} \\
- \hline
- \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
- \multicolumn{8}{@{}p{128mm}@{}}{
- \centering options (if any)} \\
- \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\
- \hline
- \end{tabular}
- \caption{L'intestazione o \textit{header} di IPv4}
-\label{tab:IP_ipv4head}
-\end{table}
+ \includegraphics[width=10cm]{img/ipv4_head}
+ \caption{L'intestazione o \textit{header} di IPv4.}
+ \label{fig:IP_ipv4head}
+\end{figure}
\begin{table}[htb]
\footnotesize
progetto molto ambizioso ...).
-Infatti benché le man pages e il manuale delle librerie del C GNU siano una
-fonte inesauribile di informazioni (da cui si è costantemente attinto nella
-stesura di tutto il testo) la loro struttura li rende totalmente inadatti ad
-una trattazione che vada oltre la descrizione delle caratteristiche
-particolari dello specifico argomento in esame (ed in particolare lo
-\textit{GNU C Library Reference Manual} non brilla per chiarezza espositiva).
+Infatti benché le pagine di manuale del sistema (quelle che si accedono con il
+comando \cmd{man}) e il manuale delle librerie del C GNU siano una fonte
+inesauribile di informazioni (da cui si è costantemente attinto nella stesura
+di tutto il testo) la loro struttura li rende totalmente inadatti ad una
+trattazione che vada oltre la descrizione delle caratteristiche particolari
+dello specifico argomento in esame (ed in particolare lo \textit{GNU C Library
+ Reference Manual} non brilla per chiarezza espositiva).
Per questo motivo si è cercato di fare tesoro di quanto appreso dai testi di
R. Stevens (in particolare \cite{APUE} e \cite{UNP1}) per rendere la
non può essere usata nella lista degli argomenti di una funzione, perché lo
spazio verrebbe allocato nel mezzo degli stessi.
-% Questo è riportato solo dal manuale delle glibc, nelle man page non c'è
+% Questo è riportato solo dal manuale delle glibc, nelle pagine di manuale non c'è
% traccia di tutto ciò
%
%Inoltre se si
che i numeri dei segnali sono allocati progressivamente, essa corrisponde
anche al successivo del valore numerico assegnato all'ultimo segnale definito.
In \tabref{tab:sig_signal_list} si è riportato l'elenco completo dei segnali
-definiti in Linux (estratto dalle man page), comparati con quelli definiti in
-vari standard.
+definiti in Linux (estratto dalle pagine di manuale), comparati con quelli
+definiti in vari standard.
\begin{table}[htb]
\footnotesize
questo sia sotto BSD4.3 che in SUSv2 è stata definita la funzione
\func{usleep} (dove la \texttt{u} è intesa come sostituzione di $\mu$); i due
standard hanno delle definizioni diverse, ma le \acr{glibc}
-seguono\footnote{secondo la man page almeno dalla versione 2.2.2.} seguono
-quella di SUSv2 che prevede il seguente prototipo:
+seguono\footnote{secondo la pagina di manuale almeno dalla versione 2.2.2.}
+seguono quella di SUSv2 che prevede il seguente prototipo:
\begin{prototype}{unistd.h}{int usleep(unsigned long usec)}
Pone il processo in stato di sleep per \param{usec} microsecondi.
controllo (\macro{SIGCHLD}, \macro{SIGTRAP} e \macro{SIGPOLL}) forniscono
altre informazioni speecifiche. In tutti i casi il valore del campo è
riportato attraverso delle costanti (le cui definizioni si trovano
-\file{bits/siginfo.h}) il cui elenco dettagliato è disponibile nella man page
-di \func{sigaction}.
+\file{bits/siginfo.h}) il cui elenco dettagliato è disponibile nella pagina di
+manuale di di \func{sigaction}.
Il resto della struttura è definito come \ctyp{union} ed i valori
eventualmente presenti dipendono dal segnale, così \macro{SIGCHLD} ed i
sempre la parola inglese.} è uno dei principali meccanismi di comunicazione
fra programmi utilizzato in ambito Unix. Il socket costituisce in sostanza un
canale di comunicazione fra due processi su cui si possono leggere e scrivere
-dati analogo a quello di una pipe ma a differenza di questa e degli altri
-meccanismi esaminati nel capitolo \capref{cha:IPC} i socket non sono limitati
-alla comunicazione fra processi che girano sulla stessa macchina ma possono
-effettuare la comunicazione anche attraverso la rete.
+dati analogo a quello di una pipe (vedi \secref{sec:ipc_pipes}) ma a
+differenza di questa e degli altri meccanismi esaminati nel capitolo
+\capref{cha:IPC} i socket non sono limitati alla comunicazione fra processi
+che girano sulla stessa macchina ma possono effettuare la comunicazione anche
+attraverso la rete.
Quella dei socket costituisce infatti la principale API (\textit{Application
Program Interface}) usata nella programmazione di rete. La loro origine
sostanzialmente la stessa con piccole modifiche negli anni successivi. Benché
siano state sviluppate interfacce alternative, originate dai sistemi SVr4,
come la XTI (\textit{X/Open Transport Interface}) nessuna ha mai raggiunto la
-diffusione e la popolarità di quella dei socket (né tantomeno usabilità e
-flessibilità).
+diffusione e la popolarità di quella dei socket (né tantomeno la stessa
+usabilità e flessibilità).
La flessibilità e la genericità dell'interfaccia inoltre ha consentito di
utilizzare i socket con i più disparati meccanismi di comunicazione, e non
Per questo motivo una semplice descrizione dell'interfaccia è assolutamente
inutile, in quanto il comportamento di quest'ultima e le problematiche da
-affrontare cambiano radicalmente a seconda dello ``stile'' di comunicazione
-usato. La scelta di questo stile va infatti ad incidere sulla semantica che
-verrà utilizzata a livello utente per gestire la comunicazione (su come
-inviare e ricevere i dati) e sul comportamento effettivo delle funzioni
-utilizzate.
+affrontare cambiano radicalmente a seconda dello \textsl{stile} di
+comunicazione usato. La scelta di questo stile va infatti ad incidere sulla
+semantica che verrà utilizzata a livello utente per gestire la comunicazione
+(su come inviare e ricevere i dati) e sul comportamento effettivo delle
+funzioni utilizzate.
La scelta di uno stile dipende sia dai meccanismi disponibili, sia dal tipo di
comunicazione che si vuole effettuare. Ad esempio alcuni stili di
A ciascun tipo di dominio corrisponde un analogo nome simbolico che inizia per
\texttt{AF\_} da \textit{address family}, e che identifica il formato degli
-indirizzi usati in quel dominio; le man pages di Linux si riferiscono a questi
-anche come \textit{name space}, (nome che però il manuale della glibc riserva
-ai domini) e che identifica il formato degli indirizzi usati in quel dominio.
+indirizzi usati in quel dominio; le pagine di manuale di Linux si riferiscono
+a questi anche come \textit{name space}, (nome che però il manuale delle
+\acr{glibc} riserva ai domini) e che identifica il formato degli indirizzi
+usati in quel dominio.
L'idea alla base della distinzione era che una famiglia di protocolli potesse
supportare vari tipi di indirizzi, per cui il prefisso \texttt{PF\_} si
I domini (e i relativi nomi simbolici), così come i nomi delle famiglie di
indirizzi sono definiti dall'header \textit{socket.h}. In Linux le famiglie di
-protocolli disponibili sono riportate in \ntab.
+protocolli disponibili sono riportate in \tabref{tab:net_pf_names}.
\begin{table}[htb]
\footnotesize
\macro{PF\_UNIX},
\macro{PF\_LOCAL} & Local communication & unix(7) \\
\macro{PF\_INET} & IPv4 Internet protocols & ip(7) \\
- \macro{PF\_INET6} & IPv6 Internet protocols & \\
+ \macro{PF\_INET6} & IPv6 Internet protocols & ipv6(7) \\
\macro{PF\_IPX} & IPX - Novell protocols & \\
\macro{PF\_NETLINK}& Kernel user interface device & netlink(7) \\
\macro{PF\_X25} & ITU-T X.25 / ISO-8208 protocol & x25(7) \\
Non tutte le famiglie di protocolli sono accessibili dall'utente generico, ad
esempio in generale tutti i socket di tipo \macro{SOCK\_RAW} possono essere
-creati solo da processi che hanno i privilegi di root (cioè effective uid
-uguale a zero) o la capability \macro{CAP\_NET\_RAW}.
+creati solo da processi che hanno i privilegi di root (cioè con
+\textit{effective user id} uguale a zero) o con la capability
+\macro{CAP\_NET\_RAW}.
\subsection{Il tipo, o stile}
comunicazione, questo infatti viene a dipendere dal protocollo che si andrà ad
utilizzare fra quelli disponibili nella famiglia scelta. Le API permettono di
scegliere lo stile di comunicazione indicando il tipo di socket; Linux e le
-glibc mettono a disposizione i seguenti tipi di socket (che il manuale della
-glibc chiama \textit{styles}) definiti come \ctyp{int} in \file{socket.h}:
+\acr{glibc} mettono a disposizione i seguenti tipi di socket (che il manuale
+della \acr{glibc} chiama \textit{styles}) definiti come \ctyp{int} in
+\file{socket.h}:
\begin{list}{}{}
\item \macro{SOCK\_STREAM} Provvede un canale di trasmissione dati
\item \macro{SOCK\_PACKET} Obsoleto, non deve essere usato.
\end{list}
-Si tenga presente che non tutte le combinazioni di famiglia di protocolli e
-tipo di socket sono valide, in quanto non è detto che nella famiglia esista un
-protocollo per tutti gli stili di comunicazione indicati qui sopra. Una
-tabella che mostra le combinazioni valide è la seguente:
+Si tenga presente che non tutte le combinazioni fra una famiglia di protocolli
+e un tipo di socket sono valide, in quanto non è detto che in una famiglia
+esista un protocollo per ciascuno dei diversi stili di comunicazione appena
+elencati.
\begin{table}[htb]
\footnotesize
\label{tab:sock_sock_valid_combinations}
\end{table}
-Dove per ogni combinazione valida si è indicato il tipo di protocollo, o la
-parola \textsl{si} qualora non il protocollo non abbia un nome definito,
-mentre si sono lasciate vuote le caselle per le combinazioni non supportate.
+In \secref{tab:sock_sock_valid_combinations} sono mostrate le combinazioni
+valide possibili per le varie famiglie di protocolli. Per ogni combinazione
+valida si è indicato il tipo di protocollo, o la parola \textsl{si} qualora
+non il protocollo non abbia un nome definito, mentre si sono lasciate vuote le
+caselle per le combinazioni non supportate.
maneggiare puntatori a strutture relative a tutti gli indirizzi possibili
nelle varie famiglie di protocolli; questo pone il problema di come passare
questi puntatori, il C ANSI risolve questo problema coi i puntatori generici
-(i \ctyp{void *}), ma l'interfaccia dei socket è antecedente alla
-definizione dello standard ANSI, e per questo nel 1982 fu scelto di definire
-una struttura generica \type{sockaddr} per gli indirizzi dei socket mostrata
-in \nfig:
+(i \ctyp{void *}), ma l'interfaccia dei socket è antecedente alla definizione
+dello standard ANSI, e per questo nel 1982 fu scelto di definire una struttura
+generica per gli indirizzi dei socket, \type{sockaddr}, che si è riportata in
+\figref{fig:sock_sa_gen_struct}.
\begin{figure}[!htb]
\footnotesize
occorrerà eseguire un casting del relativo puntatore.
I tipi di dati che compongono la struttura sono stabiliti dallo standard
-POSIX.1g, riassunti in \ntab\ con i rispettivi file di include in cui sono
-definiti; la struttura è invece definita nell'include file
-\file{sys/socket.h}
+POSIX.1g, riassunti in \tabref{tab:sock_data_types} con i rispettivi file di
+include in cui sono definiti; la struttura è invece definita nell'include file
+\file{sys/socket.h}.
\begin{table}[!htb]
\centering
\hline
\end{tabular}
\caption{Tipi di dati usati nelle strutture degli indirizzi, secondo quanto
- stabilito dallo standard POSIX.1g}
+ stabilito dallo standard POSIX.1g.}
\label{tab:sock_data_types}
\end{table}
I socket di tipo \macro{PF\_INET} vengono usati per la comunicazione
attraverso internet; la struttura per gli indirizzi per un socket internet
(IPv4) è definita come \type{sockaddr\_in} nell'header file
-\file{netinet/in.h} e secondo le man page ha la forma mostrata in \nfig,
-conforme allo standard POSIX.1g.
+\file{netinet/in.h} e secondo le pagine di manuale ha la forma mostrata in
+\figref{fig:sock_sa_ipv4_struct}, conforme allo standard POSIX.1g.
\begin{figure}[!htb]
\footnotesize
definizioni precise e dettagli di funzionamento che saranno trattati
estensivamente più avanti.
-In \nfig\ è riportata la sezione principale del codice del nostro client
-elementare per il servizio \textit{daytime}, un servizio standard che
-restituisce l'ora locale della macchina a cui si effettua la richiesta.
+In \figref{fig:net_cli_code} è riportata la sezione principale del codice del
+nostro client elementare per il servizio \textit{daytime}, un servizio
+standard che restituisce l'ora locale della macchina a cui si effettua la
+richiesta.
\begin{figure}[!htb]
\footnotesize
Dopo aver illustrato il client daremo anche un esempio di un server
elementare, in grado di rispondere al precedente client. Il listato è
-nuovamente mostrato in \nfig, il sorgente completo
+nuovamente mostrato in \figref{fig:net_serv_code}, il sorgente completo
(\file{ElemDaytimeTCPServer.c}) è allegato insieme agli altri file nella
directory \file{sources}.
alle applicazioni di sistema presenti (come quelli su alcuni parametri delle
espressioni regolari o del comando \cmd{bc}), non li tratteremo
esplicitamente, se ne trova una menzione completa nell'header file
-\file{bits/posix2\_lim.h}, e alcuni di loro sono descritti nella man page di
-\func{sysconf} e nel manuale delle \acr{glibc}.
+\file{bits/posix2\_lim.h}, e alcuni di loro sono descritti nella pagina di
+manuale di \func{sysconf} e nel manuale delle \acr{glibc}.
\subsection{La funzione \func{sysconf}}
completa. Per questo motivo l'uso di queste funzioni è deprecato in favore
dell'uso di PAM, ci limiteremo pertanto ad elencarle in
\tabref{tab:sys_passwd_func}, rimandando chi fosse interessato alle rispettive
-man page e al manuale delle \acr{glibc} per i dettagli del loro funzionamento.
+pagine di manuale e al manuale delle \acr{glibc} per i dettagli del loro
+funzionamento.
\func{strerror}; per questo motivo non è rientrante e nel caso si usino i
thread è provvista\footnote{questa funzione è la versione prevista dalle
\acr{glibc}, ed effettivamente definita in \file{string.h}, ne esiste una
- analoga nello standard SUSv3 (quella riportata dalla man page), che
+ analoga nello standard SUSv3 (quella riportata dalla pagina di manuale), che
restituisce \code{int} al posto di \code{char *}, e che tronca la stringa
restituita a \param{size}.} una versione apposita:
\begin{prototype}{string.h}
projects / gapil.git / commitdiff