+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 infatti vengono specificati attraverso apposite strutture che
+vengono utilizzate dalle altre funzioni della interfaccia 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 moderno risolve questo problema coi i puntatori
+generici (i \ctyp{void *}), ma l'interfaccia dei socket è antecedente alla
+definizione dello standard ANSI C, e per questo nel 1982 fu scelto di definire
+una struttura generica per gli indirizzi dei socket, \struct{sockaddr}, che si
+è riportata in fig.~\ref{fig:sock_sa_gen_struct}.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{0.80\textwidth}
+ \includestruct{listati/sockaddr.h}
+ \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 una conversione del relativo puntatore.
+
+I tipi di dati che compongono la struttura sono stabiliti dallo standard
+POSIX.1g e li abbiamo riassunti in tab.~\ref{tab:sock_data_types} con i
+rispettivi file di include in cui sono definiti; la struttura è invece
+definita nell'include file \headfile{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
+ \typed{int8\_t} & intero a 8 bit con segno & \headfile{sys/types.h}\\
+ \typed{uint8\_t} & intero a 8 bit senza segno & \headfile{sys/types.h}\\
+ \typed{int16\_t} & intero a 16 bit con segno & \headfile{sys/types.h}\\
+ \typed{uint16\_t} & intero a 16 bit senza segno& \headfile{sys/types.h}\\
+ \typed{int32\_t} & intero a 32 bit con segno & \headfile{sys/types.h}\\
+ \typed{uint32\_t} & intero a 32 bit senza segno& \headfile{sys/types.h}\\
+ \hline
+ \typed{sa\_family\_t} & famiglia degli indirizzi&\headfile{sys/socket.h}\\
+ \typed{socklen\_t} & lunghezza (\type{uint32\_t}) dell'indirizzo di
+ un socket& \headfile{sys/socket.h}\\
+ \hline
+ \typed{in\_addr\_t} & indirizzo IPv4 (\type{uint32\_t}) &
+ \headfile{netinet/in.h}\\
+ \typed{in\_port\_t} & porta TCP o UDP (\type{uint16\_t})&
+ \headfile{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 in
+\cite{UNP1}). 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}, comune a tutte le famiglie, 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.
+
+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} 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{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
+fig.~\ref{fig:sock_sa_ipv4_struct}, conforme allo standard POSIX.1g.
+
+\begin{figure}[!htb]
+ \footnotesize\centering
+ \begin{minipage}[c]{0.80\textwidth}
+ \includestruct{listati/sockaddr_in.h}
+ \end{minipage}
+ \caption{La struttura \structd{sockaddr\_in} degli indirizzi dei socket
+ Internet (IPv4) e la struttura \structd{in\_addr} degli indirizzi IPv4.}
+ \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 \textsl{numero di porta} (affronteremo in
+dettaglio il significato di questi numeri in sez.~\ref{sec:TCP_port_num}). Il
+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}
+specifica il \textsl{numero di porta}. I numeri di porta sotto il 1024 sono
+chiamati \textsl{riservati} in quanto utilizzati da servizi standard e
+soltanto processi con i privilegi di amministratore (con \ids{UID} effettivo
+uguale a zero) o con la \textit{capability} \const{CAP\_NET\_BIND\_SERVICE}
+possono usare la funzione \func{bind} (che vedremo in
+sez.~\ref{sec:TCP_func_bind}) su queste porte.
+
+Il membro \var{sin\_addr} contiene un indirizzo Internet, e viene acceduto sia
+come struttura (un resto di una implementazione precedente in cui questa era
+una \dirct{union} usata per accedere alle diverse classi di indirizzi) che
+direttamente come intero. In \headfile{netinet/in.h} vengono definite anche
+alcune costanti che identificano alcuni indirizzi speciali, riportati in
+tab.~\ref{tab:TCP_ipv4_addr}, che rincontreremo più avanti.
+
+Infine occorre 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} (vedi
+sez.~\ref{sec:endianness}), questo comporta la necessità di usare apposite
+funzioni di conversione per mantenere la portabilità del codice (vedi
+sez.~\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 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}, è
+riportata in fig.~\ref{fig:sock_sa_ipv6_struct}.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{0.80\textwidth}
+ \includestruct{listati/sockaddr_in6.h}
+ \end{minipage}
+ \caption{La struttura \structd{sockaddr\_in6} degli indirizzi dei socket
+ IPv6 e la struttura \structd{in6\_addr} degli indirizzi IPv6.}
+ \label{fig:sock_sa_ipv6_struct}
+\end{figure}
+
+Il campo \var{sin6\_family} deve essere sempre impostato ad \constd{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 sez.~\ref{sec:IP_ipv6head}) ed
+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; 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{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
+anonima attraverso la funzione \func{socketpair} (che abbiamo trattato in
+sez.~\ref{sec:ipc_socketpair}). Quando però si vuole fare riferimento
+esplicito ad uno di questi socket si deve usare una struttura degli indirizzi
+di tipo \struct{sockaddr\_un}, la cui definizione si è riportata in
+fig.~\ref{fig:sock_sa_local_struct}.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{0.80\textwidth}
+ \includestruct{listati/sockaddr_un.h}
+ \end{minipage}
+ \caption{La struttura \structd{sockaddr\_un} degli indirizzi dei socket
+ locali (detti anche \textit{unix domain}) definita in
+ \headfiled{sys/un.h}.}
+ \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 ``\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{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
+kernel supporta solo due strati del protocollo, DDP e AARP, e di norma è
+opportuno usare le funzioni della libreria \texttt{netatalk}, tratteremo qui
+questo argomento principalmente per mostrare l'uso di un protocollo
+alternativo.
+
+I socket AppleTalk permettono di usare il protocollo DDP, che è un protocollo
+a pacchetto, di tipo \const{SOCK\_DGRAM}; l'argomento \param{protocol} di
+\func{socket} deve essere nullo. È altresì possibile usare i socket raw
+specificando un tipo \const{SOCK\_RAW}, nel qual caso l'unico valore valido
+per \param{protocol} è \constd{ATPROTO\_DDP}.
+
+Gli indirizzi AppleTalk devono essere specificati tramite una struttura
+\struct{sockaddr\_atalk}, la cui definizione è riportata in
+fig.~\ref{fig:sock_sa_atalk_struct}; la struttura viene dichiarata includendo
+il file \headfiled{netatalk/at.h}.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{0.80\textwidth}
+ \includestruct{listati/sockaddr_atalk.h}
+ \end{minipage}
+ \caption{La struttura \structd{sockaddr\_atalk} degli indirizzi dei socket
+ AppleTalk, e la struttura \structd{at\_addr} degli indirizzi AppleTalk.}
+ \label{fig:sock_sa_atalk_struct}
+\end{figure}
+
+Il campo \var{sat\_family} deve essere sempre \constd{AF\_APPLETALK}, mentre
+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.
+
+
+\subsection{La struttura degli indirizzi dei \textit{packet socket}}
+\label{sec:sock_sa_packet}
+
+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 \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
+altre piattaforme, anche se con funzionalità ridotte.
+
+Questi socket possono essere di tipo \const{SOCK\_RAW} o \const{SOCK\_DGRAM}.
+Con socket di tipo \const{SOCK\_RAW} si può operare sul livello di
+collegamento, ed i pacchetti vengono passati direttamente dal socket al driver
+del dispositivo e viceversa. In questo modo, in fase di trasmissione, il
+contenuto completo dei pacchetti, comprese le varie intestazioni, deve essere
+fornito dall'utente. In fase di ricezione invece tutto il contenuto del
+pacchetto viene passato inalterato sul socket, anche se il kernel analizza
+comunque il pacchetto, riempiendo gli opportuni campi della struttura
+\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}.
+
+Nella creazione di un \textit{packet socket} il valore dell'argomento
+\param{protocol} di \func{socket} serve a specificare, in \textit{network
+ order}, il numero identificativo del protocollo di collegamento si vuole
+utilizzare. I valori possibili sono definiti secondo lo standard IEEE 802.3, e
+quelli disponibili in Linux sono accessibili attraverso opportune costanti
+simboliche definite nel file \file{linux/if\_ether.h}. Se si usa il valore
+speciale \constd{ETH\_P\_ALL} passeranno sul \textit{packet socket} tutti i
+pacchetti, qualunque sia il loro protocollo di collegamento. Ovviamente l'uso
+di questi socket è una operazione privilegiata e può essere effettuati solo da
+un processo con i privilegi di amministratore (\ids{UID} effettivo nullo) o
+con la \textit{capability} \const{CAP\_NET\_RAW}.
+
+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} (vedi sez.~\ref{sec:TCP_func_bind}) per
+agganciare il socket a quest'ultima.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{\textwidth}
+ \includestruct{listati/sockaddr_ll.h}
+ \end{minipage}
+ \caption{La struttura \structd{sockaddr\_ll} degli indirizzi dei
+ \textit{packet socket}.}
+ \label{fig:sock_sa_packet_struct}
+\end{figure}
+
+Nel caso dei \textit{packet socket} la struttura degli indirizzi è di tipo
+\struct{sockaddr\_ll}, e la sua definizione è riportata in
+fig.~\ref{fig:sock_sa_packet_struct}; essa però viene ad assumere un ruolo
+leggermente diverso rispetto a quanto visto finora per gli altri tipi di
+socket. Infatti se il socket è di tipo \const{SOCK\_RAW} si deve comunque
+scrivere tutto direttamente nel pacchetto, quindi la struttura non serve più a
+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 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 (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
+relativa lunghezza; ovviamente questi valori cambiano a seconda del tipo di
+collegamento che si usa, ad esempio, nel caso di Ethernet, questi saranno il
+MAC address della scheda e la relativa lunghezza. Essi vengono usati, insieme
+ai campi \var{sll\_family} e \var{sll\_ifindex} quando si inviano dei
+pacchetti, in questo caso tutti gli altri campi devono essere nulli.
+
+Il campo \var{sll\_hatype} indica il tipo ARP, come definito in
+\file{linux/if\_arp.h}, mentre il campo \var{sll\_pkttype} indica il tipo di
+pacchetto; entrambi vengono impostati alla ricezione di un pacchetto ed han
+senso solo in questo caso. In particolare \var{sll\_pkttype} può assumere i
+seguenti valori: \constd{PACKET\_HOST} per un pacchetto indirizzato alla
+macchina ricevente, \constd{PACKET\_BROADCAST} per un pacchetto di
+\textit{broadcast}, \constd{PACKET\_MULTICAST} per un pacchetto inviato ad un
+indirizzo fisico di \textit{multicast}, \constd{PACKET\_OTHERHOST} per un
+pacchetto inviato ad un'altra stazione (e ricevuto su un'interfaccia in modo
+promiscuo), \constd{PACKET\_OUTGOING} per un pacchetto originato dalla propria
+macchina che torna indietro sul socket.
+
+Si tenga presente infine che in fase di ricezione, anche se si richiede il
+troncamento del pacchetto, le funzioni \func{recv}, \func{recvfrom} e
+\func{recvmsg} (vedi sez.~\ref{sec:net_sendmsg}) restituiranno comunque la
+lunghezza effettiva del pacchetto così come arrivato sulla linea.
+
+%% \subsection{La struttura degli indirizzi DECnet}
+%% \label{sec:sock_sa_decnet}
+
+%% 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
+