X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=network.tex;h=d564dc4ac76540ac7d239268ec79ccaf6b2d6e63;hp=606a3300e9e153e6ba124a6001b4db85984f8ea5;hb=5c31faf40cb22faf707e6dc3b16770ae64fe5b4d;hpb=adbc2a4478d606025705a406603e6097584b9fa0

diff --git a/network.tex b/network.tex
index 606a330..d564dc4 100644
--- 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}
 
-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.
-
 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
-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}
 
-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}
 
-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}
@@ -317,7 +381,7 @@ reciproche e con alcune dalle principali applicazioni che li usano.
 
 \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}