Aggiornamenti del copyright all'anno nuovo, e risistemazione delle

[gapil.git] / othersock.tex

diff --git a/othersock.tex b/othersock.tex
index 856c4f6d5cf2ae0d79676d418db0125689e9ba64..9ffb653055bd8489538494dc8e588405d0ca2ff8 100644 (file)
--- a/othersock.tex
+++ b/othersock.tex
@@ -1,6 +1,6 @@
 %% othersock.tex
 %%
 %% 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",
 %% 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".
 %%
 %% license is included in the section entitled "GNU Free Documentation
 %% License".
 %%

+

 \chapter{Gli altri tipi di socket}
 \label{cha:other_socket}
 
 \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}.
 
 
 \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
 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
 
 \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
 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
   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}
+  e nelle \acr{libc5}.} è:

 \begin{functions}
   \headdecl{sys/types.h}
   \headdecl{sys/socket.h}
 \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
 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.
 
 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
 \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};
   \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}
   \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
 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
 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
 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.
 
 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
 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}.
 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
 \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.
 
 
 
 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
 \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
 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: 
 %%% 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