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

[gapil.git] / othersock.tex

diff --git a/othersock.tex b/othersock.tex
index 856c4f6d5cf2ae0d79676d418db0125689e9ba64..3aa2bb905ba5448ba0fe30965e0d242d369f1382 100644 (file)
--- a/othersock.tex
+++ b/othersock.tex
@@ -54,10 +54,11 @@ utilizzando per il tipo di socket il valore \const{SOCK\_DGRAM}.
 Questa differenza comporta ovviamente che anche le modalità con cui si usano i
 socket UDP sono completamente diverse rispetto ai socket TCP, ed in
 particolare non esistendo il concetto di connessione non esiste il meccanismo
 Questa differenza comporta ovviamente che anche le modalità con cui si usano i
 socket UDP sono completamente diverse rispetto ai socket TCP, ed in
 particolare non esistendo il concetto di connessione non esiste il meccanismo

-del \textit{three way handshake} né quello degli stati del protocollo. In
-realtà tutto quello che avviene nella comunicazione attraverso dei socket UDP
-è la trasmissione di un pacchetto da un client ad un server o viceversa,
-secondo lo schema illustrato in fig.~\ref{fig:UDP_packet-exchange}.
+del \itindex{three~way~handshake}\textit{three way handshake} né quello degli
+stati del protocollo. In realtà tutto quello che avviene nella comunicazione
+attraverso dei socket UDP è la trasmissione di un pacchetto da un client ad un
+server o viceversa, secondo lo schema illustrato in
+fig.~\ref{fig:UDP_packet-exchange}.

 
 \begin{figure}[htb]
   \centering
 
 \begin{figure}[htb]
   \centering


@@ -130,11 +131,11 @@ la destinazione dei dati trasmessi o ottenere l'origine dei dati ricevuti. La
 prima di queste funzioni è \funcd{sendto} ed il suo prototipo\footnote{il
   prototipo illustrato è quello utilizzato dalle \acr{glibc}, che seguono le
   \textit{Single Unix Specification}, l'argomento \param{flags} era di tipo
 prima di queste funzioni è \funcd{sendto} ed il suo prototipo\footnote{il
   prototipo illustrato è quello utilizzato dalle \acr{glibc}, che seguono le
   \textit{Single Unix Specification}, l'argomento \param{flags} era di tipo

-  \type{int} nei vari BSD4.*, mentre nelle \acr{libc4} e \acr{libc5} veniva
-  usato un \type{unsigned int}; l'argomento \param{len} era \type{int} nei
+  \texttt{int} nei vari BSD4.*, mentre nelle \acr{libc4} e \acr{libc5} veniva
+  usato un \texttt{unsigned int}; l'argomento \param{len} era \texttt{int} nei

   vari BSD4.* e nelle \acr{libc4}, ma \type{size\_t} nelle \acr{libc5}; infine
   vari BSD4.* e nelle \acr{libc4}, ma \type{size\_t} nelle \acr{libc5}; infine

-  l'argomento \param{tolen} era \type{int} nei vari BSD4.* nelle \acr{libc4} e
-  nelle \acr{libc5}.} è:
+  l'argomento \param{tolen} era \texttt{int} nei vari BSD4.* nelle \acr{libc4}
+  e nelle \acr{libc5}.} è:

 \begin{functions}
   \headdecl{sys/types.h}
   \headdecl{sys/socket.h}
 \begin{functions}
   \headdecl{sys/types.h}
   \headdecl{sys/socket.h}


@@ -219,9 +220,9 @@ La seconda funzione utilizzata nella comunicazione fra socket UDP 
 \funcd{recvfrom}, che serve a ricevere i dati inviati da un altro socket; il
 suo prototipo\footnote{il prototipo è quello delle \acr{glibc} che seguono le
   \textit{Single Unix Specification}, i vari BSD4.*, le \acr{libc4} e le
 \funcd{recvfrom}, che serve a ricevere i dati inviati da un altro socket; il
 suo prototipo\footnote{il prototipo è quello delle \acr{glibc} che seguono le
   \textit{Single Unix Specification}, i vari BSD4.*, le \acr{libc4} e le

-  \acr{libc5} usano un \type{int} come valore di ritorno; per gli argomenti
+  \acr{libc5} usano un \texttt{int} come valore di ritorno; per gli argomenti

   \param{flags} e \param{len} vale quanto detto a proposito di \func{sendto};
   \param{flags} e \param{len} vale quanto detto a proposito di \func{sendto};

-  infine l'argomento \param{fromlen} è \type{int} per i vari BSD4.*, le
+  infine l'argomento \param{fromlen} è \texttt{int} per i vari BSD4.*, le

   \acr{libc4} e le \acr{libc5}.} è:
 \begin{functions}
   \headdecl{sys/types.h}
   \acr{libc4} e le \acr{libc5}.} è:
 \begin{functions}
   \headdecl{sys/types.h}


