X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=socket.tex;h=6773fc287009f5d80936e1996886829529e01204;hp=bda41602a653c4c52ec21755413eb974aaf9a2bf;hb=ee65c9e30267ed1b0c0cef337c3ff86f9e0b370d;hpb=4d46f47e3a0e08440812b334f79489d92814e6d2 diff --git a/socket.tex b/socket.tex index bda4160..6773fc2 100644 --- a/socket.tex +++ b/socket.tex @@ -1,6 +1,6 @@ %% socket.tex %% -%% Copyright (C) 2000-2015 Simone Piccardi. Permission is granted to +%% Copyright (C) 2000-2018 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", @@ -33,7 +33,7 @@ creati. \index{socket!definizione|(} -\subsection{Cosa sono \textit{socket}} +\subsection{Cosa sono i \textit{socket}} \label{sec:sock_socket_def} I \textit{socket} (una traduzione letterale potrebbe essere \textsl{presa}, ma @@ -191,7 +191,7 @@ 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] +\begin{table}[!htb] \footnotesize \centering \begin{tabular}[c]{|l|l|l|l|} @@ -199,44 +199,58 @@ comunicazione. \textbf{Nome}&\textbf{Valore}&\textbf{Utilizzo}&\textbf{Man page} \\ \hline \hline - \const{PF\_UNSPEC} & 0& Non specificato & \\ - \const{PF\_LOCAL} & 1& Local communication & unix(7) \\ - \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\_APPLETALK}& 5& Appletalk & ddp(7) \\ - \const{PF\_NETROM} & 6& Amateur radio NetROM & \\ - \const{PF\_BRIDGE} & 7& Multiprotocol bridge & \\ - \const{PF\_ATMPVC} & 8& Access to raw ATM PVCs & \\ - \const{PF\_X25} & 9& ITU-T X.25 / ISO-8208 protocol& x25(7) \\ - \const{PF\_INET6} &10& IPv6 Internet protocols & ipv6(7) \\ - \const{PF\_ROSE} &11& Amateur Radio X.25 PLP & \\ - \const{PF\_DECnet} &12& Reserved for DECnet project & \\ - \const{PF\_NETBEUI} &13& Reserved for 802.2LLC project & \\ - \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 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 & \\ + \constd{AF\_UNSPEC} & 0& Non specificato & \\ + \constd{AF\_LOCAL} & 1& Local communication & unix(7) \\ + \constd{AF\_UNIX}, \constd{AF\_FILE}&1&Sinonimi di \const{AF\_LOCAL}& \\ + \constd{AF\_INET} & 2& IPv4 Internet protocols & ip(7) \\ + \constd{AF\_AX25} & 3& Amateur radio AX.25 protocol & \\ + \constd{AF\_IPX} & 4& IPX - Novell protocols & \\ + \constd{AF\_APPLETALK}& 5& Appletalk & ddp(7) \\ + \constd{AF\_NETROM} & 6& Amateur radio NetROM & \\ + \constd{AF\_BRIDGE} & 7& Multiprotocol bridge & \\ + \constd{AF\_ATMPVC} & 8& Access to raw ATM PVCs & \\ + \constd{AF\_X25} & 9& ITU-T X.25 / ISO-8208 protocol& x25(7) \\ + \constd{AF\_INET6} &10& IPv6 Internet protocols & ipv6(7) \\ + \constd{AF\_ROSE} &11& Amateur Radio X.25 PLP & \\ + \constd{AF\_DECnet} &12& Reserved for DECnet project & \\ + \constd{AF\_NETBEUI} &13& Reserved for 802.2LLC project & \\ + \constd{AF\_SECURITY} &14& Security callback pseudo AF & \\ + \constd{AF\_KEY} &15& AF\_KEY key management API & \\ + \constd{AF\_NETLINK} &16& Kernel user interface device & netlink(7) \\ + \constd{AF\_ROUTE} &16& Sinonimo di \const{AF\_NETLINK} emula BSD.&\\ + \constd{AF\_PACKET} &17& Low level packet interface & packet(7) \\ + \constd{AF\_ASH} &18& Ash & \\ + \constd{AF\_ECONET} &19& Acorn Econet & \\ + \constd{AF\_ATMSVC} &20& ATM SVCs & \\ + \constd{AF\_RDS} &21& RDS Sockets & \\ + \constd{AF\_SNA} &22& Linux SNA Project & \\ + \constd{AF\_IRDA} &23& IRDA socket (infrarossi) & irda(7) \\ + \constd{AF\_PPPOX} &24& PPPoX socket & \\ + \constd{AF\_WANPIPE} &25& Wanpipe API socket & \\ + \constd{AF\_LLC} &26& Linux LLC & \\ + \constd{AF\_IB} &27& Native InfiniBand address & \\ + \constd{AF\_MPLS} &28& MPSL & \\ + \constd{AF\_CAN} &29& Controller Are Network & \\ + \constd{AF\_TIPC} &30& TIPC sockets & \\ + \constd{AF\_BLUETOOTH}&31& Bluetooth socket & \\ + \constd{AF\_IUCV} &32& IUCV sockets & \\ + \constd{AF\_RXRPC} &33& RxRPC sockets & \\ + \constd{AF\_ISDN} &34& mISDN sockets & \\ + \constd{AF\_PHONET} &35& Phonet sockets & \\ + \constd{AF\_IEEE802154}&36& IEEE802154 sockets & \\ + \constd{AF\_CAIF} &37& CAIF sockets & \\ + \constd{AF\_ALG} &38& Algorithm sockets & \\ + \constd{AF\_NFC} &39& NFC sockets & \\ + \constd{AF\_VSOCK} &40& vSockets & \\ + \constd{AF\_KCM} &41& Kernel Connection Multiplexor & \\ + \constd{AF\_QIPCRTR} &42& Qualcomm IPC Router & \\ + \constd{AF\_SMC} &43& smc sockets & \\ \hline \end{tabular} \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 @@ -251,13 +265,13 @@ valori numerici.\footnote{in Linux, come si può verificare andando a guardare 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}. 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. +indirizzi, sono definiti dall'\textit{header file} \headfiled{socket.h}. Un +elenco, aggiornato alla versione 4.15, delle famiglie di protocolli +disponibili in Linux è riportato in 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 \constd{AF\_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 @@ -280,29 +294,28 @@ 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{1.5cm}\desclabelstyle{\nextlinelabel}} -\item[\const{SOCK\_STREAM}] Provvede un canale di trasmissione dati +\begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}} +\item[\constd{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}) 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 + urgenti (o \textit{out-of-band}, vedi sez.~\ref{sec:TCP_urgent_data}). +\item[\constd{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 maniera non affidabile. -\item[\const{SOCK\_SEQPACKET}] Provvede un canale di trasmissione di dati +\item[\constd{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, e devono essere letti integralmente da ciascuna chiamata a \func{read}. -\item[\const{SOCK\_RAW}] Provvede l'accesso a basso livello ai protocolli di +\item[\constd{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. -\item[\const{SOCK\_RDM}] Provvede un canale di trasmissione di dati +\item[\constd{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 più usato (e pertanto +\item[\constd{SOCK\_PACKET}] Obsoleto, non deve essere più usato (e pertanto non ne parleremo ulteriormente). \end{basedescript} @@ -312,20 +325,19 @@ impostare dei flag relativi alle caratteristiche generali del \textit{socket} non strettamente attinenti all'indicazione del tipo secondo i valori appena illustrati. Essi infatti possono essere combinati con un OR aritmetico delle ulteriori costanti: -\begin{basedescript}{\desclabelwidth{1.5cm}\desclabelstyle{\nextlinelabel}} -\item[\const{SOCK\_CLOEXEC}] imposta il flag di \textit{close-on-exec} sul +\begin{basedescript}{\desclabelwidth{2.5cm}\desclabelstyle{\nextlinelabel}} +\item[\constd{SOCK\_CLOEXEC}] imposta il flag di \textit{close-on-exec} sul file descriptor del socket, ottenendo lo stesso effetto del flag \const{O\_CLOEXEC} di \func{open} (vedi tab.~\ref{tab:open_operation_flag}), di cui costituisce l'analogo. -\item[\const{SOCK\_NONBLOCK}] crea il socket in modalità non-bloccante, con +\item[\constd{SOCK\_NONBLOCK}] crea il socket in modalità non-bloccante, con effetti identici ad una successiva chiamata a \func{fcntl} per impostare il flag di \const{O\_NONBLOCK} sul file descriptor (si faccia di nuovo riferimenti al significato di quest'ultimo come spiegato in tab.~\ref{tab:open_operation_flag}). \end{basedescript} - Si tenga presente inoltre 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 esista un protocollo per ciascuno dei diversi stili di comunicazione @@ -343,27 +355,39 @@ appena elencati. &\const{SOCK\_STREAM} &\const{SOCK\_DGRAM} &\const{SOCK\_RAW}& \const{SOCK\_RDM}&\const{SOCK\_SEQPACKET} \\ \hline - \const{PF\_LOCAL} & si & si & & & \\ + \const{AF\_UNIX} & si & si & -- & -- & si\footnotemark \\ \hline -% \const{PF\_UNIX}&\multicolumn{5}{|l|}{sinonimo di \const{PF\_LOCAL}.}\\ -% \hline - \const{PF\_INET} & TCP & UDP & IPv4 & & \\ + \const{AF\_LOCAL}&\multicolumn{5}{|c|}{sinonimo di \const{AF\_UNIX}}\\ + \hline + \const{AF\_INET} & TCP & UDP & IPv4 & -- & -- \\ + \hline + \const{AF\_INET6} & TCP & UDP & IPv6 & -- & -- \\ + \hline + \const{AF\_IPX} & -- & si & -- & -- & -- \\ + \hline + \const{AF\_NETLINK} & -- & si & si & -- & -- \\ \hline - \const{PF\_INET6} & TCP & UDP & IPv6 & & \\ + \const{AF\_X25} & -- & -- & -- & -- & si \\ \hline - \const{PF\_IPX} & & & & & \\ + \const{AF\_AX25} & -- & si & si & -- & si \\ \hline - \const{PF\_NETLINK} & & si & si & & \\ +% \const{AF\_ATMPVC} & -- & -- & -- & -- & -- \\ +% \hline + \const{AF\_APPLETALK} & -- & si & si & -- & -- \\ + \hline + \const{AF\_PACKET} & -- & si & si & -- & -- \\ + \hline + \const{AF\_KEY} & -- & -- & si & -- & -- \\ \hline - \const{PF\_X25} & & & & & si \\ + \const{AF\_IRDA} & si & si & si & -- & si \\ \hline - \const{PF\_AX25} & & & & & \\ + \const{AF\_NETROM} & -- & -- & -- & -- & si \\ \hline - \const{PF\_ATMPVC} & & & & & \\ + \const{AF\_ROSE} & -- & -- & -- & -- & si \\ \hline - \const{PF\_APPLETALK} & & si & si & & \\ + \const{AF\_RDS} & -- & -- & -- & -- & si \\ \hline - \const{PF\_PACKET} & & si & si & & \\ + \const{AF\_ECONET} & -- & si & -- & -- & -- \\ \hline \end{tabular} \caption{Combinazioni valide di dominio e tipo di protocollo per la @@ -371,11 +395,14 @@ appena elencati. \label{tab:sock_sock_valid_combinations} \end{table} +\footnotetext{supportati a partire dal kernel 2.6.4 per socket che conservano + i limiti dei messaggi e li consegnano in sequenza ordinata.} + 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 -\textsl{si} qualora non il protocollo non abbia un nome definito, mentre si -sono lasciate vuote le caselle per le combinazioni non supportate. +\textsl{si} qualora 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} @@ -439,20 +466,20 @@ definita nell'include file \headfile{sys/socket.h}. \multicolumn{1}{|c|}{\textbf{Header}} \\ \hline \hline - \type{int8\_t} & intero a 8 bit con segno & \headfile{sys/types.h}\\ - \type{uint8\_t} & intero a 8 bit senza segno & \headfile{sys/types.h}\\ - \type{int16\_t} & intero a 16 bit con segno & \headfile{sys/types.h}\\ - \type{uint16\_t} & intero a 16 bit senza segno& \headfile{sys/types.h}\\ - \type{int32\_t} & intero a 32 bit con segno & \headfile{sys/types.h}\\ - \type{uint32\_t} & intero a 32 bit senza segno& \headfile{sys/types.h}\\ + \typed{int8\_t} & intero a 8 bit con segno & \headfile{sys/types.h}\\ + \typed{uint8\_t} & intero a 8 bit senza segno & \headfile{sys/types.h}\\ + \typed{int16\_t} & intero a 16 bit con segno & \headfile{sys/types.h}\\ + \typed{uint16\_t} & intero a 16 bit senza segno& \headfile{sys/types.h}\\ + \typed{int32\_t} & intero a 32 bit con segno & \headfile{sys/types.h}\\ + \typed{uint32\_t} & intero a 32 bit senza segno& \headfile{sys/types.h}\\ \hline - \type{sa\_family\_t} & famiglia degli indirizzi&\headfile{sys/socket.h}\\ - \type{socklen\_t} & lunghezza (\type{uint32\_t}) dell'indirizzo di + \typed{sa\_family\_t} & famiglia degli indirizzi&\headfile{sys/socket.h}\\ + \typed{socklen\_t} & lunghezza (\type{uint32\_t}) dell'indirizzo di un socket& \headfile{sys/socket.h}\\ \hline - \type{in\_addr\_t} & indirizzo IPv4 (\type{uint32\_t}) & + \typed{in\_addr\_t} & indirizzo IPv4 (\type{uint32\_t}) & \headfile{netinet/in.h}\\ - \type{in\_port\_t} & porta TCP o UDP (\type{uint16\_t})& + \typed{in\_port\_t} & porta TCP o UDP (\type{uint16\_t})& \headfile{netinet/in.h}\\ \hline \end{tabular} @@ -475,14 +502,43 @@ indirizzo; per questo motivo, anche se l'uso di un puntatore \ctyp{void *} sarebbe più immediato per l'utente (che non dovrebbe più eseguire il casting), è stato mantenuto l'uso di questa struttura. +Se si usa una struttura \struct{sockaddr} per allocare delle variabili +generiche da usare in seguito per degli indirizzi si pone il problema che +niente assicura che i dati necessari per le varie famiglie di indirizzi +possano rientrare nella dimensione del campo \var{sa\_data} indicata in +fig.~\ref{fig:sock_sa_gen_struct}, anzi, come vedremo in +sez.~\ref{sec:sock_sa_ipv6}, nel caso di indirizzi IPv6 questa non è proprio +sufficiente. + +\begin{figure}[!htb] + \footnotesize \centering + \begin{minipage}[c]{0.95\textwidth} + \includestruct{listati/sockaddr_storage.h} + \end{minipage} + \caption{La struttura generica degli indirizzi dei socket + \structd{sockaddr\_storage}.} + \label{fig:sock_sa_storage_struct} +\end{figure} + +Per questo l'interfaccia di programmazione dei socket prevede la defizione di +una speciale struttura \struct{sockaddr\_storage} illustrata in +fig.~\ref{fig:sock_sa_storage_struct}, in cui di nuovo si usa il primo campo +(\var{ss\_family}) per indicare il tipo di indirizzo, ed in cui i campi +successivi sono utilizzati per allineare i dati al tipo di architettura +hardware utilizzata, e per allocare uno spazio sufficiente ampio per contenere +qualunque tipo di indirizzo supportato. Allocando questa struttura si ha la +certezza di non eccedere le dimensioni qualunque sia il tipo di indirizzi che +si useranno, pertanto risulta utile tutte le volte che si devono gestire in +maniera generica tipi di indirizzi diversi (ad esempio IPv4 ed IPv6). + \subsection{La struttura degli indirizzi IPv4} \label{sec:sock_sa_ipv4} -I socket di tipo \const{PF\_INET} vengono usati per la comunicazione -attraverso internet; la struttura per gli indirizzi per un socket internet (se +I socket di tipo \const{AF\_INET} vengono usati per la comunicazione +attraverso Internet; la struttura per gli indirizzi per un socket Internet (se si usa IPv4) è definita come \struct{sockaddr\_in} nell'header file -\headfile{netinet/in.h} ed ha la forma mostrata in +\headfiled{netinet/in.h} ed ha la forma mostrata in fig.~\ref{fig:sock_sa_ipv4_struct}, conforme allo standard POSIX.1g. \begin{figure}[!htb] @@ -491,19 +547,20 @@ fig.~\ref{fig:sock_sa_ipv4_struct}, conforme allo standard POSIX.1g. \includestruct{listati/sockaddr_in.h} \end{minipage} \caption{La struttura \structd{sockaddr\_in} degli indirizzi dei socket - internet (IPv4) e la struttura \structd{in\_addr} degli indirizzi IPv4.} + 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 +L'indirizzo di un socket Internet (secondo IPv4) comprende l'indirizzo +Internet di un'interfaccia più un \textsl{numero di porta} (affronteremo in dettaglio il significato di questi numeri in sez.~\ref{sec:TCP_port_num}). Il -protocollo IP 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 impostato al numero di protocollo. +protocollo IP di per sé non prevede numeri di porta, questi sono utilizzati +solo dai protocolli di livello superiore come TCP e UDP, ma devono essere +indicati qui. Inoltre questa struttura viene usata anche per i socket RAW che +accedono direttamente al livello di IP, in questo caso il numero della porta +deve essere impostato al numero di protocollo. -Il membro \var{sin\_family} deve essere sempre impostato a \const{AF\_INET}, +Il membro \var{sin\_family} deve essere sempre impostato a \constd{AF\_INET}, altrimenti si avrà un errore di \errcode{EINVAL}; il membro \var{sin\_port} specifica il \textsl{numero di porta}. I numeri di porta sotto il 1024 sono chiamati \textsl{riservati} in quanto utilizzati da servizi standard e @@ -512,9 +569,9 @@ 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 +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 +una \dirct{union} usata per accedere alle diverse classi di indirizzi) che direttamente come intero. In \headfile{netinet/in.h} vengono definite anche alcune costanti che identificano alcuni indirizzi speciali, riportati in tab.~\ref{tab:TCP_ipv4_addr}, che rincontreremo più avanti. @@ -531,7 +588,7 @@ soluzioni). \subsection{La struttura degli indirizzi IPv6} \label{sec:sock_sa_ipv6} -Essendo IPv6 un'estensione di IPv4, i socket di tipo \const{PF\_INET6} sono +Essendo IPv6 un'estensione di IPv4, i socket di tipo \const{AF\_INET6} sono sostanzialmente identici ai precedenti; la parte in cui si trovano praticamente tutte le differenze fra i due socket è quella della struttura degli indirizzi; la sua definizione, presa da \headfile{netinet/in.h}, è @@ -547,7 +604,7 @@ riportata in fig.~\ref{fig:sock_sa_ipv6_struct}. \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\_family} deve essere sempre impostato ad \constd{AF\_INET6}, il campo \var{sin6\_port} è analogo a quello di IPv4 e segue le stesse regole; il campo \var{sin6\_flowinfo} è a sua volta diviso in tre parti di cui i 24 bit inferiori indicano l'etichetta di flusso, i successivi 4 bit la priorità e @@ -556,19 +613,32 @@ specifici dell'header dei pacchetti IPv6 (vedi sez.~\ref{sec:IP_ipv6head}) ed il loro uso è sperimentale. Il campo \var{sin6\_addr} contiene l'indirizzo a 128 bit usato da IPv6, -espresso da un vettore di 16 byte. Infine il campo \var{sin6\_scope\_id} è un -campo introdotto in Linux con il kernel 2.4, per gestire alcune operazioni -riguardanti il \textit{multicasting}. 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. +espresso da un vettore di 16 byte; anche in questo caso esistono alcuni valori +predediniti, ma essendo il campo un vettore di byte non è possibile assegnarli +con il calore di una costante. Esistono però le variabili predefinite +\var{in6addr\_any} (che indica l'indirizzo generico) e \var{in6addr\_loopback} +(che indica l'indirizzo di loopback) il cui valore può essere copiato in +questo campo. A queste due variabili si aggiungono le macro +\macrod{IN6ADDR\_ANY\_INIT} e \macrod{IN6ADDR\_LOOPBACK\_INIT} per effettuare +delle assegnazioni statiche. + +Infine il campo \var{sin6\_scope\_id} è un campo introdotto in Linux con il +kernel 2.4, per gestire alcune operazioni riguardanti il +\textit{multicasting}, è supportato solo per gli indirizzi di tipo +\textit{link-local} (vedi sez.~\ref{sec:IP_ipv6_unicast}) e deve contenere +l'\textit{interface index} (vedi sez.~\ref{sec:sock_ioctl_netdevice}) della +scheda di rete. Si noti infine che \struct{sockaddr\_in6} ha una dimensione +maggiore della struttura \struct{sockaddr} generica di +fig.~\ref{fig:sock_sa_gen_struct}, quindi occorre stare attenti a non avere +fatto assunzioni riguardo alla possibilità di contenere i dati nelle +dimensioni di quest'ultima (per questo se necessario è opportuno usare +\struct{sockaddr\_storage}). \subsection{La struttura degli indirizzi locali} \label{sec:sock_sa_local} -I socket di tipo \const{PF\_UNIX} o \const{PF\_LOCAL} vengono usati per una +I socket di tipo \const{AF\_UNIX} o \const{AF\_LOCAL} vengono usati per una comunicazione fra processi che stanno sulla stessa macchina (per questo vengono chiamati \textit{local domain} o anche \textit{Unix domain}); essi hanno la caratteristica ulteriore di poter essere creati anche in maniera @@ -585,24 +655,34 @@ fig.~\ref{fig:sock_sa_local_struct}. \end{minipage} \caption{La struttura \structd{sockaddr\_un} degli indirizzi dei socket locali (detti anche \textit{unix domain}) definita in - \headfile{sys/un.h}.} + \headfiled{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 -(mantenuta in uno spazio di nomi astratto). Nel primo caso l'indirizzo viene -specificato come una stringa (terminata da uno zero) corrispondente al -\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. - +In questo caso il campo \var{sun\_family} deve essere \constd{AF\_UNIX}, +mentre il campo \var{sun\_path} deve specificare un indirizzo. Questo ha due +forme; può essere ``\textit{named}'' ed in tal caso deve corrispondere ad un +file (di tipo socket) presente nel filesystem o essere ``\textit{abstract}'' +nel qual caso viene identificato da una stringa univoca in uno spazio di nomi +astratto. + +Nel primo caso l'indirizzo viene specificato in \var{sun\_path} come una +stringa (terminata da uno zero) corrispondente al \textit{pathname} del file; +nel secondo caso (che è specifico di Linux e non portabile) \var{sun\_path} +deve iniziare con uno zero ed il nome verrà costituito dai restanti byte che +verranno interpretati come stringa senza terminazione (un byte nullo non ha in +questo caso nessun significato). + +In realtà esiste una terza forma, \textit{unnamed}, che non è possibile +indicare in fase di scrittura, ma che è quella che viene usata quando si legge +l'indirizzo di un socket anonimo creato con \texttt{socketpair}; in tal caso +la struttura restituita è di dimensione \code{sizeof(sa\_family\_t)}, quindi +\var{sun\_path} non esiste e non deve essere referenziato. \subsection{La struttura degli indirizzi AppleTalk} \label{sec:sock_sa_appletalk} -I socket di tipo \const{PF\_APPLETALK} sono usati dalla libreria +I socket di tipo \const{AF\_APPLETALK} sono usati dalla libreria \file{netatalk} per implementare la comunicazione secondo il protocollo AppleTalk, uno dei primi protocolli di rete usato nel mondo dei personal computer, usato dalla Apple per connettere fra loro computer e stampanti. Il @@ -615,12 +695,12 @@ I socket AppleTalk permettono di usare il protocollo DDP, che è un protocollo a pacchetto, di tipo \const{SOCK\_DGRAM}; l'argomento \param{protocol} di \func{socket} deve essere nullo. È altresì possibile usare i socket raw specificando un tipo \const{SOCK\_RAW}, nel qual caso l'unico valore valido -per \param{protocol} è \const{ATPROTO\_DDP}. +per \param{protocol} è \constd{ATPROTO\_DDP}. Gli indirizzi AppleTalk devono essere specificati tramite una struttura \struct{sockaddr\_atalk}, la cui definizione è riportata in fig.~\ref{fig:sock_sa_atalk_struct}; la struttura viene dichiarata includendo -il file \headfile{netatalk/at.h}. +il file \headfiled{netatalk/at.h}. \begin{figure}[!htb] \footnotesize \centering @@ -632,24 +712,26 @@ il file \headfile{netatalk/at.h}. \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 -\textit{capability} \const{CAP\_NET\_BIND\_SERVICE}. L'indirizzo remoto è -specificato nella struttura \var{sat\_addr}, e deve essere in \textit{network - order} (vedi sez.~\ref{sec:endianness}); esso è composto da un parte di -rete data dal campo \var{s\_net}, che può assumere il valore -\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. +Il campo \var{sat\_family} deve essere sempre \constd{AF\_APPLETALK}, mentre +il campo \var{sat\_port} specifica la porta che identifica i vari +servizi. Valori inferiori a 129 sono usati per le \textsl{porte riservate}, e +possono essere usati solo da processi con i privilegi di amministratore o con +la \textit{capability} \const{CAP\_NET\_BIND\_SERVICE}. + +L'indirizzo remoto è specificato nella struttura \var{sat\_addr}, e deve +essere in \textit{network order} (vedi sez.~\ref{sec:endianness}); esso è +composto da un parte di rete data dal campo \var{s\_net}, che può assumere il +valore \constd{AT\_ANYNET}, che indica una rete generica e vale anche per +indicare la rete su cui si è, il singolo nodo è indicato da \var{s\_node}, e +può prendere il valore generico \constd{AT\_ANYNODE} che indica anche il nodo +corrente, ed il valore \constd{ATADDR\_BCAST} che indica tutti i nodi della +rete. \subsection{La struttura degli indirizzi dei \textit{packet socket}} \label{sec:sock_sa_packet} -I \textit{packet socket}, identificati dal dominio \const{PF\_PACKET}, sono +I \textit{packet socket}, identificati dal dominio \const{AF\_PACKET}, sono un'interfaccia specifica di Linux per inviare e ricevere pacchetti direttamente su un'interfaccia di rete, senza passare per le funzioni di gestione dei protocolli di livello superiore. In questo modo è possibile @@ -671,12 +753,14 @@ comunque il pacchetto, riempiendo gli opportuni campi della struttura \struct{sockaddr\_ll} ad esso associata. Si usano invece socket di tipo \const{SOCK\_DGRAM} quando si vuole operare a -livello di rete. In questo caso in fase di ricezione l'intestazione del -protocollo di collegamento viene rimossa prima di passare il resto del -pacchetto all'utente, mentre in fase di trasmissione viene creata una -opportuna intestazione per il protocollo a livello di collegamento -utilizzato, usando le informazioni necessarie che devono essere specificate -sempre con una struttura \struct{sockaddr\_ll}. +livello di rete. + +In questo caso in fase di ricezione l'intestazione del protocollo di +collegamento viene rimossa prima di passare il resto del pacchetto all'utente, +mentre in fase di trasmissione viene creata una opportuna intestazione per il +protocollo a livello di collegamento utilizzato, usando le informazioni +necessarie che devono essere specificate sempre con una struttura +\struct{sockaddr\_ll}. Nella creazione di un \textit{packet socket} il valore dell'argomento \param{protocol} di \func{socket} serve a specificare, in \textit{network @@ -684,7 +768,7 @@ Nella creazione di un \textit{packet socket} il valore dell'argomento utilizzare. I valori possibili sono definiti secondo lo standard IEEE 802.3, e quelli disponibili in Linux sono accessibili attraverso opportune costanti simboliche definite nel file \file{linux/if\_ether.h}. Se si usa il valore -speciale \const{ETH\_P\_ALL} passeranno sul \textit{packet socket} tutti i +speciale \constd{ETH\_P\_ALL} passeranno sul \textit{packet socket} tutti i pacchetti, qualunque sia il loro protocollo di collegamento. Ovviamente l'uso di questi socket è una operazione privilegiata e può essere effettuati solo da un processo con i privilegi di amministratore (\ids{UID} effettivo nullo) o @@ -693,7 +777,8 @@ con la \textit{capability} \const{CAP\_NET\_RAW}. Una volta aperto un \textit{packet socket}, tutti i pacchetti del protocollo specificato passeranno attraverso di esso, qualunque sia l'interfaccia da cui provengono; se si vuole limitare il passaggio ad una interfaccia specifica -occorre usare la funzione \func{bind} per agganciare il socket a quest'ultima. +occorre usare la funzione \func{bind} (vedi sez.~\ref{sec:TCP_func_bind}) per +agganciare il socket a quest'ultima. \begin{figure}[!htb] \footnotesize \centering @@ -714,24 +799,25 @@ scrivere tutto direttamente nel pacchetto, quindi la struttura non serve più a specificare gli indirizzi. Essa mantiene questo ruolo solo per i socket di tipo \const{SOCK\_DGRAM}, per i quali permette di specificare i dati necessari al protocollo di collegamento, mentre viene sempre utilizzata in lettura (per -entrambi i tipi di socket), per la ricezione dei i dati relativi a ciascun +entrambi i tipi di socket), per la ricezione dei dati relativi a ciascun pacchetto. Al solito il campo \var{sll\_family} deve essere sempre impostato al valore -\const{AF\_PACKET}. Il campo \var{sll\_protocol} indica il protocollo scelto, +\constd{AF\_PACKET}. Il campo \var{sll\_protocol} indica il protocollo scelto, e deve essere indicato in \textit{network order}, facendo uso delle costanti simboliche definite in \file{linux/if\_ether.h}. Il campo \var{sll\_ifindex} è -l'indice dell'interfaccia, che, in caso di presenza di più interfacce dello -stesso tipo (se ad esempio si hanno più schede ethernet), permette di -selezionare quella con cui si vuole operare (un valore nullo indica qualunque -interfaccia). Questi sono i due soli campi che devono essere specificati -quando si vuole selezionare una interfaccia specifica, usando questa struttura -con la funzione \func{bind}. +l'indice dell'interfaccia (l'\textit{inxterface index} (vedi +sez.~\ref{sec:sock_ioctl_netdevice}) che in caso di presenza di più +interfacce dello stesso tipo (se ad esempio si hanno più schede Ethernet), +permette di selezionare quella con cui si vuole operare (un valore nullo +indica qualunque interfaccia). Questi sono i due soli campi che devono essere +specificati quando si vuole selezionare una interfaccia specifica, usando +questa struttura con la funzione \func{bind}. I campi \var{sll\_halen} e \var{sll\_addr} indicano rispettivamente l'indirizzo associato all'interfaccia sul protocollo di collegamento e la relativa lunghezza; ovviamente questi valori cambiano a seconda del tipo di -collegamento che si usa, ad esempio, nel caso di ethernet, questi saranno il +collegamento che si usa, ad esempio, nel caso di Ethernet, questi saranno il MAC address della scheda e la relativa lunghezza. Essi vengono usati, insieme ai campi \var{sll\_family} e \var{sll\_ifindex} quando si inviano dei pacchetti, in questo caso tutti gli altri campi devono essere nulli. @@ -740,14 +826,13 @@ 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: \const{PACKET\_HOST} per un pacchetto indirizzato alla -macchina ricevente, \const{PACKET\_BROADCAST} per un pacchetto di -\textit{broadcast}, \const{PACKET\_MULTICAST} per un pacchetto inviato ad un -indirizzo fisico di \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. - +seguenti valori: \constd{PACKET\_HOST} per un pacchetto indirizzato alla +macchina ricevente, \constd{PACKET\_BROADCAST} per un pacchetto di +\textit{broadcast}, \constd{PACKET\_MULTICAST} per un pacchetto inviato ad un +indirizzo fisico di \textit{multicast}, \constd{PACKET\_OTHERHOST} per un +pacchetto inviato ad un'altra stazione (e ricevuto su un'interfaccia in modo +promiscuo), \constd{PACKET\_OUTGOING} per un pacchetto originato dalla propria +macchina che torna indietro sul socket. Si tenga presente infine che in fase di ricezione, anche se si richiede il troncamento del pacchetto, le funzioni \func{recv}, \func{recvfrom} e @@ -757,13 +842,15 @@ 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 +%% I socket di tipo \const{AF\_DECnet} usano il protocollo DECnet, usato dai VAX %% Digital sotto VMS quando ancora il TCP/IP non era diventato lo standard di %% fatto. Il protocollo è un protocollo chiuso, ed il suo uso attuale è limitato %% alla comunicazione con macchine che stanno comunque scomparendo. Lo si riporta %% solo come esempio +% TODO aggiungere AF_CAN, vedi http://lwn.net/Articles/253425, dal 2.6.25 ? + % TODO: trattare i socket RDS, vedi documentazione del kernel, file % Documentation/networking/rds.txt @@ -773,11 +860,12 @@ lunghezza effettiva del pacchetto così come arrivato sulla linea. \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 nel cosiddetto \textit{network order}, che corrisponde al formato \textit{big - endian}, anche quando la proprio macchina non usa questo formati, cosa che -può comportare la necessità di eseguire delle conversioni. + endian} (vedi sez.~\ref{sec:endianness}), anche quando la proprio macchina +non usa questo formato, cosa che può comportare la necessità di eseguire delle +conversioni. \subsection{Le funzioni per il riordinamento} @@ -787,32 +875,33 @@ Come già visto in sez.~\ref{sec:endianness} il problema connesso all'\textit{endianness} è 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 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}, \funcd{htons}, -\funcd{ntohl} e \funcd{ntohs} ed i rispettivi prototipi sono: -\begin{functions} - \headdecl{netinet/in.h} - \funcdecl{unsigned long int htonl(unsigned long int hostlong)} - Converte l'intero a 32 bit \param{hostlong} dal formato della macchina a - quello della rete. - - \funcdecl{unsigned short int htons(unsigned short int hostshort)} - Converte l'intero a 16 bit \param{hostshort} dal formato della macchina a - quello della rete. - - \funcdecl{unsigned long int ntohl(unsigned long int netlong)} - Converte l'intero a 32 bit \param{netlong} dal formato della rete a quello - della macchina. - - \funcdecl{unsigned sort int ntohs(unsigned short int netshort)} - Converte l'intero a 16 bit \param{netshort} dal formato della rete a quello - della macchina. - - \bodydesc{Tutte le funzioni restituiscono il valore convertito, e non - prevedono errori.} -\end{functions} +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}, \funcd{htons}, \funcd{ntohl} e \funcd{ntohs} ed i +rispettivi prototipi sono: + +\begin{funcproto}{ +\fhead{arpa/inet.h} +\fdecl{unsigned long int htonl(unsigned long int hostlong)} +\fdesc{Converte l'intero a 32 bit \param{hostlong} dal formato della macchina a + quello della rete.} +\fdecl{unsigned short int htons(unsigned short int hostshort)} +\fdesc{Converte l'intero a 16 bit \param{hostshort} dal formato della macchina a + quello della rete.} +\fdecl{unsigned long int ntohl(unsigned long int netlong)} +\fdesc{Converte l'intero a 32 bit \param{netlong} dal formato della rete a + quello della macchina.} +\fdecl{unsigned sort int ntohs(unsigned short int netshort)} +\fdesc{Converte l'intero a 16 bit \param{netshort} dal formato della rete a + quello della macchina.} +} + +{Tutte le funzioni restituiscono il valore convertito, e non prevedono + errori.} +\end{funcproto} I nomi sono assegnati usando la lettera \texttt{n} come mnemonico per indicare l'ordinamento usato sulla rete (da \textit{network order}) e la lettera @@ -828,63 +917,112 @@ sempre utilizzate, anche quando potrebbero non essere necessarie, in modo da assicurare la portabilità del codice su tutte le architetture. -\subsection{Le funzioni \func{inet\_aton}, \func{inet\_addr} e - \func{inet\_ntoa}} +\subsection{Le funzioni di conversione per gli indirizzi IPv4} \label{sec:sock_func_ipv4} -Un secondo insieme di funzioni di manipolazione serve per passare dal formato -binario usato nelle strutture degli indirizzi alla rappresentazione simbolica -dei numeri IP che si usa normalmente. +Un secondo insieme di funzioni di manipolazione è quello che serve per passare +dalla rappresentazione simbolica degli indirizzi IP al formato binario +previsto dalla struttura degli indirizzi di +fig.~\ref{fig:sock_sa_ipv4_struct}, e viceversa. La notazione più comune è la +cosiddetta notazione \itindex{dotted-decimal} \textit{dotted-decimal}, che +prevede che gli indirizzi IPv4 siano indicati con l'espressione del valore +numerico decimale di ciascuno dei 4 byte che li costituiscono separati da un +punto (ad esempio \texttt{192.168.0.1}). + +In realtà le funzioni che illustreremo supportano una notazione che più +propriamente dovrebbe esser chiamata \textit{numbers-and-dot} in quanto il +valore può essere indicato con numeri espressi sia in decimale, che in ottale +(se indicati apponendo uno zero) che in esadecimale (se indicati apponendo +\texttt{0x}). Inoltre per la parte meno significativa dell'espressione, quella +che riguarda l'indirizzo locale, si può usare, eliminando altrettanti punti, +valori a 16 o a 24 bit, e togliendo tutti i punti, si può usare anche +direttamente un valore numerico a 32 bit.\footnote{la funzionalità si trova + anche in gran parte dei programmi che usano indirizzi di rete, e deriva + direttamente da queste funzioni.} + +Tradizionalmente la conversione di un indirizzo \textit{dotted-decimal} al +valore numerico veniva eseguita dalla funzione \funcd{inet\_addr} (prevista +fin dalle origini in BSD e inclusa in POSIX.1-2001) il cui prototipo è: + +\begin{funcproto}{ +\fhead{arpa/inet.h} +\fdecl{in\_addr\_t inet\_addr(const char *strptr)} +\fdesc{Converte la stringa dell'indirizzo \textit{dotted decimal} in nel + numero IP in network order.} +} + +{La funzione ritorna il valore dell'indirizzo in caso di successo e + \const{INADDR\_NONE} per un errore e non genera codici di errore.} +\end{funcproto} -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 -\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}, -\funcd{inet\_aton} e \funcd{inet\_ntoa}, ed i rispettivi prototipi sono: -\begin{functions} - \headdecl{arpa/inet.h} - - \funcdecl{in\_addr\_t inet\_addr(const char *strptr)} Converte la stringa - dell'indirizzo \textit{dotted decimal} in nel numero IP in network order. +La prima funzione, \func{inet\_addr}, restituisce l'indirizzo a 32 bit in +\textit{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 dato che genererebe comunque +un errore; per questo motivo essa è generalmente deprecata in favore di +\func{inet\_aton}. + +Per effettuare la conversione inversa la funzione usata tradizionalmente è +\funcd{inet\_ntoa}, anch'essa presente fin da BSD 4.3, in cui si riprende la +notazione già vista in sez.~\ref{sec:sock_func_ord} che usa la lettera +\texttt{n} come mnemonico per indicare la rete ed \texttt{a} (per ASCII) come +mnemonico per indicare la stringa corrispodente all'indirizzo; il suo +prototipo è: - \funcdecl{int inet\_aton(const char *src, struct in\_addr *dest)} Converte - la stringa dell'indirizzo \textit{dotted decimal} in un indirizzo IP. +\begin{funcproto}{ +\fhead{arpa/inet.h} +\fdecl{char *inet\_ntoa(struct in\_addr addrptr)} +\fdesc{Converte un indirizzo IP in una stringa \textit{dotted decimal}.} +} - \funcdecl{char *inet\_ntoa(struct in\_addr addrptr)} - Converte un indirizzo IP in una stringa \textit{dotted decimal}. +{La funzione l'indirizzo della stringa con il valore dell'indirizzo convertito + e non prevede errori.} +\end{funcproto} - \bodydesc{Tutte queste le funzioni non generano codice di errore.} -\end{functions} +La funzione converte il valore a 32 bit dell'indirizzo, espresso in +\textit{network order}, e preso direttamente con un puntatore al relativo +campo della struttura degli indirizzi, restituendo il puntatore alla stringa +che contiene l'espressione in formato \textit{dotted-decimal}. Si deve tenere +presente che la stringa risiede in un segmento di memoria statica, per cui +viene riscritta ad ogni chiamata e la funzione non è rientrante. -La prima funzione, \func{inet\_addr}, restituisce l'indirizzo a 32 bit in -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 -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 -modo da poterla usare direttamente con il puntatore usato per passare la -struttura degli indirizzi). La funzione restituisce un valore diverso da zero -se l'indirizzo è valido e la conversione ha successo e 0 in caso contrario. -Se usata con \param{dest} inizializzato a \val{NULL} effettua la validazione -dell'indirizzo. - -L'ultima funzione, \func{inet\_ntoa}, converte il valore a 32 bit -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. - - -\subsection{Le funzioni \func{inet\_pton} e \func{inet\_ntop}} +Per rimediare ai problemi di \funcd{inet\_addr} è stata sostituita da +\funcd{inet\_aton}, che però non è stata standardizzata e non è presente in +POSIX.1-2001, anche se è definita sulla gran parte dei sistemi Unix; il suo +prototipo è: + +\begin{funcproto}{ +\fhead{arpa/inet.h} +\fdecl{int inet\_aton(const char *src, struct in\_addr *dest)} +\fdesc{Converte la stringa dell'indirizzo \textit{dotted decimal} in un + indirizzo IP.} +} + +{La funzione ritorna un valore non nullo in caso di successo e $0$ per un + errore e non genera codici di errore.} +\end{funcproto} + +La funzione 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 modo da poterla +usare direttamente con il puntatore usato per passare la struttura degli +indirizzi). La funzione restituisce un valore diverso da zero se l'indirizzo è +valido e la conversione ha successo e 0 in caso contrario. Se usata +con \param{dest} inizializzato a \val{NULL} può essere usata per effettuare la +validazione dell'indirizzo espresso da \param{src}. + +Oltre a queste tre funzioni esistono le ulteriori \funcm{inet\_lnaof}, +\funcm{inet\_netof} e \funcm{inet\_makeaddr} che assumono la ormai obsoleta e +deprecata suddivisione in classi degli indirizzi IP per fornire la parte di +rete e quella di indirizzo locale. Ad oggi il loro uso non ha più alcun senso +per ciò non le tratteremo. + + +\subsection{Le funzioni di conversione per indirizzi IP generici} \label{sec:sock_conv_func_gen} Le tre funzioni precedenti sono limitate solo ad indirizzi IPv4, per questo @@ -898,47 +1036,61 @@ 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 prima funzione, \funcd{inet\_pton}, serve a convertire una stringa in un indirizzo; il suo prototipo è: -\begin{prototype}{sys/socket.h} -{int inet\_pton(int af, const char *src, void *addr\_ptr)} - Converte l'indirizzo espresso tramite una stringa nel valore numerico. - - \bodydesc{La funzione restituisce un valore negativo se \param{af} specifica - una famiglia di indirizzi non valida, con \var{errno} che assume il valore - \errcode{EAFNOSUPPORT}, un valore nullo se \param{src} non rappresenta un - indirizzo valido, ed un valore positivo in caso di successo.} -\end{prototype} +\begin{funcproto}{ +\fhead{sys/socket.h} +\fdecl{int inet\_pton(int af, const char *src, void *addr\_ptr)} +\fdesc{Converte l'indirizzo espresso tramite una stringa nel valore numerico.} +} + +{La funzione ritorna $1$ in caso di successo, $0$ se \param{src} non contiene + una rappresentazione valida per la famiglia di indirizzi indicati + da \param{af} e $-1$ se \param{af} specifica una famiglia di indirizzi non + valida, e solo in quest'ultimo caso \var{errno} assumerà il valore + \errcode{EAFNOSUPPORT}. +} +\end{funcproto} La funzione converte la stringa indicata tramite \param{src} nel valore numerico dell'indirizzo IP del tipo specificato da \param{af} che viene -memorizzato all'indirizzo puntato da \param{addr\_ptr}, la funzione -restituisce un valore positivo in caso di successo, nullo se la stringa non -rappresenta un indirizzo valido, e negativo se \param{af} specifica una -famiglia di indirizzi non valida. +memorizzato all'indirizzo puntato da \param{addr\_ptr}. La funzione supporta +per IPv4 la sola notazione \textit{dotted-decimal}, e non quella più completa +\textit{number-and-dot} che abbiamo visto per \func{inet\_aton}. Per IPv6 la +notazione prevede la suddivisione dei 128 bit dell'indirizzo in 16 parti di 16 +bit espresse con valori esadecimali separati dal carattere ``\texttt{:}'' ed +una serie di valori nulli possono essere sostituiti (una sola volta, sempre a +partire dalla sinistra) con la notazione ``\texttt{::}'', un esempio di +indirizzo in questa forma potrebbe essere \texttt{2001:db8::8:ba98:2078:e3e3}, +per una descrizione più completa si veda sez.~\ref{sec:IP_ipv6_notation}. 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. - - \bodydesc{La funzione restituisce un puntatore non nullo alla stringa - convertita in caso di successo e \val{NULL} in caso di fallimento, nel - qual caso \var{errno} assume i valori: - \begin{errlist} + +\begin{funcproto}{ +\fhead{sys/socket.h} +\fdecl{char *inet\_ntop(int af, const void *addr\_ptr, char *dest, size\_t len)} +\fdesc{Converte l'indirizzo dalla relativa struttura in una stringa simbolica.} +} + +{La funzione ritorna un puntatore non nullo alla stringa convertita in caso di + successo e \val{NULL} per un errore, nel qual caso \var{errno} assumerà uno + dei valori: + \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 è una valida. - \end{errlist}} -\end{prototype} + \end{errlist} +} +\end{funcproto} + La funzione converte la struttura dell'indirizzo puntata da \param{addr\_ptr} in una stringa che viene copiata nel buffer puntato dall'indirizzo \param{dest}; questo deve essere preallocato dall'utente e la lunghezza deve -essere almeno \const{INET\_ADDRSTRLEN} in caso di indirizzi IPv4 e -\const{INET6\_ADDRSTRLEN} per indirizzi IPv6; la lunghezza del buffer deve -comunque venire specificata attraverso il parametro \param{len}. +essere almeno \constd{INET\_ADDRSTRLEN} in caso di indirizzi IPv4 e +\constd{INET6\_ADDRSTRLEN} per indirizzi IPv6; la lunghezza del buffer deve +comunque essere specificata con il parametro \param{len}. Gli indirizzi vengono convertiti da/alle rispettive strutture di indirizzo (una struttura \struct{in\_addr} per IPv4, e una struttura \struct{in6\_addr} @@ -946,12 +1098,6 @@ 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. -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. - - -