From: Simone Piccardi Date: Wed, 1 Jan 2003 12:13:37 +0000 (+0000) Subject: Fine correzioni ortografiche X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=9b0f636834e8d92e87131bbb99d7d846bab1421a;p=gapil.git Fine correzioni ortografiche --- diff --git a/elemtcp.tex b/elemtcp.tex index f59308a..39fc7cd 100644 --- a/elemtcp.tex +++ b/elemtcp.tex @@ -141,7 +141,7 @@ regolare la connessione. Normalmente vengono usate le seguenti opzioni: 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 ritardi nel + alta velocità (sopra i 45Mbit/sec) e quelle che hanno grandi ritardi nel cammino dei pacchetti (come i satelliti) richiedono una finestra più grande per poter ottenere il massimo dalla trasmissione, per questo esiste questa opzione che indica un fattore di scala da applicare al valore della finestra @@ -150,7 +150,7 @@ regolare la connessione. Normalmente vengono usate le seguenti opzioni: attiva prevede come negoziazione che l'altro capo della connessione riconosca esplicitamente l'opzione inserendola anche lui nel suo SYN di risposta dell'apertura della connessione.} per la connessione corrente - (espresso come numero di bit cui shiftare a sinistra il valore della + (espresso come numero di bit cui spostare a sinistra il valore della finestra annunciata inserito nel pacchetto). \item \textit{timestamp option}, è anche questa una nuova opzione necessaria @@ -324,10 +324,9 @@ dati rispondono meglio alle esigenze che devono essere affrontate. Come riportato da Stevens in \cite{UNP1} lo stato \texttt{TIME\_WAIT} è probabilmente uno degli aspetti meno compresi del protocollo TCP, è infatti -comune trovare nei newsgroup domande su come sia possibile evitare che -un'applicazione resti in questo stato lasciando attiva una connessione ormai -conclusa; la risposta è che non deve essere fatto, ed il motivo cercheremo di -spiegarlo adesso. +comune trovare domande su come sia possibile evitare che un'applicazione resti +in questo stato lasciando attiva una connessione ormai conclusa; la risposta è +che non deve essere fatto, ed il motivo cercheremo di spiegarlo adesso. Come si è visto nell'esempio precedente (vedi \figref{fig:TPCel_conn_example}) \texttt{TIME\_WAIT} è lo stato finale in cui il capo di una connessione che @@ -339,12 +338,12 @@ La MSL sulla rete; questo tempo è limitato perché ogni pacchetto IP può essere ritrasmesso dai router un numero massimo di volte (detto \textit{hop limit}). Il numero di ritrasmissioni consentito è indicato dal campo TTL dell'header di -IP (per maggiori dettagli vedi \secref{sec:IP_xxx}), e viene decrementato -ad ogni passaggio da un router; quando si annulla il pacchetto viene scartato. -Siccome il numero è ad 8 bit il numero massimo di ``salti'' è di 255, pertanto -anche se il TTL (da \textit{time to live}) non è propriamente un limite sul -tempo di vita, si stima che un pacchetto IP non possa restare nella rete per -più di MSL secondi. +IP (per maggiori dettagli vedi \secref{sec:IP_xxx}), e viene decrementato ad +ogni passaggio da un router; quando si annulla il pacchetto viene scartato. +Siccome il numero è ad 8 bit il numero massimo di ``\textsl{salti}'' è di 255, +pertanto anche se il TTL (da \textit{time to live}) non è propriamente un +limite sul tempo di vita, si stima che un pacchetto IP non possa restare nella +rete per più di MSL secondi. Ogni implementazione del TCP deve scegliere un valore per la MSL (l'RFC~1122 raccomanda 2 minuti, Linux usa 30 secondi), questo comporta una durata dello @@ -1042,7 +1041,7 @@ prima connessione completa (estratta dalla relativa coda, vedi socket \param{sockfd}. Quest'ultimo (detto \textit{listening socket}) è quello creato all'inizio e messo in ascolto con \func{listen}, e non viene toccato dalla funzione. Se non ci sono connessioni pendenti da accettare la funzione -mette in attesa il processo\footnote{a meno che non si sia imopstato il socket +mette in attesa il processo\footnote{a meno che non si sia impostato il socket per essere non bloccante (vedi \secref{sec:file_noblocking}), nel qual caso ritorna con l'errore \errcode{EAGAIN}. Torneremo su questa modalità di operazione in \secref{sec:xxx_sock_noblock}.} fintanto che non ne arriva @@ -1123,7 +1122,7 @@ rispetto al precedente esempio. Al solito il sorgente completo del server \begin{lstlisting}{} #include /* predefined types */ #include /* include unix standard library */ -#include /* IP addresses conversion utiliites */ +#include /* IP addresses conversion utililites */ #include /* socket library */ #include /* include standard I/O library */ #include @@ -1222,7 +1221,7 @@ chiusa. \subsection{Le funzioni \func{getsockname} e \func{getpeername}} \label{sec:TCPel_get_names} -Queste due funzioni vengono usate per ottenere i dati realtivi alla socket +Queste due funzioni vengono usate per ottenere i dati relativi alla socket pair associata ad un certo socket; la prima è \funcd{getsockname} e restituisce l'indirizzo locale; il suo prototipo è: \begin{prototype}{sys/socket.h} diff --git a/errors.tex b/errors.tex index 391cc82..6d6bfd3 100644 --- a/errors.tex +++ b/errors.tex @@ -44,9 +44,9 @@ gestione dei file. file che si suppone erroneamente essere esistente. \item \errcode{EIO} \textit{Input/output error}. Errore di input/output: usato per riportare errori hardware in lettura/scrittura su un dispositivo. -\item \errcode{ENXIO} \textit{No such device or address}. Device inesistente: - il sistema ha tentato di usare un dispositivo attraverso il file - specificato, ma non lo ha trovato. Può significare che il file di +\item \errcode{ENXIO} \textit{No such device or address}. Dispositivo + inesistente: il sistema ha tentato di usare un dispositivo attraverso il + file specificato, ma non lo ha trovato. Può significare che il file di dispositivo non è corretto, che il modulo relativo non è stato caricato nel kernel, o che il dispositivo è fisicamente assente o non funzionante. \item \errcode{ENOEXEC} \textit{Invalid executable file format}. Il file non ha @@ -149,7 +149,7 @@ gestione dei processi. processo figlio. Viene rilevato dalle funzioni per la gestione dei processi figli. %\item \errcode{EPROCLIM} \textit{}. Il limite dell'utente per nuovi processi -% sarà ecceduto alla prossima \func{fork}. (non credo esista in linux) +% sarà ecceduto alla prossima \func{fork}. (non credo esista in Linux) \end{description} @@ -313,7 +313,7 @@ specificati nelle sezioni precedenti. comando o opzione o che, in caso di oggetti specifici (file descriptor o altro) non è in grado di supportare i parametri richiesti. \item \errcode{EILSEQ} \textit{Illegal byte sequence}. Nella decodifica di un - carattere multibyte si è avuta una sequenza errata o incompleta o si è + carattere esteso si è avuta una sequenza errata o incompleta o si è specificato un valore non valido. \end{description} diff --git a/fileintro.tex b/fileintro.tex index 342cd8d..026325f 100644 --- a/fileintro.tex +++ b/fileintro.tex @@ -45,7 +45,7 @@ viene resa disponibile ai processi attraverso quello che viene chiamato il \textsl{montaggio} del \textit{filesystem}. % (approfondiremo tutto ciò in \secref{sec:file_arch_func}). -In questa sezione faremo una panormamica generica su come il sistema presenta +In questa sezione faremo una panoramica generica su come il sistema presenta i file ai processi, trattando l'organizzazione di file e directory, i tipi di file ed introducendo le interfacce disponibili e le loro caratteristiche. @@ -69,7 +69,7 @@ accedere al file a partire dalla \textit{root directory}, che una serie di nomi separati da una \file{/}. All'avvio del sistema, completata la fase di inizializzazione, il kernel -riceve dal boot loader l'indicazione di quale dispositivo contiene il +riceve dal bootloader l'indicazione di quale dispositivo contiene il filesystem da usare come punto di partenza e questo viene montato come radice dell'albero (cioè nella directory \file{/}); tutti gli ulteriori filesystem che possono essere su altri dispositivi dovranno poi essere inseriti @@ -175,10 +175,10 @@ in cui il dispositivo sottostante effettua le operazioni di I/O.\footnote{in un file che identifica una periferica ad accesso a caratteri \\ \textit{block device} & \textsl{dispositivo a blocchi} & un file che identifica una periferica ad accesso a blocchi \\ - \textit{fifo} & \textsl{``coda''} & + \textit{fifo} & ``\textsl{coda}'' & un file speciale che identifica una linea di comunicazione software unidirezionale (vedi \secref{sec:ipc_named_pipe}).\\ - \textit{socket}\index{socket} & \textsl{``presa''} & + \textit{socket}\index{socket} & ``\textsl{presa}''& un file speciale che identifica una linea di comunicazione software bidirezionale (vedi \capref{cha:socket_intro}) \\ \hline @@ -192,12 +192,12 @@ Windows) flusso continuo di byte. Non esiste cioè differenza per come vengono visti dal sistema file di diverso contenuto o formato (come nel caso di quella fra file di testo e binari che c'è in Windows) né c'è una strutturazione a record per -il cosiddetto ``accesso diretto'' come nel caso del VMS.\footnote{questo vale - anche per i dispositivi a blocchi: la strutturazione dell'I/O in blocchi di - dimensione fissa avviene solo all'interno del kernel, ed è completamente - trasparente all'utente. Inoltre talvolta si parla di \textsl{accesso - diretto} riferendosi alla capacità, che non ha niente a che fare con tutto - ciò, di effettuare, attraverso degli appositi file di +il cosiddetto ``\textsl{accesso diretto}'' come nel caso del +VMS.\footnote{questo vale anche per i dispositivi a blocchi: la strutturazione + dell'I/O in blocchi di dimensione fissa avviene solo all'interno del kernel, + ed è completamente trasparente all'utente. Inoltre talvolta si parla di + \textsl{accesso diretto} riferendosi alla capacità, che non ha niente a che + fare con tutto ciò, di effettuare, attraverso degli appositi file di dispositivo\index{file!di dispositivo}, operazioni di I/O direttamente sui dischi senza passare attraverso un filesystem (il cosiddetto \textit{raw access}, introdotto coi kernel della serie 2.4.x).} @@ -453,7 +453,7 @@ Una singola \textit{dentry} contiene in genere il puntatore ad un disco e che identifica un singolo oggetto del VFS sia esso un file ordinario, una directory, un link simbolico, una FIFO, un file di dispositivo\index{file!di dispositivo}, o una qualsiasi altra cosa che possa -essere rappresentata dal VFS (i tipi di ``file'' riportati in +essere rappresentata dal VFS (i tipi di file riportati in \tabref{tab:file_file_types}). A ciascuno di essi è associata pure una struttura che sta in memoria, e che, oltre alle informazioni sullo specifico file, contiene anche il riferimento alle funzioni (i \textsl{metodi} del VFS) diff --git a/filestd.tex b/filestd.tex index 8d6b55b..78d67c2 100644 --- a/filestd.tex +++ b/filestd.tex @@ -137,7 +137,7 @@ uno degli aspetti pi riguarda l'aspetto della scrittura dei dati sul file. I caratteri che vengono scritti su di uno stream normalmente vengono -accumulati in un buffer e poi trasmessi in blocco\footnote{qiesta operazione +accumulati in un buffer e poi trasmessi in blocco\footnote{questa operazione viene usualmente chiamata \textsl{scaricamento} dei dati, dal termine inglese \textit{flush}.} tutte le volte che il buffer viene riempito, in maniera asincrona rispetto alla scrittura. Un comportamento analogo avviene @@ -152,7 +152,7 @@ Per lo stesso motivo, in tutte le situazioni in cui si sta facendo dell'input/output interattivo, bisognerà tenere presente le caratteristiche delle operazioni di scaricamento dei dati, poiché non è detto che ad una scrittura sullo stream corrisponda una immediata scrittura sul dispositivo (la -cosa è particolaemente evidente quando con le operazioni di input/output su +cosa è particolarmente evidente quando con le operazioni di input/output su terminale). Per rispondere ad esigenze diverse, lo standard definisce tre distinte @@ -854,7 +854,7 @@ illustrate finora (eccetto \func{gets} e \func{puts}), che eseguono esattamente le stesse operazioni delle loro equivalenti, evitando però il lock implicito dello stream (vedi \secref{sec:file_stream_thread}). Come per le altre forma di I/O, dette funzioni hanno lo stesso nome della loro analoga -normale, con l'aggiuta dell'estensione \code{\_unlocked}. +normale, con l'aggiunta dell'estensione \code{\_unlocked}. Come abbiamo visto, le funzioni di lettura per l'input/output di linea previste dallo standard ANSI C presentano svariati inconvenienti. Benché @@ -1194,7 +1194,7 @@ davanti a \texttt{print}, sono trattate in dettaglio nella documentazione delle In corrispondenza alla famiglia di funzioni \func{printf} che si usano per l'output formattato, l'input formattato viene eseguito con le funzioni della famiglia \func{scanf}; fra queste le tre più importanti sono \funcd{scanf}, -\funcd{fscanf} e \funcd{sscanf}, i cui proprotipi sono: +\funcd{fscanf} e \funcd{sscanf}, i cui prototipi sono: \begin{functions} \headdecl{stdio.h} \funcdecl{int scanf(const char *format, ...)} Esegue una scansione di \file{stdin} cercando una corrispondenza di quanto letto con il @@ -1249,7 +1249,7 @@ scansione e conversione di quanto serve direttamente con una delle funzioni di conversione delle stringhe; se invece il formato è più complesso diventa più facile utilizzare uno strumento come \cmd{flex}\footnote{il programma \cmd{flex}, è una implementazione libera di \cmd{lex} un generatore di - analizzatori lessicali, per i dettagli si può fare riferimento al manuale + analizzatori lessicali. Per i dettagli si può fare riferimento al manuale \cite{flex}.} per generare un analizzatore lessicale o il \cmd{bison}\footnote{il programma \cmd{bison} è un clone del generatore di parser \cmd{yacc}, maggiori dettagli possono essere trovati nel relativo diff --git a/fileunix.tex b/fileunix.tex index b23698a..543c967 100644 --- a/fileunix.tex +++ b/fileunix.tex @@ -317,9 +317,10 @@ usato sempre il file descriptor con il valore pi file con un nome univoco e la funzione \func{link} per verificarne l'esistenza (vedi \secref{sec:ipc_file_lock}).} -\footnotetext[3]{\textit{Denial of Service}, si chiamano così attacchi miranti - ad impedire un servizio causando una qualche forma di carico eccessivo per - il sistema, che resta bloccato nelle risposte all'attacco.} +\footnotetext[3]{\textit{Denial of Service}\index{DoS}, si chiamano così + attacchi miranti ad impedire un servizio causando una qualche forma di + carico eccessivo per il sistema, che resta bloccato nelle risposte + all'attacco.} \footnotetext[4]{il problema è che NFS non supporta la scrittura in append, ed il kernel deve simularla, ma questo comporta la possibilità di una race diff --git a/intro.tex b/intro.tex index 74ec9f2..04d7ad8 100644 --- a/intro.tex +++ b/intro.tex @@ -64,15 +64,15 @@ porte di input/output). Una parte del kernel, lo \textit{scheduler}\index{scheduler}, si occupa di stabilire, ad intervalli fissi e sulla base di un opportuno calcolo delle -priorità, quale ``processo'' deve essere posto in esecuzione (il cosiddetto -\textit{preemptive scheduling}\index{preemptive scheduling}). Questo verrà -comunque eseguito in modalità protetta; quando necessario il processo potrà -accedere alle risorse hardware soltanto attraverso delle opportune chiamate al -sistema che restituiranno il controllo al kernel. +priorità, quale ``\textsl{processo}'' deve essere posto in esecuzione (il +cosiddetto \textit{preemptive scheduling}\index{preemptive scheduling}). +Questo verrà comunque eseguito in modalità protetta; quando necessario il +processo potrà accedere alle risorse hardware soltanto attraverso delle +opportune chiamate al sistema che restituiranno il controllo al kernel. La memoria viene sempre gestita dal kernel attraverso il meccanismo della \textsl{memoria virtuale}\index{memoria virtuale}, che consente di assegnare a -ciascun processo uno spazio di indirizzi ``virtuale'' (vedi +ciascun processo uno spazio di indirizzi ``\textsl{virtuale}'' (vedi \secref{sec:proc_memory}) che il kernel stesso, con l'ausilio della unità di gestione della memoria, si incaricherà di rimappare automaticamente sulla memoria disponibile, salvando su disco quando necessario (nella cosiddetta @@ -196,7 +196,7 @@ maggioranza dei casi,\footnote{esistono implementazioni diverse delle librerie completamente soppiantate dalle \acr{glibc}, le \textit{uClib} pur non essendo complete come le \acr{glibc}, restano invece molto diffuse nel mondo embedded per le loro di dimensioni ridotte (e soprattutto la possibilità di - togliere le parti non necessearie), e pertanto costituiscono un valido + togliere le parti non necessarie), e pertanto costituiscono un valido rimpiazzo delle \acr{glibc} in tutti quei sistemi specializzati che richiedono una minima occupazione di memoria.} si dovrebbe usare il nome GNU/Linux (piuttosto che soltanto Linux) in quanto una parte essenziale del @@ -466,13 +466,13 @@ possono recuperare varie (e di norma piuttosto intricate) informazioni POSIX.2 & 1003.2 & 9945-2& Comandi \\ POSIX.3 & 2003 &TR13210& Metodi di test \\ POSIX.4 & 1003.1b & --- & Estensioni real-time \\ - POSIX.4a& 1003.1c & --- & Threads \\ + POSIX.4a& 1003.1c & --- & Thread \\ POSIX.4b& 1003.1d &9945-1& Ulteriori estensioni real-time \\ POSIX.5 & 1003.5 & 14519& Interfaccia per il linguaggio ADA \\ POSIX.6 & 1003.2c,1e& 9945-2& Sicurezza \\ POSIX.8 & 1003.1f& 9945-1& Accesso ai file via rete \\ - POSIX.9 & 1003.9 & --- & Intercaccia per il Fortran-77 \\ - POSIX.12& 1003.1g& 9945-1& Sockets \\ + POSIX.9 & 1003.9 & --- & Interfaccia per il Fortran-77 \\ + POSIX.12& 1003.1g& 9945-1& Socket \\ \hline \end{tabular} \caption{Elenco dei vari standard POSIX e relative denominazioni.} @@ -558,7 +558,7 @@ richiede sia X11 che Motif). La conformit del nome \textit{Unix 98}, usato spesso anche per riferirsi allo standard. -\subsection{Lo ``standard'' BSD} +\subsection{Lo ``\textsl{standard}'' BSD} \label{sec:intro_bsd} Lo sviluppo di BSD iniziò quando la fine della collaborazione fra l'Università @@ -667,7 +667,7 @@ Le macro disponibili per i vari standard sono le seguenti: standard ISO C, POSIX.1, POSIX.2, and X/Open. \item[\macro{\_XOPEN\_SOURCE}] definendo questa macro si attivano le funzionalità descritte nella \textit{X/Open Portability Guide}. Anche queste - sono un soprainsieme di quelle definite in POSIX.1 e POSIX.2 ed in effetti + sono un sovrainsieme di quelle definite in POSIX.1 e POSIX.2 ed in effetti sia \macro{\_POSIX\_SOURCE} che \macro{\_POSIX\_C\_SOURCE} vengono automaticamente definite. Sono incluse anche ulteriori funzionalità disponibili in BSD e SVID. Se il valore della macro è posto a 500 questo diff --git a/ipc.tex b/ipc.tex index fca22f0..977f9f0 100644 --- a/ipc.tex +++ b/ipc.tex @@ -561,7 +561,8 @@ Il secondo caso processo alla volta (nel qual caso basta usare due fifo, una per leggere ed una per scrivere), le cose diventano invece molto più complesse quando si vuole effettuare una comunicazione fra il server ed un numero imprecisato di -client; se il primo infatti può ricevere le richieste attraverso una fifo```\textsl{nota}'', per le risposte non si può fare altrettanto, dato che, per +client; se il primo infatti può ricevere le richieste attraverso una fifo +``\textsl{nota}'', per le risposte non si può fare altrettanto, dato che, per la struttura sequenziale delle fifo, i client dovrebbero sapere, prima di leggerli, quando i dati inviati sono destinati a loro. @@ -2940,18 +2941,18 @@ modalit Un esempio classico di uso della memoria condivisa è quello del ``\textit{monitor}'', in cui essa viene per scambiare informazioni fra un -processo ``server'' che vi scrive dei dati di interesse generale che ha -ottenuto, e tutti i processi ``client'' interessati agli stessi dati che così +processo server che vi scrive dei dati di interesse generale che ha +ottenuto, e tutti i processi client interessati agli stessi dati che così possono leggerli in maniera completamente asincrona. Con questo schema di -funzionamento da una parte si evita che ciascun processo ``client'' debba +funzionamento da una parte si evita che ciascun processo client debba compiere l'operazione, potenzialmente onerosa, di ricavare e trattare i dati, -e dall'altra si evita al processo ``server'' di dover gestire l'invio a tutti +e dall'altra si evita al processo server di dover gestire l'invio a tutti i client di tutti i dati (non potendo il server sapere quali di essi servono effettivamente al singolo client). -Nel nostro caso implementeremo un ``monitor'' di una directory: un processo si -incaricherà di tenere sotto controllo alcuni parametri relativi ad una -directory (il numero dei file contenuti, la dimensione totale, ecc.) che +Nel nostro caso implementeremo un ``\textsl{monitor}'' di una directory: un +processo si incaricherà di tenere sotto controllo alcuni parametri relativi ad +una directory (il numero dei file contenuti, la dimensione totale, ecc.) che saranno salvati in un segmento di memoria condivisa cui altri processi potranno accedere per ricavare la parte di informazione che interessa. diff --git a/ipprot.tex b/ipprot.tex index 8a64949..110fcb5 100644 --- a/ipprot.tex +++ b/ipprot.tex @@ -373,9 +373,9 @@ differenze: \item è stato introdotto un nuovo campo \textit{flow label}, che viene usato, insieme al campo \textit{priority} (che recupera i bit di precedenza del campo \textit{type of service}) per implementare la gestione di una - ``qualità di servizio'' (vedi \secref{sec:IP_ipv6_qos}) che permette di - identificare i pacchetti appartenenti a un ``flusso'' di dati per i quali si - può provvedere un trattamento speciale. + ``\textsl{qualità di servizio}'' (vedi \secref{sec:IP_ipv6_qos}) che + permette di identificare i pacchetti appartenenti a un ``\textsl{flusso}'' + di dati per i quali si può provvedere un trattamento speciale. \end{itemize} @@ -412,7 +412,7 @@ differenze: \textsl{flag} bit di frammentazione, uno indica se un pacchetto è frammentato, un'altro se ci sono ulteriori frammenti, e un'altro se il pacchetto non può essere frammentato. \\ - \textit{fragmentation offset} & 13 bit& \textsl{offset di frammento}, + \textit{fragmentation offset} & 13 bit & \textsl{offset di frammento}, indica la posizione del frammento rispetto al pacchetto originale\\ \textit{time to live} & 16 bit & \textsl{tempo di vita}, ha lo stesso significato di @@ -963,7 +963,7 @@ nodi locali). Gli indirizzi \textit{anycast} sono indirizzi che vengono assegnati ad un gruppo di interfacce: un pacchetto indirizzato a questo tipo di indirizzo -viene inviato al componente del gruppo più ``vicino'' secondo la distanza di +viene inviato al componente del gruppo più ``\textsl{vicino}'' secondo la distanza di instradamento calcolata dai router. Questi indirizzi sono allocati nello stesso spazio degli indirizzi unicast, diff --git a/network.tex b/network.tex index 671dd38..e904ccf 100644 --- a/network.tex +++ b/network.tex @@ -26,11 +26,11 @@ pi \label{sec:net_cliserv} La differenza principale fra un'applicazione di rete e un programma normale è -che quest'ultima per definizione concerne la comunicazione fra ``processi'' +che quest'ultima per definizione concerne la comunicazione fra processi diversi (che in generale non girano neanche sulla stessa macchina). Questo già -prefigura un cambiamento completo rispetto all'ottica del ``programma'' -monolitico all'interno del quale vengono eseguite tutte le istruzioni, e -presuppone un sistema operativo ``multitasking'' in grado di eseguire processi +prefigura un cambiamento completo rispetto all'ottica del programma monolitico +all'interno del quale vengono eseguite tutte le istruzioni, e chiaramente +presuppone un sistema operativo multitasking in grado di eseguire processi diversi. Un concetto fondamentale su cui si basa la programmazione di rete sotto Linux @@ -437,8 +437,9 @@ relazione tra origine e destinazione dei pacchetti. Si hanno cos in cui un client può scrivere su uno stesso socket\index{socket} pacchetti destinati a server diversi, o un server ricevere su un socket\index{socket} pacchetti provenienti da client diversi. Il modo più semplice di immaginarsi -il funzionamento di UDP è quello della radio, in cui si può ``trasmettere a'' -e ``ricevere da'' più stazioni usando la stessa frequenza. +il funzionamento di UDP è quello della radio, in cui si può +``\textsl{trasmettere a}'' e ``\textsl{ricevere da}'' più stazioni usando la +stessa frequenza. Nonostante gli evidenti svantaggi comportati dall'inaffidabilità UDP ha il grande pregio della velocità che in certi casi è essenziale; inoltre si presta @@ -462,13 +463,13 @@ due i due capi della comunicazione su cui poi viene quest'ultima viene effettuata. Caratteristica fondamentale di TCP è l'affidabilità; quando i dati vengono -inviati attraverso una connessione ne viene richiesto un ``ricevuto'' +inviati attraverso una connessione ne viene richiesto un ``\textsl{ricevuto}'' (il cosiddetto \textit{acknowlegment}), se questo non arriva essi verranno -ritrasmessi per un determinato numero di tentativi, intervallati da un -periodo di tempo crescente, fino a che sarà considerata fallita o caduta la +ritrasmessi per un determinato numero di tentativi, intervallati da un periodo +di tempo crescente, fino a che sarà considerata fallita o caduta la connessione (e generato un errore di \textit{time-out}), dopo un periodo di -tempo che dipende dall'implementazione e che può variare far i -quattro e i dieci minuti. +tempo che dipende dall'implementazione e che può variare far i quattro e i +dieci minuti. Inoltre per tenere conto delle diverse condizioni in cui può trovarsi la linea di comunicazione TCP comprende anche un algoritmo di calcolo dinamico del diff --git a/session.tex b/session.tex index 1080139..26df18c 100644 --- a/session.tex +++ b/session.tex @@ -1900,7 +1900,7 @@ La funzione agisce sul terminale associato a \param{fd}, l'argomento entrambe), operare. Esso può prendere i valori riportati in \tabref{tab:sess_tcflush_queue}, nel caso si specifichi la coda di ingresso cancellerà i dati ricevuti ma non ancora letti, nel caso si specifichi la coda -di uscita cancellerài dati scritti ma non ancora trasmessi. +di uscita cancellerà i dati scritti ma non ancora trasmessi. \begin{table}[htb] \footnotesize @@ -1930,7 +1930,7 @@ dei dati sul terminale; il suo prototipo \funcdecl{int tcflow(int fd, int action)} - Sospende e rivvia il flusso dei dati sul terminale. + Sospende e riavvia il flusso dei dati sul terminale. \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di errore, nel qual caso \var{errno} assumerà i valori \errval{EBADF} o diff --git a/signal.tex b/signal.tex index 2e30498..250653e 100644 --- a/signal.tex +++ b/signal.tex @@ -518,7 +518,8 @@ segnali sono: \item[\const{SIGTERM}] Il nome sta per \textit{terminate}. È un segnale generico usato per causare la conclusione di un programma. Al contrario di \const{SIGKILL} può essere intercettato, ignorato, bloccato. In genere lo si - usa per chiedere in maniera ``educata'' ad un processo di concludersi. + usa per chiedere in maniera ``\textsl{educata}'' ad un processo di + concludersi. \item[\const{SIGINT}] Il nome sta per \textit{interrupt}. È il segnale di interruzione per il programma. È quello che viene generato di default dal comando \cmd{kill} o dall'invio sul terminale del carattere di controllo @@ -804,7 +805,7 @@ gestore non comporta nessun inconveniente. In alcuni casi però alcune system call (che per questo motivo vengono chiamate \textsl{lente}) possono bloccarsi indefinitamente. In questo caso non si può -attendere la conclusione della sistem call, perché questo renderebbe +attendere la conclusione della system call, perché questo renderebbe impossibile una risposta pronta al segnale, per cui il gestore viene eseguito prima che la system call sia ritornata. Un elenco dei casi in cui si presenta questa situazione è il seguente: @@ -940,7 +941,7 @@ un ciclo infinito. Come accennato in \secref{sec:sig_types}, un segnale può essere generato direttamente da un processo attraverso una opportuna system call. Le funzioni -che si usano di solito per invare un segnale generico sono due, \func{raise} e +che si usano di solito per inviare un segnale generico sono due, \func{raise} e \func{kill}. La prima funzione è \funcd{raise}, che è definita dallo standard ANSI C, e @@ -1471,10 +1472,10 @@ Il compito principale del gestore terminazione del processo, cosa che viene eseguita nel ciclo in (\texttt{\small 15-21}). Il ciclo è necessario a causa di una caratteristica fondamentale della gestione dei segnali: abbiamo già accennato come fra la -generazione di un segnale e l'esecuzione del gestore possa passare un -certo lasso di tempo e niente ci assicura che il gestore venga eseguito -prima della generazione di ulteriori segnali dello stesso tipo. In questo caso -normalmente i segnali segnali successivi vengono ``fusi'' col primo ed al +generazione di un segnale e l'esecuzione del gestore possa passare un certo +lasso di tempo e niente ci assicura che il gestore venga eseguito prima della +generazione di ulteriori segnali dello stesso tipo. In questo caso normalmente +i segnali segnali successivi vengono ``\textsl{fusi}'' col primo ed al processo ne viene recapitato soltanto uno. Questo può essere un caso comune proprio con \const{SIGCHLD}, qualora capiti @@ -1942,7 +1943,7 @@ specifica: ad esempio i vari segnali di errore (\const{SIGFPE}, maggiori dettagli riguardo l'errore (come il tipo di errore aritmetico, di istruzione illecita o di violazione di memoria) mentre alcuni segnali di controllo (\const{SIGCHLD}, \const{SIGTRAP} e \const{SIGPOLL}) forniscono -altre informazioni speecifiche. In tutti i casi il valore del campo è +altre informazioni specifiche. In tutti i casi il valore del campo è riportato attraverso delle costanti (le cui definizioni si trovano \file{bits/siginfo.h}) il cui elenco dettagliato è disponibile nella pagina di manuale di di \func{sigaction}. @@ -2449,7 +2450,7 @@ tutti la stessa priorit real-time. Si tenga presente che questi nuovi segnali non sono associati a nessun evento -sepcifico (a meno di non utilizzarli, come vedremo in +specifico (a meno di non utilizzarli, come vedremo in \secref{sec:file_asyncronous_io}, per l'I/O asincrono) e devono essere inviati esplicitamente. Tutti i segnali real-time restituiscono al gestore, oltre ai campi \var{si\_pid} e \var{si\_uid} di \struct{siginfo\_t} una struttura @@ -2487,7 +2488,7 @@ nuova funzione, \funcd{sigqueue}, il cui prototipo \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di errore, nel qual caso \var{errno} assumerà uno dei valori: \begin{errlist} - \item[\errcode{EAGAIN}] La coda è esarita, ci sono già \const{SIGQUEUE\_MAX} + \item[\errcode{EAGAIN}] La coda è esaurita, ci sono già \const{SIGQUEUE\_MAX} segnali in attesa si consegna. \item[\errcode{EPERM}] Non si hanno privilegi appropriati per inviare il segnale al processo specificato. @@ -2576,7 +2577,7 @@ relativi prototipi sono: \func{sigwait}, ai quali si aggiunge, per \func{sigtimedwait}: \begin{errlist} \item[\errcode{EAGAIN}] Si è superato il timeout senza che un segnale atteso - fosse emmesso. + fosse emesso. \end{errlist} } \end{functions} @@ -2591,7 +2592,7 @@ associato viene riportato in \var{si\_value}, che altrimenti La seconda è identica alla prima ma in più permette di specificare un timeout, scaduto il quale ritornerà con un errore. Se si specifica un puntatore nullo il comportamento sarà identico a \func{sigwaitinfo}, se si specifica un tempo -di timeout nullo, e non ci sono sengali pendenti la funzione ritornerà +di timeout nullo, e non ci sono segnali pendenti la funzione ritornerà immediatamente; in questo modo si può eliminare un segnale dalla coda senza dover essere bloccati qualora esso non sia presente. diff --git a/simpltcp.tex b/simpltcp.tex index 93a66e1..4d46b1a 100644 --- a/simpltcp.tex +++ b/simpltcp.tex @@ -220,12 +220,11 @@ in \secref{sec:net_cli_sample}, il client si connette sulla porta 7 all'indirizzo specificato dalla linea di comando (a cui si è aggiunta una elementare gestione delle opzioni non riportata in figura). -Completata la connessione, al ritrno fiììdi \func{connect} è ritornata, la -funzione \code{ClientEcho}, riportata in -\figref{fig:TCPsimpl_client_echo_sub}, si preoccupa di gestire la -comunicazione, leggendo una riga alla volta dallo \file{stdin}, scrivendola -sul socket e ristampando su \file{stdout} quanto ricevuto in risposta dal -server. +Completata la connessione, al ritorno di \func{connect}, la funzione +\code{ClientEcho}, riportata in \figref{fig:TCPsimpl_client_echo_sub}, si +preoccupa di gestire la comunicazione, leggendo una riga alla volta dallo +\file{stdin}, scrivendola sul socket e ristampando su \file{stdout} quanto +ricevuto in risposta dal server. \begin{figure}[!htb] \footnotesize diff --git a/socket.tex b/socket.tex index b93fc88..fa70b6d 100644 --- a/socket.tex +++ b/socket.tex @@ -90,8 +90,8 @@ avviene, in certi casi essa pu con un solo partner come per una telefonata; altri casi possono prevedere una comunicazione come per lettera, in cui si scrive l'indirizzo su ogni pacchetto, altri ancora una comunicazione \textit{broadcast} come per la -radio, in cui i pacchetti vengono emessi su appositi ``canali'' dove chiunque -si collega possa riceverli. +radio, in cui i pacchetti vengono emessi su appositi ``\textsl{canali}'' dove +chiunque si collega possa riceverli. É chiaro che ciascuno di questi stili comporta una modalità diversa di gestire la comunicazione, ad esempio se è inaffidabile occorrerà essere in grado di @@ -113,7 +113,7 @@ La creazione di un socket avviene attraverso l'uso della funzione \funcd{socket}; questa restituisce un \textit{file descriptor}\footnote{del tutto analogo a quelli che si ottengono per i file di dati e le pipe, descritti in \secref{sec:file_fd}.} che serve come riferimento al socket; il -suo protototipo è: +suo prototipo è: \begin{prototype}{sys/socket.h}{int socket(int domain, int type, int protocol)} Apre un socket. @@ -677,9 +677,9 @@ mnemonico per indicare la stringa. Dette funzioni sono \funcd{inet\_addr}, \bodydesc{Tutte queste le funzioni non generano codice di errore.} \end{functions} -La prima funcione, \func{inet\_addr}, restituisce l'indirizzo a 32 bit in +La prima funzione, \func{inet\_addr}, restituisce l'indirizzo a 32 bit in network order (del tipo \type{in\_addr\_t}) a partire dalla stringa passata -nellargomento \param{strptr}. In caso di errore (quando la stringa non esprime +nell'argomento \param{strptr}. In caso di errore (quando la stringa non esprime un indirizzo valido) restituisce invece il valore \const{INADDR\_NONE} che tipicamente sono trentadue bit a uno. Questo però comporta che la stringa \texttt{255.255.255.255}, che pure è un indirizzo valido, non può essere usata @@ -691,7 +691,7 @@ nell'indirizzo binario che viene memorizzato nell'opportuna struttura \struct{in\_addr} (si veda \secref{fig:sock_sa_ipv4_struct}) situata all'indirizzo dato dall'argomento \param{dest} (è espressa in questa forma in modo da poterla usare direttamente con il puntatore usato per passare la -struttura degli indirizzi). La funzione restituesce 0 in caso di successo e 1 +struttura degli indirizzi). La funzione restituisce 0 in caso di successo e 1 in caso di fallimento. Se usata con \param{dest} inizializzato a \val{NULL} effettua la validazione dell'indirizzo. @@ -743,7 +743,7 @@ un valore positivo in caso di successo, e zero se la stringa non rappresenta un indirizzo valido, e negativo se \param{af} specifica una famiglia di indirizzi non valida. -La sedonda funzione è \funcd{inet\_ntop} che converte un indirizzo in una +La seconda funzione è \funcd{inet\_ntop} che converte un indirizzo in una stringa; il suo prototipo è: \begin{prototype}{sys/socket.h} {char *inet\_ntop(int af, const void *addr\_ptr, char *dest, size\_t len)} @@ -751,7 +751,7 @@ stringa; il suo prototipo \bodydesc{La funzione restituisce un puntatore non nullo alla stringa convertita in caso di successo e \val{NULL} in caso di fallimento, nel - qual caso \var{errno} assume i valor: + qual caso \var{errno} assume i valori: \begin{errlist} \item[\errcode{ENOSPC}] le dimensioni della stringa con la conversione dell'indirizzo eccedono la lunghezza specificata da \param{len}. diff --git a/system.tex b/system.tex index c5e1822..a8174db 100644 --- a/system.tex +++ b/system.tex @@ -2144,7 +2144,7 @@ struct tm { int tm_yday; /* day in the year */ int tm_isdst; /* daylight saving time */ long int tm_gmtoff; /* Seconds east of UTC. */ - cost char *tm_zone; /* Timezone abbreviation. */ + const char *tm_zone; /* Timezone abbreviation. */ }; \end{lstlisting} \end{minipage} @@ -2265,7 +2265,7 @@ solare, la seconda per l'ora legale.\footnote{anche se sono indicati come Benché la funzione \func{asctime} fornisca la modalità più immediata per stampare un tempo o una data, la flessibilità non fa parte delle sue caratteristiche; quando si vuole poter stampare solo una parte (l'ora, o il -gionrno) di un tempo si può ricorrere alla più sofisticata \funcd{strftime}, +giorno) di un tempo si può ricorrere alla più sofisticata \funcd{strftime}, il cui prototipo è: \begin{prototype}{time.h} {size\_t strftime(char *s, size\_t max, const char *format, @@ -2275,7 +2275,7 @@ Stampa il tempo \param{tm} nella stringa \param{s} secondo il formato \param{format}. \bodydesc{La funzione ritorna il numero di caratteri stampati in \param{s}, - altrimenti restuisce 0.} + altrimenti restituisce 0.} \end{prototype} La funzione converte opportunamente il tempo \param{tm} in una stringa di @@ -2332,7 +2332,7 @@ viene utilizzato come modificatore; alcuni\footnote{per la precisione quelli le \acr{glibc} provvedono tutte le estensioni introdotte da POSIX.2 per il comando \cmd{date}, i valori introdotti da SVID3 e ulteriori estensioni GNU; l'elenco completo dei possibili valori è riportato nella pagina di manuale - della funzione.} dei possibili valori che esso può assumere sono ripotati in + della funzione.} dei possibili valori che esso può assumere sono riportati in \tabref{tab:sys_strftime_format}. La funzione tiene conto anche della presenza di una localizzazione per stampare in maniera adeguata i vari nomi.