+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 \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).
+
+
+\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