(e non solo). Il 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 ma a differenza di questa e degli altri meccanismi esaminati nel capitolo
-\ref{cha:IPC} i socket non sono limitati alla comunicazione fra processi che
-girano sulla stessa macchina ma possono effettuare la comunicazione anche
+\capref{cha:IPC} i socket non sono limitati alla comunicazione fra processi
+che girano sulla stessa macchina ma possono effettuare la comunicazione anche
attraverso la rete.
Quella dei socket costituisce infatti la principale API (\textit{Application
\label{sec:sock_gen}
Per capire il funzionamento dei socket occorre avere presente il funzionamento
-dei protocolli di rete (vedi \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 \capref{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.
Il prototipo della funzione è definito nell'header \texttt{sys/socket.h}, la
funzione prende tre parametri, il dominio del socket (che definisce la
-famiglia di protocolli, vedi \ref{sec:sock_domain}), il tipo di socket (che
-definisce lo stile di comunicazione vedi \ref{sec:sock_type}) e il protocollo;
-in genere quest'ultimo è indicato implicitamente dal tipo di socket, per cui
-viene messo a zero (con l'eccezione dei \textit{raw socket}).
+famiglia di protocolli, vedi \secref{sec:sock_domain}), il tipo di socket (che
+definisce lo stile di comunicazione vedi \secref{sec:sock_type}) e il
+protocollo; in genere quest'ultimo è indicato implicitamente dal tipo di
+socket, per cui viene messo a zero (con l'eccezione dei \textit{raw socket}).
\begin{itemize}
\item \texttt{int socket(int domain, int type, int protocol)}
Dati i tanti e diversi protocolli di comunicazione disponibili, esistono vari
tipi di socket, che vengono classificati raggruppandoli in quelli che si
-chiamano \textsl{domini} (\textit{domains}). La scelta di un dominio equivale
-in sostanza alla scelta di una famiglia di protocolli. Ciascun dominio ha un
-suo nome simbolico che convenzionalmente inizia con \texttt{PF\_} (da
-\textit{Protocol Family}, altro nome con cui si indicano i domini).
+chiamano \textsl{domini}. La scelta di un dominio equivale in sostanza alla
+scelta di una famiglia di protocolli. Ciascun dominio ha un suo nome simbolico
+che convenzionalmente inizia con \texttt{PF\_} da \textit{protocol family},
+altro nome con cui si indicano i domini.
A ciascun tipo di dominio corrisponde un analogo nome simbolico che inizia per
-\texttt{AF\_} da \textit{Address Family}, e che identifica il formato degli
+\texttt{AF\_} da \textit{address family}, e che identifica il formato degli
indirizzi usati in quel dominio; le man pages di linux si riferiscono a questi
anche come \textit{name space}, (nome che però il manuale della glibc riserva
ai domini) e che identifica il formato degli indirizzi usati in quel dominio.
\centering
\begin{tabular}[c]{lll}
Nome & Utilizzo & Man page \\
+ \hline
PF\_UNIX,PF\_LOCAL & Local communication & unix(7) \\
PF\_INET & IPv4 Internet protocols & ip(7) \\
PF\_INET6 & IPv6 Internet protocols & \\
\label{tab:sock_data_types}
\end{table}
-In alcuni sistemi (per BSD a partire da 4.3BSD-reno) la struttura è
-leggermente diversa e prevede un primo membro aggiuntivo \texttt{uint8\_t
- sin\_len} (come riportato da R. Stevens nei suoi libri). Questo campo non
-verrebbe usato direttamente dal programmatore e non è richiesto dallo standard
-Posix.1g, in Linux pertanto non sussiste. Il campo \texttt{sa\_family\_t} era
-storicamente un \texttt{unsigned short}.
+In alcuni sistemi la struttura è leggermente diversa e prevede un primo membro
+aggiuntivo \texttt{uint8\_t sin\_len} (come riportato da R. Stevens nei suoi
+libri). Questo campo non verrebbe usato direttamente dal programmatore e non è
+richiesto dallo standard Posix.1g, in linux pertanto non sussiste. Il campo
+\texttt{sa\_family\_t} era storicamente un \texttt{unsigned short}.
Dal punto di vista del programmatore l'unico uso di questa struttura è quello
di fare da riferimento per il casting, per il kernel le cose sono un po'
porta viene settato al numero di protocollo.
Il membro \texttt{sin\_family} deve essere sempre settato; \texttt{sin\_port}
-specifica il numero di porta; i numeri di porta sotto il 1024 sono chiamati
-\textsl{riservati} in quanto utilizzati da servizi standard. Soltanto processi
-con i privilegi di root (effective uid uguale a zero) o con la capability
-\texttt{CAP\_NET\_BIND\_SERVICE} possono usare la funzione \texttt{bind} su
-queste porte.
+specifica il numero di porta (vedi \secref{sec:TCPel_port_num}; i numeri di
+porta sotto il 1024 sono chiamati \textsl{riservati} in quanto utilizzati da
+servizi standard. Soltanto processi con i privilegi di root (effective uid
+uguale a zero) o con la capability \texttt{CAP\_NET\_BIND\_SERVICE} possono
+usare la funzione \texttt{bind} su queste porte.
Il membro \texttt{sin\_addr} contiene l'indirizzo internet dell'altro capo
della comunicazione, e viene acceduto sia come struttura (un resto di una
essere specificati in quello che viene chiamato \textit{network order}, cioè
con i bit ordinati in formato \textit{big endian}, questo comporta la
necessità di usare apposite funzioni di conversione per mantenere la
-portabilità del codice (vedi \ref{sec:sock_addr_func} per i dettagli del
+portabilità del codice (vedi \secref{sec:sock_addr_func} per i dettagli del
problema e le relative soluzioni).
\subsection{La struttura degli indirizzi IPv6}
in tre parti di cui i 24 bit inferiori indicano l'etichetta di flusso, i
successivi 4 bit la priorità e gli ultimi 4 sono riservati; questi valori
fanno riferimento ad alcuni campi specifici dell'header dei pacchetti IPv6
-(vedi \ref{sec:appA_ipv6}) ed il loro uso è sperimentale.
+(vedi \secref{sec:appA_ipv6}) ed il loro uso è sperimentale.
Il campo \texttt{sin6\_addr} contiene l'indirizzo a 128 bit usato da IPv6,
infine il campo \texttt{sin6\_scope\_id} è un campo introdotto con il kernel
quindi occorre stare attenti a non avere fatto assunzioni riguardo alla
possibilità di contenere i dati nelle dimensioni di quest'ultima.
-
+
\subsection{La struttura degli indirizzi locali}
\label{sec:sock_sa_local}
I socket di tipo \texttt{PF\_UNIX} vengono usati per una comunicazione
efficiente fra processi che stanno sulla stessa macchina; essi rispetto ai
precedenti possono essere anche creati in maniera anonima attraverso la
-funzione \texttt{socketpair}. Quando però si vuole fare riferiemento ad uno di
-questi socket si deve usare la seguente struttura di indirizzi definita nel
-file di header \texttt{sys/un.h}.
+funzione \texttt{socketpair}. Quando però si vuole fare riferimento esplicito
+ad uno di questi socket si deve usare la seguente struttura di indirizzi
+definita nel file di header \texttt{sys/un.h}.
\begin{figure}[!htbp]
\footnotesize
due forme un file (di tipo socket) nel filesystem o una stringa univoca
(tenuta in uno spazio di nomi astratto). Nel primo caso l'indirizzo viene
specificato come una stringa (terminata da uno zero) corrispondente al
-pathname del file; nel secondo qinvece \texttt{sun\_path} inizia con uno zero
-vegono usati i restanti bytes come stringa (senza terminazione).
+pathname del file; nel secondo invece \texttt{sun\_path} inizia con uno zero
+vengono usati i restanti bytes come stringa (senza terminazione).
-\subsection{Il passaggio delle strutture}
-\label{sec:sock_addr_pass}
+% \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.
+% 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
\section{Le funzioni di conversione degli indirizzi}
\label{sec:sock_addr_func}
-Come accennato gli indirizzi internet e i numeri di porta usati nella rete
-devono essere forniti in formato big endian. In genere la rappresentazione di
-un numbero 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 (in diretta
-corrispondenza a come sono poi in realtà cablati sui bus interni del
-computer).
+In questa sezione tratteremo delle varie funzioni usate per manipolare 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 seguito.
+
+
+\subsection{La \textit{endianess}}
+\label{sec:sock_endianess}
+
+La rappresentazione di un numbero 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 (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 16 bit scritto in una
locazione di memoria posta ad un certo indirizzo. 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 little
-endian dato che il dato finale è la parte ``piccola'' del numero. Il caso
-opposto, in cui si parte dal bit meno significativo è detto per lo stesso
-motivo big endian.
+significativi nell'indirizzo successivo; questo ordinamento è detto
+\textit{little endian} dato che il dato finale è la parte ``piccola'' del
+numero. Il caso opposto, in cui si parte dal bit meno significativo è detto
+per lo stesso motivo \textit{big endian}.
La \textit{endianess} di un computer dipende essenzialmente dalla architettura
hardware usata; intel e digital usano il little endian, motorola, ibm, sun
cambiamenti sono possibili anche dopo che il sistema è avviato, non vengono
mai eseguiti.
+\subsection{Le funzioni per il riordinamento}
+\label{sec:sock_func_ord}
+
Il problema connesso all'endianess è che quando si passano dei dati da un tipo
-di architettura all'altra; in questo caso infatti nel passaggio i dati vengono
-interpretati in maniera diversa, e nel caso dell'esempio dell'intero a 16 bit
-ci si ritroverà con i due bytes componenti scambiati di posto, mentre in
-generale ne sarà invertito l'ordine di lettura e andranno perciò rovesciati.
+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 bytes in cui è
+suddiviso scambiati di posto, e ne sarà quindi invertito l'ordine di lettura
+per cui, per riavere il valore originale dovrenno essere rovesciati.
Per questo motivo si usano le seguenti funzioni di conversione (i cui
prototipi sono definiti in \texttt{netinet/in.h}) che servono a tener conto
automaticamente della possibile differenza fra l'ordinamento usato sul
-computer e quello che viene usato nelle trasmissione sulla rete:
+computer e quello che viene usato nelle trasmissione sulla rete; queste
+funzioni sono:
\begin{itemize}
\item \texttt{unsigned long int htonl(unsigned long int hostlong)}
codice su tutte le architetture.
+\subsection{Le funzioni \texttt{inet\_aton}, \texttt{inet\_addr} e
+ \texttt{inet\_ntoa}}
+\label{sec:sock_func_ipv4}
+
Un secondo insieme di funzioni di manipolazione (i cui prototipi sono definiti
in \texttt{arpa/inet.h}) serve per passare dal formato binario usato nelle
strutture degli indirizzi alla rappresentazione dei numeri IP che si usa
valido, non può essere usata con questa funzione; per questo motivo essa è
generalmente deprecata in favore della precedente.
-\item \texttt{char *inet\_ntop(struct in\_addr addrptr)}
+\item \texttt{char *inet\_ntoa(struct in\_addr addrptr)}
Converte il valore a 32 bit dell'indirizzo (espresso in network order)
restituendo il puntatore alla stringa che contiene l'espressione in formato
statica, per cui questa funzione non è rientrante.
\end{itemize}
-Le tre funzioni precedenti sono però limitate solo ad IPv4, per questo motivo
-è preferibile usare le due nuove funzioni \texttt{inet\_pton} e
+
+\subsection{Le funzioni \texttt{inet\_pton} e \texttt{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 \texttt{inet\_pton} e
\texttt{inet\_ntop} che possono convertire anche gli indirizzi IPv6 (secondo
-lo schema in \nfig). Anche in questo caso le lettere $n$ e $p$ sono gli
+lo schema in \nfig). Anche in questo caso le lettere $n$ e $p$ sono degli
mnemonici per ricordare il tipo di conversione effettuata e stanno per
\textit{presentation} e \textit{numeric}.
Infatti con i socket può accadere che funzioni come \texttt{read} o
\texttt{write} possano restituire in input o scrivere in output un numero di
bytes minore di quello richiesto. Questo è un comportamento normale e non un
-errore, e succede perché si eccede il limite di buffer del kernel. In questo
-caso tutto quello che il programma chiamante deve fare è di ripetere la
-lettura (o scrittura) per la quantità di bytes rimanenti (lo stesso può
+errore, e succede perché si eccede in lettura o scrittura il limite di buffer
+del kernel.
+
+In questo caso tutto quello che il programma chiamante deve fare è di ripetere
+la lettura (o scrittura) per la quantità di bytes rimanenti (lo stesso può
avvenire scrivendo più di 4096 bytes in una pipe, dato che quello è il limite
di solito adottato per il buffer di trasmissione del kernel).
all'esaurimento del numero di bytes richiesti, in caso di errore viene
controllato se questo è \texttt{EINTR} (cioè un'interruzione della system call
dovuta ad un segnale), nel qual caso l'accesso viene ripetuto, altrimenti
-l'errore viene ritornato interrompendo il loop.
+l'errore viene ritornato interrompendo il loop.
Nel caso della lettura se il numero di bytes letti è zero significa che è
arrivati alla fine del file e pertanto si ritorna senza aver concluso la
projects / gapil.git / blobdiff