Passata generale di ispell
authorSimone Piccardi <piccardi@gnulinux.it>
Mon, 19 Nov 2001 23:13:58 +0000 (23:13 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Mon, 19 Nov 2001 23:13:58 +0000 (23:13 +0000)
13 files changed:
elemtcp.tex
errors.tex
filedir.tex
fileintro.tex
filestd.tex
fileunix.tex
ipprot.tex
network.tex
pref.tex
process.tex
session.tex
signal.tex
socket.tex

index 9d2df4a..effafc3 100644 (file)
@@ -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).
 
index 5f7958d..529d256 100644 (file)
@@ -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
index 93af489..c9884c4 100644 (file)
@@ -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
index c786f22..640affb 100644 (file)
@@ -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. 
 
index 55ad9c1..297d2a8 100644 (file)
@@ -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}
 
index 8c33fa3..5c1ab7c 100644 (file)
@@ -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}
index c02ba10..c366d89 100644 (file)
@@ -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}
 
index 9f84d7d..49c6a5f 100644 (file)
@@ -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
index 25e07dc..c68ee81 100644 (file)
--- 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.
 
index 66a6e20..ed4cb07 100644 (file)
@@ -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}
index 3de0e52..634a5f7 100644 (file)
@@ -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}
 
index b675fde..a73b7fc 100644 (file)
@@ -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
index b8d1a19..e5fc8ae 100644 (file)
@@ -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 <sys/types.h>   /* predefined types */
 #include <unistd.h>      /* include unix standard library */
-#include <arpa/inet.h>   /* IP addresses conversion utiliites */
+#include <arpa/inet.h>   /* IP addresses conversion utilities */
 #include <sys/socket.h>  /* socket library */
 #include <stdio.h>       /* 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 <sys/types.h>   /* predefined types */
 #include <unistd.h>      /* include unix standard library */
-#include <arpa/inet.h>   /* IP addresses conversion utiliites */
+#include <arpa/inet.h>   /* IP addresses conversion utilities */
 #include <sys/socket.h>  /* socket library */
 #include <stdio.h>       /* include standard I/O library */
 #include <time.h>