Rimessi a posto tutti i riferimenti a figure e tabelle cancellando

delle vecchie macro che non funzionavano bene.

diff --git a/elemtcp.tex b/elemtcp.tex
index 964dd4f16f5cc1c0539b9338093392ae75c5905a..67157706e24aefc1b3dbaa54fcf4f44caf5918fe 100644 (file)
--- a/elemtcp.tex
+++ b/elemtcp.tex
@@ -70,9 +70,9 @@ creazione di una connessione 
 \end{enumerate} 
 
 Il procedimento viene chiamato \textit{three way handshake} dato che per
 \end{enumerate} 
 
 Il procedimento viene chiamato \textit{three way handshake} dato che per

-realizzarlo devono essere scambiati tre segmenti.  In \nfig\ si è
-rappresentata graficamente la sequenza di scambio dei segmenti che stabilisce
-la connessione.
+realizzarlo devono essere scambiati tre segmenti.  In \figref{fig:TCPel_TWH}
+si è rappresentata graficamente la sequenza di scambio dei segmenti che
+stabilisce la connessione.

 
 % Una analogia citata da R. Stevens per la connessione TCP è quella con il
 % sistema del telefono. La funzione \texttt{socket} può essere considerata
 
 % Una analogia citata da R. Stevens per la connessione TCP è quella con il
 % sistema del telefono. La funzione \texttt{socket} può essere considerata


@@ -91,11 +91,11 @@ la connessione.
 \end{figure}
 
 Si è accennato in precedenza ai \textsl{numeri di sequenza} (che sono anche
 \end{figure}
 
 Si è accennato in precedenza ai \textsl{numeri di sequenza} (che sono anche

-riportati in \curfig); per gestire una connessione affidabile infatti il
-protocollo TCP prevede nell'header la presenza di un numero a 32 bit (chiamato
-appunto \textit{sequence number}) che identifica a quale byte nella sequenza
-del flusso corrisponde il primo byte della sezione dati contenuta nel
-segmento.
+riportati in \figref{fig:TCPel_TWH}); per gestire una connessione affidabile
+infatti il protocollo TCP prevede nell'header la presenza di un numero a 32
+bit (chiamato appunto \textit{sequence number}) che identifica a quale byte
+nella sequenza del flusso corrisponde il primo byte della sezione dati
+contenuta nel segmento.

 
 Il numero di sequenza di ciascun segmento viene calcolato a partire da un
 \textsl{numero di sequenza iniziale} generato in maniera casuale del kernel
 
 Il numero di sequenza di ciascun segmento viene calcolato a partire da un
 \textsl{numero di sequenza iniziale} generato in maniera casuale del kernel


@@ -106,7 +106,7 @@ il flag ACK e restituendo nell'apposito campo dell'header un
 aspetta di ricevere con il pacchetto successivo; dato che il primo pacchetto
 SYN consuma un byte, nel \textit{three way handshake} il numero di acknowledge
 è sempre pari al numero di sequenza iniziale incrementato di uno; lo stesso
 aspetta di ricevere con il pacchetto successivo; dato che il primo pacchetto
 SYN consuma un byte, nel \textit{three way handshake} il numero di acknowledge
 è sempre pari al numero di sequenza iniziale incrementato di uno; lo stesso

-varrà anche (vedi \nfig) per l'acknowledgement di un FIN.
+varrà anche (vedi \figref{fig:TCPel_close}) per l'acknowledgement di un FIN.

 
 \subsection{Le opzioni TCP.}
 \label{sec:TCPel_TCP_opt}
 
 \subsection{Le opzioni TCP.}
 \label{sec:TCPel_TCP_opt}


@@ -192,8 +192,8 @@ normalmente i segmenti scambiati sono quattro.  Questo non 
 giacché in alcune situazioni il FIN del passo 1) è inviato insieme a dei dati.
 Inoltre è possibile che i segmenti inviati nei passi 2 e 3 dal capo che
 effettua la chiusura passiva, siano accorpati in un singolo segmento. In
 giacché in alcune situazioni il FIN del passo 1) è inviato insieme a dei dati.
 Inoltre è possibile che i segmenti inviati nei passi 2 e 3 dal capo che
 effettua la chiusura passiva, siano accorpati in un singolo segmento. In

-\nfig\ si è rappresentato graficamente lo sequenza di scambio dei segmenti che
-stabilisce la connessione.
+\figref{fig:TCPel_close} si è rappresentato graficamente lo sequenza di
+scambio dei segmenti che stabilisce la connessione.

 
 \begin{figure}[htb]
   \centering  
 
 \begin{figure}[htb]
   \centering  


@@ -234,10 +234,11 @@ quali 
 
 Le operazioni del TCP nella creazione e conclusione di una connessione sono
 specificate attraverso il diagramma di transizione degli stati riportato in
 
 Le operazioni del TCP nella creazione e conclusione di una connessione sono
 specificate attraverso il diagramma di transizione degli stati riportato in

-\nfig. TCP prevede l'esistenza di 11 diversi stati per un socket ed un insieme
-di regole per le transizioni da uno stato all'altro basate sullo stato
-corrente e sul tipo di segmento ricevuto; i nomi degli stati sono gli stessi
-che vengono riportati del comando \cmd{netstat} nel campo \textit{State}.
+\figref{fig:TPCel_conn_example}. TCP prevede l'esistenza di 11 diversi stati
+per un socket ed un insieme di regole per le transizioni da uno stato
+all'altro basate sullo stato corrente e sul tipo di segmento ricevuto; i nomi
+degli stati sono gli stessi che vengono riportati del comando \cmd{netstat}
+nel campo \textit{State}.

 
 Una descrizione completa del funzionamento del protocollo va al di là degli
 obiettivi di questo libro; un approfondimento sugli aspetti principali si
 
 Una descrizione completa del funzionamento del protocollo va al di là degli
 obiettivi di questo libro; un approfondimento sugli aspetti principali si


@@ -263,9 +264,9 @@ attiva) la transizione 
 l'applicazione riceve un FIN nello stato \texttt{ESTABLISHED} (chiusura
 passiva) la transizione è verso lo stato \texttt{CLOSE\_WAIT}.
 
 l'applicazione riceve un FIN nello stato \texttt{ESTABLISHED} (chiusura
 passiva) la transizione è verso lo stato \texttt{CLOSE\_WAIT}.
 

-In \nfig\ è riportato lo schema dello scambio dei pacchetti che avviene per
-una un esempio di connessione, insieme ai vari stati che il protocollo viene
-ad assumere per i due lati, server e client.
+In \figref{fig:TPCel_conn_example} è riportato lo schema dello scambio dei
+pacchetti che avviene per una un esempio di connessione, insieme ai vari stati
+che il protocollo viene ad assumere per i due lati, server e client.

 
 \begin{figure}[htb]
   \centering
 
 \begin{figure}[htb]
   \centering


@@ -312,18 +313,18 @@ dati rispondono meglio alle esigenze che devono essere affrontate.
 \subsection{Lo stato \texttt{TIME\_WAIT}}
 \label{sec:TCPel_time_wait}
 
 \subsection{Lo stato \texttt{TIME\_WAIT}}
 \label{sec:TCPel_time_wait}
 

-Come riportato da Stevens (FIXME citare) lo stato \texttt{TIME\_WAIT} è
+Come riportato da Stevens in \cite{UNP1} lo stato \texttt{TIME\_WAIT} è

 probabilmente uno degli aspetti meno compresi del protocollo TCP, è infatti
 comune trovare nei newsgroup domande su come sia possibile evitare che
 un'applicazione resti in questo stato lasciando attiva una connessione ormai
 conclusa; la risposta è che non deve essere fatto, ed il motivo cercheremo di
 spiegarlo adesso.
 
 probabilmente uno degli aspetti meno compresi del protocollo TCP, è infatti
 comune trovare nei newsgroup domande su come sia possibile evitare che
 un'applicazione resti in questo stato lasciando attiva una connessione ormai
 conclusa; la risposta è che non deve essere fatto, ed il motivo cercheremo di
 spiegarlo adesso.
 

