Correzioni varie.
[gapil.git] / sockctrl.tex
index 585e3712e22092777a4b6d4420ef063be881524e..8abb56af36ffc510f5e164a8ae03dcf06364a08c 100644 (file)
@@ -2520,32 +2520,37 @@ si pu
 fare questa operazione per un socket TCP dato che su di essi si può sempre
 invocare \func{getsockname} una volta che si è completata la connessione.
 
-Infine il quarto caso è quello in cui si vuole effettivamente ottenere un
-\textit{completely duplicate binding}, quando cioè si vuole eseguire
-\func{bind} su un indirizzo ed una porta che sono già \textsl{legati} ad un
-altro socket.  Questo ovviamente non ha senso per il normale traffico di rete,
-in cui i pacchetti vengono scambiati direttamente fra due applicazioni; ma
-quando un sistema supporta il traffico in multicast, in cui una applicazione
-invia i pacchetti a molte altre (vedi sez.~\ref{sec:multicast_xxx}), allora ha
-senso che su una macchina i pacchetti provenienti dal traffico in multicast
-possano essere ricevuti da più applicazioni\footnote{l'esempio classico di
-  traffico in multicast è quello di uno streaming di dati (audio, video,
-  ecc.), l'uso del multicast consente in tal caso di trasmettere un solo
-  pacchetto, che potrà essere ricevuto da tutti i possibili destinatari
-  (invece di inviarne un duplicato a ciascuno); in questo caso è perfettamente
-  logico aspettarsi che sulla stessa macchina più utenti possano lanciare un
-  programma che permetta loro di ricevere gli stessi dati.} o da diverse
-istanze della stessa applicazione.
+Infine il quarto caso è quello in cui si vuole effettivamente ottenere
+un \textit{completely duplicate binding}, quando cioè si vuole
+eseguire \func{bind} su un indirizzo ed una porta che sono già
+\textsl{legati} ad un altro socket.  Questo ovviamente non ha senso
+per il normale traffico di rete, in cui i pacchetti vengono scambiati
+direttamente fra due applicazioni; ma quando un sistema supporta il
+traffico in \itindex{multicast}\textit{multicast}, in cui una
+applicazione invia i pacchetti a molte altre (vedi
+sez.~\ref{sec:multicast_xxx}), allora ha senso che su una macchina i
+pacchetti provenienti dal traffico in multicast possano essere
+ricevuti da più applicazioni\footnote{l'esempio classico di traffico
+  in multicast è quello di uno streaming di dati (audio, video, ecc.),
+  l'uso del multicast consente in tal caso di trasmettere un solo
+  pacchetto, che potrà essere ricevuto da tutti i possibili
+  destinatari (invece di inviarne un duplicato a ciascuno); in questo
+  caso è perfettamente logico aspettarsi che sulla stessa macchina più
+  utenti possano lanciare un programma che permetta loro di ricevere
+  gli stessi dati.} o da diverse istanze della stessa applicazione.
+\itindex{multicast}
 
 In questo caso utilizzando \const{SO\_REUSEADDR} si consente ad una
-applicazione eseguire \func{bind} sulla stessa porta ed indirizzo usata da
-un'altra, così che anche essa possa ricevere gli stessi pacchetti (chiaramente
-la cosa non ha alcun senso per i socket TCP, ed infatti in questo tipo di
-applicazione è normale l'uso del protovollo UDP). La regola è che quando si
-hanno più applicazioni che hanno eseguito \func{bind} sulla stessa porta, di
-tutti pacchetti destinati ad un indirizzo di broadcast o di multicast viene
-inviata una copia a ciascuna applicazione. Non è definito invece cosa accade
-qualora il pacchetto sia destinato ad un indirizzo normale (unicast).
+applicazione eseguire \func{bind} sulla stessa porta ed indirizzo
+usata da un'altra, così che anche essa possa ricevere gli stessi
+pacchetti (chiaramente la cosa non ha alcun senso per i socket TCP, ed
+infatti in questo tipo di applicazione è normale l'uso del protovollo
+UDP). La regola è che quando si hanno più applicazioni che hanno
+eseguito \func{bind} sulla stessa porta, di tutti pacchetti destinati
+ad un indirizzo di broadcast o di \itindex{multicast}
+\texttt{multicast} viene inviata una copia a ciascuna applicazione.
+Non è definito invece cosa accade qualora il pacchetto sia destinato
+ad un indirizzo normale (unicast).
 
 Essendo questo un caso particolare in alcuni sistemi (come BSD) è stata
 introdotta una opzione ulteriore, \const{SO\_REUSEPORT} che richiede che detta
@@ -2835,12 +2840,14 @@ ottenibile rispettivamente dai campi \var{ipi\_addr} e \var{ipi\_ifindex} di
   L'opzione richiede per \param{optval} un intero usato come valore logico;
   l'opzione non è applicabile a socket di tipo \const{SOCK\_STREAM}.
 
-\item[\const{IP\_MTU\_DISCOVER}] Questa è una opzione introdotta con i kernel
-  della serie 2.2.x, ed è specifica di Linux.  L'opzione permette di scrivere
-  o leggere le impostazioni usate nella determinazione della \textit{Maximum
-    Tranfer Unit} (vedi sez.~\ref{sec:net_lim_dim}) per il socket. Il valore
-  di default è determinato dal parametro \texttt{ip\_no\_pmtu\_disc} di
-  \func{sysctl}.
+\item[\const{IP\_MTU\_DISCOVER}] Questa è una opzione introdotta con i
+  kernel della serie 2.2.x, ed è specifica di Linux.  L'opzione
+  permette di scrivere o leggere le impostazioni usate nella
+  determinazione della \textit{Maximum Tranfer Unit} (vedi
+  sez.~\ref{sec:net_lim_dim}) per il socket. Il valore di default è
+  determinato dal parametro \texttt{ip\_no\_pmtu\_disc} di
+  \func{sysctl} per i socket di tipo \const{SOCK\_STREAM}, mentre è
+  diabilitato per tutti gli altri.
 
 \item[\const{IP\_MTU}] Permette di leggere il valore della \textit{Maximum
     Tranfer Unit} di percorso del socket.  L'opzione richiede per
@@ -2848,8 +2855,12 @@ ottenibile rispettivamente dai campi \var{ipi\_addr} e \var{ipi\_ifindex} di
   una opzione introdotta con i kernel della serie 2.2.x, ed è specifica di
   Linux.
 
-\item[\const{IP\_ROUTER\_ALERT}] Questa è una opzione introdotta con i kernel
-  della serie 2.2.x, ed è specifica di Linux.
+\item[\const{IP\_ROUTER\_ALERT}] Questa è una opzione introdotta con i
+  kernel della serie 2.2.x, ed è specifica di Linux. Prende per
+  \param{optval} un intero usato come valore logico. Se abilitata
+  passa tutti i pacchetti con l'opzione \textit{IP Router Alert} (vedi
+  sez.\ref{sec:IP_options}) che devono essere inoltrati al socket
+  corrente. Può essere usata soltanto per socket di tipo raw.
 
 \item[\const{IP\_MULTICAST\_TTL}] L'opzione permette di impostare o leggere il
   valore del campo TTL per i pacchetti in uscita associati al socket. È
@@ -2859,10 +2870,11 @@ ottenibile rispettivamente dai campi \var{ipi\_addr} e \var{ipi\_ifindex} di
   L'opzione richiede per \param{optval} un intero che conterrà il valore del
   TTL.
 
-\item[\const{IP\_MULTICAST\_LOOP}] L'opzione consente di decidere se i dati
-  che si inviano su un socket usato con il multicast vengano ricevuti anche
-  sulla stessa macchina da cui li si stanno inviando.  Prende per
-  \param{optval} un intero usato come valore logico. 
+\item[\const{IP\_MULTICAST\_LOOP}] L'opzione consente di decidere se i
+  dati che si inviano su un socket usato con il \itindex{multicast}
+  \texttt{multicast} vengano ricevuti anche sulla stessa macchina da
+  cui li si stanno inviando.  Prende per \param{optval} un intero
+  usato come valore logico.
 
   In generale se si vuole che eventuali client possano ricevere i dati che si
   inviano occorre che questa funzionalità sia abilitata (come avviene di
@@ -2870,15 +2882,17 @@ ottenibile rispettivamente dai campi \var{ipi\_addr} e \var{ipi\_ifindex} di
   disponibili in locale l'uso di questa opzione permette di disabilitare
   questo tipo di traffico.
 
-\item[\const{IP\_ADD\_MEMBERSHIP}] L'opzione consente di unirsi ad gruppo di
-  multicast, e può essere usata solo con \func{setsockopt}. L'argomento
-  \param{optval} in questo caso deve essere una struttura di tipo
-  \struct{ip\_mreqn}, illustrata in fig.~\ref{fig:ip_mreqn_struct}, che
-  permette di indicare, con il campo \var{imr\_multiaddr} l'indirizzo del
-  gruppo di multicast a cui ci si vuole unire, con il campo \var{imr\_address}
-  l'indirizzo dell'interfaccia locale con cui unirsi al gruppo di multicast e
-  con \var{imr\_ifindex} l'indice dell'interfaccia da utilizzare (un valore
-  nullo indica una interfaccia qualunque).  
+\item[\const{IP\_ADD\_MEMBERSHIP}] L'opzione consente di unirsi ad
+  gruppo di \itindex{multicast} \texttt{multicast}, e può essere usata
+  solo con \func{setsockopt}. L'argomento \param{optval} in questo
+  caso deve essere una struttura di tipo \struct{ip\_mreqn},
+  illustrata in fig.~\ref{fig:ip_mreqn_struct}, che permette di
+  indicare, con il campo \var{imr\_multiaddr} l'indirizzo del gruppo
+  di multicast a cui ci si vuole unire, con il campo
+  \var{imr\_address} l'indirizzo dell'interfaccia locale con cui
+  unirsi al gruppo di multicast e con \var{imr\_ifindex} l'indice
+  dell'interfaccia da utilizzare (un valore nullo indica una
+  interfaccia qualunque).
 
   Per compatibilità è possibile utilizzare anche un argomento di tipo
   \struct{ip\_mreq}, una precedente versione di \struct{ip\_mreqn}, che
@@ -2895,11 +2909,15 @@ ottenibile rispettivamente dai campi \var{ipi\_addr} e \var{ipi\_ifindex} di
 \end{figure}
 
 
+\item[\const{IP\_DROP\_MEMBERSHIP}] Lascia un gruppo di
+  \itindex{multicast} \texttt{multicast}, prende per \param{optval} la
+  stessa struttura \struct{ip\_mreqn} (o \struct{ip\_mreq}) usata
+  anche per \const{IP\_ADD\_MEMBERSHIP}.
 
-
-\item[\const{IP\_DROP\_MEMBERSHIP}]
-
-\item[\const{IP\_MULTICAST\_IF}] 
+\item[\const{IP\_MULTICAST\_IF}] Imposta l'interfaccia locale per
+  i'utilizzo del multicast, ed utilizza come \param{optval} le stesse
+  strutture \struct{ip\_mreqn} o \struct{ip\_mreq} delle due
+  precedenti opzioni.
 
 
 \end{basedescript}