\subsection{I \textit{socket}}
\label{sec:sock_socket_def}
-I \textit{socket}\footnote{una traduzione letterale potrebbe essere
- \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 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
-meccanismi esaminati nel capitolo cap.~\ref{cha:IPC}, i socket non sono
-limitati alla comunicazione fra processi che girano sulla stessa macchina, ma
-possono realizzare la comunicazione anche attraverso la rete.
+I \textit{socket} (una traduzione letterale potrebbe essere \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 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
+\textit{pipe} (vedi sez.~\ref{sec:ipc_pipes}) ma, a differenza di questa e
+degli altri meccanismi esaminati nel capitolo cap.~\ref{cha:IPC}, i socket non
+sono limitati alla comunicazione fra processi che girano sulla stessa
+macchina, ma possono realizzare la comunicazione anche attraverso la rete.
Quella dei socket costituisce infatti la principale interfaccia usata nella
programmazione di rete. La loro origine risale al 1983, quando furono
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à).
+di quella dei socket (né tantomeno la stessa usabilità e flessibilità) ed oggi
+sono praticamente dimenticate.
La flessibilità e la genericità dell'interfaccia inoltre consente di
utilizzare i socket con i più disparati meccanismi di comunicazione, e non
\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
-problemi) siano diverse a seconda del tipo di protocollo di comunicazione
-usato, le funzioni da usare restano le stesse.
+dei protocolli di rete che su utilizzeranno (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 nella gestione dei
+socket restano le stesse.
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
-(su come inviare e ricevere i dati) e sul comportamento effettivo delle
-funzioni utilizzate.
-
-La scelta di uno stile dipende sia dai meccanismi disponibili, sia dal tipo di
-comunicazione che si vuole effettuare. Ad esempio alcuni stili di
+affrontare cambiano radicalmente a seconda del tipo di comunicazione usato.
+La scelta di questo tipo (sovente anche detto \textsl{stile}) va infatti ad
+incidere sulla semantica che verrà utilizzata a livello utente per gestire la
+comunicazione cioè su come inviare e ricevere i dati e sul comportamento
+effettivo delle funzioni utilizzate.
+
+La scelta di uno \textsl{stile} dipende sia dai meccanismi disponibili, sia
+dal tipo di comunicazione che si vuole effettuare. Ad esempio alcuni tipi di
comunicazione considerano i dati come una sequenza continua di byte, in quello
che viene chiamato un \textsl{flusso} (in inglese \textit{stream}), mentre
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
-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).
-
-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 \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
-dovranno essere opportunamente trattati, ecc.
+\textit{datagram}) che vengono sempre inviati in blocchi separati e non
+divisibili.
+
+Un altro esempio delle differenze fra i diversi tipi di comunicazione concerne
+la possibilità che essa possa o meno perdere dati nella trasmissione, che
+possa o meno rispettare l'ordine in cui i dati inviati e ricevuti, o che possa
+accadere di inviare dei pacchetti di dati più volte (differenze che ad esempio
+sono presenti nel caso di utilizzo dei protocolli TCP o UDP).
+
+Un terzo esempio di differenza nel tipo di comunicazione concerne il modo in
+cui essa avviene nei confronti dei corrispondenti, 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 \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 diversi aspetti associato ad un tipo di
+comunicazione comporta una modalità diversa di gestire la stessa, 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 socket}
\subsection{La funzione \func{socket}}
\label{sec:sock_socket}
-La creazione di un socket avviene attraverso l'uso della funzione
-\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 è:
-\begin{prototype}{sys/socket.h}{int socket(int domain, int type, int protocol)}
+La creazione di un socket avviene attraverso l'uso della funzione di sistema
+\funcd{socket}; essa restituisce un \textit{file descriptor} (del tutto
+analogo a quelli che si ottengono per i file di dati e le \textit{pipe},
+descritti in sez.~\ref{sec:file_fd}) che serve come riferimento al socket; il
+suo prototipo è:
- 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à
- i valori:
+\begin{funcproto}{
+\fhead{sys/socket.h}
+\fdecl{int socket(int domain, int type, int protocol)}
+\fdesc{Apre un socket.}
+}
+
+{La funzione ritorna un valore positivo in caso di successo e $-1$ per un
+ errore, nel qual caso \var{errno} assumerà uno dei 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
- 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
dominio o con il protocollo specificato.
- \item[\errcode{EINVAL}] protocollo sconosciuto o dominio non disponibile.
+ \item[\errcode{EAFNOSUPPORT}] famiglia di indirizzi non supportata.
+ \item[\errcode{EINVAL}] argomento \param{type} invalido.
+ \item[\errcode{EMFILE}] si è ecceduta la tabella dei file.
+ \item[\errcode{ENFILE}] si è raggiunto il limite massimo di file aperti.
\item[\errcode{ENOBUFS}] non c'è sufficiente memoria per creare il socket
(può essere anche \errval{ENOMEM}).
+ \item[\errcode{EPROTONOSUPPORT}] il tipo di socket o il protocollo scelto
+ non sono supportati nel dominio.
\end{errlist}
- inoltre, a seconda del protocollo usato, potranno essere generati altri
- errori, che sono riportati nelle relative pagine di manuale.}
-\end{prototype}
+ ed inoltre a seconda del protocollo usato, potranno essere generati altri
+ errori, che sono riportati nelle pagine di manuale relative al protocollo.}
+\end{funcproto}
+
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
% http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c319b4d76b9e583a5d88d6bf190e079c4e43213d
Si noti che la creazione del socket si limita ad allocare le opportune
-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.
+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. Questo significa che
+la funzione da sola non è in grado di fornire alcun tipo di comunicazione.
+
\subsection{Il dominio dei socket}
\label{sec:sock_domain}
associato ad una costante, che inizia invece per \texttt{AF\_} (da
\textit{address family}) che identifica il formato degli indirizzi usati in
quel dominio. Le pagine di manuale di Linux si riferiscono a questi indirizzi
-anche come \textit{name space},\footnote{nome che invece il manuale delle
- \acr{glibc} riserva a quello che noi abbiamo chiamato domini.} dato che
-identificano il formato degli indirizzi usati in quel dominio per identificare
-i capi della comunicazione.
+anche come \textit{name space}, (nome che invece il manuale delle \acr{glibc}
+riserva a quello che noi abbiamo chiamato domini) dato che identificano il
+formato degli indirizzi usati in quel dominio per identificare i capi della
+comunicazione.
\begin{table}[htb]
\footnotesize
\const{PF\_ECONET} &19& Acorn Econet & \\
\const{PF\_ATMSVC} &20& ATM SVCs & \\
\const{PF\_SNA} &22& Linux SNA Project & \\
- \const{PF\_IRDA} &23& IRDA socket & \\
+ \const{PF\_IRDA} &23& IRDA socket (infrarossi) & \\
\const{PF\_PPPOX} &24& PPPoX socket & \\
\const{PF\_WANPIPE} &25& Wanpipe API socket & \\
\const{PF\_LLC} &26& Linux LLC & \\
+ \const{PF\_CAN} &29& Controller Are network & \\
\const{PF\_BLUETOOTH}&31& Bluetooth socket & \\
\hline
\end{tabular}
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
il contenuto di \file{bits/socket.h}, le costanti sono esattamente le stesse
e ciascuna \texttt{AF\_} è definita alla corrispondente \texttt{PF\_} e con
- lo stesso nome.}
+ lo stesso nome.} Qui si sono indicati i nomi con il prefisso \texttt{AF\_}
+seguendo la convenzione usata nelle pagine di manuale.
I domini (e i relativi nomi simbolici), così come i nomi delle famiglie di
indirizzi, sono definiti dall'\textit{header file} \headfile{socket.h}. Un
elenco delle 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 è
- 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).}
+tab.~\ref{tab:net_pf_names}. L'elenco indica tutti i protocolli 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.
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 \ids{UID} effettivo uguale a zero) o dotati della
-\itindex{capabilities} \textit{capability} \const{CAP\_NET\_RAW}.
+\textit{capability} \const{CAP\_NET\_RAW}.
\subsection{Il tipo di socket}
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 \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.
+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
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
-\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_endianness}); 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.
+\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_endianness}); 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}}
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
-un processo con i privilegi di amministratore (\ids{UID} effettivo nullo) o con
-la \itindex{capabilities} \textit{capability} \const{CAP\_NET\_RAW}.
+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
projects / gapil.git / blobdiff