X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=othersock.tex;h=f04d9ae0b73b2b5474cc4705a8edbb28e73f2d94;hp=abf0f782533c07e85fb66bf14f74083688cf6052;hb=dcf2c2df897955ff3503a7c426025457ab456fd7;hpb=193d612d40c5f81f5559ea6e11e70f6b6e51fb39 diff --git a/othersock.tex b/othersock.tex index abf0f78..f04d9ae 100644 --- a/othersock.tex +++ b/othersock.tex @@ -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