Piccole correzioni dimenticate

[gapil.git] / othersock.tex

diff --git a/othersock.tex b/othersock.tex
index abf0f782533c07e85fb66bf14f74083688cf6052..24db472c41c4d7f881700c5053c4a2bd18bec1b6 100644 (file)
--- a/othersock.tex
+++ b/othersock.tex
@@ -1,6 +1,6 @@
 %% othersock.tex
 %%
 %% othersock.tex
 %%

-%% Copyright (C) 2004-2011 Simone Piccardi.  Permission is granted to
+%% Copyright (C) 2004-2017 Simone Piccardi.  Permission is granted to

 %% copy, distribute and/or modify this document under the terms of the GNU Free
 %% Documentation License, Version 1.1 or any later version published by the
 %% Free Software Foundation; with the Invariant Sections being "Un preambolo",
 %% copy, distribute and/or modify this document under the terms of the GNU Free
 %% Documentation License, Version 1.1 or any later version published by the
 %% Free Software Foundation; with the Invariant Sections being "Un preambolo",


@@ -55,15 +55,13 @@ 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 \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
-  \includegraphics[width=10cm]{img/udp_connection}  
+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}.
+
+\begin{figure}[!htb]
+  \centering \includegraphics[width=10cm]{img/udp_connection}  

   \caption{Lo schema di interscambio dei pacchetti per una comunicazione via
      UDP.}
   \label{fig:UDP_packet-exchange}
   \caption{Lo schema di interscambio dei pacchetti per una comunicazione via
      UDP.}
   \label{fig:UDP_packet-exchange}


@@ -71,8 +69,8 @@ fig.~\ref{fig:UDP_packet-exchange}.
 
 Come illustrato in fig.~\ref{fig:UDP_packet-exchange} la struttura generica di
 un server UDP prevede, una volta creato il socket, la chiamata a \func{bind}
 
 Come illustrato in fig.~\ref{fig:UDP_packet-exchange} la struttura generica di
 un server UDP prevede, una volta creato il socket, la chiamata a \func{bind}

-per mettersi in ascolto dei dati. Questa è l'unica parte comune con un server
-TCP: non essendovi il concetto di connessione le funzioni \func{listen} ed
+per mettersi in ascolto dei dati, questa è l'unica parte comune con un server
+TCP. Non essendovi il concetto di connessione le funzioni \func{listen} ed

 \func{accept} non sono mai utilizzate nel caso di server UDP. La ricezione dei
 dati dal client avviene attraverso la funzione \func{recvfrom}, mentre una
 eventuale risposta sarà inviata con la funzione \func{sendto}.
 \func{accept} non sono mai utilizzate nel caso di server UDP. La ricezione dei
 dati dal client avviene attraverso la funzione \func{recvfrom}, mentre una
 eventuale risposta sarà inviata con la funzione \func{sendto}.


@@ -132,11 +130,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

-  \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
-  l'argomento \param{tolen} era \texttt{int} nei vari BSD4.* nelle \acr{libc4}
-  e nelle \acr{libc5}.} è:
+  \ctyp{int} nei vari BSD4.*, mentre nelle \acr{libc4} e \acr{libc5} veniva
+  usato un \texttt{unsigned int}; l'argomento \param{len} era \ctyp{int} nei
+  vari BSD4.* e nelle \acr{libc4}, ma \type{size\_t} nelle \acr{libc5};
+  infine l'argomento \param{tolen} era \ctyp{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}


@@ -168,7 +166,7 @@ prima di queste funzioni è \funcd{sendto} ed il suo prototipo\footnote{il
   \item[\errcode{EOPNOTSUPP}] il valore di \param{flag} non è appropriato per
     il tipo di socket usato.
   \item[\errcode{EPIPE}] il capo locale della connessione è stato chiuso, si
   \item[\errcode{EOPNOTSUPP}] il valore di \param{flag} non è appropriato per
     il tipo di socket usato.
   \item[\errcode{EPIPE}] il capo locale della connessione è stato chiuso, si

-    riceverà anche un segnale di \const{SIGPIPE}, a meno di non aver impostato
+    riceverà anche un segnale di \signal{SIGPIPE}, a meno di non aver impostato

     \const{MSG\_NOSIGNAL} in \param{flags}.
   \end{errlist}
   ed anche \errval{EFAULT}, \errval{EBADF}, \errval{EINVAL}, \errval{EINTR},
     \const{MSG\_NOSIGNAL} in \param{flags}.
   \end{errlist}
   ed anche \errval{EFAULT}, \errval{EBADF}, \errval{EINVAL}, \errval{EINTR},


@@ -203,7 +201,7 @@ Se il socket è di un tipo che prevede le connessioni (ad esempio un socket
 TCP), questo deve essere già connesso prima di poter eseguire la funzione, in
 caso contrario si riceverà un errore di \errcode{ENOTCONN}. In questo
 specifico caso in cui gli argomenti \param{to} e \param{tolen} non servono
 TCP), questo deve essere già connesso prima di poter eseguire la funzione, in
 caso contrario si riceverà un errore di \errcode{ENOTCONN}. In questo
 specifico caso in cui gli argomenti \param{to} e \param{tolen} non servono

