Usate le nuove macro per le referenze, e trovato un formato sensato per
authorSimone Piccardi <piccardi@gnulinux.it>
Fri, 11 May 2001 17:11:49 +0000 (17:11 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Fri, 11 May 2001 17:11:49 +0000 (17:11 +0000)
i prototipi delle funzioni

elemtcp.tex
filedir.tex
fileintro.tex
intro.tex
macro.tex
main.tex
network.tex
signal.tex
socket.tex

index 94612fa..d317883 100644 (file)
@@ -3,9 +3,10 @@
 
 In questo capitolo inizieremo ad approndire la conoscenza dei socket TCP,
 tratteremo qui dunque il funzionamento delle varie funzioni che si sono usate
-nei due esempi elementari forniti in precedenza (vedi \ref{sec:net_cli_sample}
-e \ref{sec:net_serv_sample}), previa una descrizione delle principali
-caratteristiche del funzionamento di una connessione TCP.
+nei due esempi elementari forniti in precedenza (vedi
+\secref{sec:net_cli_sample} e \secref{sec:net_serv_sample}), previa una
+descrizione delle principali caratteristiche del funzionamento di una
+connessione TCP.
 
 La seconda parte del capitolo sarà poi dedicata alla scrittura di una prima
 semplice applicazione client/server completa, che implementi il servizio
@@ -31,8 +32,8 @@ l'uso del programma \texttt{netstat}.
 Il processo che porta a creare una connessione TCP è chiamato \textit{three
   way handushake}; la successione tipica degli eventi (la stessa che si
 verifica utilizzando il codice dei due precedenti esempi elementari
-\ref{fig:net_cli_code} e \ref{fig:net_serv_code}) che porta alla creazione di
-una connessione è la seguente:
+\figref{fig:net_cli_code} e \figref{fig:net_serv_code}) che porta alla
+creazione di una connessione è la seguente:
  
 \begin{itemize}
 \item Il server deve essere preparato per accettare le connessioni in arrivo;
@@ -55,7 +56,7 @@ una connessione 
     \texttt{SYN}, \texttt{ACK}, \texttt{URG}, \texttt{FIN}, alcuni di essi,
     come \texttt{SYN} (che sta per \textit{sincronize}) corrispondono a
     funzioni particolari del protocollo e danno il nome al segmento, (per
-    maggiori dettagli vedere \ref{cha:tcp_protocol})}, in sostanza viene
+    maggiori dettagli vedere \capref{cha:tcp_protocol})}, in sostanza viene
   inviato al server un pacchetto IP che contiene solo gli header IP e TCP (con
   il numero di sequenza iniziale e il flag \texttt{SYN}) e le opzioni di TCP.
   
@@ -126,7 +127,7 @@ regolare la connessione. Normalmente vengono usate le seguenti opzioni:
   connesione corrente. È possibile leggere e scrivere questo valore attraverso
   l'opzione del socket \texttt{TCP\_MAXSEG}.
   
-\item \textit{window scale option} come spiegato in \ref{cha:tcp_protocol} il
+\item \textit{window scale option} come spiegato in \capref{cha:tcp_protocol} il
   protocollo TCP implementa il controllo di flusso attraverso una
   \textsl{finestra annunciata} (\textit{advertized window}) con la quale
   ciascun capo della comunicazione dichiara quanto spazio disponibile ha in
@@ -164,8 +165,8 @@ elevati. In ogni caso linux supporta pienamente entrambe le opzioni.
 
 Mentre per creare una connessione occorre un interscambio di tre segmenti, la
 procedura di chiusura ne richede quattro; ancora una volta si può fare
-riferimento al codice degli esempi \ref{fig:net_cli_code} e
-\ref{fig:net_serv_code}, in questo caso la successione degli eventi è la
+riferimento al codice degli esempi \figref{fig:net_cli_code} e
+\figref{fig:net_serv_code}, in questo caso la successione degli eventi è la
 seguente:
 
 \begin{enumerate}
@@ -218,17 +219,17 @@ pi
 
 La emissione del FIN avviene quando il socket viene chiuso, questo però non
 avviene solo per la chiamata della funzione \texttt{close} (come in
-\ref{fig:net_serv_code}), ma anche alla terminazione di un processo (come in
-\ref{fig:net_cli_code}). Questo vuol dire ad esempio che se un processo viene
-terminato da un segnale tutte le connessioni aperte verranno chiuse.
+\figref{fig:net_serv_code}), ma anche alla terminazione di un processo (come
+in \figref{fig:net_cli_code}). Questo vuol dire ad esempio che se un processo
+viene terminato da un segnale tutte le connessioni aperte verranno chiuse.
 
 Infine è da sottolineare che, benché nella figura (e nell'esempio che vedremo
-in \ref{sec:TCPel_echo_example}) sia il client ad eseguire la chiusura attiva,
-nella realtà questa può essere eseguita da uno qualunque dei due capi della
-comunicazione (come in fatto in precedenza da \ref{fig:net_serv_code}), e
-benché quello del client sia il caso più comune ci sono alcuni servizi, il
-principale dei quali è l'HTTP, per i quali è il server ad effettuare la
-chiusura attiva.
+in \secref{sec:TCPel_echo_example}) sia il client ad eseguire la chiusura
+attiva, nella realtà questa può essere eseguita da uno qualunque dei due capi
+della comunicazione (come in fatto in precedenza da
+\figref{fig:net_serv_code}), e benché quello del client sia il caso più comune
+ci sono alcuni servizi, il principale dei quali è l'HTTP, per i quali è il
+server ad effettuare la chiusura attiva.
 
 \subsection{Un esempio di connessione}
 \label{sec:TCPel_conn_dia}
