From e20a546af590a50e7ac47f68f6c7d4648bb4f31a Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Mon, 19 Nov 2001 23:13:58 +0000 Subject: [PATCH] Passata generale di ispell --- elemtcp.tex | 38 +++++++++++++++++--------------------- errors.tex | 20 ++++++++++---------- filedir.tex | 46 +++++++++++++++++++++++----------------------- fileintro.tex | 14 +++++++------- filestd.tex | 15 ++++++++++++++- fileunix.tex | 4 ++-- ipprot.tex | 25 +++++++++++++------------ network.tex | 24 ++++++++++++------------ pref.tex | 4 ++-- process.tex | 12 ++++++------ session.tex | 11 +++++++++++ signal.tex | 8 ++++---- socket.tex | 38 +++++++++++++++++++------------------- 13 files changed, 140 insertions(+), 119 deletions(-) diff --git a/elemtcp.tex b/elemtcp.tex index 9d2df4a..effafc3 100644 --- a/elemtcp.tex +++ b/elemtcp.tex @@ -128,7 +128,7 @@ regolare la connessione. Normalmente vengono usate le seguenti opzioni: \textsl{finestra annunciata} (\textit{advertized window}) con la quale ciascun capo della comunicazione dichiara quanto spazio disponibile ha in memoria per i dati. Questo è un numero a 16 bit dell'header, che così può - indicare un massimo di 65535 bytes (anche se Linux usa come massimo 32767 + indicare un massimo di 65535 byte (anche se Linux usa come massimo 32767 per evitare problemi con alcuni stack bacati che usano l'aritmetica con segno per implementare lo stack TCP); ma alcuni tipi di connessione come quelle ad alta velocità (sopra i 45Mbits/sec) e quelle che hanno grandi @@ -210,7 +210,7 @@ che si mantenga un flusso di dati dal capo della connessione che deve ancora eseguire la chiusura passiva a quello che sta eseguendo la chiusura attiva. Nella sequenza indicata i dati verrebbero persi, dato che si è chiuso il socket dal lato che esegue la chiusura attiva; esistono tuttavia situazioni in -cui si vuole poter sfuttare questa possibilità, usando una procedura che è +cui si vuole poter sfruttare questa possibilità, usando una procedura che è chiamata \textit{half-close}; torneremo su questo aspetto e su come utilizzarlo più avanti, quando parleremo della funzione \func{shutdown}. @@ -275,12 +275,12 @@ ad assumere per i due lati, server e client. \end{figure} La connessione viene iniziata dal client che annuncia un MSS di 1460 (un -valore tipico per IPv4 su ethernet) con Linux, il server risponde con lo +valore tipico per IPv4 su Ethernet) con Linux, il server risponde con lo stesso valore (ma potrebbe essere anche un valore diverso). Una volta che la connessione è stabilita il client scrive al server una richiesta (che assumiamo stare in un singolo segmento, cioè essere minore dei -1460 bytes annunciati dal server), quest'ultimo riceve la richiesta e +1460 byte annunciati dal server), quest'ultimo riceve la richiesta e restituisce una risposta (che di nuovo supponiamo stare in un singolo segmento). Si noti che l'acknowledge della richiesta è mandato insieme alla risposta, questo viene chiamato \textit{piggybacking} ed avviene tutte le @@ -955,20 +955,16 @@ viene messo in attesa. Il prototipo della funzione operazione. \item \macro{EAGAIN} o \macro{EWOULDBLOCK} il socket è stato settato come non bloccante, e non ci sono connessioni in attesa di essere accettate. - \item \macro{EFAULT} l'argomento \var{addr} . - \item \macro{EPERM} Firewall rules forbid connection. - - \item \macro{ENOBUFS, ENOMEM} Not enough free memory. This often means - that the memory allocation is limited by the socket buffer limits, not by - the system memory. - - Inoltre possono essere restituiti gli errori di rete relativi al nuovo - socket come: \macro{EMFILE}, \macro{EINVAL}, \macro{ENOSR}, - \macro{ENOBUFS}, \macro{EPERM}, \macro{ECONNABORTED}, - \macro{ESOCKTNOSUPPORT}, \macro{EPROTONOSUPPORT}, \macro{ETIMEDOUT}, - \macro{ERESTARTSYS}. - + \item \macro{EPERM} Le regole del firewall non consentono la connessione. + \item \macro{ENOBUFS, ENOMEM} . Questo spesso significa che l'allocazione + della memoria è limitata dai limiti sui buffer dei socket, non dalla + memoria di sistema. \end{errlist} + Inoltre possono essere restituiti gli errori di rete relativi al nuovo + socket come: \macro{EMFILE}, \macro{EINVAL}, \macro{ENOSR}, \macro{ENOBUFS}, + \macro{EFAULT}, \macro{EPERM}, \macro{ECONNABORTED}, + \macro{ESOCKTNOSUPPORT}, \macro{EPROTONOSUPPORT}, \macro{ETIMEDOUT}, + \macro{ERESTARTSYS}. \end{prototype} La funzione può essere usata solo con socket che supportino la connessione @@ -977,8 +973,8 @@ La funzione pu esplicita della connessione, (attualmente in Linux solo DECnet ha questo comportamento), la funzione opera solo l'estrazione dalla coda delle connessioni, la conferma della connessione viene fatta implicitamente dalla -prima chiamata ad una \func{read} o una \func{write} mentre il rifiuto -della connessione viene fatto con la funzione \func{close}. +prima chiamata ad una \func{read} o una \func{write} mentre il rifiuto della +connessione viene fatto con la funzione \func{close}. È da chiarire che Linux presenta un comportamento diverso nella gestione degli errori rispetto ad altre implementazioni dei socket BSD, infatti la funzione @@ -993,7 +989,7 @@ I due argomenti \var{cliaddr} e \var{addrlen} (si noti che quest'ultimo l'indirizzo del client da cui proviene la connessione. Prima della chiamata \var{addrlen} deve essere inizializzato alle dimensioni della struttura il cui indirizzo è passato come argomento in \var{cliaddr}, al ritorno della -funzione \var{addrlen} conterrà il numero di bytes scritti dentro +funzione \var{addrlen} conterrà il numero di byte scritti dentro \var{cliaddr}. Se questa informazione non interessa basterà inizializzare a \macro{NULL} detti puntatori. @@ -1246,7 +1242,7 @@ In generale per questo avviene quando il server invece di far gestire la connessione direttamente a un processo figlio, come nell'esempio precedente, lancia un opportuno programma per ciascuna connessione usando \func{exec} (questa ad -esempio è la modailità con cui opera il \textsl{super-server} \cmd{inetd} +esempio è la modalità con cui opera il \textsl{super-server} \cmd{inetd} che gestisce tutta una serie di servizi lanciando per ogni connessione l'opportuno server). diff --git a/errors.tex b/errors.tex index 5f7958d..529d256 100644 --- a/errors.tex +++ b/errors.tex @@ -56,11 +56,11 @@ gestione dei file. che non è un \textit{block device} in un contesto in cui era necessario specificare un \textit{block device} (ad esempio si è tentato di montare un file ordinario). -\item \macro{EEXIST} \textit{File exists}. Si è specficato un file esistente - in un constesto in cui ha senso solo specificare un nuovo file. +\item \macro{EEXIST} \textit{File exists}. Si è specificato un file esistente + in un contesto in cui ha senso solo specificare un nuovo file. \item \macro{EBUSY} \textit{Resource busy}. Una risorsa di sistema che non può essere condivisa è occupata. Ad esempio si è tentato di cancellare la - directory su cui si è montato un filesistem. + directory su cui si è montato un filesystem. \item \macro{EXDEV} \textit{Cross-device link}. Si è tentato di creare un link diretto che attraversa due filesystem differenti. \item \macro{ENODEV} \textit{No such device}. Si è indicato un tipo di device @@ -107,7 +107,7 @@ gestione dei file. filesystem NFS. \item \macro{EREMOTE} \textit{Object is remote}. Si è fatto un tentativo di montare via NFS un filesystem remoto con un nome che già specifica un - filesystem montao via NFS. + filesystem montato via NFS. \item \macro{ENOLCK} \textit{No locks available}. È usato dalle utilità per la gestione del file lock; non viene generato da un sistema GNU, ma può risultare da un'operazione su un server NFS di un altro sistema. @@ -159,7 +159,7 @@ gestione dei socket e delle connessioni di rete. sbagliato per il socket. Il socket usato non supporta il protocollo di comunicazione richiesto. \item \macro{ENOPROTOOPT} \textit{Protocol not available}. Protocollo non - disponibile. Si è richiesta un'opzione per il socket non diponibile con il + disponibile. Si è richiesta un'opzione per il socket non disponibile con il protocollo usato. \item \macro{EPROTONOSUPPORT} \textit{Protocol not supported}. Protocollo non supportato. Il tipo di socket non supporta il protocollo richiesto (un @@ -167,7 +167,7 @@ gestione dei socket e delle connessioni di rete. \item \macro{ESOCKTNOSUPPORT} \textit{Socket type not supported}. Socket non supportato. Il tipo di socket scelto non è supportato. \item \macro{EOPNOTSUPP} \textit{Operation not supported on transport - endpoint}. L'operazione richesta non è supportata. Alcune funzioni non + endpoint}. L'operazione richiesta non è supportata. Alcune funzioni non hanno senso per tutti i tipi di socket, ed altre non sono implementate per tutti i protocolli di trasmissione. Questo errore quando un socket non supporta una particolare operazione, e costituisce una indicazione generica @@ -223,16 +223,16 @@ gestione dei socket e delle connessioni di rete. \item \macro{ECONNREFUSED} \textit{Connection refused}. Un host remoto ha rifiutato la connessione (in genere dipende dal fatto che non c'è un server per soddisfare il servizio richiesto). -\item \macro{EHOSTDOWN} \textit{Host is down}. L'host remorto di una +\item \macro{EHOSTDOWN} \textit{Host is down}. L'host remoto di una connessione è giù. -\item \macro{EHOSTUNREACH} \textit{No route to host}. L'host remorto di una +\item \macro{EHOSTUNREACH} \textit{No route to host}. L'host remoto di una connessione non è raggiungibile. \end{description} \section{Errori generici} In questa sezione sono raccolti i codici restituiti dalle funzioni di libreria -attinenti ad errori generici, si trovano qui tutti i cosici di errore non +attinenti ad errori generici, si trovano qui tutti i codici di errore non specificati nelle sezioni precedenti. \begin{description} @@ -247,7 +247,7 @@ specificati nelle sezioni precedenti. queste situazioni, nel qual caso si avrebbe in blocco. \item \macro{EFAULT} \textit{Bad address}. Una stringa passata come parametro è fuori dello spazio di indirizzi del processo, in genere questa situazione - provoca l'emissione di un sengale di \textit{segment violation} + provoca l'emissione di un segnale di \textit{segment violation} (\macro{SIGSEGV}). \item \macro{EINVAL} \textit{Invalid argument}. Errore utilizzato per segnalare vari tipi di problemi dovuti all'aver passato un argomento diff --git a/filedir.tex b/filedir.tex index 93af489..c9884c4 100644 --- a/filedir.tex +++ b/filedir.tex @@ -29,7 +29,7 @@ capitolo precedente. Una caratteristica comune a diversi sistemi operativi è quella di poter creare dei nomi fittizi (come gli alias del MacOS o i collegamenti di Windows) che -permettono di fare riferiremento allo stesso file chiamandolo con nomi diversi +permettono di fare riferimento allo stesso file chiamandolo con nomi diversi o accedendovi da directory diverse. Questo è possibile anche in ambiente unix, dove tali collegamenti sono @@ -86,7 +86,7 @@ essere cos Per quanto dicevamo in \secref{sec:file_filesystem} la creazione di un collegamento diretto è possibile solo se entrambi i pathname sono nello stesso filesystem; inoltre il filesystem deve supportare i collegamenti diretti (il -mneccanismo non è disponibile ad esempio con il filesystem \acr{vfat} di +meccanismo non è disponibile ad esempio con il filesystem \acr{vfat} di Windows). La funzione inoltre opera sia sui file ordinari che sugli altri oggetti del @@ -188,7 +188,7 @@ nello stesso filesystem) si usa invece la funzione \func{rename}\footnote{la \begin{prototype}{stdio.h} {int rename(const char *oldpath, const char *newpath)} - Rinomina \var{oldpath} in \var{newpth}, eseguendo se necessario lo + Rinomina \var{oldpath} in \var{newpath}, eseguendo se necessario lo spostamento di un file fra directory diverse. Eventuali altri link diretti allo stesso file non vengono influenzati. @@ -255,7 +255,7 @@ riferimento allo stesso file. Come abbiamo visto in \secref{sec:file_link} la funzione \func{link} crea riferimenti agli inodes, pertanto può funzionare soltanto per file che -risiedono sullo stesso filesysteme e solo per un filesystem di tipo unix. +risiedono sullo stesso filesystem e solo per un filesystem di tipo unix. Inoltre abbiamo visto che in Linux non è consentito eseguire un link diretto ad una directory. @@ -447,7 +447,7 @@ prototipo della prima \item \macro{EMLINK} La directory in cui si vuole creare la nuova directory contiene troppi file. Sotto Linux questo normalmente non avviene perché il filesystem standard consente la creazione di un numero di file maggiore di - quelli che possono essere contenuti nell'hard-disk, ma potendo avere a che + quelli che possono essere contenuti nel disco, ma potendo avere a che fare anche con filesystem di altri sistemi questo errore può presentarsi. \item \macro{ENOSPC} Non c'è abbastanza spazio sul file system per creare la nuova directory o si è esaurita la quota disco dell'utente. @@ -562,7 +562,7 @@ apposita funzione di libreria, \func{getcwd}, il cui prototipo Il buffer deve essere sufficientemente lungo da poter contenere il pathname completo più lo zero di terminazione della stringa. Qualora esso ecceda le -dimensioni specificate con \var{size} la funzione restituiece un errore. Si +dimensioni specificate con \var{size} la funzione restituisce un errore. Si può anche specificare un puntatore nullo come \var{buffer}\footnote{questa è una estensione allo standard POSIX.1, supportata da Linux}, nel qual caso la stringa sarà allocata automaticamente per una dimensione pari a \var{size} @@ -1249,19 +1249,19 @@ corrispondono dell'utente con cui si Se però il file del programma\footnote{per motivi di sicurezza il kernel ignora i bit \acr{suid} e \acr{sgid} per gli script eseguibili} (che ovviamente deve essere eseguibile) ha il bit \acr{suid} settato, il kernel -assegnerà come \textit{effective user id} al nuovo processo l'uid del -proprietario del file al posto dell'uid del processo originario. Avere il bit -\acr{sgid} settato ha lo stesso effetto sull'\textit{effective group id} del -processo. - -I bit \acr{suid} e \acr{sgid} vengono usati per permettere agli utenti -normali di usare programmi che abbisognano di privilegi speciali; l'esempio -classico è il comando \cmd{passwd} che ha la necessità di modificare il file -delle password, quest'ultimo ovviamente può essere scritto solo -dall'amministratore, ma non è necessario chiamare l'amministratore per -cambiare la propria password. Infatti il comando \cmd{passwd} appartiene a -root ma ha il bit suid settato per cui quando viene lanciato da un utente -normale parte con i privilegi di root. +assegnerà come \textit{effective user id} al nuovo processo l'\acr{uid} del +proprietario del file al posto dell'\acr{uid} del processo originario. Avere +il bit \acr{sgid} settato ha lo stesso effetto sull'\textit{effective group + id} del processo. + +I bit \acr{suid} e \acr{sgid} vengono usati per permettere agli utenti normali +di usare programmi che abbisognano di privilegi speciali; l'esempio classico è +il comando \cmd{passwd} che ha la necessità di modificare il file delle +password, quest'ultimo ovviamente può essere scritto solo dall'amministratore, +ma non è necessario chiamare l'amministratore per cambiare la propria +password. Infatti il comando \cmd{passwd} appartiene a root ma ha il bit +\acr{suid} settato per cui quando viene lanciato da un utente normale parte +con i privilegi di root. Chiaramente avere un processo che ha privilegi superiori a quelli che avrebbe normalmente l'utente che lo ha lanciato comporta vari rischi, e questo tipo di @@ -1353,11 +1353,11 @@ invece prevede due diverse possibilit \begin{itemize} \item il \acr{gid} del file corrisponde all'\textit{effective group id} del processo. -\item il \acr{gid} del file corrisponde al gid della directory in cui esso è - creato. +\item il \acr{gid} del file corrisponde al \acr{gid} della directory in cui + esso è creato. \end{itemize} in genere BSD usa sempre la seconda possibilità, che viene per questo chiamata -semantica BSD. Linux invece segue quella che viene chiamata semantica SVR4; di +semantica BSD. Linux invece segue quella che viene chiamata semantica SVr4; di norma cioè il nuovo file viene creato, seguendo la prima opzione, con il \acr{gid} del processo, se però la directory in cui viene creato il file ha il bit \acr{sgid} settato allora viene usata la seconda opzione. @@ -1470,7 +1470,7 @@ divisibili in gruppi di tre). Ad esempio i permessi standard assegnati ai nuovi file (lettura e scrittura per il proprietario, sola lettura per il gruppo e gli altri) sono corrispondenti al valore ottale $0644$, un programma invece avrebbe anche il bit di esecuzione attivo, con un valore di $0755$, se -si volesse attivare il bit suid il valore da fornire sarebbe $4755$. +si volesse attivare il bit \acr{suid} il valore da fornire sarebbe $4755$. \begin{table}[!htb] \centering diff --git a/fileintro.tex b/fileintro.tex index c786f22..640affb 100644 --- a/fileintro.tex +++ b/fileintro.tex @@ -199,7 +199,7 @@ L'interfaccia bufferizzato in quanto la lettura e la scrittura vengono eseguite chiamando direttamente le system call del kernel (in realtà il kernel effettua al suo interno alcune bufferizzazioni per aumentare l'efficienza nell'accesso ai -dispositivi); i file descriptors sono rappresentati da numeri interi (cioè +dispositivi); i file descriptor sono rappresentati da numeri interi (cioè semplici variabili di tipo \type{int}). L'interfaccia è definita nell'header \file{unistd.h}. @@ -217,7 +217,7 @@ del C, si accede ad essi sempre in maniera indiretta utilizzando il tipo Entrambe le interfacce possono essere usate per l'accesso ai file come agli altri oggetti del VFS (pipe, socket, device), ma per poter accedere alle operazioni di controllo sul particolare tipo di oggetto del VFS scelto occorre -usare l'interfaccia standard di unix coi file descriptors. Allo stesso modo +usare l'interfaccia standard di unix coi file descriptor. 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 \secref{sec:file_noblocking}). @@ -377,7 +377,7 @@ Il primo oggetto usato dal VFS una apposita struttura che contiene vari dati come le informazioni comuni ad ogni filesystem, i dati privati relativi a quel filesystem specifico, e i puntatori alle funzioni del kernel relative al filesystem. Il VFS può così -usare le funzioni contenute nel filesystem decriptor per accedere alle routine +usare le funzioni contenute nel filesystem descriptor per accedere alle routine specifiche di quel filesystem. Gli altri due descrittori usati dal VFS sono relativi agli altri due oggetti @@ -605,14 +605,14 @@ seguenti: kernel quando agisce su gruppi di file. Possono essere settati su file e directory e in quest'ultimo caso i nuovi file creati nella directory ereditano i suoi attributi. -\item sono supportate entrambe le semantiche di BSD e SYSV come opzioni di +\item sono supportate entrambe le semantiche di BSD e SVr4 come opzioni di montaggio. La semantica BSD comporta che i file in una directory sono creati con lo stesso identificatore di gruppo della directory che li contiene. La - semantica SYSV comporta che i file vengono creati con l'identificatore del + semantica SVr4 comporta che i file vengono creati con l'identificatore del gruppo primario del processo, eccetto il caso in cui la directory ha il bit di \acr{sgid} settato (per una descrizione dettagliata del significato di questi termini si veda \secref{sec:file_access_control}), nel qual caso file - e sotto-directory ereditano sia il \acr{gid} che lo \acr{sgid}. + e subdirectory ereditano sia il \acr{gid} che lo \acr{sgid}. \item l'amministratore può scegliere la dimensione dei blocchi del filesystem in fase di creazione, a seconda delle sue esigenze (blocchi più grandi permettono un accesso più veloce, ma sprecano più spazio disco). @@ -644,7 +644,7 @@ superblock principale. \label{fig:file_ext2_dirs} \end{figure} -L'utilizzo di raggrupamenti di blocchi ha inoltre degli effetti positivi nelle +L'utilizzo di raggruppamenti di blocchi ha inoltre degli effetti positivi nelle prestazioni dato che viene ridotta la distanza fra i dati e la tabella degli inode. diff --git a/filestd.tex b/filestd.tex index 55ad9c1..297d2a8 100644 --- a/filestd.tex +++ b/filestd.tex @@ -18,7 +18,7 @@ contengono tutte le informazioni necessarie a gestire le operazioni sugli stream, come la posizione corrente, lo stato del buffer e degli indicatori di stato e di fine del file. Per questo motivo gli utenti non devono mai utilizzare direttamente o allocare queste strutture, ma usare sempre puntatori -del tipo \type{FILE *} (tanto che in certi caso il termine di puntatore a file +del tipo \type{FILE *} (tanto che in certi casi il termine di puntatore a file è diventato sinonimo di stream). \subsection{Gli stream standard} @@ -46,30 +46,41 @@ tre stream sono definiti nell'header \file{stdio.h} e sono: \subsection{La bufferizzazione} \label{sec:file_buffering} + + \section{Funzioni base} \label{sec:file_ansi_base_func} + \subsection{Apertura di uno stream} \label{sec:file_fopen} + \subsection{Lettura e scrittura su uno stream} \label{sec:file_io} + \subsection{Posizionamento su uno stream} \label{sec:file_fseek} + \subsection{Input/output binario} \label{sec:file_binary_io} + \subsection{Input/output di linea} \label{sec:file_line_io} + \subsection{Input/output formattato} \label{sec:file_formatted_io} + \subsection{Chiusura di uno stream} \label{sec:file_fclose} + + \section{Funzioni avanzate} \label{sec:file_stream_adv_func} @@ -77,9 +88,11 @@ tre stream sono definiti nell'header \file{stdio.h} e sono: \subsection{Dettagli dell'implementazione} \label{sec:file_stream_details} + \subsection{File temporanei} \label{sec:file_temp_file} + \subsection{Efficienza} \label{sec:file_stream_efficiency} diff --git a/fileunix.tex b/fileunix.tex index 8c33fa3..5c1ab7c 100644 --- a/fileunix.tex +++ b/fileunix.tex @@ -917,7 +917,7 @@ valori \macro{SIGURG} per gli eventi associati al file descriptor \var{fd}. Il process group è restituito come valore negativo. \item[\macro{F\_SETOWN}] setta il processo o process group che riceverà i - sengali \macro{SIGIO} e \macro{SIGURG} per gli eventi associati al file + segnali \macro{SIGIO} e \macro{SIGURG} per gli eventi associati al file descriptor \var{fd}. I process group sono settati usando valori negativi. \item[\macro{F\_GETSIG}] restituisce il segnale mandato quando ci sono dati disponibili in input sul file descriptor. Il valore 0 indica il default (che @@ -961,7 +961,7 @@ per ogni singolo dispositivo. Il prototipo di questa funzione l'informazione necessaria al dispositivo. La funzione nella maggior parte dei casi ritorna 0, alcune operazioni usano - però il valore di ritorno per restituire informazoni. In caso di errore + però il valore di ritorno per restituire informazioni. In caso di errore viene sempre restituito -1 e \var{errno} viene settata ad uno dei valori seguenti: \begin{errlist} diff --git a/ipprot.tex b/ipprot.tex index c02ba10..c366d89 100644 --- a/ipprot.tex +++ b/ipprot.tex @@ -1,7 +1,7 @@ \chapter{Il protocollo IP} \label{cha:ip_protocol} -L'attuale Internent Protocol (IPv4) viene standardizzato nel 1981 +L'attuale Internet Protocol (IPv4) viene standardizzato nel 1981 dall'RFC~719; esso nasce per disaccoppiare le applicazioni della struttura hardware delle reti di trasmissione, e creare una interfaccia di trasmissione dei dati indipendente dal sottostante substrato di rete, che può essere @@ -175,7 +175,7 @@ indirizzi disponibili. In realtà il problema non è propriamente legato al numero di indirizzi disponibili; infatti con 32 bit si hanno $2^{32}$, cioè circa 4 miliardi, -numeri diversi possibili, che sono molti di più dei computer attualemente +numeri diversi possibili, che sono molti di più dei computer attualmente esistenti. Il punto è che la suddivisione di questi numeri nei due livelli rete/host e @@ -301,7 +301,7 @@ numero dei campi da 12 a 8. \textsl{etichetta di flusso}, vedi Sez.~\ref{sec:IP_ipv6_flow}\\ \textit{payload leght} & 16 bit & \textsl{lunghezza del carico}, cioè del corpo dei dati che segue - l'intestazione, in bytes. \\ + l'intestazione, in byte. \\ \textit{next header} & 8 bit & \textsl{testata successiva}, identifica il tipo di pacchetto che segue la testata di IPv6, usa gli stessi valori del campo protocollo nella testata di IPv4\\ @@ -346,7 +346,7 @@ di IPv4 (vedi \secref{tab:IP_ipv4head}) mostra le seguenti differenze: necessità di ricalcolare la checksum ad ogni passaggio di un pacchetto per il cambiamento del campo \textit{hop limit}. \item è stato eliminato il campo \textit{type of service}, che praticamente - non è mai stato utilizzato; una parte delle funzionalià ad esso delegate + non è mai stato utilizzato; una parte delle funzionalità ad esso delegate sono state reimplementate (vedi il campo \textit{priority} al prossimo punto) con altri metodi. \item è stato introdotto un nuovo campo \textit{flow label}, che viene usato, @@ -453,7 +453,7 @@ quello di IPv6 sono le seguenti: \item IPv6 richiede il supporto per il \textit{path MTU discovery} (cioè il protocollo per la selezione della massima lunghezza del pacchetto); seppure questo sia in teoria opzionale, senza di esso non sarà possibile inviare - pacchetti più larghi della dimensione minima (576 bytes). + pacchetti più larghi della dimensione minima (576 byte). \end{itemize} \section{Gli indirizzi di IPv6} @@ -659,7 +659,7 @@ gestione dei singoli fruitori finali, gli indirizzi \textit{provider-based} lasciano normalmente gli ultimi 64~bit a disposizione per questo livello, la modalità più immediata è quella di usare uno schema del tipo mostrato in \tabref{tab:IP_ipv6_uninterf} dove l'\textit{Interface Id} è dato dal -MAC-address a 48~bit dello standard ethernet, scritto in genere nell'hardware +MAC-address a 48~bit dello standard Ethernet, scritto in genere nell'hardware delle scheda di rete, e si usano i restanti 16~bit per indicare la sottorete. \begin{table}[htb] @@ -976,7 +976,7 @@ protocollo di trasporto. Per aumentare la velocità di processo, sia dei dati del livello seguente che di ulteriori opzioni, ciascuna estensione deve avere una lunghezza multipla di -8 bytes per mantenere l'allineamento a 64~bit di tutti le testate seguenti. +8 byte per mantenere l'allineamento a 64~bit di tutti le testate seguenti. Dato che la maggior parte di queste estensioni non sono esaminate dai router durante l'instradamento e la trasmissione dei pacchetti, ma solo all'arrivo @@ -985,7 +985,7 @@ prestazioni rispetto a IPv4 dove la presenza di un'opzione comportava l'esame di tutte quante. Un secondo miglioramento è che rispetto a IPv4 le opzioni possono essere di -lunghezza arbitraria e non limitate a 40 bytes; questo, insieme al modo in cui +lunghezza arbitraria e non limitate a 40 byte; questo, insieme al modo in cui vengono trattate, consente di utilizzarle per scopi come l'autenticazione e la sicurezza, improponibili con IPv4. @@ -1147,7 +1147,7 @@ trovi in mezzo. Con IPv4 non è possibile realizzare un meccanismo di autenticazione e riservatezza a un livello inferiore al primo (quello di applicazione), con IPv6 è stato progettata la possibilità di intervenire al livello del -collegamento (il terzo) prevendo due apposite estensioni che possono essere +collegamento (il terzo) prevedendo due apposite estensioni che possono essere usate per fornire livelli di sicurezza a seconda degli utenti. La codifica generale di questa architettura è riportata nell'RFC 2401. @@ -1167,7 +1167,7 @@ il nome di associazione di sicurezza. I pacchetti autenticati e crittografati portano un indice dei parametri di sicurezza (SPI, \textit{Security Parameter Index}) che viene negoziato prima di ogni comunicazione ed è definito dalla stazione sorgente. Nel caso di -multicast dovà essere lo stesso per tutte le stazioni del gruppo. +multicast dovrà essere lo stesso per tutte le stazioni del gruppo. \subsection{Autenticazione} Il primo meccanismo di sicurezza è quello della testata di autenticazione @@ -1184,7 +1184,7 @@ di sicurezza, e un numero di sequenza che la stazione sorgente deve incrementare di pacchetto in pacchetto. Completano la testata i dati di autenticazione che contengono un valore di -controllo di intgrità (ICV, \textit{Integrity Check Value}), che deve essere +controllo di integrità (ICV, \textit{Integrity Check Value}), che deve essere di dimensione pari a un multiplo intero di 32 bit e può contenere un padding per allineare la testata a 64 bit. Tutti gli algoritmi di autenticazione devono provvedere questa capacità. @@ -1255,7 +1255,7 @@ prima che dopo. \end{pspicture} \end{center} -La modalit`\a tunnel può essere utilizzata sia per comunicazioni fra stazioni +La modalità tunnel può essere utilizzata sia per comunicazioni fra stazioni singole che con un gateway di sicurezza; in questa modalità @@ -1284,6 +1284,7 @@ ancora in fase di definizione; attualmente modifica dell'MD5 chiamata \textit{keyed MD5} che combina alla codifica anche una chiave che viene inserita all'inizio e alla fine degli altri campi. + \subsection{Riservatezza} \label{sec:ecry} diff --git a/network.tex b/network.tex index 9f84d7d..49c6a5f 100644 --- a/network.tex +++ b/network.tex @@ -90,7 +90,7 @@ livelli, secondo quanto riportato in \ntab. \label{tab:net_osilayers} \end{table} -Il modello ISO/OSI è stato sviluppato corrispondentemente alla definizione +Il modello ISO/OSI è stato sviluppato in corrispondenza alla definizione della serie di protocolli X.25 per la commutazione di pacchetto. Ma nonostante il lavoro dettagliato di standardizzazione il modello si è rivelato sostanzialmente troppo complesso e poco flessibile rispetto a quello, @@ -171,7 +171,7 @@ lo scambio di informazione su ciascuno livello. \label{fig:net_tcpip_data_flux} \end{figure} -La struttura della comuniczione pertanto si può riassumere nei seguenti passi: +La struttura della comunicazione pertanto si può riassumere nei seguenti passi: \begin{itemize} \item Le singole applicazioni si scambieranno i dati secondo un loro formato specifico, implementando un protocollo di applicazione (esempi possono @@ -192,7 +192,7 @@ La struttura della comuniczione pertanto si pu \item L'ultimo passo è il trasferimento del pacchetto al driver della interfaccia di trasmissione che si incarica di incapsularlo nel relativo protocollo di trasmissione fisica usato dall'hardware usato per la - comunicazione (ad esempio ethernet per una scheda di rete). + comunicazione (ad esempio Ethernet per una scheda di rete). \end{itemize} @@ -308,7 +308,7 @@ I vari protocolli mostrati in figura sono i seguenti: \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 + internet). È usato in reti di tipo broadcast come Ethernet, Token Ring o FDDI ma non serve in connessioni punto-punto. \item \textsl{RARP} \textit{Reverse Address Resolution Protocol}. È il protocollo che mappa un indirizzo hardware in un indirizzo IP. Viene usato a @@ -463,9 +463,9 @@ cadere facilmente in timeout. Inoltre TCP è in grado di preservare l'ordine dei dati assegnando un numero di sequenza ad ogni byte che trasmette. Ad esempio se un'applicazione scrive 3000 -bytes su un socket TCP, questi potranno essere spezzati dal protocollo in due +byte su un socket TCP, questi potranno essere spezzati dal protocollo in due segmenti (le unità di dati passate da TCP a IP vengono chiamate -\textit{segment}) di 1500 bytes, di cui il primo conterrà il numero di +\textit{segment}) di 1500 byte, di cui il primo conterrà il numero di sequenza $1-1500$ e il secondo il numero $1501-3000$. In questo modo anche se i segmenti arrivano a destinazione in un ordine diverso, o se alcuni arrivano più volte a causa di ritrasmissioni dovute alla perdita dei ricevuto, @@ -506,18 +506,18 @@ delle applicazioni. Un elenco di questi limiti è il seguente, insieme ad un breve accenno alle loro origini ed alle eventuali implicazioni che possono avere: \begin{itemize} -\item La dimensione massima di un pacchetti IP è di 65535 bytes, compreso +\item La dimensione massima di un pacchetti IP è di 65535 byte, compreso l'header. Questo è dovuto al fatto che la dimensione è indicata da un campo apposito nell'header di IP che è lungo 16 bit (vedi \tabref{tab:IP_ipv4head}). -\item La dimensione massima di un pacchetto normale di IPv6 è di 65575 bytes, +\item La dimensione massima di un pacchetto normale di IPv6 è di 65575 byte, 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 suddetto campo. Inoltre IPv6 ha la possibilità di estendere la dimensione di un pacchetto usando la \textit{jumbo payload option}. -\item Molte reti fisiche hanno un MTU (\textit{maximum tranfer unit}) che +\item Molte reti fisiche hanno un MTU (\textit{maximum transfer unit}) che dipende dal protocollo specifico usato al livello di link. Il più comune è - quello dell'ethernet che è pari a 1500 bytes, una serie di valori possibili + quello dell'Ethernet che è pari a 1500 byte, una serie di valori possibili sono riportati in \ntab. \end{itemize} @@ -544,7 +544,7 @@ possono essere trasmessi attraverso l'interfaccia. X.25 & 576 \\ \hline \end{tabular} - \caption{Valori della MTU (\textit{maximum tranfer unit}) per una serie di + \caption{Valori della MTU (\textit{maximum transfer unit}) per una serie di reti diverse.} \label{tab:net_mtu_values} \end{table} @@ -567,7 +567,7 @@ Nell'header di IPv4 pacchetto non deve essere frammentato; un router che riceva un pacchetto le cui dimensioni eccedano quelle dell'MTU della rete di destinazione genererà un messaggio di errore ICMPv4 di tipo \textit{destination unreachable, - fragentation needed but DF bit set}. + fragmentation needed but DF bit set}. Dato che i router IPv6 non possono effettuare la frammentazione la ricezione di un pacchetto di dimensione eccessiva per la ritrasmissione genererà sempre diff --git a/pref.tex b/pref.tex index 25e07dc..c68ee81 100644 --- a/pref.tex +++ b/pref.tex @@ -4,7 +4,7 @@ Nelle motivazioni in cui si introduce la GNU Free Documentation License (FDL) (reperibili su http://www.gnu.org/philosophy/free-doc.html) si dà una grande rilevanza all'importanza di disporre di buoni manuali, in quanto la fruibilità -e la possilità di usare appieno il software libero, vengono notevolmente +e la possibilità di usare appieno il software libero, vengono notevolmente ridotte senza la presenza di un valido manuale che sia altrettanto liberamente disponibile. @@ -60,7 +60,7 @@ particolare il compilatore usato per provare tutti i programmi e gli esempi descritti nel testo è lo GNU GCC. Infine, dato che lo scopo del progetto è la produzione di un libro, si è -scelto di usare Latex come "ambiente di sviluppo" del medesimo, sia per +scelto di usare LaTex come "ambiente di sviluppo" del medesimo, sia per l'impareggiabile qualità tipografica ottenibile, che per la congruenza dello strumento, tanto sul piano pratico, quanto su quello filosofico. diff --git a/process.tex b/process.tex index 66a6e20..ed4cb07 100644 --- a/process.tex +++ b/process.tex @@ -570,7 +570,7 @@ questa viene rilasciata automaticamente al ritorno della funzione. Come è evidente questa funzione ha molti vantaggi, e permette di evitare i problemi di memory leak non essendo più necessaria la deallocazione esplicita; una delle ragioni principali per usarla è però che funziona anche quando si -usa \func{longjump} per uscire con un salto non locale da una funzione (vedi +usa \func{longjmp} per uscire con un salto non locale da una funzione (vedi \secref{sec:proc_longjmp}), Un altro vantaggio e che in Linux la funzione è molto veloce e non viene @@ -712,7 +712,7 @@ Le funzioni per bloccare e sbloccare singole sezioni di memoria sono caso \var{errno} è settata ad uno dei valori seguenti: \begin{errlist} \item \macro{ENOMEM} alcuni indirizzi dell'intervallo specificato non - corripondono allo spazio di indirizzi del processo o si è ecceduto il + corrispondono allo spazio di indirizzi del processo o si è ecceduto il numero massimo consentito di pagine bloccate. \item \macro{EPERM} il processo non ha i privilegi richiesti per l'operazione. @@ -727,7 +727,7 @@ Le funzioni per bloccare e sbloccare singole sezioni di memoria sono \var{errno} è settata ad uno dei valori seguenti: \begin{errlist} \item \macro{ENOMEM} alcuni indirizzi dell'intervallo specificato non - corripondono allo spazio di indirizzi del processo. + corrispondono allo spazio di indirizzi del processo. \item \macro{EINVAL} \var{len} non è un valore positivo. \end{errlist} \end{functions} @@ -1018,7 +1018,7 @@ anche altre: per una lista pi Lo standard ANSI C, pur lasciando alle varie implementazioni i contenuti, definisce la funzione \func{getenv} che permetta di ottenere i valori delle -varibili di ambiente, il suo prototipo è: +variabili di ambiente, il suo prototipo è: \begin{prototype}{stdlib.h}{char *getenv(const char *name)} Esamina l'ambiente del processo cercando una stringa che corrisponda a @@ -1123,14 +1123,14 @@ prototipo La funzione ritorna zero quando è chiamata direttamente e un valore diverso da zero quando ritorna da una chiamata di \func{longjmp} che usa il contesto - salvato in predenza. + salvato in precedenza. \funcdecl{void longjmp(jmp\_buf env, int val)} Ripristina il contesto dello stack salvato dall'ultima chiamata di \func{setjmp} con l'argomento \param{env}. Il programma prosegue dal ritorno di \func{setjmp} con un valore \param{val}. Il valore di \param{val} deve - essere diverso da zero, se viene specficato 0 sarà usato 1 al suo posto. + essere diverso da zero, se viene specificato 0 sarà usato 1 al suo posto. La funzione non ritorna. \end{functions} diff --git a/session.tex b/session.tex index 3de0e52..634a5f7 100644 --- a/session.tex +++ b/session.tex @@ -1,30 +1,41 @@ \chapter{Il controllo di sessione} \label{cha:session} + + \section{Il login} \label{sec:sess_login} + \subsection{Il login da terminale} \label{sec:sess_term_log} + \subsection{Il login via rete} \label{sec:sess_net_log} + \section{Le relazioni fra i processi} \label{sec:sess_relation} + \subsection{I \textit{process group}} \label{sec:sess_proc_group} + \subsection{Le sessioni} \label{sec:sess_sessions} + \subsection{Il terminale di controllo} \label{sec:sess_ctrl_term} + + \section{Il \textit{job control}} \label{sec:sess_job_control} + \subsection{La shell e i programmi} \label{sec:sess_shell} diff --git a/signal.tex b/signal.tex index b675fde..a73b7fc 100644 --- a/signal.tex +++ b/signal.tex @@ -74,7 +74,7 @@ int sig_handler() \end{lstlisting} \normalsize se un secondo segnale arriva prima che il manipolatore invocato dal primo -abbia eseguito la re-installazione di se stesso il segnale può essere perso o +abbia eseguito la reinstallazione di se stesso il segnale può essere perso o causare il comportamento originale assegnato al segnale (in genere la terminazione del processo). @@ -129,7 +129,7 @@ il processo rester % Un'altra caratteristica della implementazione inaffidabile è che le chiamate % di sistema non sono fatte ripartire automaticamente quando sono interrotte da % un segnale, per questo un programma deve controllare lo stato di uscita della -% chiamata al sistema e riperterla nel caso l'errore riportato da \texttt{errno} +% chiamata al sistema e ripeterla nel caso l'errore riportato da \texttt{errno} % sia \texttt{EINTR}. Questo ci mostra ad esempio come con la semantica inaffidabile non esista una @@ -402,7 +402,7 @@ Questi segnali sono: % Per questo segnale le cose sono complicate dal fatto che possono esserci % molte diverse eccezioni che \texttt{SIGFPE} non distingue, mentre lo -% standard IEEE per le operazioni in virgola mobile definisce vaire eccezioni +% standard IEEE per le operazioni in virgola mobile definisce varie eccezioni % aritmetiche e richiede che esse siano notificate. \item[\macro{SIGILL}] Il nome deriva da \textit{illegal instruction}, @@ -425,7 +425,7 @@ Questi segnali sono: inizializzato leggendo al di la della fine di un vettore. \item[\macro{SIGBUS}] Il nome deriva da \textit{bus error}. Come \macro{SIGSEGV} questo è un segnale che viene generato di solito quando si - dereferenzia un puntatore non inzializzato, la differenza è che + dereferenzia un puntatore non inizializzato, la differenza è che \macro{SIGSEGV} indica un accesso non permesso su un indirizzo esistente (tipo fuori dallo heap o dallo stack), mentre \macro{SIGBUS} indica l'accesso ad un indirizzo non valido, come nel caso di un puntatore non diff --git a/socket.tex b/socket.tex index b8d1a19..e5fc8ae 100644 --- a/socket.tex +++ b/socket.tex @@ -35,7 +35,7 @@ Quella dei socket costituisce infatti la principale API (\textit{Application Program Interface}) usata nella programmazione di rete. La loro origine risale al 1983, quando furono introdotti nel BSD 4.2; l'interfaccia è rimasta sostanzialmente la stessa con piccole modifiche negli anni successivi. Benché -siano state sviluppate interfacce alternative, originate dai sistemi SYSV, +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à). @@ -65,7 +65,7 @@ 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 -comunicazione considerano i dati come una sequenza continua di bytes, altri +comunicazione considerano i dati come una sequenza continua di byte, altri invece li raggruppano in blocchi (i pacchetti). Un'altro esempio di stile concerne la possibilità che la comunicazione possa o @@ -297,7 +297,7 @@ 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 \type{void *}), ma l'interfaccia dei socket è antecendente alla +(i \type{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: @@ -498,7 +498,7 @@ due forme un file (di tipo socket) nel filesystem o una stringa univoca (tenuta in uno spazio di nomi astratto). Nel primo caso l'indirizzo viene specificato come una stringa (terminata da uno zero) corrispondente al pathname del file; nel secondo invece \var{sun\_path} inizia con uno zero -vengono usati i restanti bytes come stringa (senza terminazione). +vengono usati i restanti byte come stringa (senza terminazione). % \subsection{Il passaggio delle strutture} @@ -570,7 +570,7 @@ questi cambiamenti. Il problema connesso all'endianess è che quando si passano dei dati da un tipo di architettura all'altra i dati vengono interpretati in maniera diversa, e ad -esempio nel caso dell'intero a 16 bit ci si ritroverà con i due bytes in cui è +esempio nel caso dell'intero a 16 bit ci si ritroverà con i due byte in cui è suddiviso scambiati di posto, e ne sarà quindi invertito l'ordine di lettura per cui, per riavere il valore originale dovranno essere rovesciati. @@ -699,7 +699,7 @@ seguenti: indirizzi valida. \end{prototype} -Gli indirizzi vengono cnovertiti da/alle rispettive strutture di indirizzo +Gli indirizzi vengono convertiti da/alle rispettive strutture di indirizzo (\var{struct in\_addr} per IPv4, e \var{struct in6\_addr} per IPv6), che devono essere precedentemente allocate e passate attraverso il puntatore \var{addr\_ptr}; il parametro \var{dest} di \func{inet\_ntop} non può essere @@ -716,7 +716,7 @@ Il formato usato per gli indirizzi in formato di presentazione Per evitare di rendere questa introduzione ai socket puramente teorica iniziamo con il mostrare un esempio di un client TCP elementare. Prima di -passare agli esempi del client e del server, esamimeremo una caratteristica +passare agli esempi del client e del server, esamineremo una caratteristica delle funzioni di I/O sui socket che ci tornerà utile anche in seguito. @@ -729,14 +729,14 @@ comportamento che avrebbero con i normali files (in particolare questo accade per i socket di tipo stream). Infatti con i socket è comune che funzioni come \func{read} o \func{write} -possano restituire in input o scrivere in output un numero di bytes minore di +possano restituire in input o scrivere in output un numero di byte minore di quello richiesto. Come già accennato in \secref{sec:file_read} questo è un comportamento normale anche per l'I/O su file, e succede perché si eccede in lettura o scrittura il limite di buffer del kernel. In questo caso tutto quello che il programma chiamante deve fare è di ripetere -la lettura (o scrittura) per la quantità di bytes rimanenti (lo stesso può -avvenire scrivendo più di 4096 bytes in una pipe, dato che quello è il limite +la lettura (o scrittura) per la quantità di byte rimanenti (lo stesso può +avvenire scrivendo più di 4096 byte in una pipe, dato che quello è il limite di solito adottato per il buffer di trasmissione del kernel). \begin{figure}[htb] @@ -767,14 +767,14 @@ ssize_t SockRead(int fd, void *buf, size_t count) return (count - nleft); } \end{lstlisting} - \caption{Funzione \func{SockRead}, legge \var{count} bytes da un socket } + \caption{Funzione \func{SockRead}, legge \var{count} byte da un socket } \label{fig:sock_SockRead_code} \end{figure} Per questo motivo seguendo l'esempio di W. R. Stevens si sono definite due funzioni \func{SockRead} e \func{SockWrite} che eseguono la lettura da un socket tenendo conto di questa caratteristica, ed in grado di ritornare dopo -avere letto o scritto esattamente il numero di bytes specificato; il sorgente +avere letto o scritto esattamente il numero di byte specificato; il sorgente è riportato in \curfig\ e \nfig\ ed è disponibile fra i sorgenti allegati alla guida nei files \file{SockRead.c} e \file{SockWrite.c}. @@ -804,19 +804,19 @@ ssize_t SockWrite(int fd, const void *buf, size_t count) return (count); } \end{lstlisting} - \caption{Funzione \func{SockWrite}, scrive \var{count} bytes su un socket } + \caption{Funzione \func{SockWrite}, scrive \var{count} byte su un socket } \label{fig:sock_SockWrite_code} \end{figure} Come si può notare le funzioni ripetono la lettura/scrittura in un ciclo fino -all'esaurimento del numero di bytes richiesti, in caso di errore viene +all'esaurimento del numero di byte richiesti, in caso di errore viene controllato se questo è \macro{EINTR} (cioè un'interruzione della system call dovuta ad un segnale), nel qual caso l'accesso viene ripetuto, altrimenti l'errore viene ritornato interrompendo il ciclo. -Nel caso della lettura, se il numero di bytes letti è zero, significa che si è +Nel caso della lettura, se il numero di byte letti è zero, significa che si è arrivati alla fine del file e pertanto si ritorna senza aver concluso la -lettura di tutti i bytes richiesti. +lettura di tutti i byte richiesti. @@ -839,7 +839,7 @@ restituisce l'ora locale della macchina a cui si effettua la richiesta. \begin{lstlisting}{} #include /* predefined types */ #include /* include unix standard library */ -#include /* IP addresses conversion utiliites */ +#include /* IP addresses conversion utilities */ #include /* socket library */ #include /* include standard I/O library */ @@ -898,7 +898,7 @@ pu 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 +comando (effettuata con le apposite routine illustrate in \capref{sec:proc_opt_handling}). Il primo passo (\texttt{\small 14--18}) è creare un \textit{socket} IPv4 @@ -961,7 +961,7 @@ directory \file{sources}. \begin{lstlisting}{} #include /* predefined types */ #include /* include unix standard library */ -#include /* IP addresses conversion utiliites */ +#include /* IP addresses conversion utilities */ #include /* socket library */ #include /* include standard I/O library */ #include -- 2.30.2