les appels de procédure distants - 4

LES APPELS DE PROCÉDURE
DISTANTS
Heithem [email protected]
Rappel du schéma client-serveur
2
 
Appel synchrone Requête-Réponse
 
Mise en œuvre
 
Bas niveau : utilisation directe du transport : sockets (construit sur
TCP ou UDP)
 
 
Exemple : utilisation des sockets en C
Haut niveau : intégration dans un langage de programmation : RPC
(construit sur sockets)
 
Exemple : RPC en C
Définition
3
 
 
 
Appel de procédure à distance (Remote Procedure Call, ou RPC) : un
outil pour construire des applications client-serveur dans un langage de
haut niveau
L’appel et le retour ont lieu sur un site , l’exécution se déroule sur un site
distinct
L’effet de l’appel doit être identique dans les deux situations (local et
distant)
 
Mais cet objectif ne peut être atteint en toute rigueur en présence de défaillances
Avantages attendus
4
 
Facilité de programmation
  La
complexité des protocoles de communication est cachée
  Ne pas avoir à programmer des échanges au niveau réseau
 
 
Facilité de mise au point : une application peut être
mise au point sur un site unique, puis déployée sur
plusieurs sites
Portabilité : résulte de l’usage d’un langage de haut
niveau
  Indépendance
par rapport au système de communication
Problèmes de réalisation
5
 
Transmission des paramètres
  conversion
entre la forme interne, propre à un langage,
et une forme adaptée à la transmission
 
Gestion des processus
  Séquentielle
 
et parallèle
Réaction aux défaillances
  Trois
modes de défaillance indépendants : client,
serveur, réseau
Mise en œuvre
6
1 
Par migration
2 
Par mémoire partagée
3 
Par messages
4 
Par appel léger (LRPC)
Réalisation par migration
1
7
 
Stratégie de migration
  Le
code et les données de la procédure distante sont amenés
sur le site appelant pour y être exécutés par un appel local
habituel.
 
Analogie
  Stratégie
 
Avantages
  Très
 
de pré-chargement en mémoire.
efficace pour de nombreux appels
Inconvénients
  Univers
d’exécutions homogènes (ex machine virtuelle).
  Performances selon le volume de codes et de données.
  Problèmes de partage des objets.
2
Réalisation en mémoire partagée répartie
8
 
L’appel distant est réalisé en utilisant une mémoire
virtuelle partagée répartie
  La
procédure est installée pour le client comme pour le
serveur dans la mémoire virtuelle partagée répartie.
  Mais, réellement, elle est dans l’espace mémoire du serveur.
 
 
 
L’appel du client se fait comme si la procédure était
locale, provoquant un premier défaut de page sur le
début du code de la procédure.
Le code et les données de la procédure distante sont
amenés page par page sur le site appelant selon le
parcours du code et des données.
Analogie avec une stratégie page à la demande.
2
Réalisation en mémoire partagée répartie
9
 
Avantages
  Efficace
en cas de nombreux appels
  Efficace si tout le code et les données ne sont pas visités
  Résout le problème de l’utilisation des pointeurs (références
d’adresses en mémoire)
 
Inconvénients
  Univers
de systèmes homogènes
  Volume de codes et de données à échanger pages par
pages
  Problèmes de partage selon la cohérence de la mémoire
répartie
Réalisation par messages
3
10
 
Deux messages (au moins) échangés : requête et réponse
  Le
premier message correspondant à la requête est celui de
l'appel de procédure, porteur des paramètres d'appel.
  Le second message correspondant à la réponse est celui du
retour de procédure porteur des paramètres résultats.
Notion des souches (1/2)
11
 
Un mode de réalisation par interception (wrapping)
  Une
procédure intercepteur (wrapper) intercepte l’appel
d’un client vers un serveur et modifie le traitement serveur à
sa guise.
 
 
Décomposition en traitements avant et après le
traitement serveur.
Décomposition en intercepteur coté client, souche client,
et intercepteur coté serveur, souche serveur
  Très
nombreuses terminologies dans ce cas : Souches
("Stubs"), Talons, Squelettes ("Skeletons")…
 
Objectif: transformer l’appel local en un appel distant.
3
Notion des souches (2/2)
12
 
