X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=tcpsock.tex;h=583ec3d14cecf907f70cf4c89675b43bccc9ab98;hp=78a6ce446664057d26eecd33fc6de8ea8f8fc65f;hb=b38fb9f5c8fb8360f7ac296baa8f4a0bdd692d1c;hpb=997a10619163980437d438ba7a4d8dda3fc56d98

diff --git a/tcpsock.tex b/tcpsock.tex
index 78a6ce4..583ec3d 100644
--- a/tcpsock.tex
+++ b/tcpsock.tex
@@ -38,7 +38,7 @@ significato di alcuni dei vari \textsl{stati} ad essa associati.
 \subsection{La creazione della connessione: il \textit{three way handshake}}
 \label{sec:TCP_conn_cre}
 
-\index{\textit{three~way~handshake}|(}
+\itindbeg{three~way~handshake} 
 Il processo che porta a creare una connessione TCP è chiamato \textit{three
   way handshake}; la successione tipica degli eventi (e dei
 \textsl{segmenti}\footnote{Si ricordi che il segmento è l'unità elementare di
@@ -118,7 +118,8 @@ aspetta di ricevere con il pacchetto successivo; dato che il primo pacchetto
 SYN consuma un byte, nel \textit{three way handshake} il numero di acknowledge
 è sempre pari al numero di sequenza iniziale incrementato di uno; lo stesso
 varrà anche (vedi fig.~\ref{fig:TCP_close}) per l'acknowledgement di un FIN.
-\index{\textit{three~way~handshake}|)}
+
+\itindend{three~way~handshake}
 
 
 \subsection{Le opzioni TCP.}
@@ -716,7 +717,7 @@ Si noti che si 
 \const{INADDR\_ANY}, anche se, essendo questo nullo, il riordinamento è
 inutile.  Si tenga presente comunque che tutte le costanti \val{INADDR\_}
 (riportate in tab.~\ref{tab:TCP_ipv4_addr}) sono definite secondo
-l'\textit{endianess}\index{\textit{endianess}} della macchina, ed anche se
+l'\textit{endianess}\itindex{endianess} della macchina, ed anche se
 esse possono essere invarianti rispetto all'ordinamento dei bit, è comunque
 buona norma usare sempre la funzione \func{htonl}.
 
@@ -765,8 +766,8 @@ connessione con un server TCP,\footnote{di nuovo la funzione 
   limiterà ad impostare l'indirizzo dal quale e verso il quale saranno inviati
   e ricevuti i pacchetti, mentre per socket di tipo \const{SOCK\_STREAM} o
   \const{SOCK\_SEQPACKET}, essa attiverà la procedura di avvio (nel caso del
-  TCP il \index{\textit{three~way~handshake}}\textit{three way handshake})
-  della connessione.}  il prototipo della funzione è il seguente:
+  TCP il \itindex{three~way~handshake}\textit{three way handshake}) della
+  connessione.}  il prototipo della funzione è il seguente:
 \begin{prototype}{sys/socket.h}
   {int connect(int sockfd, const struct sockaddr *servaddr, socklen\_t
     addrlen)}
@@ -809,7 +810,7 @@ nell'esempio sez.~\ref{sec:TCP_daytime_client}, usando le funzioni illustrate
 in sez.~\ref{sec:sock_addr_func}.
 
 Nel caso di socket TCP la funzione \func{connect} avvia il
-\index{\textit{three~way~handshake}}\textit{three way handshake}, e ritorna
+\itindex{three~way~handshake}\textit{three way handshake}, e ritorna
 solo quando la connessione è stabilita o si è verificato un errore. Le
 possibili cause di errore sono molteplici (ed i relativi codici riportati
 sopra), quelle che però dipendono dalla situazione della rete e non da errori
