X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=blobdiff_plain;f=socket.tex;h=7e1f6bd7db68ba847089f35ac99dbbd04ce1cea8;hb=bea3ef3f853bda8591b685fa92a24b34d8cde6d3;hp=95e68bdfcb4daaccf2a57d6b2d67fe55ccc2cea3;hpb=6b10a81a8b1fc4cd623d6b3b1f7852117de55605;p=gapil.git diff --git a/socket.tex b/socket.tex index 95e68bd..7e1f6bd 100644 --- a/socket.tex +++ b/socket.tex @@ -127,7 +127,7 @@ L'idea alla base della distinzione 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 è quanto specificato anche -dallo standard POSIX1g, ma non esistono a tuttora famiglie di protocolli che +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. @@ -155,9 +155,10 @@ protocolli disponibili sono riportate in \ntab. \label{tab:net_pf_names} \end{table} -Non tutte le famiglie di protocolli sono accessibili dall'utente generico, -come forma di protezione infatti soltanto root può usare i protocolli di basso -livello [NdA approfondire]. +Non tutte le famiglie di protocolli sono accessibili dall'utente generico, ad +esempio in generale tutti i socket di tipo \texttt{SOCK\_RAW} possono essere +creati solo da processi che hanno i provilegi di root (cioè effective uid +uguale a zero) o la capability \texttt{CAP\_NET\_RAW}. \subsection{Il tipo, o stile} @@ -212,19 +213,19 @@ tabella che mostra le combinazioni valide \cline{2-6} \texttt{PF\_INET6} & TCP & UDP & IPv6 & & \\ \cline{2-6} - \texttt{PF\_IPX} & ? & & & & \\ + \texttt{PF\_IPX} & & & & & \\ \cline{2-6} - \texttt{PF\_NETLINK} & & & si & & \\ + \texttt{PF\_NETLINK} & & si & si & & \\ \cline{2-6} - \texttt{PF\_X25} & & & & & \\ + \texttt{PF\_X25} & & & & & si \\ \cline{2-6} \texttt{PF\_AX25} & & & & & \\ \cline{2-6} - \texttt{PF\_ATMPVC} & ? & & & & \\ + \texttt{PF\_ATMPVC} & & & & & \\ \cline{2-6} - \texttt{PF\_APPLETALK} & ? & & & & \\ + \texttt{PF\_APPLETALK} & & si & si & & \\ \cline{2-6} - \texttt{PF\_PACKET} & & & & & \\ + \texttt{PF\_PACKET} & & si & si & & \\ \cline{2-6} \end{tabular} \caption{Combinazioni valide di dominio e tipo di protocollo per la funzione \texttt{socket}.} @@ -238,38 +239,378 @@ mentre si sono lasciate vuote le caselle per le combinazioni non supportate. \section{Le strutture degli indirizzi dei socket} \label{sec:sock_sockaddr} -Benché esse non vengano utilizzate nella creazione di un socket le strutture -degli indirizzi sono usate da quasi tutte le altre funzioni concernenti -socket, per cui in questa sezione le tratteremo in dettaglio. +Come si è visto nella creazione di un socket non si specifica nulla oltre al +tipo di famiglia di protocolli che si vuole utilizzare, in particolare nessun +indirizzo che identifichi i due capi della comunicazione. La funzione infatti +si limita ad allocare nel kernel quanto necessario per poter poi realizzare la +comunicazione. +Gli indirizzi vengono specificati attraverso apposite strutture che vengono +utilizzate dalle altre funzioni della API dei socket quando la comunicazione +viene effettivamente realizzata. -I nomi di tutte queste strutture iniziano per \texttt{sockaddr\_} e ciascuna -famiglia di protocolli ha una sua peculiare, che viene identificata dal -suffisso finale aggiunto al nome precedente. - +Ogni famiglia di protocolli ha ovviamente una sua forma di indirizzamento e in +corrispondenza a questa una sua peculiare struttura degli indirizzi; i nomi di +tutte queste strutture iniziano per \texttt{sockaddr\_}, quelli propri di +ciascuna famiglia vengono identificati dal suffisso finale, aggiunto al nome +precedente. \subsection{La struttura generica} \label{sec:sock_sa_gen} +Le strutture degli indirizzi vengono sempre passate alle varie funzioni +attraverso puntatori (cioè \textit{by reference}), ma le funzioni devono poter +maneggiare puntatori a strutture relative a tutti gli indirizzi possibili +nelle varie famiglie di protocolli; questo pone il problema di come passare +questi puntatori, il C ANSI risolve questo problema coi i puntatori generici +(i \texttt{void *}), ma l'interfaccia dei socket è antecendente alla +definizione dello standard ANSI, e per questo nel 1982 fu scelto di definire +una struttura generica \texttt{sockaddr} per gli indirizzi dei socket mostrata +in \nfig: + +\begin{figure}[!htbp] + \footnotesize + \begin{lstlisting}{} +struct sockaddr { + sa_family_t sa_family; /* address family: AF_xxx */ + char sa_data[14]; /* address (protocol-specific) */ +}; + \end{lstlisting} + \caption{La struttura generica degli indirizzi dei socket \texttt{sockaddr}} + \label{fig:sock_sa_struct} +\end{figure} + +Tutte le funzioni dei socket che usano gli indirizzi sono definite usando nel +prototipo un puntatore a questa struttura; per questo motivo quando si +invocano dette funzioni passando l'indirizzo di un protocollo specifico +occorrerà eseguire un casting del relativo puntatore. + +I tipi di dati che compongono la struttura sono stabiliti dallo standard +Posix.1g, riassunti in \ntab\ con i rispettivi file di include in cui sono +definiti; la struttura è invece definita nell'include file +\texttt{sys/socket.h} + +\begin{table}[!htbp] + \centering + \begin{tabular}{|l|l|l|} + \hline + \multicolumn{1}{|c|}{Tipo}& \multicolumn{1}{|c|}{Descrizione}& + \multicolumn{1}{|c|}{Header} \\ + \hline + \hline + \texttt{int8\_t} & intero a 8 bit con segno & \texttt{sys/types.h}\\ + \texttt{uint8\_t} & intero a 8 bit senza segno & \texttt{sys/types.h}\\ + \texttt{int16\_t} & intero a 16 bit con segno & \texttt{sys/types.h}\\ + \texttt{uint16\_t} & intero a 16 bit senza segno& \texttt{sys/types.h}\\ + \texttt{int32\_t} & intero a 32 bit con segno & \texttt{sys/types.h}\\ + \texttt{uint32\_t} & intero a 32 bit senza segno& \texttt{sys/types.h}\\ + \hline + \texttt{sa\_family\_t} & famiglia degli indirizzi& \texttt{sys/socket.h}\\ + \texttt{socklen\_t} & lunghezza (\texttt{uint32\_t}) dell'indirizzo di + un socket& \texttt{sys/socket.h}\\ + \hline + \texttt{in\_addr\_t} & indirizzo IPv4 (\texttt{uint32\_t}) & + \texttt{netinet/in.h}\\ + \texttt{in\_port\_t} & porta TCP o UDP (\texttt{uint16\_t})& + \texttt{netinet/in.h}\\ + \hline + \end{tabular} + \caption{Tipi di dati usati nelle strutture degli indirizzi, secondo quanto + stabilito dallo standard Posix.1g} + \label{tab:sock_data_types} +\end{table} + +In alcuni sistemi (per BSD a partire da 4.3BSD-reno) la struttura è +leggermente diversa e prevede un primo membro aggiuntivo \texttt{uint8\_t + sin\_len} (come riportato da R. Stevens nei suoi libri). Questo campo non +verrebbe usato direttamente dal programmatore e non è richiesto dallo standard +Posix.1g, in Linux pertanto non sussiste. Il campo \texttt{sa\_family\_t} era +storicamente un \texttt{unsigned short}. + +Dal punto di vista del programmatore l'unico uso di questa struttura è quello +di fare da riferimento per il casting, per il kernel le cose sono un po' +diverse, in quanto esso usa il puntatore per recuperare il campo +\texttt{sa\_family} con cui determinare il tipo di indirizzo; per questo +motivo, anche se l'uso di un puntatore \texttt{void *} sarebbe più immediato +per l'utente (che non dovrebbe più eseguire il casting), è stato mantenuto +l'uso di questa struttura. + + \subsection{La struttura degli indirizzi IPv4} \label{sec:sock_sa_ipv4} +I socket di tipo \texttt{PF\_INET} vengono usati per la comunicazione +attraverso internet; la struttura per gli indirizzi per un socket internet +(IPv4) è definita come \texttt{sockaddr\_in} nell'header file +\texttt{netinet/in.h} e secondo le man page ha la forma mostrata in \nfig, +conforme allo standard Posix.1g. + + +\begin{figure}[!htbp] + \footnotesize + \begin{lstlisting}{} +struct sockaddr_in { + sa_family_t sin_family; /* address family: AF_INET */ + u_int16_t sin_port; /* port in network byte order */ + struct in_addr sin_addr; /* internet address */ +}; +/* Internet address. */ +struct in_addr { + u_int32_t s_addr; /* address in network byte order */ +}; + \end{lstlisting} + \caption{La struttura degli indirizzi dei socket internet (IPv4) + \texttt{sockaddr\_in}.} + \label{fig:sock_sa_struct} +\end{figure} + +L'indirizzo di un socket internet (secondo IPv4) comprende l'indirizzo +internet di un'interfaccia più un numero di porta. Il protocollo IP non +prevede numeri di porta, che sono utilizzati solo dai protocolli di livello +superiore come TCP e UDP. Questa struttura però viene usata anche per i socket +RAW che accedono direttamente al livello di IP, nel qual caso il numero della +porta viene settato al numero di protocollo. + +Il membro \texttt{sin\_family} deve essere sempre settato; \texttt{sin\_port} +specifica il numero di porta; i numeri di porta sotto il 1024 sono chiamati +\textsl{riservati} in quanto utilizzati da servizi standard. Soltanto processi +con i privilegi di root (effective uid uguale a zero) o con la capability +\texttt{CAP\_NET\_BIND\_SERVICE} possono usare la funzione \texttt{bind} su +queste porte. + +Il membro \texttt{sin\_addr} contiene l'indirizzo internet dell'altro capo +della comunicazione, e viene acceduto sia come struttura (un resto di una +implementazione precedente in cui questa era una union usata per accedere alle +diverse classi di indirizzi) che come intero. + +Infine è da sottolineare che sia gli indirizzi che i numeri di porta devono +essere specificati in quello che viene chiamato \textit{network order}, cioè +con i bit ordinati in formato \textit{big endian}, questo comporta la +necessità di usare apposite funzioni di conversione per mantenere la +portabilità del codice (vedi \ref{sec:sock_addr_func} per i dettagli del +problema e le relative soluzioni). + \subsection{La struttura degli indirizzi IPv6} \label{sec:sock_sa_ipv6} + +Essendo IPv6 una estenzione di IPv4 i socket di tipo \texttt{PF\_INET6} sono +sostanzialmente identici ai precedenti; la parte in cui si trovano +praticamente tutte le differenze è quella della struttura degli indirizzi. La +struttura degli indirizzi è definita ancora in \texttt{netinet/in.h}. + +\begin{figure}[!htbp] + \footnotesize + \begin{lstlisting}{} +struct sockaddr_in6 { + u_int16_t sin6_family; /* AF_INET6 */ + u_int16_t sin6_port; /* port number */ + u_int32_t sin6_flowinfo; /* IPv6 flow information */ + struct in6_addr sin6_addr; /* IPv6 address */ + u_int32_t sin6_scope_id; /* Scope id (new in 2.4) */ +}; + +struct in6_addr { + unsigned char s6_addr[16]; /* IPv6 address */ +}; + \end{lstlisting} + \caption{La struttura degli indirizzi dei socket IPv6 + \texttt{sockaddr\_in6}.} + \label{fig:sock_sa_struct} +\end{figure} + +Il campo \texttt{sin6\_family} deve essere sempre settato ad +\texttt{AF\_INET6}, il campo \texttt{sin6\_port} è analogo a quello di IPv4 e +segue le stesse regole; il campo \texttt{sin6\_flowinfo} è a dua volta diviso +in tre parti di cui i 24 bit inferiori indicano l'etichetta di flusso, i +successivi 4 bit la priorità e gli ultimi 4 sono riservati; questi valori +fanno riferimento ad alcuni campi specifici dell'header dei pacchetti IPv6 +(vedi \ref{sec:appA_ipv6}) ed il loro uso è sperimentale. + +Il campo \texttt{sin6\_addr} contiene l'indirizzo a 128 bit usato da IPv6, +infine il campo \texttt{sin6\_scope\_id} è un campo introdotto con il kernel +2.4 per gestire alcune operazioni riguardanti il multicasting. + +Si noti che questa struttura è più grande di una \texttt{sockaddr} generica, +quindi occorre stare attenti a non avere fatto assunzioni riguardo alla +possibilità di contenere i dati nelle dimensioni di quest'ultima. + \subsection{La struttura degli indirizzi locali} \label{sec:sock_sa_local} +I socket di tipo \texttt{PF\_UNIX} vengono usati per una comunicazione +efficiente fra processi che stanno sulla stessa macchina; essi rispetto ai +precedenti possono essere anche creati in maniera anonima attraverso la +funzione \texttt{socketpair}. Quando però si vuole fare riferiemento ad uno di +questi socket si deve usare la seguente struttura di indirizzi definita nel +file di header \texttt{sys/un.h}. + +\begin{figure}[!htbp] + \footnotesize + \begin{lstlisting}{} +#define UNIX_PATH_MAX 108 +struct sockaddr_un { + sa_family_t sun_family; /* AF_UNIX */ + char sun_path[UNIX_PATH_MAX]; /* pathname */ +}; + \end{lstlisting} + \caption{La struttura degli indirizzi dei socket locali + \texttt{sockaddr\_un}.} + \label{fig:sock_sa_struct} +\end{figure} + +In questo caso il campo \texttt{sun\_family} deve essere \texttt{AF\_UNIX}, +mentre il campo \texttt{sun\_path} deve specificare un indirizzo; questo ha +due forme un file (di tipo socket) nel filesystem o una stringa univoca +(tenuta in uno spazio di nomi astratto). Nel primo caso l'indirizzo viene +specificato come una stringa (terminata da uno zero) corrispondente al +pathname del file; nel secondo qinvece \texttt{sun\_path} inizia con uno zero +vegono usati i restanti bytes come stringa (senza terminazione). + + +\subsection{Il passaggio delle strutture} +\label{sec:sock_addr_pass} +Come detto nelle funzioni della API dei socket le strutture degli indirizzi +vengono sempre passate per riferimento usando un puntatore; anche la lunghezza +della struttura è passata come argomento, ma in questo caso la modalità del +passaggio dipende dalla direzione del medesimo, dal processo al kernel o +viceversa. +% In particolare le tre funzioni \texttt{bind}, \texttt{connect} e +% \texttt{sendto} passano la struttura al kernel, in questo caso è passata +% \textsl{per valore} anche la dimensione della medesima + + +% Le funzioni \texttt{accept}, \texttt{recvfrom}, \texttt{getsockname} e +% \texttt{getpeername} invece ricevono i valori del kernel \section{Le funzioni di conversione degli indirizzi} -\label{sec:sock_addr_conv} +\label{sec:sock_addr_func} + +Come accennato gli indirizzi internet e i numero di porta espressi 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 bit sono aggregati per formare le +unità più grandi. + +Si consideri ad esempio 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 big endian. + +La \textit{endianess} di un computer dipende essenzialmente dalla architettura +usata; intel e digital usano il little endian, motorola, ibm, sun +(sostanzialmente tutti gli altri) usano il big endian. Il formato della rete è +anch'esso big endian. Esistono poi anche dei sistemi che possono scegliere il +tipo di formato e alcuni, come il PowerPC o l'intel i860, possono pure passare +da un tipo all'altro; ma in generale un sistema ha un suo specifico +comportamento a questo riguardo. + +Il problema si pone quando si passano dei dati da un tipo di archiettura +all'altra dato che, con l'eccezione dei tipi numerici ad otto bit, tutti gli +altri si ritrovano rovesciati. + +Per questo motivo si usano le seguenti funzioni di conversione che tengano +conto della differenza delle architetture: +\begin{itemize} +\item \texttt{unsigned long int htonl(unsigned long int hostlong)} + + Converte l'intero a 32 bit \texttt{hostlong} dal formato della macchina a + quello della rete. + +\item \texttt{unsigned sort int htons(unsigned short int hostshort)} + Converte l'intero a 16 bit \texttt{hostshort} dal formato della macchina a + quello della rete. + +\item \texttt{unsigned long int ntonl(unsigned long int netlong)} + + Converte l'intero a 32 bit \texttt{netlong} dal formato della rete a quello + della macchina. + +\item \texttt{unsigned sort int ntons(unsigned short int netshort)} + + Converte l'intero a 16 bit \texttt{netshort} dal formato della rete a quello + della macchina. +\end{itemize} +in cui la lettera $n$ è uno mnemonico per indicare l'ordinamento usato sulla +rete (da \textit{network order}) e la lettere $h$ uno mnemonico per +l'ordinamento usato sulla macchina locale (da \textit{host order}), mentre le +lettere $s$ e $l$ stanno ad indicare i tipi di dato (riportati anche dai +prototipi). + +Usando queste funzioni si ha la conversione automatica in caso di necessità +(nel caso pure la macchina sia in big endian queste funzioni sono definite +come macro che non fanno nulla). + +A parte i problemi connessi con l'ordinamento dei bit esistono poi altre +funzioni connesse alla manipolazione degli indirizzi internet, in particolare +per convertire indirizzi espressi in forma di stringa (di più immediata +manipolazione ``umana'') nella forma binaria usata nelle strutture degli +indirizzi. + +Le prime tre funzioni riguardano la conversione degli indirizzi IPv4 fra +l'espressione come stringhe \textit{dotted-decimal}, cioè del tipo +\texttt{192.160.0.1} al formato binario ordinato secondo la rete: +\begin{itemize} +\item \texttt{int inet\_aton(const char *strptr, struct in\_addr *addrptr)} + + Converte la stringa puntata da \texttt{strptr} nell'indirizzo binario da + memorizzare all'indirizzo puntato da \texttt{addrptr}, restituendo 0 in caso + di successo e 1 in caso di fallimento (è espressa in questa forma in modo da + poterla usare direttamente con il puntatore usato per passare la struttura + degli indirizzi). Se usata con \texttt{addrptr} inizializzato a + \texttt{NULL} effettua la validazione dell'indirizzo. + +\item \texttt{in\_addr\_t inet\_addr(const char *strptr)} + + Restituisce l'indirizzo a 32 bit in network order a partire dalla stringa + passata come parametro, in caso di errore restituisce il valore + \texttt{INADDR\_NONE} (che tipicamente sono trentadue bit a uno, il che + significa che la stringa \texttt{255.255.255.255} non può essere un + indirizzo valido). Questa funzione è generalmente deprecata in favore della + precedente. + +\item \texttt{char *inet\_ntop(struct in\_addr addrptr)} + + Questa funzione converte il valore a 32 bit in network order dell'indirizzo + in una stringa. La stringe risiede in memoria statica, per cui questa + funzione non è rientrante, inoltre, in maniera abbastanza atipica, prende in + ingresso una struttura e non un puntarore. +\end{itemize} +Queste funzioni sono limitate solo ad IPv4, per questo motivo è preferibile +usare le due nuove funzioni \texttt{inet\_pton} e \texttt{inet\_ntop} che +funzionano anche per indirizzi IPv6. In questo caso le lettere $n$ e $p$ sono +gli mnemonici per ricordare il tipo di conversione effettuato e stanno per +\textit{presentation} e \textit{numeric}. +\begin{itemize} +\item \texttt{int inet\_pton(int family, const char *strptr, void *addrptr)} + + Converte la stringa puntata da \texttt{strptr} nell'indirizzo binario da + memorizzare all'indirizzo puntato da \texttt{addrptr}, restituendo 0 in caso + di successo e 1 in caso di fallimento (è espressa in questa forma in modo da + poterla usare direttamente con il puntatore usato per passare la struttura + degli indirizzi). Se usata con \texttt{addrptr} inizializzato a + \texttt{NULL} effettua la validazione dell'indirizzo. + + +\item \texttt{char *inet\_ntop(int family, const void *addrptr, char *strptr, + size\_t len)} + + Questa funzione converte il valore a 32 bit in network order dell'indirizzo + in una stringa. La stringe risiede in memoria statica, per cui questa + funzione non è rientrante, inoltre, in maniera abbastanza atipica, prende in + ingresso una struttura e non un puntatore. +\end{itemize}