La souche client ("client stub")
Intercepteur (procédure) coté client qui reçoit l’appel en mode
local,
  Le transforme en appel distant,
  Envoie message d’appel de procédure,
  Reçoit le message contenant les résultats après l’exécution,
  Retourne les résultats comme dans un retour local de procédure.
 
 
La souche serveur ("server stub")
Intercepteur (procédure) coté serveur qui reçoit le message
d’appel,
  Fait réaliser l’exécution sur le site serveur par la procédure
serveur,
  Récupère les résultats et retransmet les résultats par message.
 
3
Les étapes de RPC par messages (1/4)
13
3
Les étapes de RPC par messages (2/4)
14
Étape 1
Le client réalise un appel procédural vers la procédure
souche client.
La souche client collecte les paramètres , les emballe dans
le message d’appel.
Étape 2
La souche client demande à une entité de transport locale
la transmission du message d'appel.
Étape 3
Le message d’appel est transmis sur un réseau au site
serveur.
3
Les étapes de RPC par messages (3/4)
15
Étape 4
Le message d’appel est délivré à la souche serveur.
La souche serveur déballe les paramètres
Étape 5
La souche serveur réalise l’appel effectif de la procédure serveur.
Étape 6
La procédure serveur ayant terminé son exécution transmet à la
souche serveur dans son retour de procédure les paramètres
résultats.
La souche serveur collecte les paramètres retour, les emballe dans
un message.
3
Les étapes de RPC par messages (4/4)
16
Étape 7
La procédure souche serveur demande à l ’entité de transport
serveur la transmission du message de réponse.
Étape 8
Le message de réponse est transmis sur un réseau au site client.
Étape 9
Le message de réponse est délivré à la souche client.
La souche client déballe les paramètres résultats.
Étape 10
La procédure souche client transmet les résultats au client en
effectuant un retour habituel de procédure en mode local.
3
17
Diagramme de RPC par messages
Talon
(stub)
client
Les talons (ou souches) client et serveur sont créés (générés
automatiquement) à partir d’une description d’interface
3
Talon
(stub)
serveur
Description d’interface
18
 
Interface = “contrat” entre client et serveur
Définition commune abstraite
  Indépendante d’un langage particulier (adaptée à des langages
multiples)
  Indépendante de la représentation des types
  Indépendante de la machine (hétérogénéité)
 
 
Contenu minimal
Identification des procédures (nom, version)
  Définition des types des paramètres, résultats
  Définition du mode de passage (IN, OUT, IN-OUT)
 
 
Extensions possibles
 
Procédures de conversion pour types complexes
3
Avantages/inconvénients
19
 
Avantages
  Applicable
en univers hétérogènes moyennant des
conversions
  Partage d’accès sur le site serveur
 
Inconvénients
  Pas
d’usage des pointeurs dans les paramètres.
  Échange de données complexes/de grande taille
délicat.
  Peu efficace pour de très nombreux appels.
3
D) Lightweight RPC (LRPC)
20
 
 
 
 
Quand on appelle un serveur qui se trouve sur la même
machine, la traversée des couches réseaux est inutile et
coûteuse  Optimisation de la communication
Problème: Client et Serveur (2 processus) qui se trouvent dans
deux domaines de protection différents !
Solution: la communication réseau est réalisée par un
segment de mémoire partagée entre le client et le
serveur qui contient une pile pour les paramètres
d’appel et de réponse.
LRPC: principe de RPC mais entre processus locaux
s'exécutant sur la même machine
4
Lightweight RPC
21
4
4
Avantages et Inconvénients : RPC léger
22
 
Avantages
  Transmission
d’appel très performant comme mode de
RPC local.
 
Limites
  Uniquement
applicable dans une même machine.
Récap. sur les modes de réalisation
23
 
RPC par messages :
  Le
premier modèle implémenté
  Supporte l’hétérogénéité
  Le plus simple à réaliser
  RPC,
 
RMI, DCE, CORBA, DCOM, SOAP
Des optimisations peuvent être obtenues par l’usage
des autres solutions
  Exemple
  Chorus
:
a développé les quatre solutions.
  DCOM a développé RPC par messages + RPC léger
