supportare vari tipi di indirizzi, per cui il prefisso \texttt{PF\_} si
sarebbe dovuto usare nella creazione dei socket e il prefisso \texttt{AF\_} in
quello delle strutture degli indirizzi; questo è quanto specificato anche
-dallo standard POSIX1g, ma non esistono a tuttora famiglie di protocolli che
+dallo standard POSIX.1g, ma non esistono a tuttora famiglie di protocolli che
supportino diverse strutture di indirizzi, per cui nella pratica questi due
nomi sono equivalenti e corrispondono agli stessi valori.
\label{tab:net_pf_names}
\end{table}
-Non tutte le famiglie di protocolli sono accessibili dall'utente generico,
-come forma di protezione infatti soltanto root può usare i protocolli di basso
-livello [NdA approfondire].
+Non tutte le famiglie di protocolli sono accessibili dall'utente generico, ad
+esempio in generale tutti i socket di tipo \texttt{SOCK\_RAW} possono essere
+creati solo da processi che hanno i provilegi di root (cioè effective uid
+uguale a zero) o la capability \texttt{CAP\_NET\_RAW}.
\subsection{Il tipo, o stile}
\cline{2-6}
\texttt{PF\_INET6} & TCP & UDP & IPv6 & & \\
\cline{2-6}
- \texttt{PF\_IPX} & ? & & & & \\
+ \texttt{PF\_IPX} & & & & & \\
\cline{2-6}
- \texttt{PF\_NETLINK} & & & si & & \\
+ \texttt{PF\_NETLINK} & & si & si & & \\
\cline{2-6}
- \texttt{PF\_X25} & & & & & \\
+ \texttt{PF\_X25} & & & & & si \\
\cline{2-6}
\texttt{PF\_AX25} & & & & & \\
\cline{2-6}
- \texttt{PF\_ATMPVC} & ? & & & & \\
+ \texttt{PF\_ATMPVC} & & & & & \\
\cline{2-6}
- \texttt{PF\_APPLETALK} & ? & & & & \\
+ \texttt{PF\_APPLETALK} & & si & si & & \\
\cline{2-6}
- \texttt{PF\_PACKET} & & & & & \\
+ \texttt{PF\_PACKET} & & si & si & & \\
\cline{2-6}
\end{tabular}
\caption{Combinazioni valide di dominio e tipo di protocollo per la funzione \texttt{socket}.}
\section{Le strutture degli indirizzi dei socket}
\label{sec:sock_sockaddr}
-Benché esse non vengano utilizzate nella creazione di un socket le strutture
-degli indirizzi sono usate da quasi tutte le altre funzioni concernenti
-socket, per cui in questa sezione le tratteremo in dettaglio.
+Come si è visto nella creazione di un socket non si specifica nulla oltre al
+tipo di famiglia di protocolli che si vuole utilizzare, in particolare nessun
+indirizzo che identifichi i due capi della comunicazione. La funzione infatti
+si limita ad allocare nel kernel quanto necessario per poter poi realizzare la
+comunicazione.
+Gli indirizzi vengono specificati attraverso apposite strutture che vengono
+utilizzate dalle altre funzioni della API dei socket quando la comunicazione
+viene effettivamente realizzata.
-I nomi di tutte queste strutture iniziano per \texttt{sockaddr\_} e ciascuna
-famiglia di protocolli ha una sua peculiare, che viene identificata dal
-suffisso finale aggiunto al nome precedente.
-
+Ogni famiglia di protocolli ha ovviamente una sua forma di indirizzamento e in
+corrispondenza a questa una sua peculiare struttura degli indirizzi; i nomi di
+tutte queste strutture iniziano per \texttt{sockaddr\_}, quelli propri di
+ciascuna famiglia vengono identificati dal suffisso finale, aggiunto al nome
+precedente.
\subsection{La struttura generica}
\label{sec:sock_sa_gen}
+Le strutture degli indirizzi vengono sempre passate alle varie funzioni
+attraverso puntatori (cioè \textit{by reference}), ma le funzioni devono poter
+maneggiare puntatori a strutture relative a tutti gli indirizzi possibili
+nelle varie famiglie di protocolli; questo pone il problema di come passare
+questi puntatori, il C ANSI risolve questo problema coi i puntatori generici
+(i \texttt{void *}), ma l'interfaccia dei socket è antecendente alla
+definizione dello standard ANSI, e per questo nel 1982 fu scelto di definire
+una struttura generica \texttt{sockaddr} per gli indirizzi dei socket mostrata
+in \nfig:
+
+\begin{figure}[!htbp]
+ \footnotesize
+ \begin{lstlisting}{}
+struct sockaddr {
+ sa_family_t sa_family; /* address family: AF_xxx */
+ char sa_data[14]; /* address (protocol-specific) */
+};
+ \end{lstlisting}
+ \caption{La struttura generica degli indirizzi dei socket \texttt{sockaddr}}
+ \label{fig:sock_sa_struct}
+\end{figure}
+
+Tutte le funzioni dei socket che usano gli indirizzi sono definite usando nel
+prototipo un puntatore a questa struttura; per questo motivo quando si
+invocano dette funzioni passando l'indirizzo di un protocollo specifico
+occorrerà eseguire un casting del relativo puntatore.
+
+I tipi di dati che compongono la struttura sono stabiliti dallo standard
+Posix.1g, riassunti in \ntab\ con i rispettivi file di include in cui sono
+definiti; la struttura è invece definita nell'include file
+\texttt{sys/socket.h}
+
+\begin{table}[!htbp]
+ \centering
+ \begin{tabular}{|l|l|l|}
+ \hline
+ \multicolumn{1}{|c|}{Tipo}& \multicolumn{1}{|c|}{Descrizione}&
+ \multicolumn{1}{|c|}{Header} \\
+ \hline
+ \hline
+ \texttt{int8\_t} & intero a 8 bit con segno & \texttt{sys/types.h}\\
+ \texttt{uint8\_t} & intero a 8 bit senza segno & \texttt{sys/types.h}\\
+ \texttt{int16\_t} & intero a 16 bit con segno & \texttt{sys/types.h}\\
+ \texttt{uint16\_t} & intero a 16 bit senza segno& \texttt{sys/types.h}\\
+ \texttt{int32\_t} & intero a 32 bit con segno & \texttt{sys/types.h}\\
+ \texttt{uint32\_t} & intero a 32 bit senza segno& \texttt{sys/types.h}\\
+ \hline
+ \texttt{sa\_family\_t} & famiglia degli indirizzi& \texttt{sys/socket.h}\\
+ \texttt{socklen\_t} & lunghezza (\texttt{uint32\_t}) dell'indirizzo di
+ un socket& \texttt{sys/socket.h}\\
+ \hline
+ \texttt{in\_addr\_t} & indirizzo IPv4 (\texttt{uint32\_t}) &
+ \texttt{netinet/in.h}\\
+ \texttt{in\_port\_t} & porta TCP o UDP (\texttt{uint16\_t})&
+ \texttt{netinet/in.h}\\
+ \hline
+ \end{tabular}
+ \caption{Tipi di dati usati nelle strutture degli indirizzi, secondo quanto
+ stabilito dallo standard Posix.1g}
+ \label{tab:sock_data_types}
+\end{table}
+
+In alcuni sistemi (per BSD a partire da 4.3BSD-reno) la struttura è
+leggermente diversa e prevede un primo membro aggiuntivo \texttt{uint8\_t
+ sin\_len} (come riportato da R. Stevens nei suoi libri). Questo campo non
+verrebbe usato direttamente dal programmatore e non è richiesto dallo standard
+Posix.1g, in Linux pertanto non sussiste. Il campo \texttt{sa\_family\_t} era
+storicamente un \texttt{unsigned short}.
+
+Dal punto di vista del programmatore l'unico uso di questa struttura è quello
+di fare da riferimento per il casting, per il kernel le cose sono un po'
+diverse, in quanto esso usa il puntatore per recuperare il campo
+\texttt{sa\_family} con cui determinare il tipo di indirizzo; per questo
+motivo, anche se l'uso di un puntatore \texttt{void *} sarebbe più immediato
+per l'utente (che non dovrebbe più eseguire il casting), è stato mantenuto
+l'uso di questa struttura.
+
+
\subsection{La struttura degli indirizzi IPv4}
\label{sec:sock_sa_ipv4}
+I socket di tipo \texttt{PF\_INET} vengono usati per la comunicazione
+attraverso internet; la struttura per gli indirizzi per un socket internet
+(IPv4) è definita come \texttt{sockaddr\_in} nell'header file
+\texttt{netinet/in.h} e secondo le man page ha la forma mostrata in \nfig,
+conforme allo standard Posix.1g.
+
+
+\begin{figure}[!htbp]
+ \footnotesize
+ \begin{lstlisting}{}
+struct sockaddr_in {
+ sa_family_t sin_family; /* address family: AF_INET */
+ u_int16_t sin_port; /* port in network byte order */
+ struct in_addr sin_addr; /* internet address */
+};
+/* Internet address. */
+struct in_addr {
+ u_int32_t s_addr; /* address in network byte order */
+};
+ \end{lstlisting}
+ \caption{La struttura degli indirizzi dei socket internet (IPv4)
+ \texttt{sockaddr\_in}.}
+ \label{fig:sock_sa_struct}
+\end{figure}
+
+L'indirizzo di un socket internet (secondo IPv4) comprende l'indirizzo
+internet di un'interfaccia più un numero di porta. 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 settato al numero di protocollo.
+
+Il membro \texttt{sin\_family} deve essere sempre settato; \texttt{sin\_port}
+specifica il numero di porta; i numeri di porta sotto il 1024 sono chiamati
+\textsl{riservati} in quanto utilizzati da servizi standard. Soltanto processi
+con i privilegi di root (effective uid uguale a zero) o con la capability
+\texttt{CAP\_NET\_BIND\_SERVICE} possono usare la funzione \texttt{bind} su
+queste porte.
+
+Il membro \texttt{sin\_addr} contiene l'indirizzo internet dell'altro capo
+della comunicazione, e viene acceduto sia come struttura (un resto di una
+implementazione precedente in cui questa era una union usata per accedere alle
+diverse classi di indirizzi) che come intero.
+
+Infine è da sottolineare che sia gli indirizzi che i numeri di porta devono
+essere specificati in quello che viene chiamato \textit{network order}, cioè
+con i bit ordinati in formato \textit{big endian}, questo comporta la
+necessità di usare apposite funzioni di conversione per mantenere la
+portabilità del codice (vedi \ref{sec:sock_addr_func} per i dettagli del
+problema e le relative soluzioni).
+
\subsection{La struttura degli indirizzi IPv6}
\label{sec:sock_sa_ipv6}
+
+Essendo IPv6 una estenzione di IPv4 i socket di tipo \texttt{PF\_INET6} sono
+sostanzialmente identici ai precedenti; la parte in cui si trovano
+praticamente tutte le differenze è quella della struttura degli indirizzi. La
+struttura degli indirizzi è definita ancora in \texttt{netinet/in.h}.
+
+\begin{figure}[!htbp]
+ \footnotesize
+ \begin{lstlisting}{}
+struct sockaddr_in6 {
+ u_int16_t sin6_family; /* AF_INET6 */
+ u_int16_t sin6_port; /* port number */
+ u_int32_t sin6_flowinfo; /* IPv6 flow information */
+ struct in6_addr sin6_addr; /* IPv6 address */
+ u_int32_t sin6_scope_id; /* Scope id (new in 2.4) */
+};
+
+struct in6_addr {
+ unsigned char s6_addr[16]; /* IPv6 address */
+};
+ \end{lstlisting}
+ \caption{La struttura degli indirizzi dei socket IPv6
+ \texttt{sockaddr\_in6}.}
+ \label{fig:sock_sa_struct}
+\end{figure}
+
+Il campo \texttt{sin6\_family} deve essere sempre settato ad
+\texttt{AF\_INET6}, il campo \texttt{sin6\_port} è analogo a quello di IPv4 e
+segue le stesse regole; il campo \texttt{sin6\_flowinfo} è a dua volta diviso
+in tre parti di cui i 24 bit inferiori indicano l'etichetta di flusso, i
+successivi 4 bit la priorità e gli ultimi 4 sono riservati; questi valori
+fanno riferimento ad alcuni campi specifici dell'header dei pacchetti IPv6
+(vedi \ref{sec:appA_ipv6}) ed il loro uso è sperimentale.
+
+Il campo \texttt{sin6\_addr} contiene l'indirizzo a 128 bit usato da IPv6,
+infine il campo \texttt{sin6\_scope\_id} è un campo introdotto con il kernel
+2.4 per gestire alcune operazioni riguardanti il multicasting.
+
+Si noti che questa struttura è più grande di una \texttt{sockaddr} generica,
+quindi occorre stare attenti a non avere fatto assunzioni riguardo alla
+possibilità di contenere i dati nelle dimensioni di quest'ultima.
+
+
\subsection{La struttura degli indirizzi locali}
\label{sec:sock_sa_local}
+I socket di tipo \texttt{PF\_UNIX} vengono usati per una comunicazione
+efficiente fra processi che stanno sulla stessa macchina; essi rispetto ai
+precedenti possono essere anche creati in maniera anonima attraverso la
+funzione \texttt{socketpair}. Quando però si vuole fare riferiemento ad uno di
+questi socket si deve usare la seguente struttura di indirizzi definita nel
+file di header \texttt{sys/un.h}.
+\begin{figure}[!htbp]
+ \footnotesize
+ \begin{lstlisting}{}
+#define UNIX_PATH_MAX 108
+struct sockaddr_un {
+ sa_family_t sun_family; /* AF_UNIX */
+ char sun_path[UNIX_PATH_MAX]; /* pathname */
+};
+ \end{lstlisting}
+ \caption{La struttura degli indirizzi dei socket locali
+ \texttt{sockaddr\_un}.}
+ \label{fig:sock_sa_struct}
+\end{figure}
+In questo caso il campo \texttt{sun\_family} deve essere \texttt{AF\_UNIX},
+mentre il campo \texttt{sun\_path} deve specificare un indirizzo; questo ha
+due forme un file (di tipo socket) nel filesystem o una stringa univoca
+(tenuta in uno spazio di nomi astratto). Nel primo caso l'indirizzo viene
+specificato come una stringa (terminata da uno zero) corrispondente al
+pathname del file; nel secondo qinvece \texttt{sun\_path} inizia con uno zero
+vegono usati i restanti bytes come stringa (senza terminazione).
-\section{Le funzioni di conversione degli indirizzi}
-\label{sec:sock_addr_conv}
+\subsection{Il passaggio delle strutture}
+\label{sec:sock_addr_pass}
+
+Come detto nelle funzioni della API dei socket le strutture degli indirizzi
+vengono sempre passate per riferimento usando un puntatore; anche la lunghezza
+della struttura è passata come argomento, ma in questo caso la modalità del
+passaggio dipende dalla direzione del medesimo, dal processo al kernel o
+viceversa.
+
+In particolare le tre funzioni \texttt{bind}, \texttt{connect} e
+\texttt{sendto} passano la struttura al kernel, in questo caso è passata
+\textsl{per valore} anche la dimensione della medesima
+Le funzioni \texttt{accept}, \texttt{recvfrom}, \texttt{getsockname} e
+\texttt{getpeername}
+
+
+\section{Le funzioni di conversione degli indirizzi}
+\label{sec:sock_addr_func}
projects / gapil.git / commitdiff