Correzioni multiple agli indici delle funzioni, inserita macro per
[gapil.git] / othersock.tex
index abf0f782533c07e85fb66bf14f74083688cf6052..f04d9ae0b73b2b5474cc4705a8edbb28e73f2d94 100644 (file)
@@ -1,6 +1,6 @@
 %% othersock.tex
 %%
-%% Copyright (C) 2004-2011 Simone Piccardi.  Permission is granted to
+%% Copyright (C) 2004-2012 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",
@@ -61,9 +61,8 @@ 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}  
+\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}
@@ -71,8 +70,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}
-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}.
@@ -168,7 +167,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
-    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},
@@ -203,7 +202,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
-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}.
@@ -211,7 +210,7 @@ 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
-\const{MSG\_NOSIGNAL} che impedisce l'invio del segnale \const{SIGPIPE} quando
+\const{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ò
@@ -232,7 +231,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)}
   
-  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
@@ -280,7 +279,7 @@ 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}.
+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
@@ -307,9 +306,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.
 
-\begin{figure}[!htb] 
+\begin{figure}[!htbp
   \footnotesize \centering
-  \begin{minipage}[c]{15.6cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/UDP_daytime.c}
   \end{minipage} 
   \normalsize
@@ -407,9 +406,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. 
 
-\begin{figure}[!htb] 
+\begin{figure}[!htbp
   \footnotesize \centering
-  \begin{minipage}[c]{15.6cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/UDP_daytimed.c}
   \end{minipage} 
   \normalsize
@@ -509,9 +508,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}. 
 
-\begin{figure}[!htb] 
+\begin{figure}[!htbp
   \footnotesize \centering
-  \begin{minipage}[c]{15.6cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/UDP_echo_first.c}
   \end{minipage} 
   \normalsize
@@ -530,9 +529,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.
 
-\begin{figure}[!htb] 
+\begin{figure}[!htbp
   \footnotesize \centering
-  \begin{minipage}[c]{15.6cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/UDP_ClientEcho_first.c}
   \end{minipage}
   \normalsize
@@ -677,7 +676,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
-  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
@@ -693,9 +692,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}.
 
-\begin{figure}[!htb] 
+\begin{figure}[!htbp
   \footnotesize \centering
-  \begin{minipage}[c]{15.6cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/UDP_echo.c}
   \end{minipage}
   \normalsize
@@ -712,9 +711,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}.
 
-\begin{figure}[!htb] 
+\begin{figure}[!htbp
   \footnotesize \centering
-  \begin{minipage}[c]{15.6cm}
+  \begin{minipage}[c]{\codesamplewidth}
     \includecodesample{listati/UDP_ClientEcho.c}
   \end{minipage}
   \normalsize