Nuovo overview dei protocolli. Scritto qualcosa su peer-to-peer e three-tier

diff --git a/img/gapil.jpg b/img/gapil.jpg
deleted file mode 100644 (file)
index cdf8a7e..0000000
Binary files a/img/gapil.jpg and /dev/null differ

diff --git a/img/tcpip_overview.dia b/img/tcpip_overview.dia
index 4f2436e4eb743cc294564838acdf64513efb10e7..26b22546edebe19dce133e543e0a914ace612af5 100644 (file)
Binary files a/img/tcpip_overview.dia and b/img/tcpip_overview.dia differ

diff --git a/network.tex b/network.tex
index 606a3300e9e153e6ba124a6001b4db85984f8ea5..d564dc4ac76540ac7d239268ec79ccaf6b2d6e63 100644 (file)
--- a/network.tex
+++ b/network.tex
@@ -47,43 +47,107 @@ gli scopi del testo approfondire questi argomenti.
 \subsection{Il modello \textit{client-server}}
 \label{sec:net_cliserv}
 
 \subsection{Il modello \textit{client-server}}
 \label{sec:net_cliserv}
 

-Il concetto fondamentale su cui si basa la programmazione di rete sotto Linux
-(e sotto Unix in generale) è il modello \textit{client-server} in cui un
-programma di servizio, il \textit{server}, riceve una richiesta e risponde a
-un programma di utilizzo, il \textit{client}, fornendo a quest'ultimo un
-definito insieme di servizi. 
-
-Infatti seguono questo modello tutti i servizi fondamentali di internet, come
-il le pagine web, ftp, telnet, ssh e praticamente ogni servizio che viene
-fornito tramite la rete, anche se, come abbiamo visto, il modello è utilizzato
-in generale anche per programmi che, come gli esempi che abbiamo usato in
-\capref{cha:IPC} a proposito della comunicazione fra processi nello stesso
-sistema, non fanno necessariamente uso della rete.
+L'architettura fondamentale su cui si basa gran parte della programmazione di
+rete sotto Linux (e sotto Unix in generale) è il modello
+\textit{client-server} caratterizzato dalla presenza di due categorie di
+soggetti, i programmi di servizio, chiamati \textit{server}, che ricevono le
+richieste e forniscono le risposte, ed i programmi di utilizzo, detti
+\textit{client}.
+
+In generale un server può (di norma deve) essere in grado di rispondere a più
+di un client, per cui è possibile che molti programmi possano interagire
+contemporaneamente, quello che contraddistingue il modello però è che
+l'architettura dell'interazione è sempre nei termini di molti verso uno, il
+server, che viene ad assumere un ruolo privilegiato.
+
+Seguono questo modello tutti i servizi fondamentali di internet, come le
+pagine web, la posta elettronica, ftp, telnet, ssh e praticamente ogni
+servizio che viene fornito tramite la rete, anche se, come abbiamo visto, il
+modello è utilizzato in generale anche per programmi che, come gli esempi che
+abbiamo usato in \capref{cha:IPC} a proposito della comunicazione fra processi
+nello stesso sistema, non fanno necessariamente uso della rete.

 
 Normalmente si dividono i server in due categorie principali, e vengono detti
 \textsl{concorrenti} o \textsl{iterativi}, sulla base del loro comportamento.
 
 Normalmente si dividono i server in due categorie principali, e vengono detti
 \textsl{concorrenti} o \textsl{iterativi}, sulla base del loro comportamento.

-

 Un \textsl{server iterativo} risponde alla richiesta inviando i dati e resta
 Un \textsl{server iterativo} risponde alla richiesta inviando i dati e resta

