From: Simone Piccardi Date: Fri, 11 May 2001 17:11:49 +0000 (+0000) Subject: Usate le nuove macro per le referenze, e trovato un formato sensato per X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=4826742c87d76af810c8a30e5495135fb43b8091;p=gapil.git Usate le nuove macro per le referenze, e trovato un formato sensato per i prototipi delle funzioni --- diff --git a/elemtcp.tex b/elemtcp.tex index 94612fa..d317883 100644 --- a/elemtcp.tex +++ b/elemtcp.tex @@ -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 diff --git a/filedir.tex b/filedir.tex index 6df35b2..ecabab0 100644 --- a/filedir.tex +++ b/filedir.tex @@ -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}). diff --git a/fileintro.tex b/fileintro.tex index c010983..c89f76b 100644 --- a/fileintro.tex +++ b/fileintro.tex @@ -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. diff --git a/intro.tex b/intro.tex index 471eada..a65d72d 100644 --- 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 diff --git a/macro.tex b/macro.tex index 93f3563..2f4ea86 100644 --- 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}} diff --git a/main.tex b/main.tex index 1ab522c..603ed56 100644 --- 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, diff --git a/network.tex b/network.tex index 6da5a49..dc24c66 100644 --- a/network.tex +++ b/network.tex @@ -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 diff --git a/signal.tex b/signal.tex index 054ff44..c5b2282 100644 --- a/signal.tex +++ b/signal.tex @@ -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. diff --git a/socket.tex b/socket.tex index 4d19955..86c0b71 100644 --- a/socket.tex +++ b/socket.tex @@ -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