+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.
+
+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 \var{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 \ctyp{void *}), ma l'interfaccia dei socket è antecedente alla definizione
+dello standard ANSI, e per questo nel 1982 fu scelto di definire una struttura
+generica per gli indirizzi dei socket, \struct{sockaddr}, che si è riportata in
+\figref{fig:sock_sa_gen_struct}.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
+struct sockaddr {
+ sa_family_t sa_family; /* address family: AF_xxx */
+ char sa_data[14]; /* address (protocol-specific) */
+};
+ \end{lstlisting}
+ \end{minipage}
+ \caption{La struttura generica degli indirizzi dei socket
+ \structd{sockaddr}.}
+ \label{fig:sock_sa_gen_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 \tabref{tab:sock_data_types} con i rispettivi file di
+include in cui sono definiti; la struttura è invece definita nell'include file
+\file{sys/socket.h}.
+
+\begin{table}[!htb]
+ \centering
+ \footnotesize
+ \begin{tabular}{|l|l|l|}
+ \hline
+ \multicolumn{1}{|c|}{\textbf{Tipo}}&
+ \multicolumn{1}{|c|}{\textbf{Descrizione}}&
+ \multicolumn{1}{|c|}{\textbf{Header}} \\
+ \hline
+ \hline
+ \type{int8\_t} & intero a 8 bit con segno & \file{sys/types.h}\\
+ \type{uint8\_t} & intero a 8 bit senza segno & \file{sys/types.h}\\
+ \type{int16\_t} & intero a 16 bit con segno & \file{sys/types.h}\\
+ \type{uint16\_t} & intero a 16 bit senza segno& \file{sys/types.h}\\
+ \type{int32\_t} & intero a 32 bit con segno & \file{sys/types.h}\\
+ \type{uint32\_t} & intero a 32 bit senza segno& \file{sys/types.h}\\
+ \hline
+ \type{sa\_family\_t} & famiglia degli indirizzi& \file{sys/socket.h}\\
+ \type{socklen\_t} & lunghezza (\type{uint32\_t}) dell'indirizzo di
+ un socket& \file{sys/socket.h}\\
+ \hline
+ \type{in\_addr\_t} & indirizzo IPv4 (\type{uint32\_t}) &
+ \file{netinet/in.h}\\
+ \type{in\_port\_t} & porta TCP o UDP (\type{uint16\_t})&
+ \file{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 la struttura è leggermente diversa e prevede un primo membro
+aggiuntivo \code{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 esiste. Il campo
+\type{sa\_family\_t} era storicamente un \ctyp{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
+\var{sa\_family} con cui determinare il tipo di indirizzo; per questo
+motivo, anche se l'uso di un puntatore \ctyp{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 \const{PF\_INET} vengono usati per la comunicazione
+attraverso internet; la struttura per gli indirizzi per un socket internet
+(IPv4) è definita come \struct{sockaddr\_in} nell'header file
+\file{netinet/in.h} e secondo le pagine di manuale ha la forma mostrata in
+\figref{fig:sock_sa_ipv4_struct}, conforme allo standard POSIX.1g.
+
+\begin{figure}[!htb]
+ \footnotesize\centering
+ \begin{minipage}[c]{15cm}
+ \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
+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}
+ \end{minipage}
+ \caption{La struttura degli indirizzi dei socket internet (IPv4)
+ \structd{sockaddr\_in}.}
+ \label{fig:sock_sa_ipv4_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 impostato al numero di protocollo.
+
+Il membro \var{sin\_family} deve essere sempre impostato; \var{sin\_port}
+specifica il numero di porta (vedi \secref{sec:TCPel_port_num}; i numeri di
+porta sotto il 1024 sono chiamati \textsl{riservati} in quanto utilizzati da
+servizi standard. Soltanto processi con i privilegi di root (con userid
+effettivo uguale a zero) o con la capability \texttt{CAP\_NET\_BIND\_SERVICE}
+possono usare la funzione \func{bind} su queste porte.
+
+Il membro \var{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 \direct{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 \secref{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 un'estensione di IPv4 i socket di tipo \const{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 \file{netinet/in.h}.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
+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}
+ \end{minipage}
+ \caption{La struttura degli indirizzi dei socket IPv6
+ \structd{sockaddr\_in6}.}
+ \label{fig:sock_sa_ipv6_struct}
+\end{figure}
+
+Il campo \var{sin6\_family} deve essere sempre impostato ad
+\const{AF\_INET6}, il campo \var{sin6\_port} è analogo a quello di IPv4 e
+segue le stesse regole; il campo \var{sin6\_flowinfo} è a sua 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 \secref{sec:IP_ipv6head}) ed il loro uso è sperimentale.
+
+Il campo \var{sin6\_addr} contiene l'indirizzo a 128 bit usato da IPv6,
+infine il campo \var{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 \struct{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 \const{PF\_UNIX} o \const{PF\_LOCAL} vengono usati per una
+comunicazione fra processi che stanno sulla stessa macchina (per vengono
+chiamati \textit{local domain} o anche \textit{Unix domain}); essi rispetto ai
+precedenti possono essere anche creati in maniera anonima attraverso la
+funzione \func{socketpair} (vedi \secref{sec:ipc_socketpair}). Quando però si
+vuole fare riferimento esplicito ad uno di questi socket si deve usare la
+seguente struttura di indirizzi definita nel file di header \file{sys/un.h}.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
+#define UNIX_PATH_MAX 108
+struct sockaddr_un {
+ sa_family_t sun_family; /* AF_UNIX */
+ char sun_path[UNIX_PATH_MAX]; /* pathname */
+};
+ \end{lstlisting}
+ \end{minipage}
+ \caption{La struttura degli indirizzi dei socket locali
+ \structd{sockaddr\_un}.}
+ \label{fig:sock_sa_local_struct}
+\end{figure}
+
+In questo caso il campo \var{sun\_family} deve essere \const{AF\_UNIX},
+mentre il campo \var{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 invece \var{sun\_path} inizia con uno zero
+vengono usati i restanti byte come stringa (senza terminazione).
+
+
+% \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} invece ricevono i valori del kernel
+