24
Gestion du contrôle
I) Parallélisme chez le client
II) Parallélisme chez le serveur
I) Parallélisme chez le client
25
 
 
Appel de procédure distante en mode
synchrone
Appel de procédure distante en mode
asynchrone
Appel de procédure distante en mode synchrone
26
 
L’exécution du client est suspendue tant que la réponse du
serveur n’est pas revenue ou qu’une condition d’exception
n’a pas entraîné un traitement spécifique.
  Avantage : le flot de contrôle est le même que dans l’appel
en mode centralisé.
  Inconvénient : le client reste inactif.
Appel de procédure distante en mode synchrone
27
 
 
Solution au problème de l’inactivité du client : création
des activités concurrentes
Création de (au moins) deux activités (‘threads’) sur le
site client:
  L’une
occupe le site appelant par un travail à faire.
  L’autre gère l’appel en mode synchrone en restant bloquée :
  Le
fonctionnement est exactement celui d’un appel habituel.
Appel de procédure distante en mode asynchrone
28
 
 
 
Le client poursuit son exécution immédiatement après
l’émission du message porteur de l’appel.
La procédure distante s’exécute en parallèle avec la
poursuite du client.
Le client doit récupérer les résultats quand il en a
besoin.
II) Parallélisme chez le serveur
29
Exécution séquentielle des appels
  Exécution parallèle des appels
 
Exécution séquentielle des appels
30
 
 
Les requêtes d’exécution sont traitées l’une après l’autre
par le serveur  exclusion mutuelle entre les
traitements.
Si la couche transport assure la livraison en séquence et
que l’on gère une file d’attente « premier arrivé
premier servi », on a un traitement ordonné des suites
d’appels.
Exécution parallèle des appels
31
 
Dans ce mode le serveur créé un processus ou une activité
(un processus léger ou "thread") pour chaque appel
 
 
 
Gestion possible de pool de processus ou d’activités
Les appels sont exécutés concurremment.
Si les procédures manipulent des données globales
persistantes sur le site serveur, le contrôle de concurrence
doit être géré.
32
Gestion des données
I) Gestion des données applicatives persistantes.
II) Gestion des données protocolaires persistantes.
Gestion des données applicatives
sans données partagées persistantes
33
L’appel de procédure s’exécute en fonction
uniquement des paramètres d’entrée : en produisant
uniquement des paramètres résultats.
  Données locales à la procédure  pas de problème.
  Il n’y a pas de modification de données persistantes
sur le site serveur.
  Situation très favorable
 
  pour
la tolérance aux pannes
  pour le contrôle de concurrence
Gestion des données applicatives
partagées persistantes
34
Les exécutions successives manipulent des données
persistantes sur le site serveur:
  Une exécution modifie le contexte sur le site distant
 
  Exemple:
un serveur de fichier réparti, de bases de
données.
=> Problème de contrôle de concurrence
=> Problème des pannes en cours d’exécution
Gestion des données protocolaires
mode avec ou sans état
35
 
 
 
Autre aspect de la persistance des données sur le
serveur.
La terminologie avec ou sans état porte sur l’existence
ou non d’un descriptif pour chaque relation client
serveur au niveau du serveur.
Notion d’état : un ensemble de données persistantes au
niveau du protocole pour chaque relation client serveur.
  Permettrait
de traiter les requêtes dans l’ordre d’émission.
  Permettrait de traiter une requête en fonction des
caractéristiques de la relation client serveur (qualité de
service).
Mode sans état
36
 
 
 
Les appels successifs d’une même procédure s’exécutent
sans liens entre eux.
Il peut y avoir modification de données globales
persistantes sur le site serveur mais chaque opération
du point de vue du protocole s’effectue sans référence
au passé (indépendamment de toutes celles qui ont
précédé).
Exemple : NFS "Network File System" de SUN
  système
 
de fichier réparti basé sur RPC sans état.
Exemple : HTTP "HyperText Transfer Protocol"
  protocole
d’exécution de méthodes distantes sans état.
Mode avec état
37
Les appels successifs s’exécutent en fonction d’un état
de la relation client serveur laissé par les appels
antérieurs.
  La gestion de l'ordre des requêtes est indispensable.
  Exemple :
 
  Opérations