@@ -908,7 +909,7 @@ infatti vengono mantenute due code:
 \begin{enumerate}
 \item La coda delle connessioni incomplete (\textit{incomplete connection
     queue} che contiene un riferimento per ciascun socket per il quale è
-  arrivato un SYN ma il \index{\textit{three~way~handshake}}\textit{three way
+  arrivato un SYN ma il \itindex{three~way~handshake}\textit{three way
     handshake} non si è ancora concluso.  Questi socket sono tutti nello stato
   \texttt{SYN\_RECV}.
 \item La coda delle connessioni complete (\textit{complete connection queue}
@@ -922,7 +923,7 @@ quando arriva un SYN da un client il server crea una nuova voce nella coda
 delle connessioni incomplete, e poi risponde con il SYN$+$ACK. La voce resterà
 nella coda delle connessioni incomplete fino al ricevimento dell'ACK dal
 client o fino ad un timeout. Nel caso di completamento del
-\index{\textit{three~way~handshake}}\textit{three way handshake} la voce viene
+\itindex{three~way~handshake}\textit{three way handshake} la voce viene
 spostata nella coda delle connessioni complete.  Quando il processo chiama la
 funzione \func{accept} (vedi sez.~\ref{sec:TCP_func_accept}) la prima voce
 nella coda delle connessioni complete è passata al programma, o, se la coda è
@@ -979,7 +980,7 @@ che il compito principale della coda sia quello di gestire il caso in cui il
 server è occupato fra chiamate successive alla \func{accept} (per cui la coda
 più occupata sarebbe quella delle connessioni completate), ma piuttosto quello
 di gestire la presenza di un gran numero di SYN in attesa di concludere il
-\textit{three way handshake}\index{\textit{three~way~handshake}}.
+\textit{three way handshake}\itindex{three~way~handshake}.
 
 Infine va messo in evidenza che, nel caso di socket TCP, quando un SYN arriva
 con tutte le code piene, il pacchetto deve essere ignorato. Questo perché la
@@ -997,10 +998,10 @@ trasparente dal protocollo TCP.
 \label{sec:TCP_func_accept}
 
 La funzione \funcd{accept} è chiamata da un server per gestire la connessione
-una volta che sia stato completato il \textit{three way
-  handshake},\footnote{la funzione è comunque generica ed è utilizzabile su
-  socket di tipo \const{SOCK\_STREAM}, \const{SOCK\_SEQPACKET} e
-  \const{SOCK\_RDM}.} la funzione restituisce un nuovo socket descriptor su
+una volta che sia stato completato il \itindex{three~way~handshake}
+\textit{three way handshake},\footnote{la funzione è comunque generica ed è
+  utilizzabile su socket di tipo \const{SOCK\_STREAM}, \const{SOCK\_SEQPACKET}
+  e \const{SOCK\_RDM}.} la funzione restituisce un nuovo socket descriptor su
 cui si potrà operare per effettuare la comunicazione. Se non ci sono
 connessioni completate il processo viene messo in attesa. Il prototipo della
 funzione è il seguente:
@@ -1911,14 +1912,14 @@ connessioni da qualunque indirizzo e da qualunque porta e su qualunque
 interfaccia locale.
 
 A questo punto si può lanciare il client, esso chiamerà \func{socket} e
-\func{connect}; una volta completato il \textit{three way handshake} la
-connessione è stabilita; la \func{connect} ritornerà nel client\footnote{si
-  noti che è sempre la \func{connect} del client a ritornare per prima, in
-  quanto questo avviene alla ricezione del secondo segmento (l'ACK del server)
-  del \textit{three way handshake}, la \func{accept} del server ritorna solo
-  dopo un altro mezzo RTT quando il terzo segmento (l'ACK del client) viene
-  ricevuto.}  e la \func{accept} nel server, ed usando di nuovo \cmd{netstat}
-otterremmo che:
+\func{connect}; una volta completato il \itindex{three~way~handshake}
+\textit{three way handshake} la connessione è stabilita; la \func{connect}
+ritornerà nel client\footnote{si noti che è sempre la \func{connect} del
+  client a ritornare per prima, in quanto questo avviene alla ricezione del
+  secondo segmento (l'ACK del server) del \textit{three way handshake}, la
+  \func{accept} del server ritorna solo dopo un altro mezzo RTT quando il
+  terzo segmento (l'ACK del client) viene ricevuto.}  e la \func{accept} nel
+server, ed usando di nuovo \cmd{netstat} otterremmo che:
 \begin{verbatim}
 Active Internet connections (servers and established)
 Proto Recv-Q Send-Q Local Address           Foreign Address         State
@@ -2262,10 +2263,10 @@ Bench
 con dei server molto occupati. In tal caso, con una struttura del server
 simile a quella del nostro esempio, in cui la gestione delle singole
 connessioni è demandata a processi figli, può accadere che il \textit{three
-  way handshake}\index{\textit{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 ad eseguire la chiamata ad
-\func{accept}. Di nuovo si ha una situazione analoga a quella illustrata in
+  way handshake}\itindex{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 ad eseguire la chiamata ad \func{accept}. Di
+nuovo si ha una situazione analoga a quella illustrata in
 fig.~\ref{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.
@@ -2373,8 +2374,8 @@ anarres.echo > gont.34559: R 511689732:511689732(0) win 0
 
 Le prime tre righe vengono prodotte al momento in cui lanciamo il nostro
 client, e corrispondono ai tre pacchetti del
-\index{\textit{three~way~handshake}}\textit{three way handshake}.  L'output
-del comando riporta anche i numeri di sequenza iniziali, mentre la lettera
+\itindex{three~way~handshake}\textit{three way handshake}.  L'output del
+comando riporta anche i numeri di sequenza iniziali, mentre la lettera
 \texttt{S} indica che per quel pacchetto 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
@@ -2388,17 +2389,17 @@ 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 \textit{three way handshake}\index{\textit{three~way~handshake}} non
-avremo nulla fin tanto che non scriveremo una prima riga sul client; al
-momento in cui facciamo questo si genera una sequenza di altri quattro
-pacchetti. Il primo, dal client al server, contraddistinto da una lettera
-\texttt{P} che significa che il flag PSH è impostato, contiene la nostra riga
-(che è appunto di 11 caratteri), e ad esso il server risponde immediatamente
-con un pacchetto vuoto di ricevuto. Poi tocca al server riscrivere indietro
-quanto gli è stato inviato, per cui sarà lui a mandare indietro un terzo
-pacchetto con lo stesso contenuto appena ricevuto, e a sua volta riceverà dal
-client un ACK nel quarto pacchetto.  Questo causerà la ricezione dell'eco nel
-client che lo stamperà a video.
+del \textit{three way handshake}\itindex{three~way~handshake} non avremo nulla
+fin tanto che non scriveremo una prima riga sul client; al momento in cui
+facciamo questo si genera una sequenza di altri quattro pacchetti. Il primo,
+dal client al server, contraddistinto da una lettera \texttt{P} che significa
+che il flag PSH è impostato, contiene la nostra riga (che è appunto di 11
+caratteri), e ad esso il server risponde immediatamente con un pacchetto vuoto
+di ricevuto. Poi tocca al server riscrivere indietro quanto gli è stato
+inviato, per cui sarà lui a mandare indietro un terzo pacchetto con lo stesso
+contenuto appena ricevuto, e a sua volta riceverà dal client un ACK nel quarto
+pacchetto.  Questo causerà la ricezione dell'eco nel client che lo stamperà a
+video.
 
 A questo punto noi procediamo ad interrompere l'esecuzione del server con un
 \texttt{C-c} (cioè con l'invio di \const{SIGTERM}): nel momento in cui