-Come si è visto nell'esempio precedente (vedi \curfig) \texttt{TIME\_WAIT} è
-lo stato finale in cui il capo di una connessione che esegue la chiusura
-attiva resta prima di passare alla chiusura definitiva della connessione. Il
-tempo in cui l'applicazione resta in questo stato deve essere due volte la MSL
-(\textit{Maximum Segment Lifetime}). 
+Come si è visto nell'esempio precedente (vedi \figref{fig:TPCel_conn_example})
+\texttt{TIME\_WAIT} è lo stato finale in cui il capo di una connessione che
+esegue la chiusura attiva resta prima di passare alla chiusura definitiva
+della connessione. Il tempo in cui l'applicazione resta in questo stato deve
+essere due volte la MSL (\textit{Maximum Segment Lifetime}).

 
 La MSL è la stima del massimo periodo di tempo che un pacchetto IP può vivere
 sulla rete; questo tempo è limitato perché ogni pacchetto IP può essere
 
 La MSL è la stima del massimo periodo di tempo che un pacchetto IP può vivere
 sulla rete; questo tempo è limitato perché ogni pacchetto IP può essere


@@ -354,13 +355,14 @@ riferimento solo alla prima; ma 
 capisce il perché della scelta di un tempo pari al doppio della MSL come
 durata di questo stato.
 
 capisce il perché della scelta di un tempo pari al doppio della MSL come
 durata di questo stato.
 

-Il primo dei due motivi precedenti si può capire tornando a \curfig: assumendo
-che l'ultimo ACK della sequenza (quello del capo che ha eseguito la chiusura
-attiva) vanga perso, chi esegue la chiusura passiva non ricevendo risposta
-rimanderà un ulteriore FIN, per questo motivo chi esegue la chiusura attiva
-deve mantenere lo stato della connessione per essere in grado di reinviare
-l'ACK e chiuderla correttamente. Se non fosse così la risposta sarebbe un RST
-(un altro tipo si segmento) che verrebbe interpretato come un errore.
+Il primo dei due motivi precedenti si può capire tornando a
+\figref{fig:TPCel_conn_example}: assumendo che l'ultimo ACK della sequenza
+(quello del capo che ha eseguito la chiusura attiva) vanga perso, chi esegue
+la chiusura passiva non ricevendo risposta rimanderà un ulteriore FIN, per
+questo motivo chi esegue la chiusura attiva deve mantenere lo stato della
+connessione per essere in grado di reinviare l'ACK e chiuderla correttamente.
+Se non fosse così la risposta sarebbe un RST (un altro tipo si segmento) che
+verrebbe interpretato come un errore.

 
 Se il TCP deve poter chiudere in maniera pulita entrambe le direzioni della
 connessione allora deve essere in grado di affrontare la perdita di uno
 
 Se il TCP deve poter chiudere in maniera pulita entrambe le direzioni della
 connessione allora deve essere in grado di affrontare la perdita di uno


@@ -469,10 +471,11 @@ in tre intervalli:
 \end{enumerate}
 
 In realtà rispetto a quanto indicato nell'RFC~1700 i vari sistemi hanno fatto
 \end{enumerate}
 
 In realtà rispetto a quanto indicato nell'RFC~1700 i vari sistemi hanno fatto

-scelte diverse per le porte effimere, in particolare in \nfig\ sono riportate
-quelle di BSD, Solaris e Linux. Nel caso di Linux poi la scelta fra i due
-intervalli possibili viene fatta dinamicamente a seconda della memoria a
-disposizione del kernel per gestire le relative tabelle.
+scelte diverse per le porte effimere, in particolare in
+\figref{fig:TCPel_port_alloc} sono riportate quelle di BSD, Solaris e Linux.
+Nel caso di Linux poi la scelta fra i due intervalli possibili viene fatta
+dinamicamente a seconda della memoria a disposizione del kernel per gestire le
+relative tabelle.

 
 \begin{figure}[!htb]
   \centering
 
 \begin{figure}[!htb]
   \centering


@@ -606,12 +609,12 @@ l'uso dei socket TCP gi
 della funzione \func{socket} che è già stata esaminata in dettaglio in
 \secref{sec:sock_socket}.
 
 della funzione \func{socket} che è già stata esaminata in dettaglio in
 \secref{sec:sock_socket}.
 

-In \nfig\ abbiamo un tipico schema di funzionamento di un'applicazione
-client-server che usa i socket TCP: prima il server viene avviato ed in
-seguito il client si connette, in questo caso, a differenza di quanto accadeva
-con gli esempi elementari del \capref{cha:network} si assume che sia il
-client ad effettuare delle richieste a cui il server risponde, il client
-notifica poi di avere concluso inviando un end-of-file a cui il server
+In \figref{fig:TCPel_cliserv_func} abbiamo un tipico schema di funzionamento
+di un'applicazione client-server che usa i socket TCP: prima il server viene
+avviato ed in seguito il client si connette, in questo caso, a differenza di
+quanto accadeva con gli esempi elementari del \capref{cha:network} si assume
+che sia il client ad effettuare delle richieste a cui il server risponde, il
+client notifica poi di avere concluso inviando un end-of-file a cui il server

 risponderà anche lui chiudendo la connessione per aspettarne una nuova.
 
 \begin{figure}[!htb]
 risponderà anche lui chiudendo la connessione per aspettarne una nuova.
 
 \begin{figure}[!htb]


@@ -862,16 +865,16 @@ infatti vengono mantenute due code:
   Questi socket sono tutti nello stato \texttt{ESTABLISHED}.
 \end{enumerate}
 
   Questi socket sono tutti nello stato \texttt{ESTABLISHED}.
 \end{enumerate}
 

-Lo schema di funzionamento è descritto in \nfig, quando arriva un SYN da un
-client il server crea una nuova entrata nella coda delle connessioni
-incomplete, e poi risponde con il SYN$+$ACK. La entrata resterà nella coda
-delle connessioni incomplete fino al ricevimento dell'ACK dal client o fino ad
-un timeout. Nel caso di completamento del three way handshake l'entrata viene
-sostata nella coda delle connessioni complete. Quando il processo chiama la
-funzione \func{accept} (vedi \secref{sec:TCPel_func_accept}) la prima
-entrata nella coda delle connessioni complete è passata al programma, o, se la
-coda è vuota, il processo viene posto in attesa e risvegliato all'arrivo della
-prima connessione completa.
+Lo schema di funzionamento è descritto in \figref{fig:TCPel_xxx}, quando
+arriva un SYN da un client il server crea una nuova entrata nella coda delle
+connessioni incomplete, e poi risponde con il SYN$+$ACK. La entrata resterà
+nella coda delle connessioni incomplete fino al ricevimento dell'ACK dal
+client o fino ad un timeout. Nel caso di completamento del three way handshake
+l'entrata viene sostata nella coda delle connessioni complete. Quando il
+processo chiama la funzione \func{accept} (vedi
+\secref{sec:TCPel_func_accept}) la prima entrata nella coda delle connessioni
+complete è passata al programma, o, se la coda è vuota, il processo viene
+posto in attesa e risvegliato all'arrivo della prima connessione completa.

 
 Storicamente il valore del parametro \var{backlog} era corrispondente al
 massimo valore della somma del numero di entrate possibili per ciascuna di
 
 Storicamente il valore del parametro \var{backlog} era corrispondente al
 massimo valore della somma del numero di entrate possibili per ciascuna di


@@ -1073,9 +1076,9 @@ concorrente abbiamo riscritto il server \texttt{daytime} dell'esempio
 precedente in forma concorrente, inserendo anche una opzione per la stampa
 degli indirizzi delle connessioni ricevute.
 
 precedente in forma concorrente, inserendo anche una opzione per la stampa
 degli indirizzi delle connessioni ricevute.
 

-In \nfig\ è mostrato un estratto del codice, in cui si sono tralasciati il
-trattamento delle opzioni e le parti rimaste invariate rispetto al precedente
-esempio. Al solito il sorgente completo del server
+In \figref{fig:TCPel_serv_code} è mostrato un estratto del codice, in cui si
+sono tralasciati il trattamento delle opzioni e le parti rimaste invariate
+rispetto al precedente esempio. Al solito il sorgente completo del server

 \file{ElemDaytimeTCPCuncServ.c} è allegato nella directory dei sorgenti.
 
 \begin{figure}[!htb]
 \file{ElemDaytimeTCPCuncServ.c} è allegato nella directory dei sorgenti.
 
 \begin{figure}[!htb]