-occupato (non rispondendo ad ulteriori richieste) fintanto che non ha concluso
-la richiesta. Una volta completata la richiesta il server diventa di nuovo
-disponibile.
+occupato e non rispondendo ad ulteriori richieste fintanto che non ha fornito
+una risposta alla richiesta. Una volta completata la risposta il server
+diventa di nuovo disponibile.

 
 Un \textsl{server concorrente} al momento di trattare la richiesta crea un
 
 Un \textsl{server concorrente} al momento di trattare la richiesta crea un

-processo figlio incaricato di fornire i servizi richiesti, per poi porsi in
-attesa di ulteriori richieste. In questo modo più richieste possono essere
-soddisfatte contemporaneamente; una volta che il processo figlio ha concluso
-il suo lavoro viene terminato, mentre il server originale resta sempre attivo.
+processo figlio (o un thread) incaricato di fornire i servizi richiesti, per
+porsi immediatamente in attesa di ulteriori richieste. In questo modo, con
+sistemi multitasking, più richieste possono essere soddisfatte
+contemporaneamente. Una volta che il processo figlio ha concluso il suo lavoro
+esso di norma viene terminato, mentre il server originale resta sempre attivo.

 
 
 
 

-\subsection{Il modello \textit{peer-to-perr}}
+\subsection{Il modello \textit{peer-to-peer}}

 \label{sec:net_peertopeer}
 
 \label{sec:net_peertopeer}
 

-Da fare
+Come abbiamo visto il tratto saliente dell'architettura \textit{client-server}
+è quello della preminenza del server rispetto ai client, le architetture
+\textit{peer-to-peer} si basano su un approccio completamente opposto che è
+quello di non avere nessun programma che svolga un ruolo preminente.
+
+Questo vuol dire che in generale ciascun programma viene ad agire come un nodo
+in una rete potenzialmente paritetica; ciascun programma si trova pertanto a
+ricevere ed inviare richieste ed a ricevere ed inviare risposte, e non c'è più
+la separazione netta dei compiti che si ritrova nelle archietetture
+\textit{client-server}.
+
+Le architetture \textit{peer-to-peer} sono salite alla ribalta con
+l'esplosione del fenomeno Napster, ma gli stessi protocolli di routing sono un
+buon esempio di archietetture \textit{peer-to-peer}, in cui ciascun nodo,
+tramite il demone che gestisce il routing, richiede ed invia informazioni ad
+altri nodi.
+
+In realtà in molti casi di archietture classificate come \textit{peer-to-peer}
+non è detto che la struttura sia totalmente paritetica e ci sono parecchi
+esempi in cui alcuni servizi vengono centralizzati o disribuiti
+gerarchicamente, come per lo stesso Napster, in cui le ricerche venivano
+effettuate su un server centrale.
+
+

 
 \subsection{Il modello \textit{three-tier}}
 \label{sec:net_three_tier}
 
 
 \subsection{Il modello \textit{three-tier}}
 \label{sec:net_three_tier}
 

