X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=tcpsock.tex;h=19a9898e0a4a948c3fa70bcb291e1c4ac160fcbf;hp=81cb8e45af9f21156a05256935f19287e1ebf7aa;hb=18f401b26dcb222f30925a0cf03cca8db52495cb;hpb=265547995607b3ec2c04f9b8b035b416e892920b

diff --git a/tcpsock.tex b/tcpsock.tex
index 81cb8e4..19a9898 100644
--- a/tcpsock.tex
+++ b/tcpsock.tex
@@ -144,29 +144,28 @@ connessione.  Normalmente vengono usate le seguenti opzioni:
   sez.~\ref{sec:sock_tcp_udp_options}).
   
 \item \textit{window scale option}, il protocollo TCP implementa il controllo
-  di flusso attraverso una \itindex{advertised~window} \textit{advertised
-    window} (la ``\textsl{finestra annunciata}'', vedi
-  sez.~\ref{sec:tcp_protocol_xxx}) con la quale ciascun capo della
-  comunicazione dichiara quanto spazio disponibile ha in memoria per i dati.
-  Questo è un numero a 16 bit dell'header, che così può indicare un massimo di
-  65535 byte;\footnote{in Linux il massimo è 32767 per evitare problemi con
-    alcune implementazioni che usano l'aritmetica con segno per implementare
-    lo stack TCP.} ma alcuni tipi di connessione come quelle ad alta velocità
-  (sopra i 45Mbit/sec) e quelle che hanno grandi ritardi nel cammino dei
-  pacchetti (come i satelliti) richiedono una finestra più grande per poter
-  ottenere il massimo dalla trasmissione. Per questo esiste questa opzione che
-  indica un fattore di scala da applicare al valore della
-  \itindex{advertised~window} finestra annunciata\footnote{essendo una nuova
-    opzione per garantire la compatibilità con delle vecchie implementazioni
-    del protocollo la procedura che la attiva prevede come negoziazione che
-    l'altro capo della connessione riconosca esplicitamente l'opzione
-    inserendola anche lui nel suo SYN di risposta dell'apertura della
-    connessione.} per la connessione corrente (espresso come numero di bit cui
-  spostare a sinistra il valore della finestra annunciata inserito nel
-  pacchetto). Con Linux è possibile indicare al kernel di far negoziare il
-  fattore di scala in fase di creazione di una connessione tramite la
-  \textit{sysctl} \itindex{TCP~window~scaling} \texttt{tcp\_window\_scaling}
-  (vedi sez.~\ref{sec:sock_ipv4_sysctl}).\footnote{per poter usare questa
+  di flusso attraverso una \textit{advertised window} (la ``\textsl{finestra
+    annunciata}'', vedi sez.~\ref{sec:tcp_protocol_xxx}) con la quale ciascun
+  capo della comunicazione dichiara quanto spazio disponibile ha in memoria
+  per i dati.  Questo è un numero a 16 bit dell'header, che così può indicare
+  un massimo di 65535 byte;\footnote{in Linux il massimo è 32767 per evitare
+    problemi con alcune implementazioni che usano l'aritmetica con segno per
+    implementare lo stack TCP.} ma alcuni tipi di connessione come quelle ad
+  alta velocità (sopra i 45Mbit/sec) e quelle che hanno grandi ritardi nel
+  cammino dei pacchetti (come i satelliti) richiedono una finestra più grande
+  per poter ottenere il massimo dalla trasmissione. Per questo esiste questa
+  opzione che indica un fattore di scala da applicare al valore della finestra
+  annunciata\footnote{essendo una nuova opzione per garantire la compatibilità
+    con delle vecchie implementazioni del protocollo la procedura che la
+    attiva prevede come negoziazione che l'altro capo della connessione
+    riconosca esplicitamente l'opzione inserendola anche lui nel suo SYN di
+    risposta dell'apertura della connessione.} per la connessione corrente
+  (espresso come numero di bit cui spostare a sinistra il valore della
+  finestra annunciata inserito nel pacchetto). Con Linux è possibile indicare
+  al kernel di far negoziare il fattore di scala in fase di creazione di una
+  connessione tramite la \textit{sysctl} \itindex{TCP~window~scaling}
+  \texttt{tcp\_window\_scaling} (vedi
+  sez.~\ref{sec:sock_ipv4_sysctl}).\footnote{per poter usare questa
     funzionalità è comunque necessario ampliare le dimensioni dei buffer di
     ricezione e spedizione, cosa che può essere fatta sia a livello di sistema
     con le opportune \textit{sysctl} (vedi sez.~\ref{sec:sock_ipv4_sysctl})
@@ -2400,13 +2399,13 @@ si aveva il SYN flag attivo.  Si noti come a partire dal secondo pacchetto sia
 sempre attivo il campo \texttt{ack}, seguito dal numero di sequenza per il
 quale si da il ricevuto; quest'ultimo, a partire dal terzo pacchetto, viene
 espresso in forma relativa per maggiore compattezza.  Il campo \texttt{win} in
-ogni riga indica la \itindex{advertised~window} \textit{advertised window} di
-cui parlavamo in sez.~\ref{sec:TCP_TCP_opt}.  Allora si può verificare
-dall'output del comando come venga appunto realizzata la sequenza di pacchetti
-descritta in sez.~\ref{sec:TCP_conn_cre}: prima viene inviato dal client un
-primo pacchetto con il SYN che inizia la connessione, a cui il server risponde
-dando il ricevuto con un secondo pacchetto, che a sua volta porta un SYN, cui
-il client risponde con un il terzo pacchetto di ricevuto.
+ogni riga indica la \textit{advertised window} di cui parlavamo in
+sez.~\ref{sec:TCP_TCP_opt}.  Allora si può verificare dall'output del comando
+come venga appunto realizzata la sequenza di pacchetti descritta in
+sez.~\ref{sec:TCP_conn_cre}: prima viene inviato dal client un primo pacchetto
+con il SYN che inizia la connessione, a cui il server risponde dando il
+ricevuto con un secondo pacchetto, che a sua volta porta un SYN, cui il client
+risponde con un il terzo pacchetto di ricevuto.
 
 Ritorniamo allora alla nostra sessione con il servizio echo: dopo le tre righe
 del \itindex{three~way~handshake} \textit{three way handshake} non avremo