diff --git a/fileadv.tex b/fileadv.tex
index 0d6e2f08d1f3160ce34f94cd4b847d0ebc9526dd..454396284aeb4eda50e21e3bc3db924ad9e84ccc 100644 (file)
--- a/fileadv.tex
+++ b/fileadv.tex
@@ -1315,10 +1315,21 @@ Il comportamento della funzione 
   \label{tab:file_flock_operation}
 \end{table}
 
   \label{tab:file_flock_operation}
 \end{table}
 

+
+Con \func{flock} il blocco è associato direttamente al file (cioè rispetto
+allo schema di \secref{sec:file_fd} fa riferimento all'inode e non al file
+descriptor); pertanto sia \func{dup} che \func{fork} non creano altre istanze
+del blocco ma piuttosto degli ulteriori riferimenti allo stesso \textit{file
+  lock}. 
+

 La funzione blocca direttamente il file (cioè rispetto allo schema di
 La funzione blocca direttamente il file (cioè rispetto allo schema di

-\secref{fig:file_stat_struct} fa riferimento all'inode, non al file
-descriptor). Pertanto sia \func{dup} che \func{fork} non creano altre istanze
-di un \textit{file lock}.
+\secref{fig:file_stat_struct} fa riferimento alla struttura \var{file}, non al
+file descriptor). Pertanto sia \func{dup} che \func{fork} non creano ulteriori
+istanze di un \textit{file lock} quanto piuttosto degli ulteriori riferimenti
+allo stesso \textit{file lock}. Questo comporta che un lock può essere rimosso
+su uno qualunque dei file descriptor che fanno riferimento allo stesso file,
+ed esso .
+

 
 La seconda interfaccia per l'\textit{advisory locking} disponibile in Linux è
 quella standardizzata da POSIX, basata sulla funzione \func{fcntl}. Abbiamo
 
 La seconda interfaccia per l'\textit{advisory locking} disponibile in Linux è
 quella standardizzata da POSIX, basata sulla funzione \func{fcntl}. Abbiamo

diff --git a/filedir.tex b/filedir.tex
index 30d71caf2719152003dd00200760dbfe78023d7a..28326342d99d52478023e86cf421ff773acfae38 100644 (file)
--- a/filedir.tex
+++ b/filedir.tex
@@ -305,10 +305,11 @@ che non esiste: in questo caso si ha quello che viene chiamato un
 \textit{dangling link}, letteralmente un \textsl{link ciondolante}.
 
 Come accennato i link simbolici sono risolti automaticamente dal kernel
 \textit{dangling link}, letteralmente un \textsl{link ciondolante}.
 
 Come accennato i link simbolici sono risolti automaticamente dal kernel

-all'invocazione delle varie system call; in \ntab\ si è riportato un elenco
-dei comportamenti delle varie funzioni di libreria che operano sui file nei
-confronti della risoluzione dei link simbolici, specificando quali seguono il
-link simbolico e quali invece possono operare direttamente sul suo contenuto.
+all'invocazione delle varie system call; in \tabref{tab:file_symb_effect} si è
+riportato un elenco dei comportamenti delle varie funzioni di libreria che
+operano sui file nei confronti della risoluzione dei link simbolici,
+specificando quali seguono il link simbolico e quali invece possono operare
+direttamente sul suo contenuto.

 \begin{table}[htb]
   \centering
   \footnotesize
 \begin{table}[htb]
   \centering
   \footnotesize


@@ -386,15 +387,15 @@ stringa con un carattere nullo e la tronca alla dimensione specificata da
 \end{figure}
 
 Un caso comune che si può avere con i link simbolici è la creazione dei
 \end{figure}
 
 Un caso comune che si può avere con i link simbolici è la creazione dei

-cosiddetti \textit{loop}. La situazione è illustrata in \curfig, che riporta
-la struttura della directory \file{/boot}. Come si vede si è creato al suo
-interno un link simbolico che punta di nuovo a \file{/boot}.\footnote{Questo
-  tipo di loop è stato effettuato per poter permettere a \cmd{grub} (un
-  bootloader in grado di leggere direttamente da vari filesystem il file da
-  lanciare come sistema operativo) di vedere i file in questa directory con lo
-  stesso path con cui verrebbero visti dal sistema operativo, anche se essi si
-  trovano, come è solito, su una partizione separata (e che \cmd{grub}
-  vedrebbe come radice).}
+cosiddetti \textit{loop}. La situazione è illustrata in
+\figref{fig:file_link_loop}, che riporta la struttura della directory
+\file{/boot}. Come si vede si è creato al suo interno un link simbolico che
+punta di nuovo a \file{/boot}.\footnote{Questo tipo di loop è stato effettuato
+  per poter permettere a \cmd{grub} (un bootloader in grado di leggere
+  direttamente da vari filesystem il file da lanciare come sistema operativo)
+  di vedere i file in questa directory con lo stesso path con cui verrebbero
+  visti dal sistema operativo, anche se essi si trovano, come è solito, su una
+  partizione separata (e che \cmd{grub} vedrebbe come radice).}

 
 Questo può causare problemi per tutti quei programmi che effettuano la
 scansione di una directory senza tener conto dei link simbolici, ad esempio se
 
 Questo può causare problemi per tutti quei programmi che effettuano la
 scansione di una directory senza tener conto dei link simbolici, ad esempio se


@@ -919,10 +920,10 @@ su un file, su un link simbolico e su un file descriptor.
 
 La struttura \var{stat} usata da queste funzioni è definita nell'header
 \file{sys/stat.h} e in generale dipende dall'implementazione, la versione
 
 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 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).
+usata da Linux è mostrata in \figref{fig:file_stat_struct}, 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
 
 \begin{figure}[!htb]
   \footnotesize


@@ -970,7 +971,7 @@ standard POSIX definisce un insieme di macro per verificare il tipo di files,
 queste vengono usate anche da Linux che supporta pure le estensioni allo
 standard per i link simbolici e i socket definite da BSD; l'elenco completo
 delle macro con cui è possibile estrarre l'informazione da \var{st\_mode} è
 queste vengono usate anche da Linux che supporta pure le estensioni allo
 standard per i link simbolici e i socket definite da BSD; l'elenco completo
 delle macro con cui è possibile estrarre l'informazione da \var{st\_mode} è

-riportato in \ntab.
+riportato in \tabref{tab:file_type_macro}.

 \begin{table}[htb]
   \centering
   \footnotesize
 \begin{table}[htb]
   \centering
   \footnotesize


@@ -995,9 +996,10 @@ riportato in \ntab.
 Oltre alle macro di \tabref{tab:file_type_macro} è possibile usare
 direttamente il valore di \var{st\_mode} per ricavare il tipo di file
 controllando direttamente i vari bit in esso memorizzati. Per questo sempre in
 Oltre alle macro di \tabref{tab:file_type_macro} è possibile usare
 direttamente il valore di \var{st\_mode} per ricavare il tipo di file
 controllando direttamente i vari bit in esso memorizzati. Per questo sempre in

-\file{sys/stat.h} sono definite le costanti numeriche riportate in \ntab.
+\file{sys/stat.h} sono definite le costanti numeriche riportate in
+\tabref{tab:file_mode_flags}.

 
 

-Il primo valore dell'elenco di \secref{tab:file_mode_flags} è la maschera
+Il primo valore dell'elenco di \tabref{tab:file_mode_flags} è la maschera

 binaria che permette di estrarre i bit nei quali viene memorizzato il tipo di
 file, i valori successivi sono le costanti corrispondenti ai singoli bit, e
 possono essere usati per effettuare la selezione sul tipo di file voluto, con
 binaria che permette di estrarre i bit nei quali viene memorizzato il tipo di
 file, i valori successivi sono le costanti corrispondenti ai singoli bit, e
 possono essere usati per effettuare la selezione sul tipo di file voluto, con


@@ -1132,8 +1134,9 @@ Il sistema mantiene per ciascun file tre tempi. Questi sono registrati
 nell'inode insieme agli altri attributi del file e possono essere letti
 tramite la funzione \func{stat}, che li restituisce attraverso tre campi della
 struttura \var{stat} di \figref{fig:file_stat_struct}. Il significato di detti
 nell'inode insieme agli altri attributi del file e possono essere letti
 tramite la funzione \func{stat}, che li restituisce attraverso tre campi della
 struttura \var{stat} di \figref{fig:file_stat_struct}. Il significato di detti

