From cd905cd37ac75847fdbfcc6fb4d2fd094dd808b7 Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Thu, 17 Oct 2002 17:32:52 +0000 Subject: [PATCH] Rimessi a posto tutti i riferimenti a figure e tabelle cancellando delle vecchie macro che non funzionavano bene. --- elemtcp.tex | 111 ++++++++++++++++++++++++++------------------------ fileadv.tex | 17 ++++++-- filedir.tex | 61 ++++++++++++++------------- fileintro.tex | 62 +++++++++++++++------------- fileunix.tex | 12 +++--- gapil.tex | 6 +-- ipprot.tex | 39 +++++++++--------- macro.tex | 21 ---------- network.tex | 38 ++++++++--------- process.tex | 26 ++++++------ prochand.tex | 16 ++++---- simpltcp.tex | 17 ++++---- socket.tex | 5 ++- system.tex | 2 +- 14 files changed, 220 insertions(+), 213 deletions(-) diff --git a/elemtcp.tex b/elemtcp.tex index 964dd4f..6715770 100644 --- 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 -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 @@ -91,11 +91,11 @@ la connessione. \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 @@ -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 -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} @@ -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 -\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 @@ -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 -\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 @@ -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}. -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 @@ -312,18 +313,18 @@ dati rispondono meglio alle esigenze che devono essere affrontate. \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. -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 @@ -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. -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 @@ -469,10 +471,11 @@ in tre intervalli: \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 @@ -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}. -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] @@ -862,16 +865,16 @@ infatti vengono mantenute due code: 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 @@ -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. -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] diff --git a/fileadv.tex b/fileadv.tex index 0d6e2f0..4543962 100644 --- a/fileadv.tex +++ b/fileadv.tex @@ -1315,10 +1315,21 @@ Il comportamento della funzione \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 -\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 diff --git a/filedir.tex b/filedir.tex index 30d71ca..2832634 100644 --- 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 -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 @@ -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 -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 @@ -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 -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 @@ -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} è -riportato in \ntab. +riportato in \tabref{tab:file_type_macro}. \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 -\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 @@ -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 -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 @@ -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 -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 è -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 @@ -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 -\var{st\_mode} sono riportate in \ntab. +\var{st\_mode} sono riportate in \tabref{tab:file_bit_perm}. \begin{table}[htb] \centering diff --git a/fileintro.tex b/fileintro.tex index 359a1e2..794d611 100644 --- 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 -operazioni previste dal kernel è riportato in \ntab. +operazioni previste dal kernel è riportato in +\tabref{tab:file_file_operations}. \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 -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 @@ -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 -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 @@ -562,11 +565,11 @@ esemplificare la situazione con uno schema come quello esposto in \nfig. \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} @@ -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}). - -\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 @@ -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 -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 @@ -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 -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 cec06e3..bd3ed09 100644 --- a/fileunix.tex +++ b/fileunix.tex @@ -138,10 +138,11 @@ posto di questi valori numerici: \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 @@ -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 -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 diff --git a/gapil.tex b/gapil.tex index 3140c28..c37cd34 100644 --- a/gapil.tex +++ b/gapil.tex @@ -21,8 +21,8 @@ \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} % @@ -73,7 +73,7 @@ \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} diff --git a/ipprot.tex b/ipprot.tex index 818abcb..23598b1 100644 --- 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 -mostrato in \ntab. +mostrato in \tabref{tab:IP_ipv6_uninaz}. \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 -è 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 @@ -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 -\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 @@ -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 -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 -\ntab: +\tabref{tab:IP_ipv6_multicast}: \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 - \ntab. + \tabref{tab:IP_ipv6_multiscope}. \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 -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} diff --git a/macro.tex b/macro.tex index afd290c..33640c5 100644 --- a/macro.tex +++ b/macro.tex @@ -8,31 +8,10 @@ % % 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{\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 diff --git a/network.tex b/network.tex index db2cb4d..6f6148e 100644 --- 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 -\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 @@ -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 -\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} @@ -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 -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 -è 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 @@ -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 -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 @@ -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 - 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 diff --git a/process.tex b/process.tex index e5e4b50..9a23884 100644 --- 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 -normalmente un programma è riportato in \nfig. +normalmente un programma è riportato in \figref{fig:proc_prog_start_stop}. \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 -\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 -questo meccanismo è mostrato in \curfig. +questo meccanismo è mostrato in \figref{fig:proc_argv_argc}. \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 -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 @@ -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ù -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 @@ -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 -in \ntab. +in \tabref{tab:proc_env_func}. \begin{table}[htb] \centering @@ -1108,9 +1110,9 @@ in \ntab. \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} diff --git a/prochand.tex b/prochand.tex index af65598..534049e 100644 --- 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 -\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 @@ -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 -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 diff --git a/simpltcp.tex b/simpltcp.tex index b9d99e6..8a6b2ae 100644 --- 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}. -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 diff --git a/socket.tex b/socket.tex index 98a79a6..ef729a5 100644 --- 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 -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] diff --git a/system.tex b/system.tex index 310cd85..c474854 100644 --- 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 -valori riportati in \ntab. +valori riportati in \tabref{tab:sys_mount_flags}. \begin{table}[htb] \footnotesize -- 2.30.2