Aggiunta socketpair, ed iniziata la descrizione del syslog

[gapil.git] / ipc.tex

diff --git a/ipc.tex b/ipc.tex
index 1116f2e3634111f717c899ef9e71cb683f31bcb2..d0cf5ce86b4d33de1cda5cd415e70dc739aeed32 100644 (file)
--- a/ipc.tex
+++ b/ipc.tex
@@ -786,7 +786,6 @@ dal server siano sempre di dimensioni inferiori a \macro{PIPE\_BUF},
 tralasciamo la gestione del caso in cui questo non è vero. Infine si stampa
 (\texttt{\small 32}) a video la risposta, si chiude (\texttt{\small 33}) la
 fifo e si cancella (\texttt{\small 34}) il relativo file.
-
 Si noti come la fifo per la risposta sia stata aperta solo dopo aver inviato
 la richiesta, se non si fosse fatto così si avrebbe avuto uno stallo, in
 quanto senza la richiesta, il server non avrebbe potuto aprirne il capo in
@@ -808,6 +807,57 @@ come quelli che esamineremo in seguito.
 
 
 
+\subsection{La funzione \func{socketpair}}
+\label{sec:ipc_socketpair}
+
+Un meccanismo di comunicazione molto simile alle pipe, ma che non presenta il
+problema della unidirezionalità del flusso dei dati, è quello dei cosiddetti
+\textit{socket} locali (o \textit{Unix domain socket}). Tratteremo l'argomento
+dei socket in \capref{cha:socket_intro}, nell'ambito dell'interfaccia generale
+che essi forniscono per la programmazione di rete; e vedremo
+(in~\secref{sec:sock_sa_local}) come in tal caso si possono definire dei file
+speciali (di tipo \textit{socket}, analoghi alle fifo) cui si accede però
+attraverso quella interfaccia; vale però la pena esaminare qui una
+modalità\footnote{la funzione \func{socketpair} è stata introdotta in BSD4.4,
+  ma è supportata in genere da qualunque sistema che fornisca l'interfaccia
+  dei socket.} di uso di questi socket che li rende sostanzialmente identici
+ad una pipe bidirezionale.
+
+Attraverso la funzione \func{socketpair} infatti è possibile creare una coppia
+di socket (che sono trattati com file descriptor) connessi fra di loro, senza
+fare nessun riferimento ad un file speciale sul filesystem, in maniera analoga
+a quello che si fa con \func{pipe}; la differenza è che in questo caso il
+flusso dei dati è bidirezionale. Il prototipo della funzione è:
+\begin{functions}
+  \headdecl{sys/types.h} 
+  \headdecl{sys/socket.h} 
+  
+  \funcdecl{int socketpair(int domain, int type, int protocol, int sv[2])}
+  
+  Crea una coppia di socket connessi fra loro.
+  
+  \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
+    errore, nel qual caso \var{errno} assumerà uno dei valori:
+  \begin{errlist}
+  \item[\macro{EAFNOSUPPORT}] I socket locali non sono supportati.
+  \item[\macro{EPROTONOSUPPORT}] Il protocollo specificato non è supportato.
+  \item[\macro{EOPNOTSUPP}] Il protocollo specificato non supporta la
+  creazione di coppie di socket.
+  \end{errlist}
+  ed inoltre \macro{EMFILE},  \macro{EFAULT}.
+}
+\end{functions}
+
+La funzione restituisce in \param{sv} una coppia di descrittori di socket
+(come vedremo in \capref{cha:socket_intro} i file descriptor vengono usati
+anche per i socket) connessi fra di loro, così che quello che si scrive da una
+parte può essere riletto dall'altra e viceversa. I parametri \param{domain},
+\param{type} e \param{protocol} derivano dall'interfaccia dei socket, ma in
+questo caso i soli valori validi sono rispettivamente \macro{AF\_UNIX},
+\macro{SOCK\_STREAM} e \macro{0}.
+
+
+
 \section{La comunicazione fra processi di System V}
 \label{sec:ipc_sysv}
 
@@ -1162,7 +1212,7 @@ una 
   
   \funcdecl{int msgget(key\_t key, int flag)}
   
-  Restituisce l'identificatore di una cosa di messaggi.
+  Restituisce l'identificatore di una coda di messaggi.
   
   \bodydesc{La funzione restituisce l'identificatore (un intero positivo) o -1
     in caso di errore, nel qual caso \var{errno} assumerà uno dei valori: