%% license is included in the section entitled "GNU Free Documentation
%% License".
%%
-\chapter{Socket TCP}
+\chapter{Socket TCP elementari}
\label{cha:TCP_socket}
In questo capitolo iniziamo ad approfondire la conoscenza dei socket TCP,
è chiuso il socket dal lato che esegue la chiusura attiva; esistono tuttavia
situazioni in cui si vuole poter sfruttare questa possibilità, usando una
procedura che è chiamata \textit{half-close}; torneremo su questo aspetto e su
-come utilizzarlo in \secref{xxx_shutdown}, quando parleremo della funzione
+come utilizzarlo in \secref{sec:TCP_shutdown}, quando parleremo della funzione
\func{shutdown}.
La emissione del FIN avviene quando il socket viene chiuso, questo però non
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.
+IP (per maggiori dettagli vedi \secref{sec:ip_protocol}), 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
Il primo dei due motivi precedenti si può capire tornando a
\figref{fig:TCP_conn_example}: assumendo che l'ultimo ACK della sequenza
-(quello del capo che ha eseguito la chiusura attiva) vanga perso, chi esegue
+(quello del capo che ha eseguito la chiusura attiva) venga perso, chi esegue
la chiusura passiva non ricevendo risposta rimanderà un ulteriore FIN, per
questo motivo chi esegue la chiusura attiva deve mantenere lo stato della
connessione per essere in grado di reinviare l'ACK e chiuderla correttamente.
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
-una.
+ operazione in \secref{sec:TCP_sock_multiplexing}.} fintanto che non ne
+arriva una.
La funzione può essere usata solo con socket che supportino la connessione
(cioè di tipo \const{SOCK\_STREAM}, \const{SOCK\_SEQPACKET} o
Per attivare immediatamente l'emissione del FIN e la sequenza di chiusura
descritta in \secref{sec:TCP_conn_term}, si può invece usare la funzione
\func{shutdown} su cui torneremo in seguito (vedi
-\secref{sec:TCP_xxx_shutdown}).
+\secref{sec:TCP_shutdown}).
\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{15.6cm}
- \includecodesample{listati/ClientEcho.c}
+ \includecodesample{listati/ClientEcho_first.c}
\end{minipage}
\normalsize
\caption{Codice della prima versione della funzione \texttt{ClientEcho} per
introdotte una serie di nuove opzioni che ci saranno utili per il debug, è
mostrata in \figref{fig:TCP_echo_server_code_second}, dove si sono riportate
la sezioni di codice modificate nella seconda versione del programma, il
-sorgente completo di quest'ultimo si trova nel file
-\file{TCP\_echod\_second.c} dei sorgenti allegati alla guida.
+codice completo di quest'ultimo si trova nel file \file{TCP\_echod\_second.c}
+dei sorgenti allegati alla guida.
La prima modifica effettuata è stata quella di introdurre una nuova opzione a
riga di comando, \texttt{-c}, che permette di richiedere il comportamento
al primo accesso al socket. Nel caso di Linux inoltre, anche qualora si
modifichi il client per fargli gestire l'invio di un segmento di RST alla
chiusura dal socket (come suggerito da Stevens in \cite{UNP1}), non si ha
-nessun errore al ritorno di \funcd{accept} quanto un errore di
+nessun errore al ritorno di \funcd{accept}, quanto un errore di
\errcode{ECONNRESET} al primo tentativo di accesso al socket.
nell'output di \cmd{netstat}.
Come abbiamo accennato in \secref{sec:TCP_conn_term} e come vedremo più avanti
-in \secref{sec:TCP_xxx_shutdown} la chiusura di un solo capo di un socket è
+in \secref{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
\end{minipage}
\normalsize
\caption{La sezione nel codice della seconda versione della funzione
- \func{CleintEcho} usata dal client per il servizio \textit{echo}
+ \func{ClientEcho} usata dal client per il servizio \textit{echo}
modificata per tener conto degli eventuali errori.}
\label{fig:TCP_ClientEcho_second}
\end{figure}
fare con la necessità di lavorare con più descrittori, nel qual caso diventa
si pone la questione di come fare a non restare bloccati su un socket quando
altri potrebbero essere liberi. Vedremo come affrontare questa problematica in
-\secref{sec:TCP_xxx_advanced}.
+\secref{sec:TCP_sock_multiplexing}.
\subsection{Altri scenari di terminazione della connessione}
Il risultato finale qui dipende dall'implementazione dello stack TCP, e nel
caso di Linux anche dall'impostazione di alcuni dei parametri di sistema che
-si trovane in \file{/proc/sys/net/ipv4}, che ne controllano il comportamento:
+si trovano in \file{/proc/sys/net/ipv4}, che ne controllano il comportamento:
in questo caso in particolare da \file{tcp\_retries2}. Questo parametro
infatti specifica il numero di volte che deve essere ritentata la
ritrasmissione di un pacchetto nel mezzo di una connessione prima di riportare
quando la macchina è su una rete remota, è \errcode{ENETUNREACH}; esso viene
riportato alla ricezione di un pacchetto ICMP di \textit{destination
unreachable} da parte del router che individua l'interruzione della
-connessione. Di nuovo anche qui tutto dipende da chi è il meccanismo più
-veloce ad accorgersi del problema.
+connessione. Di nuovo anche qui il risultato finale dipende da quale è il
+meccanismo più veloce ad accorgersi del problema.
Se però agiamo sui parametri del kernel, e scriviamo in \file{tcp\_retries2}
un valore di tentativi più basso, possiamo evitare la scadenza della
si vuole che il client sia in grado di accorgersi del crollo del server anche
quando non sta effettuando uno scambio di dati, è possibile usare una
impostazione speciale del socket (ci torneremo in
-\secref{sec:TCP_xxx_sockopt}) che provvede all'esecuzione di questo controllo.
+\secref{sec:TCP_sock_options}) che provvede all'esecuzione di questo
+controllo.
projects / gapil.git / blobdiff