Il Modello Client/Server

Materie:	Riassunto
Categoria:	Sistemi
Voto:	2 (2)
Download:	165
Data:	21.06.2005
Numero di pagine:	4
Formato di file:	.doc (Microsoft Word)

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 processi 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:

lungo la sottorete di comunicazione, il pacchetto giunge a destinazione cioè raggiunge il livello fisico del nodo in cui è in esecuzione il programma server

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