From f03c81e511c5c9c5c65f9b2bcd21dc7664c08b38 Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Fri, 5 Jan 2007 12:18:29 +0000 Subject: [PATCH] Piccole correzioni, ed iniziato a parlare dei ''Posix Semaphores''. Introdotto il necessario per suddividere le parti. --- gapil.tex | 13 ++++ intro.tex | 24 +++--- ipc.tex | 205 ++++++++++++++++++++++++++------------------------- netlayer.tex | 16 ++-- 4 files changed, 141 insertions(+), 117 deletions(-) diff --git a/gapil.tex b/gapil.tex index 7f35473..0c329e6 100644 --- a/gapil.tex +++ b/gapil.tex @@ -76,6 +76,15 @@ \makeindex +% Solo prima parte, scommentare +%\includeonly{macro,preambolo,pref,intro,process,prochand,fileintro,filedir, +% fileunix,filestd,system,system,signal,session,fileadv,ipc,errors, +% ringraziamenti,fdl} + +% Solo seconda parte e appendici, scommentare +%\includeonly{macro,preambolo,network,socket,tcpsock,sockctrl,othersock, +% sockadv,netlayer,trasplayer,errors,ringraziamenti,fdl} + \begin{document} \frontmatter @@ -148,8 +157,11 @@ \include{session} \include{fileadv} \include{ipc} + +% Commentare sotto se si genera la prima parte \part{Programmazione di rete} \label{part:progr-di-rete} + \include{network} \include{socket} \include{tcpsock} @@ -157,6 +169,7 @@ \include{othersock} \include{sockadv} \appendix + \part{Appendici} \label{part:appendici} \include{netlayer} diff --git a/intro.tex b/intro.tex index 23f677b..69b22e7 100644 --- a/intro.tex +++ b/intro.tex @@ -73,8 +73,8 @@ attraverso delle opportune chiamate al sistema che restituiranno il controllo al kernel. La memoria viene sempre gestita dal kernel attraverso il meccanismo della -\textsl{memoria virtuale}\index{memoria~virtuale}, che consente di assegnare a -ciascun processo uno spazio di indirizzi ``\textsl{virtuale}'' (vedi +\index{memoria~virtuale} \textsl{memoria virtuale}, che consente di assegnare +a ciascun processo uno spazio di indirizzi ``\textsl{virtuale}'' (vedi sez.~\ref{sec:proc_memory}) che il kernel stesso, con l'ausilio della unità di gestione della memoria, si incaricherà di rimappare automaticamente sulla memoria disponibile, salvando su disco quando necessario (nella cosiddetta @@ -257,13 +257,13 @@ L'utente e il gruppo sono identificati da due numeri, la cui corrispondenza ad un nome espresso in caratteri è inserita nei due file \file{/etc/passwd} e \file{/etc/groups}.\footnote{in realtà negli sistemi più moderni, come vedremo in sez.~\ref{sec:sys_user_group} queste informazioni possono essere - mantenute, con l'uso del \textit{Name Service Switch}, su varie tipologie di - supporti, compresi server centralizzati come LDAP.} -\itindex{Name~Service~Switch} Questi numeri sono l'\textit{user identifier}, -detto in breve \textsl{user-ID}, ed indicato dall'acronimo \acr{uid}, e il -\textit{group identifier}, detto in breve \textsl{group-ID}, ed identificato -dall'acronimo \acr{gid}, e sono quelli che vengono usati dal kernel per -identificare l'utente. + mantenute, con l'uso del \itindex{Name~Service~Switch} \textit{Name Service + Switch}, su varie tipologie di supporti, compresi server centralizzati + come LDAP.} Questi numeri sono l'\textit{user identifier}, detto in breve +\textsl{user-ID}, ed indicato dall'acronimo \acr{uid}, e il \textit{group + identifier}, detto in breve \textsl{group-ID}, ed identificato dall'acronimo +\acr{gid}, e sono quelli che vengono usati dal kernel per identificare +l'utente. In questo modo il sistema è in grado di tenere traccia dell'utente a cui appartiene ciascun processo ed impedire ad altri utenti di interferire con @@ -380,7 +380,7 @@ Uno dei problemi di portabilit dati utilizzati nei programmi, che spesso variano da sistema a sistema, o anche da una architettura ad un'altra (ad esempio passando da macchine con processori 32 bit a 64). In particolare questo è vero nell'uso dei cosiddetti -\textit{tipi elementari}\index{tipo!elementare} del linguaggio C (come +\index{tipo!elementare} \textit{tipi elementari}del linguaggio C (come \ctyp{int}) la cui dimensione varia a seconda dell'architettura hardware. Storicamente alcuni tipi nativi dello standard ANSI C sono sempre stati @@ -405,7 +405,7 @@ una infinita serie di problemi di portabilit \type{clock\_t} & Contatore del tempo di sistema.\\ \type{dev\_t} & Numero di dispositivo.\\ \type{gid\_t} & Identificatore di un gruppo.\\ - \type{ino\_t} & Numero di \textit{inode}\index{inode}.\\ + \type{ino\_t} & Numero di \index{inode} \textit{inode}.\\ \type{key\_t} & Chiave per il System V IPC.\\ \type{loff\_t} & Posizione corrente in un file.\\ \type{mode\_t} & Attributi di un file.\\ @@ -427,7 +427,7 @@ una infinita serie di problemi di portabilit Per questo motivo tutte le funzioni di libreria di solito non fanno riferimento ai tipi elementari dello standard del linguaggio C, ma ad una -serie di \textsl{tipi primitivi}\index{tipo!primitivo} del sistema, riportati +serie di \index{tipo!primitivo} \textsl{tipi primitivi} del sistema, riportati in tab.~\ref{tab:intro_primitive_types}, e definiti nell'header file \file{sys/types.h}, in modo da mantenere completamente indipendenti i tipi utilizzati dalle funzioni di sistema dai tipi elementari supportati dal diff --git a/ipc.tex b/ipc.tex index 1888d4a..74b5136 100644 --- a/ipc.tex +++ b/ipc.tex @@ -170,7 +170,7 @@ direzione del flusso dei dati Si potrebbe obiettare che sarebbe molto più semplice salvare il risultato intermedio su un file temporaneo. Questo però non tiene conto del fatto che un \textit{CGI} deve poter gestire più richieste in concorrenza, e si avrebbe una -evidente \textit{race condition}\itindex{race~condition} in caso di accesso +evidente \itindex{race~condition} \textit{race condition} in caso di accesso simultaneo a detto file.\footnote{il problema potrebbe essere superato determinando in anticipo un nome appropriato per il file temporaneo, che verrebbe utilizzato dai vari sotto-processi, e cancellato alla fine della @@ -418,13 +418,13 @@ o nella relazione padre/figlio; per superare questo problema lo standard POSIX.1 ha definito dei nuovi oggetti, le \textit{fifo}, che hanno le stesse caratteristiche delle pipe, ma che invece di essere strutture interne del kernel, visibili solo attraverso un file descriptor, sono accessibili -attraverso un inode\index{inode} che risiede sul filesystem, così che i +attraverso un \index{inode} inode che risiede sul filesystem, così che i processi le possono usare senza dovere per forza essere in una relazione di \textsl{parentela}. Utilizzando una \textit{fifo} tutti i dati passeranno, come per le pipe, attraverso un apposito buffer nel kernel, senza transitare dal filesystem; -l'inode\index{inode} allocato sul filesystem serve infatti solo a fornire un +\index{inode} l'inode allocato sul filesystem serve infatti solo a fornire un punto di riferimento per i processi, che permetta loro di accedere alla stessa fifo; il comportamento delle funzioni di lettura e scrittura è identico a quello illustrato per le pipe in sez.~\ref{sec:ipc_pipes}. @@ -454,8 +454,8 @@ comunque una fifo in scrittura anche se non ci sono ancora processi il lettura; è possibile anche usare la fifo all'interno di un solo processo, nel qual caso però occorre stare molto attenti alla possibili situazioni di stallo.\footnote{se si cerca di leggere da una fifo che non contiene dati si - avrà un deadlock\itindex{deadlock} immediato, dato che il processo si blocca - e non potrà quindi mai eseguire le funzioni di scrittura.} + avrà un \itindex{deadlock} deadlock immediato, dato che il processo si + blocca e non potrà quindi mai eseguire le funzioni di scrittura.} Per la loro caratteristica di essere accessibili attraverso il filesystem, è piuttosto frequente l'utilizzo di una fifo come canale di comunicazione nelle @@ -649,7 +649,7 @@ state raccolte nella libreria \file{libgapil.so}, per poter usare quest'ultima occorrerà definire la speciale variabile di ambiente \code{LD\_LIBRARY\_PATH} in modo che il linker dinamico possa accedervi. -In generale questa variabile indica il \itindex{pathname}\textit{pathname} +In generale questa variabile indica il \itindex{pathname} \textit{pathname} della directory contenente la libreria. Nell'ipotesi (che daremo sempre per verificata) che si facciano le prove direttamente nella directory dei sorgenti (dove di norma vengono creati sia i programmi che la libreria), il comando da @@ -879,7 +879,7 @@ nome di un file ed un numero di versione; il suo prototipo \end{functions} La funzione determina un valore della chiave sulla base di \param{pathname}, -che deve specificare il \itindex{pathname}\textit{pathname} di un file +che deve specificare il \itindex{pathname} \textit{pathname} di un file effettivamente esistente e di un numero di progetto \param{proj\_id)}, che di norma viene specificato come carattere, dato che ne vengono utilizzati solo gli 8 bit meno significativi.\footnote{nelle libc4 e libc5, come avviene in @@ -889,7 +889,7 @@ gli 8 bit meno significativi.\footnote{nelle libc4 e libc5, come avviene in Il problema è che anche così non c'è la sicurezza che il valore della chiave sia univoco, infatti esso è costruito combinando il byte di \param{proj\_id)} -con i 16 bit meno significativi dell'inode\index{inode} del file +con i 16 bit meno significativi \index{inode} dell'inode del file \param{pathname} (che vengono ottenuti attraverso \func{stat}, da cui derivano i possibili errori), e gli 8 bit meno significativi del numero del dispositivo su cui è il file. Diventa perciò relativamente facile ottenere delle @@ -1185,23 +1185,23 @@ file \file{msgmax}, \file{msgmnb} e \file{msgmni} di \file{/proc/sys/kernel/}. \end{figure} -Una coda di messaggi è costituita da una \itindex{linked~list}\textit{linked - list};\footnote{una \textit{linked list} è una tipica struttura di dati, - organizzati in una lista in cui ciascun elemento contiene un puntatore al - successivo. In questo modo la struttura è veloce nell'estrazione ed - immissione dei dati dalle estremità dalla lista (basta aggiungere un - elemento in testa o in coda ed aggiornare un puntatore), e relativamente - veloce da attraversare in ordine sequenziale (seguendo i puntatori), è - invece relativamente lenta nell'accesso casuale e nella ricerca.} i nuovi -messaggi vengono inseriti in coda alla lista e vengono letti dalla cima, in -fig.~\ref{fig:ipc_mq_schema} si è riportato lo schema con cui queste strutture -vengono mantenute dal kernel.\footnote{lo schema illustrato in - fig.~\ref{fig:ipc_mq_schema} è in realtà una semplificazione di quello usato - effettivamente fino ai kernel della serie 2.2.x, nei kernel della serie - 2.4.x la gestione delle code di messaggi è stata modificata ed è effettuata - in maniera diversa; abbiamo mantenuto lo schema precedente in quanto - illustra comunque in maniera più che adeguata i principi di funzionamento - delle code di messaggi.} +Una coda di messaggi è costituita da una \itindex{linked~list} \textit{linked + list};\footnote{una \itindex{linked~list} \textit{linked list} è una tipica + struttura di dati, organizzati in una lista in cui ciascun elemento contiene + un puntatore al successivo. In questo modo la struttura è veloce + nell'estrazione ed immissione dei dati dalle estremità dalla lista (basta + aggiungere un elemento in testa o in coda ed aggiornare un puntatore), e + relativamente veloce da attraversare in ordine sequenziale (seguendo i + puntatori), è invece relativamente lenta nell'accesso casuale e nella + ricerca.} i nuovi messaggi vengono inseriti in coda alla lista e vengono +letti dalla cima, in fig.~\ref{fig:ipc_mq_schema} si è riportato lo schema con +cui queste strutture vengono mantenute dal kernel.\footnote{lo schema + illustrato in fig.~\ref{fig:ipc_mq_schema} è in realtà una semplificazione + di quello usato effettivamente fino ai kernel della serie 2.2.x, nei kernel + della serie 2.4.x la gestione delle code di messaggi è stata modificata ed è + effettuata in maniera diversa; abbiamo mantenuto lo schema precedente in + quanto illustra comunque in maniera più che adeguata i principi di + funzionamento delle code di messaggi.} \begin{figure}[!htb] \footnotesize \centering @@ -1517,7 +1517,7 @@ possono essere utilizzate, e non si ha a disposizione niente di analogo alle funzioni \func{select} e \func{poll}. Questo rende molto scomodo usare più di una di queste strutture alla volta; ad esempio non si può scrivere un server che aspetti un messaggio su più di una coda senza fare ricorso ad una tecnica -di \textit{polling}\itindex{polling} che esegua un ciclo di attesa su +di \itindex{polling} \textit{polling} che esegua un ciclo di attesa su ciascuna di esse. Come esempio dell'uso delle code di messaggi possiamo riscrivere il nostro @@ -1680,7 +1680,7 @@ viene interrotto dopo l'invio del messaggio di richiesta e prima della lettura della risposta, quest'ultima resta nella coda (così come per le fifo si aveva il problema delle fifo che restavano nel filesystem). In questo caso però il problemi sono maggiori, sia perché è molto più facile esaurire la memoria -dedicata ad una coda di messaggi che gli inode\index{inode} di un filesystem, +dedicata ad una coda di messaggi che gli \index{inode} inode di un filesystem, sia perché, con il riutilizzo dei \acr{pid} da parte dei processi, un client eseguito in un momento successivo potrebbe ricevere un messaggio non indirizzato a lui. @@ -1693,8 +1693,8 @@ indirizzato a lui. I semafori non sono meccanismi di intercomunicazione diretta come quelli (pipe, fifo e code di messaggi) visti finora, e non consentono di scambiare dati fra processi, ma servono piuttosto come meccanismi di sincronizzazione o -di protezione per le \textsl{sezioni critiche} \index{sezione~critica} del -codice (si ricordi quanto detto in sez.~\ref{sec:proc_race_cond}). +di protezione per le \index{sezione~critica} \textsl{sezioni critiche} del +codice (si ricordi quanto detto in sez.~\ref{sec:proc_race_cond}). Un semaforo è uno speciale contatore, mantenuto nel kernel, che permette, a seconda del suo valore, di consentire o meno la prosecuzione dell'esecuzione @@ -2197,7 +2197,7 @@ coda di attesa associata a ciascun insieme di semafori\footnote{che viene Nella struttura viene memorizzato il riferimento alle operazioni richieste (nel campo \var{sops}, che è un puntatore ad una struttura \struct{sembuf}) e al processo corrente (nel campo \var{sleeper}) poi quest'ultimo viene messo -stato di attesa e viene invocato lo scheduler\itindex{scheduler} per passare +stato di attesa e viene invocato lo \itindex{scheduler} scheduler per passare all'esecuzione di un altro processo. Se invece tutte le operazioni possono avere successo queste vengono eseguite @@ -2511,14 +2511,14 @@ corrispondente comportamento della funzione, sono i seguenti: memoria virtuale; si ricordi quanto trattato in sez.~\ref{sec:proc_mem_lock}.} sul segmento di memoria condivisa. Solo l'amministratore può utilizzare questo comando. -\item[\const{SHM\_UNLOCK}] Disabilita il \textit{memory locking} - \itindex{memory~locking} sul segmento di memoria condivisa. Solo +\item[\const{SHM\_UNLOCK}] Disabilita il \itindex{memory~locking} + \textit{memory locking} sul segmento di memoria condivisa. Solo l'amministratore può utilizzare questo comando. \end{basedescript} i primi tre comandi sono gli stessi già visti anche per le code di messaggi e gli insiemi di semafori, gli ultimi due sono delle estensioni specifiche previste da Linux, che permettono di abilitare e disabilitare il meccanismo -della memoria virtuale \index{memoria~virtuale} per il segmento. +della \index{memoria~virtuale} memoria virtuale per il segmento. L'argomento \param{buf} viene utilizzato solo con i comandi \const{IPC\_STAT} e \const{IPC\_SET} nel qual caso esso dovrà puntare ad una struttura @@ -3021,6 +3021,7 @@ diffuso. \label{sec:ipc_file_lock} \index{file!di lock|(} + Come illustrato in sez.~\ref{sec:ipc_sysv_sem} i semafori del \textit{SysV IPC} presentano una interfaccia inutilmente complessa e con alcuni difetti strutturali, per questo quando si ha una semplice esigenza di sincronizzazione @@ -3077,35 +3078,36 @@ acquisizione sono atomici; la soluzione funziona anche su NFS, ma ha un altro difetto è che è quello di poterla usare solo se si opera all'interno di uno stesso filesystem. -Un generale comunque l'uso di un \textsl{file di lock} presenta parecchi -problemi, che non lo rendono una alternativa praticabile per la +In generale comunque l'uso di un \textsl{file di lock} presenta parecchi +problemi che non lo rendono una alternativa praticabile per la sincronizzazione: anzitutto in caso di terminazione imprevista del processo, si lascia allocata la risorsa (il \textsl{file di lock}) e questa deve essere sempre cancellata esplicitamente. Inoltre il controllo della disponibilità -può essere eseguito solo con una tecnica di \textit{polling}\itindex{polling}, -ed è quindi molto inefficiente. +può essere eseguito solo con una tecnica di \itindex{polling} +\textit{polling}, ed è quindi molto inefficiente. La tecnica dei file di lock ha comunque una sua utilità, e può essere usata con successo quando l'esigenza è solo quella di segnalare l'occupazione di una risorsa, senza necessità di attendere che questa si liberi; ad esempio la si usa spesso per evitare interferenze sull'uso delle porte seriali da parte di più programmi: qualora si trovi un file di lock il programma che cerca di -accedere alla seriale si limita a segnalare che la risorsa non è -disponibile.\index{file!di lock|)} +accedere alla seriale si limita a segnalare che la risorsa non è disponibile. + +\index{file!di lock|)} \subsection{La sincronizzazione con il \textit{file locking}} \label{sec:ipc_lock_file} -Dato che i file di lock\index{file!di lock} presentano gli inconvenienti +Dato che i \index{file!di lock} file di lock presentano gli inconvenienti illustrati in precedenza, la tecnica alternativa di sincronizzazione più -comune è quella di fare ricorso al \textit{file locking}\index{file!locking} +comune è quella di fare ricorso al \index{file!locking} \textit{file locking} (trattato in sez.~\ref{sec:file_locking}) usando \func{fcntl} su un file creato per l'occasione per ottenere un write lock. In questo modo potremo usare il lock come un \textit{mutex}: per bloccare la risorsa basterà acquisire il lock, per sbloccarla basterà rilasciare il lock. Una richiesta fatta con un write lock metterà automaticamente il processo in stato di -attesa, senza necessità di ricorrere al \textit{polling}\itindex{polling} per +attesa, senza necessità di ricorrere al \itindex{polling} \textit{polling} per determinare la disponibilità della risorsa, e al rilascio della stessa da parte del processo che la occupava si otterrà il nuovo lock atomicamente. @@ -3275,67 +3277,65 @@ richiesto \end{itemize} Data la assoluta genericità delle specifiche, il comportamento delle funzioni -è pertanto subordinato in maniera quasi completa alla relativa +è subordinato in maniera quasi completa alla relativa implementazione.\footnote{tanto che Stevens in \cite{UNP2} cita questo caso come un esempio della maniera standard usata dallo standard POSIX per consentire implementazioni non standardizzabili.} Nel caso di Linux, sia per -quanto riguarda la memoria condivisa, che per quanto riguarda le code di -messaggi, tutto viene creato usando come radici delle opportune directory -(rispettivamente \file{/dev/shm} e \file{/dev/mqueue}, per i dettagli si -faccia riferimento a sez.~\ref{sec:ipc_posix_shm} e -sez.~\ref{sec:ipc_posix_mq}) ed i nomi specificati nelle relative funzioni -sono considerati come un \itindsub{pathname}{assoluto}\textit{pathname} -assoluto (comprendente eventuali sottodirectory) rispetto a queste radici. +quanto riguarda la memoria condivisa ed i semafori, che per quanto riguarda le +code di messaggi, tutto viene creato usando come radici delle opportune +directory (rispettivamente \file{/dev/shm} e \file{/dev/mqueue}, per i +dettagli si faccia riferimento a sez.~\ref{sec:ipc_posix_shm}, +sez.~\ref{sec:ipc_posix_sem} e sez.~\ref{sec:ipc_posix_mq}) ed i nomi +specificati nelle relative funzioni sono considerati come un +\itindsub{pathname}{assoluto}\textit{pathname} assoluto (comprendente +eventuali sottodirectory) rispetto a queste radici. Il vantaggio degli oggetti di IPC POSIX è comunque che essi vengono inseriti nell'albero dei file, e possono essere maneggiati con le usuali funzioni e -comandi di accesso ai file,\footnote{questo è ancora più vero nel caso di - Linux, che usa una implementazione che lo consente, non è detto che - altrettanto valga per altri kernel. In particolare sia la memoria condivisa - che per le code di messaggi, come si può facilmente evincere con uno - \cmd{strace}, le system call utilizzate sono le stesse, in quanto esse sono - realizzate con dei file in speciali filesystem.} che funzionano come su dei -file normali. +comandi di accesso ai file,\footnote{questo è vero nel caso di Linux, che usa + una implementazione che lo consente, non è detto che altrettanto valga per + altri kernel; in particolare sia la memoria condivisa che per le code di + messaggi, come si può facilmente evincere con uno \cmd{strace}, le system + call utilizzate sono le stesse, in quanto detti oggetti sono realizzati con + dei file in speciali filesystem.} che funzionano come su dei file normali. In particolare i permessi associati agli oggetti di IPC POSIX sono identici ai permessi dei file, e il controllo di accesso segue esattamente la stessa semantica (quella illustrata in sez.~\ref{sec:file_access_control}), invece di quella particolare (si ricordi quanto visto in -sez.~\ref{sec:ipc_sysv_access_control}) usata per gli oggetti del SysV IPC. Per -quanto riguarda l'attribuzione dell'utente e del gruppo proprietari +sez.~\ref{sec:ipc_sysv_access_control}) usata per gli oggetti del SysV IPC. +Per quanto riguarda l'attribuzione dell'utente e del gruppo proprietari dell'oggetto alla creazione di quest'ultimo essa viene effettuata secondo la -semantica SysV (essi corrispondono cioè a userid e groupid effettivi del -processo che esegue la creazione). +semantica SysV; essi corrispondono cioè a userid e groupid effettivi del +processo che esegue la creazione. \subsection{Code di messaggi} \label{sec:ipc_posix_mq} -Le code di messaggi non sono ancora supportate nel kernel ufficiale, esiste -però una implementazione sperimentale di Michal Wronski e Krzysztof -Benedyczak,\footnote{i patch al kernel e la relativa libreria possono essere -trovati su \href{http://www.mat.uni.torun.pl/~wrona/posix_ipc} -{\textsf{http://www.mat.uni.torun.pl/\tild{}wrona/posix\_ipc}}, questi sono -stati inseriti nel kernel ufficiale a partire dalla versione 2.6.6-rc1.}. In +Le code di messaggi POSIX sono supportate da Linux a partire dalla versione +2.6.6-rc1 del kerne;, \footnote{l'implementazione è dovuta a Michal Wronski e + Krzysztof Benedyczak, e le relative informazioni si possono trovare su + \href{http://www.geocities.com/wronski12/posix_ipc/index.html} + {\texttt{http://www.geocities.com/wronski12/posix\_ipc/index.html}}.} In generale, come le corrispettive del SysV IPC, le code di messaggi sono poco -usate, dato che i socket, nei casi in cui sono sufficienti, sono -più comodi, e che in casi più complessi la comunicazione può essere gestita -direttamente con mutex e memoria condivisa con tutta la flessibilità che -occorre. - -Per poter utilizzare le code di messaggi, oltre ad utilizzare un kernel cui -siano stati opportunamente applicati i relativi patch, occorre utilizzare la -libreria \file{mqueue}\footnote{i programmi che usano le code di messaggi cioè +usate, dato che i socket, nei casi in cui sono sufficienti, sono più comodi, e +che in casi più complessi la comunicazione può essere gestita direttamente con +mutex e memoria condivisa con tutta la flessibilità che occorre. + +Per poter utilizzare le code di messaggi, oltre ad utilizzare un kernel +superiore al 2.6.6 (o precedente, purché cui siano stati opportunamente +applicati i relativi patch) occorre utilizzare la libreria +\file{libmqueue}\footnote{i programmi che usano le code di messaggi cioè devono essere compilati aggiungendo l'opzione \code{-lmqueue} al comando \cmd{gcc}, dato che le funzioni non fanno parte della libreria standard, in corrispondenza all'inclusione del supporto nel kernel ufficiale, anche le - relative funzioni sono state inserite nelle \acr{glibc} a partire dalla - versione 2.3.4.} che contiene le funzioni dell'interfaccia -POSIX.\footnote{in realtà l'implementazione è realizzata tramite delle - speciali chiamate ad \func{ioctl} sui file del filesystem speciale su cui - vengono mantenuti questi oggetti di IPC.} - + relative funzioni sono state inserite nelle \acr{glibc}, e presenti a + partire dalla versione 2.3.4 delle medesime.} che contiene le funzioni +dell'interfaccia POSIX.\footnote{in realtà l'implementazione è realizzata + tramite delle speciali chiamate ad \func{ioctl} sui file del filesystem + speciale su cui vengono mantenuti questi oggetti di IPC.} La libreria inoltre richiede la presenza dell'apposito filesystem di tipo \texttt{mqueue} montato su \file{/dev/mqueue}; questo può essere fatto @@ -3770,31 +3770,38 @@ mascherati. In realtà a partire dal kernel 2.5.7 è stato introdotto un meccanismo di sincronizzazione completamente nuovo, basato sui cosiddetti \textit{futex}\footnote{la sigla sta per \textit{fast user mode mutex}.}, con -il quale dovrebbe essere possibile implementare una versione nativa dei -semafori; esso è già stato usato con successo per reimplementare in maniera -più efficiente tutte le direttive di sincronizzazione previste per i thread -POSIX. L'interfaccia corrente è stata stabilizzata a partire dal kernel -2.5.40. +il quale è stato possibile implementare una versione nativa dei semafori; esso +è già stato usato con successo per reimplementare in maniera più efficiente +tutte le direttive di sincronizzazione previste per i thread POSIX; e con il +kernel della serie 2.6 e le nuove versioni delle \acr{glibc} che usano quella +che viene chiamata la \textit{New Posix Thread Library} sono state +implementate tutte le funzioni occorrenti. + +Anche in questo caso (come per le code di messaggi) è necessario appoggiarsi +alla libreria per le estensioni \textit{real-time} \texttt{librt}, questo +significa che se si vuole utilizzare questa interfaccia, oltre ad utilizzare +gli opportuni file di definizione, occorrerà compilare i programmi con +l'opzione \texttt{-lrt}. -% TODO vedere se ci sono novità e trattare la cosa. +% TODO trattare l'argomento a partire da man sem_overview. \subsection{Memoria condivisa} \label{sec:ipc_posix_shm} -La memoria condivisa è l'unico degli oggetti di IPC POSIX già presente nel -kernel ufficiale; in realtà il supporto a questo tipo di oggetti è realizzato -attraverso il filesystem \texttt{tmpfs}, uno speciale filesystem che mantiene -tutti i suoi contenuti in memoria,\footnote{il filesystem \texttt{tmpfs} è - diverso da un normale RAM disk, anch'esso disponibile attraverso il - filesystem \texttt{ramfs}, proprio perché realizza una interfaccia - utilizzabile anche per la memoria condivisa; esso infatti non ha dimensione - fissa, ed usa direttamente la cache interna del kernel (che viene usata - anche per la shared memory in stile SysV). In più i suoi contenuti, essendo - trattati direttamente dalla memoria virtuale\index{memoria~virtuale} possono - essere salvati sullo swap automaticamente.} che viene attivato abilitando -l'opzione \texttt{CONFIG\_TMPFS} in fase di compilazione del kernel. +La memoria condivisa è stato il primo degli oggetti di IPC POSIX inserito nel +kernel ufficiale; il supporto a questo tipo di oggetti è realizzato attraverso +il filesystem \texttt{tmpfs}, uno speciale filesystem che mantiene tutti i +suoi contenuti in memoria,\footnote{il filesystem \texttt{tmpfs} è diverso da + un normale RAM disk, anch'esso disponibile attraverso il filesystem + \texttt{ramfs}, proprio perché realizza una interfaccia utilizzabile anche + per la memoria condivisa; esso infatti non ha dimensione fissa, ed usa + direttamente la cache interna del kernel (che viene usata anche per la + shared memory in stile SysV). In più i suoi contenuti, essendo trattati + direttamente dalla memoria virtuale\index{memoria~virtuale} possono essere + salvati sullo swap automaticamente.} che viene attivato abilitando l'opzione +\texttt{CONFIG\_TMPFS} in fase di compilazione del kernel. Per potere utilizzare l'interfaccia POSIX per le code di messaggi le diff --git a/netlayer.tex b/netlayer.tex index 4195888..b931172 100644 --- a/netlayer.tex +++ b/netlayer.tex @@ -1509,18 +1509,22 @@ l'indirizzo link-local e ricever \section{Il protocollo ICMP} -\label{sec:icmp_protocol} +\label{sec:ICMP_protocol} -Il protocollo ICMP \textit{Internet Control Message Protocol} è un protocollo -di servizio fondamentale per il funzionamento del livello di rete. I pacchetti +Come già accennato nelle sezioni precedenti, l'\textit{Internet Control + Message Protocol} è un protocollo di servizio fondamentale per il +funzionamento del livello di rete. Il protocollo ICMP viene trasportato +direttamente su IP, ma proprio per questa sua caratteristica di protocollo di +servizio è da considerarsi a tutti gli effetti appartenente al livello di +rete. \subsection{L'intestazione di ICMP} \label{sec:ICMP_header} - -In fig.~\ref{fig:ICMP_header} si è riportata la struttura dell'intestazione di -un pacchetto ICMP generico. +Il protocollo ICMP è estremamente semplice, ed il suo unico scopo è quello di +inviare messaggi di controllo; in fig.~\ref{fig:ICMP_header} si è riportata la +struttura dell'intestazione di un pacchetto ICMP generico. \begin{figure}[htb] \centering \includegraphics[width=12cm]{img/icmp_head} -- 2.30.2