Caricare documenti e articoli online  
INFtube.com è un sito progettato per cercare i documenti in vari tipi di file e il caricamento di articoli online.
Meneame
 
Non ricordi la password?  ››  Iscriviti gratis
 

Modello Client / Server - ESEMPIO DI TRANSAZIONE TRA CLIENT E SERVER

finanze


Inviare l'articolo a Facebook Inviala documento ad un amico Appunto e analisi gratis - tweeter Scheda libro l'a yahoo - corso di



ALTRI DOCUMENTI

PRINCIPI CHE REGOLANO L'APPLICAZIONE DELL'IMPOSTA
Luis Cernuda
Assistenzialismo e fascismo - POPOLAZIONE E FAMIGLIA
IL BILANCIO DELLO STATO (artt. 81, 75 ,100 cost.)
GLI EFFETTI DELL'IMPOSIZIONE
LE ENTRATE PUBBLICHE
E' IMPORTANTE LA STRUTTURA FINANZIARIA
COME LE IMPRESE EMETTONO TITOLI
BACK UP FACILITIES
Tabelle di conversione - Binario - Ottale, Esadecimale

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

           







Privacy

Articolo informazione


Hits: 2507
Apprezzato: scheda appunto

Commentare questo articolo:

Non sei registrato
Devi essere registrato per commentare

ISCRIVITI

E 'stato utile?



Copiare il codice

nella pagina web del tuo sito.


Copyright InfTub.com 2019