%% othersock.tex
%%
-%% Copyright (C) 2004-2011 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2004-2018 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",
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}
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}.
\label{sec:UDP_sendto_recvfrom}
Come accennato in sez.~\ref{sec:UDP_characteristics} le due funzioni
-principali usate per la trasmissione di dati attraverso i socket UDP sono
-\func{sendto} e \func{recvfrom}. La necessità di usare queste funzioni è
-dovuta al fatto che non esistendo con UDP il concetto di connessione, non si
-ha neanche a disposizione un \textsl{socket connesso} su cui sia possibile
-usare direttamente \func{read} e \func{write} avendo già stabilito (grazie
-alla chiamata ad \func{accept} che lo associa ad una connessione) quali sono
-sorgente e destinazione dei dati.
+principali usate per la trasmissione di dati attraverso i socket UDP (ed in
+generale per i socket di tipo \textit{datagram}) sono \func{sendto} e
+\func{recvfrom}. La necessità di usare queste funzioni è dovuta al fatto che
+non esistendo con UDP il concetto di connessione, non si può stabilire (come
+avviene con i socket TCP grazie alla chiamata ad \func{accept} che li associa
+ad una connessione) quali sono la sorgente e la destinazione dei dati che
+passano sul socket.\footnote{anche se in alcuni casi, come quello di un client
+ che contatta un server, è possibile connettere il socket (vedi
+ sez.~\ref{sec:UDP_connect}), la necessità di \func{sendto} e \func{recvfrom}
+ resta, dato che questo è possibile solo sul lato del client.}
+
+Per questo anche se in generale si possono comunque leggere i dati con
+\func{read}, usando questa funzione non si sarà in grado di determinare da
+quale fra i possibili corrispondenti (se ve ne sono più di uno, come avviene
+sul lato del server) questi arrivino. E non sarà comunque possibile usare
+\func{write} (che fallisce un errore di \errval{EDESTADDRREQ}) in quanto non
+è determinato la destinazione che i dati avrebbero.
Per questo motivo nel caso di UDP diventa essenziale utilizzare queste due
funzioni, che sono comunque utilizzabili in generale per la trasmissione di
prevedere tre argomenti aggiuntivi attraverso i quali è possibile specificare
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
+ prototipo illustrato è quello utilizzato dalla \acr{glibc}, che segue 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 nella \acr{libc4}, ma \type{size\_t} nella \acr{libc5}; infine
+ l'argomento \param{tolen} era \ctyp{int} nei vari BSD4.*, nella \acr{libc4} e
+ nella \acr{libc5}.} è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/socket.h}
\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},
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}.
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
- \acr{libc5} usano un \texttt{int} come valore di ritorno; per gli argomenti
+suo prototipo\footnote{il prototipo è quello della \acr{glibc} che segue le
+ \textit{Single Unix Specification}, i vari BSD4.*, le \acr{libc4} e la
+ \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};
- infine l'argomento \param{fromlen} è \texttt{int} per i vari BSD4.*, le
- \acr{libc4} e le \acr{libc5}.} è:
+ infine l'argomento \param{fromlen} è \ctyp{int} per i vari BSD4.*, la
+ \acr{libc4} e la \acr{libc5}.} è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/socket.h}
\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
\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
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
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
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
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
qualunque cosa si scriva sul socket sarà inviata a quell'indirizzo; non sarà
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
- \param{tolen} deve essere inizializzato a zero, pena un errore.}
+le normali funzioni \func{read} e \func{write} che a questo punto non
+falliranno più con l'errore di \errval{EDESTADDRREQ}.\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 \val{NULL}, e
+ \param{tolen} deve essere inizializzato a zero, pena un errore di
+ \errval{EISCONN}.}
Una volta che il socket è connesso cambia però anche il comportamento in
ricezione; prima infatti il kernel avrebbe restituito al socket qualunque
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
\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
non c'è traffico sulla rete. In questo caso l'errore sarà rilevato alla
ricezione del pacchetto ICMP \textit{destination unreachable} emesso dalla
macchina cui ci si è rivolti, e questa volta, essendo il socket UDP connesso,
-il kernel potrà riportare detto errore in user space in maniera non ambigua,
-ed esso apparirà alla successiva lettura sul socket.
+il kernel potrà riportare detto errore in \textit{user space} in maniera non
+ambigua, ed esso apparirà alla successiva lettura sul socket.
Si tenga presente infine che l'uso dei socket connessi non risolve l'altro
problema del client, e cioè il fatto che in caso di perdita di un pacchetto
projects / gapil.git / blobdiff