X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=socket.tex;h=a8c697b378b86b3d8755a92f3b018b6e846bd8ef;hp=52d4809000ebe950948325cbdaaafc443970157c;hb=2270d0dd8cf9460e3aef8d5ffa2bf5c825707e58;hpb=8be8c7db6968087cfeebe972614884a71ca12178 diff --git a/socket.tex b/socket.tex index 52d4809..a8c697b 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-2016 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", @@ -227,7 +227,7 @@ comunicazione. \constd{PF\_PPPOX} &24& PPPoX socket & \\ \constd{PF\_WANPIPE} &25& Wanpipe API socket & \\ \constd{PF\_LLC} &26& Linux LLC & \\ - \constd{PF\_CAN} &29& Controller Are network & \\ + \constd{PF\_CAN} &29& Controller Are Network & \\ \constd{PF\_BLUETOOTH}&31& Bluetooth socket & \\ \hline \end{tabular} @@ -342,27 +342,27 @@ appena elencati. &\const{SOCK\_STREAM} &\const{SOCK\_DGRAM} &\const{SOCK\_RAW}& \const{SOCK\_RDM}&\const{SOCK\_SEQPACKET} \\ \hline - \const{PF\_LOCAL} & si & si & & & \\ + \const{PF\_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{PF\_LOCAL}&\multicolumn{5}{|c|}{sinonimo di \const{PF\_UNIX}}\\ \hline - \const{PF\_INET6} & TCP & UDP & IPv6 & & \\ + \const{PF\_INET} & TCP & UDP & IPv4 & -- & -- \\ \hline - \const{PF\_IPX} & & & & & \\ + \const{PF\_INET6} & TCP & UDP & IPv6 & -- & -- \\ \hline - \const{PF\_NETLINK} & & si & si & & \\ + \const{PF\_IPX} & -- & -- & -- & -- & -- \\ \hline - \const{PF\_X25} & & & & & si \\ + \const{PF\_NETLINK} & -- & si & si & -- & -- \\ \hline - \const{PF\_AX25} & & & & & \\ + \const{PF\_X25} & -- & -- & -- & -- & si \\ \hline - \const{PF\_ATMPVC} & & & & & \\ + \const{PF\_AX25} & -- & -- & -- & -- & -- \\ \hline - \const{PF\_APPLETALK} & & si & si & & \\ + \const{PF\_ATMPVC} & -- & -- & -- & -- & -- \\ \hline - \const{PF\_PACKET} & & si & si & & \\ + \const{PF\_APPLETALK} & -- & si & si & -- & -- \\ + \hline + \const{PF\_PACKET} & -- & si & si & -- & -- \\ \hline \end{tabular} \caption{Combinazioni valide di dominio e tipo di protocollo per la @@ -370,11 +370,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} @@ -474,12 +477,22 @@ 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}, anzi, come +vedremo in sez.~\ref{sec:sock_sa_ipv6}, nel caso di indirizzi IPv6 questa +non è proprio sufficiente. Per questo l'interfaccia di programmazione dei +socket prevede la defizione di una speciale struttura +\struct{sockaddr\_storage} per la quale è assicurato che la dimensione sia +sufficiente per qualunque + \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 +attraverso Internet; la struttura per gli indirizzi per un socket Internet (se si usa IPv4) è definita come \struct{sockaddr\_in} nell'header file \headfiled{netinet/in.h} ed ha la forma mostrata in fig.~\ref{fig:sock_sa_ipv4_struct}, conforme allo standard POSIX.1g. @@ -490,12 +503,12 @@ 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 @@ -511,7 +524,7 @@ 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 \dirct{union} usata per accedere alle diverse classi di indirizzi) che direttamente come intero. In \headfile{netinet/in.h} vengono definite anche @@ -721,7 +734,7 @@ Al solito il campo \var{sll\_family} deve essere sempre impostato al valore 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 +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 @@ -730,7 +743,7 @@ 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. @@ -747,7 +760,6 @@ 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 \func{recvmsg} (vedi sez.~\ref{sec:net_sendmsg}) restituiranno comunque la @@ -772,11 +784,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} @@ -786,32 +799,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. +suddiviso scambiati di posto. - \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. +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: - \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} +\begin{funcproto}{ +\fhead{netinet/in.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