di Linux questa è disponibile.} anche quando questa è presente, non è detto
possa essere usata con \func{accept}. La portabilità però viene al costo di
una riscrittura parziale del server, secondo quanto mostrato in
-\figref{fig:TCP_echo_server_code}.
+\figref{fig:TCP_echo_server_code}, dove si è riportata la sezione di codice
+modificata per la seconda versione del programma.
-\begin{figure}[!htbp]
+\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{15.6cm}
\includecodesample{listati/TCP_echod.c}
\end{minipage}
\normalsize
- \caption{Codice del corpo principale della seconda versione del server
- per il servizio \textit{echo}.}
+ \caption{Sezione del codice seconda versione del server
+ per il servizio \textit{echo} modificate rispetto alla prima.}
\label{fig:TCP_echo_server_code}
\end{figure}
padre in stato di sleep.\footnote{si noti infatti che le altre \textit{slow
system call} o sono chiamate prima di entrare nel ciclo principale, quando
ancora non esistono processi figli, o sono chiamate dai figli stessi.} Per
-questo l'unica modifica nella nuova versione del server, rispetto alla
-versione precedente vista in \figref{fig:TCP_ServEcho}, è nella sezione
-(\texttt{\small 43--48}) in cui si effettua la chiamata di \func{accept}.
-Quest'ultima allora viene effettuata (\texttt{\small 43--44}) all'interno di
-un ciclo di \code{while}\footnote{la sintassi del C relativa a questo ciclo
- può non essere del tutto chiara. In questo caso infatti si è usato un ciclo
- vuoto che non esegue nessuna istruzione, in questo modo quello che viene
- ripetuto con il ciclo è soltanto il codice che esprime la condizione
- all'interno del \code{while}.} che la ripete indefinitamente qualora in
-caso di errore il valore di \var{errno} sia \errcode{EINTR}. Negli altri casi
-si esce in caso di errore effettivo (\texttt{\small 45--48}), altrimenti il
-programma prosegue esattamente allo stesso modo del precedente.
-
+questo l'unica modifica sostanziale nella nuova versione del server, rispetto
+alla versione precedente vista in \figref{fig:TCP_ServEcho}, è nella sezione
+(\texttt{\small 9--14}) in cui si effettua la chiamata di \func{accept}.
+Quest'ultima viene effettuata (\texttt{\small 9--10}) all'interno di un ciclo
+di \code{while}\footnote{la sintassi del C relativa a questo ciclo può non
+ essere del tutto chiara. In questo caso infatti si è usato un ciclo vuoto
+ che non esegue nessuna istruzione, in questo modo quello che viene ripetuto
+ con il ciclo è soltanto il codice che esprime la condizione all'interno del
+ \code{while}.} che la ripete indefinitamente qualora in caso di errore il
+valore di \var{errno} sia \errcode{EINTR}. Negli altri casi si esce in caso di
+errore effettivo (\texttt{\small 11--14}), altrimenti il programma prosegue.
+
+Si noti che in questa nuova versione si è aggiunta una ulteriore sezione
+(\texttt{\small 15--28}) per il debugging, che stampa l'indirizzo da cui si è
+avuta la connessione, e la gestione (\texttt{\small 5}) di una nuova opzione,
+specificabile con \code{-w Nsec}, che inizializza la variabile \var{waiting}
+al numero di secondi da aspettare. Questa opzione permette di specificare un
+tempo di attesa prima di passare alla chiamata \func{accept}, il cui scopo
+sarà più chiaro facendo riferimento al primo degli scenari critici di
+\secref{sec:TCP_echo_critical}.
gestire tutta una serie di situazioni critiche che non esistono per i processi
locali.
-La prima situazione critica è quella della terminazione precoce, per via di un
-qualche errore di rete, della connessione effettuata da un client. Come
+La prima situazione critica è quella della terminazione precoce, causata da un
+qualche errore sulla rete, della connessione effettuata da un client. Come
accennato in \secref{sec:TCP_func_accept} la funzione \func{accept} riporta
tutti gli eventuali errori di rete pendenti su una connessione sul
-\textit{connected socket}.
+\textit{connected socket}. Di norma questo non è un problema a questo livello,
+in quanto una volta completata la connessione \func{accept} ritorna e l'errore
+sarà rilevato in seguito dal processo che la gestisce.
-Questo significa che, oltre alla interruzione da parte di un segnale, che
-abbiamo trattato in \secref{sec:TCP_child_hand} nel caso particolare di
-\const{SIGCHLD}, si possono avere altri errori non fatali all'uscita di
-\func{accept}, che necessitano semplicemente la ripetizione della chiamata
-senza che si debba uscire dal programma. Uno scenario tipo è quello mostrato
-in \figref{fig:TCP_early_abort}, in cui la connessione viene abortita sul lato
-client con l'invio di un segmento RST, prima che nel server sia stata chiamata
-la funzione \func{accept}.
+In generale però è possibile incorrere anche in uno scenario del tipo di
+quello mostrato in \figref{fig:TCP_early_abort}, in cui la connessione viene
+abortita sul lato client con l'invio di un segmento RST, prima che nel server
+sia stata chiamata la funzione \func{accept}.
\begin{figure}[htb]
\centering
demandata a processi figli, può accadere che il three way handshake venga
completato e la relativa connessione abortita subito dopo, prima che il padre,
per via del carico della macchina abbia fatto in tempo a rieseguire la
-chiamata \func{accept}. In questo caso si ha una situazione analoga a quella
-illustrata in \figref{fig:TCP_early_abort}, la connessione viene stabilita, ma
-subito dopo si ha una condizione
-
-
-che, come nell'esempio in figura, ritornerebbe
-immediatamente con un errore relativo alla connessione abortita.
+chiamata \func{accept}. Di nuovo si ha una situazione analoga a quella
+illustrata in \figref{fig:TCP_early_abort}, in cui la connessione viene
+stabilita, ma subito dopo si ha una condizione di errore che la chiude prima
+che essa sia stata accettata dal programma.
+Questo significa che, oltre alla interruzione da parte di un segnale, che
+abbiamo trattato in \secref{sec:TCP_child_hand} nel caso particolare di
+\const{SIGCHLD}, si possono ricevere altri errori non fatali all'uscita di
+\func{accept}, che come nel caso precedente, necessitano semplicemente la
+ripetizione della chiamata senza che si debba uscire dal programma. In questo
+caso anche la versione modificata del nostro server non sarebbe adatta, in
+quanto uno di questi errori causerebbe la terminazione dello stesso.
Si tenga presente che questo tipo di terminazione non è riproducibile
terminando il client prima della chiamata ad \func{accept}; in tal caso
infatti il socket associato alla connessione viene semplicemente chiuso,
attraverso la sequenza vista in \secref{sec:TCP_conn_term}, per cui la
\func{accept} ritornerà senza errori, e si avrà semplicemente un end-of-file
-al primo accesso al socket.
+al primo accesso al socket. Per riprodurre l'errore occorrerebbe usare
+l'opzione \const{SO\_LINGER} (vedi \secref{sec:xxx}) per chiedere al client di
+chiudere il socket con un segmento RST, invece che con la normale sequenza di
+chiusura.
-In questo caso
projects / gapil.git / blobdiff