Aggiornamenti del copyright all'anno nuovo, e risistemazione delle
[gapil.git] / othersock.tex
index 856c4f6d5cf2ae0d79676d418db0125689e9ba64..9ffb653055bd8489538494dc8e588405d0ca2ff8 100644 (file)
@@ -1,6 +1,6 @@
 %% othersock.tex
 %%
-%% Copyright (C) 2004-2005 Simone Piccardi.  Permission is granted to
+%% Copyright (C) 2004-2007 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",
@@ -8,12 +8,13 @@
 %% license is included in the section entitled "GNU Free Documentation
 %% License".
 %%
+
 \chapter{Gli altri tipi di socket}
 \label{cha:other_socket}
 
-Dopo aver trattato in cap.~\ref{cha:TCP_socket} i socket TCP, che costituiscono
-l'esempio più comune dell'interfaccia dei socket, esamineremo in questo
-capitolo gli altri tipi di socket, a partire dai socket UDP, e i socket
+Dopo aver trattato in cap.~\ref{cha:TCP_socket} i socket TCP, che
+costituiscono l'esempio più comune dell'interfaccia dei socket, esamineremo in
+questo capitolo gli altri tipi di socket, a partire dai socket UDP, e i socket
 \textit{Unix domain} già incontrati in sez.~\ref{sec:ipc_socketpair}.
 
 
@@ -54,10 +55,11 @@ 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
-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}.
+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
@@ -130,11 +132,11 @@ 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
   \textit{Single Unix Specification}, l'argomento \param{flags} era di tipo
-  \type{int} nei vari BSD4.*, mentre nelle \acr{libc4} e \acr{libc5} veniva
-  usato un \type{unsigned int}; l'argomento \param{len} era \type{int} nei
+  \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 \type{int} nei vari BSD4.* nelle \acr{libc4} e
-  nelle \acr{libc5}.} è:
+  l'argomento \param{tolen} era \texttt{int} nei vari BSD4.* nelle \acr{libc4}
+  nelle \acr{libc5}.} è:
 \begin{functions}
   \headdecl{sys/types.h}
   \headdecl{sys/socket.h}
@@ -211,7 +213,7 @@ come maschera binaria che permette di impostare una serie di modalit
 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:xxx_sendmsg},
+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.
 
@@ -219,9 +221,9 @@ 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 \type{int} come valore di ritorno; per gli argomenti
+  \acr{libc5} usano un \texttt{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} è \type{int} per i vari BSD4.*, le
+  infine l'argomento \param{fromlen} è \texttt{int} per i vari BSD4.*, le
   \acr{libc4} e le \acr{libc5}.} è:
 \begin{functions}
   \headdecl{sys/types.h}
@@ -265,8 +267,8 @@ l'indirizzo del mittente del pacchetto che 
 opportunamente inizializzati con i puntatori alle variabili dove la struttura
 contenente quest'ultimo e la relativa lunghezza saranno scritti (si noti che
 \param{fromlen} è un valore intero ottenuto come
-\index{\textit{value~result~argument}}\textit{value result argument}).  Se non
-si è interessati a questa informazione, entrambi gli argomenti devono essere
+\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}.
 
 Una differenza fondamentale del comportamento di queste funzioni rispetto alle
@@ -322,9 +324,9 @@ Il passo successivo (\texttt{\small 13--21}) 
 struttura degli indirizzi; prima (\texttt{\small 14}) si cancella
 completamente la stessa con \func{memset}, (\texttt{\small 15}) poi si imposta
 la famiglia dell'indirizzo ed infine (\texttt{\small 16} la porta. Infine
-(\texttt{\small 18--21}) si ricava l'indirizzo del server da contattare dal
-parametro passato a riga di comando, convertendolo con \func{inet\_pton}. Si
-noti come questa sezione sia identica a quella del client TCP di
+(\texttt{\small 18--21}) si ricava l'indirizzo del server da contattare
+dall'argomento passato a riga di comando, convertendolo con \func{inet\_pton}.
+Si noti come questa sezione sia identica a quella del client TCP di
 fig.~\ref{fig:TCP_daytime_client_code}, in quanto la determinazione dell'uso
 di UDP al posto di TCP è stata effettuata quando si è creato il socket.
 