@@ -242,7 +243,7 @@ che vengono riportati del comando \texttt{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
-trova in \ref{cha:tcp_protocol}, ma per una trattazione esauriente il miglior
+trova in \capref{cha:tcp_protocol}, ma per una trattazione esauriente il miglior
 riferimento resta (FIXME citare lo Stevens); qui ci limiteremo a descrivere
 brevemente un semplice esempio di connessione e le transizioni che avvengono
 nei due casi appena citati (creazione e terminazione della connessione).
@@ -289,7 +290,7 @@ caso contrario si avrebbe prima l'emissione di un ACK e poi l'invio della
 risposta.
 
 Infine si ha lo scambio dei quattro segmenti che terminano la connessione
-secondo quanto visto in \ref{sec:TCPel_conn_term}; si noti che il capo della
+secondo quanto visto in \secref{sec:TCPel_conn_term}; si noti che il capo della
 connessione che esegue la chiusura attiva entra nello stato
 \textsl{TIME\_WAIT} su cui torneremo fra poco.
 
@@ -329,7 +330,7 @@ La MSL 
 sulla rete; questo tempo è limitato perché ogni pacchetto IP può essere
 ritrasmesso dai router un numero massimo di volte (detto \textit{hop limit}).
 Il numero di ritrasmissioni consentito è indicato dal campo TTL dell'header di
-IP (per maggiori dettagli vedi \ref{sec:appA_xxx}), e viene decrementato ad
+IP (per maggiori dettagli vedi \secref{sec:appA_xxx}), e viene decrementato ad
 ogni passaggio da un router; quando si annulla il pacchetto viene scartato.
 Siccome il numero è ad 8 bit il numero massimo di ``salti'' è di 255, pertanto
 anche se il TTL (da \textit{time to live}) non è propriamente un limite sul
@@ -422,7 +423,7 @@ In un ambiente multitasking in un dato momento pi
 usare sia UDP che TCP, e ci devono poter essere più connessioni in
 contemporanea. Per poter tenere distinte le diverse connessioni entrambi i
 protocolli usano i \textsl{numeri di porta}, che fanno parte, come si può
-vedere in \ref{sec:sock_sa_ipv4} e \ref{sec:sock_sa_ipv6} pure delle strutture
+vedere in \secref{sec:sock_sa_ipv4} e \secref{sec:sock_sa_ipv6} pure delle strutture
 degli indirizzi del socket.
 
 Quando un client contatta un server deve poter identificare con quale dei vari
@@ -508,7 +509,7 @@ campi \textit{Local Address} e \textit{Foreing Address}.
 
 Per capire meglio l'uso delle porte e come vengono utilizzate quando si ha a
 che fare con un'applicazione client/server (come quella che scriveremo in
-\ref{sec:TCPel_echo_example}) esaminaremo cosa accade con le connessioni nel
+\secref{sec:TCPel_echo_example}) esaminaremo cosa accade con le connessioni nel
 caso di un server TCP che deve gestire connessioni multiple.
 
 Se esguiamo un \texttt{netstat} su una macchina di prova (che supponiamo avere
@@ -600,14 +601,14 @@ alla porta 21101 al secondo.
 
 In questa sezione descriveremo in dettaglio le varie funzioni necessarie per
 l'uso dei socket TCP già citate in precedenza (e utilizzate nei due esempi
-\ref{sec:net_cli_sample} e \ref{sec:net_serv_sample}) con l'eccezione della
-funzione \texttt{socket} che è già stata esaminata in dettaglio in
-\ref{sec:sock_socket}.
+\secref{sec:net_cli_sample} e \secref{sec:net_serv_sample}) con l'eccezione
+della funzione \texttt{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 Cap.~\ref{cha:network} si assume che sia il
+con gli esempi elementari del Cap.~\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.
@@ -621,7 +622,7 @@ risponder
 \end{figure}
 
 Useremo questo schema per l'esempio di implementazione del servizio
-\texttt{echo} che illustreremo in \ref{sec:TCPel_echo_example}. 
+\texttt{echo} che illustreremo in \secref{sec:TCPel_echo_example}. 
 
 
 \subsection{La funzione \texttt{bind}}
@@ -642,7 +643,7 @@ Il prototipo della funzione, definito in \texttt{sys/socket.h}, 
   Il primo argomento è un file descriptor ottenuto da una precedente chiamata
   a \texttt{socket}, mentre il secondo e terzo argomento sono rispettivamente
   l'indirizzo (locale) del socket e la dimensione della struttura che lo
-  contiene, secondo quanto già trattato in \ref{sec:sock_sockaddr}.
+  contiene, secondo quanto già trattato in \secref{sec:sock_sockaddr}.
 
   La funzione restituisce zero in caso di successo e -1 per un errore, in caso
   di errore. La variabile \texttt{errno} viene settata secondo i seguenti
@@ -685,7 +686,7 @@ client.
 
 Per specificare un indirizzo generico con IPv4 si usa il valore
 \texttt{INADDR\_ANY}, il cui valore, come visto anche negli esempi precedenti
-è pari a zero, nell'esempio \ref{fig:net_serv_sample} si è usata
+è pari a zero, nell'esempio \figref{fig:net_serv_sample} si è usata
 un'assegnazione immediata del tipo:
 \begin{verbatim}
    serv_add.sin_addr.s_addr = htonl(INADDR_ANY);   /* connect from anywhere */
@@ -724,7 +725,7 @@ connessione con un server TCP, il prototipo della funzione, definito in
   Il primo argomento è un file descriptor ottenuto da una precedente chiamata
   a \texttt{socket}, mentre il secondo e terzo argomento sono rispettivamente
   l'indirizzo e la dimensione della struttura che contiene l'indirizzo del
-  socket, già descritta in \ref{sec:sock_sockaddr}.
+  socket, già descritta in \secref{sec:sock_sockaddr}.
 
   La funzione restituisce zero in caso di successo e -1 per un errore, in caso
   di errore. La variabile \texttt{errno} viene settata secondo i seguenti
@@ -755,8 +756,8 @@ connessione con un server TCP, il prototipo della funzione, definito in
 
 La struttura dell'indirizzo deve essere inizializzata con l'indirizzo IP e il
 numero di porta del server a cui ci si vuole connettere, come mostrato
-nell'esempio \ref{sec:net_cli_sample} usando le funzioni illustrate in
-\ref{sec:sock_addr_func}.
+nell'esempio \secref{sec:net_cli_sample} usando le funzioni illustrate in
+\secref{sec:sock_addr_func}.
 
 Nel caso di socket TCP la funzione \texttt{connect} avvia il three way
 handshake, e ritorna solo quando la connessione è stabilita o si è verificato
@@ -802,7 +803,7 @@ da errori o problemi nella chiamata della funzione sono le seguenti:
 \end{enumerate}
 
 Se si fa riferimento al diagramma degli stati del TCP riportato in
-\ref{fig:appB:tcp_state_diag} la funzione \texttt{connect} porta un socket
+\figref{fig:appB:tcp_state_diag} la funzione \texttt{connect} porta un socket
 dallo stato \texttt{CLOSED} (lo stato iniziale in cui si trova un socket
 appena creato) prima allo stato \texttt{SYN\_SENT} e poi, al ricevimento del
 ACK, nello stato \texttt{ESTABLISHED}. Se invece la connessione fallisce il
index 6df35b2..ecabab0 100644 (file)
@@ -18,12 +18,12 @@ cancellare i files ed esaminare o cambiare i loro attributi.
 \label{sec:filedir_org}
 
 L'organizzazione dei nomi dei file deriva direttamente dall'organizzazione dei
-medesimi nell'albero descritto brevemente in \ref{sec:fileintr_overview}; una
-directory comunque, come già specificato in \ref{sec:fileintr_vfs}, è solo un
-particolare tipo di file che contiene le informazioni che associano un nome al
-contenuto. Per questo, anche se è usuale parlare di ``file in una directory''
-in realtà una directory contiene solo delle etichette per fare riferimento ai
-file stessi.
+medesimi nell'albero descritto brevemente in \secref{sec:fileintr_overview};
+una directory comunque, come già specificato in \secref{sec:fileintr_vfs}, è
+solo un particolare tipo di file che contiene le informazioni che associano un
+nome al contenuto. Per questo, anche se è usuale parlare di ``file in una
+directory'' in realtà una directory contiene solo delle etichette per fare
+riferimento ai file stessi.
 
 I manuale delle librerie del C chiama i nomi contenuti nelle directory
 \textsl{componenti} (in inglese \textit{file name components}), noi li
@@ -53,12 +53,12 @@ permessi devono consentire l'accesso.
 
 Se il pathname comincia per \texttt{/} la ricerca parte dalla directory radice
 del processo; questa, a meno di un \textit{chroot} (su cui torneremo in
-seguito, vedi \ref{sec:proc_chroot}) è la stessa per tutti i processi ed
+seguito, vedi \secref{sec:proc_chroot}) è la stessa per tutti i processi ed
 equivale alla directory radice dell'albero (come descritto in
