Altra roba che mi ero dimenticato ieri

diff --git a/tcpsock.tex b/tcpsock.tex
index 2318fb017cfb0a20107ec3947a534efcbee2b032..8b2be4f70ba383c9750fc59ad01e754c337fc7e1 100644 (file)
--- a/tcpsock.tex
+++ b/tcpsock.tex
@@ -2237,7 +2237,7 @@ attraverso la sequenza vista in \secref{sec:TCP_conn_term}, per cui la
 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
 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.
 
 
 \errcode{ECONNRESET} al primo tentativo di accesso al socket.
 
 


@@ -2537,7 +2537,7 @@ successivo, per tentare di ristabilire la 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
 
 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
 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


@@ -2573,8 +2573,8 @@ Un altro errore possibile in questo tipo di situazione, che si pu
 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
 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
 
 Se però agiamo sui parametri del kernel, e scriviamo in \file{tcp\_retries2}
 un valore di tentativi più basso, possiamo evitare la scadenza della

diff --git a/tcpsockadv.tex b/tcpsockadv.tex
index af3348945068b2df47b195bb85105f81782a4e8f..e77e4320ec8878aad850118fa9bf870e1b8f3725 100644 (file)
--- a/tcpsockadv.tex
+++ b/tcpsockadv.tex
@@ -238,24 +238,67 @@ connesso, ed alla ricezione del FIN la funzione \func{select} ritorner
 illustrato in \secref{sec:TCP_sock_select}) segnalando una condizione di end
 of file, per cui il nostro client potrà uscire immediatamente.
 
 illustrato in \secref{sec:TCP_sock_select}) segnalando una condizione di end
 of file, per cui il nostro client potrà uscire immediatamente.
 

+Riprendiamo la situazione affrontata in \secref{sec:TCP_server_crash},
+terminando il server durante una connessione, in questo caso quello che
+otterremo, una volta scritta una prima riga ed interrotto il server con un
+\texttt{C-c}, sarà:
+\begin{verbatim}
+[piccardi@gont sources]$ ./echo 192.168.1.1
+Prima riga
+Prima riga
+EOF sul socket
+\end{verbatim}%$
+dove l'ultima riga compare immediatamente dopo aver interrotto il server. Il
+nostro client infatti è in grado di accorgersi immediatamente che il socket
+connesso è stato chiuso ed uscire immediatamente.
+
+Veniamo allora agli altri scenari di terminazione anomala visti in
+\secref{sec:TCP_conn_crash}. Il primo di questi è l'interruzione fisica della
+connessione; in questo caso avremo un comportamento analogo al precedente, in
+cui si scrive una riga e non si riceve risposta dal server e non succede
+niente fino a quando non si riceve un errore di \errcode{EHOSTUNREACH} o
+\errcode{ETIMEDOUT} a seconda dei casi.
+
+La differenza è che stavolta potremo scrivere più righe dopo l'interruzione,
+in quanto il nostro client dopo aver inviato i dati non si bloccherà più nella
+lettura dal socket, ma nella \func{select}; per questo potrà accettare
+ulteriore dati che scriverà di nuovo sul socket, fintanto che c'è spazio sul
+buffer di uscita (ecceduto il quale si bloccherà in scrittura). Si ricordi
+infatti che il client non ha modo di determinare se la connessione è attiva o
+meno (dato che in molte situazioni reali l'inattività può essere temporanea).
+Tra l'altro se si ricollega la rete prima della scadenza del timeout, potremo
+anche verificare come tutto quello che si era scritto viene poi effettivamente
+trasmesso non appena la connessione ridiventa attiva, per cui otterremo
+qualcosa del tipo:
+\begin{verbatim}
+[piccardi@gont sources]$ ./echo 192.168.1.1
+Prima riga
+Prima riga
+Seconda riga dopo l'interruzione
+Terza riga
+Quarta riga
+Seconda riga dopo l'interruzione
+Terza riga
+Quarta riga
+\end{verbatim}
+in cui, una volta riconnessa la rete, tutto quello che abbiamo scritto durante
+il periodo di disconnessione restituito indietro e stampato immediatamente.
+
+Lo stesso comportamento visto in \secref{sec:TCP_server_crash} si riottiene
+nel caso di un crollo completo della macchina su cui sta il server. In questo
+caso di nuovo il client non è in grado di accorgersi di niente dato che si
+suppone che il programma server non venga terminato correttamente, ma si
+blocchi tutto senza la possibilità di avere l'emissione di un segmento FIN che
+segnala la terminazione della connessione. Di nuovo fintanto che la
+connessione non si riattiva )con il riavvio della macchina del server) il
+client non è in grado di fare altro che accettare dell'input e tentare di
+inviarlo. La differenza in questo caso è che non appena la connessione
+ridiventa attiva i dati verranno sì trasmessi, ma essendo state perse tutte le
+informazioni relative alle precedenti connessioni ai tentativi di scrittura
+del client sarà risposto con un segmento RST che provocherà il ritorno di
+\func{select} per la ricezione di un errore di \errcode{ECONNRESET}.

 
 
 
 

-\section{Le opzioni dei socket}
-\label{sec:TCP_sock_options}
-
-Dato che la maggior parte delle opzioni dei socket sono relative ai socket
-TCP, ed hanno poi significato analogo quando usate con altri socket, abbiamo
-preferito trattare l'argomento in generale in questa sezione piuttosto che nel
-capitolo dedicato alla trattazione generica dei socket.
-
-
-
-\section{I dati \textit{out-of-band}}
-\label{sec:TCP_urgent_data}
-
-Una caratteristica speciale dei socket TCP è quella della presenza dei
-cosiddetti dati \textit{out-of-band}
-

 
 
 \subsection{La funzione \func{shutdown}}
 
 
 \subsection{La funzione \func{shutdown}}


@@ -283,6 +326,24 @@ scrivere. Per poter permettere allora
 
 
 
 
 
 

+\section{Le opzioni dei socket}
+\label{sec:TCP_sock_options}
+
+Dato che la maggior parte delle opzioni dei socket sono relative ai socket
+TCP, ed hanno poi significato analogo quando usate con altri socket, abbiamo
+preferito trattare l'argomento in generale in questa sezione piuttosto che nel
+capitolo dedicato alla trattazione generica dei socket.
+
+
+
+\section{I dati \textit{out-of-band}}
+\label{sec:TCP_urgent_data}
+
+Una caratteristica speciale dei socket TCP è quella della presenza dei
+cosiddetti dati \textit{out-of-band}
+
+
+

 
 %%% Local Variables: 
 %%% mode: latex
 
 %%% Local Variables: 
 %%% mode: latex