Rilettura, secondo capitolo

[gapil.git] / tcpsock.tex

diff --git a/tcpsock.tex b/tcpsock.tex
index 27f96ef930fa10b01a0e8df787fe2edfa37c7ae2..1c55fd300bfb1e32fd01f05e009ebee59c4cbbd8 100644 (file)
--- a/tcpsock.tex
+++ b/tcpsock.tex
@@ -1,6 +1,6 @@
 %% tcpsock.tex
 %%
-%% Copyright (C) 2000-2004 Simone Piccardi.  Permission is granted to
+%% Copyright (C) 2000-2005 Simone Piccardi.  Permission is granted to
 %% copy, distribute and/or modify this document under the terms of the GNU Free
 %% Documentation License, Version 1.1 or any later version published by the
 %% Free Software Foundation; with the Invariant Sections being "Un preambolo",
@@ -88,7 +88,7 @@ stabilisce la connessione.
 % Una analogia citata da R. Stevens per la connessione TCP è quella con il
 % sistema del telefono. La funzione \texttt{socket} può essere considerata
 % l'equivalente di avere un telefono. La funzione \texttt{bind} è analoga al
-% dire alle altre persone qual'è il proprio numero di telefono perché possano
+% dire alle altre persone qual è il proprio numero di telefono perché possano
 % chiamare. La funzione \texttt{listen} è accendere il campanello del telefono
 % per sentire le chiamate in arrivo.  La funzione \texttt{connect} richiede di
 % conoscere il numero di chi si vuole chiamare. La funzione \texttt{accept} è
@@ -930,7 +930,7 @@ connessione completa.
   \label{fig:TCP_listen_backlog}
 \end{figure}
 
-Storicamente il valore del parametro \param{backlog} era corrispondente al
+Storicamente il valore dell'argomento \param{backlog} era corrispondente al
 massimo valore della somma del numero di voci possibili per ciascuna delle due
 code. Stevens in \cite{UNP1} riporta che BSD ha sempre applicato un fattore di
 1.5 a detto valore, e fornisce una tabella con i risultati ottenuti con vari
@@ -1182,13 +1182,13 @@ ritornata da \func{accept}), all'esecuzione di \func{exec} verr
 memoria l'immagine del programma eseguito, che a questo punto perde ogni
 riferimento ai valori tornati da \func{accept}.  Il socket descriptor però
 resta aperto, e se si è seguita una opportuna convenzione per rendere noto al
-programma eseguito qual'è il socket connesso, \footnote{ad esempio il solito
+programma eseguito qual è il socket connesso, \footnote{ad esempio il solito
   \cmd{inetd} fa sempre in modo che i file descriptor 0, 1 e 2 corrispondano
   al socket connesso.} quest'ultimo potrà usare la funzione \func{getpeername}
 per determinare l'indirizzo remoto del client.
 
 Infine è da chiarire (si legga la pagina di manuale) che, come per
-\func{accept}, il terzo parametro, che è specificato dallo standard POSIX.1g
+\func{accept}, il terzo argomento, che è specificato dallo standard POSIX.1g
 come di tipo \code{socklen\_t *} in realtà deve sempre corrispondere ad un
 \ctyp{int *} come prima dello standard perché tutte le implementazioni dei
 socket BSD fanno questa assunzione.
@@ -1460,7 +1460,7 @@ programma.
 Il passo successivo (\texttt{\small 35--39}) è quello di mettere ``in
 ascolto'' il socket; questo viene fatto (\texttt{\small 36}) con la funzione
 \func{listen} che dice al kernel di accettare connessioni per il socket che
-abbiamo creato; la funzione indica inoltre, con il secondo parametro, il
+abbiamo creato; la funzione indica inoltre, con il secondo argomento, il
 numero massimo di connessioni che il kernel accetterà di mettere in coda per
 il suddetto socket. Di nuovo in caso di errore si stampa (\texttt{\small 37})
 un messaggio, e si esce (\texttt{\small 38}) immediatamente.
@@ -2434,13 +2434,13 @@ di RST, contraddistinto dalla lettera \texttt{R}, che causa la conclusione
 definitiva della connessione anche nel client, dove non comparirà più
 nell'output di \cmd{netstat}.
 
-Come abbiamo accennato in sez.~\ref{sec:TCP_conn_term} e come vedremo più avanti
-in sez.~\ref{sec:TCP_shutdown} la chiusura di un solo capo di un socket è
-una operazione lecita, per cui la nostra scrittura avrà comunque successo
+Come abbiamo accennato in sez.~\ref{sec:TCP_conn_term} e come vedremo più
+avanti in sez.~\ref{sec:TCP_shutdown} la chiusura di un solo capo di un socket
+è una operazione lecita, per cui la nostra scrittura avrà comunque successo
 (come si può constatare lanciando usando \cmd{strace}\footnote{il comando
-  \cmd{strace} è un comando di debug molto utile che prende come parametro un
+  \cmd{strace} è un comando di debug molto utile che prende come argomento un
   altro comando e ne stampa a video tutte le invocazioni di una system call,
-  coi relativi parametri e valori di ritorno, per cui usandolo in questo
+  coi relativi argomenti e valori di ritorno, per cui usandolo in questo
   contesto potremo verificare che effettivamente la \func{write} ha scritto la
   riga, che in effetti è stata pure trasmessa via rete.}), in quanto il nostro
 programma non ha a questo punto alcun modo di sapere che dall'altra parte non