projects / gapil.git / blobdiff
? search:
summary | shortlog | log | commit | commitdiff | tree
raw | inline | side by side
Materuale vario, correzioni e aggiornamenti sulla code di messaggi
[gapil.git] / othersock.tex
diff --git a/othersock.tex b/othersock.tex
index 1509ff2c86e5ef3bbce53cf741661652c151ee08..3cc81f22a69d72fa2c80293fbde8880b4f9ccae1 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-2014 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",
@@ -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}.
 
 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}
   \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}
 
 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}.
@@ -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
   \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},
@@ -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
 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ò
 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)}
   
   \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
@@ -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.
 
 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 +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. 
 
 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 +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}. 
 
 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 +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.
 
 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
@@ -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}.
 
 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 +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}.
 
 \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
GaPiL: Guida alla Programmazione in Linux