Lavoro fatto a casa senza ADSL, correzioni multiple agli indici, documentato

[gapil.git] / tcpsock.tex

diff --git a/tcpsock.tex b/tcpsock.tex
index 583ec3d14cecf907f70cf4c89675b43bccc9ab98..14c664b9949cd98a88675f055fd76738bc7b4136 100644 (file)
--- a/tcpsock.tex
+++ b/tcpsock.tex
@@ -137,7 +137,8 @@ regolare la connessione. Normalmente vengono usate le seguenti opzioni:
   connessione corrente. È possibile leggere e scrivere questo valore
   attraverso l'opzione del socket \const{TCP\_MAXSEG}.
   
   connessione corrente. È possibile leggere e scrivere questo valore
   attraverso l'opzione del socket \const{TCP\_MAXSEG}.
   

-\item \textit{window scale option}, %come spiegato in sez.~\ref{sec:tcp_protocol}
+\item \textit{window scale
+    option}, %come spiegato in sez.~\ref{sec:tcp_protocol}

   il protocollo TCP implementa il controllo di flusso attraverso una
   \textsl{finestra annunciata} (\textit{advertized window}) con la quale
   ciascun capo della comunicazione dichiara quanto spazio disponibile ha in
   il protocollo TCP implementa il controllo di flusso attraverso una
   \textsl{finestra annunciata} (\textit{advertized window}) con la quale
   ciascun capo della comunicazione dichiara quanto spazio disponibile ha in


@@ -393,7 +394,7 @@ una connessione fra due router si interrompa. In questo caso i protocolli di
 instradamento dei pacchetti possono impiegare diverso tempo (anche dell'ordine
 dei minuti) prima di trovare e stabilire un percorso alternativo per i
 pacchetti. Nel frattempo possono accadere casi in cui un router manda i
 instradamento dei pacchetti possono impiegare diverso tempo (anche dell'ordine
 dei minuti) prima di trovare e stabilire un percorso alternativo per i
 pacchetti. Nel frattempo possono accadere casi in cui un router manda i

-pacchetti verso un'altro e quest'ultimo li rispedisce indietro, o li manda ad
+pacchetti verso un altro e quest'ultimo li rispedisce indietro, o li manda ad

 un terzo router che li rispedisce al primo, si creano cioè dei circoli (i
 cosiddetti \textit{routing loop}) in cui restano intrappolati i pacchetti.
 
 un terzo router che li rispedisce al primo, si creano cioè dei circoli (i
 cosiddetti \textit{routing loop}) in cui restano intrappolati i pacchetti.
 


@@ -621,17 +622,17 @@ tcp        0      0 195.110.112.152:22      192.84.146.100:21100    ESTABLISHED
 tcp        0      0 195.110.112.152:22      192.84.146.100:21101    ESTABLISHED
 \end{verbatim}
 cioè il client effettuerà la connessione usando un'altra porta effimera: con
 tcp        0      0 195.110.112.152:22      192.84.146.100:21101    ESTABLISHED
 \end{verbatim}
 cioè il client effettuerà la connessione usando un'altra porta effimera: con

-questa sarà aperta la connessione, ed il server creerà un'altro processo
+questa sarà aperta la connessione, ed il server creerà un altro processo

 figlio per gestirla.
 
 Tutto ciò mostra come il TCP, per poter gestire le connessioni con un server
 concorrente, non può suddividere i pacchetti solo sulla base della porta di
 destinazione, ma deve usare tutta l'informazione contenuta nella socket pair,
 compresa la porta dell'indirizzo remoto.  E se andassimo a vedere quali sono i
 figlio per gestirla.
 
 Tutto ciò mostra come il TCP, per poter gestire le connessioni con un server
 concorrente, non può suddividere i pacchetti solo sulla base della porta di
 destinazione, ma deve usare tutta l'informazione contenuta nella socket pair,
 compresa la porta dell'indirizzo remoto.  E se andassimo a vedere quali sono i