-tempi e dei relativi campi è riportato nello schema in \ntab, dove si è anche
-riportato un esempio delle funzioni che effettuano cambiamenti su di essi.
+tempi e dei relativi campi è riportato nello schema in
+\tabref{tab:file_file_times}, dove si è anche riportato un esempio delle
+funzioni che effettuano cambiamenti su di essi.

 
 \begin{table}[htb]
   \centering
 
 \begin{table}[htb]
   \centering


@@ -1176,14 +1179,14 @@ quali file necessitano di essere ricompilati o (talvolta insieme anche al
 tempo di cambiamento di stato) per decidere quali file devono essere
 archiviati per il backup. Il comando \cmd{ls} (quando usato con le opzioni
 \cmd{-l} o \cmd{-t}) mostra i tempi dei file secondo lo schema riportato
 tempo di cambiamento di stato) per decidere quali file devono essere
 archiviati per il backup. Il comando \cmd{ls} (quando usato con le opzioni
 \cmd{-l} o \cmd{-t}) mostra i tempi dei file secondo lo schema riportato

-nell'ultima colonna di \curtab.
+nell'ultima colonna di \tabref{tab:file_file_times}.

 
 L'effetto delle varie funzioni di manipolazione dei file sui tempi è
 
 L'effetto delle varie funzioni di manipolazione dei file sui tempi è

-illustrato in \ntab. Si sono riportati gli effetti sia per il file a cui si fa
-riferimento, sia per la directory che lo contiene; questi ultimi possono
-essere capiti se si tiene conto di quanto già detto, e cioè che anche le
-directory sono file (che contengono una lista di nomi) che il sistema tratta
-in maniera del tutto analoga a tutti gli altri.
+illustrato in \tabref{tab:file_times_effects}. Si sono riportati gli effetti
+sia per il file a cui si fa riferimento, sia per la directory che lo contiene;
+questi ultimi possono essere capiti se si tiene conto di quanto già detto, e
+cioè che anche le directory sono file (che contengono una lista di nomi) che
+il sistema tratta in maniera del tutto analoga a tutti gli altri.

 
 Per questo motivo tutte le volte che compiremo un'operazione su un file che
 comporta una modifica del nome contenuto nella directory, andremo anche a
 
 Per questo motivo tutte le volte che compiremo un'operazione su un file che
 comporta una modifica del nome contenuto nella directory, andremo anche a


@@ -1389,7 +1392,7 @@ distinzione dato che in certi casi, mutuando la terminologia in uso nel VMS,
 si parla dei permessi base come di permessi per \textit{owner}, \textit{group}
 ed \textit{all}, le cui iniziali possono dar luogo a confusione.  Le costanti
 che permettono di accedere al valore numerico di questi bit nel campo
 si parla dei permessi base come di permessi per \textit{owner}, \textit{group}
 ed \textit{all}, le cui iniziali possono dar luogo a confusione.  Le costanti
 che permettono di accedere al valore numerico di questi bit nel campo

-\var{st\_mode} sono riportate in \ntab.
+\var{st\_mode} sono riportate in \tabref{tab:file_bit_perm}.

 
 \begin{table}[htb]
   \centering
 
 \begin{table}[htb]
   \centering

diff --git a/fileintro.tex b/fileintro.tex
index 359a1e26391e07f38de5b5186c64638d215997e8..794d61159b96fe74cb463c39be53c3697fbdc405 100644 (file)
--- a/fileintro.tex
+++ b/fileintro.tex
@@ -471,7 +471,8 @@ metodi che implementano le operazioni disponibili sul file. In questo modo i
 processi in user space possono accedere alle operazioni attraverso detti
 metodi, che saranno diversi a seconda del tipo di file (o dispositivo) aperto
 (su questo torneremo in dettaglio in \secref{sec:file_fd}). Un elenco delle
 processi in user space possono accedere alle operazioni attraverso detti
 metodi, che saranno diversi a seconda del tipo di file (o dispositivo) aperto
 (su questo torneremo in dettaglio in \secref{sec:file_fd}). Un elenco delle

-operazioni previste dal kernel è riportato in \ntab.
+operazioni previste dal kernel è riportato in
+\tabref{tab:file_file_operations}.

 
 \begin{table}[htb]
   \centering
 
 \begin{table}[htb]
   \centering


@@ -533,13 +534,14 @@ alle caratteristiche comuni di qualunque filesystem di sistema unix-like.
 
 Lo spazio fisico di un disco viene usualmente diviso in partizioni; ogni
 partizione può contenere un filesystem. La strutturazione tipica
 
 Lo spazio fisico di un disco viene usualmente diviso in partizioni; ogni
 partizione può contenere un filesystem. La strutturazione tipica

-dell'informazione su un disco è riportata in \nfig; in essa si fa riferimento
-alla struttura del filesystem \acr{ext2}, che prevede una separazione dei dati
-in \textit{blocks group} che replicano il superblock (ma sulle caratteristiche
-di \acr{ext2} torneremo in \secref{sec:file_ext2}). È comunque caratteristica
-comune di tutti i filesystem per Unix, indipendentemente da come poi viene
-strutturata nei dettagli questa informazione, prevedere una divisione fra la
-lista degli inodes e lo spazio a disposizione per i dati e le directory.
+dell'informazione su un disco è riportata in \figref{fig:file_disk_filesys};
+in essa si fa riferimento alla struttura del filesystem \acr{ext2}, che
+prevede una separazione dei dati in \textit{blocks group} che replicano il
+superblock (ma sulle caratteristiche di \acr{ext2} torneremo in
+\secref{sec:file_ext2}). È comunque caratteristica comune di tutti i
+filesystem per Unix, indipendentemente da come poi viene strutturata nei
+dettagli questa informazione, prevedere una divisione fra la lista degli
+inodes e lo spazio a disposizione per i dati e le directory.

 
 \begin{figure}[htb]
   \centering
 
 \begin{figure}[htb]
   \centering


@@ -553,7 +555,8 @@ Se si va ad esaminare con maggiore dettaglio la strutturazione
 dell'informazione all'interno del singolo filesystem (tralasciando i dettagli
 relativi al funzionamento del filesystem stesso come la strutturazione in
 gruppi dei blocchi, il superblock e tutti i dati di gestione) possiamo
 dell'informazione all'interno del singolo filesystem (tralasciando i dettagli
 relativi al funzionamento del filesystem stesso come la strutturazione in
 gruppi dei blocchi, il superblock e tutti i dati di gestione) possiamo

-esemplificare la situazione con uno schema come quello esposto in \nfig.
+esemplificare la situazione con uno schema come quello esposto in
+\figref{fig:file_filesys_detail}.

 
 \begin{figure}[htb]
   \centering
 
 \begin{figure}[htb]
   \centering


@@ -562,11 +565,11 @@ esemplificare la situazione con uno schema come quello esposto in \nfig.
   \label{fig:file_filesys_detail}
 \end{figure}
 
   \label{fig:file_filesys_detail}
 \end{figure}
 

-Da \curfig\ si evidenziano alcune delle caratteristiche di base di un
-filesystem, sulle quali è bene porre attenzione visto che sono fondamentali
-per capire il funzionamento delle funzioni che manipolano i file e le
-directory che tratteremo nel prossimo capitolo; in particolare è opportuno
-ricordare sempre che:
+Da \figref{fig:file_filesys_detail} si evidenziano alcune delle
+caratteristiche di base di un filesystem, sulle quali è bene porre attenzione
+visto che sono fondamentali per capire il funzionamento delle funzioni che
+manipolano i file e le directory che tratteremo nel prossimo capitolo; in
+particolare è opportuno ricordare sempre che:

 
 \begin{enumerate}
   
 
 \begin{enumerate}
   


@@ -579,15 +582,15 @@ ricordare sempre che:
   traduzione dell'inglese \textit{directory entry}, che non useremo anche per
   evitare confusione con le \textit{dentry} del kernel di cui si parlava in
   \secref{sec:file_vfs}).
   traduzione dell'inglese \textit{directory entry}, che non useremo anche per
   evitare confusione con le \textit{dentry} del kernel di cui si parlava in
   \secref{sec:file_vfs}).