-Da fare
+Benché qui sia trattato a parte, il modello \textit{three-tier} in realtà è
+una estensione del modello \textit{client-server}. Con il crescere della
+quantità dei servizi forniti in rete (in particolare su internet) ed al numero
+di accessi richiesto. Si è così assistito anche ad una notevole crescita di
+complessità, in cui diversi servizi venivano ad essere integrati fra di loro.
+
+In particolare sempre più spesso si assiste ad una integrazione di servizi di
+database con servizi di web, in cui le pagine vengono costruite dinamicamente
+sulla base dei dati contenuti nel database. In tutti questi casi il problema
+fondamentale di una architettura \textit{client-server} è che la richiesta di
+un servizio da parte di un gran numero di client si scontra con il collo di
+bottiglia dell'accesso diretto ad un unico server, con gravi problemi di
+scalabilità.
+
+Rispondere a queste esigenze di scalabilità il modello più semplice (chiamato
+talvolta \textit{two-tier}) da adottare è stata quello di distribuire il
+carico delle richieste su più server identici, mantenendo quindi
+sostanzialmente inalterata l'archiettettura \textit{client-server} originale.
+
+Nel far questo ci si scontra però con gravi problemi di manutenibilità dei
+servizi, in particolare per quanto riguarda la sincronizzazione dei dati, e di
+inefficienza dell'uso delle risorse. Il problema è particolarmente grave per i
+database che non possono essere replicati e sincronizzati facilemente, e che
+sono molto onerosi sia in termini di richiesta risorse.
+
+È a partire da queste problematiche che nasce il modello \textit{three-tier},
+che si struttura, come dice il nome, su tre livelli. Il primo, quello dei
+client, che eseguono le richieste e gestiscono l'interfaccia con l'utente,
+resta sostanzialmente lo stesso del modello \textit{client-server}, ma la
+parte server viene suddivisa in due livelli, introducendo un
+\textit{middle-tier}, su cui deve appoggiarsi tutta la logica di analisi delle
+richieste dei client per ottimizzare l'accesso al terzo livello, quello dei
+server che invece si limita a fornire dei dati che verranno usati dal
+\textit{middle-tier} per eseguire le operazioni.
+

 
 
 \section{I protocolli di rete}
 
 
 \section{I protocolli di rete}


@@ -317,7 +381,7 @@ reciproche e con alcune dalle principali applicazioni che li usano.
 
 \begin{figure}[!htbp]
   \centering
 
 \begin{figure}[!htbp]
   \centering

-  \includegraphics[width=15cm]{img/tcpip_overview}  
+  \includegraphics[width=13cm]{img/tcpip_overview}  

   \caption{Panoramica sui vari protocolli che compongono la suite TCP/IP.}
   \label{fig:net_tcpip_overview}
 \end{figure}
   \caption{Panoramica sui vari protocolli che compongono la suite TCP/IP.}
   \label{fig:net_tcpip_overview}
 \end{figure}

diff --git a/socket.tex b/socket.tex
index 5a2a8ea15a29165e53655f5f6aa8a8272a7c04b2..2dc56748093a9512a8094634c3f235faca61585c 100644 (file)
--- a/socket.tex
+++ b/socket.tex
@@ -278,33 +278,35 @@ elencati.
 \begin{table}[htb]
   \footnotesize
   \centering
 \begin{table}[htb]
   \footnotesize
   \centering

-  \begin{tabular}{l|c|c|c|c|c|}
-   \multicolumn{1}{c}{} &\multicolumn{1}{c}{\const{SOCK\_STREAM}}& 
-     \multicolumn{1}{c}{\const{SOCK\_DGRAM}} & 
-     \multicolumn{1}{c}{\const{SOCK\_RAW}} & 
-     \multicolumn{1}{c}{\const{SOCK\_PACKET}}& 
-     \multicolumn{1}{c}{\const{SOCK\_SEQPACKET}} \\
-     \cline{2-6}
+  \begin{tabular}{|l|c|c|c|c|c|}
+    \hline
+    \multicolumn{1}{|c|}{\textbf{Famiglia}}&
+    \multicolumn{5}{|c|}{\textbf{Tipo}}\\
+    \hline
+    \hline
+    &\const{SOCK\_STREAM} &\const{SOCK\_DGRAM}     &\const{SOCK\_RAW}& 
+      \const{SOCK\_PACKET}&\const{SOCK\_SEQPACKET} \\
+     \hline

     \const{PF\_UNIX}      &  si & si  &      &     &     \\
     \const{PF\_UNIX}      &  si & si  &      &     &     \\

-     \cline{2-6}
+     \hline

     \const{PF\_INET}      & TCP & UDP & IPv4 &     &     \\
     \const{PF\_INET}      & TCP & UDP & IPv4 &     &     \\

-     \cline{2-6}
+     \hline

     \const{PF\_INET6}     & TCP & UDP & IPv6 &     &     \\
     \const{PF\_INET6}     & TCP & UDP & IPv6 &     &     \\

