%% othersock.tex
%%
-%% Copyright (C) 2004-2014 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}.
+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}
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}
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 \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.
+\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}
\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 \val{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