-\ref{sec:fileintr_overview}): in questo caso si parla di un pathname
+\secref{sec:fileintr_overview}): in questo caso si parla di un pathname
 \textsl{assoluto}. Altrimenti la ricerca parte dalla directory corrente (su
-cui torneremo più avanti in \ref{sec:filedir_work_dir}) ed il pathname è detto
-\textsl{relativo}.
+cui torneremo più avanti in \secref{sec:filedir_work_dir}) ed il pathname è
+detto \textsl{relativo}.
 
 I nomi \texttt{.} e \texttt{..} hanno un significato speciale e vengono
 inseriti in ogni directory, il primo fa riferimento alla directory corrente e
@@ -76,13 +76,13 @@ breve introduzione agli oggetti su cui 
 particolare si riprenderà, approfondendolo sul piano dell'uso nelle funzioni
 di libreria, il concetto di \textit{inode} di cui abbiamo brevemente accennato
 le caratteristiche (dal lato dell'implementazione nel kernel) in
-\ref{sec:fileintr_vfs}.
+\secref{sec:fileintr_vfs}.
 
 
 \subsection{Il funzionamento di un filesystem}
 \label{sec:filedir_filesystem}
 
-Come già accennato in \ref{sec:fileintr_overview} linux (ed ogni unix in
+Come già accennato in \secref{sec:fileintr_overview} linux (ed ogni unix in
 generale) organizza i dati che tiene su disco attraverso l'uso di un
 filesystem. Una delle caratteristiche di linux rispetto agli altri unix è
 quella di poter supportare grazie al VFS una enorme quantità di filesystem
@@ -118,7 +118,7 @@ attenzione in quanto sono fondamentali per capire il funzionamento delle
 funzioni che manipolano i file e le directory su cui torneremo fra poco; in
 particolare è opportuno ricordare sempre che:
 
-\begin{itemize}
+\begin{enumerate}
   
 \item L'\textit{inode} contiene tutte le informazioni riguardanti il file: il
   tipo di file, i permessi di accesso, le dimensioni, i puntatori ai blocchi
@@ -128,7 +128,7 @@ particolare 
   associato, cioè quella che da qui in poi chiameremo una \textsl{voce}
   (traduzione approssimata dell'inglese \textit{directory entry}, che non
   useremo anche per evitare confusione con le \textit{dentries} del kernel di
-  cui si parlava in \ref{sec:fileintr_vfs}).
+  cui si parlava in \secref{sec:fileintr_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
@@ -146,12 +146,12 @@ particolare 
   esistente, con la funzione \texttt{link}) al filesystem corrente.
   
 \item Quando si cambia nome ad un file senza cambiare filesystem il contenuto
-  del file non deve essere spostato, viene semplicemente creata una nuova
-  \textit{dentry} per l'\textit{inode} in questione e rimossa la vecchia
-  (questa è la modalità in cui opera normalmente il comando \texttt{mv}
-  attraverso la funzione \texttt{rename}).
+  del file non deve essere spostato, viene semplicemente creata una nuova voce
+  per l'\textit{inode} in questione e rimossa la vecchia (questa è la modalità
+  in cui opera normalmente il comando \texttt{mv} attraverso la funzione
+  \texttt{rename}).
 
-\end{itemize}
+\end{enumerate}
 
 Infine è bene avere presente che essendo file pure loro, esiste un numero di
 riferimenti anche per le directories; per cui se ad esempio a partire dalla
@@ -191,17 +191,14 @@ suole chiamare questo tipo di associazione un collegamento diretto (o
 \textit{hard link}).  Il prototipo della funzione, definita in
 \texttt{unistd.h}, e le sue caratteritiche principali, come risultano dalla
 man page, sono le seguenti:
-\begin{itemize}
-\item \texttt{int link(const char * oldname, const char * newname)}
-  
+\begin{prototype}{int link(const char * oldname, const char * newname)}
   Crea un nuovo collegamento diretto al file indicato da \texttt{oldname}
   dandogli nome \texttt{newname}.
   
   La funzione restituisce zero in caso di successo e -1 per un errore, in caso
   di errore. La variabile \texttt{errno} viene settata secondo i seguenti
   codici di errore:
-
-  \begin{itemize}
+  \begin{errlist}
   \item \texttt{EXDEV} \texttt{oldname} e \texttt{newname} non sono sullo
     stesso filesystem.
   \item \texttt{EPERM} il filesystem che contiene \texttt{oldname} e
@@ -213,20 +210,20 @@ man page, sono le seguenti:
     già.
   \item \texttt{EMLINK} Ci sono troppi link al file \texttt{oldname} (il
     numero massimo è specificato dalla variabile \texttt{LINK\_MAX}, vedi
-    \ref{sec:xxx_limits}.
+    \secref{sec:xxx_limits}.
   \item \texttt{ENOSPC} La directory in cui si vuole creare il link è piena e
     non può essere ampliata.
   \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
     su un filesystem montato readonly.
-  \end{itemize}
-\end{itemize}
+  \end{errlist}
+\end{prototype}
 
 La creazione di un nuovo collegamento diretto non copia il contenuto del file,
 ma si limita ad aumentare di uno il numero di referenze al file aggiungendo il
 nuovo nome ai precedenti. Si noti che uno stesso file può essere così
 richiamato in diverse directory.
  
-Per quanto dicevamo in \ref{sec:filedir_filesystem} la creazione del
+Per quanto dicevamo in \secref{sec:filedir_filesystem} la creazione del
 collegamento diretto è possibile solo se entrambi i pathname sono nello stesso
 filesytem; inoltre il filesystem deve supportare i collegamenti diretti (non è
 il caso ad esempio del filesystem \texttt{vfat} di windows).
@@ -234,27 +231,24 @@ il caso ad esempio del filesystem \texttt{vfat} di windows).
 La funzione opera sui file ordinari, come sugli altri oggetti del filesystem,
 ma solo l'amministratore è in grado di creare un collegamento diretto ad
 un'altra directory, questo lo si fa perché in questo caso è possibile creare
-dei cerchi nel filesystem (vedi \ref{sec:filedir_symlink}) che molti programmi
+dei cerchi nel filesystem (vedi \secref{sec:filedir_symlink}) che molti programmi
 non sono in grado di gestire e la cui rimozione diventa estremamente
 complicata (in genere occorre far girare il programma \texttt{fsck} per
 riparare il filesystem).
 
 
-La rimozione di un file (o più precisamente di una sua dentry) si effettua con
-la funzione \texttt{unlink}; il suo prototipo, definito in \texttt{unistd.h} è
-il seguente:
+La rimozione di un file (o più precisamente della voce che lo referenzia) si
+effettua con la funzione \texttt{unlink}; il suo prototipo, definito in
+\texttt{unistd.h} è il seguente:
 
-\begin{itemize}
-\item \texttt{int unlink(const char * filename)}
-  
+\begin{prototype}{int unlink(const char * filename)}
   Cancella il nome specificato dal pathname nella relativa directory e
   decrementa il numero di riferimenti nel relativo inode.
   
-  La funzione restituisce zero in caso di successo e -1 per un errore, in caso
-  di errore. La variabile \texttt{errno} viene settata secondo i seguenti
-  codici di errore:
-
-  \begin{itemize}
+  La funzione restituisce zero in caso di successo e -1 per un errore, nel
+  qual caso il file non viene toccato. La variabile \texttt{errno} viene
+  settata secondo i seguenti codici di errore:
+  \begin{errlist}
   \item \texttt{EXDEV} \texttt{oldname} e \texttt{newname} non sono sullo
     stesso filesystem.
   \item \texttt{EPERM} il filesystem che contiene \texttt{oldname} e
@@ -266,27 +260,36 @@ il seguente:
     già.
   \item \texttt{EMLINK} Ci sono troppi link al file \texttt{oldname} (il
     numero massimo è specificato dalla variabile \texttt{LINK\_MAX}, vedi
-    \ref{sec:xxx_limits}.
+    \secref{sec:xxx_limits}.
   \item \texttt{ENOSPC} La directory in cui si vuole creare il link è piena e
     non può essere ampliata.
   \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
     su un filesystem montato readonly.
-  \end{itemize}
-\end{itemize}
-
-Per cancellare 
-
-
-
+  \end{errlist}
+\end{prototype}
 
+Per cancellare una voce in una directory è necessario avere il permesso di
+scrittura su di essa (dato che si va a rimuovere una voce dal suo contenuto) e
+il diritto di esecuzione sulla directory che la contiene (torneremo in
+dettaglio sui permessi e gli attributi fra poco), se inoltre lo
+\textit{sticky} bit è settato occorerà anche essere proprietari del file o
+proprietari della directory (o root, per cui nessuna delle restrizioni è
+applicata).
 
 Una delle caratteristiche di queste funzioni è che la creazione/rimozione
-della nnome dalla directory e l'incremento/decremento del numero di
+della nome dalla directory e l'incremento/decremento del numero di
 riferimenti nell'inode deve essere una operazione atomica (cioè non
 interrompibile da altri) processi, per questo entrambe queste funzioni sono
 realizzate tramite una singola system call.
 
-
+Si ricordi infine che il file non viene eliminato dal disco fintanto che tutti
+i riferimenti ad esso sono stati cancellati, solo quando il \textit{link
+  count} mantenuto nell'inode diventa zero lo spazio occupato viene rimosso. A
+questo però si aggiunge una altra condizione, e cioè che non ci siano processi
+che abbiano detto file aperto. Come accennato questa proprietà viene spesso
+usata per essere sicuri di non lasciare file temporanei su disco in caso di
+crash dei programmi; la tecnica è quella di aprire il file e chiamare
+\texttt{unlink} subito dopo.
 
 
 \subsection{Le funzioni \texttt{remove} e \texttt{rename}}
@@ -296,11 +299,11 @@ realizzate tramite una singola system call.
 \subsection{I link simbolici}
 \label{sec:filedir_sym_link}
 
-Siccome tutto ciò funziona facendo riferimento ad un inode, questa funzione
-può essere applicata soltanto per file che risiedono sullo stesso filesystem,
-(dato che solo in questo caso è garantita l'unicità dell'inode) e solo per
-filesystem di tipo unix. Inoltre in linux non è consentito eseguire un link
-diretto ad una directory.
+Siccome la funzione \texttt{link} crea riferimenti agli inodes, essa può
+funzionare soltanto per file che risiedono sullo stesso filesystem, dato che
+in questo caso è garantita l'unicità dell'inode, e solo per un filesystem di
+tipo unix.  Inoltre in linux non è consentito eseguire un link diretto ad una
+directory se non si è root.
 
 Per ovviare a queste limitazioni i sistemi unix supportano un'altra forma di
 link (i cosiddetti \textit{soft link} o \textit{symbolic link}), che sono,
@@ -322,18 +325,15 @@ riferimento.
 Le funzioni per operare sui link simbolici sono le seguenti, esse sono tutte
 dichiarate nell'header file \texttt{unistd.h}.
 
-\begin{itemize}
-\item \texttt{int symlink(const char * oldname, const char * newname)}
-  
+\begin{prototype}{int symlink(const char * oldname, const char * newname)}
   Crea un nuovo link simbolico al file indicato da \texttt{oldname} dandogli
   nome \texttt{newname}.
   
   La funzione restituisce zero in caso di successo e -1 per un errore, in caso
   di errore. La variabile \texttt{errno} viene settata secondo i codici di
   errore standard di accesso ai files (trattati in dettaglio in
-  \ref{sec:filedir_access_control}) ai quali si aggiungono i seguenti:
-
-  \begin{itemize}
+  \secref{sec:filedir_access_control}) ai quali si aggiungono i seguenti:
+  \begin{errlist}
   \item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
     già.
   \item \texttt{EROFS} La directory su cui si vuole inserire il nuovo link è
