%% 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",
% 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} è
\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
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.
connessione non avesse chiuso la sua parte). Il kernel invierà comunque tutti
i dati che ha in coda prima di iniziare la sequenza di chiusura.
-Vedremo più avanti in sez.~\ref{sec:TCP_so_linger} come è possibile cambiare
-questo comportamento, e cosa deve essere fatto perché il processo possa
-assicurarsi che l'altro capo abbia ricevuto tutti i dati.
+Vedremo più avanti in sez.~\ref{sec:sock_generic_options} come sia possibile
+cambiare questo comportamento, e cosa può essere fatto perché il processo
+possa assicurarsi che l'altro capo abbia ricevuto tutti i dati.
Come per tutti i file descriptor anche per i socket viene mantenuto un numero
di riferimenti, per cui se più di un processo ha lo stesso socket aperto
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.
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
projects / gapil.git / blobdiff