X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=othersock.tex;h=9ffb653055bd8489538494dc8e588405d0ca2ff8;hp=4be71fbca6a76f114757960092ab1f7420398234;hb=ff76d56c6a2c280cbe4f153173488871d7b12336;hpb=bf81ce9ec539254693a8c41641a99af1aa1d886f diff --git a/othersock.tex b/othersock.tex index 4be71fb..9ffb653 100644 --- a/othersock.tex +++ b/othersock.tex @@ -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} + 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} @@ -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 @@ -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