@@ -342,8 +342,8 @@ dichiarate nell'header file \texttt{unistd.h}.
     link è piena e non c'è ulteriore spazio disponibile.
   \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione di
     \texttt{oldname} o di \texttt{newname}.
-  \end{itemize}
-\end{itemize}
+  \end{errlist}
+\end{prototype}
 
 
 \subsection{Le funzioni \texttt{mkdir} e \texttt{rmdir}} 
@@ -353,9 +353,7 @@ Per creare una nuova directory si pu
 dell'analogo comando di shell \texttt{mkdir}; per accedere alla funzioni il
 programma deve includere il file \texttt{sys/stat.h}.
 
-\begin{itemize}
-\item \texttt{char * mkdir (const char * dirname, mode\_t mode)}
-  
+\begin{prototype}{char * mkdir (const char * dirname, mode\_t mode)}
   Questa funzione crea una nuova directory vuota con il nome indicato da
   \texttt{dirname}, assegnandole i permessi indicati da \texttt{mode}. Il nome
   può essere indicato con il pathname assoluto o relativo.
@@ -363,8 +361,8 @@ programma deve includere il file \texttt{sys/stat.h}.
   La funzione restituisce zero in caso di successo e -1 per un errore, in caso
   di errore \texttt{errno} viene settata secondo i codici di errore standard
   di accesso ai files (trattati in dettaglio in
-  \ref{sec:filedir_access_control}) ai quali si aggiungono i seguenti:
-  \begin{itemize}
+  \secref{sec:filedir_access_control}) ai quali si aggiungono i seguenti:
+  \begin{errlist}
   \item \texttt{EACCESS} 
     Non c'è il permesso di scrittura per la directory in cui si vuole inserire
     la nuova directory.
@@ -378,8 +376,8 @@ programma deve includere il file \texttt{sys/stat.h}.
     la nuova directory.
   \item \texttt{EROFS} La directory su cui si vuole inserire la nuova
     directory è su un filesystem montato readonly.
-  \end{itemize}
-\end{itemize}
+  \end{errlist}
+\end{prototype}
  
 
 \subsection{Accesso alle directory}
@@ -395,7 +393,7 @@ Per accedere al contenuto delle directory si usano i cosiddetti
 la funzione \texttt{opendir} apre uno di questi stream e la funzione
 \texttt{readdir} legge il contenuto della directory, i cui elementi sono le
 \textit{directory entries} (da distinguersi da quelle della cache di cui
-parlavamo in \ref{sec:fileintr_vfs}) in una opportuna struttura
+parlavamo in \secref{sec:fileintr_vfs}) in una opportuna struttura
 \texttt{struct dirent}.
 
 
@@ -417,9 +415,7 @@ directory corrente di qualunque comando da essa lanciato.
 Le funzioni qui descritte servono esaminare e cambiare la directory di lavoro
 corrente. I prototipi di queste funzioni sono dichiarati in \texttt{unistd.h}. 
 