d’achat des produits sur Internet (payement
électronique)
38
Transmission des arguments
I) La transmission par valeur
II) Les autres modes de passage
Transmission par valeur (1/2)
39
 
 
Le seul mode de transmission des données dans les
messages en réseau.
Si le site client et le site serveur utilisent des formats de
données différents : problème syntaxique
=> une conversion est nécessaire.
 
Solution : notion de présentation des données au moyen
d’une syntaxe de transfert
=> une représentation lexicale des données simples et
une convention d’alignement (emballage/déballage)
des données commune au client et au serveur.
Transmission par valeur (2/2)
40
 
Définir une syntaxe abstraite des données
échangées:
  analogue
à celles des langages évolués,
  facile à générer pour un développeur d’application
 
À partir de la syntaxe abstraite :
  codage/décodage
de la syntaxe de transfert
Transmission par valeur
dans l’appel de procédure distante
41
 
En appel de procédure distante :
  génération
automatique du code des souches à partir
de la syntaxe abstraite,
  les souches fabriquent la syntaxe de transfert en
réalisant l’alignement (emballage/déballage) des
paramètres dans les messages.
Définition des nouveaux langages de syntaxe abstraite
adaptés aux appels de procédure distante : ‘Interface
Definition Language’ (IDL)
Pourquoi les langages IDL ?
42
Être indépendant des langages évolués utilisant le
RPC.
  Permettre l’appel distant avec tout langage évolué:
 
  Définition
d’un langage pivot (intermédiaire) de
description de données ayant des fonctionnalités assez
riches pour les langages les plus récents.
  Notion de correspondance entre les types retenus dans
l’IDL et les types des différents langages existants
Génération des souches
43
Source code client
Définition de l’interface en
IDL
Source code
serveur
Compilateur IDL
Souche client
Entête
Souche serveur
Compilateur
(C, java, ..)
Compilateur
(C, java,..)
Binaire client
Binaire serveur
Exemples d’IDL
et de format de présentation en RPC
44
 
SUN RPC
 
 
OSF DCE
 
 
Langage Java - Protocole JRMP Java Remote Method Protocol
Microsoft DCOM
 
 
IDL Corba - Format CDR Common Data Representation, Protocole IIOP
SUN Java RMI
 
 
IDL DCE - Format NDR Network Data Representation
OMG CORBA
 
 
RPCL - XDR eXternal Data Representation
MIDL Microsoft IDL - DCOM Protocole ORPC Object RPC Format NDR
Web Services
 
Web Services Definition Language (WSDL) – eXtensible Markup
Language (XML)
Autres modes de transmission :
passage par adresse
45
Le passage par adresse (par pointeur) utilise une
adresse mémoire centrale du site de l’appelant qui
n’a aucun sens sur l’appelé (sauf cas particulier).
  Indispensable de traiter ce problème.
  3 solutions :
 
  Interdiction
totale des pointeurs
  Simulation du passage par adresse en utilisant une
copie restauration
  Passage par adresse en mémoire virtuelle partagée
répartie
A) Interdiction totale des pointeurs
46
 
 
Dans la plupart des RPC, pas de passage des
paramètres par adresse ou de structures de
données contenant des pointeurs.
Introduit une différence dans le développement de
procédures locales et celles destinées à un usage
distant.
B) Simulation du passage par adresse en utilisant une
copie restauration
47
 
Passage par copie-restauration:
  A
l’appel: copie des valeurs des paramètres de
l’appelant vers l’appelé
  Au retour: copie de nouvelles valeurs pour les
paramètres de l’appelé vers l’appelant
B) Simulation du passage par adresse en utilisant une
copie restauration
48
 
 
 
 
Marche bien dans beaucoup de cas mais violation assez inacceptable dans certains cas de la
sémantique du passage.
Exemple de problème
procédure double_incr ( x , y ) ;
x , y : entier ;
début
x := x + 1 ;
y := y + 1 ;
fin ;
Séquence d’appel : passage par adresse
a := 0 ;
double_incr ( a , a ) ;
Résultat attendu : a = 2
Utilisation d’une copie restauration
Résultat obtenu : a = 1
B) Simulation du passage par adresse en utilisant une
copie restauration
49
C) Passage par adresse en mémoire virtuelle partagée
répartie
50
Faire réaliser des accès mémoire inter-sites :
mémoire virtuelle partagée répartie
  Solution très satisfaisante mais également très
