Dopo una breve panoramica sulle caratteristiche di questa interfaccia vedremo
come creare un socket e come collegarlo allo specifico protocollo di rete che
-utilizzerà per la comunicazione. Per evitare una introduzione puramente teorica
+utilizzerà per la comunicazione. Per evitare un'introduzione puramente teorica
concluderemo il capitolo con un primo esempio di applicazione.
\section{Una panoramica}
\label{sec:sock_socket_def}
Il \textit{socket}\footnote{una traduzione letterale potrebbe essere
- \textsl{manicotto}, ma essendo universalmente noti come socket utilizzeremo
- sempre la parola inglese} è uno dei principali meccanismi di comunicazione
-fra programmi utilizzato in ambito unix. Il socket costituisce in sostanza un
+ \textsl{presa}, ma essendo universalmente noti come socket utilizzeremo
+ sempre la parola inglese.} è uno dei principali meccanismi di comunicazione
+fra programmi utilizzato in ambito Unix. Il socket costituisce in sostanza un
canale di comunicazione fra due processi su cui si possono leggere e scrivere
dati analogo a quello di una pipe ma a differenza di questa e degli altri
meccanismi esaminati nel capitolo \capref{cha:IPC} i socket non sono limitati
utilizzare fra quelli disponibili nella famiglia scelta. Le API permettono di
scegliere lo stile di comunicazione indicando il tipo di socket; Linux e le
glibc mettono a disposizione i seguenti tipi di socket (che il manuale della
-glibc chiama \textit{styles}) definiti come \type{int} in \file{socket.h}:
+glibc chiama \textit{styles}) definiti come \ctyp{int} in \file{socket.h}:
\begin{list}{}{}
\item \macro{SOCK\_STREAM} Provvede un canale di trasmissione dati
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 \type{void *}), ma l'interfaccia dei socket è antecedente alla
+(i \ctyp{void *}), ma l'interfaccia dei socket è antecedente alla
definizione dello standard ANSI, e per questo nel 1982 fu scelto di definire
una struttura generica \type{sockaddr} per gli indirizzi dei socket mostrata
in \nfig:
\centering
\begin{tabular}{|l|l|l|}
\hline
- \multicolumn{1}{|c|}{Tipo}& \multicolumn{1}{|c|}{Descrizione}&
- \multicolumn{1}{|c|}{Header} \\
+ \multicolumn{1}{|c|}{\textbf{Tipo}}&
+ \multicolumn{1}{|c|}{\textbf{Descrizione}}&
+ \multicolumn{1}{|c|}{\textbf{Header}} \\
\hline
\hline
\type{int8\_t} & intero a 8 bit con segno & \file{sys/types.h}\\
\hline
\type{sa\_family\_t} & famiglia degli indirizzi& \file{sys/socket.h}\\
\type{socklen\_t} & lunghezza (\type{uint32\_t}) dell'indirizzo di
- un socket& \type{sys/socket.h}\\
+ un socket& \file{sys/socket.h}\\
\hline
- \type{in\_addr\_t} & indirizzo IPv4 (\file{uint32\_t}) &
- \type{netinet/in.h}\\
- \type{in\_port\_t} & porta TCP o UDP (\file{uint16\_t})&
- \type{netinet/in.h}\\
+ \type{in\_addr\_t} & indirizzo IPv4 (\type{uint32\_t}) &
+ \file{netinet/in.h}\\
+ \type{in\_port\_t} & porta TCP o UDP (\type{uint16\_t})&
+ \file{netinet/in.h}\\
\hline
\end{tabular}
\caption{Tipi di dati usati nelle strutture degli indirizzi, secondo quanto
aggiuntivo \var{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 esiste. Il campo
-\type{sa\_family\_t} era storicamente un \type{unsigned short}.
+\type{sa\_family\_t} era storicamente un \ctyp{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
\var{sa\_family} con cui determinare il tipo di indirizzo; per questo
-motivo, anche se l'uso di un puntatore \type{void *} sarebbe più immediato
+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.
\subsection{La struttura degli indirizzi IPv6}
\label{sec:sock_sa_ipv6}
-Essendo IPv6 una estensione di IPv4 i socket di tipo \macro{PF\_INET6} sono
+Essendo IPv6 un'estensione di IPv4 i socket di tipo \macro{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 \file{netinet/in.h}.
l'ordinamento usato sulla rete (da \textit{network order}) e la lettera
\texttt{h} come mnemonico per l'ordinamento usato sulla macchina locale (da
\textit{host order}), mentre le lettere \texttt{s} e \texttt{l} stanno ad
-indicare i tipi di dato (\type{long} o \type{short}, riportati anche dai
+indicare i tipi di dato (\ctyp{long} o \ctyp{short}, riportati anche dai
prototipi).
Usando queste funzioni si ha la conversione automatica: nel caso in cui la
socket in tutte le chiamate successive. Nel caso la chiamata fallisca si
stampa un errore con la relativa routine e si esce.
-Il passo seguente (\texttt{\small 19--27}) è quello di costruire una apposita
+Il passo seguente (\texttt{\small 19--27}) è quello di costruire un'apposita
struttura \type{sockaddr\_in} in cui sarà inserito l'indirizzo del server ed
il numero della porta del servizio. Il primo passo è inizializzare tutto a
zero, per poi inserire il tipo di protocollo e la porta (usando per
come demone di sistema (che è in esecuzione anche quando non c'è nessuna shell
attiva e il terminale da cui lo si è lanciato è stato sconnesso),
occorrerebbero delle opportune modifiche.
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End:
projects / gapil.git / blobdiff