%% socket.tex
%%
-%% Copyright (C) 2000-2004 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2011 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",
%% license is included in the section entitled "GNU Free Documentation
%% License".
%%
+
\chapter{Introduzione ai socket}
\label{cha:socket_intro}
In questo capitolo inizieremo a spiegare le caratteristiche salienti della
principale interfaccia per la programmazione di rete, quella dei
-\textit{socket}, che, pur essendo nata in ambiente Unix, è usata ormai da
+\textit{socket}, che, pur essendo nata in ambiente Unix, è usata ormai da
tutti i sistemi operativi.
Dopo una breve panoramica sulle caratteristiche di questa interfaccia vedremo
come creare un socket e come collegarlo allo specifico protocollo di rete che
-si utilizzerà per la comunicazione. Per evitare un'introduzione puramente
+si utilizzerà per la comunicazione. Per evitare un'introduzione puramente
teorica concluderemo il capitolo con un primo esempio di applicazione.
\section{Una panoramica}
Iniziamo con una descrizione essenziale di cosa sono i \textit{socket} e di
quali sono i concetti fondamentali da tenere presente quando si ha a che fare
con essi.
-\index{socket|(}
+\index{socket!definizione|(}
\subsection{I \textit{socket}}
\label{sec:sock_socket_def}
\textsl{presa}, ma essendo universalmente noti come \textit{socket}
utilizzeremo sempre la parola inglese.} sono uno dei principali meccanismi
di comunicazione utilizzato in ambito Unix, e li abbiamo brevemente incontrati
-in sez.~\ref{sec:ipc_socketpair}, fra i vari meccanismi di intercominazione
+in sez.~\ref{sec:ipc_socketpair}, fra i vari meccanismi di intercomunicazione
fra processi. Un socket costituisce in sostanza un canale di comunicazione fra
due processi su cui si possono leggere e scrivere dati analogo a quello di una
pipe (vedi sez.~\ref{sec:ipc_pipes}) ma, a differenza di questa e degli altri
Quella dei socket costituisce infatti la principale interfaccia usata nella
programmazione di rete. La loro origine risale al 1983, quando furono
-introdotti in BSD 4.2; l'interfaccia è rimasta sostanzialmente la stessa, con
-piccole modifiche, negli anni successivi. Benché siano state sviluppate
+introdotti in BSD 4.2; l'interfaccia è rimasta sostanzialmente la stessa, con
+piccole modifiche, negli anni successivi. Benché siano state sviluppate
interfacce alternative, originate dai sistemi SVr4 come la XTI (\textit{X/Open
- Transport Interface}) nessuna ha mai raggiunto la diffusione e la popolarità
-di quella dei socket (né tantomeno la stessa usabilità e flessibilità).
+ Transport Interface}) nessuna ha mai raggiunto la diffusione e la popolarità
+di quella dei socket (né tantomeno la stessa usabilità e flessibilità).
-La flessibilità e la genericità dell'interfaccia inoltre consente di
-utilizzare i socket con i più disparati meccanismi di comunicazione, e non
-solo con l'insieme dei protocolli TCP/IP, anche se questa sarà comunque quella
-di cui tratteremo in maniera più estesa.
+La flessibilità e la genericità dell'interfaccia inoltre consente di
+utilizzare i socket con i più disparati meccanismi di comunicazione, e non
+solo con l'insieme dei protocolli TCP/IP, anche se questa sarà comunque quella
+di cui tratteremo in maniera più estesa.
\subsection{Concetti base}
\label{sec:sock_gen}
Per capire il funzionamento dei socket occorre avere presente il funzionamento
-dei protocolli di rete (vedi cap.~\ref{cha:network}), ma l'interfaccia è del
-tutto generale e benché le problematiche (e quindi le modalità di risolvere i
+dei protocolli di rete (vedi cap.~\ref{cha:network}), ma l'interfaccia è del
+tutto generale e benché le problematiche (e quindi le modalità di risolvere i
problemi) siano diverse a seconda del tipo di protocollo di comunicazione
usato, le funzioni da usare restano le stesse.
-Per questo motivo una semplice descrizione dell'interfaccia è assolutamente
+Per questo motivo una semplice descrizione dell'interfaccia è assolutamente
inutile, in quanto il comportamento di quest'ultima e le problematiche da
affrontare cambiano radicalmente a seconda dello \textsl{stile} di
comunicazione usato. La scelta di questo stile va infatti ad incidere sulla
-semantica che verrà utilizzata a livello utente per gestire la comunicazione
+semantica che verrà utilizzata a livello utente per gestire la comunicazione
(su come inviare e ricevere i dati) e sul comportamento effettivo delle
funzioni utilizzate.
altri invece li raggruppano in \textsl{pacchetti} (in inglese
\textit{datagram}) che vengono inviati in blocchi separati.
-Un'altro esempio di stile concerne la possibilità che la comunicazione possa o
+Un altro esempio di stile concerne la possibilità che la comunicazione possa o
meno perdere dati, possa o meno non rispettare l'ordine in cui essi non sono
-inviati, o inviare dei pacchetti più volte (come nel caso di TCP e UDP).
+inviati, o inviare dei pacchetti più volte (come nel caso di TCP e UDP).
-Un terzo esempio di stile di comunicazione concerne le modalità in cui essa
-avviene, in certi casi essa può essere condotta con una connessione diretta
+Un terzo esempio di stile di comunicazione concerne le modalità in cui essa
+avviene, in certi casi essa può essere condotta con una connessione diretta
con un solo corrispondente, come per una telefonata; altri casi possono
prevedere una comunicazione come per lettera, in cui si scrive l'indirizzo su
-ogni pacchetto, altri ancora una comunicazione \textit{broadcast} come per la
-radio, in cui i pacchetti vengono emessi su appositi ``\textsl{canali}'' dove
-chiunque si collega possa riceverli.
+ogni pacchetto, altri ancora una comunicazione \itindex{broadcast}
+\textit{broadcast} come per la radio, in cui i pacchetti vengono emessi su
+appositi ``\textsl{canali}'' dove chiunque si collega possa riceverli.
-É chiaro che ciascuno di questi stili comporta una modalità diversa di gestire
-la comunicazione, ad esempio se è inaffidabile occorrerà essere in grado di
-gestire la perdita o il rimescolamento dei dati, se è a pacchetti questi
+É chiaro che ciascuno di questi stili comporta una modalità diversa di gestire
+la comunicazione, ad esempio se è inaffidabile occorrerà essere in grado di
+gestire la perdita o il rimescolamento dei dati, se è a pacchetti questi
dovranno essere opportunamente trattati, ecc.
-\section{La creazione di un \textit{socket}}
+\section{La creazione di un socket}
\label{sec:sock_creation}
-Come accennato l'interfaccia dei socket è estremamente flessibile e permette
+Come accennato l'interfaccia dei socket è estremamente flessibile e permette
di interagire con protocolli di comunicazione anche molto diversi fra di loro;
-in questa sezione vedremo come è possibile creare un socket e come specificare
+in questa sezione vedremo come è possibile creare un socket e come specificare
il tipo di comunicazione che esso deve utilizzare.
\subsection{La funzione \func{socket}}
\funcd{socket}; essa restituisce un \textit{file descriptor}\footnote{del
tutto analogo a quelli che si ottengono per i file di dati e le pipe,
descritti in sez.~\ref{sec:file_fd}.} che serve come riferimento al socket;
-il suo prototipo è:
+il suo prototipo è:
\begin{prototype}{sys/socket.h}{int socket(int domain, int type, int protocol)}
Apre un socket.
\bodydesc{La funzione restituisce un intero positivo in caso di successo, e
- -1 in caso di fallimento, nel qual caso la variabile \var{errno} assumerà
+ -1 in caso di fallimento, nel qual caso la variabile \var{errno} assumerà
i valori:
\begin{errlist}
- \item[\errcode{EPROTONOSUPPORT}] Il tipo di socket o il protocollo scelto non
- sono supportati nel dominio.
- \item[\errcode{ENFILE}] Il kernel non ha memoria sufficiente a creare una
+ \item[\errcode{EPROTONOSUPPORT}] il tipo di socket o il protocollo scelto
+ non sono supportati nel dominio.
+ \item[\errcode{ENFILE}] il kernel non ha memoria sufficiente a creare una
nuova struttura per il socket.
- \item[\errcode{EMFILE}] Si è ecceduta la tabella dei file.
- \item[\errcode{EACCES}] Non si hanno privilegi per creare un socket nel
+ \item[\errcode{EMFILE}] si è ecceduta la tabella dei file.
+ \item[\errcode{EACCES}] non si hanno privilegi per creare un socket nel
dominio o con il protocollo specificato.
- \item[\errcode{EINVAL}] Protocollo sconosciuto o dominio non disponibile.
- \item[\errcode{ENOBUFS}] Non c'è sufficiente memoria per creare il socket
- (può essere anche \errval{ENOMEM}).
+ \item[\errcode{EINVAL}] protocollo sconosciuto o dominio non disponibile.
+ \item[\errcode{ENOBUFS}] non c'è sufficiente memoria per creare il socket
+ (può essere anche \errval{ENOMEM}).
\end{errlist}
inoltre, a seconda del protocollo usato, potranno essere generati altri
errori, che sono riportati nelle relative pagine di manuale.}
\end{prototype}
La funzione ha tre argomenti, \param{domain} specifica il dominio del socket
-(definisce cioè, come vedremo in sez.~\ref{sec:sock_domain}, la famiglia di
-protocolli usata), \param{type} specifica il tipo di socket (definisce cioè,
+(definisce cioè, come vedremo in sez.~\ref{sec:sock_domain}, la famiglia di
+protocolli usata), \param{type} specifica il tipo di socket (definisce cioè,
come vedremo in sez.~\ref{sec:sock_type}, lo stile di comunicazione) e
-\param{protocol} il protocollo; in genere quest'ultimo è indicato
+\param{protocol} il protocollo; in genere quest'ultimo è indicato
implicitamente dal tipo di socket, per cui di norma questo valore viene messo
a zero (con l'eccezione dei \textit{raw socket}).
Si noti che la creazione del socket si limita ad allocare le opportune
-strutture nel kernel (sostanzialmente una voce nella \textit{file table}) e
-non comporta nulla riguardo all'indicazione degli indirizzi remoti o locali
-attraverso i quali si vuole effettuare la comunicazione.
+strutture nel kernel (sostanzialmente una voce nella \itindex{file~table}
+\textit{file table}) e non comporta nulla riguardo all'indicazione degli
+indirizzi remoti o locali attraverso i quali si vuole effettuare la
+comunicazione.
-\subsection{Il dominio, o \textit{protocol family}}
+\subsection{Il dominio dei socket}
\label{sec:sock_domain}
Dati i tanti e diversi protocolli di comunicazione disponibili, esistono vari
chiamano \textsl{domini}. La scelta di un dominio equivale in sostanza alla
scelta di una famiglia di protocolli, e viene effettuata attraverso
l'argomento \param{domain} della funzione \func{socket}. Ciascun dominio ha un
-suo nome simbolico che convenzionalmente inizia con una costante che inizia
-per \texttt{PF\_}, iniziali di \textit{protocol family}, un altro nome con cui
-si indicano i domini.
+suo nome simbolico che convenzionalmente è indicato da una costante che inizia
+per \texttt{PF\_}, sigla che sta per \textit{protocol family}, altro nome con
+cui si indicano i domini.
A ciascun tipo di dominio corrisponde un analogo nome simbolico, anch'esso
associato ad una costante, che inizia invece per \texttt{AF\_} (da
\hline
\const{PF\_UNSPEC} & 0& Non specificato & \\
\const{PF\_LOCAL} & 1& Local communication & unix(7) \\
- \const{PF\_UNIX}, \const{PF\_FILE}&1& & \\
+ \const{PF\_UNIX}, \const{PF\_FILE}&1&Sinonimi di \const{PF\_LOCAL}& \\
\const{PF\_INET} & 2& IPv4 Internet protocols & ip(7) \\
\const{PF\_AX25} & 3& Amateur radio AX.25 protocol & \\
\const{PF\_IPX} & 4& IPX - Novell protocols & \\
\const{PF\_SECURITY} &14& Security callback pseudo AF & \\
\const{PF\_KEY} &15& PF\_KEY key management API & \\
\const{PF\_NETLINK} &16& Kernel user interface device & netlink(7) \\
+ \const{PF\_ROUTE} &16& Sinonimo di \const{PF\_NETLINK} emula BSD.&\\
\const{PF\_PACKET} &17& Low level packet interface & packet(7) \\
\const{PF\_ASH} &18& Ash & \\
\const{PF\_ECONET} &19& Acorn Econet & \\
\const{PF\_ATMSVC} &20& ATM SVCs & \\
\const{PF\_SNA} &22& Linux SNA Project & \\
- \const{PF\_IRDA} &23& IRDA sockets & \\
- \const{PF\_PPPOX} &24& PPPoX sockets & \\
- \const{PF\_WANPIPE} &25& Wanpipe API sockets & \\
- \const{PF\_BLUETOOTH}&31& Bluetooth sockets & \\
+ \const{PF\_IRDA} &23& IRDA socket & \\
+ \const{PF\_PPPOX} &24& PPPoX socket & \\
+ \const{PF\_WANPIPE} &25& Wanpipe API socket & \\
+ \const{PF\_LLC} &26& Linux LLC & \\
+ \const{PF\_BLUETOOTH}&31& Bluetooth socket & \\
\hline
\end{tabular}
- \caption{Famiglie di protocolli definiti in Linux.}
+ \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
-il prefisso \texttt{AF\_} in quello delle strutture degli indirizzi; questo è
+il prefisso \texttt{AF\_} in quello delle strutture degli indirizzi; questo è
quanto specificato anche 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 numerici.\footnote{in Linux, come si può verificare andando a guardare
+valori numerici.\footnote{in Linux, come si può verificare andando a guardare
il contenuto di \file{bits/socket.h}, le costanti sono esattamente le stesse
- e ciascuna \texttt{AF\_} è definita alla corrispondente \texttt{PF\_} e con
+ e ciascuna \texttt{AF\_} è definita alla corrispondente \texttt{PF\_} e con
lo stesso nome.}
-I domini (e i relativi nomi simbolici), così come i nomi delle famiglie di
+I domini (e i relativi nomi simbolici), così come i nomi delle famiglie di
indirizzi, sono definiti dall'header \texttt{socket.h}. Un elenco delle
-famiglie di protocolli disponibili in Linux è riportato in
+famiglie di protocolli disponibili in Linux è riportato in
tab.~\ref{tab:net_pf_names}.\footnote{l'elenco indica tutti i protocolli
- definiti; fra questi però saranno utilizzabili solo quelli per i quali si è
+ 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 \const{PF\_MAX} che indica il valore
massimo associabile ad un dominio (nel caso il suo valore 32).}
Si tenga presente che non tutte le famiglie di protocolli sono utilizzabili
dall'utente generico, ad esempio in generale tutti i socket di tipo
\const{SOCK\_RAW} possono essere creati solo da processi che hanno i privilegi
-di amministratore (cioè con user-ID effettivo uguale a zero) o dotati della
-capability \texttt{CAP\_NET\_RAW}.
+di amministratore (cioè con user-ID effettivo uguale a zero) o dotati della
+\itindex{capabilities} \textit{capability} \const{CAP\_NET\_RAW}.
-\subsection{Il tipo, o stile}
+\subsection{Il tipo di socket}
\label{sec:sock_type}
-La scelta di un dominio non comporta però la scelta dello stile di
-comunicazione, questo infatti viene a dipendere dal protocollo che si andrà ad
+La scelta di un dominio non comporta però la scelta dello stile di
+comunicazione, questo infatti viene a dipendere dal protocollo che si andrà ad
utilizzare fra quelli disponibili nella famiglia scelta. L'interfaccia dei
socket permette di scegliere lo stile di comunicazione indicando il tipo di
socket con l'argomento \param{type} di \func{socket}. Linux mette a
disposizione vari tipi di socket (che corrispondono a quelli che il manuale
della \acr{glibc} \cite{glibc} chiama \textit{styles}) identificati dalle
-seguenti costanti:
+seguenti costanti:\footnote{le pagine di manuale POSIX riportano solo i primi
+ 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{2.9cm}\desclabelstyle{\nextlinelabel}}
\item[\const{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
- byte (da cui il nome \textit{stream}).
+ byte (da cui il nome \textit{stream}) e possono essere letti in blocchi di
+ dimensioni qualunque. Può supportare la trasmissione dei cosiddetti dati
+ urgenti (o \itindex{out-of-band} \textit{out-of-band}, vedi
+ sez.~\ref{sec:TCP_urgent_data}).
\item[\const{SOCK\_DGRAM}] Viene usato per trasmettere pacchetti di dati
(\textit{datagram}) di lunghezza massima prefissata, indirizzati
- singolarmente. Non esiste una connessione e la trasmissione è effettuata in
+ singolarmente. Non esiste una connessione e la trasmissione è effettuata in
maniera non affidabile.
\item[\const{SOCK\_SEQPACKET}] Provvede un canale di trasmissione di dati
bidirezionale, sequenziale e affidabile. Opera su una connessione con un
altro socket. I dati possono vengono trasmessi per pacchetti di dimensione
- massima fissata, ed devono essere letti integralmente da ciascuna
- chiamata a \func{read}.
+ massima fissata, e devono essere letti integralmente da ciascuna chiamata a
+ \func{read}.
\item[\const{SOCK\_RAW}] Provvede l'accesso a basso livello ai protocolli di
rete e alle varie interfacce. I normali programmi di comunicazione non
- devono usarlo, è riservato all'uso di sistema.
+ devono usarlo, è riservato all'uso di sistema.
\item[\const{SOCK\_RDM}] Provvede un canale di trasmissione di dati
- affidabile, ma in cui non è garantito l'ordine di arrivo dei pacchetti.
-\item[\const{SOCK\_PACKET}] Obsoleto, non deve essere usato.
+ affidabile, ma in cui non è garantito l'ordine di arrivo dei pacchetti.
+\item[\const{SOCK\_PACKET}] Obsoleto, non deve essere più usato.\footnote{e
+ pertanto non ne parleremo ulteriormente.}
\end{basedescript}
Si tenga presente 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
+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 appena
elencati.
\hline
\hline
&\const{SOCK\_STREAM} &\const{SOCK\_DGRAM} &\const{SOCK\_RAW}&
- \const{SOCK\_PACKET}&\const{SOCK\_SEQPACKET} \\
+ \const{SOCK\_RDM}&\const{SOCK\_SEQPACKET} \\
\hline
- \const{PF\_UNIX} & si & si & & & \\
+ \const{PF\_LOCAL} & si & si & & & \\
\hline
+% \const{PF\_UNIX}&\multicolumn{5}{|l|}{sinonimo di \const{PF\_LOCAL}.}\\
+% \hline
\const{PF\_INET} & TCP & UDP & IPv4 & & \\
\hline
\const{PF\_INET6} & TCP & UDP & IPv6 & & \\
In tab.~\ref{tab:sock_sock_valid_combinations} sono mostrate le combinazioni
valide possibili per le principali famiglie di protocolli. Per ogni
-combinazione valida si è indicato il tipo di protocollo, o la parola
+combinazione valida si è indicato il tipo di protocollo, o la parola
\textsl{si} qualora non il protocollo non abbia un nome definito, mentre si
sono lasciate vuote le caselle per le combinazioni non supportate.
\section{Le strutture degli indirizzi dei socket}
\label{sec:sock_sockaddr}
-Come si è visto nella creazione di un socket non si specifica nulla oltre al
+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
\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
+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
+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}.
+è riportata in fig.~\ref{fig:sock_sa_gen_struct}.
\begin{figure}[!htb]
\footnotesize \centering
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.
+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
+rispettivi file di include in cui sono definiti; la struttura è invece
definita nell'include file \file{sys/socket.h}.
\begin{table}[!htb]
\label{tab:sock_data_types}
\end{table}
-In alcuni sistemi la struttura è leggermente diversa e prevede un primo membro
+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
+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
+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.
+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}
I socket di tipo \const{PF\_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
+si usa IPv4) è definita come \struct{sockaddr\_in} nell'header file
\file{netinet/in.h} ed ha la forma mostrata in
fig.~\ref{fig:sock_sa_ipv4_struct}, conforme allo standard POSIX.1g.
\begin{minipage}[c]{15cm}
\includestruct{listati/sockaddr_in.h}
\end{minipage}
- \caption{La struttura degli indirizzi dei socket internet (IPv4)
- \structd{sockaddr\_in}.}
+ \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
+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
+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 a \const{AF\_INET},
-altrimenti si avrà un errore di \errcode{EINVAL}; il membro \var{sin\_port}
+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 user-ID effettivo
-uguale a zero) o con la capability \texttt{CAP\_NET\_BIND\_SERVICE} possono
-usare la funzione \func{bind} (che vedremo in sez.~\ref{sec:TCP_func_bind}) su
-queste porte.
+uguale a zero) o con la \itindex{capabilities} \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 \direct{union} usata per accedere alle diverse classi di indirizzi) che
direttamente come intero. In \file{netinet/in.h} vengono definite anche alcune
costanti che identificano alcuni indirizzi speciali, riportati in
-tab.~\ref{tab:TCP_ipv4_addr}, che reincontreremo più avanti.
+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è
+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 sez.~\ref{sec:sock_addr_func} per i dettagli del
+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).
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 fra i due socket è quella della struttura
-degli indirizzi; la sua definizione, presa da \file{netinet/in.h}, è riportata
+praticamente tutte le differenze fra i due socket è quella della struttura
+degli indirizzi; la sua definizione, presa da \file{netinet/in.h}, è riportata
in fig.~\ref{fig:sock_sa_ipv6_struct}.
\begin{figure}[!htb]
\begin{minipage}[c]{15cm}
\includestruct{listati/sockaddr_in6.h}
\end{minipage}
- \caption{La struttura degli indirizzi dei socket IPv6
- \structd{sockaddr\_in6}.}
+ \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 \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
+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 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
+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 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.
+riguardanti il \itindex{multicast} \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.
\subsection{La struttura degli indirizzi locali}
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
+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
+di tipo \struct{sockaddr\_un}, la cui definizione si è riportata in
fig.~\ref{fig:sock_sa_local_struct}.
\begin{figure}[!htb]
\begin{minipage}[c]{15cm}
\includestruct{listati/sockaddr_un.h}
\end{minipage}
- \caption{La struttura degli indirizzi dei socket locali (detti anche
- \textit{unix domain}) \structd{sockaddr\_un} definita in \file{sys/un.h}.}
+ \caption{La struttura \structd{sockaddr\_un} degli indirizzi dei socket
+ locali (detti anche \textit{unix domain}) definita in \file{sys/un.h}.}
\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;
-può essere un file (di tipo socket) nel filesystem o una stringa univoca
+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
-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.
+\itindex{pathname} \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.
\subsection{La struttura degli indirizzi AppleTalk}
\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 è
+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
+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
+\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} è \func{ATPROTO\_DDP}.
+per \param{protocol} è \const{ATPROTO\_DDP}.
Gli indirizzi AppleTalk devono essere specificati tramite una struttura
-\struct{sockaddr\_atalk}, la cui definizione è riportata in
+\struct{sockaddr\_atalk}, la cui definizione è riportata in
fig.~\ref{fig:sock_sa_atalk_struct}; la struttura viene dichiarata includendo
il file \file{netatalk/at.h}.
\begin{minipage}[c]{15cm}
\includestruct{listati/sockaddr_atalk.h}
\end{minipage}
- \caption{La struttura degli indirizzi dei socket AppleTalk
- \structd{sockaddr\_atalk}.}
+ \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 \const{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 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:sock_endianess}); esso è composto da un parte di rete data dal
-campo \var{s\_net}, che può assumere il valore \const{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
-\const{AT\_ANYNODE} che indica anche il nodo corrente, ed il valore
-\const{ATADDR\_BCAST} che indica tutti i nodi della rete.
+usati solo da processi con i privilegi di amministratore o con la
+\itindex{capabilities} \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:sock_endianess}); esso è
+composto da un parte di rete data dal campo \var{s\_net}, che può assumere il
+valore \const{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 \const{AT\_ANYNODE} che indica anche il nodo
+corrente, ed il valore \const{ATADDR\_BCAST} che indica tutti i nodi della
+rete.
\subsection{La struttura degli indirizzi dei \textit{packet socket}}
I \textit{packet socket}, identificati dal dominio \const{PF\_PACKET}, sono
un'interfaccia specifica di Linux per inviare e ricevere pacchetti
-direttamente su un'interfaccia di rete, senza passare per le routine di
-gestione dei protocolli di livello superiore. In questo modo è possibile
+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 \file{pcap}, che
-assicura la portabilità su altre piattaforme, anche se con funzionalità
+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 \href{http://www.tcpdump.org/}{\textsf{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
+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
simboliche definite nel file \file{linux/if\_ether.h}. Se si usa il valore
speciale \const{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
+di questi socket è una operazione privilegiata e può essere effettuati solo da
un processo con i privilegi di amministratore (user-ID effettivo nullo) o con
-la capability \const{CAP\_NET\_RAW}.
+la \itindex{capabilities} \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
\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
+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
+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
Al solito il campo \var{sll\_family} deve essere sempre impostato al valore
\const{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
+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
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: \var{PACKET\_HOST} per un pacchetto indirizzato alla macchina
-ricevente, \var{PACKET\_BROADCAST} per un pacchetto di broadcast,
-\var{PACKET\_MULTICAST} per un pacchetto inviato ad un indirizzo fisico di
-multicast, \var{PACKET\_OTHERHOST} per un pacchetto inviato ad un'altra
-stazione (e ricevuto su un'interfaccia in modo promiscuo),
-\var{PACKET\_OUTGOING} per un pacchetto originato dalla propria macchina che
-torna indietro sul socket.
+senso solo in questo caso. In particolare \var{sll\_pkttype} può assumere i
+seguenti valori: \const{PACKET\_HOST} per un pacchetto indirizzato alla
+macchina ricevente, \const{PACKET\_BROADCAST} per un pacchetto di
+\itindex{broadcast} \textit{broadcast}, \const{PACKET\_MULTICAST} per un
+pacchetto inviato ad un indirizzo fisico di \itindex{multicast}
+\textit{multicast}, \const{PACKET\_OTHERHOST} per un pacchetto inviato ad
+un'altra stazione (e ricevuto su un'interfaccia in \index{modo~promiscuo} modo
+promiscuo), \const{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{recvmsg}, \func{recv} e
-\func{recvfrom} restituiranno comunque la lunghezza effettiva del pacchetto
-così come arrivato sulla linea.
+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{PF\_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
+%% 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
-
-% \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
+% TODO: trattare i socket RDS, vedi documentazione del kernel, file
+% Documentation/networking/rds.txt
\label{sec:sock_addr_func}
In questa sezione tratteremo delle varie funzioni usate per manipolare gli
-indirizzi, limitandoci però agli indirizzi internet. Come accennato gli
+indirizzi, limitandoci però agli indirizzi internet. Come accennato gli
indirizzi e i numeri di porta usati nella rete devono essere forniti in
formato opportuno (il \textit{network order}). Per capire cosa significa tutto
-ciò occorre introdurre un concetto generale che tornerà utile anche in
+ciò occorre introdurre un concetto generale che tornerà utile anche in
seguito.
-\subsection{La \textit{endianess}\index{endianess}}
+\subsection{La \textit{endianess}}
\label{sec:sock_endianess}
-La rappresentazione di un numero binario in un computer può essere fatta in
+\itindbeg{endianess}
+La rappresentazione di un numero binario in un computer può essere fatta in
due modi, chiamati rispettivamente \textit{big endian} e \textit{little
endian} a seconda di come i singoli bit vengono aggregati per formare le
variabili intere (ed in genere in diretta corrispondenza a come sono poi in
-realtà cablati sui bus interni del computer).
-
-Per capire meglio il problema si consideri un intero a 32 bit scritto in una
-locazione di memoria posta ad un certo indirizzo. Come illustrato in
-fig.~\ref{fig:sock_endianess} i singoli bit possono essere disposti un memoria
-in due modi: a partire dal più significativo o a partire dal meno
-significativo. Così nel primo caso si troverà il byte che contiene i bit più
-significativi all'indirizzo menzionato e il byte con i bit meno significativi
-nell'indirizzo successivo; questo ordinamento è detto \textit{big endian},
-dato che si trova per prima la parte più grande. Il caso opposto, in cui si
-parte dal bit meno significativo è detto per lo stesso motivo \textit{little
- endian}.
+realtà cablati sui bus interni del computer).
\begin{figure}[htb]
\centering
\includegraphics[height=3cm]{img/endianess}
\caption{Schema della disposizione dei dati in memoria a seconda della
- \textit{endianess}\index{endianess}.}
+ \textit{endianess}.}
\label{fig:sock_endianess}
\end{figure}
-Si può allora verificare quale tipo di endianess usa il proprio computer con
-un programma elementare che si limita ad assegnare un valore ad una variabile
-per poi ristamparne il contenuto leggendolo un byte alla volta. Il codice di
-detto programma, \file{endtest.c}, è nei sorgenti allegati, allora se lo
-eseguiamo su un PC otterremo:
+Per capire meglio il problema si consideri un intero a 32 bit scritto in una
+locazione di memoria posta ad un certo indirizzo. Come illustrato in
+fig.~\ref{fig:sock_endianess} i singoli bit possono essere disposti in memoria
+in due modi: a partire dal più significativo o a partire dal meno
+significativo. Così nel primo caso si troverà il byte che contiene i bit più
+significativi all'indirizzo menzionato e il byte con i bit meno significativi
+nell'indirizzo successivo; questo ordinamento è detto \textit{big endian},
+dato che si trova per prima la parte più grande. Il caso opposto, in cui si
+parte dal bit meno significativo è detto per lo stesso motivo \textit{little
+ endian}.
+
+Si può allora verificare quale tipo di \textit{endianess} usa il proprio
+computer con un programma elementare che si limita ad assegnare un valore ad
+una variabile per poi ristamparne il contenuto leggendolo un byte alla volta.
+Il codice di detto programma, \file{endtest.c}, è nei sorgenti allegati,
+allora se lo eseguiamo su un PC otterremo:
\begin{verbatim}
[piccardi@gont sources]$ ./endtest
Using value ABCDEF01
\end{verbatim}%$
-La \textit{endianess}\index{endianess} di un computer dipende essenzialmente
-dalla architettura hardware usata; Intel e Digital usano il \textit{little
- endian}, Motorola, IBM, Sun (sostanzialmente tutti gli altri) usano il
-\textit{big endian}. Il formato dei dati contenuti nelle intestazioni dei
-protocolli di rete è anch'esso \textit{big endian}; altri esempi di uso di
-questi due diversi formati sono quello del bus PCI, che è \textit{little
- endian}, o quello del bus VME che è \textit{big endian}.
+La \textit{endianess} di un computer dipende essenzialmente dalla architettura
+hardware usata; Intel e Digital usano il \textit{little endian}, Motorola,
+IBM, Sun (sostanzialmente tutti gli altri) usano il \textit{big endian}. Il
+formato dei dati contenuti nelle intestazioni dei protocolli di rete è
+anch'esso \textit{big endian}; altri esempi di uso di questi due diversi
+formati sono quello del bus PCI, che è \textit{little endian}, o quello del
+bus VME che è \textit{big endian}.
Esistono poi anche dei processori che possono scegliere il tipo di formato
all'avvio e alcuni che, come il PowerPC o l'Intel i860, possono pure passare
da un tipo di ordinamento all'altro con una specifica istruzione. In ogni caso
-in Linux l'ordinamento è definito dall'architettura e dopo l'avvio del sistema
+in Linux l'ordinamento è definito dall'architettura e dopo l'avvio del sistema
resta sempre lo stesso, anche quando il processore permetterebbe di eseguire
questi cambiamenti.
-Per controllare quale tipo di ordinamento si ha sul proprio computer si è
-scritta una piccola funzione di controllo, il cui codice è riportato
-fig.~\ref{fig:sock_endian_code}, che restituisce un valore nullo (falso) se
-l'architettura è \textit{big endian} ed uno non nullo (vero) se l'architettura
-è \textit{little endian}.
-
\begin{figure}[htb]
\footnotesize \centering
\begin{minipage}[c]{15cm}
\label{fig:sock_endian_code}
\end{figure}
-Come si vede la funzione è molto semplice, e si limita, una volta assegnato
+Per controllare quale tipo di ordinamento si ha sul proprio computer si è
+scritta una piccola funzione di controllo, il cui codice è riportato
+fig.~\ref{fig:sock_endian_code}, che restituisce un valore nullo (falso) se
+l'architettura è \textit{big endian} ed uno non nullo (vero) se l'architettura
+è \textit{little endian}.
+
+Come si vede la funzione è molto semplice, e si limita, una volta assegnato
(\texttt{\small 9}) un valore di test pari a \texttt{0xABCD} ad una variabile
-di tipo \ctyp{short} (cioè a 16 bit), a ricostruirne una copia byte a byte.
+di tipo \ctyp{short} (cioè a 16 bit), a ricostruirne una copia byte a byte.
Per questo prima (\texttt{\small 10}) si definisce il puntatore \var{ptr} per
accedere al contenuto della prima variabile, ed infine calcola (\texttt{\small
11}) il valore della seconda assumendo che il primo byte sia quello meno
-significativo (cioè, per quanto visto in fig.~\ref{fig:sock_endianess}, che sia
+significativo (cioè, per quanto visto in fig.~\ref{fig:sock_endianess}, che sia
\textit{little endian}). Infine la funzione restituisce (\texttt{\small 12})
-il valore del confonto delle due variabili.
-
+il valore del confronto delle due variabili.
+\itindend{endianess}
\subsection{Le funzioni per il riordinamento}
\label{sec:sock_func_ord}
-Il problema connesso all'endianess\index{endianess} è che quando si passano
+Il problema connesso \itindex{endianess} all'endianess è che quando si passano
dei dati da un tipo di architettura all'altra i dati vengono interpretati in
-maniera diversa, e ad esempio nel caso dell'intero a 16 bit ci si ritroverà
-con i due byte in cui è suddiviso scambiati di posto. Per questo motivo si
+maniera diversa, e ad esempio nel caso dell'intero a 16 bit ci si ritroverà
+con i due byte in cui è suddiviso scambiati di posto. Per questo motivo si
usano delle funzioni di conversione che servono a tener conto automaticamente
della possibile differenza fra l'ordinamento usato sul computer e quello che
viene usato nelle trasmissione sulla rete; queste funzioni sono \funcd{htonl},
macchina che si sta usando abbia una architettura \textit{big endian} queste
funzioni sono definite come macro che non fanno nulla. Per questo motivo vanno
sempre utilizzate, anche quando potrebbero non essere necessarie, in modo da
-assicurare la portabilità del codice su tutte le architetture.
+assicurare la portabilità del codice su tutte le architetture.
\subsection{Le funzioni \func{inet\_aton}, \func{inet\_addr} e
dei numeri IP che si usa normalmente.
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
+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},
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
+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
+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 0 in caso di successo e 1
in caso di fallimento. Se usata con \param{dest} inizializzato a \val{NULL}
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.
+funzione non è \index{funzioni!rientranti} rientrante.
\subsection{Le funzioni \func{inet\_pton} e \func{inet\_ntop}}
\label{sec:sock_conv_func_gen}
Le tre funzioni precedenti sono limitate solo ad indirizzi IPv4, per questo
-motivo è preferibile usare le due nuove funzioni \func{inet\_pton} e
+motivo è preferibile usare le due nuove funzioni \func{inet\_pton} e
\func{inet\_ntop} che possono convertire anche gli indirizzi IPv6. Anche in
questo caso le lettere \texttt{n} e \texttt{p} sono degli mnemonici per
ricordare il tipo di conversione effettuata e stanno per \textit{presentation}
e \textit{numeric}.
-% \begin{figure}[htb]
-% \centering
-
-% \caption{Schema della rappresentazioni utilizzate dalle funzioni di
-% conversione \texttt{inet\_pton} e \texttt{inet\_ntop} }
-% \label{fig:sock_inet_conv_func}
-
-% \end{figure}
-
Entrambe le funzioni accettano l'argomento \param{af} che indica il tipo di
-indirizzo, e che può essere soltanto \const{AF\_INET} o \const{AF\_INET6}. La
+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 è:
+indirizzo; il suo prototipo è:
\begin{prototype}{sys/socket.h}
{int inet\_pton(int af, const char *src, void *addr\_ptr)}
rappresenta un indirizzo valido, e negativo se \param{af} specifica una
famiglia di indirizzi non valida.
-La seconda funzione di conversione è \funcd{inet\_ntop} che converte un
-indirizzo in una stringa; il suo prototipo è:
+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.
\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 è
+ \item[\errcode{ENOAFSUPPORT}] la famiglia di indirizzi \param{af} non è
una valida.
\end{errlist}}
\end{prototype}
(una struttura \struct{in\_addr} per IPv4, e una struttura \struct{in6\_addr}
per IPv6), che devono essere precedentemente allocate e passate attraverso il
puntatore \param{addr\_ptr}; l'argomento \param{dest} di \func{inet\_ntop} non
-può essere nullo e deve essere allocato precedentemente.
+può essere nullo e deve essere allocato precedentemente.
-Il formato usato per gli indirizzi in formato di presentazione è la notazione
+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.
-\index{socket|)}
+\index{socket!definizione|)}
+
+
+
+
+
+
+% LocalWords: socket sez cap BSD SVr XTI Transport Interface TCP stream UDP PF
+% LocalWords: datagram broadcast descriptor sys int domain type protocol errno
+% LocalWords: EPROTONOSUPPORT ENFILE kernel EMFILE EACCES EINVAL ENOBUFS raw
+% LocalWords: ENOMEM table family AF address name glibc UNSPEC LOCAL Local IPv
+% LocalWords: communication INET protocols ip AX Amateur IPX Novell APPLETALK
+% LocalWords: Appletalk ddp NETROM NetROM Multiprotocol ATMPVC Access to ATM
+% LocalWords: PVCs ITU ipv PLP DECnet Reserved for project NETBEUI LLC KEY key
+% LocalWords: SECURITY Security callback NETLINK interface device netlink Low
+% LocalWords: PACKET level packet ASH Ash ECONET Acorn Econet ATMSVC SVCs SNA
+% LocalWords: IRDA PPPOX PPPoX WANPIPE Wanpipe BLUETOOTH Bluetooth POSIX bits
+% LocalWords: dall'header tab SOCK capabilities capability styles DGRAM read
+% LocalWords: SEQPACKET RDM sockaddr reference void fig Header uint socklen at
+% LocalWords: addr netinet port len Stevens unsigned short casting nell'header
+% LocalWords: BIND SERVICE bind union order big endian flowinfo dell'header ll
+% LocalWords: multicast multicasting local socketpair sun path filesystem AARP
+% LocalWords: pathname AppleTalk netatalk personal Apple ATPROTO atalk sat if
+% LocalWords: ANYNET node ANYNODE ATADDR BCAST pcap IEEE linux ether ETH ALL
+% LocalWords: sll ifindex ethernet halen MAC hatype ARP arp pkttype HOST recv
+% LocalWords: OTHERHOST OUTGOING recvfrom recvmsg endianess little endtest Mac
+% LocalWords: Intel Digital Motorola IBM VME PowerPC l'Intel xABCD ptr htonl
+% LocalWords: all'endianess htons ntohl ntohs long hostlong hostshort netlong
+% LocalWords: sort netshort host inet aton ntoa dotted decimal const char src
+% LocalWords: strptr struct dest addrptr INADDR NULL pton ntop presentation af
+% LocalWords: numeric EAFNOSUPPORT size ENOSPC ENOAFSUPPORT ADDRSTRLEN ROUTE
+% LocalWords: of tcpdump page
%%% Local Variables:
projects / gapil.git / blobdiff