-\begin{itemize}
-\item \texttt{char * getcwd (char * buffer, size\_t size)}
-  
+\begin{prototype}{char * getcwd (char * buffer, size\_t size)}
   Restituisce il filename completo della directory di lavoro corrente nella
   stringa puntata da \texttt{buffer}, che deve essere precedentemente
   allocata, per una dimensione massima di \texttt{size}. Si può anche
@@ -432,8 +428,7 @@ corrente. I prototipi di queste funzioni sono dichiarati in \texttt{unistd.h}.
   La funzione restituisce il puntatore \texttt{buffer} se riesce,
   \texttt{NULL} se fallisce, in quest'ultimo caso la variabile
   \texttt{errno} è settata con i seguenti codici di errore:
-
-  \begin{itemize}
+  \begin{errlist}
   \item \texttt{EINVAL} L'argomento \texttt{size} è zero e \texttt{buffer} non
     è nullo.
   \item \texttt{ERANGE} L'argomento \texttt{size} è più piccolo della
@@ -441,14 +436,14 @@ corrente. I prototipi di queste funzioni sono dichiarati in \texttt{unistd.h}.
   \item \texttt{EACCES} Manca il permesso di lettura o di ricerca su uno dei
     componenti del pathname (cioè su una delle directory superiori alla
     corrente).
-  \end{itemize}
-\end{itemize}
+  \end{errlist}
+\end{prototype}
 
 Di questa funzione esiste una versione \texttt{char * getwd(char * buffer)}
 fatta per compatibilità all'indietro con BSD, che non consente di specificare
 la dimensione del buffer; esso deve essere allocato in precedenza ed avere una
 dimensione superiore a \texttt{PATH\_MAX} (di solito 256 byters, vedi
-\ref{sec:xxx_limits}; il problema è che in linux non esiste una dimensione
+\secref{sec:xxx_limits}; il problema è che in linux non esiste una dimensione
 superiore per un pathname, per cui non è detto che il buffer sia sufficiente a
 contenere il nome del file, e questa è la ragione principale per cui questa
 funzione è deprecata.
@@ -464,27 +459,22 @@ riferirsi ad esse tramite il file descriptor dell'interfaccia a basso livello,
 e non solo tramite il filename; per questo motivo ci sono due diverse funzioni
 per cambiare directory di lavoro.
 
-\begin{itemize}
-\item \texttt{int chdir (const char * pathname)}
-  
+\begin{prototype}{int chdir (const char * pathname)}
   Come dice il nome (che significa \textit{change directory}) questa funzione
   serve a cambiare la directory di lavoro a quella speficata dal pathname
   contenuto nella stringa \texttt{pathname}.
+\end{prototype}
   
-\item \texttt{int fchdir (int filedes)} analoga alla precedente, ma usa un
-  file descriptor invece del pathname.
-
+\begin{prototype}{int fchdir (int filedes)} 
+  Analoga alla precedente, ma usa un file descriptor invece del pathname.
   
   Entrambe le funzioni restituiscono zero in caso di successo e -1 per un
   errore, in caso di errore \texttt{errno} viene settata secondo i codici di
   errore standard di accesso ai files (trattati in dettaglio in
-  \ref{sec:filedir_access_control}) ai quali si aggiunge il codice
+  \secref{sec:filedir_access_control}) ai quali si aggiunge il codice
   \texttt{ENOTDIR} nel caso il \texttt{filename} indichi un file che non sia
   una directory.
-\end{itemize}
-
-
-
+\end{prototype}
 
 
 
@@ -543,6 +533,6 @@ per cambiare directory di lavoro.
 %La struttura fondamentale che contiene i dati essenziali relativi ai file è il
 %cosiddetto \textit{inode}; questo conterrà informazioni come il
 %tipo di file (file di dispositivo, directory, file di dati, per un elenco
-%completo vedi \ntab), i permessi (vedi \ref{sec:file_perms}), le date (vedi
-%\ref{sec:file_times}).
+%completo vedi \ntab), i permessi (vedi \secref{sec:file_perms}), le date (vedi
+%\secref{sec:file_times}).
 
index c010983..c89f76b 100644 (file)
@@ -26,7 +26,7 @@ Visto il ruolo fondamentale che i files vengono ad assumere in un sistema
 unix, è anzitutto opportuno fornire un'introduzione dettagliata su come essi
 vengono trattati dal sistema. In particolare occorre tenere presente dov'è che
 si situa il limite fondamentale fra kernel space e user space che tracciavamo
-al Cap.~\ref{cha:intro_unix}.
+al \capref{cha:intro_unix}.
 
 Partiamo allora da come viene strutturata nel sistema la disposizione dei
 file: per potervi accedere il kernel usa una apposita interfaccia che permetta
@@ -37,7 +37,7 @@ questo nome al posto della pi
 Sarà attraverso quest'ultimo che il kernel andrà a gestire l'accesso ai dati
 memorizzati all'interno del disco stesso, strutturando l'informazione in files
 e directory (su questo aspetto torneremo con maggiori dettagli in
-\ref{sec:filedir_filesystem}).  Per poter accedere ai file contenuti in un
+\secref{sec:filedir_filesystem}).  Per poter accedere ai file contenuti in un
 disco occorrerà perciò attivare il filesystem, questo viene fatto
 \textsl{montando} il disco (o la partizione del disco).
 
@@ -130,7 +130,7 @@ dentry e una struttura \verb|f_ops| che contiene i puntatori ai 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 \ref{sec:fileunix_fd}). Un elenco delle operazioni
+torneremo in dettaglio in \secref{sec:fileunix_fd}). Un elenco delle operazioni
 previste dal kernel è riportato in \ntab.
 
 \begin{table}[htb]
@@ -177,7 +177,7 @@ diversi filesystem (come quelli usati da Windows o MacOs) 
 In unix è implementata da qualunque filesystem standard una forma elementare
 (ma adatta alla maggior parte delle esigenze) di controllo di accesso ai
 files. Torneremo sull'argomento in dettaglio più avanti (vedi
-\ref{sec:filedir_access_control}), qui ci limitiamo ad una introduzione dei
+\secref{sec:filedir_access_control}), qui ci limitiamo ad una introduzione dei
 concetti essenziali.
 
 Si tenga conto poi che quanto diremo è vero solo per filesystem di tipo Unix,
@@ -188,7 +188,7 @@ di controllo di accesso molto pi
 
 Ad ogni file Unix associa sempre l'utente che ne è proprietario (il cosiddetto
 \textit{owner}) e il gruppo di appartenenza, secondo il meccanismo degli uid e
-gid accennato in Sez.~\ref{sec:intro_usergroup}, e un insieme di permessi che
+gid accennato in \secref{sec:intro_usergroup}, e un insieme di permessi che
 sono divisi in tre classi, e cioè attribuiti rispettivamente al proprietario,
 a qualunque utente faccia parte del gruppo cui appartiene il file, e a tutti
 gli altri utenti.
@@ -198,10 +198,10 @@ significativi sono usati a gruppi di tre per indicare i permessi base di
 lettura, scrittura ed esecuzione (indicati rispettivamente con le lettere
 \textit{w}, \textit{r} \textit{x}) applicabili rispettivamente al
 proprietario, al gruppo, a tutti (una descrizione più dettagliata dei vari
-permessi associati ai file è riportata in \ref{sec:filedir_suid_sgid}).  I
+permessi associati ai file è riportata in \secref{sec:filedir_suid_sgid}).  I
 restanti tre bit sono usati per indicare alcune caratteristiche più complesse
 (\textit{suid}, \textit{sgid}, e \textit{sticky}) su cui pure torneremo in