-essi dovranno essere inizializzati rispettivamente a \const{NULL} e 0;
+essi dovranno essere inizializzati rispettivamente a \val{NULL} e 0;

 normalmente quando si opera su un socket connesso essi vengono ignorati, ma
 qualora si sia specificato un indirizzo è possibile ricevere un errore di
 \errcode{EISCONN}.
 normalmente quando si opera su un socket connesso essi vengono ignorati, ma
 qualora si sia specificato un indirizzo è possibile ricevere un errore di
 \errcode{EISCONN}.


@@ -211,19 +209,19 @@ qualora si sia specificato un indirizzo è possibile ricevere un errore di
 Finora abbiamo tralasciato l'argomento \param{flags}; questo è un intero usato
 come maschera binaria che permette di impostare una serie di modalità di
 funzionamento della comunicazione attraverso il socket (come
 Finora abbiamo tralasciato l'argomento \param{flags}; questo è un intero usato
 come maschera binaria che permette di impostare una serie di modalità di
 funzionamento della comunicazione attraverso il socket (come

-\const{MSG\_NOSIGNAL} che impedisce l'invio del segnale \const{SIGPIPE} quando
-si è già chiuso il capo locale della connessione). Torneremo con maggiori
-dettagli sul significato di questo argomento in sez.~\ref{sec:net_sendmsg},
-dove tratteremo le funzioni avanzate dei socket, per il momento ci si può
-limitare ad usare sempre un valore nullo.
+\constd{MSG\_NOSIGNAL} che impedisce l'invio del segnale \signal{SIGPIPE}
+quando si è già chiuso il capo locale della connessione). Torneremo con
+maggiori dettagli sul significato di questo argomento in
+sez.~\ref{sec:net_sendmsg}, dove tratteremo le funzioni avanzate dei socket,
+per il momento ci si può limitare ad usare sempre un valore nullo.

 
 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
 
 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

-  \acr{libc5} usano un \texttt{int} come valore di ritorno; per gli argomenti
+  \acr{libc5} usano un \ctyp{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} è \texttt{int} per i vari BSD4.*, le
+  infine l'argomento \param{fromlen} è \ctyp{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}