coûteuse.
  Nécessité d’un système réparti autorisant la
mémoire virtuelle répartie (Chorus, Mach).
  Contrainte: Ne se conçoit que dans un système
réparti de machines de même type (environnement
homogène).
 
51
Désignation et liaison
Désignation
52
 
La structuration des noms et références permet de désigner les
services distants :
Nom symbolique : utilisable au moyen d’un serveur d’annuaire.
  Référence : une structure de données permettant de réaliser l’appel.
 
 
Référence : selon l’implantation considérée:
Désignation du protocole permettant l’accès distant (TCP ou UDP)
  Désignation de l’hôte où se trouve le serveur (adresse IP).
  Désignation du point d’accès de service transport (numéro de port).
  Désignation de la procédure.
 
Liaison (1/2)
53
 
 
 
 
Comment localiser une procédure distante ?
  Au moyen d’un service de gestion de noms (serveur d’annuaire)
À quel moment effectuer la liaison
  Le plus tôt possible (statique) => plus performant.
  Le plus tard possible (dynamique) => plus souple, moins
performant.
Réalisation de la liaison à la compilation (statique)
  Vision très statique, le serveur ne doit pas bouger.
Réalisation de la liaison en exécution (dynamique)
  Au chargement du client.
  Au moment de la première invocation (ou appel).
  Localiser la procédure (référence), mettre en cache.
  Relocaliser à chaque fois qu’il est nécessaire.
Liaison (2/2)
54
Problèmes
  Le serveur est-il disponible ?
  Solution
 
- fabrique de serveurs (performants)
Est ce que la version de la procédure utilisée est
consistante (stable) ?
  Solution
- gestion d’identificateurs uniques de
procédures (comportant des numéros de version).
 
Existence de serveurs multiples
  Gestion
d’une technique d’équilibrage de charge.
  Gestion de redondances.
Enregistrement d’un serveur
55
Site Serveur
Export(nom)
(1)
Serveur
Retour
Export(nom)
Serveur de nom
(annuaire)
(2)
Retour
Souche
serveur
Enregistrer_local (nom)
(3)
Ajouter_service(nom)
(4)
Enregistrer_global (nom)
Adaptateur
(gestion locale
des noms)
Liaison client-serveur
56
Site Client
Ref=import(nom)
Code client
(1)
Retour ref
Ref=import(nom)
Souche client
(2)
Retour ref
Requête_annuaire (nom)
(4)
Adaptateur client Vérifier (nom)
(3)
Serveur de nom
(d’annuaire)
Recherche (nom)
(5)
Site Serveur
Recherche
(nom)
Retour ref
57
Tolérance aux pannes
Appel local vs Appel distant
58
En appel local
  L’appelant et l’appelé s’exécutent sur la même machine : même
exécutant => mêmes performances et modes de pannes.
  L’appel et le retour de procédure sont des mécanismes internes
considérés comme fiables.
  Problème des erreurs abordé => exceptions chez l’appelant.
En appel distant
  Appelant et appelé peuvent tomber en panne indépendamment.
  Le message d’appel ou celui de retour peuvent être perdus (sauf si
l’on emploie un protocole de transport fiable).
  Le temps de réponse peut-être très long en raison de surcharges
diverses (réseau, site appelé).
RPC : “sémantique” en cas de panne
59
 
Détection de panne = expiration de délai de garde.
 
 
On tente de réexecuter l’appel. Combien de fois la procédure a-t-elle
été exécutée!?
La sémantique : nombre d’exécution de la procédure
(dépend des hypothèses de pannes et du mécanisme de reprise)
 
 
Indéfini (pas d’hypothèses)
Au moins une fois (appel répété, plusieurs exécutions possibles, au moins
une réussit)
 
 
Au plus une fois (0 ou 1 fois)
 
 
acceptable si opération idempotente (2 appels successifs ont le même effet
que 1 appel)
on évite les exécutions répétées, mais on ne garantit pas le succès
Exactement une fois (c’est l’idéal, difficile à atteindre)
Hypothèses de défaillances
60
 
