X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=othersock.tex;h=6ebdcb86475ab0c4447fecac79a23c2c255b84dd;hp=648dc61be2799e0a7f228873751c7e40e5c92cdc;hb=33a54e1bfa5e62cb90d84c2d5f2d0c53864f6bec;hpb=2354bea32f841874996df139e72aab07b29ba12e diff --git a/othersock.tex b/othersock.tex index 648dc61..6ebdcb8 100644 --- a/othersock.tex +++ b/othersock.tex @@ -1,19 +1,20 @@ %% othersock.tex %% -%% Copyright (C) 2004 Simone Piccardi. Permission is granted to +%% Copyright (C) 2004-2011 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 "Prefazione", +%% Free Software Foundation; with the Invariant Sections being "Un preambolo", %% with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the %% 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} + e 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} @@ -262,11 +264,22 @@ comunque il numero di byte letti. I due argomenti \param{from} e \param{fromlen} sono utilizzati per ottenere l'indirizzo del mittente del pacchetto che è stato ricevuto, e devono essere -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 +opportunamente inizializzati; il primo deve contenere il puntatore alla +struttura (di tipo \ctyp{sockaddr}) che conterrà l'indirizzo e il secondo il +puntatore alla variabile con la dimensione di detta struttura. Si tenga +presente che mentre il contenuto della struttura \ctyp{sockaddr} cui punta +\param{from} può essere qualunque, la variabile puntata da \param{fromlen} +deve essere opportunamente inizializzata a \code{sizeof(sockaddr)}, +assicurandosi che la dimensione sia sufficiente a contenere tutti i dati +dell'indirizzo.\footnote{si ricordi che \ctyp{sockaddr} è un tipo generico che + serve ad indicare la struttura corrispondente allo specifico tipo di + indirizzo richiesto, il valore di \param{fromlen} pone un limite alla + quantità di dati che verranno scritti sulla struttura puntata da + \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 \const{NULL}. Una differenza fondamentale del comportamento di queste funzioni rispetto alle @@ -322,9 +335,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 +707,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,26 +750,70 @@ 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} + + +% articoli interessanti: +% http://www.linuxjournal.com/article/5617 +% http://www.linuxjournal.com/article/4659 +% + +% 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 packet