From c00fca809a709ea67ab3dfdede3a83ead0a9fcaf Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Sat, 10 Aug 2002 15:54:36 +0000 Subject: [PATCH] Correzioni varie di poco conto --- elemtcp.tex | 12 ++--- errors.tex | 3 +- filedir.tex | 10 ++-- filestd.tex | 6 +-- fileunix.tex | 14 +++--- gapil.tex | 6 +-- img/ipv6_head.dia | Bin 1577 -> 1501 bytes ipprot.tex | 125 +++++++++++++++++++--------------------------- pref.tex | 13 ++--- process.tex | 2 +- signal.tex | 12 ++--- socket.tex | 89 ++++++++++++++++++--------------- system.tex | 9 ++-- 13 files changed, 145 insertions(+), 156 deletions(-) diff --git a/elemtcp.tex b/elemtcp.tex index 1678559..964dd4f 100644 --- a/elemtcp.tex +++ b/elemtcp.tex @@ -823,7 +823,7 @@ sostanza l'effetto della funzione \texttt{CLOSED} a quello \texttt{LISTEN}. In genere si chiama la funzione in un server dopo le chiamate a \func{socket} e \func{bind} e prima della chiamata ad \func{accept}. Il prototipo della funzione come definito dalla -man page è: +pagina di manuale è: \begin{prototype}{sys/socket.h}{int listen(int sockfd, int backlog)} La funzione pone il socket specificato da \var{sockfd} in modalità passiva e predispone una coda per le connessioni in arrivo di lunghezza pari @@ -1262,11 +1262,11 @@ connesso (\cmd{inetd} ad esempio fa sempre in modo che i file descriptor 0, 1 e 2 corrispondano al socket connesso) quest'ultimo potrà usare la funzione \func{getpeername} per determinare l'indirizzo remoto del client. -Infine è da chiarire (si legga la man page) che come per \func{accept} il -terzo parametro che è specificato dallo standard POSIX 1003.1g come di tipo -\code{socklen\_t *} in realtà deve sempre corrispondere ad un \ctyp{int *} -come prima dello standard perché tutte le implementazioni dei socket BSD fanno -questa assunzione. +Infine è da chiarire (si legga la pagina di manuale) che, come per +\func{accept}, il terzo parametro, che è specificato dallo standard POSIX.1g +come di tipo \code{socklen\_t *} in realtà deve sempre corrispondere ad un +\ctyp{int *} come prima dello standard perché tutte le implementazioni dei +socket BSD fanno questa assunzione. diff --git a/errors.tex b/errors.tex index 547bb1c..a75e0e1 100644 --- a/errors.tex +++ b/errors.tex @@ -73,7 +73,8 @@ gestione dei file. \item \macro{EMFILE} \textit{Too many open files}. Il processo corrente ha troppi file aperti e non può aprirne altri. Anche i descrittori duplicati vengono tenuti in conto\footnote{Il numero massimo di file aperti è - controllabile dal sistema, in Linux si può usare il comando \cmd{ulimit}}. + controllabile dal sistema, in Linux si può usare il comando + \cmd{ulimit}.}. \item \macro{ENFILE} \textit{File table overflow}. Ci sono troppi file aperti nel sistema. \item \macro{ENOTTY} \textit{Not a terminal}. Si è tentata una operazione di diff --git a/filedir.tex b/filedir.tex index d1d8606..b734c44 100644 --- a/filedir.tex +++ b/filedir.tex @@ -53,7 +53,7 @@ rispetto agli altri. Per aggiungere un nome ad un inode si utilizza la funzione \func{link}; si suole chiamare questo tipo di associazione un collegamento diretto (o \textit{hard link}). Il prototipo della funzione e le sue caratteristiche -principali, come risultano dalla man page, sono le seguenti: +principali, come risultano dalla pagina di manuale, sono le seguenti: \begin{prototype}{unistd.h} {int link(const char *oldpath, const char *newpath)} Crea un nuovo collegamento diretto al file indicato da \var{oldpath} @@ -920,10 +920,10 @@ su un file, su un link simbolico e su un file descriptor. La struttura \var{stat} usata da queste funzioni è definita nell'header \file{sys/stat.h} e in generale dipende dall'implementazione, la versione -usata da Linux è mostrata in \nfig, così come riportata dalla man page di -\func{stat} (in realtà la definizione effettivamente usata nel kernel dipende -dall'architettura e ha altri campi riservati per estensioni come tempi più -precisi, o per il padding dei campi). +usata da Linux è mostrata in \nfig, così come riportata dalla pagina di +manuale di \func{stat} (in realtà la definizione effettivamente usata nel +kernel dipende dall'architettura e ha altri campi riservati per estensioni +come tempi più precisi, o per il padding dei campi). \begin{figure}[!htb] \footnotesize diff --git a/filestd.tex b/filestd.tex index 921f082..a3e719f 100644 --- a/filestd.tex +++ b/filestd.tex @@ -1056,8 +1056,8 @@ questo ordine: \end{itemize*} -Dettagli ulteriori sulle varie opzioni possono essere trovati nella man page -di \func{printf} e nella documentazione delle \acr{glibc}. +Dettagli ulteriori sulle varie opzioni possono essere trovati nella pagina di +manuale di \func{printf} e nella documentazione delle \acr{glibc}. \begin{table}[htb] \centering @@ -1204,7 +1204,7 @@ spazio in \param{format} corrisponde con un numero qualunque di caratteri di separazione (che possono essere spazi, tabulatori, virgole etc.), mentre caratteri diversi richiedono una corrispondenza esatta. Le direttive di conversione sono analoghe a quelle di \func{printf} e si trovano descritte in -dettaglio nelle man page e nel manuale delle \acr{glibc}. +dettaglio nelle pagine di manuale e nel manuale delle \acr{glibc}. Le funzioni eseguono la lettura dall'input, scartano i separatori (e gli eventuali caratteri diversi indicati dalla stringa di formato) effettuando le diff --git a/fileunix.tex b/fileunix.tex index d430199..c83cc73 100644 --- a/fileunix.tex +++ b/fileunix.tex @@ -292,10 +292,10 @@ sempre il file descriptor con il valore pi \label{tab:file_open_flags} \end{table} -\footnotetext[2]{la man page di \func{open} segnala che questa opzione è - difettosa su NFS, e che i programmi che la usano per stabilire un file di - lock possono incorrere in una race condition\index{race condition}. Si - consiglia come alternativa di usare un file con un nome univoco e la +\footnotetext[2]{la pagina di manuale di \func{open} segnala che questa + opzione è difettosa su NFS, e che i programmi che la usano per stabilire un + file di lock possono incorrere in una race condition\index{race condition}. + Si consiglia come alternativa di usare un file con un nome univoco e la funzione \func{link} per verificarne l'esistenza.} \footnotetext[3]{\textit{Denial of Service}, si chiamano così attacchi miranti @@ -1002,9 +1002,9 @@ valori di \tabref{tab:file_open_flags}). \item[\macro{F\_SETFL}] imposta il \textit{file status flag} al valore specificato da \param{arg}, possono essere impostati solo i bit riportati - nella terza sezione di \tabref{tab:file_open_flags}.\footnote{la man page - riporta come impostabili solo \macro{O\_APPEND}, \macro{O\_NONBLOCK} e - \macro{O\_ASYNC}.} + nella terza sezione di \tabref{tab:file_open_flags}.\footnote{la pagina di + manuale riporta come impostabili solo \macro{O\_APPEND}, + \macro{O\_NONBLOCK} e \macro{O\_ASYNC}.} \item[\macro{F\_GETLK}] se un file lock è attivo restituisce nella struttura \param{lock} la struttura \type{flock} che impedisce l'acquisizione del blocco, altrimenti imposta il campo \var{l\_type} a \macro{F\_UNLCK} (per i diff --git a/gapil.tex b/gapil.tex index 6392012..be7b703 100644 --- a/gapil.tex +++ b/gapil.tex @@ -21,8 +21,8 @@ \usepackage{listings} \lstloadlanguages{C++} \usepackage{color} -%\usepackage{mdwlist} % scommentare per la stampa (PS e PDF) -%\usepackage{boxedminipage} % scommentare per la stampa (PS e PDF) +\usepackage{mdwlist} % scommentare per la stampa (PS e PDF) +\usepackage{boxedminipage} % scommentare per la stampa (PS e PDF) %\usepackage{footnote} %\usepackage{mdwtab} % @@ -73,7 +73,7 @@ \tableofcontents \clearemptydoublepage -\include{compatib} % commentare per la stampa PS e PDF +%\include{compatib} % commentare per la stampa PS e PDF \include{macro} \setcounter{secnumdepth}{-2} \include{pref} diff --git a/img/ipv6_head.dia b/img/ipv6_head.dia index 47bc364bb5ce6f425669c29a0eb8375f1c9d8dc9..2d2e75f9ab371dd0c484262554340d7c1dfbda91 100644 GIT binary patch literal 1501 zcmV<31tR(%iwFP!000001MOVfZsRr(ea}}2&dU}^XpxjCX|v9vTcALJ0xjC~IiM}Z zW-E&ZMd$X=Z!aY)zTYC6LcC=F2a&+c5viGTW=531e0?5g-XoI*7kRG(f#301J`gF- zhrP~UcRydpov*hSUs6s#>(5Zqv8VqdFUq4{XQb5RbGQ5S^aQe(f+`_F#;2fQ-G6D8 z(XJlU?c82?-m-y|Dq5ba&r+o%?@tx;ayn+cPM;3`8A>tD)6Q&EJ#HW}A-zYM^*Wai z)la8eo9V9D*<*V`CrqxJ9Zy8T^$_(k*%-3JPWgLjOg*a5gYx0+<&VMT?2_se3tQVR zbSH=!Q#s`MCXQq@n=J$aF+%8V9o`Sow-1rohmiImcyT`wQc23yCQM(5jM03Cq~w$} z$0-Ih(=M}bDzLfr2dmHi;`nY3fFgvv- zR24)Ro$x>{)ddlB)%mr@hW^{_6Uy z&q!O-479O86EVM$J|I{6vp(m|o4Lz;zrSu>>Iu+%n6Wp65Jy;pU=oKBywPX`MI~r; z+zeTj%dv*L?i_1lc5!E=wkzY-gxTMr%X{K#7n6!yZ9^*0*F%01Q^|EI(KW#tF+Ln^ zMOtPcYzDIGS4a6)6PPN2+Xl3p+4)K@xi8lIYKxIA$$|hTlfH-CO3%f<_1xy zF`_8EK>(rf3hI(8Y=+1(HohMSnQvC&r$vyW?hBbR zdFax8;5S_RVkDmKxAb5R*ShxnAD_biQ49W$D*rFpQ3n8NBLI-q05G$DC;|c(0mnu_ zU>X6MlPxO%0&uPXxO9E{3ScxTrvM+)|96x`p>av1GgkevDggvWi3Wir36Rc$V2ogi zSss4;YN%dv=6xbRv{@J3@i8l|{}5xEe;>8cx}&+$$R;rmQ)0lDX#s%{k}#a}f=&)& z9E9gX3=_$PGfQtmxu)1nYgAe#&1hQ~RHv?!6uDH^J< zg@!7uBr*a%Dx0e<^i!ctg(OWW)hXnupRoI4wI!W`C z@G}0$yia#`zq&_{hD{WgBDS|p+jv(Fgx0G_Em#DH3xm65G-gz?6usM_R4tmY6t4i_(SMEZ~Lj9%k_#J$GRj0`qh%W;8KE+D7b znLzCBOjvoxQzM?&JD#y4gXaBZM+WVYf$=saVx0_#E*%J2N)3pv9WXwt(2Ng= zx4z;f^@0Z^niT4S` zUY{%1dNe5|R-Mmrh0UjPC)vJ5TG+ltR(3f1ZEWBo?uFR@#ltz|o9ks_RV~9f2(Drf z)nciol3bOVd1hLfvO@8kzEfd}Af=vV*% DCvDDh literal 1577 zcmV+^2G;o>iwFP!000001MOT}Z`(E$e$THE+?NhWXps~tscllM0|pEzuwl!d1KMJ2 zZn9`dbZ!s*?V~QWV_D8c6pgr}0SA#lpHHOD`M$#=QlCEGEmH4>=Y^2j`3M4k7bF8%UU9<+x-yxo@79Gs@6t#A7$3FfW zZ$iI67eG@kfEWap$v{IOOv4Qu=o5tE;E3n|L&pdG_+Zz+93c!s2w&t~2Opqea)Zcj zZV(cU5r*U=0tk^)sHa?{A0kir;%X}MYoO|!-PlucrU5W)S&i<4Omi-uWqqd{DsgX@$pr*utEz<%51X4oQ zyr7fA2nXbNh+&xvnG3}nDfA}=>?q-2)soPd5kO=)SH@+Q+~ms5Y|(nMY}BilB+Ic& zmfuLS9GONy1gK?I3_%e1ex-`ARK*xXejJy_0pOrI?op?>b!-g>(YhUm$lp z&Pk+2iHwIRsKNsjRAD8NA@EUITs=TN71~rt+LuzDLJs|e-5(-JM3yIx)c1qZ?`w%9 zzzSgDGU&;haKRR7hyN1}C&EkQBsgfrNhb$lba^ zhIaK41LXAaEj(_7#w$)rkF*>B8Uk)2psu1=j{viNxga>IBoPl$M?tphC_aMg95Dt_ z5XQ%oA}XDvc}jYzxZ&RW%ge9s(W7Az#ifXcTc&NiDhERAvq&vi6q5}@Xrc6Ba7+}z z3&j-kiq&+=i$dJE2azVL6QG+$9+V@D7cPa>A~$L^hww4kY~%>_KjetEaX{*}ar7gD z9oKSPV3iB#Fe?+N-IWPjdptGbaqaPp92xYlFFP_g92podQ=-<%fa<9OrH@hr3Sx@! zQ6&e&@j*X6ppFj?$_J781E;`hy*&UiCK1snq^UJR7{Ky4K8{L)$P$r@hX?5uGM{N* z;ofh5+)(d5ioA(XuJmX!mDqMZ#}zi8&JD7BiymP47TsFm>>pwQ7j+wA{}&JEkZ-P+ zu~oGsQ4pL)AZ)}kpoE^r^(LTW(#nJvN@VPz+8bEwC3J#0fMCW>E(ey&uOj1JRAK%; zrBh^k?{K-8OM~EAFU#%oC1hW{oXRY_;#pGl;Wa($eAiE8(0%P6(`EYty52tc8l$Pc z(F5q+KuUzn%epwmVY&Dm(=fEV@eBtgk`F@Pr#Seyfu=;Cc>BWigO+n5`{ms|KIXLN bW#mvFSFZuRIN5qn=*7u@W`z^XM_T{@1;7Vl diff --git a/ipprot.tex b/ipprot.tex index b1362a3..6faf9eb 100644 --- a/ipprot.tex +++ b/ipprot.tex @@ -241,45 +241,53 @@ grandi linee nei seguenti punti: Per capire le caratteristiche di IPv6 partiamo dall'intestazione usata dal protocollo per gestire la trasmissione dei pacchetti; in -\tabref{tab:IP_ipv6head} è riportato il formato dell'intestazione di IPv6 da -confrontare con quella di IPv4 in \tabref{tab:IP_ipv4head}. La spiegazione del +\figref{fig:IP_ipv6head} è riportato il formato dell'intestazione di IPv6 da +confrontare con quella di IPv4 in \figref{fig:IP_ipv4head}. La spiegazione del significato dei vari campi delle due intestazioni è riportato rispettivamente in \tabref{tab:IP_ipv6field} e \tabref{tab:IP_ipv4field}) -\begin{table}[htb] - \footnotesize - \begin{center} - \begin{tabular}{@{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule}p{16mm} - @{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule}p{16mm} - @{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule} } - \multicolumn{8}{@{}c@{}}{0\hfill 15 16\hfill 31}\\ - \hline - \centering version&\centering priority& - \multicolumn{6}{@{}p{96mm}@{\vrule}}{\centering flow label} \\ - \hline - \multicolumn{4}{@{\vrule}p{64mm}@{\vrule}}{\centering payload length} & - \multicolumn{2}{@{}p{32mm}@{\vrule}}{\centering next header} & - \multicolumn{2}{@{}p{32mm}@{\vrule}}{\centering hop limit}\\ - \hline - \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\ - \multicolumn{8}{@{\vrule}c@{\vrule}}{ - source} \\ - \multicolumn{8}{@{\vrule}c@{\vrule}}{ - IP address} \\ - \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\ - \hline - \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\ - \multicolumn{8}{@{\vrule}c@{\vrule}}{ - destination} \\ - \multicolumn{8}{@{\vrule}c@{\vrule}}{ - IP address} \\ - \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\ - \hline - \end{tabular} - \caption{L'intestazione o \textit{header} di IPv6} - \label{tab:IP_ipv6head} - \end{center} -\end{table} +% \begin{table}[htb] +% \footnotesize +% \begin{center} +% \begin{tabular}{@{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule}p{16mm} +% @{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule}p{16mm} +% @{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule} } +% \multicolumn{8}{@{}c@{}}{0\hfill 15 16\hfill 31}\\ +% \hline +% \centering version&\centering priority& +% \multicolumn{6}{@{}p{96mm}@{\vrule}}{\centering flow label} \\ +% \hline +% \multicolumn{4}{@{\vrule}p{64mm}@{\vrule}}{\centering payload length} & +% \multicolumn{2}{@{}p{32mm}@{\vrule}}{\centering next header} & +% \multicolumn{2}{@{}p{32mm}@{\vrule}}{\centering hop limit}\\ +% \hline +% \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\ +% \multicolumn{8}{@{\vrule}c@{\vrule}}{ +% source} \\ +% \multicolumn{8}{@{\vrule}c@{\vrule}}{ +% IP address} \\ +% \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\ +% \hline +% \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\ +% \multicolumn{8}{@{\vrule}c@{\vrule}}{ +% destination} \\ +% \multicolumn{8}{@{\vrule}c@{\vrule}}{ +% IP address} \\ +% \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\ +% \hline +% \end{tabular} +% \caption{L'intestazione o \textit{header} di IPv6} +% \label{tab:IP_ipv6head} +% \end{center} +% \end{table} + +\begin{figure}[htb] + \centering + \includegraphics[width=10cm]{img/ipv6_head} + \caption{L'intestazione o \textit{header} di IPv6.} + \label{fig:IP_ipv6head} +\end{figure} + Come si può notare l'intestazione di IPv6 diventa di dimensione fissa, pari a 40 byte, contro una dimensione (minima, in assenza di opzioni) di 20 byte per @@ -323,7 +331,7 @@ numero dei campi da 12 a 8. Abbiamo già anticipato in \secref{sec:IP_ipv6over} uno dei criteri principali nella progettazione di IPv6 è stato quello di ridurre al minimo il tempo di processamento dei pacchetti da parte dei router, un confronto con -l'intestazione di IPv4 (vedi \secref{tab:IP_ipv4head}) mostra le seguenti +l'intestazione di IPv4 (vedi \figref{fig:IP_ipv4head}) mostra le seguenti differenze: \begin{itemize} @@ -355,47 +363,18 @@ differenze: \item è stato introdotto un nuovo campo \textit{flow label}, che viene usato, insieme al campo \textit{priority} (che recupera i bit di precedenza del campo \textit{type of service}) per implementare la gestione di una - ``qualità di servizio'' (vedi Sez.~\ref{sec:IP_ipv6_qos}) che permette di + ``qualità di servizio'' (vedi \secref{sec:IP_ipv6_qos}) che permette di identificare i pacchetti appartenenti a un ``flusso'' di dati per i quali si può provvedere un trattamento speciale. \end{itemize} -\begin{table}[htb] - \footnotesize + +\begin{figure}[htb] \centering - \begin{tabular}{@{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule}p{16mm} - @{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule}p{16mm} - @{\vrule}p{16mm}@{\vrule}p{16mm}@{\vrule} } - \multicolumn{8}{@{}c@{}}{0\hfill 15 16\hfill 31}\\ - \hline - \centering version& - \centering head length& - \multicolumn{2}{@{}p{32mm}@{\vrule}}{\centering type of service} & - \multicolumn{4}{@{}p{64mm}@{\vrule}}{\centering total length} \\ - \hline - \multicolumn{4}{@{\vrule}p{64mm}@{\vrule}}{\centering identification} & - \multicolumn{4}{@{}p{64mm}@{\vrule}}{\parbox{11mm}{\centering flag} \vrule - \parbox{52mm}{\centering fragment offset}}\\ - \hline - \multicolumn{2}{@{\vrule}p{32mm}@{\vrule}}{\centering TTL}& - \multicolumn{2}{@{}p{32mm}@{\vrule}}{\centering protocol}& - \multicolumn{4}{@{}p{64mm}@{\vrule}}{\centering header checksum} \\ - \hline - \multicolumn{8}{@{\vrule}c@{\vrule}}{ - source IP address} \\ - \hline - \multicolumn{8}{@{\vrule}c@{\vrule}}{ - destination IP address} \\ - \hline - \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\ - \multicolumn{8}{@{}p{128mm}@{}}{ - \centering options (if any)} \\ - \multicolumn{8}{@{\vrule}c@{\vrule}}{} \\ - \hline - \end{tabular} - \caption{L'intestazione o \textit{header} di IPv4} -\label{tab:IP_ipv4head} -\end{table} + \includegraphics[width=10cm]{img/ipv4_head} + \caption{L'intestazione o \textit{header} di IPv4.} + \label{fig:IP_ipv4head} +\end{figure} \begin{table}[htb] \footnotesize diff --git a/pref.tex b/pref.tex index db5ca4a..2fd6792 100644 --- a/pref.tex +++ b/pref.tex @@ -51,12 +51,13 @@ sistema della stessa qualit progetto molto ambizioso ...). -Infatti benché le man pages e il manuale delle librerie del C GNU siano una -fonte inesauribile di informazioni (da cui si è costantemente attinto nella -stesura di tutto il testo) la loro struttura li rende totalmente inadatti ad -una trattazione che vada oltre la descrizione delle caratteristiche -particolari dello specifico argomento in esame (ed in particolare lo -\textit{GNU C Library Reference Manual} non brilla per chiarezza espositiva). +Infatti benché le pagine di manuale del sistema (quelle che si accedono con il +comando \cmd{man}) e il manuale delle librerie del C GNU siano una fonte +inesauribile di informazioni (da cui si è costantemente attinto nella stesura +di tutto il testo) la loro struttura li rende totalmente inadatti ad una +trattazione che vada oltre la descrizione delle caratteristiche particolari +dello specifico argomento in esame (ed in particolare lo \textit{GNU C Library + Reference Manual} non brilla per chiarezza espositiva). Per questo motivo si è cercato di fare tesoro di quanto appreso dai testi di R. Stevens (in particolare \cite{APUE} e \cite{UNP1}) per rendere la diff --git a/process.tex b/process.tex index 00e75a9..9f61d88 100644 --- a/process.tex +++ b/process.tex @@ -603,7 +603,7 @@ suo utilizzo quindi limita la portabilit non può essere usata nella lista degli argomenti di una funzione, perché lo spazio verrebbe allocato nel mezzo degli stessi. -% Questo è riportato solo dal manuale delle glibc, nelle man page non c'è +% Questo è riportato solo dal manuale delle glibc, nelle pagine di manuale non c'è % traccia di tutto ciò % %Inoltre se si diff --git a/signal.tex b/signal.tex index 0026cda..c737f57 100644 --- a/signal.tex +++ b/signal.tex @@ -289,8 +289,8 @@ Il numero totale di segnali presenti che i numeri dei segnali sono allocati progressivamente, essa corrisponde anche al successivo del valore numerico assegnato all'ultimo segnale definito. In \tabref{tab:sig_signal_list} si è riportato l'elenco completo dei segnali -definiti in Linux (estratto dalle man page), comparati con quelli definiti in -vari standard. +definiti in Linux (estratto dalle pagine di manuale), comparati con quelli +definiti in vari standard. \begin{table}[htb] \footnotesize @@ -1298,8 +1298,8 @@ La granularit questo sia sotto BSD4.3 che in SUSv2 è stata definita la funzione \func{usleep} (dove la \texttt{u} è intesa come sostituzione di $\mu$); i due standard hanno delle definizioni diverse, ma le \acr{glibc} -seguono\footnote{secondo la man page almeno dalla versione 2.2.2.} seguono -quella di SUSv2 che prevede il seguente prototipo: +seguono\footnote{secondo la pagina di manuale almeno dalla versione 2.2.2.} +seguono quella di SUSv2 che prevede il seguente prototipo: \begin{prototype}{unistd.h}{int usleep(unsigned long usec)} Pone il processo in stato di sleep per \param{usec} microsecondi. @@ -1915,8 +1915,8 @@ istruzione illecita o di violazione di memoria) mentre alcuni segnali di controllo (\macro{SIGCHLD}, \macro{SIGTRAP} e \macro{SIGPOLL}) forniscono altre informazioni speecifiche. In tutti i casi il valore del campo è riportato attraverso delle costanti (le cui definizioni si trovano -\file{bits/siginfo.h}) il cui elenco dettagliato è disponibile nella man page -di \func{sigaction}. +\file{bits/siginfo.h}) il cui elenco dettagliato è disponibile nella pagina di +manuale di di \func{sigaction}. Il resto della struttura è definito come \ctyp{union} ed i valori eventualmente presenti dipendono dal segnale, così \macro{SIGCHLD} ed i diff --git a/socket.tex b/socket.tex index 11e19a6..8511778 100644 --- a/socket.tex +++ b/socket.tex @@ -26,10 +26,11 @@ Il \textit{socket}\footnote{una traduzione letterale potrebbe essere sempre la parola inglese.} è uno dei principali meccanismi di comunicazione fra programmi utilizzato in ambito Unix. Il socket costituisce in sostanza un canale di comunicazione fra due processi su cui si possono leggere e scrivere -dati analogo a quello di una pipe ma a differenza di questa e degli altri -meccanismi esaminati nel capitolo \capref{cha:IPC} i socket non sono limitati -alla comunicazione fra processi che girano sulla stessa macchina ma possono -effettuare la comunicazione anche attraverso la rete. +dati analogo a quello di una pipe (vedi \secref{sec:ipc_pipes}) ma a +differenza di questa e degli altri meccanismi esaminati nel capitolo +\capref{cha:IPC} i socket non sono limitati alla comunicazione fra processi +che girano sulla stessa macchina ma possono effettuare la comunicazione anche +attraverso la rete. Quella dei socket costituisce infatti la principale API (\textit{Application Program Interface}) usata nella programmazione di rete. La loro origine @@ -37,8 +38,8 @@ risale al 1983, quando furono introdotti nel BSD 4.2; l'interfaccia sostanzialmente la stessa con piccole modifiche negli anni successivi. Benché siano state sviluppate interfacce alternative, originate dai sistemi SVr4, come la XTI (\textit{X/Open Transport Interface}) nessuna ha mai raggiunto la -diffusione e la popolarità di quella dei socket (né tantomeno usabilità e -flessibilità). +diffusione e la popolarità di quella dei socket (né tantomeno la stessa +usabilità e flessibilità). La flessibilità e la genericità dell'interfaccia inoltre ha consentito di utilizzare i socket con i più disparati meccanismi di comunicazione, e non @@ -57,11 +58,11 @@ usato, le funzioni da usare restano le stesse. Per questo motivo una semplice descrizione dell'interfaccia è assolutamente inutile, in quanto il comportamento di quest'ultima e le problematiche da -affrontare cambiano radicalmente a seconda dello ``stile'' di comunicazione -usato. La scelta di questo stile va infatti ad incidere sulla semantica che -verrà utilizzata a livello utente per gestire la comunicazione (su come -inviare e ricevere i dati) e sul comportamento effettivo delle funzioni -utilizzate. +affrontare cambiano radicalmente a seconda dello \textsl{stile} di +comunicazione usato. La scelta di questo stile va infatti ad incidere sulla +semantica che verrà utilizzata a livello utente per gestire la comunicazione +(su come inviare e ricevere i dati) e sul comportamento effettivo delle +funzioni utilizzate. La scelta di uno stile dipende sia dai meccanismi disponibili, sia dal tipo di comunicazione che si vuole effettuare. Ad esempio alcuni stili di @@ -148,9 +149,10 @@ altro nome con cui si indicano i domini. A ciascun tipo di dominio corrisponde un analogo nome simbolico che inizia per \texttt{AF\_} da \textit{address family}, e che identifica il formato degli -indirizzi usati in quel dominio; le man pages di Linux si riferiscono a questi -anche come \textit{name space}, (nome che però il manuale della glibc riserva -ai domini) e che identifica il formato degli indirizzi usati in quel dominio. +indirizzi usati in quel dominio; le pagine di manuale di Linux si riferiscono +a questi anche come \textit{name space}, (nome che però il manuale delle +\acr{glibc} riserva ai domini) e che identifica il formato degli indirizzi +usati in quel dominio. L'idea alla base della distinzione era che una famiglia di protocolli potesse supportare vari tipi di indirizzi, per cui il prefisso \texttt{PF\_} si @@ -162,7 +164,7 @@ nomi sono equivalenti e corrispondono agli stessi valori. I domini (e i relativi nomi simbolici), così come i nomi delle famiglie di indirizzi sono definiti dall'header \textit{socket.h}. In Linux le famiglie di -protocolli disponibili sono riportate in \ntab. +protocolli disponibili sono riportate in \tabref{tab:net_pf_names}. \begin{table}[htb] \footnotesize @@ -175,7 +177,7 @@ protocolli disponibili sono riportate in \ntab. \macro{PF\_UNIX}, \macro{PF\_LOCAL} & Local communication & unix(7) \\ \macro{PF\_INET} & IPv4 Internet protocols & ip(7) \\ - \macro{PF\_INET6} & IPv6 Internet protocols & \\ + \macro{PF\_INET6} & IPv6 Internet protocols & ipv6(7) \\ \macro{PF\_IPX} & IPX - Novell protocols & \\ \macro{PF\_NETLINK}& Kernel user interface device & netlink(7) \\ \macro{PF\_X25} & ITU-T X.25 / ISO-8208 protocol & x25(7) \\ @@ -191,8 +193,9 @@ protocolli disponibili sono riportate in \ntab. Non tutte le famiglie di protocolli sono accessibili dall'utente generico, ad esempio in generale tutti i socket di tipo \macro{SOCK\_RAW} possono essere -creati solo da processi che hanno i privilegi di root (cioè effective uid -uguale a zero) o la capability \macro{CAP\_NET\_RAW}. +creati solo da processi che hanno i privilegi di root (cioè con +\textit{effective user id} uguale a zero) o con la capability +\macro{CAP\_NET\_RAW}. \subsection{Il tipo, o stile} @@ -202,8 +205,9 @@ La scelta di un dominio non comporta per comunicazione, questo infatti viene a dipendere dal protocollo che si andrà ad utilizzare fra quelli disponibili nella famiglia scelta. Le API permettono di scegliere lo stile di comunicazione indicando il tipo di socket; Linux e le -glibc mettono a disposizione i seguenti tipi di socket (che il manuale della -glibc chiama \textit{styles}) definiti come \ctyp{int} in \file{socket.h}: +\acr{glibc} mettono a disposizione i seguenti tipi di socket (che il manuale +della \acr{glibc} chiama \textit{styles}) definiti come \ctyp{int} in +\file{socket.h}: \begin{list}{}{} \item \macro{SOCK\_STREAM} Provvede un canale di trasmissione dati @@ -225,10 +229,10 @@ glibc chiama \textit{styles}) definiti come \ctyp{int} in \file{socket.h}: \item \macro{SOCK\_PACKET} Obsoleto, non deve essere usato. \end{list} -Si tenga presente che non tutte le combinazioni di famiglia di protocolli e -tipo di socket sono valide, in quanto non è detto che nella famiglia esista un -protocollo per tutti gli stili di comunicazione indicati qui sopra. Una -tabella che mostra le combinazioni valide è la seguente: +Si tenga presente che non tutte le combinazioni fra una famiglia di protocolli +e un tipo di socket sono valide, in quanto non è detto che in una famiglia +esista un protocollo per ciascuno dei diversi stili di comunicazione appena +elencati. \begin{table}[htb] \footnotesize @@ -266,9 +270,11 @@ tabella che mostra le combinazioni valide \label{tab:sock_sock_valid_combinations} \end{table} -Dove per ogni combinazione valida si è indicato il tipo di protocollo, o la -parola \textsl{si} qualora non il protocollo non abbia un nome definito, -mentre si sono lasciate vuote le caselle per le combinazioni non supportate. +In \secref{tab:sock_sock_valid_combinations} sono mostrate le combinazioni +valide possibili per le varie famiglie di protocolli. Per ogni combinazione +valida si è indicato il tipo di protocollo, o la parola \textsl{si} qualora +non il protocollo non abbia un nome definito, mentre si sono lasciate vuote le +caselle per le combinazioni non supportate. @@ -300,10 +306,10 @@ attraverso puntatori (cio maneggiare puntatori a strutture relative a tutti gli indirizzi possibili nelle varie famiglie di protocolli; questo pone il problema di come passare questi puntatori, il C ANSI risolve questo problema coi i puntatori generici -(i \ctyp{void *}), ma l'interfaccia dei socket è antecedente alla -definizione dello standard ANSI, e per questo nel 1982 fu scelto di definire -una struttura generica \type{sockaddr} per gli indirizzi dei socket mostrata -in \nfig: +(i \ctyp{void *}), ma l'interfaccia dei socket è antecedente alla definizione +dello standard ANSI, e per questo nel 1982 fu scelto di definire una struttura +generica per gli indirizzi dei socket, \type{sockaddr}, che si è riportata in +\figref{fig:sock_sa_gen_struct}. \begin{figure}[!htb] \footnotesize @@ -323,9 +329,9 @@ invocano dette funzioni passando l'indirizzo di un protocollo specifico occorrerà eseguire un casting del relativo puntatore. I tipi di dati che compongono la struttura sono stabiliti dallo standard -POSIX.1g, riassunti in \ntab\ con i rispettivi file di include in cui sono -definiti; la struttura è invece definita nell'include file -\file{sys/socket.h} +POSIX.1g, riassunti in \tabref{tab:sock_data_types} con i rispettivi file di +include in cui sono definiti; la struttura è invece definita nell'include file +\file{sys/socket.h}. \begin{table}[!htb] \centering @@ -354,7 +360,7 @@ definiti; la struttura \hline \end{tabular} \caption{Tipi di dati usati nelle strutture degli indirizzi, secondo quanto - stabilito dallo standard POSIX.1g} + stabilito dallo standard POSIX.1g.} \label{tab:sock_data_types} \end{table} @@ -379,8 +385,8 @@ l'uso di questa struttura. I socket di tipo \macro{PF\_INET} vengono usati per la comunicazione attraverso internet; la struttura per gli indirizzi per un socket internet (IPv4) è definita come \type{sockaddr\_in} nell'header file -\file{netinet/in.h} e secondo le man page ha la forma mostrata in \nfig, -conforme allo standard POSIX.1g. +\file{netinet/in.h} e secondo le pagine di manuale ha la forma mostrata in +\figref{fig:sock_sa_ipv4_struct}, conforme allo standard POSIX.1g. \begin{figure}[!htb] \footnotesize @@ -835,9 +841,10 @@ successivo; qui ci limiteremo a introdurre la nomenclatura senza fornire definizioni precise e dettagli di funzionamento che saranno trattati estensivamente più avanti. -In \nfig\ è riportata la sezione principale del codice del nostro client -elementare per il servizio \textit{daytime}, un servizio standard che -restituisce l'ora locale della macchina a cui si effettua la richiesta. +In \figref{fig:net_cli_code} è riportata la sezione principale del codice del +nostro client elementare per il servizio \textit{daytime}, un servizio +standard che restituisce l'ora locale della macchina a cui si effettua la +richiesta. \begin{figure}[!htb] \footnotesize @@ -957,7 +964,7 @@ necessario deve provvedere il programma stesso. Dopo aver illustrato il client daremo anche un esempio di un server elementare, in grado di rispondere al precedente client. Il listato è -nuovamente mostrato in \nfig, il sorgente completo +nuovamente mostrato in \figref{fig:net_serv_code}, il sorgente completo (\file{ElemDaytimeTCPServer.c}) è allegato insieme agli altri file nella directory \file{sources}. diff --git a/system.tex b/system.tex index c68686f..bc7cac5 100644 --- a/system.tex +++ b/system.tex @@ -270,8 +270,8 @@ altre costanti. Siccome queste sono principalmente attinenti a limiti relativi alle applicazioni di sistema presenti (come quelli su alcuni parametri delle espressioni regolari o del comando \cmd{bc}), non li tratteremo esplicitamente, se ne trova una menzione completa nell'header file -\file{bits/posix2\_lim.h}, e alcuni di loro sono descritti nella man page di -\func{sysconf} e nel manuale delle \acr{glibc}. +\file{bits/posix2\_lim.h}, e alcuni di loro sono descritti nella pagina di +manuale di \func{sysconf} e nel manuale delle \acr{glibc}. \subsection{La funzione \func{sysconf}} @@ -1122,7 +1122,8 @@ capacit completa. Per questo motivo l'uso di queste funzioni è deprecato in favore dell'uso di PAM, ci limiteremo pertanto ad elencarle in \tabref{tab:sys_passwd_func}, rimandando chi fosse interessato alle rispettive -man page e al manuale delle \acr{glibc} per i dettagli del loro funzionamento. +pagine di manuale e al manuale delle \acr{glibc} per i dettagli del loro +funzionamento. @@ -2388,7 +2389,7 @@ programma e che \func{strerror}; per questo motivo non è rientrante e nel caso si usino i thread è provvista\footnote{questa funzione è la versione prevista dalle \acr{glibc}, ed effettivamente definita in \file{string.h}, ne esiste una - analoga nello standard SUSv3 (quella riportata dalla man page), che + analoga nello standard SUSv3 (quella riportata dalla pagina di manuale), che restituisce \code{int} al posto di \code{char *}, e che tronca la stringa restituita a \param{size}.} una versione apposita: \begin{prototype}{string.h} -- 2.30.2