@@ -232,7 +230,7 @@ suo prototipo\footnote{il prototipo è quello delle \acr{glibc} che seguono le
   \funcdecl{ssize\_t recvfrom(int sockfd, const void *buf, size\_t len, int
     flags, const struct sockaddr *from, socklen\_t *fromlen)}
   
   \funcdecl{ssize\_t recvfrom(int sockfd, const void *buf, size\_t len, int
     flags, const struct sockaddr *from, socklen\_t *fromlen)}
   

-  Riceve un messaggio ad un socket.
+  Riceve un messaggio da un socket.

   
   \bodydesc{La funzione restituisce il numero di byte ricevuti in caso di
     successo e -1 in caso di errore; nel qual caso \var{errno} assumerà il
   
   \bodydesc{La funzione restituisce il numero di byte ricevuti in caso di
     successo e -1 in caso di errore; nel qual caso \var{errno} assumerà il


@@ -278,9 +276,9 @@ dell'indirizzo.\footnote{si ricordi che \ctyp{sockaddr} è un tipo generico che
   \param{from} e se è insufficiente l'indirizzo risulterà corrotto.}  Al
 ritorno della funzione si otterranno i dati dell'indirizzo e la sua effettiva
 lunghezza, (si noti che \param{fromlen} è un valore intero ottenuto come
   \param{from} e se è insufficiente l'indirizzo risulterà corrotto.}  Al
 ritorno della funzione si otterranno i dati dell'indirizzo e la sua effettiva
 lunghezza, (si noti che \param{fromlen} è un valore intero ottenuto come

-\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}.
+\textit{value result argument}).  Se non si è interessati a questa
+informazione, entrambi gli argomenti devono essere inizializzati al valore
+\val{NULL}.

 
 Una differenza fondamentale del comportamento di queste funzioni rispetto alle
 usuali \func{read} e \func{write} che abbiamo usato con i socket TCP è che in
 
 Una differenza fondamentale del comportamento di queste funzioni rispetto alle
 usuali \func{read} e \func{write} che abbiamo usato con i socket TCP è che in


@@ -307,9 +305,9 @@ che nel caso di uso di UDP prescrive che il client debba inviare un pacchetto
 UDP al server (di contenuto non specificato), il quale risponderà a inviando a
 sua volta un pacchetto UDP contenente la data.
 
 UDP al server (di contenuto non specificato), il quale risponderà a inviando a
 sua volta un pacchetto UDP contenente la data.
 

-\begin{figure}[!htb] 
+\begin{figure}[!htbp] 

   \footnotesize \centering
   \footnotesize \centering

-  \begin{minipage}[c]{15.6cm}
+  \begin{minipage}[c]{\codesamplewidth}

     \includecodesample{listati/UDP_daytime.c}
   \end{minipage} 
   \normalsize
     \includecodesample{listati/UDP_daytime.c}
   \end{minipage} 
   \normalsize


@@ -407,9 +405,9 @@ server.  Si ricordi che il compito di quest'ultimo è quello di ricevere un
 pacchetto di richiesta ed inviare in risposta un pacchetto contenente una
 stringa con la data corrente. 
 
 pacchetto di richiesta ed inviare in risposta un pacchetto contenente una
 stringa con la data corrente. 
 

-\begin{figure}[!htb] 
+\begin{figure}[!htbp] 

   \footnotesize \centering
   \footnotesize \centering

-  \begin{minipage}[c]{15.6cm}
+  \begin{minipage}[c]{\codesamplewidth}

     \includecodesample{listati/UDP_daytimed.c}
   \end{minipage} 
   \normalsize
     \includecodesample{listati/UDP_daytimed.c}
   \end{minipage} 
   \normalsize


@@ -509,9 +507,9 @@ nella chiamata a \func{recvfrom}. Per evidenziare meglio quali problemi si
 possono avere proviamo allora con un servizio leggermente più complesso come
 \textit{echo}. 
 
 possono avere proviamo allora con un servizio leggermente più complesso come
 \textit{echo}. 
 

-\begin{figure}[!htb] 
+\begin{figure}[!htbp] 

   \footnotesize \centering
   \footnotesize \centering

-  \begin{minipage}[c]{15.6cm}
+  \begin{minipage}[c]{\codesamplewidth}

     \includecodesample{listati/UDP_echo_first.c}
   \end{minipage} 
   \normalsize
     \includecodesample{listati/UDP_echo_first.c}
   \end{minipage} 
   \normalsize


@@ -530,9 +528,9 @@ programma è identico, e tutto il lavoro viene effettuato attraverso la
 chiamata (\texttt{\small 28}) alla funzione \func{ClientEcho} che stavolta
 però prende un argomento in più, che è l'indirizzo del socket.
 
 chiamata (\texttt{\small 28}) alla funzione \func{ClientEcho} che stavolta
 però prende un argomento in più, che è l'indirizzo del socket.
 

-\begin{figure}[!htb] 
+\begin{figure}[!htbp] 

   \footnotesize \centering
   \footnotesize \centering

-  \begin{minipage}[c]{15.6cm}
+  \begin{minipage}[c]{\codesamplewidth}

     \includecodesample{listati/UDP_ClientEcho_first.c}
   \end{minipage}
   \normalsize
     \includecodesample{listati/UDP_ClientEcho_first.c}
   \end{minipage}
   \normalsize


@@ -677,7 +675,7 @@ più necessario usare l'argomento \param{to} di \func{sendto} per specificare
 la destinazione dei pacchetti, che potranno essere inviati e ricevuti usando
 le normali funzioni \func{read} e \func{write}.\footnote{in realtà si può
   anche continuare ad usare la funzione \func{sendto}, ma in tal caso
 la destinazione dei pacchetti, che potranno essere inviati e ricevuti usando
 le normali funzioni \func{read} e \func{write}.\footnote{in realtà si può
   anche continuare ad usare la funzione \func{sendto}, ma in tal caso

-  l'argomento \param{to} deve essere inizializzato a \const{NULL}, e
+  l'argomento \param{to} deve essere inizializzato a \val{NULL}, e

   \param{tolen} deve essere inizializzato a zero, pena un errore.}
 
 Una volta che il socket è connesso cambia però anche il comportamento in
   \param{tolen} deve essere inizializzato a zero, pena un errore.}
 
 Una volta che il socket è connesso cambia però anche il comportamento in


@@ -693,9 +691,9 @@ vengono riportati alle funzioni che operano su di esso; pertanto potremo
 riscrivere il nostro client per il servizio \textit{echo} con le modifiche
 illustrate in fig.~\ref{fig:UDP_echo_conn_cli}.
 
 riscrivere il nostro client per il servizio \textit{echo} con le modifiche
 illustrate in fig.~\ref{fig:UDP_echo_conn_cli}.
 

-\begin{figure}[!htb] 
+\begin{figure}[!htbp] 

   \footnotesize \centering
   \footnotesize \centering

-  \begin{minipage}[c]{15.6cm}
+  \begin{minipage}[c]{\codesamplewidth}

     \includecodesample{listati/UDP_echo.c}
   \end{minipage}
   \normalsize
     \includecodesample{listati/UDP_echo.c}
   \end{minipage}
   \normalsize


@@ -712,9 +710,9 @@ 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}.
 
 \func{write} come illustrato dal nuovo codice riportato in
 fig.~\ref{fig:UDP_echo_conn_echo_client}.
 

-\begin{figure}[!htb] 
+\begin{figure}[!htbp] 

   \footnotesize \centering
   \footnotesize \centering

-  \begin{minipage}[c]{15.6cm}
+  \begin{minipage}[c]{\codesamplewidth}

     \includecodesample{listati/UDP_ClientEcho.c}
   \end{minipage}
   \normalsize
     \includecodesample{listati/UDP_ClientEcho.c}
   \end{minipage}
   \normalsize