Il \textit{socket} (traducibile liberamente come \textsl{manicotto}) è uno dei
principali meccanismi di comunicazione fra programmi utilizzato in ambito unix
(e non solo). Il socket costituisce in sostanza un canale di comunicazione fra
-due processi su cui si possono leggere e scrivere dati.
-
-La creazione di un socket restituisce un file descriptor con un comportamento
-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 attraverso la rete.
+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
+attraverso la rete.
Quella dei socket costituisce infatti la principale API (\textit{Application
Program Interface}) usata nella programmazione di rete. La loro origine
la comunicazione, ad esempio se è inaffidabile occorrerà essere in grado di
gestire la perdita o il rimescolamento dei dati.
+
+\section{La funzione \texttt{socket}}
+\label{sec:sock_socket}
+
+La creazione di un socket avviene attraverso l'uso della funzione
+\texttt{socket} questa restituisce un \textit{socket descriptor} (un valore
+intero non negativo) che come gli analoghi file descriptor di files e alle
+pipes serve come riferimento al socket; in sostanza è l'indice nella tabella
+dei file che contiene i puntatori alle opportune strutture usate dal kernel ed
+allocate per ogni processo, (la stessa usata per i files e le pipes [NdA
+verificare!]).
+
+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}).
+
+\begin{itemize}
+\item \texttt{int socket(int domain, int type, int protocol)}
+
+ La funzione restituisce un intero positivo se riesce, e -1 se fallisce, in
+ quest'ultimo caso la variabile \texttt{errno} è settata con i seguenti
+ codici di errore:
+
+ \begin{itemize}
+ \item \texttt{EPROTONOSUPPORT} Il tipo di socket o il protocollo scelto non
+ sono supportati nel dominio.
+ \item \texttt{ENFILE} Il kernel non ha memoria sufficiente a creare una
+ nuova struttura per il socket.
+ \item \texttt{EMFILE} Si è ecceduta la tabella dei file.
+ \item \texttt{EACCES} Non si hanno privilegi per creare un socket nel
+ dominio o con il protocollo specificato.
+ \item \texttt{EINVAL} Protocollo sconosciuto o dominio non disponibile.
+ \item \texttt{ENOBUFS} o \texttt{ENOMEM} Non c'è sufficiente memoria per
+ creare il socket.
+ \end{itemize}
+\end{itemize}
+
+Si noti che la creazione del socket non comporta nulla riguardo
+all'indicazione degli indirizzi remoti o locali attraverso i quali si vuole
+effettuare la comunicazione.
+
+\subsection{Il dominio, o \textit{protocol family}}
+\label{sec:sock_domain}
+
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
\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}, nome che useremo anche noi; 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.
+\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.
+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 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.
-I domini (e i relativi nomi simbolici) sono definiti dall'header
-\textit{socket.h}. In linux sono disponibili le famiglie di protocolli
-riportate in \ntab.
+I domini (e i relativi nomi simbolici), così come i nomi delle famiglie di
+indirizzi sono definiti dall'header \textit{socket.h}. In linux le famiglie di
+protocolli disponibili sono riportate in \ntab.
\begin{table}[htb]
+ \footnotesize
\centering
\begin{tabular}[c]{lll}
Nome & Utilizzo & Man page \\
\label{tab:net_pf_names}
\end{table}
+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}
+\label{sec:sock_type}
+
La scelta di un dominio non comporta però la scelta dello stile di
comunicazione, questo infatti viene a dipendere dal protocollo che si andrà ad
utilizzare fra quelli disponibili nella famiglia scelta. Le API permettono di
\item \texttt{SOCK\_PACKET} Obsoleto, non deve essere usato.
\end{list}
+Si tenga presente che non tutte le combinazioni di famiglia di protocolli e
+tipo di socket sono valide, in quanto non è detto che nella famiglia esista un
+protocollo per tutti gli stili di comunicazione indicati qui sopra. Una
+tabella che mostra le combinazioni valide è la seguente:
+
+\begin{table}[htb]
+ \footnotesize
+ \centering
+ \begin{tabular}{l|c|c|c|c|c|}
+ \multicolumn{1}{c}{} &\multicolumn{1}{c}{\texttt{SOCK\_STREAM}}&
+ \multicolumn{1}{c}{\texttt{SOCK\_DGRAM}} &
+ \multicolumn{1}{c}{\texttt{SOCK\_RAW}} &
+ \multicolumn{1}{c}{\texttt{SOCK\_PACKET}}&
+ \multicolumn{1}{c}{\texttt{SOCK\_SEQPACKET}} \\
+ \cline{2-6}
+ \texttt{PF\_UNIX} & si & si & & & \\
+ \cline{2-6}
+ \texttt{PF\_INET} & TCP & UDP & IPv4 & & \\
+ \cline{2-6}
+ \texttt{PF\_INET6} & TCP & UDP & IPv6 & & \\
+ \cline{2-6}
+ \texttt{PF\_IPX} & & & & & \\
+ \cline{2-6}
+ \texttt{PF\_NETLINK} & & si & si & & \\
+ \cline{2-6}
+ \texttt{PF\_X25} & & & & & si \\
+ \cline{2-6}
+ \texttt{PF\_AX25} & & & & & \\
+ \cline{2-6}
+ \texttt{PF\_ATMPVC} & & & & & \\
+ \cline{2-6}
+ \texttt{PF\_APPLETALK} & & si & si & & \\
+ \cline{2-6}
+ \texttt{PF\_PACKET} & & si & si & & \\
+ \cline{2-6}
+ \end{tabular}
+ \caption{Combinazioni valide di dominio e tipo di protocollo per la funzione \texttt{socket}.}
+ \label{tab:sock_sock_valid_combinations}
+\end{table}
+
+Dove 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.
+
+\section{Le strutture degli indirizzi dei socket}
+\label{sec:sock_sockaddr}
+
+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.
+
+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_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}
+
+
+
+
+\chapter{Socket TCP elementari}
+\label{cha:elem_TCP_sock}
+
+Esamineremo in questo capitolo quanto necessario per capire come scrivere un
+client e un server TCP, riprendendo quanto visto in \ref{sec:net_cli_sample} e
+\ref{sec:net_cli_server}.
+
+
+
+\subsection{Creazione e terminazione della connessione TCP}
+
+Per capire il funzionamento delle funzioni della interfaccia dei socket che
+operano con TCP (le varie \texttt{connect}, \texttt{accept}, \texttt{close}
+che abbiamo visto negli esempi iniziali e su cui torneremo più avanti) è
+fodamentale capire come funziona la creazione e la conclusione di una
+connessione TCP.
+
+\subsection{Le porte}
+
projects / gapil.git / blobdiff