-     \cline{2-6}
+     \hline

     \const{PF\_IPX}       &     &     &      &     &     \\
     \const{PF\_IPX}       &     &     &      &     &     \\

-     \cline{2-6}
+     \hline

     \const{PF\_NETLINK}   &     &  si &  si  &     &     \\
     \const{PF\_NETLINK}   &     &  si &  si  &     &     \\

-     \cline{2-6}
+     \hline

     \const{PF\_X25}       &     &     &      &     &  si \\
     \const{PF\_X25}       &     &     &      &     &  si \\

-     \cline{2-6}
+     \hline

     \const{PF\_AX25}      &     &     &      &     &     \\
     \const{PF\_AX25}      &     &     &      &     &     \\

-     \cline{2-6}
+     \hline

     \const{PF\_ATMPVC}    &     &     &      &     &     \\
     \const{PF\_ATMPVC}    &     &     &      &     &     \\

-     \cline{2-6}
+     \hline

     \const{PF\_APPLETALK} &     & si  &  si  &     &     \\
     \const{PF\_APPLETALK} &     & si  &  si  &     &     \\

-     \cline{2-6}
+     \hline

     \const{PF\_PACKET}    &     & si  & si   &     &     \\    
     \const{PF\_PACKET}    &     & si  & si   &     &     \\    

-     \cline{2-6}
+     \hline

   \end{tabular}
   \caption{Combinazioni valide di dominio e tipo di protocollo per la 
     funzione \func{socket}.}
   \end{tabular}
   \caption{Combinazioni valide di dominio e tipo di protocollo per la 
     funzione \func{socket}.}


@@ -437,12 +439,12 @@ si usa IPv4) 
     \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
 struct sockaddr_in {
     sa_family_t     sin_family; /* address family: AF_INET */
     \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
 struct sockaddr_in {
     sa_family_t     sin_family; /* address family: AF_INET */

-    u_int16_t       sin_port;   /* port in network byte order */
+    in_port_t       sin_port;   /* port in network byte order */

     struct in_addr  sin_addr;   /* internet address */
 };
 /* Internet address. */
 struct in_addr {
     struct in_addr  sin_addr;   /* internet address */
 };
 /* Internet address. */
 struct in_addr {

-    u_int32_t       s_addr;     /* address in network byte order */
+    in_addr_t       s_addr;     /* address in network byte order */

 };
     \end{lstlisting}
   \end{minipage} 
 };
     \end{lstlisting}
   \end{minipage} 


@@ -497,15 +499,15 @@ in \figref{fig:sock_sa_ipv6_struct}.
   \begin{minipage}[c]{15cm}
     \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
 struct sockaddr_in6 {
   \begin{minipage}[c]{15cm}
     \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
 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 */
+    uint16_t        sin6_family;   /* AF_INET6 */
+    in_port_t       sin6_port;     /* port number */
+    uint32_t        sin6_flowinfo; /* IPv6 flow information */

     struct in6_addr sin6_addr;     /* IPv6 address */
     struct in6_addr sin6_addr;     /* IPv6 address */

-    u_int32_t       sin6_scope_id; /* Scope id (new in 2.4) */
+    uint32_t        sin6_scope_id; /* Scope id (new in 2.4) */

 };
 
 struct in6_addr {
 };
 
 struct in6_addr {

-    unsigned char   s6_addr[16];   /* IPv6 address */
+    uint8_t       s6_addr[16];   /* IPv6 address */

 };
     \end{lstlisting}
   \end{minipage} 
 };
     \end{lstlisting}
   \end{minipage} 


@@ -540,8 +542,9 @@ 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} (vedi \secref{sec:ipc_socketpair}). Quando però si
 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} (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}.