@@ -694,7 +696,7 @@ illustrate in fig.~\ref{fig:UDP_echo_conn_cli}.
 Ed in questo caso rispetto alla precedente versione, il solo cambiamento è
 l'utilizzo (\texttt{\small 17}) della funzione \func{connect} prima della
 chiamata alla funzione di gestione del protocollo, che a sua volta è stata
-modificata eliminando l'indirizzo passato come parametro e sostituendo le
+modificata eliminando l'indirizzo passato come argomento e sostituendo le
 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}.
@@ -737,25 +739,51 @@ risolvere questo problema l'unico modo sarebbe quello di impostare un
 
 
 
+\index{socket!locali|(}
+
+
 \section{I socket \textit{Unix domain}}
 \label{sec:unix_socket}
 
 Benché i socket Unix domain, come meccanismo di comunicazione fra processi che
 girano sulla stessa macchina, non siano strettamente attinenti alla rete, li
-tratteremo comunque in questa sezione. Nonstante le loro peculiarità infatti,
+tratteremo comunque in questa sezione. Nonostante le loro peculiarità infatti,
 l'interfaccia di programmazione che serve ad utilizzarli resta sempre quella
 dei socket.
 
 
 
+\subsection{Il passaggio di file descriptor}
+\label{sec:sock_fd_passing}
+
+
+
+\index{socket!locali|)}
+
+
 \section{Altri socket}
 \label{sec:socket_other}
 
 Tratteremo in questa sezione gli altri tipi particolari di socket supportati
-da Linux, come i \textit{raw socket}, con i quali si possono \textsl{forgiare}
-direttamente i pacchetti a tutti i livelli dello stack dei protocolli, o i
+da Linux, come quelli relativi a particolare protocolli di trasmissione, i
 socket \textit{netlink} che definiscono una interfaccia di comunicazione con
-il kernel.
+il kernel, ed i \textit{packet socket} che consentono di inviare pacchetti
+direttamente a livello delle interfacce di rete. 
+
+\subsection{I socket \textit{raw}}
+\label{sec:socket_raw}
+
+Tratteremo in questa sezione i cosiddetti \textit{raw socket}, con i quali si
+possono \textsl{forgiare} direttamente i pacchetti a tutti i livelli dello
+stack dei protocolli. 
+
+\subsection{I socket \textit{netlink}}
+\label{sec:socket_netlink}
+
+
+\subsection{I \textit{packet socket}}
+\label{sec:packet_socket}
+
 
 
 
@@ -764,3 +792,16 @@ il kernel.
 %%% mode: latex
 %%% TeX-master: "gapil"
 %%% End: 
+
+% LocalWords:  socket cap TCP UDP domain sez NFS DNS stream datagram PF INET to
+% LocalWords:  IPv tab SOCK DGRAM three way handshake client fig bind listen AF
+% LocalWords:  accept recvfrom sendto connect netstat named DHCP kernel ICMP CR
+% LocalWords:  port unreachable read write glibc Specification flags int BSD LF
+% LocalWords:  libc unsigned len size tolen sys ssize sockfd const void buf MSG
+% LocalWords:  struct sockaddr socklen errno EAGAIN ECONNRESET EDESTADDRREQ RFC
+% LocalWords:  EISCONN EMSGSIZE ENOBUFS ENOTCONN EOPNOTSUPP EPIPE SIGPIPE EBADF
+% LocalWords:  NOSIGNAL EFAULT EINVAL EINTR ENOMEM ENOTSOCK NULL fromlen from
+% LocalWords:  ECONNREFUSED value result argument close shutdown daytime nell'
+% LocalWords:  memset inet pton nread NUL superdemone inetd sniffer daytimed
+% LocalWords:  INADDR ANY addr echo ClientEcho sendbuff serv VPN tcpdump l'I
+% LocalWords:  Stevens destination descriptor raw stack netlink