@@ -265,8 +266,8 @@ l'indirizzo del mittente del pacchetto che 
 opportunamente inizializzati con i puntatori alle variabili dove la struttura
 contenente quest'ultimo e la relativa lunghezza saranno scritti (si noti che
 \param{fromlen} è un valore intero ottenuto come
 opportunamente inizializzati con i puntatori alle variabili dove la struttura
 contenente quest'ultimo e la relativa lunghezza saranno scritti (si noti che
 \param{fromlen} è un valore intero ottenuto come

-\index{\textit{value~result~argument}}\textit{value result argument}).  Se non
-si è interessati a questa informazione, entrambi gli argomenti devono essere
+\itindex{value~result~argument}\textit{value result argument}).  Se non si è
+interessati a questa informazione, entrambi gli argomenti devono essere

 inizializzati al valore \const{NULL}.
 
 Una differenza fondamentale del comportamento di queste funzioni rispetto alle
 inizializzati al valore \const{NULL}.
 
 Una differenza fondamentale del comportamento di queste funzioni rispetto alle


@@ -322,9 +323,9 @@ Il passo successivo (\texttt{\small 13--21}) 
 struttura degli indirizzi; prima (\texttt{\small 14}) si cancella
 completamente la stessa con \func{memset}, (\texttt{\small 15}) poi si imposta
 la famiglia dell'indirizzo ed infine (\texttt{\small 16} la porta. Infine
 struttura degli indirizzi; prima (\texttt{\small 14}) si cancella
 completamente la stessa con \func{memset}, (\texttt{\small 15}) poi si imposta
 la famiglia dell'indirizzo ed infine (\texttt{\small 16} la porta. Infine

-(\texttt{\small 18--21}) si ricava l'indirizzo del server da contattare dal
-parametro passato a riga di comando, convertendolo con \func{inet\_pton}. Si
-noti come questa sezione sia identica a quella del client TCP di
+(\texttt{\small 18--21}) si ricava l'indirizzo del server da contattare
+dall'argomento passato a riga di comando, convertendolo con \func{inet\_pton}.
+Si noti come questa sezione sia identica a quella del client TCP di

 fig.~\ref{fig:TCP_daytime_client_code}, in quanto la determinazione dell'uso
 di UDP al posto di TCP è stata effettuata quando si è creato il socket.
 
 fig.~\ref{fig:TCP_daytime_client_code}, in quanto la determinazione dell'uso
 di UDP al posto di TCP è stata effettuata quando si è creato il socket.
 


@@ -694,7 +695,7 @@ illustrate in fig.~\ref{fig:UDP_echo_conn_cli}.
 Ed in questo caso rispetto alla precedente versione, il solo cambiamento è
 l'utilizzo (\texttt{\small 17}) della funzione \func{connect} prima della
 chiamata alla funzione di gestione del protocollo, che a sua volta è stata
 Ed in questo caso rispetto alla precedente versione, il solo cambiamento è
 l'utilizzo (\texttt{\small 17}) della funzione \func{connect} prima della
 chiamata alla funzione di gestione del protocollo, che a sua volta è stata

-modificata eliminando l'indirizzo passato come parametro e sostituendo le
+modificata eliminando l'indirizzo passato come argomento e sostituendo le

 chiamata a \func{sendto} e \func{recvfrom} con chiamate a \func{read} e
 \func{write} come illustrato dal nuovo codice riportato in
 fig.~\ref{fig:UDP_echo_conn_echo_client}.
 chiamata a \func{sendto} e \func{recvfrom} con chiamate a \func{read} e
 \func{write} come illustrato dal nuovo codice riportato in
 fig.~\ref{fig:UDP_echo_conn_echo_client}.


@@ -747,13 +748,19 @@ l'interfaccia di programmazione che serve ad utilizzarli resta sempre quella
 dei socket.
 
 
 dei socket.
 
 

+\section{I socket \textit{raw}}
+\label{sec:socket_raw}
+
+Tratteremo in questa sezione i cosiddetti \textit{raw socket}, con i quali si
+possono \textsl{forgiare} direttamente i pacchetti a tutti i livelli dello
+stack dei protocolli. 
+

 
 \section{Altri socket}
 \label{sec:socket_other}
 
 Tratteremo in questa sezione gli altri tipi particolari di socket supportati
 
 \section{Altri socket}
 \label{sec:socket_other}
 
 Tratteremo in questa sezione gli altri tipi particolari di socket supportati

-da Linux, come i \textit{raw socket}, con i quali si possono \textsl{forgiare}
-direttamente i pacchetti a tutti i livelli dello stack dei protocolli, o i
+da Linux, come quelli relativi a particolare protocolli di trasmissione ed i

 socket \textit{netlink} che definiscono una interfaccia di comunicazione con
 il kernel.
 
 socket \textit{netlink} che definiscono una interfaccia di comunicazione con
 il kernel.