+vuole fare riferimento esplicito ad uno di questi socket si deve usare una
+struttura degli indirizzi di tipo \struct{sockaddr\_un}, la cui definizione si
+è riportata in \secref{fig:sock_sa_local_struct}.

 
 \begin{figure}[!htb]
   \footnotesize \centering
 
 \begin{figure}[!htb]
   \footnotesize \centering


@@ -554,18 +557,18 @@ struct sockaddr_un {
 };
     \end{lstlisting}
   \end{minipage} 
 };
     \end{lstlisting}
   \end{minipage} 

-  \caption{La struttura degli indirizzi dei socket locali 
-    \structd{sockaddr\_un}.}
+  \caption{La struttura degli indirizzi dei socket locali (detti anche
+    \textit{unix domain}) \structd{sockaddr\_un} definita in \file{sys/un.h}.}

   \label{fig:sock_sa_local_struct}
 \end{figure}
 
 In questo caso il campo \var{sun\_family} deve essere \const{AF\_UNIX}, mentre
   \label{fig:sock_sa_local_struct}
 \end{figure}
 
 In questo caso il campo \var{sun\_family} deve essere \const{AF\_UNIX}, mentre

-il campo \var{sun\_path} deve specificare un indirizzo; questo ha due forme:
+il campo \var{sun\_path} deve specificare un indirizzo. Questo ha due forme:

 un file (di tipo socket) nel filesystem o una stringa univoca (mantenuta 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;
 un file (di tipo socket) nel filesystem o una stringa univoca (mantenuta 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 byte come stringa (senza terminazione).
+nel secondo invece \var{sun\_path} inizia con uno zero e vengono usati i
+restanti byte come stringa, senza terminazione.

 
 
 \subsection{La struttura degli indirizzi AppleTalk}
 
 
 \subsection{La struttura degli indirizzi AppleTalk}


@@ -576,8 +579,9 @@ I socket di tipo \const{PF\_APPLETALK} sono usati dalla libreria
 AppleTalk, uno dei primi protocolli di rete usato nel mondo dei personal
 computer, usato dalla Apple per connettere fra loro computer e stampanti. Il
 kernel supporta solo due strati del protocollo, DDP e AARP, e di norma è
 AppleTalk, uno dei primi protocolli di rete usato nel mondo dei personal
 computer, usato dalla Apple per connettere fra loro computer e stampanti. Il
 kernel supporta solo due strati del protocollo, DDP e AARP, e di norma è

-opportuno usare le funzioni di libreria, si tratta qui questo argomento
-principalmente per mostrare l'uso di un protocollo alternativo.
+opportuno usare le funzioni della libreria \texttt{netatalk}, tratteremo qui
+questo argomento principalmente per mostrare l'uso di un protocollo
+alternativo.

 
 I socket AppleTalk permettono di usare il protocollo DDP, che è un protocollo
 a pacchetto, di tipo \const{SOCK\_DGRAM}; l'argomento \param{protocol} di
 
 I socket AppleTalk permettono di usare il protocollo DDP, che è un protocollo
 a pacchetto, di tipo \const{SOCK\_DGRAM}; l'argomento \param{protocol} di


@@ -585,19 +589,24 @@ a pacchetto, di tipo \const{SOCK\_DGRAM}; l'argomento \param{protocol} di
 specificando un tipo \const{SOCK\_RAW}, nel qual caso l'unico valore valido
 per \param{protocol} è \func{ATPROTO\_DDP}.
 
 specificando un tipo \const{SOCK\_RAW}, nel qual caso l'unico valore valido
 per \param{protocol} è \func{ATPROTO\_DDP}.
 

+Gli indirizzi AppleTalk devono essere specificati tramite una struttura
+\struct{sockaddr\_atalk}, la cui definizione è riportata in
+\figref{fig:sock_sa_atalk_struct}; la struttura viene dichiarata includendo il
+file \file{netatalk/at.h}.
+

 \begin{figure}[!htb]
   \footnotesize \centering
   \begin{minipage}[c]{15cm}
     \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
 struct sockaddr_atalk {
     sa_family_t     sat_family; /* address family */
 \begin{figure}[!htb]
   \footnotesize \centering
   \begin{minipage}[c]{15cm}
     \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
 struct sockaddr_atalk {
     sa_family_t     sat_family; /* address family */

-    u_char          sat_port;   /* port */
+    uint8_t         sat_port;   /* port */

     struct at_addr  sat_addr;   /* net/node */
 };
 
 struct at_addr {
     struct at_addr  sat_addr;   /* net/node */
 };
 
 struct at_addr {

-    unsigned short  s_net;
-    unsigned char   s_node;
+    uint16_t        s_net;
+    uint8_t         s_node;

 };
     \end{lstlisting}
   \end{minipage} 
 };
     \end{lstlisting}
   \end{minipage} 


@@ -606,12 +615,12 @@ struct at_addr {
   \label{fig:sock_sa_atalk_struct}
 \end{figure}
 
   \label{fig:sock_sa_atalk_struct}
 \end{figure}
 

-Il campo \var{sut\_family} deve essere sempre \const{AF\_APPLETALK}, mentre il
-campo \var{sun\_port} specifica la porta che identifica i vari servizi. Valori
+Il campo \var{sat\_family} deve essere sempre \const{AF\_APPLETALK}, mentre il
+campo \var{sat\_port} specifica la porta che identifica i vari servizi. Valori

 inferiori a 129 sono usati per le \textsl{porte riservate}, e possono essere
 usati solo da processi con i privilegi di amministratore o con la capability
 \const{CAP\_NET\_BIND\_SERVICE}. L'indirizzo remoto è specificato nella
 inferiori a 129 sono usati per le \textsl{porte riservate}, e possono essere
 usati solo da processi con i privilegi di amministratore o con la capability
 \const{CAP\_NET\_BIND\_SERVICE}. L'indirizzo remoto è specificato nella

-struttura \var{sun\_addr}, e deve essere in \textit{network order}; esso è
+struttura \var{sat\_addr}, e deve essere in \textit{network order}; esso è

 composto da un parte di rete data dal campo \var{s\_net}, che può assumere il
 valore \const{AT\_ANYNET}, che indica una rete genrica e vale anche per
 indicare la rete su cui si è, il singolo nodo è indicato da \var{s\_node}, e
 composto da un parte di rete data dal campo \var{s\_net}, che può assumere il
 valore \const{AT\_ANYNET}, che indica una rete genrica e vale anche per
 indicare la rete su cui si è, il singolo nodo è indicato da \var{s\_node}, e


@@ -619,18 +628,14 @@ pu
 corrente, ed il valore \const{ATADDR\_BCAST} che indica tutti i nodi della
 rete.
 
 corrente, ed il valore \const{ATADDR\_BCAST} che indica tutti i nodi della
 rete.
 

-
-
-
-
-\subsection{La struttura degli indirizzi DECnet}
-\label{sec:sock_sa_decnet}
-
-I socket di tipo \const{PF\_DECnet} usano il protocollo DECnet, usato dai VAX
-Digital sotto VMS quando ancora il TCP/IP non era diventato lo standard di
-fatto. Il protocollo è un protocollo chiuso, ed il suo uso attuale è di
-compatibilità con macchine che stanno comunque scomparendo. Lo si riporta solo
-come esempio 
+%% \subsection{La struttura degli indirizzi DECnet}
+%% \label{sec:sock_sa_decnet}
+ 
+%% I socket di tipo \const{PF\_DECnet} usano il protocollo DECnet, usato dai VAX
+%% Digital sotto VMS quando ancora il TCP/IP non era diventato lo standard di
+%% fatto. Il protocollo è un protocollo chiuso, ed il suo uso attuale è limitato
+%% alla comunicazione con macchine che stanno comunque scomparendo. Lo si riporta
+%% solo come esempio