Système de communication
  Congestion
du réseau, messages retardés
  Perte de messages
 
Serveur
  Défaillance
avant l’exécution de la procédure
  Défaillance pendant l’exécution de la procédure
  Défaillance après l’exécution de la procédure
  Défaillance définitive ou reprise possible
 
Client
  Défaillance
pendant le traitement de la requête
Les différents modes de pannes
61
 
Les pannes franches
  Le
 
système s’arrête (fail stop)
Les pannes transitoires
  Perte
 
de messages entre les entité communicantes
Les pannes temporelles
Les pannes franches (1/2)
62
Les pannes franches du serveur
  Attente indéfinie par le client d’une réponse qui ne
viendra jamais => Abandon du programme sur un
temps limite.
  Utilisation
d’un délai de garde par le site appelant
  Absence de réponse : le client choisit la stratégie de reprise:
⇒ Reprise
arrière automatique (si possible) : soit tentative d’exécution
sur un autre site soit reprise sur le même site (si relance)
⇒ 
Plusieurs exécutions successives de la même procédure
pour une seule demande
⇒  Peut
provoquer l’inconsistance (incohérence )de l’état du
serveur
Les pannes franches (2/2)
63
Les pannes franches du client
  Le serveur est dit orphelin ("orphan").
  Réalisation de travaux inutiles.
  Confusion, après relance du client, entre les nouvelles
réponses attendues et les réponses à d’anciennes
requêtes
  Entraine
⇒ 
une inconsistance de l’état du client
Nécessité de détruire les tâches serveurs orphelines et
de distinguer les requêtes utiles des vieilles requêtes.
Les pannes transitoires
64
 
 
 
Des messages sont perdus entre le client et le serveur
Cas facile : pertes traitées par une couche transport
fiable (TCP).
Cas difficile : il existe des RPC implantés pour des
raisons d’efficacité au dessus d’une communication non
fiable (UDP) => Mécanisme de traitement des pertes
de message à prévoir dans la conception du RPC :
  Exemple
1: La réponse acquitte la demande et la prochaine
requête acquitte la réponse.
  Exemple 2: lancer plusieurs exécutions de la même requête.
Les pannes temporelles
65
 
Cas d’un appel de procédure utilisé sous contraintes
de qualité de service temporelle
  application
temps réel
  application multimédia
Temps de réponse : la réponse doit parvenir avant
une date limite définie par une échéance.
  Variation du temps de réponse : La variation du
temps de traitement doit être bornée.
  Gestion de priorités : gestion d’échéances intégrant
les délais réseaux.
 
Gestion des Orphelins (1/3)
66
 
Demande reçue par le serveur suivie d'une panne du
client : requête orpheline
Abandonner le plus vite possible l’exécution en cours.
  En laissant un état cohérent sur le site serveur.
 
1. Extermination
 
 
Une approche de journalisation: la souche client
enregistre en mémoire stable tous les appels en cours.
Lorsqu'un site client est relancé, il doit examiner
l'historique des appels en cours non terminés et demande
la destruction de tous les serveurs orphelins encore actifs.
Gestion des Orphelins (2/3)
67
2. Réincarnation
 
 
 
Une technique de numéros de séquence: en fait un
numéro d'époque (séquence) correspondant aux
périodes d'activité successives du client.
Il doit être enregistré en mémoire stable et doit
marquer toutes les requêtes (appels et réponses).
Lorsqu'un client est relancé il change d'époque
(numéro de séquence) et diffuse sa nouvelle époque à
ses serveurs qui détruisent les appels anciens.
Gestion des Orphelins (3/3)
68
3. Expiration
 
 
Une technique de délais de garde : l'exécution d'un serveur est
toujours associée à une surveillance périodique du client : le
serveur arme des délais de garde.
Si le quantum s'achève, le serveur demande à son client s'il est
encore opérationnel:
 
si le client répond : armement d'un nouveau délai et poursuite.
 
si le client est en panne : abandon cohérent d'exécution.