Note

[gapil.git] / othersock.tex

diff --git a/othersock.tex b/othersock.tex
index 6d73bee8d3e3b1d4ac4bc89e159f3027e721d62d..de8c3d19cfe452736fb1e04fff7c22fbfb0d2293 100644 (file)
--- a/othersock.tex
+++ b/othersock.tex
@@ -1,6 +1,6 @@
 %% othersock.tex
 %%
 %% othersock.tex
 %%

-%% Copyright (C) 2004-2015 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",
 %% 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",


@@ -55,11 +55,10 @@ utilizzando per il tipo di socket il valore \const{SOCK\_DGRAM}.
 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
 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}  
 
 \begin{figure}[!htb]
   \centering \includegraphics[width=10cm]{img/udp_connection}  


@@ -129,13 +128,13 @@ dati attraverso qualunque tipo di socket. Esse hanno la caratteristica 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
 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
   \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
   \textit{Single Unix Specification}, l'argomento \param{flags} era di tipo
   \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 nelle \acr{libc4}, ma \type{size\_t} nelle \acr{libc5};
-  infine l'argomento \param{tolen} era \ctyp{int} nei vari BSD4.* nelle
-  \acr{libc4} e nelle \acr{libc5}.} è:
+  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}
 \begin{functions}
   \headdecl{sys/types.h}
   \headdecl{sys/socket.h}


@@ -210,20 +209,20 @@ 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 \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
 
 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
+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};
   \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} è \ctyp{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}
 \begin{functions}
   \headdecl{sys/types.h}
   \headdecl{sys/socket.h}


@@ -738,8 +737,8 @@ con UDP non esiste una connessione, e fintanto che non si invia un pacchetto
 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,
 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
 
 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