Sistemato un conflitto con un correzione applicata due volte ed indicizzato

in maniera uniforme RTT.

diff --git a/fileunix.tex b/fileunix.tex
index bfaab858ad4566a48af8e5c4240b5eb3b2a17356..52dc4a16ce535c91c18ef07150dcc849ab0742ed 100644 (file)
--- a/fileunix.tex
+++ b/fileunix.tex
@@ -81,7 +81,7 @@ file, fra cui:
 \item lo stato del file (nel campo \var{f\_flags}).
 \item il valore della posizione corrente (l'\textit{offset}) nel file (nel
   campo \var{f\_pos}).
-\item un puntatore all'inode\index{inode}\footnote{nel kernel 2.4.x si è in
+\item un puntatore \index{inode} all'inode\footnote{nel kernel 2.4.x si è in
     realtà passati ad un puntatore ad una struttura \struct{dentry} che punta a
     sua volta all'inode\index{inode} passando per la nuova struttura del VFS.}
   del file.
@@ -118,10 +118,10 @@ stato chiuso nessuno in precedenza).
 
 In tutti i sistemi unix-like esiste una convenzione generale per cui ogni
 processo viene lanciato dalla shell con almeno tre file aperti. Questi, per
-quanto appena detto, avranno come \textit{file
-  descriptor}\index{file!descriptor} i valori 0, 1 e 2.  Benché questa sia
-soltanto una convenzione, essa è seguita dalla gran parte delle applicazioni,
-e non aderirvi potrebbe portare a gravi problemi di interoperabilità.
+quanto appena detto, avranno come \index{file!descriptor} \textit{file
+  descriptor} i valori 0, 1 e 2.  Benché questa sia soltanto una convenzione,
+essa è seguita dalla gran parte delle applicazioni, e non aderirvi potrebbe
+portare a gravi problemi di interoperabilità.
 
 Il primo file è sempre associato al cosiddetto \textit{standard input}; è cioè
 il file da cui il processo si aspetta di ricevere i dati in ingresso. Il
@@ -296,6 +296,7 @@ descriptor con il valore pi
                          \itindex{Denial~of~Service~(DoS)}
                          \textit{DoS}\protect\footnotemark\ quando 
                          \func{opendir} viene chiamata su una fifo o su un
+                         dispositivo associato ad una unità a nastri, non deve
                          dispositivo a nastri; non deve essere utilizzato
                          al di fuori dell'implementazione di \func{opendir}. \\
     \const{O\_LARGEFILE}&nel caso di sistemi a 32 bit che supportano file di
@@ -1335,4 +1336,4 @@ relativi ad operazioni comunque eseguibili anche attraverso \func{fcntl}.
 % LocalWords:  SETOWN GETSIG SETSIG sigaction SIGINFO siginfo SETLEASE lease is
 % LocalWords:  truncate GETLEASE NOTIFY all'I AND ACCMODE ioctl everything argp
 % LocalWords:  framebuffer request ENOTTY CDROM nell'header magic number
-% LocalWords:  FIOCLEX FIONCLEX FIOASYNC FIONBIO
+% LocalWords:  FIOCLEX FIONCLEX FIOASYNC FIONBIO NOATIME

diff --git a/network.tex b/network.tex
index 9f67097ab5f60cc43be86c86cd47abd1c23c0fdd..619793641b3577bec8bb118ade929e86757ddc16 100644 (file)
--- a/network.tex
+++ b/network.tex
@@ -647,9 +647,9 @@ minuti.
 Inoltre, per tenere conto delle diverse condizioni in cui può trovarsi la
 linea di comunicazione, TCP comprende anche un algoritmo di calcolo dinamico
 del tempo di andata e ritorno dei pacchetti fra un client e un server (il
-cosiddetto RTT, \textit{round-trip time}), che lo rende in grado di adattarsi
-alle condizioni della rete per non generare inutili ritrasmissioni o cadere
-facilmente in timeout.
+cosiddetto RTT, \itindex{Round~Trip~Time} \textit{Round Trip Time}), che lo
+rende in grado di adattarsi alle condizioni della rete per non generare
+inutili ritrasmissioni o cadere facilmente in timeout.
 
 Inoltre TCP è in grado di preservare l'ordine dei dati assegnando un numero di
 sequenza ad ogni byte che trasmette. Ad esempio se un'applicazione scrive 3000

diff --git a/sockctrl.tex b/sockctrl.tex
index 3170c53ca6a7a7aabe28ec8fe46d7369b420d7da..a307c197b5f32b11ac4b459e7427d4e1938e9a76 100644 (file)
--- a/sockctrl.tex
+++ b/sockctrl.tex
@@ -3025,9 +3025,9 @@ identificano le operazioni sono le seguenti:
 \item[\const{SIOCGSTAMP}] restituisce il contenuto di una struttura
   \struct{timeval} con la marca temporale dell'ultimo pacchetto ricevuto sul
   socket, questa operazione può essere utilizzata per effettuare delle
-  misurazioni precise del tempo di andata e ritorno\footnote{il cosiddetto
-    \itindex{round~trip~time} \textit{round trip time}.} dei pacchetti sulla
-  rete.
+  misurazioni precise del tempo di andata e ritorno\footnote{il
+    \itindex{Round~Trip~Time} \textit{Round Trip Time} cui abbiamo già
+    accennato in sez.~\ref{sec:net_tcp}.} dei pacchetti sulla rete.
 
 \item[\const{SIOCSPGRP}] imposta il processo o il \itindex{process~group}
   \textit{process group} a cui inviare i segnali \const{SIGIO} e

diff --git a/tcpsock.tex b/tcpsock.tex
index 31667f13bb43fc45ced2da84ac881bf0d4875878..54b9e0a93c17decdb52a84be861b38f7817a5f28 100644 (file)
--- a/tcpsock.tex
+++ b/tcpsock.tex
@@ -3126,8 +3126,9 @@ velocit
 una macchina remota occorre un certo tempo perché i pacchetti vi arrivino,
 vengano processati, e poi tornino indietro. Considerando trascurabile il tempo
 di processo, questo tempo è quello impiegato nella trasmissione via rete, che
-viene detto RTT (dalla denominazione inglese \textit{Round Trip Time}) ed è
-quello che viene stimato con l'uso del comando \cmd{ping}.
+viene detto RTT (dalla denominazione inglese \itindex{Round~Trip~Time}
+\textit{Round Trip Time}) ed è quello che viene stimato con l'uso del comando
+\cmd{ping}.
 
 A questo punto, se torniamo al codice mostrato in
 fig.~\ref{fig:TCP_ClientEcho_third}, possiamo vedere che mentre i pacchetti