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
-alla comunicazione fra processi che girano sulla stessa macchina ma possono
-effettuare la comunicazione anche attraverso la rete.
+dati analogo a quello di una pipe (vedi \secref{sec:ipc_pipes}) ma a
+differenza di questa e degli altri meccanismi esaminati nel capitolo
+\capref{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
risale al 1983, quando furono introdotti nel BSD 4.2; l'interfaccia è rimasta
sostanzialmente la stessa con piccole modifiche negli anni successivi. Benché
-siano state sviluppate interfacce alternative, originate dai sistemi SYSV,
+siano state sviluppate interfacce alternative, originate dai sistemi SVr4,
come la XTI (\textit{X/Open Transport Interface}) nessuna ha mai raggiunto la
-diffusione e la popolarità di quella dei socket (né tantomeno usabilità e
-flessibilità).
+diffusione e la popolarità di quella dei socket (né tantomeno la stessa
+usabilità e flessibilità).
La flessibilità e la genericità dell'interfaccia inoltre ha consentito di
utilizzare i socket con i più disparati meccanismi di comunicazione, e non
Per questo motivo una semplice descrizione dell'interfaccia è assolutamente
inutile, in quanto il comportamento di quest'ultima e le problematiche da
-affrontare cambiano radicalmente a seconda dello ``stile'' di comunicazione
-usato. La scelta di questo stile va infatti ad incidere sulla semantica che
-verrà utilizzata a livello utente per gestire la comunicazione (su come
-inviare e ricevere i dati) e sul comportamento effettivo delle funzioni
-utilizzate.
+affrontare cambiano radicalmente a seconda dello \textsl{stile} di
+comunicazione usato. La scelta di questo stile va infatti ad incidere sulla
+semantica che verrà utilizzata a livello utente per gestire la comunicazione
+(su come inviare e ricevere i dati) e sul comportamento effettivo delle
+funzioni utilizzate.
La scelta di uno stile dipende sia dai meccanismi disponibili, sia dal tipo di
comunicazione che si vuole effettuare. Ad esempio alcuni stili di
-comunicazione considerano i dati come una sequenza continua di bytes, altri
+comunicazione considerano i dati come una sequenza continua di byte, altri
invece li raggruppano in blocchi (i pacchetti).
Un'altro esempio di stile concerne la possibilità che la comunicazione possa o
socket, per cui viene messo a zero (con l'eccezione dei \textit{raw socket}).
\begin{prototype}{sys/socket.h}{int socket(int domain, int type, int protocol)}
+
+ Apre un socket.
- La funzione restituisce un intero positivo se riesce, e -1 se fallisce, in
- quest'ultimo caso la variabile \var{errno} è settata con i seguenti
- codici di errore:
+ \bodydesc{La funzione restituisce un intero positivo se riesce, e -1 se
+ fallisce, in quest'ultimo caso la variabile \var{errno} è impostata con i
+ seguenti codici di errore:
\begin{errlist}
- \item \macro{EPROTONOSUPPORT} Il tipo di socket o il protocollo scelto non
+ \item[\macro{EPROTONOSUPPORT}] Il tipo di socket o il protocollo scelto non
sono supportati nel dominio.
- \item \macro{ENFILE} Il kernel non ha memoria sufficiente a creare una
+ \item[\macro{ENFILE}] Il kernel non ha memoria sufficiente a creare una
nuova struttura per il socket.
- \item \macro{EMFILE} Si è ecceduta la tabella dei file.
- \item \macro{EACCES} Non si hanno privilegi per creare un socket nel
+ \item[\macro{EMFILE}] Si è ecceduta la tabella dei file.
+ \item[\macro{EACCES}] Non si hanno privilegi per creare un socket nel
dominio o con il protocollo specificato.
- \item \macro{EINVAL} Protocollo sconosciuto o dominio non disponibile.
- \item \macro{ENOBUFS} o \macro{ENOMEM} Non c'è sufficiente memoria per
- creare il socket.
- \end{errlist}
+ \item[\macro{EINVAL}] Protocollo sconosciuto o dominio non disponibile.
+ \item[\macro{ENOBUFS}] Non c'è sufficiente memoria per creare il socket (può
+ essere anche \macro{ENOMEM}).
+ \end{errlist}}
\end{prototype}
Si noti che la creazione del socket non comporta nulla riguardo
A ciascun tipo di dominio corrisponde un analogo nome simbolico che inizia per
\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.
+indirizzi usati in quel dominio; le pagine di manuale di Linux si riferiscono
+a questi anche come \textit{name space}, (nome che però il manuale delle
+\acr{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
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.
+protocolli disponibili sono riportate in \tabref{tab:net_pf_names}.
\begin{table}[htb]
\footnotesize
\centering
- \begin{tabular}[c]{lll}
+ \begin{tabular}[c]{|l|l|l|}
\hline
- \textsl{Nome} & \textsl{Utilizzo} &\textsl{Man page} \\
+ \textbf{Nome} & \textbf{Utilizzo} &\textbf{Man page} \\
\hline
\hline
- PF\_UNIX,PF\_LOCAL & Local communication & unix(7) \\
- PF\_INET & IPv4 Internet protocols & ip(7) \\
- PF\_INET6 & IPv6 Internet protocols & \\
- PF\_IPX & IPX - Novell protocols & \\
- PF\_NETLINK & Kernel user interface device & netlink(7) \\
- PF\_X25 & ITU-T X.25 / ISO-8208 protocol & x25(7) \\
- PF\_AX25 & Amateur radio AX.25 protocol & \\
- PF\_ATMPVC & Access to raw ATM PVCs & \\
- PF\_APPLETALK & Appletalk & ddp(7) \\
- PF\_PACKET & Low level packet interface & packet(7) \\
+ \macro{PF\_UNIX},
+ \macro{PF\_LOCAL} & Local communication & unix(7) \\
+ \macro{PF\_INET} & IPv4 Internet protocols & ip(7) \\
+ \macro{PF\_INET6} & IPv6 Internet protocols & ipv6(7) \\
+ \macro{PF\_IPX} & IPX - Novell protocols & \\
+ \macro{PF\_NETLINK}& Kernel user interface device & netlink(7) \\
+ \macro{PF\_X25} & ITU-T X.25 / ISO-8208 protocol & x25(7) \\
+ \macro{PF\_AX25} & Amateur radio AX.25 protocol & \\
+ \macro{PF\_ATMPVC} & Access to raw ATM PVCs & \\
+ \macro{PF\_APPLETALK}& Appletalk & ddp(7) \\
+ \macro{PF\_PACKET} & Low level packet interface & packet(7) \\
\hline
\end{tabular}
\caption{Famiglie di protocolli definiti in Linux}
Non tutte le famiglie di protocolli sono accessibili dall'utente generico, ad
esempio in generale tutti i socket di tipo \macro{SOCK\_RAW} possono essere
-creati solo da processi che hanno i privilegi di root (cioè effective uid
-uguale a zero) o la capability \macro{CAP\_NET\_RAW}.
+creati solo da processi che hanno i privilegi di root (cioè con userid
+effettivo uguale a zero) o con la capability \macro{CAP\_NET\_RAW}.
\subsection{Il tipo, o stile}
comunicazione, questo infatti viene a dipendere dal protocollo che si andrà ad
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}:
+\acr{glibc} mettono a disposizione i seguenti tipi di socket (che il manuale
+della \acr{glibc} chiama \textit{styles}) definiti come \ctyp{int} in
+\file{socket.h}:
\begin{list}{}{}
\item \macro{SOCK\_STREAM} Provvede un canale di trasmissione dati
\item \macro{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:
+Si tenga presente 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 appena
+elencati.
\begin{table}[htb]
\footnotesize
\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.
+In \secref{tab:sock_sock_valid_combinations} sono mostrate le combinazioni
+valide possibili per le varie 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.
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 è antecendente 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:
+(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 per gli indirizzi dei socket, \type{sockaddr}, che si è riportata in
+\figref{fig:sock_sa_gen_struct}.
\begin{figure}[!htb]
\footnotesize
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
-\file{sys/socket.h}
+POSIX.1g, riassunti in \tabref{tab:sock_data_types} con i rispettivi file di
+include in cui sono definiti; la struttura è invece definita nell'include file
+\file{sys/socket.h}.
\begin{table}[!htb]
\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
- \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}\\
+ \type{int8\_t} & intero a 8 bit con segno & \file{sys/types.h}\\
+ \type{uint8\_t} & intero a 8 bit senza segno & \file{sys/types.h}\\
+ \type{int16\_t} & intero a 16 bit con segno & \file{sys/types.h}\\
+ \type{uint16\_t} & intero a 16 bit senza segno& \file{sys/types.h}\\
+ \type{int32\_t} & intero a 32 bit con segno & \file{sys/types.h}\\
+ \type{uint32\_t} & intero a 32 bit senza segno& \file{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}\\
+ \type{sa\_family\_t} & famiglia degli indirizzi& \file{sys/socket.h}\\
+ \type{socklen\_t} & lunghezza (\type{uint32\_t}) dell'indirizzo di
+ un socket& \file{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}\\
+ \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
- stabilito dallo standard POSIX.1g}
+ stabilito dallo standard POSIX.1g.}
\label{tab:sock_data_types}
\end{table}
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.
I socket di tipo \macro{PF\_INET} vengono usati per la comunicazione
attraverso internet; la struttura per gli indirizzi per un socket internet
(IPv4) è definita come \type{sockaddr\_in} nell'header file
-\file{netinet/in.h} e secondo le man page ha la forma mostrata in \nfig,
-conforme allo standard POSIX.1g.
+\file{netinet/in.h} e secondo le pagine di manuale ha la forma mostrata in
+\figref{fig:sock_sa_ipv4_struct}, conforme allo standard POSIX.1g.
\begin{figure}[!htb]
\footnotesize
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.
+porta viene impostato al numero di protocollo.
-Il membro \var{sin\_family} deve essere sempre settato; \var{sin\_port}
+Il membro \var{sin\_family} deve essere sempre impostato; \var{sin\_port}
specifica il numero di porta (vedi \secref{sec:TCPel_port_num}; 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 \macro{CAP\_NET\_BIND\_SERVICE} possono
-usare la funzione \func{bind} su queste porte.
+servizi standard. Soltanto processi con i privilegi di root (con userid
+effettivo uguale a zero) o con la capability \macro{CAP\_NET\_BIND\_SERVICE}
+possono usare la funzione \func{bind} su queste porte.
Il membro \var{sin\_addr} contiene l'indirizzo internet dell'altro capo
della comunicazione, e viene acceduto sia come struttura (un resto di una
\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}.
\label{fig:sock_sa_ipv6_struct}
\end{figure}
-Il campo \var{sin6\_family} deve essere sempre settato ad
+Il campo \var{sin6\_family} deve essere sempre impostato ad
\macro{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
\subsection{La struttura degli indirizzi locali}
\label{sec:sock_sa_local}
-I socket di tipo \macro{PF\_UNIX} vengono usati per una comunicazione
-efficiente fra processi che stanno sulla stessa macchina; essi rispetto ai
+I socket di tipo \macro{PF\_UNIX} o \macro{PF\_LOCAL} vengono usati per una
+comunicazione fra processi che stanno sulla stessa macchina (per vengono
+chiamati \textit{local domain} o anche \textit{Unix domain}); essi rispetto ai
precedenti possono essere anche creati in maniera anonima attraverso la
-funzione \func{socketpair}. Quando però si vuole fare riferimento esplicito
-ad uno di questi socket si deve usare la seguente struttura di indirizzi
-definita nel file di header \file{sys/un.h}.
+funzione \func{socketpair} (vedi \secref{sec:ipc_socketpair}). Quando però si
+vuole fare riferimento esplicito ad uno di questi socket si deve usare la
+seguente struttura di indirizzi definita nel file di header \file{sys/un.h}.
\begin{figure}[!htb]
\footnotesize
(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 invece \var{sun\_path} inizia con uno zero
-vengono usati i restanti bytes come stringa (senza terminazione).
+vengono usati i restanti byte come stringa (senza terminazione).
% \subsection{Il passaggio delle strutture}
Il problema connesso all'endianess è 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 bytes in cui è
+esempio nel caso dell'intero a 16 bit ci si ritroverà con i due byte in cui è
suddiviso scambiati di posto, e ne sarà quindi invertito l'ordine di lettura
per cui, per riavere il valore originale dovranno essere rovesciati.
Converte l'intero a 16 bit \var{netshort} dal formato della rete a quello
della macchina.
\end{prototype}
-I nomi sono assegnati usando la lettera \func{n} come mnemonico per indicare
+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
-\func{h} come mnemonico per l'ordinamento usato sulla macchina locale (da
-\textit{host order}), mentre le lettere \func{s} e \func{l} stanno ad indicare
-i tipi di dato (\type{long} o \type{short}, riportati anche dai prototipi).
+\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 (\ctyp{long} o \ctyp{short}, riportati anche dai
+prototipi).
Usando queste funzioni si ha la conversione automatica: nel caso in cui la
macchina che si sta usando abbia una architettura \textit{big endian} queste
indirizzi IPv4 da una stringa in cui il numero di IP è espresso secondo la
cosiddetta notazione \textit{dotted-decimal}, (cioè nella forma
\texttt{192.160.0.1}) al formato binario (direttamente in \textit{network
- order}) e viceversa; in questo caso si usa la lettera \func{a} come
+ order}) e viceversa; in questo caso si usa la lettera \texttt{a} come
mnemonico per indicare la stringa. Dette funzioni sono:
\begin{prototype}{arpa/inet.h}
{int inet\_aton(const char *src, struct in\_addr *dest)}
Le tre funzioni precedenti sono limitate solo ad indirizzi IPv4, per questo
motivo è preferibile usare le due nuove funzioni \func{inet\_pton} e
\func{inet\_ntop} che possono convertire anche gli indirizzi IPv6. Anche in
-questo caso le lettere \func{n} e \func{p} sono degli mnemonici per ricordare
-il tipo di conversione effettuata e stanno per \textit{presentation} e
-\textit{numeric}.
+questo caso le lettere \texttt{n} e \texttt{p} sono degli mnemonici per
+ricordare il tipo di conversione effettuata e stanno per \textit{presentation}
+e \textit{numeric}.
% \begin{figure}[htb]
% \centering
% \end{figure}
-Entrambe le funzioni accettano l'argomento \texttt{af} che indica il tipo di
-indirizzo e può essere \texttt{AF\_INET} o \texttt{AF\_INET6}. Se la famiglia
-indicata non è valida entrambe le funzioni settano la variabile \texttt{errno}
-al valore \texttt{EAFNOSUPPORT}. I prototipi delle suddette funzioni sono i
+Entrambe le funzioni accettano l'argomento \param{af} che indica il tipo di
+indirizzo e può essere \macro{AF\_INET} o \macro{AF\_INET6}. Se la famiglia
+indicata non è valida entrambe le funzioni impostano la variabile \var{errno}
+al valore \macro{EAFNOSUPPORT}. I prototipi delle suddette funzioni sono i
seguenti:
\begin{prototype}{sys/socket.h}
{int inet\_pton(int af, const char *src, void *addr\_ptr)} Converte la
\macro{INET6\_ADDRSTRLEN} per indirizzi IPv6; la lunghezza del buffer deve
comunque venire specificata attraverso il parametro \var{len}.
- La funzione restituisce un puntatore non nullo a \var{dest} in caso di
- successo e un puntatore nullo in caso di fallimento, in quest'ultimo caso
- viene settata la variabile \var{errno} con il valore \macro{ENOSPC} in
- caso le dimensioni dell'indirizzo eccedano la lunghezza specificata da
- \var{len} o \macro{ENOAFSUPPORT} in caso \var{af} non sia una famiglia di
- indirizzi valida.
+ \bodydesc{La funzione restituisce un puntatore non nullo a \var{dest} in
+ caso di successo e un puntatore nullo in caso di fallimento, in
+ quest'ultimo caso viene impostata la variabile \var{errno} con il valore
+ \macro{ENOSPC} in caso le dimensioni dell'indirizzo eccedano la lunghezza
+ specificata da \var{len} o \macro{ENOAFSUPPORT} in caso \var{af} non sia
+ una famiglia di indirizzi valida.}
\end{prototype}
-Gli indirizzi vengono cnovertiti da/alle rispettive strutture di indirizzo
+Gli indirizzi vengono convertiti da/alle rispettive strutture di indirizzo
(\var{struct in\_addr} per IPv4, e \var{struct in6\_addr} per IPv6), che
devono essere precedentemente allocate e passate attraverso il puntatore
\var{addr\_ptr}; il parametro \var{dest} di \func{inet\_ntop} non può essere
Per evitare di rendere questa introduzione ai socket puramente teorica
iniziamo con il mostrare un esempio di un client TCP elementare. Prima di
-passare agli esempi del client e del server, esamimeremo una caratteristica
+passare agli esempi del client e del server, esamineremo una caratteristica
delle funzioni di I/O sui socket che ci tornerà utile anche in seguito.
per i socket di tipo stream).
Infatti con i socket è comune che funzioni come \func{read} o \func{write}
-possano restituire in input o scrivere in output un numero di bytes minore di
+possano restituire in input o scrivere in output un numero di byte minore di
quello richiesto. Come già accennato in \secref{sec:file_read} questo è un
comportamento normale anche per l'I/O su file, e succede
perché si eccede in lettura o scrittura il limite di buffer del kernel.
In questo caso tutto quello che il programma chiamante deve fare è di ripetere
-la lettura (o scrittura) per la quantità di bytes rimanenti (lo stesso può
-avvenire scrivendo più di 4096 bytes in una pipe, dato che quello è il limite
+la lettura (o scrittura) per la quantità di byte rimanenti (lo stesso può
+avvenire scrivendo più di 4096 byte in una pipe, dato che quello è il limite
di solito adottato per il buffer di trasmissione del kernel).
\begin{figure}[htb]
return (count - nleft);
}
\end{lstlisting}
- \caption{Funzione \func{SockRead}, legge \var{count} bytes da un socket }
+ \caption{Funzione \func{SockRead}, legge \var{count} byte da un socket }
\label{fig:sock_SockRead_code}
\end{figure}
Per questo motivo seguendo l'esempio di W. R. Stevens si sono definite due
funzioni \func{SockRead} e \func{SockWrite} che eseguono la lettura da un
socket tenendo conto di questa caratteristica, ed in grado di ritornare dopo
-avere letto o scritto esattamente il numero di bytes specificato; il sorgente
+avere letto o scritto esattamente il numero di byte specificato; il sorgente
è riportato in \curfig\ e \nfig\ ed è disponibile fra i sorgenti allegati alla
guida nei files \file{SockRead.c} e \file{SockWrite.c}.
return (count);
}
\end{lstlisting}
- \caption{Funzione \func{SockWrite}, scrive \var{count} bytes su un socket }
+ \caption{Funzione \func{SockWrite}, scrive \var{count} byte su un socket }
\label{fig:sock_SockWrite_code}
\end{figure}
Come si può notare le funzioni ripetono la lettura/scrittura in un ciclo fino
-all'esaurimento del numero di bytes richiesti, in caso di errore viene
+all'esaurimento del numero di byte richiesti, in caso di errore viene
controllato se questo è \macro{EINTR} (cioè un'interruzione della system call
dovuta ad un segnale), nel qual caso l'accesso viene ripetuto, altrimenti
l'errore viene ritornato interrompendo il ciclo.
-Nel caso della lettura, se il numero di bytes letti è zero, significa che si è
+Nel caso della lettura, se il numero di byte letti è zero, significa che si è
arrivati alla fine del file e pertanto si ritorna senza aver concluso la
-lettura di tutti i bytes richiesti.
+lettura di tutti i byte richiesti.
definizioni precise e dettagli di funzionamento che saranno trattati
estensivamente più avanti.
-In \nfig\ è riportata la sezione principale del codice del nostro client
-elementare per il servizio \textit{daytime}, un servizio standard che
-restituisce l'ora locale della macchina a cui si effettua la richiesta.
+In \figref{fig:net_cli_code} è riportata la sezione principale del codice del
+nostro client elementare per il servizio \textit{daytime}, un servizio
+standard che restituisce l'ora locale della macchina a cui si effettua la
+richiesta.
\begin{figure}[!htb]
\footnotesize
\begin{lstlisting}{}
#include <sys/types.h> /* predefined types */
#include <unistd.h> /* include unix standard library */
-#include <arpa/inet.h> /* IP addresses conversion utiliites */
+#include <arpa/inet.h> /* IP addresses conversion utilities */
#include <sys/socket.h> /* socket library */
#include <stdio.h> /* include standard I/O library */
Il programma anzitutto include gli header necessari (\texttt{\small 1--5});
dopo la dichiarazione delle variabili (\texttt{\small 9--12}) si è omessa
tutta la parte relativa al trattamento degli argomenti passati dalla linea di
-comando (effettuata con le apposite routines illustrate in
+comando (effettuata con le apposite routine illustrate in
\capref{sec:proc_opt_handling}).
Il primo passo (\texttt{\small 14--18}) è creare un \textit{socket} IPv4
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
Dopo aver illustrato il client daremo anche un esempio di un server
elementare, in grado di rispondere al precedente client. Il listato è
-nuovamente mostrato in \nfig, il sorgente completo
+nuovamente mostrato in \figref{fig:net_serv_code}, il sorgente completo
(\file{ElemDaytimeTCPServer.c}) è allegato insieme agli altri file nella
directory \file{sources}.
\begin{lstlisting}{}
#include <sys/types.h> /* predefined types */
#include <unistd.h> /* include unix standard library */
-#include <arpa/inet.h> /* IP addresses conversion utiliites */
+#include <arpa/inet.h> /* IP addresses conversion utilities */
#include <sys/socket.h> /* socket library */
#include <stdio.h> /* include standard I/O library */
#include <time.h>
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