-processi\footnote{ad esempio con il comando \cmd{fuser}, o con \cmd{lsof}.} a
-cui fanno riferimento i vari socket vedremmo che i pacchetti che arrivano
-dalla porta remota 21100 vanno al primo figlio e quelli che arrivano alla
-porta 21101 al secondo.
+processi\footnote{ad esempio con il comando \cmd{fuser}, o con \cmd{lsof}, o
+  usando l'opzione \texttt{-p}.} a cui fanno riferimento i vari socket
+vedremmo che i pacchetti che arrivano dalla porta remota 21100 vanno al primo
+figlio e quelli che arrivano alla porta 21101 al secondo.

 
 
 \section{Le funzioni di base per la gestione dei socket}
 
 
 \section{Le funzioni di base per la gestione dei socket}


@@ -747,10 +748,10 @@ con una struttura, perch
 costante come operando a destra in una assegnazione.
 
 Per questo motivo nell'header \file{netinet/in.h} è definita una variabile
 costante come operando a destra in una assegnazione.
 
 Per questo motivo nell'header \file{netinet/in.h} è definita una variabile

-\const{in6addr\_any} (dichiarata come \direct{extern}, ed inizializzata dal
+\macro{in6addr\_any} (dichiarata come \direct{extern}, ed inizializzata dal

 sistema al valore \const{IN6ADRR\_ANY\_INIT}) che permette di effettuare una
 assegnazione del tipo: \includecodesnip{listati/serv_addr_sin6_addr.c} in
 sistema al valore \const{IN6ADRR\_ANY\_INIT}) che permette di effettuare una
 assegnazione del tipo: \includecodesnip{listati/serv_addr_sin6_addr.c} in

-maniera analoga si può utilizzare la variabile \const{in6addr\_loopback} per
+maniera analoga si può utilizzare la variabile \macro{in6addr\_loopback} per

 indicare l'indirizzo di \textit{loopback}, che a sua volta viene inizializzata
 staticamente a \const{IN6ADRR\_LOOPBACK\_INIT}.
 
 indicare l'indirizzo di \textit{loopback}, che a sua volta viene inizializzata
 staticamente a \const{IN6ADRR\_LOOPBACK\_INIT}.
 


@@ -818,7 +819,7 @@ o problemi nella chiamata della funzione sono le seguenti:
 \begin{enumerate}
 \item Il client non riceve risposta al SYN: l'errore restituito è
   \errcode{ETIMEDOUT}. Stevens riporta che BSD invia un primo SYN alla chiamata
 \begin{enumerate}
 \item Il client non riceve risposta al SYN: l'errore restituito è
   \errcode{ETIMEDOUT}. Stevens riporta che BSD invia un primo SYN alla chiamata

-  di \func{connect}, un'altro dopo 6 secondi, un terzo dopo 24 secondi, se
+  di \func{connect}, un altro dopo 6 secondi, un terzo dopo 24 secondi, se

   dopo 75 secondi non ha ricevuto risposta viene ritornato l'errore. Linux
   invece ripete l'emissione del SYN ad intervalli di 30 secondi per un numero
   di volte che può essere stabilito dall'utente sia con una opportuna
   dopo 75 secondi non ha ricevuto risposta viene ritornato l'errore. Linux
   invece ripete l'emissione del SYN ad intervalli di 30 secondi per un numero
   di volte che può essere stabilito dall'utente sia con una opportuna


@@ -826,10 +827,7 @@ o problemi nella chiamata della funzione sono le seguenti:
   voluto in \file{/proc/sys/net/ipv4/tcp\_syn\_retries}. Il valore predefinito
   per la ripetizione dell'invio è di 5 volte, che comporta un timeout dopo
   circa 180 secondi.
   voluto in \file{/proc/sys/net/ipv4/tcp\_syn\_retries}. Il valore predefinito
   per la ripetizione dell'invio è di 5 volte, che comporta un timeout dopo
   circa 180 secondi.

-%
-% Le informazioni su tutte le opzioni impostabili via /proc stanno in
-% Linux/Documentation/networking/ip-sysctl.txt
-%
+

 \item Il client riceve come risposta al SYN un RST significa che non c'è
   nessun programma in ascolto per la connessione sulla porta specificata (il
   che vuol dire probabilmente che o si è sbagliato il numero della porta o che
 \item Il client riceve come risposta al SYN un RST significa che non c'è
   nessun programma in ascolto per la connessione sulla porta specificata (il
   che vuol dire probabilmente che o si è sbagliato il numero della porta o che


@@ -1793,7 +1791,7 @@ processo ad un gruppo senza privilegi,\footnote{si 
   27--30}) l'operazione usando \func{setuid} per cambiare anche
 l'utente.\footnote{si tenga presente che l'ordine in cui si eseguono queste
   due operazioni è importante, infatti solo avendo i privilegi di
   27--30}) l'operazione usando \func{setuid} per cambiare anche
 l'utente.\footnote{si tenga presente che l'ordine in cui si eseguono queste
   due operazioni è importante, infatti solo avendo i privilegi di

-  amministratore si può cambiare il gruppo di un processo ad un'altro di cui
+  amministratore si può cambiare il gruppo di un processo ad un altro di cui

   non si fa parte, per cui chiamare prima \func{setuid} farebbe fallire una
   successiva chiamata a \func{setgid}.  Inoltre si ricordi (si riveda quanto
   esposto in sez.~\ref{sec:proc_perms}) che usando queste due funzioni il
   non si fa parte, per cui chiamare prima \func{setuid} farebbe fallire una
   successiva chiamata a \func{setgid}.  Inoltre si ricordi (si riveda quanto
   esposto in sez.~\ref{sec:proc_perms}) che usando queste due funzioni il