X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=blobdiff_plain;f=tcpsock.tex;h=aaa79147d819a60c1c9cebb0bbb6f027a09547e7;hb=bf81ce9ec539254693a8c41641a99af1aa1d886f;hp=1a156f7ee2ad13087dd82a7d38286bf138617fd4;hpb=66e83c068629844f84fe4a0d44b382f756c9ef32;p=gapil.git

diff --git a/tcpsock.tex b/tcpsock.tex
index 1a156f7..aaa7914 100644
--- a/tcpsock.tex
+++ b/tcpsock.tex
@@ -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
@@ -1188,7 +1188,7 @@ programma eseguito qual'
 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