Client-Serveur File - Plateforme e

Transcription

INSA - ASI
InfoRep : Client-Serveur
Informatique Répartie
Architectures Client-Serveur
Alexandre Pauchet
INSA Rouen - Département ASI
BO.B.RC.18, [email protected]
1/36
INSA - ASI
Programmation “classique” vs. Informatique Répartie
2/36
(1/6)
Quelques constats
Applications Client-Serveur
La plupart des applications réseaux sont du type Client-Serveur
Dans ce cadre, le client appelle un “service” auprès d’un serveur
⇒ la dénomination architectures orientées services existe par ailleurs ;
elle désigne principalement les Services Web
Exemples
Un navigateur web demande une page html à un serveur
Un client FTP demande la liste des fichiers et des répertoires
contenus dans un répertoire
etc.
INSA - ASI
3/36
(2/6)
Objectifs de l’Informatique Répartie
Programmation “classique”
En programmation classique lorsque qu’un programme a besoin d’un
service, il appelle une fonction d’une librairie, une méthode d’un
objet, etc.
Objectif de l’Informatique Répartie
Proposer des méthodes et outils pour simplifier le développement
d’applications réseau Client-Serveur, en essayant de s’abstraire de
l’aspect “distant” : proposer une programmation “naturelle”
Pour les applications “lourdes” :
Décomposer les applications en ensembles de services
Rationaliser la répartition des services pour limiter les échanges
d’informations
INSA - ASI
4/36
(3/6)
Programmation “classique” / Programmation distribuée
Une seule machine
Même OS
Même espace mémoire
Pas de problème de transport
Disponibilité du service assuré (tant que l’on a accès à la librairie)
Deux machines (sans compter celles “traversées”)
OS différents
Représentations différentes des types de bases
Espace mémoire : “passer un pointeur/référence comme argument” ?
Problème de transport : firewall, réseau HS, etc.
Retrouver le service ? Où se trouve-t-il ? Qui le propose ?
INSA - ASI
5/36
(4/6)
Interopérabilité des langages
Un même langage
Même paradigme de programmation
Même représentation des types de base
Même représentation de l’information composite
Deux langages
Représentation des types de base et de l’information composite
pouvant être différente
Association des paramètres effectifs aux paramètres formels ?
comment gérer les différents types de passage de paramètre ?
Paradigmes de programmation différents : qu’est-ce-qu’un objet pour
un langage procédural ? Comment gérer les erreurs ?
INSA - ASI
Une solution
6/36
(5/6)
1/2
Séparer la spécification/conception de l’implantation
Utilisation de langage propre à la spécification/conception
Utilisation de “traducteurs” vers le langage cible en distinguant le
client du serveur
Utiliser un langage de représentation de l’information
Langage de représentation indépendant du langage de programmation
Pour chaque langage de programmation, définir un ensemble
d’opérations pour “sérialiser” ces types (prédéfinis ou utilisateur)
INSA - ASI
Une solution
7/36
(6/6)
2/2
Utiliser un protocole de transport
Comment spécifier le service demandé
Comment associer les paramètres effectifs aux paramètres formels
Comment transmettre les erreurs
Définir la gestion du service
Utiliser un mécanisme permettant d’identifier la librairie (au sens
large) qui fournit le service
Utiliser un mécanisme qui permet d’activer le service si besoin
INSA - ASI
Client-Serveur
(1/15)
Définitions
Application Client-Serveur
Application faisant appel à des services distants au travers d’un échange
de messages (les requêtes et les réponses) plutôt que par un partage de
données (mémoire ou fichiers)
Serveur
Programme offrant un service sur un réseau (par extension, machine
offrant un service)
Client
Programme qui émet des requêtes (ou demandes de service). Il est
toujours l’initiateur du dialogue
8/36
INSA - ASI
Client-Serveur
9/36
(2/15)
Vues du client et du serveur
Vue du client
requête
Client
réponse
Serveur
Vue du serveur
Sélection
Requêtes
Traitement
Serveur
Réponses
Remarques
2 messages échangés au minimum (requête+réponse)
Toute application répartie peut se décomposer en ensemble de
requêtes de type Client-Serveur
INSA - ASI
Client-Serveur
10/36
(3/15)
Mises en oeuvre
Différents types de client-serveur
de données (ou procédural/fonctionnel)
à objets
à composants
Niveau de description
Bas niveau : socket ; orienté objets : RMI ; orienté services : Web
Services ; orienté ressources : REST ; orienté composants : J2EE
Langages de description d’interface : RPCL (RPC Sun), Corba XDR,
Java RMI
Intégration dans un langage de programmation
INSA - ASI
Client-Serveur
(4/15)
Conception : les protocoles de communication
Protocole de communication
Un protocole de communication formalise les messages (types,
contenus et ordre) échangés par les entités d’un système réparti.
Ils sont souvent décrits en UML par des diagrammes de séquence.
Ils sont une abstraction des protocoles de transport.
Exemple : calculatrice sur entiers positifs
Requête : C, request(opération, entier, opération) → S
Réponse : S, response(entier) → C
Réponse : S, error(description) → C
11/36
INSA - ASI
Client-Serveur
12/36
(5/15)
Formalisation des messages : de la conception à l’implémentation
Selon l’hétérogénéité entre le client et le serveur et le type d’architecture,
certains éléments de conception peuvent être modifiés :
Contenus des messages,
Typage des messages
Exceptions
Exemple
Un objet peut être sérialisé par l’ensemble de ses attributs
Une valeur en retour peu correspondre à une exception
INSA - ASI
Client-Serveur
(6/15)
Conception : serveur
Éléments à prendre en compte lors de la conception du serveur :
Gestion du(des) processus
Gestion des requêtes (priorités)
Exécution du service (séquentiel/parallèle)
Gestion de la mémoire et du stockage des informations
Taille des données manipulées
Lien entre appels successifs
Gestion des pannes
Vérification des échanges et détection des pannes,
Mémorisation de l’interaction et de l’état du client,
Processus de reprise
13/36
INSA - ASI
Client-Serveur
14/36
(7/15)
Processus unique
1
2
3
Requêtes
Traitement
Serveur
tantque Processus a c t i f
message <− r e c e p t i o n M e s s a g e ( . . . )
t r a i t e m e n t M e s s a g e ( message , . . . )
traitementService ( . . . )
envoyerMessage ( . . . )
fintantque
1
2
3
Réponses
INSA - ASI
Client-Serveur
15/36
(8/15)
Exemple de processus unique : sockets en mode non connecté
Exemple
Serveur
Client
socket()
socket()
bind()
bind()
recvfrom()
bloquant
sendto()
sendto()
recvfrom()
INSA - ASI
Client-Serveur
16/36
(9/15)
Processus unique avec gestion de file d’attente
1
2
3
Requêtes
Sélection et
Ordonnancement
Traitement
Serveur
tantque Processus a c t i f
message <− d e f i l e r M e s s a g e ( . . . )
t r a i t e m e n t M e s s a g e ( message , . . . )
fintantque
1'
2'
3'
Réponses
INSA - ASI
Client-Serveur
17/36
(10/15)
Exemple de processus unique avec file : sockets en mode connecté
Exemple
Serveur
Client
socket()
socket()
bind()
bind()
accept()
bloquant
connect()
read()/write()
read()/write()
INSA - ASI
Client-Serveur
18/36
(11/15)
Création d’exécutants
Réponses
Requêtes
n
atio
cré
Sélection et
Ordonnancement
création
cr
éa
tio
Traitement
Traitement
...
n
Traitement
Serveur
tantque processus a c t i f
m e s s a g e <− r e c e p t i o n M e s s a g e
(...)
t r a i t e m e n t M e s s a g e ( message ,
...)
p <− c r e a t i o n P r o c e s s u s
processusTraitement (p , . . . )
fintantque
procedure processusTraitement
(p , . . . )
debut
fin
INSA - ASI
Client-Serveur
19/36
(12/15)
Exemple de création d’exécutants : sockets connectés avec fork()
Exemple
Serveur
Client
socket()
socket()
bind()
bind()
accept()
bloquant
connect()
fork()
read()/write()
read()/write()
INSA - ASI
Client-Serveur
20/36
(13/15)
Pool d’exécutants
Réponses
Requêtes
...
tiv
ac
Sélection
n
atio
activation
ac
tiv
at
ion
Traitement
Traitement
...
Traitement
Serveur
m e s s a g e <− r e c e p t i o n M e s s a g e
(...)
t r a i t e m e n t M e s s a g e ( message ,
...)
empilerTache ( tache , . . . )
fintantque
t a c h e <− d e p i l e r T a c h e ( )
fintantque
INSA - ASI
Client-Serveur
(14/15)
Types de service / données manipulées
Sans données persistantes
Service fonction des paramètres d’entrée uniquement
Solution très favorable
⇒ tolérance aux pannes
⇒ contrôle de la concurrence
Exemple : calcul de fonction
Avec données persistantes
Exécutions successives manipulent les données
⇒ modification du contexte d’exécution
⇒ problèmes de contrôle de la concurrence
⇒ difficultés en cas de panne en cours d’exécution
Exemple : serveur de fichiers répartis
21/36
INSA - ASI
Client-Serveur
22/36
(15/15)
Types de service / mode
Appels de procédures non liés
Modification de données globales possible mais l’opération s’effectue
sans lien avec les appels précédents
Exemple : serveur d’enregistrement avec accès aléatoire
Appels de procédures liés
Appels successifs s’exécutent selon l’état laissé par les appels
antérieurs
⇒ ordonnancement des requêtes
Exemples : serveur d’enregistrement avec accès séquentiel, utilisation
de variables statiques, calculatrice avec mémoire
INSA - ASI
Appel de procédure à distance
(1/14)
Description
Infrastructure minimale pour mettre en place un Client-Serveur
Service : procédure ou fonction que le client peut faire exécuter à
distance par le serveur
But : forme et effet identiques à ceux d’un appel local
⇒ sans se préoccuper de la localisation de la procédure
⇒ sans se préoccuper du traitement des pannes
Mise en oeuvre classique : sockets, RPC Sun
Mise en oeuvre objet : Corba, RMI
Problèmes courants :
Pannes indépendantes client/serveur
Problèmes réseau
Temps de réponse
23/36
INSA - ASI
24/36
(2/14)
Principe de fonctionnement
Programme
client
Talon
client
1
Module de
transport
Module de
transport
Empaquetage
Dépaquetage
Talon
serveur
2
Corps
de
m()
Le réseau
m(a,b)
4
Dépaquetage
Programme
serveur
Empaquetage
3
INSA - ASI
25/36
(3/14)
Rôle des modules
Rôle des talons
Récupération des paramètres et résultats
Conversion des données
Rôle des modules de transport
Empaquetage-dépaquetage et transmission des paramètres et résultats
Gestion des erreurs de transport
INSA - ASI
26/36
(4/14)
Utilisation d’un langage pivot
Description
du service
Langage XXXL
Compilateur
XXXL → langage de programmation
Talon serveur
Talon client
Squelettes pour implanter services
Types définis dans XXXL
....
....
....
INSA - ASI
(5/14)
Problématiques courantes
Défaillances
Congestion du réseau ou du serveur
Panne du client
Panne du serveur
Erreur de transport ou de communication
...
Problèmes de sécurité
Authentification du client
Authentification du serveur
Confidentialité des échanges
...
Performance
...
27/36
INSA - ASI
28/36
(6/14)
Types de panne
Panne du serveur ⇒ attente du client
Client décide de la stratégie de reprise
Serveur applique la stratégie de reprise
Risque d’exécuter plusieurs fois la même procédure
Serveur orphelin : panne du client
Réalisation de travaux inutiles
Risque de confusion du client
États inconsistants
En cas d’erreur
Détection à l’aide d’horloges de garde
Mécanisme de reprise : nombre de relances en cas de dépassement de
délai (infini, au moins une fois, au moins X fois, ...)
INSA - ASI
(7/14)
Traitement d’une panne client
Panne du client après émission de la requête
⇒ requête est correctement traitée
Changement d’état du serveur
L’appel de procédure est déclaré orphelin
Détection : expiration du délai de garde 3
Recouvrement :
Client re-émet la requête : sémantique “Au moins UN”
Serveur ne peut pas détecter la répétition (id différente)
Service idempotent : pas d’incidence
Service non idempotent : service transactionnel (annulation par le
client des effets de l’appel orphelin)
29/36
INSA - ASI
(8/14)
Traitement d’une panne serveur
Panne du serveur après émission de la requête
⇒ requête peut-être partiellement traitée
Détection : expiration du délai de garde 1
Recouvrement :
Client re-émet la requête : sémantique “Au moins UN”
Client ne connaît pas l’endroit de la panne
Si avant 2 : pas d’incidence
Si entre 2 et 3 : changement d’état du serveur
Service transactionnel pour mémoriser id et l’état avant exécution
⇒ gestion serveur
30/36
INSA - ASI
(9/14)
Représentation des données
Problème classique des réseaux
Conversion est nécessaire si le client et le serveur
n’utilisent pas le même codage (big endian, little endian)
utilisent des formats internes différents
Dans réseau : passage de paramètres uniquement par valeur
⇒ émulation des autres modes
Solutions
Solution normalisée : syntaxe abstraite de transfert
Représentation externe commune ; ex : XDR Sun
Représentation locale pour le client, conversion par le serveur
Choix d’une représentation parmi n, conversion par le serveur
Négociation client/serveur
31/36
INSA - ASI
(10/14)
Passage par référence
Référence : adresse mémoire chez le client (resp. serveur)
⇒ aucun sens pour le serveur (resp. client)
Callback
Un callback (appel en retour) est le fait qu’un serveur (resp. un client)
exécute une action dont les résultats doivent être également répercutées
chez le client (resp. serveur).
Interdiction (procédures locales 6= distantes)
Simulation en découpant l’appel (copie de restauration)
Reconstruire la mémoire du client (solution coûteuse)
Mémoire virtuelle répartie (nécessite un système répartie avec
mémoire virtuelle)
32/36
INSA - ASI
33/36
(11/14)
Sérialisation et callbacks lors de passage d’objets
3 types de passage d’objet :
Passage simple d’information (structure) : sérialisation
Passage d’objet (attributs+méthodes) : sérialisation + accessibilité
au code
Passage d’objet non délocalisable (références locales=callback) : stub
Callback objet
Dans le cadre de systèmes orientés objets distribués, on appelle Callback
(fonction en retour) une méthode appelée par le serveur (resp. le client)
sur un objet transmis en paramètre par le client (resp. le serveur) et
nécessitant d’être exécuté par le client (resp. le serveur).
INSA - ASI
(12/14)
Désignation
Objets à désigner :
Le site d’exécution, le serveur, la procédure
Désignation globale indépendante de la localisation
Désignation :
statique : localisation du serveur connue à la compilation
dynamique : non connue à la compilation
Liaison :
Liaison statique
Liaison au premier appel
Liaison à chaque appel
34/36
INSA - ASI
35/36
(13/14)
Solution classique : DNS Internet
Client
Serveur
4
8
7
Talon client
5
6
1
Talon serveur
3
2
Serveur
d'annuaire
Etapes 1,2,3 : enregistrement en BD (serveur d’annuaire) des
services et noms de serveur
Etapes 5,6 : liaison client/serveur
Etapes 4,7,8 : Appel de procédure à distance
INSA - ASI
Performance : utilisation de cache
(14/14)
36/36

Client-Serveur File - Plateforme e

Transcription

Documents pareils

Domaine 02 : Informatique Nouveautés de Juillet-Août

Partenariat INSA

Nora DIOURI

Terminale STG GSI _fiche 2008_

Règlement du concours de nouvelles 2016 du groupe INSA Thème

DEMANDE D`HEBERGEMENT A L`INSA ELEVES

Technologie des applications client-serveur

MIYELI Jean

etudiant en informatique a l`institut national des sciences appliquees

LE GENIE MECANIQUE