Modello Client / Server
Il modello
client/servent, chiamato anche RPC (remote procedure call) è un modello di
architettura di rete che si differenzia dal modello OSI; nasce dalla necessità
di massimizzare l’efficienza e la semplicità di trasferimento dei dati tra due
nodi di una rete.
Mentre
all’interno del modello OSI sono previsti process 141g68b i perfettamente simmetrici
sugli Host che si scambiano i dati, nel modello RCP invece la comunicazione
avviene tra un nodo (client) che richiede un servizio (generalmente un file) ad
un altro nodo (server) preposto a fornirlo. Ciò implica l’esecuzione di
processi da parte del client e del server non simmetrici. Questi processi fanno
parte del software di connessione e che hanno lo scopo di rendere più
efficiente e trasparente possibile il lavoro del server. Come risultato finale
l’utente ha l’impressione che la procedura richiesta sia disponibile
direttamente sulla macchina che stà utilizzando e sulla quale è in esecuzione
appunto il programma-client.
Esempio di transazione tra Client e Server:
|
|
Client
1.
il processo-client (modulo front-end) richiama la procedura STUB, presente
nella propria libreria, passandogli come parametro la “richiesta” che
vuole inviare al server.
2.
la procedura STUB, preposta a gestire il processo di comunicazione,
procede alla formattazione della richiesta, cioè procede a creare, i parametri che saranno inseriti nel
messaggio da trasmettere al livello inferiore cioè al livello di trasporto e si pone in attesa di risposta
3.
nel livello di trasporto, in accordo con il tipo di protocollo
adottato, viene aggiunta al
messaggio l’intestazione opportuna e il pacchetto ottenuto viene inviato al
livello fisico e da qui alla
sottorete di comunicazione
|
|
lungo la sottorete di comunicazione, il
pacchetto giunge a destinazione cioè raggiunge il livello fisico del nodo in
cui è in esecuzione il programma server
|
|
Server
1.
attraversando il livello
fisico il pacchetto raggiunge il livello
di trasporto e da qui alla procedura STUB del server
2.
la procedura STUB del server, che è costantemente in attesa di
ricevere messaggi dai client, ricostruisce la richiesta originaria che è
stata impacchettata nel messaggio e la passa al programma-server.
3.
il processo-server (modulo back-end) richiama la procedura locale di
risposta al servizio richiesto; in seguito dopo aver ricevuto il risultato,
richiama la procedura STUB utilizzando quest’ultimo come parametro
4.
la procedura STUB formatta il messaggio e lo trasferisce al livello
di trasporto
5.
il livello di trasporto costruisce il pacchetto inserendo
l’intestazione e lo invia al livello fisico e da qui viene trasferito nella
sottorete di comunicazione
|
|
lungo la sottorete di comunicazione il pacchetto
raggiunge il livello fisico del nodo client e da qui le informazioni in esso
contenute risalgono i vari livelli, sino a raggiungere la procedura STUB
rimasta in attesa. Questa preleva il messaggio e consegna la risposta al
programma-client.
elementi importanti:
La comunicazione tra un client ad un server,
viene attivata in maniera diretta ad alto livello dal client, mediante l’invio
di una richiesta al server. Di fatto però i processi client e server si
limitano a richiamare delle procedure in ambiente locale, la transazione, che
resta a loro del tutto invisibile, è realizzata dalla procedura STUB che è
stata chiamata e che si occupa di predisporre il collegamento remoto in rete. Il
passaggio di parametri alla procedura STUB (che sono la richiesta di un
servizio del client e il risultato che il server deve inviare al client), viene
effettuato rigorosamente per valore.
Con i termini client e server si fa
riferimento a dei processi e non a delle macchine, infatti ad esempio su una
macchina possono essere in esecuzione in maniera concorrente più processi
server.
Seguono il modello client/server praticamente tutti i
servizi forniti tramite la rete internet (le pagine web, la posta
elettronica,ftp,telnet,ssh) il modello è utilizzato in generale anche per i
programmi in particolare nella comunicazione fra processi all’interno di uno
stesso sistema.
Il
problema dell’indirizzamento
Per
l’implementazione di questo modello, è stato affrontato anche il problema
dell’indirizzamento dei messaggi da parte del nodo client verso il server
remoto. Il modello impone che il processo-server nella sua fase di
inizializzazione registri se stesso presso il server di rete inviando a
quest’ultimo: il proprio nome e il numero della propria porta di
comunicazione. La soluzione più semplice
prevede che successivamente tutte le richieste passino attraverso il server di
rete. Per motivi di maggior efficienza è possibile implementare un:
·
canale
privato per le richieste verso il server: si impone che la procedura STUB, quando viene
richiamata per la prima volta, interroghi il server di rete per ottenere “il
riferimento” di rete del server a cui si vuole connettere, così da sfruttare,
per le richieste successive, un canale privato con il processo-server evitando
così che queste passino tutte attraverso il server di rete.
·
canale
privato per le risposte verso il client: è previsto anche che la procedura STUB del client
indichi direttamente nella richiesta di servizio il tipo di canale privato da
utilizzare per l'invio dell'esito/risposta
La gestione delle eccezioni
Le procedure
STUB sono progettate anche in modo da gestire eventi anormali, quali
malfunzionamenti del server (1), del client e della rete di
comunicazione (2).
1. nel caso in cui il client invii una richiesta
al server, ma quest’ultimo per problemi suoi non sia in grado di dare risposta,
per evitare che la procedura STUB del client rimanga eccessivamente in attesa
senza ottenere la risposta, viene associata alla STUB un timer che interrompe
l’attesa di quest’ultima se è passato troppo tempo dall’invio della richiesta,
sollevando un’eccezione di time out.
Quando la STUB
viene interrotta dall’eccezione di time out, può comportarsi in due modi:
-
ritrasmettere
la richiesta al server o
-
chiudere
il collegamento con quest’ultimo e comunicare il fallimento della transazione
al processo-client.
2. nel caso sia il client ad avere problemi dopo
aver effettuato la richiesta al server si possono adottare varie politiche:
-
si può
obbligare il server ad intervalli di tempo a ricontattare il client per
controllare che sia ancora in attesa (si => il server procede nel suo
lavoro,
no =>
il server elimina il processo divenuto orfano)
-
si
predispone il server qualora rilevi dei problemi di collegamento con il client,
ad eliminare il processo orfano e ad interrompere anche se stesso (rilasciando
tutte le risorse assegnantegli) per poi riavviarsi, così da eliminare qualunque
rapporto con il nodo “guasto”
-
si può
obbligare il client una volta ristabilita la comunicazione a comunicare al
server l’annullamento della richiesta
Server concorrenti e server
iterativi
Un
server iterativo risponde alle richieste e resta occupato non rispondendo
ad ulteriori richieste fintanto che non ha fornito una risposta alla richiesta;
una volta completata la risposta allora diventa nuovamente disponibile.
Un
server concorrente, al momento di trattare la richiesta crea un processo
figlio o un thread incaricato di fornire i servizi richiesti, per porsi
nuovamente in attesa di ulteriori richieste. Chiaramente nei sistemi
multitasking, più richieste hanno la possibilità di essere soddisfatte
contemporaneamente, perché più processi figli o thread, associati al client che
li ha invocati, sono in esecuzione in maniera concorrente. Una volta concluso
il lavoro ciascun processo figlio o thread viene terminato mentre il processo-server
rimane sempre attivo