-seguito (vedi \ref{sec:filedir_suid_sgid} e \ref{sec:filedir_stiky}).
+seguito (vedi \secref{sec:filedir_suid_sgid} e \secref{sec:filedir_stiky}).
 
 Tutte queste informazioni sono tenute per ciascun file nell'inode. Quando un
 processo cerca l'accesso al file esso controlla i propri uid e gid
@@ -213,7 +213,7 @@ pertanto accesso senza restrizione a qualunque file del sistema.
 
 In realtà il procedimento è più complesso di quanto descritto in maniera
 elementare qui; inoltre ad un processo sono associati diversi identificatori,
-torneremo su questo in maggiori dettagli in seguito in \ref{sec:proc_perms}.
+torneremo su questo in maggiori dettagli in seguito in \secref{sec:proc_perms}.
 
 \subsection{I tipi di files}
 \label{sec:fileintr_file_types}
@@ -310,7 +310,7 @@ operazioni di controllo sul particolare tipo di oggetto del VFS scelto occorre
 usare l'interfaccia standard di unix coi file descriptors. Allo stesso modo
 devono essere usati i file descriptor se si vuole ricorrere a modalità
 speciali di I/O come il polling o il non-bloccante (vedi
-\ref{sec:file_bohhhhh}).
+\secref{sec:file_bohhhhh}).
 
 Gli stream forniscono un'interfaccia di alto livello costruita sopra quella
 dei file descriptor, che tratta tutti i file nello stesso modo, con
@@ -370,11 +370,11 @@ Si tenga conto inoltre che un'altro dei dati contenuti nella struttura di
 accesso è un riferimento all'inode del file, pertanto anche se il file viene
 cancellato da un altro processo, sarà sempre possibile mantenere l'accesso ai
 dati, e lo spazio su disco non verrà rilasciato fintanto che il file non sarà
-chiuso e l'ultimo riferimento cancellato. È pertanto possibile (e pratica
-comune) aprire un file provvisorio per cancellarlo immediatamente dopo; in
-questo modo all'uscita del programma il file scomparirà definitivamente dal
-disco, ma il file ed il suo contenuto saranno disponibili per tutto il tempo
-in cui il processo è attivo.
+chiuso e l'ultimo riferimento cancellato. È pertanto possibile (come vedremo
+in dettaglio in \secref{sec:filedir_link}) aprire un file provvisorio per
+cancellarlo immediatamente dopo; in questo modo all'uscita del programma il
+file scomparirà definitivamente dal disco, ma il file ed il suo contenuto
+saranno disponibili per tutto il tempo in cui il processo è attivo.
 
 Ritorneremo su questo più avanti, quando tratteremo l'input/output sui file,
 esaminando in dettaglio come tutto ciò viene realizzato.
index 471eada..a65d72d 100644 (file)
--- a/intro.tex
+++ b/intro.tex
@@ -44,7 +44,7 @@ o alle porte di input/output).
 
 Una parte del kernel, lo \textit{scheduler}, si occupa di stabilire, ad
 intervalli fissi e sulla base di un opportuno calcolo delle priorità, quale
-``processo'' (vedi Cap.~\ref{cha:process}) deve essere posto in esecuzione (il
+``processo'' (vedi \capref{cha:process}) deve essere posto in esecuzione (il
 cosidetto \textit{prehemptive scheduling}), e questo verrà comunque eseguito
 in modelità protetta; quando necessario il processo potrà accedere alle
 risorse hardware soltanto attraverso delle opportune chiamate al sistema
@@ -60,7 +60,7 @@ necessario le pagine di memoria in eccedenza.
 
 Le periferiche infine vengono viste in genere attraverso un'interfaccia
 astratta che permette di trattarle come fossero file. secondo il concetto per
-cui \textit{everything is a file}, vedi Cap.~\ref{cha:files_intro}, (questo
+cui \textit{everything is a file}, vedi \capref{cha:files_intro}, (questo
 non è vero per le interfacce di rete, ma resta valido il concetto generale che
 tutto il lavoro di accesso e gestione a basso livello è effettuato dal
 kernel), mentre ai programmi vengono fornite solo delle routine di
@@ -77,7 +77,7 @@ l'ambiente in cui vengono eseguiti i programmi, e il \textit{kernel space} che
 é l'ambiente in cui viene eseguito il kernel. Ogni programma gira come se
 avesse la piena disponibilità della macchina e della memoria ed è, salvo i
 meccanismi di comunicazione previsti dall'architettura (che esamineremo nel
-Cap.~\ref{cha:IPC}) completamente ignaro del fatto che altri programmi possono
+\capref{cha:IPC}) completamente ignaro del fatto che altri programmi possono
 essere messi in esecuzione dal kernel.
 
 In questo non è possibile ad un singolo programma disturbare l'azione di un
@@ -193,7 +193,7 @@ In questo modo il sistema 
 dell'utente a cui appartiene ed impedire ad altri utenti di interferire con
 esso. Inoltre con questo sistema viene anche garantita una forma base di
 sicurezza interna in quanto anche l'accesso ai file (vedi
-Sez.~\ref{sec:fileintr_access_ctrl}) è regolato da questo meccanismo di
+\secref{sec:fileintr_access_ctrl}) è regolato da questo meccanismo di
 identificazione.
 
 Un utente speciale del sistema è \textit{root}, il cui uid è zero. Esso