-
-\item Come mostrato in \curfig\ si possono avere più voci che puntano allo
-  stesso \textit{inode}. Ogni \textit{inode} ha un contatore che contiene il
-  numero di riferimenti (\textit{link count}) che sono stati fatti ad esso;
-  solo quando questo contatore si annulla i dati del file vengono
-  effettivamente rimossi dal disco. Per questo la funzione per cancellare un
-  file si chiama \func{unlink}, ed in realtà non cancella affatto i dati del
-  file, ma si limita ad eliminare la relativa voce da una directory e
-  decrementare il numero di riferimenti nell'\textit{inode}.
+  
+\item Come mostrato in \figref{fig:file_filesys_detail} si possono avere più
+  voci che puntano allo stesso \textit{inode}. Ogni \textit{inode} ha un
+  contatore che contiene il numero di riferimenti (\textit{link count}) che
+  sono stati fatti ad esso; solo quando questo contatore si annulla i dati del
+  file vengono effettivamente rimossi dal disco. Per questo la funzione per
+  cancellare un file si chiama \func{unlink}, ed in realtà non cancella
+  affatto i dati del file, ma si limita ad eliminare la relativa voce da una
+  directory e decrementare il numero di riferimenti nell'\textit{inode}.

 
 \item Il numero di \textit{inode} nella voce si riferisce ad un \textit{inode}
   nello stesso filesystem e non ci può essere una directory che contiene
 
 \item Il numero di \textit{inode} nella voce si riferisce ad un \textit{inode}
   nello stesso filesystem e non ci può essere una directory che contiene


@@ -605,9 +608,10 @@ ricordare sempre che:
 
 Infine è bene avere presente che, essendo file pure loro, esiste un numero di
 riferimenti anche per le directory; per cui, se a partire dalla situazione
 
 Infine è bene avere presente che, essendo file pure loro, esiste un numero di
 riferimenti anche per le directory; per cui, se a partire dalla situazione

-mostrata in \curfig\ creiamo una nuova directory \file{img} nella directory
-\file{gapil}, avremo una situazione come quella in \nfig, dove per chiarezza
-abbiamo aggiunto dei numeri di inode.
+mostrata in \figref{fig:file_filesys_detail} creiamo una nuova directory
+\file{img} nella directory \file{gapil}, avremo una situazione come quella in
+\figref{fig:file_dirs_link}, dove per chiarezza abbiamo aggiunto dei numeri di
+inode.

 
 \begin{figure}[htb]
   \centering 
 
 \begin{figure}[htb]
   \centering 


@@ -686,9 +690,9 @@ inode.
 
 Le directory sono implementate come una linked list con voci di dimensione
 variabile. Ciascuna voce della lista contiene il numero di inode, la sua
 
 Le directory sono implementate come una linked list con voci di dimensione
 variabile. Ciascuna voce della lista contiene il numero di inode, la sua

-lunghezza, il nome del file e la sua lunghezza, secondo lo schema in \curfig;
-in questo modo è possibile implementare nomi per i file anche molto lunghi
-(fino a 1024 caratteri) senza sprecare spazio disco.
+lunghezza, il nome del file e la sua lunghezza, secondo lo schema in
+\figref{fig:file_ext2_dirs}; in questo modo è possibile implementare nomi per
+i file anche molto lunghi (fino a 1024 caratteri) senza sprecare spazio disco.

 
 
 
 
 
 

diff --git a/fileunix.tex b/fileunix.tex
index cec06e367c7b742a15d0212e5f7662d533cd5b96..bd3ed091fa27e1b6f9a2b66de914992db8be7985 100644 (file)
--- a/fileunix.tex
+++ b/fileunix.tex
@@ -138,10 +138,11 @@ posto di questi valori numerici:
   \label{tab:file_std_files}
 \end{table}
 
   \label{tab:file_std_files}
 \end{table}
 

-In \curfig\ si è utilizzata questa situazione come esempio, facendo
-riferimento ad un programma in cui lo \textit{standard input} è associato ad
-un file mentre lo \textit{standard output} e lo \textit{standard error} sono
-entrambi associati ad un altro file (e quindi utilizzano lo stesso inode).
+In \figref{tab:file_std_files} si è utilizzata questa situazione come esempio,
+facendo riferimento ad un programma in cui lo \textit{standard input} è
+associato ad un file mentre lo \textit{standard output} e lo \textit{standard
+  error} sono entrambi associati ad un altro file (e quindi utilizzano lo
+stesso inode).

 
 Nelle vecchie versioni di Unix (ed anche in Linux fino al kernel 2.0.x) il
 numero di file aperti era anche soggetto ad un limite massimo dato dalle
 
 Nelle vecchie versioni di Unix (ed anche in Linux fino al kernel 2.0.x) il
 numero di file aperti era anche soggetto ad un limite massimo dato dalle


@@ -335,7 +336,8 @@ La funzione prevede diverse opzioni, che vengono specificate usando vari bit
 dell'argomento \param{flags}.  Alcuni di questi bit vanno anche a costituire
 il flag di stato del file (o \textit{file status flag}), che è mantenuto nel
 campo \var{f\_flags} della struttura \var{file} (al solito si veda lo schema
 dell'argomento \param{flags}.  Alcuni di questi bit vanno anche a costituire
 il flag di stato del file (o \textit{file status flag}), che è mantenuto nel
 campo \var{f\_flags} della struttura \var{file} (al solito si veda lo schema

-di \curfig).  Essi sono divisi in tre categorie principali:
+di \figref{fig:file_proc_file}).  Essi sono divisi in tre categorie
+principali:

 \begin{itemize}
 \item \textsl{i bit delle modalità di accesso}: specificano con quale modalità
   si accederà al file: i valori possibili sono lettura, scrittura o
 \begin{itemize}
 \item \textsl{i bit delle modalità di accesso}: specificano con quale modalità
   si accederà al file: i valori possibili sono lettura, scrittura o

diff --git a/gapil.tex b/gapil.tex
index 3140c2844bcc921aca02168e2d4fc67728aac37e..c37cd34d50384413b56654c71a57905c48a564df 100644 (file)
--- a/gapil.tex
+++ b/gapil.tex
@@ -21,8 +21,8 @@
 \usepackage{listings}
 \lstloadlanguages{C++}
 \usepackage{color} 
 \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} 
 %
 %\usepackage{footnote} 
 %\usepackage{mdwtab} 
 %


@@ -73,7 +73,7 @@
 \tableofcontents
 \clearemptydoublepage
 
 \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}
 \include{macro}
 \setcounter{secnumdepth}{-2}
 \include{pref}

diff --git a/ipprot.tex b/ipprot.tex
index 818abcbde3b7bee3410987e8f90a17b16a51a5b3..23598b19758218a9882b595e0b41072649b28bd7 100644 (file)
--- a/ipprot.tex
+++ b/ipprot.tex
@@ -680,7 +680,7 @@ registri nazionali, quest'ultimi poi avranno il compito di gestire la
 attribuzione degli indirizzi per i fornitori di servizi nell'ambito del/i
 paese coperto dal registro nazionale con le modalità viste in precedenza.
 Una tale ripartizione andrà effettuata all'interno dei soliti 56~bit come
 attribuzione degli indirizzi per i fornitori di servizi nell'ambito del/i
 paese coperto dal registro nazionale con le modalità viste in precedenza.
 Una tale ripartizione andrà effettuata all'interno dei soliti 56~bit come

-mostrato in \ntab.
+mostrato in \tabref{tab:IP_ipv6_uninaz}.

 
 \begin{table}[htb]
   \centering
 
 \begin{table}[htb]
   \centering


@@ -747,14 +747,13 @@ sorgente o destinazione non deve venire ritrasmesso dai router.
 
 Un indirizzo \textit{site-local} invece è usato per l'indirizzamento
 all'interno di un sito che non necessita di un prefisso globale; la struttura
 
 Un indirizzo \textit{site-local} invece è usato per l'indirizzamento
 all'interno di un sito che non necessita di un prefisso globale; la struttura

-è mostrata in \ntab, questi indirizzi iniziano sempre per
-\texttt{FEC0} e non devono venire ritrasmessi dai router all'esterno del sito
-stesso; sono in sostanza gli equivalenti degli indirizzi riservati per reti
-private definiti su IPv4.
-Per entrambi gli indirizzi il campo \textit{Interface Id} è un
-identificatore che deve essere unico nel dominio in cui viene usato, un modo
-immediato per costruirlo è quello di usare il MAC-address delle schede di
-rete.
+è mostrata in \tabref{tab:IP_ipv6_sitelocal}, questi indirizzi iniziano sempre
+per \texttt{FEC0} e non devono venire ritrasmessi dai router all'esterno del
+sito stesso; sono in sostanza gli equivalenti degli indirizzi riservati per
+reti private definiti su IPv4.  Per entrambi gli indirizzi il campo
+\textit{Interface Id} è un identificatore che deve essere unico nel dominio in
+cui viene usato, un modo immediato per costruirlo è quello di usare il
+MAC-address delle schede di rete.

  
 \begin{table}[!h]
   \centering
  
 \begin{table}[!h]
   \centering


