%% socket.tex
%%
-%% Copyright (C) 2000-2016 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2018 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",
\index{socket!definizione|(}
-\subsection{Cosa sono \textit{socket}}
+\subsection{Cosa sono i \textit{socket}}
\label{sec:sock_socket_def}
I \textit{socket} (una traduzione letterale potrebbe essere \textsl{presa}, ma
associato ad una costante, che inizia invece per \texttt{AF\_} (da
\textit{address family}) che identifica il formato degli indirizzi usati in
quel dominio. Le pagine di manuale di Linux si riferiscono a questi indirizzi
-anche come \textit{name space}, (nome che invece il manuale delle \acr{glibc}
+anche come \textit{name space}, (nome che invece il manuale della \acr{glibc}
riserva a quello che noi abbiamo chiamato domini) dato che identificano il
formato degli indirizzi usati in quel dominio per identificare i capi della
comunicazione.
-\begin{table}[htb]
+\begin{table}[!htb]
\footnotesize
\centering
\begin{tabular}[c]{|l|l|l|l|}
\textbf{Nome}&\textbf{Valore}&\textbf{Utilizzo}&\textbf{Man page} \\
\hline
\hline
- \constd{PF\_UNSPEC} & 0& Non specificato & \\
- \constd{PF\_LOCAL} & 1& Local communication & unix(7) \\
- \constd{PF\_UNIX}, \constd{PF\_FILE}&1&Sinonimi di \const{PF\_LOCAL}& \\
- \constd{PF\_INET} & 2& IPv4 Internet protocols & ip(7) \\
- \constd{PF\_AX25} & 3& Amateur radio AX.25 protocol & \\
- \constd{PF\_IPX} & 4& IPX - Novell protocols & \\
- \constd{PF\_APPLETALK}& 5& Appletalk & ddp(7) \\
- \constd{PF\_NETROM} & 6& Amateur radio NetROM & \\
- \constd{PF\_BRIDGE} & 7& Multiprotocol bridge & \\
- \constd{PF\_ATMPVC} & 8& Access to raw ATM PVCs & \\
- \constd{PF\_X25} & 9& ITU-T X.25 / ISO-8208 protocol& x25(7) \\
- \constd{PF\_INET6} &10& IPv6 Internet protocols & ipv6(7) \\
- \constd{PF\_ROSE} &11& Amateur Radio X.25 PLP & \\
- \constd{PF\_DECnet} &12& Reserved for DECnet project & \\
- \constd{PF\_NETBEUI} &13& Reserved for 802.2LLC project & \\
- \constd{PF\_SECURITY} &14& Security callback pseudo AF & \\
- \constd{PF\_KEY} &15& PF\_KEY key management API & \\
- \constd{PF\_NETLINK} &16& Kernel user interface device & netlink(7) \\
- \constd{PF\_ROUTE} &16& Sinonimo di \const{PF\_NETLINK} emula BSD.&\\
- \constd{PF\_PACKET} &17& Low level packet interface & packet(7) \\
- \constd{PF\_ASH} &18& Ash & \\
- \constd{PF\_ECONET} &19& Acorn Econet & \\
- \constd{PF\_ATMSVC} &20& ATM SVCs & \\
- \constd{PF\_SNA} &22& Linux SNA Project & \\
- \constd{PF\_IRDA} &23& IRDA socket (infrarossi) & \\
- \constd{PF\_PPPOX} &24& PPPoX socket & \\
- \constd{PF\_WANPIPE} &25& Wanpipe API socket & \\
- \constd{PF\_LLC} &26& Linux LLC & \\
- \constd{PF\_CAN} &29& Controller Are Network & \\
- \constd{PF\_BLUETOOTH}&31& Bluetooth socket & \\
+ \constd{AF\_UNSPEC} & 0& Non specificato & \\
+ \constd{AF\_LOCAL} & 1& Local communication & unix(7) \\
+ \constd{AF\_UNIX}, \constd{AF\_FILE}&1&Sinonimi di \const{AF\_LOCAL}& \\
+ \constd{AF\_INET} & 2& IPv4 Internet protocols & ip(7) \\
+ \constd{AF\_AX25} & 3& Amateur radio AX.25 protocol & \\
+ \constd{AF\_IPX} & 4& IPX - Novell protocols & \\
+ \constd{AF\_APPLETALK}& 5& Appletalk & ddp(7) \\
+ \constd{AF\_NETROM} & 6& Amateur radio NetROM & \\
+ \constd{AF\_BRIDGE} & 7& Multiprotocol bridge & \\
+ \constd{AF\_ATMPVC} & 8& Access to raw ATM PVCs & \\
+ \constd{AF\_X25} & 9& ITU-T X.25 / ISO-8208 protocol& x25(7) \\
+ \constd{AF\_INET6} &10& IPv6 Internet protocols & ipv6(7) \\
+ \constd{AF\_ROSE} &11& Amateur Radio X.25 PLP & \\
+ \constd{AF\_DECnet} &12& Reserved for DECnet project & \\
+ \constd{AF\_NETBEUI} &13& Reserved for 802.2LLC project & \\
+ \constd{AF\_SECURITY} &14& Security callback pseudo AF & \\
+ \constd{AF\_KEY} &15& AF\_KEY key management API & \\
+ \constd{AF\_NETLINK} &16& Kernel user interface device & netlink(7) \\
+ \constd{AF\_ROUTE} &16& Sinonimo di \const{AF\_NETLINK} emula BSD.&\\
+ \constd{AF\_PACKET} &17& Low level packet interface & packet(7) \\
+ \constd{AF\_ASH} &18& Ash & \\
+ \constd{AF\_ECONET} &19& Acorn Econet & \\
+ \constd{AF\_ATMSVC} &20& ATM SVCs & \\
+ \constd{AF\_RDS} &21& RDS Sockets & \\
+ \constd{AF\_SNA} &22& Linux SNA Project & \\
+ \constd{AF\_IRDA} &23& IRDA socket (infrarossi) & irda(7) \\
+ \constd{AF\_PPPOX} &24& PPPoX socket & \\
+ \constd{AF\_WANPIPE} &25& Wanpipe API socket & \\
+ \constd{AF\_LLC} &26& Linux LLC & \\
+ \constd{AF\_IB} &27& Native InfiniBand address & \\
+ \constd{AF\_MPLS} &28& MPSL & \\
+ \constd{AF\_CAN} &29& Controller Are Network & \\
+ \constd{AF\_TIPC} &30& TIPC sockets & \\
+ \constd{AF\_BLUETOOTH}&31& Bluetooth socket & \\
+ \constd{AF\_IUCV} &32& IUCV sockets & \\
+ \constd{AF\_RXRPC} &33& RxRPC sockets & \\
+ \constd{AF\_ISDN} &34& mISDN sockets & \\
+ \constd{AF\_PHONET} &35& Phonet sockets & \\
+ \constd{AF\_IEEE802154}&36& IEEE802154 sockets & \\
+ \constd{AF\_CAIF} &37& CAIF sockets & \\
+ \constd{AF\_ALG} &38& Algorithm sockets & \\
+ \constd{AF\_NFC} &39& NFC sockets & \\
+ \constd{AF\_VSOCK} &40& vSockets & \\
+ \constd{AF\_KCM} &41& Kernel Connection Multiplexor & \\
+ \constd{AF\_QIPCRTR} &42& Qualcomm IPC Router & \\
+ \constd{AF\_SMC} &43& smc sockets & \\
\hline
\end{tabular}
\caption{Famiglie di protocolli definiti in Linux.}
\label{tab:net_pf_names}
\end{table}
-% TODO aggiungere PF_CAN, vedi http://lwn.net/Articles/253425, dal 2.6.25
-
L'idea alla base della distinzione fra questi due insiemi di costanti era che
una famiglia di protocolli potesse supportare vari tipi di indirizzi, per cui
il prefisso \texttt{PF\_} si sarebbe dovuto usare nella creazione dei socket e
I domini (e i relativi nomi simbolici), così come i nomi delle famiglie di
indirizzi, sono definiti dall'\textit{header file} \headfiled{socket.h}. Un
-elenco delle famiglie di protocolli disponibili in Linux è riportato in
-tab.~\ref{tab:net_pf_names}. L'elenco indica tutti i protocolli definiti; fra
-questi però saranno utilizzabili solo quelli per i quali si è compilato il
-supporto nel kernel (o si sono caricati gli opportuni moduli), viene definita
-anche una costante \constd{PF\_MAX} che indica il valore massimo associabile
-ad un dominio.
+elenco, aggiornato alla versione 4.15, delle famiglie di protocolli
+disponibili in Linux è riportato in tab.~\ref{tab:net_pf_names}. L'elenco
+indica tutti i protocolli definiti; fra questi però saranno utilizzabili solo
+quelli per i quali si è compilato il supporto nel kernel (o si sono caricati
+gli opportuni moduli), viene definita anche una costante \constd{AF\_MAX} che
+indica il valore massimo associabile ad un dominio.
Si tenga presente che non tutte le famiglie di protocolli sono utilizzabili
dall'utente generico, ad esempio in generale tutti i socket di tipo
tre tipi, Linux supporta anche gli altri, come si può verificare nel file
\texttt{include/linux/net.h} dei sorgenti del kernel.}
-\begin{basedescript}{\desclabelwidth{1.5cm}\desclabelstyle{\nextlinelabel}}
+\begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}}
\item[\constd{SOCK\_STREAM}] Provvede un canale di trasmissione dati
bidirezionale, sequenziale e affidabile. Opera su una connessione con un
altro socket. I dati vengono ricevuti e trasmessi come un flusso continuo di
non strettamente attinenti all'indicazione del tipo secondo i valori appena
illustrati. Essi infatti possono essere combinati con un OR aritmetico delle
ulteriori costanti:
-\begin{basedescript}{\desclabelwidth{1.5cm}\desclabelstyle{\nextlinelabel}}
+\begin{basedescript}{\desclabelwidth{2.5cm}\desclabelstyle{\nextlinelabel}}
\item[\constd{SOCK\_CLOEXEC}] imposta il flag di \textit{close-on-exec} sul
file descriptor del socket, ottenendo lo stesso effetto del flag
\const{O\_CLOEXEC} di \func{open} (vedi tab.~\ref{tab:open_operation_flag}),
tab.~\ref{tab:open_operation_flag}).
\end{basedescript}
-
Si tenga presente inoltre che non tutte le combinazioni fra una famiglia di
protocolli e un tipo di socket sono valide, in quanto non è detto che in una
famiglia esista un protocollo per ciascuno dei diversi stili di comunicazione
&\const{SOCK\_STREAM} &\const{SOCK\_DGRAM} &\const{SOCK\_RAW}&
\const{SOCK\_RDM}&\const{SOCK\_SEQPACKET} \\
\hline
- \const{PF\_UNIX} & si & si & -- & -- & si\footnotemark \\
+ \const{AF\_UNIX} & si & si & -- & -- & si\footnotemark \\
+ \hline
+ \const{AF\_LOCAL}&\multicolumn{5}{|c|}{sinonimo di \const{AF\_UNIX}}\\
+ \hline
+ \const{AF\_INET} & TCP & UDP & IPv4 & -- & -- \\
+ \hline
+ \const{AF\_INET6} & TCP & UDP & IPv6 & -- & -- \\
+ \hline
+ \const{AF\_IPX} & -- & si & -- & -- & -- \\
\hline
- \const{PF\_LOCAL}&\multicolumn{5}{|c|}{sinonimo di \const{PF\_UNIX}}\\
+ \const{AF\_NETLINK} & -- & si & si & -- & -- \\
\hline
- \const{PF\_INET} & TCP & UDP & IPv4 & -- & -- \\
+ \const{AF\_X25} & -- & -- & -- & -- & si \\
\hline
- \const{PF\_INET6} & TCP & UDP & IPv6 & -- & -- \\
+ \const{AF\_AX25} & -- & si & si & -- & si \\
\hline
- \const{PF\_IPX} & -- & -- & -- & -- & -- \\
+% \const{AF\_ATMPVC} & -- & -- & -- & -- & -- \\
+% \hline
+ \const{AF\_APPLETALK} & -- & si & si & -- & -- \\
\hline
- \const{PF\_NETLINK} & -- & si & si & -- & -- \\
+ \const{AF\_PACKET} & -- & si & si & -- & -- \\
\hline
- \const{PF\_X25} & -- & -- & -- & -- & si \\
+ \const{AF\_KEY} & -- & -- & si & -- & -- \\
\hline
- \const{PF\_AX25} & -- & -- & -- & -- & -- \\
+ \const{AF\_IRDA} & si & si & si & -- & si \\
\hline
- \const{PF\_ATMPVC} & -- & -- & -- & -- & -- \\
+ \const{AF\_NETROM} & -- & -- & -- & -- & si \\
\hline
- \const{PF\_APPLETALK} & -- & si & si & -- & -- \\
+ \const{AF\_ROSE} & -- & -- & -- & -- & si \\
\hline
- \const{PF\_PACKET} & -- & si & si & -- & -- \\
+ \const{AF\_RDS} & -- & -- & -- & -- & si \\
+ \hline
+ \const{AF\_ECONET} & -- & si & -- & -- & -- \\
\hline
\end{tabular}
\caption{Combinazioni valide di dominio e tipo di protocollo per la
Se si usa una struttura \struct{sockaddr} per allocare delle variabili
generiche da usare in seguito per degli indirizzi si pone il problema che
niente assicura che i dati necessari per le varie famiglie di indirizzi
-possano rientrare nella dimensione del campo \var{sa\_data}, anzi, come
-vedremo in sez.~\ref{sec:sock_sa_ipv6}, nel caso di indirizzi IPv6 questa
-non è proprio sufficiente. Per questo l'interfaccia di programmazione dei
-socket prevede la defizione di una speciale struttura
-\struct{sockaddr\_storage} per la quale è assicurato che la dimensione sia
-sufficiente per qualunque
+possano rientrare nella dimensione del campo \var{sa\_data} indicata in
+fig.~\ref{fig:sock_sa_gen_struct}, anzi, come vedremo in
+sez.~\ref{sec:sock_sa_ipv6}, nel caso di indirizzi IPv6 questa non è proprio
+sufficiente.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{0.95\textwidth}
+ \includestruct{listati/sockaddr_storage.h}
+ \end{minipage}
+ \caption{La struttura generica degli indirizzi dei socket
+ \structd{sockaddr\_storage}.}
+ \label{fig:sock_sa_storage_struct}
+\end{figure}
+
+Per questo l'interfaccia di programmazione dei socket prevede la defizione di
+una speciale struttura \struct{sockaddr\_storage} illustrata in
+fig.~\ref{fig:sock_sa_storage_struct}, in cui di nuovo si usa il primo campo
+(\var{ss\_family}) per indicare il tipo di indirizzo, ed in cui i campi
+successivi sono utilizzati per allineare i dati al tipo di architettura
+hardware utilizzata, e per allocare uno spazio sufficiente ampio per contenere
+qualunque tipo di indirizzo supportato. Allocando questa struttura si ha la
+certezza di non eccedere le dimensioni qualunque sia il tipo di indirizzi che
+si useranno, pertanto risulta utile tutte le volte che si devono gestire in
+maniera generica tipi di indirizzi diversi (ad esempio IPv4 ed IPv6).
\subsection{La struttura degli indirizzi IPv4}
\label{sec:sock_sa_ipv4}
-I socket di tipo \const{PF\_INET} vengono usati per la comunicazione
+I socket di tipo \const{AF\_INET} vengono usati per la comunicazione
attraverso Internet; la struttura per gli indirizzi per un socket Internet (se
si usa IPv4) è definita come \struct{sockaddr\_in} nell'header file
\headfiled{netinet/in.h} ed ha la forma mostrata in
L'indirizzo di un socket Internet (secondo IPv4) comprende l'indirizzo
Internet di un'interfaccia più un \textsl{numero di porta} (affronteremo in
dettaglio il significato di questi numeri in sez.~\ref{sec:TCP_port_num}). Il
-protocollo IP non prevede numeri di porta, che sono utilizzati solo dai
-protocolli di livello superiore come TCP e UDP. Questa struttura però viene
-usata anche per i socket RAW che accedono direttamente al livello di IP, nel
-qual caso il numero della porta viene impostato al numero di protocollo.
+protocollo IP di per sé non prevede numeri di porta, questi sono utilizzati
+solo dai protocolli di livello superiore come TCP e UDP, ma devono essere
+indicati qui. Inoltre questa struttura viene usata anche per i socket RAW che
+accedono direttamente al livello di IP, in questo caso il numero della porta
+deve essere impostato al numero di protocollo.
Il membro \var{sin\_family} deve essere sempre impostato a \constd{AF\_INET},
altrimenti si avrà un errore di \errcode{EINVAL}; il membro \var{sin\_port}
\subsection{La struttura degli indirizzi IPv6}
\label{sec:sock_sa_ipv6}
-Essendo IPv6 un'estensione di IPv4, i socket di tipo \const{PF\_INET6} sono
+Essendo IPv6 un'estensione di IPv4, i socket di tipo \const{AF\_INET6} sono
sostanzialmente identici ai precedenti; la parte in cui si trovano
praticamente tutte le differenze fra i due socket è quella della struttura
degli indirizzi; la sua definizione, presa da \headfile{netinet/in.h}, è
il loro uso è sperimentale.
Il campo \var{sin6\_addr} contiene l'indirizzo a 128 bit usato da IPv6,
-espresso da un vettore di 16 byte. Infine il campo \var{sin6\_scope\_id} è un
-campo introdotto in Linux con il kernel 2.4, per gestire alcune operazioni
-riguardanti il \textit{multicasting}. Si noti infine che
-\struct{sockaddr\_in6} ha una dimensione maggiore della struttura
-\struct{sockaddr} generica di fig.~\ref{fig:sock_sa_gen_struct}, quindi
-occorre stare attenti a non avere fatto assunzioni riguardo alla possibilità
-di contenere i dati nelle dimensioni di quest'ultima.
+espresso da un vettore di 16 byte; anche in questo caso esistono alcuni valori
+predediniti, ma essendo il campo un vettore di byte non è possibile assegnarli
+con il calore di una costante. Esistono però le variabili predefinite
+\var{in6addr\_any} (che indica l'indirizzo generico) e \var{in6addr\_loopback}
+(che indica l'indirizzo di loopback) il cui valore può essere copiato in
+questo campo. A queste due variabili si aggiungono le macro
+\macrod{IN6ADDR\_ANY\_INIT} e \macrod{IN6ADDR\_LOOPBACK\_INIT} per effettuare
+delle assegnazioni statiche.
+
+Infine il campo \var{sin6\_scope\_id} è un campo introdotto in Linux con il
+kernel 2.4, per gestire alcune operazioni riguardanti il
+\textit{multicasting}, è supportato solo per gli indirizzi di tipo
+\textit{link-local} (vedi sez.~\ref{sec:IP_ipv6_unicast}) e deve contenere
+l'\textit{interface index} (vedi sez.~\ref{sec:sock_ioctl_netdevice}) della
+scheda di rete. Si noti infine che \struct{sockaddr\_in6} ha una dimensione
+maggiore della struttura \struct{sockaddr} generica di
+fig.~\ref{fig:sock_sa_gen_struct}, quindi occorre stare attenti a non avere
+fatto assunzioni riguardo alla possibilità di contenere i dati nelle
+dimensioni di quest'ultima (per questo se necessario è opportuno usare
+\struct{sockaddr\_storage}).
\subsection{La struttura degli indirizzi locali}
\label{sec:sock_sa_local}
-I socket di tipo \const{PF\_UNIX} o \const{PF\_LOCAL} vengono usati per una
+I socket di tipo \const{AF\_UNIX} o \const{AF\_LOCAL} vengono usati per una
comunicazione fra processi che stanno sulla stessa macchina (per questo
vengono chiamati \textit{local domain} o anche \textit{Unix domain}); essi
hanno la caratteristica ulteriore di poter essere creati anche in maniera
\label{fig:sock_sa_local_struct}
\end{figure}
-In questo caso il campo \var{sun\_family} deve essere \constd{AF\_UNIX}, mentre
-il campo \var{sun\_path} deve specificare un indirizzo. Questo ha due forme;
-può essere un file (di tipo socket) nel filesystem o una stringa univoca
-(mantenuta in uno spazio di nomi astratto). Nel primo caso l'indirizzo viene
-specificato come una stringa (terminata da uno zero) corrispondente al
-\textit{pathname} del file; nel secondo invece \var{sun\_path} inizia con uno
-zero e vengono usati come nome i restanti byte come stringa, senza
-terminazione.
-
+In questo caso il campo \var{sun\_family} deve essere \constd{AF\_UNIX},
+mentre il campo \var{sun\_path} deve specificare un indirizzo. Questo ha due
+forme; può essere ``\textit{named}'' ed in tal caso deve corrispondere ad un
+file (di tipo socket) presente nel filesystem o essere ``\textit{abstract}''
+nel qual caso viene identificato da una stringa univoca in uno spazio di nomi
+astratto.
+
+Nel primo caso l'indirizzo viene specificato in \var{sun\_path} come una
+stringa (terminata da uno zero) corrispondente al \textit{pathname} del file;
+nel secondo caso (che è specifico di Linux e non portabile) \var{sun\_path}
+deve iniziare con uno zero ed il nome verrà costituito dai restanti byte che
+verranno interpretati come stringa senza terminazione (un byte nullo non ha in
+questo caso nessun significato).
+
+In realtà esiste una terza forma, \textit{unnamed}, che non è possibile
+indicare in fase di scrittura, ma che è quella che viene usata quando si legge
+l'indirizzo di un socket anonimo creato con \texttt{socketpair}; in tal caso
+la struttura restituita è di dimensione \code{sizeof(sa\_family\_t)}, quindi
+\var{sun\_path} non esiste e non deve essere referenziato.
\subsection{La struttura degli indirizzi AppleTalk}
\label{sec:sock_sa_appletalk}
-I socket di tipo \const{PF\_APPLETALK} sono usati dalla libreria
+I socket di tipo \const{AF\_APPLETALK} sono usati dalla libreria
\file{netatalk} per implementare la comunicazione secondo il protocollo
AppleTalk, uno dei primi protocolli di rete usato nel mondo dei personal
computer, usato dalla Apple per connettere fra loro computer e stampanti. Il
il campo \var{sat\_port} specifica la porta che identifica i vari
servizi. Valori inferiori a 129 sono usati per le \textsl{porte riservate}, e
possono essere usati solo da processi con i privilegi di amministratore o con
-la \textit{capability} \const{CAP\_NET\_BIND\_SERVICE}. L'indirizzo remoto è
-specificato nella struttura \var{sat\_addr}, e deve essere in \textit{network
- order} (vedi sez.~\ref{sec:endianness}); esso è composto da un parte di rete
-data dal campo \var{s\_net}, che può assumere il valore \constd{AT\_ANYNET},
-che indica una rete generica e vale anche per indicare la rete su cui si è, il
-singolo nodo è indicato da \var{s\_node}, e può prendere il valore generico
-\constd{AT\_ANYNODE} che indica anche il nodo corrente, ed il valore
-\constd{ATADDR\_BCAST} che indica tutti i nodi della rete.
+la \textit{capability} \const{CAP\_NET\_BIND\_SERVICE}.
+
+L'indirizzo remoto è specificato nella struttura \var{sat\_addr}, e deve
+essere in \textit{network order} (vedi sez.~\ref{sec:endianness}); esso è
+composto da un parte di rete data dal campo \var{s\_net}, che può assumere il
+valore \constd{AT\_ANYNET}, che indica una rete generica e vale anche per
+indicare la rete su cui si è, il singolo nodo è indicato da \var{s\_node}, e
+può prendere il valore generico \constd{AT\_ANYNODE} che indica anche il nodo
+corrente, ed il valore \constd{ATADDR\_BCAST} che indica tutti i nodi della
+rete.
\subsection{La struttura degli indirizzi dei \textit{packet socket}}
\label{sec:sock_sa_packet}
-I \textit{packet socket}, identificati dal dominio \const{PF\_PACKET}, sono
+I \textit{packet socket}, identificati dal dominio \const{AF\_PACKET}, sono
un'interfaccia specifica di Linux per inviare e ricevere pacchetti
direttamente su un'interfaccia di rete, senza passare per le funzioni di
gestione dei protocolli di livello superiore. In questo modo è possibile
-implementare dei protocolli in user space, agendo direttamente sul livello
-fisico. In genere comunque si preferisce usare la libreria
+implementare dei protocolli in \textit{user space}, agendo direttamente sul
+livello fisico. In genere comunque si preferisce usare la libreria
\file{pcap},\footnote{la libreria è mantenuta insieme al comando
\cmd{tcpdump}, informazioni e documentazione si possono trovare sul sito del
progetto \url{http://www.tcpdump.org/}.} che assicura la portabilità su
\struct{sockaddr\_ll} ad esso associata.
Si usano invece socket di tipo \const{SOCK\_DGRAM} quando si vuole operare a
-livello di rete. In questo caso in fase di ricezione l'intestazione del
-protocollo di collegamento viene rimossa prima di passare il resto del
-pacchetto all'utente, mentre in fase di trasmissione viene creata una
-opportuna intestazione per il protocollo a livello di collegamento
-utilizzato, usando le informazioni necessarie che devono essere specificate
-sempre con una struttura \struct{sockaddr\_ll}.
+livello di rete.
+
+In questo caso in fase di ricezione l'intestazione del protocollo di
+collegamento viene rimossa prima di passare il resto del pacchetto all'utente,
+mentre in fase di trasmissione viene creata una opportuna intestazione per il
+protocollo a livello di collegamento utilizzato, usando le informazioni
+necessarie che devono essere specificate sempre con una struttura
+\struct{sockaddr\_ll}.
Nella creazione di un \textit{packet socket} il valore dell'argomento
\param{protocol} di \func{socket} serve a specificare, in \textit{network
Una volta aperto un \textit{packet socket}, tutti i pacchetti del protocollo
specificato passeranno attraverso di esso, qualunque sia l'interfaccia da cui
provengono; se si vuole limitare il passaggio ad una interfaccia specifica
-occorre usare la funzione \func{bind} per agganciare il socket a quest'ultima.
+occorre usare la funzione \func{bind} (vedi sez.~\ref{sec:TCP_func_bind}) per
+agganciare il socket a quest'ultima.
\begin{figure}[!htb]
\footnotesize \centering
specificare gli indirizzi. Essa mantiene questo ruolo solo per i socket di
tipo \const{SOCK\_DGRAM}, per i quali permette di specificare i dati necessari
al protocollo di collegamento, mentre viene sempre utilizzata in lettura (per
-entrambi i tipi di socket), per la ricezione dei i dati relativi a ciascun
+entrambi i tipi di socket), per la ricezione dei dati relativi a ciascun
pacchetto.
Al solito il campo \var{sll\_family} deve essere sempre impostato al valore
\constd{AF\_PACKET}. Il campo \var{sll\_protocol} indica il protocollo scelto,
e deve essere indicato in \textit{network order}, facendo uso delle costanti
simboliche definite in \file{linux/if\_ether.h}. Il campo \var{sll\_ifindex} è
-l'indice dell'interfaccia, che, in caso di presenza di più interfacce dello
-stesso tipo (se ad esempio si hanno più schede Ethernet), permette di
-selezionare quella con cui si vuole operare (un valore nullo indica qualunque
-interfaccia). Questi sono i due soli campi che devono essere specificati
-quando si vuole selezionare una interfaccia specifica, usando questa struttura
-con la funzione \func{bind}.
+l'indice dell'interfaccia (l'\textit{inxterface index} (vedi
+sez.~\ref{sec:sock_ioctl_netdevice}) che in caso di presenza di più
+interfacce dello stesso tipo (se ad esempio si hanno più schede Ethernet),
+permette di selezionare quella con cui si vuole operare (un valore nullo
+indica qualunque interfaccia). Questi sono i due soli campi che devono essere
+specificati quando si vuole selezionare una interfaccia specifica, usando
+questa struttura con la funzione \func{bind}.
I campi \var{sll\_halen} e \var{sll\_addr} indicano rispettivamente
l'indirizzo associato all'interfaccia sul protocollo di collegamento e la
%% \subsection{La struttura degli indirizzi DECnet}
%% \label{sec:sock_sa_decnet}
-%% I socket di tipo \const{PF\_DECnet} usano il protocollo DECnet, usato dai VAX
+%% I socket di tipo \const{AF\_DECnet} usano il protocollo DECnet, usato dai VAX
%% Digital sotto VMS quando ancora il TCP/IP non era diventato lo standard di
%% fatto. Il protocollo è un protocollo chiuso, ed il suo uso attuale è limitato
%% alla comunicazione con macchine che stanno comunque scomparendo. Lo si riporta
%% solo come esempio
+% TODO aggiungere AF_CAN, vedi http://lwn.net/Articles/253425, dal 2.6.25 ?
+
% TODO: trattare i socket RDS, vedi documentazione del kernel, file
% Documentation/networking/rds.txt
rispettivi prototipi sono:
\begin{funcproto}{
-\fhead{netinet/in.h}
+\fhead{arpa/inet.h}
\fdecl{unsigned long int htonl(unsigned long int hostlong)}
\fdesc{Converte l'intero a 32 bit \param{hostlong} dal formato della macchina a
quello della rete.}
\fdesc{Converte l'intero a 16 bit \param{hostshort} dal formato della macchina a
quello della rete.}
\fdecl{unsigned long int ntohl(unsigned long int netlong)}
-\fdesc{Converte l'intero a 32 bit \param{netlong} dal formato della rete a quello
- della macchina.}
+\fdesc{Converte l'intero a 32 bit \param{netlong} dal formato della rete a
+ quello della macchina.}
\fdecl{unsigned sort int ntohs(unsigned short int netshort)}
-\fdesc{Converte l'intero a 16 bit \param{netshort} dal formato della rete a quello
- della macchina.}
+\fdesc{Converte l'intero a 16 bit \param{netshort} dal formato della rete a
+ quello della macchina.}
}
{Tutte le funzioni restituiscono il valore convertito, e non prevedono
assicurare la portabilità del codice su tutte le architetture.
-\subsection{Le funzioni \func{inet\_aton}, \func{inet\_addr} e
- \func{inet\_ntoa}}
+\subsection{Le funzioni di conversione per gli indirizzi IPv4}
\label{sec:sock_func_ipv4}
-Un secondo insieme di funzioni di manipolazione serve per passare dal formato
-binario usato nelle strutture degli indirizzi alla rappresentazione simbolica
-dei numeri IP che si usa normalmente.
+Un secondo insieme di funzioni di manipolazione è quello che serve per passare
+dalla rappresentazione simbolica degli indirizzi IP al formato binario
+previsto dalla struttura degli indirizzi di
+fig.~\ref{fig:sock_sa_ipv4_struct}, e viceversa. La notazione più comune è la
+cosiddetta notazione \itindex{dotted-decimal} \textit{dotted-decimal}, che
+prevede che gli indirizzi IPv4 siano indicati con l'espressione del valore
+numerico decimale di ciascuno dei 4 byte che li costituiscono separati da un
+punto (ad esempio \texttt{192.168.0.1}).
+
+In realtà le funzioni che illustreremo supportano una notazione che più
+propriamente dovrebbe esser chiamata \textit{numbers-and-dot} in quanto il
+valore può essere indicato con numeri espressi sia in decimale, che in ottale
+(se indicati apponendo uno zero) che in esadecimale (se indicati apponendo
+\texttt{0x}). Inoltre per la parte meno significativa dell'espressione, quella
+che riguarda l'indirizzo locale, si può usare, eliminando altrettanti punti,
+valori a 16 o a 24 bit, e togliendo tutti i punti, si può usare anche
+direttamente un valore numerico a 32 bit.\footnote{la funzionalità si trova
+ anche in gran parte dei programmi che usano indirizzi di rete, e deriva
+ direttamente da queste funzioni.}
+
+Tradizionalmente la conversione di un indirizzo \textit{dotted-decimal} al
+valore numerico veniva eseguita dalla funzione \funcd{inet\_addr} (prevista
+fin dalle origini in BSD e inclusa in POSIX.1-2001) il cui prototipo è:
+
+\begin{funcproto}{
+\fhead{arpa/inet.h}
+\fdecl{in\_addr\_t inet\_addr(const char *strptr)}
+\fdesc{Converte la stringa dell'indirizzo \textit{dotted decimal} in nel
+ numero IP in network order.}
+}
-Le prime tre funzioni di manipolazione riguardano la conversione degli
-indirizzi IPv4 da una stringa in cui il numero di IP è espresso secondo la
-cosiddetta notazione \textit{dotted-decimal}, (cioè nella forma
-\texttt{192.168.0.1}) al formato binario (direttamente in \textit{network
- order}) e viceversa; in questo caso si usa la lettera \texttt{a} come
-mnemonico per indicare la stringa. Dette funzioni sono \funcd{inet\_addr},
-\funcd{inet\_aton} e \funcd{inet\_ntoa}, ed i rispettivi prototipi sono:
-\begin{functions}
- \headdecl{arpa/inet.h}
-
- \funcdecl{in\_addr\_t inet\_addr(const char *strptr)} Converte la stringa
- dell'indirizzo \textit{dotted decimal} in nel numero IP in network order.
+{La funzione ritorna il valore dell'indirizzo in caso di successo e
+ \const{INADDR\_NONE} per un errore e non genera codici di errore.}
+\end{funcproto}
- \funcdecl{int inet\_aton(const char *src, struct in\_addr *dest)} Converte
- la stringa dell'indirizzo \textit{dotted decimal} in un indirizzo IP.
+La prima funzione, \func{inet\_addr}, restituisce l'indirizzo a 32 bit in
+\textit{network order} (del tipo \type{in\_addr\_t}) a partire dalla stringa
+passata nell'argomento \param{strptr}. In caso di errore (quando la stringa
+non esprime un indirizzo valido) restituisce invece il valore
+\const{INADDR\_NONE}, che tipicamente sono trentadue bit a uno. Questo però
+comporta che la stringa \texttt{255.255.255.255}, che pure è un indirizzo
+valido, non può essere usata con questa funzione dato che genererebe comunque
+un errore; per questo motivo essa è generalmente deprecata in favore di
+\func{inet\_aton}.
+
+Per effettuare la conversione inversa la funzione usata tradizionalmente è
+\funcd{inet\_ntoa}, anch'essa presente fin da BSD 4.3, in cui si riprende la
+notazione già vista in sez.~\ref{sec:sock_func_ord} che usa la lettera
+\texttt{n} come mnemonico per indicare la rete ed \texttt{a} (per ASCII) come
+mnemonico per indicare la stringa corrispodente all'indirizzo; il suo
+prototipo è:
- \funcdecl{char *inet\_ntoa(struct in\_addr addrptr)}
- Converte un indirizzo IP in una stringa \textit{dotted decimal}.
+\begin{funcproto}{
+\fhead{arpa/inet.h}
+\fdecl{char *inet\_ntoa(struct in\_addr addrptr)}
+\fdesc{Converte un indirizzo IP in una stringa \textit{dotted decimal}.}
+}
- \bodydesc{Tutte queste le funzioni non generano codice di errore.}
-\end{functions}
+{La funzione l'indirizzo della stringa con il valore dell'indirizzo convertito
+ e non prevede errori.}
+\end{funcproto}
-La prima funzione, \func{inet\_addr}, restituisce l'indirizzo a 32 bit in
-network order (del tipo \type{in\_addr\_t}) a partire dalla stringa passata
-nell'argomento \param{strptr}. In caso di errore (quando la stringa non esprime
-un indirizzo valido) restituisce invece il valore \const{INADDR\_NONE} che
-tipicamente sono trentadue bit a uno. Questo però comporta che la stringa
-\texttt{255.255.255.255}, che pure è un indirizzo valido, non può essere usata
-con questa funzione; per questo motivo essa è generalmente deprecata in favore
-di \func{inet\_aton}.
-
-La funzione \func{inet\_aton} converte la stringa puntata da \param{src}
-nell'indirizzo binario che viene memorizzato nell'opportuna struttura
-\struct{in\_addr} (si veda fig.~\ref{fig:sock_sa_ipv4_struct}) situata
-all'indirizzo dato dall'argomento \param{dest} (è espressa in questa forma in
-modo da poterla usare direttamente con il puntatore usato per passare la
-struttura degli indirizzi). La funzione restituisce un valore diverso da zero
-se l'indirizzo è valido e la conversione ha successo e 0 in caso contrario.
-Se usata con \param{dest} inizializzato a \val{NULL} effettua la validazione
-dell'indirizzo.
-
-L'ultima funzione, \func{inet\_ntoa}, converte il valore a 32 bit
-dell'indirizzo (espresso in \textit{network order}) restituendo il puntatore
-alla stringa che contiene l'espressione in formato dotted decimal. Si deve
-tenere presente che la stringa risiede in memoria statica, per cui questa
-funzione non è rientrante.
-
-
-\subsection{Le funzioni \func{inet\_pton} e \func{inet\_ntop}}
+La funzione converte il valore a 32 bit dell'indirizzo, espresso in
+\textit{network order}, e preso direttamente con un puntatore al relativo
+campo della struttura degli indirizzi, restituendo il puntatore alla stringa
+che contiene l'espressione in formato \textit{dotted-decimal}. Si deve tenere
+presente che la stringa risiede in un segmento di memoria statica, per cui
+viene riscritta ad ogni chiamata e la funzione non è rientrante.
+
+Per rimediare ai problemi di \funcd{inet\_addr} è stata sostituita da
+\funcd{inet\_aton}, che però non è stata standardizzata e non è presente in
+POSIX.1-2001, anche se è definita sulla gran parte dei sistemi Unix; il suo
+prototipo è:
+
+\begin{funcproto}{
+\fhead{arpa/inet.h}
+\fdecl{int inet\_aton(const char *src, struct in\_addr *dest)}
+\fdesc{Converte la stringa dell'indirizzo \textit{dotted decimal} in un
+ indirizzo IP.}
+}
+
+{La funzione ritorna un valore non nullo in caso di successo e $0$ per un
+ errore e non genera codici di errore.}
+\end{funcproto}
+
+La funzione converte la stringa puntata da \param{src} nell'indirizzo binario
+che viene memorizzato nell'opportuna struttura \struct{in\_addr} (si veda
+fig.~\ref{fig:sock_sa_ipv4_struct}) situata all'indirizzo dato
+dall'argomento \param{dest} (è espressa in questa forma in modo da poterla
+usare direttamente con il puntatore usato per passare la struttura degli
+indirizzi). La funzione restituisce un valore diverso da zero se l'indirizzo è
+valido e la conversione ha successo e 0 in caso contrario. Se usata
+con \param{dest} inizializzato a \val{NULL} può essere usata per effettuare la
+validazione dell'indirizzo espresso da \param{src}.
+
+Oltre a queste tre funzioni esistono le ulteriori \funcm{inet\_lnaof},
+\funcm{inet\_netof} e \funcm{inet\_makeaddr} che assumono la ormai obsoleta e
+deprecata suddivisione in classi degli indirizzi IP per fornire la parte di
+rete e quella di indirizzo locale. Ad oggi il loro uso non ha più alcun senso
+per ciò non le tratteremo.
+
+
+\subsection{Le funzioni di conversione per indirizzi IP generici}
\label{sec:sock_conv_func_gen}
Le tre funzioni precedenti sono limitate solo ad indirizzi IPv4, per questo
indirizzo, e che può essere soltanto \const{AF\_INET} o \const{AF\_INET6}. La
prima funzione, \funcd{inet\_pton}, serve a convertire una stringa in un
indirizzo; il suo prototipo è:
-\begin{prototype}{sys/socket.h}
-{int inet\_pton(int af, const char *src, void *addr\_ptr)}
- Converte l'indirizzo espresso tramite una stringa nel valore numerico.
-
- \bodydesc{La funzione restituisce un valore negativo se \param{af} specifica
- una famiglia di indirizzi non valida, con \var{errno} che assume il valore
- \errcode{EAFNOSUPPORT}, un valore nullo se \param{src} non rappresenta un
- indirizzo valido, ed un valore positivo in caso di successo.}
-\end{prototype}
+\begin{funcproto}{
+\fhead{sys/socket.h}
+\fdecl{int inet\_pton(int af, const char *src, void *addr\_ptr)}
+\fdesc{Converte l'indirizzo espresso tramite una stringa nel valore numerico.}
+}
+
+{La funzione ritorna $1$ in caso di successo, $0$ se \param{src} non contiene
+ una rappresentazione valida per la famiglia di indirizzi indicati
+ da \param{af} e $-1$ se \param{af} specifica una famiglia di indirizzi non
+ valida, e solo in quest'ultimo caso \var{errno} assumerà il valore
+ \errcode{EAFNOSUPPORT}.
+}
+\end{funcproto}
La funzione converte la stringa indicata tramite \param{src} nel valore
numerico dell'indirizzo IP del tipo specificato da \param{af} che viene
-memorizzato all'indirizzo puntato da \param{addr\_ptr}, la funzione
-restituisce un valore positivo in caso di successo, nullo se la stringa non
-rappresenta un indirizzo valido, e negativo se \param{af} specifica una
-famiglia di indirizzi non valida.
+memorizzato all'indirizzo puntato da \param{addr\_ptr}. La funzione supporta
+per IPv4 la sola notazione \textit{dotted-decimal}, e non quella più completa
+\textit{number-and-dot} che abbiamo visto per \func{inet\_aton}. Per IPv6 la
+notazione prevede la suddivisione dei 128 bit dell'indirizzo in 16 parti di 16
+bit espresse con valori esadecimali separati dal carattere ``\texttt{:}'' ed
+una serie di valori nulli possono essere sostituiti (una sola volta, sempre a
+partire dalla sinistra) con la notazione ``\texttt{::}'', un esempio di
+indirizzo in questa forma potrebbe essere \texttt{2001:db8::8:ba98:2078:e3e3},
+per una descrizione più completa si veda sez.~\ref{sec:IP_ipv6_notation}.
La seconda funzione di conversione è \funcd{inet\_ntop} che converte un
indirizzo in una stringa; il suo prototipo è:
-\begin{prototype}{sys/socket.h}
- {char *inet\_ntop(int af, const void *addr\_ptr, char *dest, size\_t len)}
- Converte l'indirizzo dalla relativa struttura in una stringa simbolica.
-
- \bodydesc{La funzione restituisce un puntatore non nullo alla stringa
- convertita in caso di successo e \val{NULL} in caso di fallimento, nel
- qual caso \var{errno} assume i valori:
- \begin{errlist}
+
+\begin{funcproto}{
+\fhead{sys/socket.h}
+\fdecl{char *inet\_ntop(int af, const void *addr\_ptr, char *dest, size\_t len)}
+\fdesc{Converte l'indirizzo dalla relativa struttura in una stringa simbolica.}
+}
+
+{La funzione ritorna un puntatore non nullo alla stringa convertita in caso di
+ successo e \val{NULL} per un errore, nel qual caso \var{errno} assumerà uno
+ dei valori:
+ \begin{errlist}
\item[\errcode{ENOSPC}] le dimensioni della stringa con la conversione
dell'indirizzo eccedono la lunghezza specificata da \param{len}.
\item[\errcode{ENOAFSUPPORT}] la famiglia di indirizzi \param{af} non è
una valida.
- \end{errlist}}
-\end{prototype}
+ \end{errlist}
+}
+\end{funcproto}
+
La funzione converte la struttura dell'indirizzo puntata da \param{addr\_ptr}
in una stringa che viene copiata nel buffer puntato dall'indirizzo
\param{dest}; questo deve essere preallocato dall'utente e la lunghezza deve
essere almeno \constd{INET\_ADDRSTRLEN} in caso di indirizzi IPv4 e
\constd{INET6\_ADDRSTRLEN} per indirizzi IPv6; la lunghezza del buffer deve
-comunque venire specificata attraverso il parametro \param{len}.
+comunque essere specificata con il parametro \param{len}.
Gli indirizzi vengono convertiti da/alle rispettive strutture di indirizzo
(una struttura \struct{in\_addr} per IPv4, e una struttura \struct{in6\_addr}
puntatore \param{addr\_ptr}; l'argomento \param{dest} di \func{inet\_ntop} non
può essere nullo e deve essere allocato precedentemente.
-Il formato usato per gli indirizzi in formato di presentazione è la notazione
-\textit{dotted decimal} per IPv4 e quello descritto in
-sez.~\ref{sec:IP_ipv6_notation} per IPv6.
-
-
projects / gapil.git / blobdiff