index 93f3563..2f4ea86 100644 (file)
--- a/macro.tex
+++ b/macro.tex
@@ -56,13 +56,24 @@ tab.~\thechapter.\theusercount}
 % Command for section and chapters
 %
 \newcommand{\capref}[1]{cap.~\ref{#1}}
-\newcommand{\sezref}[1]{sez.~\ref{#1}}
-
+\newcommand{\secref}[1]{sez.~\ref{#1}}
 %
 % Macro to create a special environment for function prototypes
 %
-\newenvironment{prototype}[1]{\begin{itemize} 
-  \item \texttt{#1}}{\end{itemize}}
-\newenvironment{errlist}{\begin{itemize}}{\end{itemize}}
+\newenvironment{prototype}[1]{
+  \center
+  \begin{minipage}[c]{14cm}
+  \par \texttt{#1}
+   \footnotesize
+  \begin{list}{}{} 
+    \item }
+{ \end{list} 
+  \par 
+\normalsize 
+\par \texttt{ }
+\end{minipage} 
+\par
+}
+\newenvironment{errlist}{\begin{description}}{\end{description}}
 
 
index 1ab522c..603ed56 100644 (file)
--- a/main.tex
+++ b/main.tex
@@ -1,6 +1,6 @@
-%%
+%% 
 %% GaPiL : Guida alla Programmazione in Linux
-%%
+%% 
 %% S. Piccardi Feb. 2001
 %%
 %% main.tex: file principale, gli altri vanno inclusi da questo.
@@ -21,7 +21,7 @@
 \usepackage{color} 
 %
 % Setting page layout
-%
+% 
 \oddsidemargin=0.5cm
 \evensidemargin=-0.5cm
 \textwidth=16cm
@@ -59,6 +59,7 @@
       A copy of the license is included in the section entitled ``GNU
       Free Documentation License''.
 
+
 \end{quote}
 \clearemptydoublepage
 
@@ -75,7 +76,6 @@
 
 \pagenumbering{arabic}
 
-
 \lstset{language=C++} 
 
 \lstset{basicstyle=\small,
index 6da5a49..dc24c66 100644 (file)
@@ -2,15 +2,15 @@
 \label{cha:network}
 
 In questo capitolo sarà fatta un'introduzione ai contetti generali che servono
-come prerequisiti per capire la programmazione di rete, partiremo con due
-semplici esempi per poi passare ad un esame a grandi linee dei protocolli di
-rete e di come questi sono organizzati e interagiscono.
+come prerequisiti per capire la programmazione di rete, per evitare un
+capitolo puramente teorico partiremo con due semplici esempi per poi passare
+ad un esame a grandi linee dei protocolli di rete e di come questi sono
+organizzati e interagiscono.
 
 In particolare, avendo assunto l'ottica di un'introduzione mirata alla
-programmazione, ci concentreremo sul protocollo più diffuso, TCP/IP, che è
-quello che sta alla base di internet, ed in particolare prenderemo in esame in
-questa introduzione i concetti più importanti da conoscere ai fini della
-programmazione.
+programmazione, ci concentreremo sul protocollo più diffuso, il TCP/IP, che è
+quello che sta alla base di internet, con un'ottica improntata a sottolineare
+i concetti più importanti da conoscere ai fini della programmazione.
 
 \section{Il modello client-server}
 \label{sec:net_cliserv}
@@ -35,18 +35,18 @@ generale anche per programmi che non fanno necessariamente uso della rete,
 come il sistema a finestre.
 
 Normalmente si dividono i server in due categorie principali, e vengono detti
-\textit{concorrenti} o \textit{iterativi}, sulla base del loro comportamento.
+\textsl{concorrenti} o \textsl{iterativi}, sulla base del loro comportamento.
 
-Un server iterativo risponde alla richiesta inviando i dati e resta occupato
-(non rispondendo ad ulteriori richieste) fintanto che non ha concluso la
-richiesta. Una volta completata la richiesta il server diventa di nuovo
+Un \textsl{server iterativo} risponde alla richiesta inviando i dati e resta
+occupato (non rispondendo ad ulteriori richieste) fintanto che non ha concluso
+la richiesta. Una volta completata la richiesta il server diventa di nuovo
 disponibile.
 
-Un server concorrente al momento di trattare la richiesta crea un processo
-figlio incaricato di fornire i servizi richiesti, per poi porsi in attesa di
-ulteriori richieste. In questo modo più richieste possono essere soddisfatte
-contemporaneamente; una volta che il processo figlio ha concluso il suo lavoro
-viene terminato, mentre il server originale resta sempre attivo.
+Un \textsl{server concorrente} al momento di trattare la richiesta crea un
+processo figlio incaricato di fornire i servizi richiesti, per poi porsi in
+attesa di ulteriori richieste. In questo modo più richieste possono essere
+soddisfatte contemporaneamente; una volta che il processo figlio ha concluso
+il suo lavoro viene terminato, mentre il server originale resta sempre attivo.
 
 
 \subsection{Un primo esempio di client}
@@ -130,7 +130,7 @@ Il programma anzitutto include gli header necessari (\texttt{\small 1--5});
 dopo la dichiarazione delle variabili (\texttt{\small 9--12}) si è omessa
 tutta la parte relativa al trattamento degli argomenti passati dalla linea di
 comando (effettuata con le apposite routines illustrate in
-\ref{cha:parameter_options}).
+\capref{cha:parameter_options}).
 
 Il primo passo (\texttt{\small 14--18}) è creare un \textit{socket} IPv4
 (\texttt{AF\_INET}), di tipo TCP \texttt{SOCK\_STREAM} (in sostanza un canale
@@ -369,7 +369,7 @@ Cos
 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
-\ref{sec:intro_unix_struct}.
+\secref{sec:intro_unix_struct}.
 
 \begin{table}[htb]
   \centering
@@ -397,7 +397,7 @@ compongono, il TCP \textit{Trasmission Control Protocol} e l'IP
 \begin{description}
 \item \textbf{Applicazione} É relativo ai programmi di interfaccia utente, in
   genere questi vengono realizzati secondo il modello Client-Server (vedi
-  \ref{sec:net_cliserv}.
+  \secref{sec:net_cliserv}.
 \item \textbf{Trasporto} Fornisce la comunicazione tra le due stazioni
   terminali su cui girano gli applicativi, regola il flusso delle
   informazioni, e può fornire un trasporto affidabile, cioè con recupero
@@ -559,7 +559,7 @@ I vari protocolli mostrati in figura sono i seguenti:
   da ICMPv6.
 \item \textsl{ICMP} \textit{Internet Group Management Protocol}. É un
   protocollo usato per il \textit{multicasting} (vedi
-  \ref{sec:xxx_multicast}), che è opzionale in IPv4.
+  \secref{sec:xxx_multicast}), che è opzionale in IPv4.
 \item \textsl{ARP} \textit{Address Resolution Protocol}. È il protocollo che
   mappa un indirizzo IP in un indirizzo hardware (come un indirizzo
   internet). È usato in reti di tipo broadcast come ethernet, token ring o
@@ -636,22 +636,22 @@ grandi linee nei seguenti punti:
 \end{itemize}
 
 Maggiori dettagli riguardo a caratteristiche, notazioni e funzionamento del
-protocollo IP sono forniti nell'appendice \ref{cha:ip_protocol}.
+protocollo IP sono forniti nell'appendice \capref{cha:ip_protocol}.
 
  
 \subsection{UDP: User Datagram Protocol)}
 \label{sec:net_udp}
 
 UDP è un protocollo di trasporto molto semplice, la sua descizione completa è
-contenuta dell'RFC~768, ma in sostanza esso è una semplice interfaccia a IP dal
-livello di trasporto. Quando un'applicazione usa UDP essa scrive un pacchetto
-di dati (il cosiddetto \textit{datagram} che da il nome al protocollo) su un
-socket, al pacchetto viene aggiunto un header molto semplice (per una
-descrizione più accurata vedi \ref{sec:appA_udp}), e poi viene passato al
-livello superiore (IPv4 o IPv6 che sia) che lo spedisce verso la destinazione.
-Dato che né IPv4 né IPv6 garantiscono l'affidabilità niente assicura che il
-pacchetto arrivi a destinazione, né che più pacchetti arrivino nello stesso
-ordine in cui sono stati spediti.
+contenuta dell'RFC~768, ma in sostanza esso è una semplice interfaccia a IP
+dal livello di trasporto. Quando un'applicazione usa UDP essa scrive un
+pacchetto di dati (il cosiddetto \textit{datagram} che da il nome al
+protocollo) su un socket, al pacchetto viene aggiunto un header molto semplice
+(per una descrizione più accurata vedi \secref{sec:appA_udp}), e poi viene
+passato al livello superiore (IPv4 o IPv6 che sia) che lo spedisce verso la
+destinazione.  Dato che né IPv4 né IPv6 garantiscono l'affidabilità niente
+assicura che il pacchetto arrivi a destinazione, né che più pacchetti arrivino
+nello stesso ordine in cui sono stati spediti.
 
 Pertanto il problema principale che si affronta quando si usa UDP è la
 mancanza di affidabilità, se si vuole essere sicuri che i pacchetti arrivino a
@@ -746,7 +746,7 @@ controllo di flusso e della gestione della sequenzialit
 effettuato per entrambe le direzioni di comunicazione.
 
 Una descrizione più accurata del protocollo è fornita in appendice
-\ref{cha:tcp_protocol}.
+\capref{cha:tcp_protocol}.
 
 \subsection{Limiti e dimensioni riguardanti la trasmissione dei dati}
 \label{sec:net_lim_dim}
@@ -763,7 +763,7 @@ loro origini ed alle eventuali implicazioni che possono avere:
 \item La dimensione massima di un pacchetti IP è di 65535 bytes, compreso
   l'header. Questo è dovuto al fatto che la dimensione è indicata da un campo
   apposito nell'header di IP che è lungo 16 bit (vedi
-  \ref{sec:appA_ipv4head}).
+  \secref{sec:appA_ipv4head}).
 \item La dimensione massima di un pacchetto normale di IPv6 è di 65575 bytes,
   il campo apposito nell'header infatti è sempre a 16 bit, ma la dimensione
   dell'header è fissa e di 40 byte e non è compresa nel valore indicato dal
@@ -797,8 +797,8 @@ dimensioni eccedono la MTU viene eseguita la cosiddetta
 \textit{frammentazione}, i pacchetti cioè vengono spezzati (sia da IPv4 che da
 IPv6, anche se i pacchetti frammentati sono gestiti con modalità
 diverse\footnote{il primo usa un flag nell'header, il secondo una opportuna
-  opzione, si veda \ref{cha:ip_protcol}}), in blocchi più piccoli che possono
-essere trasmessi attraverso l'interfaccia.
+  opzione, si veda \secref{cha:ip_protcol}}), in blocchi più piccoli che
+possono essere trasmessi attraverso l'interfaccia.
 
 La MTU più piccola fra due stazioni viene in genere chiamata \textit{path
   MTU}, che dice qual'è la lunghezza massima oltre la quale un pacchetto
index 054ff44..c5b2282 100644 (file)
@@ -159,7 +159,7 @@ diversa azione per lo stesso segnale.
 
 Se arriva un segnale per il quale non è stato specificata un'azione viene
 utilizzata l'azione standard. Questa è diversa da segnale a segnale (come
-vedremo in \ref{sec:sig_standard}) ma per la maggior parte essa comporta la
+vedremo in \secref{sec:sig_standard}) ma per la maggior parte essa comporta la
 terminazione del processo, per alcuni che invece rappresentano eventi innocui
 l'azione standard è di non fare nulla.
 
index 4d19955..86c0b71 100644 (file)
@@ -6,8 +6,8 @@ principali meccanismi di comunicazione fra programmi utilizzato in ambito unix
 (e non solo). Il socket costituisce in sostanza un canale di comunicazione fra
 due processi su cui si possono leggere e scrivere dati analogo a quello di una
 pipe ma a differenza di questa e degli altri meccanismi esaminati nel capitolo
-\ref{cha:IPC} i socket non sono limitati alla comunicazione fra processi che
-girano sulla stessa macchina ma possono effettuare la comunicazione anche
+\capref{cha:IPC} i socket non sono limitati alla comunicazione fra processi
+che girano sulla stessa macchina ma possono effettuare la comunicazione anche
 attraverso la rete.
 
 Quella dei socket costituisce infatti la principale API (\textit{Application
@@ -29,8 +29,8 @@ tratteremo in maniera pi
 \label{sec:sock_gen}
 
 Per capire il funzionamento dei socket occorre avere presente il funzionamento
-dei protocolli di rete (vedi \ref{cha:network}), ma l'interfaccia è del tutto
-generale e benché le problematiche (e quindi le modalità di risolvere i
+dei protocolli di rete (vedi \capref{cha:network}), ma l'interfaccia è del
+tutto generale e benché le problematiche (e quindi le modalità di risolvere i
 problemi) siano diverse a seconda del tipo di protocollo di comunicazione
 usato, le funzioni da usare restano le stesse.
 
@@ -77,10 +77,10 @@ verificare!]).
 
 Il prototipo della funzione è definito nell'header \texttt{sys/socket.h}, la
 funzione prende tre parametri, il dominio del socket (che definisce la
-famiglia di protocolli, vedi \ref{sec:sock_domain}), il tipo di socket (che
-definisce lo stile di comunicazione vedi \ref{sec:sock_type}) e il protocollo;
-in genere quest'ultimo è indicato implicitamente dal tipo di socket, per cui
-viene messo a zero (con l'eccezione dei \textit{raw socket}).
+famiglia di protocolli, vedi \secref{sec:sock_domain}), il tipo di socket (che
+definisce lo stile di comunicazione vedi \secref{sec:sock_type}) e il
+protocollo; in genere quest'ultimo è indicato implicitamente dal tipo di
+socket, per cui viene messo a zero (con l'eccezione dei \textit{raw socket}).
 
 \begin{itemize}
 \item \texttt{int socket(int domain, int type, int protocol)}
@@ -371,11 +371,11 @@ RAW che accedono direttamente al livello di IP, nel qual caso il numero della
 porta viene settato al numero di protocollo.
 
 Il membro \texttt{sin\_family} deve essere sempre settato; \texttt{sin\_port}
-specifica il numero di porta (vedi \ref{sec:TCPel_port_num}; i numeri di porta
-sotto il 1024 sono chiamati \textsl{riservati} in quanto utilizzati da servizi
-standard. Soltanto processi con i privilegi di root (effective uid uguale a
-zero) o con la capability \texttt{CAP\_NET\_BIND\_SERVICE} possono usare la
-funzione \texttt{bind} su queste porte.
+specifica il numero di porta (vedi \secref{sec:TCPel_port_num}; i numeri di
+porta sotto il 1024 sono chiamati \textsl{riservati} in quanto utilizzati da
+servizi standard. Soltanto processi con i privilegi di root (effective uid
+uguale a zero) o con la capability \texttt{CAP\_NET\_BIND\_SERVICE} possono
+usare la funzione \texttt{bind} su queste porte.
 
 Il membro \texttt{sin\_addr} contiene l'indirizzo internet dell'altro capo
 della comunicazione, e viene acceduto sia come struttura (un resto di una
@@ -386,7 +386,7 @@ Infine 
 essere specificati in quello che viene chiamato \textit{network order}, cioè
 con i bit ordinati in formato \textit{big endian}, questo comporta la
 necessità di usare apposite funzioni di conversione per mantenere la
-portabilità del codice (vedi \ref{sec:sock_addr_func} per i dettagli del
+portabilità del codice (vedi \secref{sec:sock_addr_func} per i dettagli del
 problema e le relative soluzioni).
 
 \subsection{La struttura degli indirizzi IPv6}
@@ -423,7 +423,7 @@ segue le stesse regole; il campo \texttt{sin6\_flowinfo} 
 in tre parti di cui i 24 bit inferiori indicano l'etichetta di flusso, i
 successivi 4 bit la priorità e gli ultimi 4 sono riservati; questi valori
 fanno riferimento ad alcuni campi specifici dell'header dei pacchetti IPv6
-(vedi \ref{sec:appA_ipv6}) ed il loro uso è sperimentale.
+(vedi \secref{sec:appA_ipv6}) ed il loro uso è sperimentale.
 
 Il campo \texttt{sin6\_addr} contiene l'indirizzo a 128 bit usato da IPv6,
 infine il campo \texttt{sin6\_scope\_id} è un campo introdotto con il kernel