@@ -790,12 +789,12 @@ Alcuni indirizzi sono riservati per scopi speciali, in particolare per scopi
 di compatibilità.
 
 Un primo tipo sono gli indirizzi \textit{IPv4 mappati su IPv6} (mostrati in
 di compatibilità.
 
 Un primo tipo sono gli indirizzi \textit{IPv4 mappati su IPv6} (mostrati in

-\ntab), questo sono indirizzi unicast che vengono usati per consentire ad
-applicazioni IPv6 di comunicare con host capaci solo di IPv4; questi sono ad
-esempio gli indirizzi generati da un DNS quando l'host richiesto supporta solo
-IPv4; l'uso di un tale indirizzo in un socket IPv6 comporta la generazione di
-un pacchetto IPv4 (ovviamente occorre che sia IPv4 che IPv6 siano supportati
-sull'host di origine).
+\tabref{tab:IP_ipv6_map}), questo sono indirizzi unicast che vengono usati per
+consentire ad applicazioni IPv6 di comunicare con host capaci solo di IPv4;
+questi sono ad esempio gli indirizzi generati da un DNS quando l'host
+richiesto supporta solo IPv4; l'uso di un tale indirizzo in un socket IPv6
+comporta la generazione di un pacchetto IPv4 (ovviamente occorre che sia IPv4
+che IPv6 siano supportati sull'host di origine).

 
 \begin{table}[!htb]
   \centering
 
 \begin{table}[!htb]
   \centering


@@ -851,11 +850,11 @@ l'accettazione di una connessione da qualunque host.
 \label{sec:IP_ipv6_multicast}
 
 Gli indirizzi \textit{multicast} sono usati per inviare un pacchetto a un
 \label{sec:IP_ipv6_multicast}
 
 Gli indirizzi \textit{multicast} sono usati per inviare un pacchetto a un

-gruppo di interfacce; l'indirizzo identifica uno specifico gruppo di
-multicast e il pacchetto viene inviato a tutte le interfacce di detto gruppo.
+gruppo di interfacce; l'indirizzo identifica uno specifico gruppo di multicast
+e il pacchetto viene inviato a tutte le interfacce di detto gruppo.

 Un'interfaccia può appartenere ad un numero qualunque numero di gruppi di
 multicast. Il formato degli indirizzi \textit{multicast} è riportato in
 Un'interfaccia può appartenere ad un numero qualunque numero di gruppi di
 multicast. Il formato degli indirizzi \textit{multicast} è riportato in

-\ntab:
+\tabref{tab:IP_ipv6_multicast}:

 
 \begin{table}[htb]
   \centering
 
 \begin{table}[htb]
   \centering


@@ -887,7 +886,7 @@ Il prefisso di formato per tutti gli indirizzi \textit{multicast} 
   transitorio.
 \item \textsl{scop} è un numero di quattro bit che indica il raggio di
   validità dell'indirizzo, i valori assegnati per ora sono riportati in
   transitorio.
 \item \textsl{scop} è un numero di quattro bit che indica il raggio di
   validità dell'indirizzo, i valori assegnati per ora sono riportati in

-  \ntab.
+  \tabref{tab:IP_ipv6_multiscope}.

 \end{itemize}
 
 
 \end{itemize}
 
 


@@ -1040,7 +1039,7 @@ che indica qual'
 opzioni questa sarà l'intestazione di un protocollo di trasporto del livello
 superiore, per cui il campo assumerà lo stesso valore del campo
 \textit{protocol} di IPv4, altrimenti assumerà il valore dell'opzione
 opzioni questa sarà l'intestazione di un protocollo di trasporto del livello
 superiore, per cui il campo assumerà lo stesso valore del campo
 \textit{protocol} di IPv4, altrimenti assumerà il valore dell'opzione

-presente; i valori possibili sono riportati in \ntab.
+presente; i valori possibili sono riportati in \tabref{tab:IP_ipv6_nexthead}.

 
 \begin{table}[htb]
   \begin{center}
 
 \begin{table}[htb]
   \begin{center}

diff --git a/macro.tex b/macro.tex
index afd290c1b96193d34494f30fbdf0e85f6ae1ea23..33640c5d74ea7a7448f10289626958d4dbe53759 100644 (file)
--- a/macro.tex
+++ b/macro.tex
@@ -8,31 +8,10 @@
 %
 % Figure commands
 %
 %
 % Figure commands
 %

-\newcommand{\curfig}{fig.~\thefigure}
-
-\newcommand{\nfig}{%
-\setcounter{usercount}{\value{figure}}%
-\addtocounter{usercount}{1}%
-fig.~\thechapter.\theusercount}
-
-\newcommand{\pfig}{%
-\setcounter{usercount}{\value{figure}}%
-\addtocounter{usercount}{-1}%
-fig.~\thechapter.\theusercount}
-

 \newcommand{\figref}[1]{fig.~\ref{#1}}
 %
 % Tables commands
 %
 \newcommand{\figref}[1]{fig.~\ref{#1}}
 %
 % Tables commands
 %

-\newcommand{\curtab}{tab.~\thetable}
-\newcommand{\ntab}{%
-\setcounter{usercount}{\value{table}}%
-\addtocounter{usercount}{1}%
-tab.~\thechapter.\theusercount}
-\newcommand{\ptab}{%
-\setcounter{usercount}{\value{table}}%
-\addtocounter{usercount}{-1}%
-tab.~\thechapter.\theusercount}

 \newcommand{\tabref}[1]{tab.~\ref{#1}}
 %
 % equations commands
 \newcommand{\tabref}[1]{tab.~\ref{#1}}
 %
 % equations commands

diff --git a/network.tex b/network.tex
index db2cb4d06cb4768889bc4ea5a9a51ec0c8eb756d..6f6148e4fd7d4896baf23f1869528c0ab117c609 100644 (file)
--- a/network.tex
+++ b/network.tex
@@ -114,11 +114,11 @@ della Difesa Americano.
 \label{sec:net_tcpip_overview}
 
 Così come ISO/OSI anche TCP/IP è stato strutturato in livelli (riassunti in
 \label{sec:net_tcpip_overview}
 
 Così come ISO/OSI anche TCP/IP è stato strutturato in livelli (riassunti in

-\ntab); un confronto fra i due è riportato in \curfig\ dove viene evidenziata
-anche la corrispondenza fra i rispettivi livelli (che comunque è
-approssimativa) e su come essi vanno ad inserirsi all'interno del sistema
-operativo rispetto alla divisione fra user space e kernel space spiegata in
-\secref{sec:intro_unix_struct}.
+\tabref{tab:net_layers}); un confronto fra i due è riportato in
+\figref{fig:net_osi_tcpip_comp} dove viene evidenziata anche la corrispondenza
+fra i rispettivi livelli (che comunque è approssimativa) e su come essi vanno
+ad inserirsi all'interno del sistema operativo rispetto alla divisione fra
+user space e kernel space spiegata in \secref{sec:intro_unix_struct}.

 
 \begin{table}[htb]
   \centering
 
 \begin{table}[htb]
   \centering


@@ -165,8 +165,8 @@ compongono, il TCP \textit{Trasmission Control Protocol} e l'IP
 
 
 La comunicazione fra due stazioni avviene secondo le modalità illustrate in
 
 
 La comunicazione fra due stazioni avviene secondo le modalità illustrate in

-\nfig, dove si è riportato il flusso dei dati reali e i protocolli usati per
-lo scambio di informazione su ciascuno livello.
+\figref{fig:net_tcpip_data_flux}, dove si è riportato il flusso dei dati reali
+e i protocolli usati per lo scambio di informazione su ciascuno livello.

 \begin{figure}[!htb]
   \centering
   \includegraphics[width=10cm]{img/tcp_data_flux}  
 \begin{figure}[!htb]
   \centering
   \includegraphics[width=10cm]{img/tcp_data_flux}  


@@ -247,16 +247,16 @@ infatti un'interfaccia nei confronti di quest'ultimo. Questo avviene perch
 di sopra del livello di trasporto i programmi hanno a che fare solo con
 dettagli specifici delle applicazioni, mentre al di sotto vengono curati tutti
 i dettagli relativi alla comunicazione. È pertanto naturale definire una API
 di sopra del livello di trasporto i programmi hanno a che fare solo con
 dettagli specifici delle applicazioni, mentre al di sotto vengono curati tutti
 i dettagli relativi alla comunicazione. È pertanto naturale definire una API

-su questo confine tanto più che è proprio li (come evidenziato in \pfig) che
-nei sistemi unix (e non solo) viene inserita la divisione fra kernel space e
-user space.
+su questo confine tanto più che è proprio li (come evidenziato in
+\figref{fig:net_osi_tcpip_comp}) che nei sistemi Unix (e non solo) viene
+inserita la divisione fra kernel space e user space.

 
 

-In realtà in un sistema unix è possibile accedere anche agli altri livelli
+In realtà in un sistema Unix è possibile accedere anche agli altri livelli

 inferiori (e non solo a quello di trasporto) con opportune interfacce (la cosa
 inferiori (e non solo a quello di trasporto) con opportune interfacce (la cosa

-è indicata in \pfig\ lasciando uno spazio fra UDP e TCP), ma queste vengono
-usate solo quando si vogliono fare applicazioni di sistema per il controllo
-della rete a basso livello, un uso quindi molto specialistico, e che non
-rientra in quanto trattato qui.
+è indicata in \figref{fig:net_osi_tcpip_comp} lasciando uno spazio fra UDP e
+TCP), ma queste vengono usate solo quando si vogliono fare applicazioni di
+sistema per il controllo della rete a basso livello, un uso quindi molto
+specialistico, e che non rientra in quanto trattato qui.

 
 In questa sezione daremo una breve descrizione dei vari protocolli di TCP/IP,
 concentrandoci per le ragioni esposte sul livello di trasporto. All'interno di
 
 In questa sezione daremo una breve descrizione dei vari protocolli di TCP/IP,
 concentrandoci per le ragioni esposte sul livello di trasporto. All'interno di


@@ -268,9 +268,9 @@ nella maggior parte delle applicazioni.
 \label{sec:net_tcpip_general}
 
 Benché si parli di TCP/IP questa famiglia di protocolli è composta anche da
 \label{sec:net_tcpip_general}
 
 Benché si parli di TCP/IP questa famiglia di protocolli è composta anche da

-altri membri. In \nfig\ si è riportato uno schema che mostra un panorama sui
-vari protocolli della famiglia, e delle loro relazioni reciproche e con
-alcune dalle principali applicazioni che li usano.
+altri membri. In \figref{fig:net_tcpip_overview} si è riportato uno schema che
+mostra un panorama sui vari protocolli della famiglia, e delle loro relazioni
+reciproche e con alcune dalle principali applicazioni che li usano.

 
 \begin{figure}[!htbp]
   \centering
 
 \begin{figure}[!htbp]
   \centering


@@ -523,7 +523,7 @@ loro origini ed alle eventuali implicazioni che possono avere:
 \item Molte reti fisiche hanno un MTU (\textit{maximum transfer unit}) che
   dipende dal protocollo specifico usato al livello di link. Il più comune è
   quello dell'Ethernet che è pari a 1500 byte, una serie di valori possibili
 \item Molte reti fisiche hanno un MTU (\textit{maximum transfer unit}) che
   dipende dal protocollo specifico usato al livello di link. Il più comune è
   quello dell'Ethernet che è pari a 1500 byte, una serie di valori possibili

-  sono riportati in \ntab.
+  sono riportati in \tabref{tab:net_mtu_values}.

 \end{itemize}
 
 Quando un pacchetto IP viene inviato su una interfaccia di rete e le sue
 \end{itemize}
 
 Quando un pacchetto IP viene inviato su una interfaccia di rete e le sue

diff --git a/process.tex b/process.tex
index e5e4b50ab66464dd828c8eead3a339c6d7a263ee..9a23884278ecd6d79893a98fb87df3e86b87cf7e 100644 (file)
--- a/process.tex
+++ b/process.tex
@@ -222,7 +222,7 @@ volontariamente la sua esecuzione 
 \func{exit} o il ritorno di \func{main}.
 
 Uno schema riassuntivo che illustra le modalità con cui si avvia e conclude
 \func{exit} o il ritorno di \func{main}.
 
 Uno schema riassuntivo che illustra le modalità con cui si avvia e conclude

-normalmente un programma è riportato in \nfig.
+normalmente un programma è riportato in \figref{fig:proc_prog_start_stop}.

 
 \begin{figure}[htb]
   \centering
 
 \begin{figure}[htb]
   \centering


@@ -233,7 +233,8 @@ normalmente un programma 
 
 Si ricordi infine che un programma può anche essere interrotto dall'esterno
 attraverso l'uso di un segnale (modalità di conclusione non mostrata in
 
 Si ricordi infine che un programma può anche essere interrotto dall'esterno
 attraverso l'uso di un segnale (modalità di conclusione non mostrata in

-\curfig); torneremo su questo aspetto in \capref{cha:signals}.
+\figref{fig:proc_prog_start_stop}); torneremo su questo aspetto in
+\capref{cha:signals}.

 
 
 
 
 
 


@@ -842,7 +843,7 @@ Nella scansione viene costruito il vettore di puntatori \var{argv} inserendo
 in successione il puntatore alla stringa costituente l'$n$-simo parametro; la
 variabile \var{argc} viene inizializzata al numero di parametri trovati, in
 questo modo il primo parametro è sempre il nome del programma; un esempio di
 in successione il puntatore alla stringa costituente l'$n$-simo parametro; la
 variabile \var{argc} viene inizializzata al numero di parametri trovati, in
 questo modo il primo parametro è sempre il nome del programma; un esempio di

-questo meccanismo è mostrato in \curfig.
+questo meccanismo è mostrato in \figref{fig:proc_argv_argc}.

 
 
 \subsection{La gestione delle opzioni}
 
 
 \subsection{La gestione delle opzioni}


@@ -1015,9 +1016,9 @@ pi
 
 Per convenzione le stringhe che definiscono l'ambiente sono tutte del tipo
 \textsl{\texttt{nome=valore}}. Inoltre alcune variabili, come quelle elencate
 
 Per convenzione le stringhe che definiscono l'ambiente sono tutte del tipo
 \textsl{\texttt{nome=valore}}. Inoltre alcune variabili, come quelle elencate

-in \curfig, sono definite dal sistema per essere usate da diversi programmi e
-funzioni: per queste c'è l'ulteriore convenzione di usare nomi espressi in
-caratteri maiuscoli.
+in \figref{fig:proc_envirno_list}, sono definite dal sistema per essere usate
+da diversi programmi e funzioni: per queste c'è l'ulteriore convenzione di
+usare nomi espressi in caratteri maiuscoli.

 
 Il kernel non usa mai queste variabili, il loro uso e la loro interpretazione è
 riservata alle applicazioni e ad alcune funzioni di libreria; in genere esse
 
 Il kernel non usa mai queste variabili, il loro uso e la loro interpretazione è
 riservata alle applicazioni e ad alcune funzioni di libreria; in genere esse


@@ -1034,8 +1035,9 @@ programmi (come \var{EDITOR} che indica l'editor preferito da invocare in caso
 di necessità).
 
 Gli standard POSIX e XPG3 definiscono alcune di queste variabili (le più
 di necessità).
 
 Gli standard POSIX e XPG3 definiscono alcune di queste variabili (le più

-comuni), come riportato in \ntab. GNU/Linux le supporta tutte e ne definisce
-anche altre: per una lista più completa si può controllare \cmd{man environ}.
+comuni), come riportato in \tabref{tab:proc_env_var}. GNU/Linux le supporta
+tutte e ne definisce anche altre: per una lista più completa si può
+controllare \cmd{man environ}.

 
 \begin{table}[htb]
   \centering
 
 \begin{table}[htb]
   \centering


@@ -1082,7 +1084,7 @@ Oltre a questa funzione di lettura, che 
 C, nell'evoluzione dei sistemi Unix ne sono state proposte altre, da
 utilizzare per impostare e per cancellare le variabili di ambiente. Uno schema
 delle funzioni previste nei vari standard e disponibili in Linux è riportato
 C, nell'evoluzione dei sistemi Unix ne sono state proposte altre, da
 utilizzare per impostare e per cancellare le variabili di ambiente. Uno schema
 delle funzioni previste nei vari standard e disponibili in Linux è riportato

-in \ntab.
+in \tabref{tab:proc_env_func}.

 
 \begin{table}[htb]
   \centering
 
 \begin{table}[htb]
   \centering


@@ -1108,9 +1110,9 @@ in \ntab.
   \label{tab:proc_env_func}
 \end{table}
 
   \label{tab:proc_env_func}
 \end{table}
 

-In Linux solo le prime quattro funzioni di \curtab\ sono definite,
-\func{getenv} l'abbiamo già esaminata; delle tre restanti le prime due,
-\func{putenv} e \func{setenv}, servono per assegnare nuove variabili di
+In Linux solo le prime quattro funzioni di \tabref{tab:proc_env_func} sono
+definite, \func{getenv} l'abbiamo già esaminata; delle tre restanti le prime
+due, \func{putenv} e \func{setenv}, servono per assegnare nuove variabili di

 ambiente, i loro prototipi sono i seguenti:
 \begin{functions}
   \headdecl{stdlib.h} 
 ambiente, i loro prototipi sono i seguenti:
 \begin{functions}
   \headdecl{stdlib.h} 

diff --git a/prochand.tex b/prochand.tex
index af655984f8244982e2b9817928cac9bd9ab753e7..534049e4af90da2abca9477674491f948239a2c8 100644 (file)
--- a/prochand.tex
+++ b/prochand.tex
@@ -109,9 +109,10 @@ Dato che tutti i processi attivi nel sistema sono comunque generati da
 possono classificare i processi con la relazione padre/figlio in
 un'organizzazione gerarchica ad albero, in maniera analoga a come i file sono
 organizzati in un albero di directory (si veda
 possono classificare i processi con la relazione padre/figlio in
 un'organizzazione gerarchica ad albero, in maniera analoga a come i file sono
 organizzati in un albero di directory (si veda

-\secref{sec:file_organization}); in \curfig\ si è mostrato il risultato del
-comando \cmd{pstree} che permette di visualizzare questa struttura, alla cui
-base c'è \cmd{init} che è progenitore di tutti gli altri processi.
+\secref{sec:file_organization}); in \figref{fig:proc_tree} si è mostrato il
+risultato del comando \cmd{pstree} che permette di visualizzare questa
+struttura, alla cui base c'è \cmd{init} che è progenitore di tutti gli altri
+processi.

 
 Il kernel mantiene una tabella dei processi attivi, la cosiddetta
 \textit{process table}; per ciascun processo viene mantenuta una voce nella
 
 Il kernel mantiene una tabella dei processi attivi, la cosiddetta
 \textit{process table}; per ciascun processo viene mantenuta una voce nella


@@ -1124,10 +1125,11 @@ linea di comando e l'ambiente ricevuti dal nuovo processo.
 \end{functions}
 
 Per capire meglio le differenze fra le funzioni della famiglia si può fare
 \end{functions}
 
 Per capire meglio le differenze fra le funzioni della famiglia si può fare

-riferimento allo specchietto riportato in \ntab. La prima differenza riguarda
-le modalità di passaggio dei parametri che poi andranno a costituire gli
-argomenti a linea di comando (cioè i valori di \var{argv} e \var{argc} visti
-dalla funzione \func{main} del programma chiamato). 
+riferimento allo specchietto riportato in \tabref{tab:proc_exec_scheme}. La
+prima differenza riguarda le modalità di passaggio dei parametri che poi
+andranno a costituire gli argomenti a linea di comando (cioè i valori di
+\var{argv} e \var{argc} visti dalla funzione \func{main} del programma
+chiamato).

 
 Queste modalità sono due e sono riassunte dagli mnemonici \code{v} e \code{l}
 che stanno rispettivamente per \textit{vector} e \textit{list}. Nel primo caso
 
 Queste modalità sono due e sono riassunte dagli mnemonici \code{v} e \code{l}
 che stanno rispettivamente per \textit{vector} e \textit{list}. Nel primo caso

diff --git a/simpltcp.tex b/simpltcp.tex
index b9d99e64afb8a46e54fa97de01dc9a66771fd6b3..8a6b2aed9a3a28077a8c3944748c741b36be9579 100644 (file)
--- a/simpltcp.tex
+++ b/simpltcp.tex
@@ -121,14 +121,15 @@ alla funzione \code{ServEcho}.
 % processo figlio, il quale si incarica di lanciare la funzione
 % \texttt{SockEcho}.
 
 % processo figlio, il quale si incarica di lanciare la funzione
 % \texttt{SockEcho}.
 

-Il codice della funzione \code{ServEcho} è invece mostrata in \nfig, la
-comunicazione viene gestita all'interno del ciclo (linee \texttt{\small
-  6--8}).  I dati inviati dal client vengono letti dal socket con una semplice
-\func{read} (che ritorna solo in presenza di dati in arrivo), la riscrittura
-viene invece gestita dalla funzione \func{SockWrite} (descritta in
-\figref{fig:sock_SockWrite_code}) che si incarica di tenere conto
-automaticamente della possibilità che non tutti i dati di cui è richiesta la
-scrittura vengano trasmessi con una singola \func{write}.
+Il codice della funzione \code{ServEcho} è invece mostrata in
+\figref{fig:TCPsimpl_server_elem_sub}, la comunicazione viene gestita
+all'interno del ciclo (linee \texttt{\small 6--8}).  I dati inviati dal client
+vengono letti dal socket con una semplice \func{read} (che ritorna solo in
+presenza di dati in arrivo), la riscrittura viene invece gestita dalla
+funzione \func{SockWrite} (descritta in \figref{fig:sock_SockWrite_code}) che
+si incarica di tenere conto automaticamente della possibilità che non tutti i
+dati di cui è richiesta la scrittura vengano trasmessi con una singola
+\func{write}.

 
 \begin{figure}[!htb]
   \footnotesize
 
 \begin{figure}[!htb]
   \footnotesize

diff --git a/socket.tex b/socket.tex
index 98a79a64db1b825aa40d988653b1140129f2fa95..ef729a56eb0e35ae88b95d02b57f4e7c911696f1 100644 (file)
--- a/socket.tex
+++ b/socket.tex
@@ -785,8 +785,9 @@ ssize_t SockRead(int fd, void *buf, size_t count)
 Per questo motivo seguendo l'esempio di W. R. Stevens si sono definite due
 funzioni \func{SockRead} e \func{SockWrite} che eseguono la lettura da un
 socket tenendo conto di questa caratteristica, ed in grado di ritornare dopo
 Per questo motivo seguendo l'esempio di W. R. Stevens si sono definite due
 funzioni \func{SockRead} e \func{SockWrite} che eseguono la lettura da un
 socket tenendo conto di questa caratteristica, ed in grado di ritornare dopo

-avere letto o scritto esattamente il numero di byte specificato; il sorgente
-è riportato in \curfig\ e \nfig\ ed è disponibile fra i sorgenti allegati alla
+avere letto o scritto esattamente il numero di byte specificato; il sorgente è
+riportato in \figref{fig:sock_SockRead_code} e
+\figref{fig:sock_SockWrite_code} ed è disponibile fra i sorgenti allegati alla

 guida nei files \file{SockRead.c} e \file{SockWrite.c}.
 
 \begin{figure}[htb]
 guida nei files \file{SockRead.c} e \file{SockWrite.c}.
 
 \begin{figure}[htb]

diff --git a/system.tex b/system.tex
index 310cd85d9236dbb81af68763d52ab5bdae5a3887..c474854e8924c5c96d5244e898a14fdd93fd7bed 100644 (file)
--- a/system.tex
+++ b/system.tex
@@ -755,7 +755,7 @@ significativi sono un \textit{magic number}\footnote{cio
   riservata al \textit{magic number}.} mentre i 16 meno significativi sono
 usati per specificare le opzioni; essi sono usati come maschera binaria e
 vanno impostati con un OR aritmetico della costante \macro{MS\_MGC\_VAL} con i
   riservata al \textit{magic number}.} mentre i 16 meno significativi sono
 usati per specificare le opzioni; essi sono usati come maschera binaria e
 vanno impostati con un OR aritmetico della costante \macro{MS\_MGC\_VAL} con i

-valori riportati in \ntab.
+valori riportati in \tabref{tab:sys_mount_flags}.

 
 \begin{table}[htb]
   \footnotesize
 
 \begin{table}[htb]
   \footnotesize